HoneyPot Easy. PARTE III
Después del fabuloso éxito-no que han tenido mis anteriores publicaciones sobre honeypot parte I y honeypot parte II, voy a seguir con el asunto :-)os aguantáis !! xD.
Vamos a probar un honeypot sencillo, de baja interacción. ¿Qué es esto? En todos los manuales, libros,artículos y demás se intenta clasificar los honeypot según su nivel de interacción, es decir, "lo que simula el honeypot" y lo que permite trabajar con el. Por ejemplo, como hablábamos en el primer artículo de un servidor NetCat que escucha entradas, eso sería baja interacción, ya que no responde. Podríamos catalogar como media interacción, por ejemplo, lo mismo que hicimos con NetCat, pero que responda si el login es correcto, o incorrecto, y que alterne mensajes de usuario incorrecto, password incorrecto. Como alta interacción, podríamos pensar en un servidor SSH completamente funcional, que lo único que hace es monitorizar las conexiones. Por ejemplo, si montamos un servidor SSH con una vulnerabilidad conocida, o vamos a pensar que desconocida !! y analizamos el ataque, podemos detectar los bufferoverflow que manda el atacante y como inyecta el payload.
Como es lógico, cuando más nivel de interacción queramos, más complejo será montarlo, y sobre todo, analizar los log´s.
El nivel de interacción suele, SUELE, estar ligado a la calidad del honeypot, ya que no solo basta con qué el atacante vea un Banner de un servicio, o unas respuestas. Todos sabéis que no todos los sistemas operativos responden a las conexiones, desconexiones,etc de la misma manera, por lo que un buen honeypot es aquel que puede emular el comportamiento del sistema operativo emulado.( FIN, ISN,Fragmentación, ventana inicial, ACK, etc etc etc)
Ya hablaremos mas sobre esto cuando entremos con HoneyD. Pero para que os hagáis una idea, cuando se configura este honeypot, se descarga el fichero de definición de identificación de servicios/S.O. de NMAP para usarlo como método de respuesta ante ataques.
Como primera prueba de concepto, vamos a usar HONEYBOT sobre windows. El proceso de instalación es sencillo: lo descargamos y con unos doble clicks está instalado.
Antes de ponerlo en marcha, hacemos un netstat anal ( inicio-ejecutar-cmd- NETSTAT -ano) para comprobar los puertos que tenemos a la escucha.
Seguro que los más impacientes, a pesar de leer (o no) los dos anteriores post, se dedican a bajar programa e instalar... luego vienen los madres mías...
Es importante saber que, si tenemos un servidor escuchando el puerto 80 ( iis, apache o el de la nintendo ds) y queremos habilitar el honeypot escuchando ese puerto... o se pelean a palos y gana el mas fuerte, o no arranca...
En este ejemplo, un honeypot sencillo, y sobre un windows xp, para probar conceptos está bien, pero para poner un honeypot en producción(para distraer hackers o para "aprender" como atacan) debemos realizar todas las comprobaciones que hemos mencionado antes, deshabilitar servicios innecesarios.
Os imaginais cuando montemos un HoneyD sobre una máquina windows, para imitar un entorno linuxero, con puertos 135,137,139 y demás? cantaría mucho y el atacante detectaría la presencia de un honeypot.
El interfaz del programa es muy sencillo, agrupando por puertos, por ip´s de origen, y alguna cosita mas.
Se pueden configurar los servicios, pero solo indicar puerto (25) tipo ( tcp o udp) activo o inactivo y un nombre. desactiva alguno ( o todos, según tu paciencia) y ejecuta otro netstat para ver como queda.
Vámonos al otro lado, al del atacante, vamos a ver un nmap básico, sin comandos, sobre el honeypot.
Así tan "a lo jabali" ( guiño guiño xD) nadie se lo creería, pero con un poco de arte, te puedes entretener mucho. RECOMIENDO NO HACERLO CON ESTE HONEYPOT.
Vamos a conectaros con netcat al puerto 22 del honeypot, emulando intentar conectarnos al servidor ssh. La respuesta queda grabada en el log´s, tal como así.
Como podéis apreciar, se graban todos los comandos introducidos desde el sistema atacante.
Dada la simpleza de este honeypot, cuando le tiras un scaneo "sofisticado" como puede ser FIN, NULL y Xmas, el honeypot no sabe "gestionar" las conexiones, no devuelve RST, por lo que no se entera de nada de nada, por eso aparecen closed.
Para que se pueda ver mas gráfico, aquí os dejo la misma captura que ayer, sobre el resultado de un escaneo Nessus, con un perfil bastante complejo. Es curioso que honeybot me ha creado, en unos 5 minutos unos 4000 registros. Se sube el proceso a 30 megas, por lo que a nivel de procesamiento va muy sobrado.
Dentro de la carpeta de la instalación de honeybot, existe una carpeta llamada captura, para recolectar los malwares/virus/troyanos que recibe el honeypot. En mi carpeta capture he encontrado un fichero que imagino es una comprobación de Nessus para detectar la existencia de netbus. Revisar esta carpeta para ver lo que os llega, aunque por la antiguedad del honeypot, según el programador, detecta "solo":
Dabber,devil,netbus, Kuang, Mydoom, sasser, Lsas,msblaster, sub7 y poco mas.
Espero que os guste esta tercera entrega, y estar atentos a las posteriores !!
Gracias por leerme.
Vamos a probar un honeypot sencillo, de baja interacción. ¿Qué es esto? En todos los manuales, libros,artículos y demás se intenta clasificar los honeypot según su nivel de interacción, es decir, "lo que simula el honeypot" y lo que permite trabajar con el. Por ejemplo, como hablábamos en el primer artículo de un servidor NetCat que escucha entradas, eso sería baja interacción, ya que no responde. Podríamos catalogar como media interacción, por ejemplo, lo mismo que hicimos con NetCat, pero que responda si el login es correcto, o incorrecto, y que alterne mensajes de usuario incorrecto, password incorrecto. Como alta interacción, podríamos pensar en un servidor SSH completamente funcional, que lo único que hace es monitorizar las conexiones. Por ejemplo, si montamos un servidor SSH con una vulnerabilidad conocida, o vamos a pensar que desconocida !! y analizamos el ataque, podemos detectar los bufferoverflow que manda el atacante y como inyecta el payload.
Como es lógico, cuando más nivel de interacción queramos, más complejo será montarlo, y sobre todo, analizar los log´s.
El nivel de interacción suele, SUELE, estar ligado a la calidad del honeypot, ya que no solo basta con qué el atacante vea un Banner de un servicio, o unas respuestas. Todos sabéis que no todos los sistemas operativos responden a las conexiones, desconexiones,etc de la misma manera, por lo que un buen honeypot es aquel que puede emular el comportamiento del sistema operativo emulado.( FIN, ISN,Fragmentación, ventana inicial, ACK, etc etc etc)
Ya hablaremos mas sobre esto cuando entremos con HoneyD. Pero para que os hagáis una idea, cuando se configura este honeypot, se descarga el fichero de definición de identificación de servicios/S.O. de NMAP para usarlo como método de respuesta ante ataques.
Como primera prueba de concepto, vamos a usar HONEYBOT sobre windows. El proceso de instalación es sencillo: lo descargamos y con unos doble clicks está instalado.
Antes de ponerlo en marcha, hacemos un netstat anal ( inicio-ejecutar-cmd- NETSTAT -ano) para comprobar los puertos que tenemos a la escucha.
Es importante saber que, si tenemos un servidor escuchando el puerto 80 ( iis, apache o el de la nintendo ds) y queremos habilitar el honeypot escuchando ese puerto... o se pelean a palos y gana el mas fuerte, o no arranca...
En este ejemplo, un honeypot sencillo, y sobre un windows xp, para probar conceptos está bien, pero para poner un honeypot en producción(para distraer hackers o para "aprender" como atacan) debemos realizar todas las comprobaciones que hemos mencionado antes, deshabilitar servicios innecesarios.
Os imaginais cuando montemos un HoneyD sobre una máquina windows, para imitar un entorno linuxero, con puertos 135,137,139 y demás? cantaría mucho y el atacante detectaría la presencia de un honeypot.
El interfaz del programa es muy sencillo, agrupando por puertos, por ip´s de origen, y alguna cosita mas.
Se pueden configurar los servicios, pero solo indicar puerto (25) tipo ( tcp o udp) activo o inactivo y un nombre. desactiva alguno ( o todos, según tu paciencia) y ejecuta otro netstat para ver como queda.
Vamos a conectaros con netcat al puerto 22 del honeypot, emulando intentar conectarnos al servidor ssh. La respuesta queda grabada en el log´s, tal como así.
Dada la simpleza de este honeypot, cuando le tiras un scaneo "sofisticado" como puede ser FIN, NULL y Xmas, el honeypot no sabe "gestionar" las conexiones, no devuelve RST, por lo que no se entera de nada de nada, por eso aparecen closed.
|
|
Espero que os guste esta tercera entrega, y estar atentos a las posteriores !!
Gracias por leerme.
