jueves, 11 de agosto de 2011

Honeypot 6

6.- Honeyd

Al igual que el honeypot BackOfficer, explicado previamente, es un honeypot de baja interacción, aunque mucho más versátil y que ofrece mucha más información. Para funcionar no asume la ip del sistema en el que se instala -como hace BackOfficer-, sino que emplea ips no empleadas por otro equipo.

Una de las ventajas que ofrece es que es capaz de simular una gran cantidad de sistemas operativos al mismo tiempo. 

Es un sistema de baja-interacción empleado principalmente en sistemas de producción a modo de alerta para detectar tanto ataques como sistemas comprometidos. De todos modos permite la incorporación de scripts para simular determinados servicios, algunos de ellos, por ejemplo en el caso del virus Kuang2 permiten incluso más interactividad para el atacante, guardando incluso los ficheros subidos por los atacantes.


Para trabajar con honeyd tendremos que redirigir todo el tráfico que deseemos al sistema que alberga honeyd, para ello podemos emplear básicamente dos métodos:
  • ARP Spoofing: podemos emplear programas como arpd o farpd, la manera de funcionar es realizando spoofing de ARP, es decir, cuando en la red local alguien pregunta la MAC de la tarjeta de red para una ip determinada, permanecen a la escucha y suplantan la identidad de las ips que queramos.
  • ARP Proxy: incluso lo podemos hacer de manera estática, lo único que tenemos que hacer es asignar de manera estática las MAC del honeypot a las ip con arp -s.
En mi caso para simular parte de las ip del sistema en producción he empleado el siguiente comando:
farpd -d -i eth2 192.168.0.20-192.168.0.30

Con la opción “-d” le indicamos que no demonice el serivicio y que muestre información detallada de las peticiones a las que responde. Con la opción “-i eth2” le especificamos que debe escuchar las peticiones de MAC en la interfaz eth2. Finalmente especificamos que sólo haga spoofing de las ips desde la 192.168.0.20 a la 192.168.0.30.

Nos permite emplear ficheros de firmas para que responda como lo haría el sistema real a determinados escáneres en busca de la huella del sistema (fingerprintins). Por defecto podemos emplear los ficheros de firmas de nmap ( iniciándo honeyd con la opción -p ) para simular el sistema y la versión del mismo que deseemos. También podemos especificar, con la opción “-x”, el fichero de firmas de xprobe para determinar cómo responderá el honeypot a las herramientas fingerprints de ICMP.

Por defecto almacena las conexiones en syslogd, aunque se pueda especificar un fichero independiente (mediante la opción “-l” ) dónde registrar todos los logs de honeyd. Además de esto se pueden especificar logs independientes para cada uno de los scripts empleados.
Por ejemplo, suponiendo que estamos en el directorio “/usr/share/honeyd/” y que hemos configurado los equipos a simular en el fichero “honeyd.conf” podríamos ejecutar honeyd de la manera siguiente:
honeyd -d -f honeyd.conf -p nmap.prints -x xprobe2.conf -0 pf.os -a nmap.assoc -l /var/log/honeypot/honeyd.log -i eth2

Finalmente tal y cómo explicaré en el otro documento honeyd debería ser empleado conjuntamente con algún sistema IDS -tipo snort-, para determinar con mayor facilidad el tipo de ataque y/o con algún sistema para almacenar el contenido completo de las comunicaciones -como tcpdump, tshark o wireshark-.

*próximamente colgaré una entrega en la que explicaré cómo poner en funcionamiento este honeypot y los resultados de algunas capturas realizadas con el mismo. Igualmente en breve nessus y snort.

Para ver el resto de manuales puede acudir al índice de temas de seguridad en el enlace