HoneyPot Easy. PARTE III
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.
