lunes, 23 de septiembre de 2013

Manual de Honeyd (VI). Honeyd

d.- Honeyd

image

La instalación en Ubuntu de honeyd es muy sencilla, simplemente ejecutaremos:
apt-get install honeyd
y el sistema instalará la lista de paquetes necesarios incluyendo algunos ficheros de configuración básicos. 
Una vez hecho podemos echarle un vistazo al directorio /etc/honeypot dónde nos encontraremos un fichero de configuración de ejemplo junto con los ficheros de firmas de nmap, p0f y xprobe. Los ficheros de firmas los empleará honeyd para engañar a escaneos activos y pasivos cuando otros sistemas traten de averiguar el sistema operativo que está simulando. El fichero de configuración “honeyd.conf” puede servirnos de guía para crear nuestro propio fichero dónde simularemos nuestra red. 
En mi caso he decidido simular tres máquinas en el mismo rango de red que la de producción, los equipos y servicios, tal y cómo se puede ver en la primera imagen del guión son: windows2003 server, windows XP y Suse 8.0 (no todos los puertos están redirigidos desde fuera). El fichero de configuración será el siguiente:

### Máquina Windows 2003
create win2k
set win2k personality "Microsoft Windows Server 2003 Standard Edition"
set win2k default tcp action reset
set win2k default udp action reset
set win2k default icmp action reset
set win2k uptime 3867
set win2k droprate in 13
add win2k tcp port 80 "/usr/share/honeyd/scripts/win32/win2k/iis.sh $ipsrc $sport $ipdst $dport"
add win2k tcp port 110 "/usr/share/honeyd/scripts/win32/win2k/exchange-pop3.sh $ipsrc $sport $ipdst $dport"
add win2k tcp port 143 "/usr/share/honeyd/scripts/win32/win2k/exchange-imap.sh $ipsrc $sport $ipdst $dport"
# Ejemplo de una plantilla para Windows Xp
create template
set template personality "Microsoft Windows XP Professional SP1"
set template uptime 1728650
set template maxfds 35
# Servidor web
add template tcp port 80 "/usr/share/honeyd/scripts/web.sh"
add template tcp port 22 "/usr/share/honeyd/scripts/test.sh $ipsrc $dport"
# Debian-specific (use nobody = 65534 instead of 32767)
set template uid 32767 gid 32767
### Plantilla Linux Suse 8.0
create suse80
set suse80 personality "Linux 2.4.7 (X86)"
set suse80 default tcp action reset
set suse80 default udp action block
set suse80 default icmp action open
set suse80 uptime 79239
set suse80 droprate in 4
add suse80 tcp port 21 "/usr/share/honeyd/scripts/unix/linux/suse8.0/proftpd.sh $ipsrc $sport $ipdst $dport"
add suse80 tcp port 22 "sh /usr/share/honeyd/scripts/unix/linux/suse8.0/ssh.sh $ipsrc $sport $ipdst $dport"
add suse80 tcp port 25 "/usr/share/honeyd/scripts/unix/linux/suse8.0/sendmail.sh $ipsrc $sport $ipdst $dport"
add suse80 tcp port 79 "sh /usr/share/honeyd/scripts/unix/linux/suse8.0/fingerd.sh $ipsrc $sport $ipdst $dport"
add suse80 tcp port 80 "/usr/share/honeyd/scripts/unix/linux/suse8.0/apache.sh $ipsrc $sport $ipdst $dport"
add suse80 tcp port 3128 "sh /usr/share/honeyd/scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport"
add suse80 tcp port 8080 "sh /usr/share/honeyd/scripts/unix/linux/suse8.0/squid.sh $ipsrc $sport $ipdst $dport"
add suse80 udp port 514 "/usr/share/honeyd/scripts/unix/linux/suse8.0/syslogd.sh $ipsrc $sport $ipdst $dport"
create default
set default default tcp action block
set default default udp action block
set default default icmp action block
bind 192.168.0.22 suse80
bind 192.168.0.23 win2k
bind 192.168.0.24 template
bind 192.168.0.25 template
bind 192.168.0.26 template
Los pasos para crear y configurar cada una de las máquinas que simulará son los siguientes:
  1. Empleamos “create” para crear una máquina a simular y darle un nombre.
  2. Elegimos que tipo de equipo vamos a simular con “set nombre personality “Sistema operativo” ”. Para elegir el sistema operativo podemos elegir uno de los listados en el fichero /etc/honeypot/
  3. Podemos seguir estapleciendo una serie de parámetros con la opción set, como pueden ser, las acciones a realizar cuando reciba paquetes, udp, tcp, icmp, tiempo que lleva activa la máquina, cambiar los permisos de ejecución de honeyd,...
  4. Añadimos los protocolos y puertos que tendrá abiertos la máquina e incluso el script que queremos que ejecute cuando llegue un paquete, lo que permitirá simular determinados servicios.
  5. Vinculamos cada máquina creada a una ip con bind: bind “ip” “nombre_máquina”
Una vez creado el fichero lo ponemos en marcha indicándole: que no demonice el servicio y que muestre por pantalla información detallada (“-d”), la interfaz en la que queremos que escuche (-i eth2) los ficheros de firmas que ha de emplear para búsqueda de huellas del sistema operativo dependiendo del programa de reconocimiento que emplee el atacante (nmap.prints, xprobe2.conf y pf.os) indicamos dónde buscar las asociaciones de sistemas operativos (nmap.assoc), finalmente almacenará todos los logs en /var/log/honeypot/honeyd.log; incluiré las opciones de inicialización en un fichero ejecutable llamado arrancar_honeyd:
honeyd -d -i eth2 -f /etc/honeypot/honeyd_uned.conf -p /etc/honeypot/nmap.prints –x /etc/honeypot/xprobe2.conf -0 /etc/honeypot/pf.os -a /etc/honeypot/nmap.assoc -l /var/log/honeypot/honeyd.log
image
vemos que se conecta sin problemas y lanza el script web.sh que simula un servidor web, el cliente vería la siguiente imagen, ya que para comprobar que funciona nos conectamos, por ejemplo al servidor web de nuestra red:
image
Además los scripts también tienen sus ficheros de log como podemos ver en el siguiente punto.

e.- Ficheros de registro de la actividad.

En resumen, con la configuración previa habremos recogido información en los siguientes lugares:
  • logs “genéricos”
    • /var/log/syslog: honeypot vuelca su información en este lugar además del fichero que le marquemos
    • /var/log/iptables: conexiones que se ajustan a las reglas que he configurado en iptables
  • logs de honeyd
    • /var/log/honeyd/honeyd.log: fichero dónde se registran todas las conexiones a nuestro “tarro de miel”.
    • Logs de scripts:
      • /var/log/honeyd.txt para los servicios vnc, finger, proftpd, exchange-pop3, exchange-imap
      • /var/log/honeypot/iis.log para el servicio web iis.sh
      • para cada uno de los servicios un fichero en el directorio /var/log/honeypot
      • /var/log/ftp-dirección_ip_del_atacante: log servicio ftp
  • Logs de snort: /var/log/alert
  • logs de iptables: he creado dentro de /var/log/honeypot/ un fichero para cada uno de los servicios del honeypot además del genérico en /var/log/iptables.
  • Contenido de los paquetes grabados con wireshark: almacenado en ficheros también dentro de /var/log/honeypot.

    3.- Tráfico capturado.

    Las primeras muestras de que hay alguien escaneando nuestros sistemas nos las ofrece honeyd desde la propia consola:image
    en la imagen podemos ver cómo desde la 83.61.252.186 han solicitado conexión a los puertos 21, 80,110 y 8080, tras comprobar que están abiertos comienzan a ejecutarse los scripts asociados a esos puertos de manera reiterada. Normalmente esto indicará que estamos sufriendo un escaneo de puertos seguido de una comprobación automatizada de vulnerabilidades de esos puertos (como el que suele realizar, por ejemplo Nmap o Nessus.

    Para obtener más información y comprobar a modo de sumario de ataques, si esto es así, acudimos a los ficheros de log. Por ejemplo en /var/log/honeypot/honeyd.log
    image
    en el mismo podemos ver varias cosas, en primer lugar que es un escaneo automatizado por las inexistentes diferencias de tiempo entre cada test (primer campo de cada lína) además
    • el segundo campo nos indica el protocolo, tcp, udp, o icmp
    • el tercer campo puede ser una S (indica inicio de nueva conexión), E (end) final de conexión o “-” si el paquete no pertenece a ninguna conexión. En el caso de E, además nos marca la cantidad de datos recibidos y enviados al final de cada línea
    • los siguientes cuatro campos indican: ip y puerto de origen e ip y puerto de destino
    • Para los paquetes que no forman parte de una conexión honeyd muestra el tamaño del paquete y los Flags TCP
    • Finalmente se añaden comentarios al final como idetinficación pasiva del sistema operativo.
    Teniendo esto en cuenta, es bastante probable que se trate de escaneos realizados desde un programa tipo nmap o nessus que se esté ejecutando desde Windows
    Esto se verá corroborado accediendo también al fichero /var/log/honeyd.txt dónde viendo una parte de las entradas podemos comprobar cómo ha intentado las conexiones con el usuario anónimo para el ftp y contraseñas para distintos servicios, finalmente vemos que ha empleado nmap para realizar los escaneos con los scrpits incluidos en nmap.
    USER anonymous
    USER anonymous
    --ENDMARK--
    PASS IEUser@
    ",
    --ENDMARK--
    PASS IEUser@
    PORT 205,217,153,62,80,80
    PORT 205,217,153,62,0,80
    --MARK--,"sáb jun 26 12:12:40 CEST 2010","ssh","83.61.252.186","192.168.0.22",1443,22,
    "SSH-2.0-Nmap-SSH2-Hostkey
    Otro ejemplo de escaneo es el realizado por nessus que incluye más plugs para comprobación de vulnerabilidades que nmap. Un ejemplo de los datos capturados por los scripts de honeyd lo podemos ver en la imagen dónde vemos como otro usuario empleando nessus es capaz de comprobar también nombres de usuarios en el servicio FTP.
    image
    Comprobamos con whois la procedencia del tráfico con el comando whois o bien desde un navegador web:
    imageimageEn cualquier caso la información más exhaustiva, siempre que esté disponible y haya captado la firma del ataque nos la proporciona snort. En la siguiente captura se puede ver un ejemplo del fichero de alertas generado por otro compañero al hacer un “ruidoso” escaneo de puertos:
    [**] [125:4:1] (ftp_telnet) FTP command parameters were malformed [**]
    [Priority: 3]
    06/25-13:00:10.933428 79.x.137.x:35267 -> 192.168.0.22:21
    TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:135
    ***AP*** Seq: 0x825D4C76 Ack: 0xF02C098 Win: 0x7FFF TcpLen: 20
    [**] [1:100000160:2] COMMUNITY SIP TCP/IP message flooding directed to SIP proxy [**]
    [Classification: Attempted Denial of Service] [Priority: 2]
    06/25-13:00:12.764218 79.x.137.x:35271 -> 192.168.0.22:21
    TCP TTL:52 TOS:0x0 ID:11101 IpLen:20 DgmLen:64 DF
    ***AP*** Seq: 0x836BC090 Ack: 0x112039FA Win: 0x16D0 TcpLen: 20
    dónde podemos ver como el primero se corresponde con una búsqueda de vulnerabilidades en el servicio ftp:
    imageSi quisiéramos comprobar de modo más exhaustivo esos tráficos, tan sólo tendríamos que irnos a las capturas completas dónde podemos ver las vulnerabilidades buscadas y cómo:
    image
 4.- Conclusiones
Tras haber leído bastante documentación sobre honeypots – a los que sólo conocía de oídas- y pasarme bastante tiempo viendo logs y averiguando el funcionamiento de los mismos, creo que es un software interesante por varios motivos: en primer lugar porque recoge bastantes de las cuestiones relativas a seguridad (IDS, iptables, programas de detección de vulnerabilidades,...) y en segundo lugar porque creo que constituyen la demostración práctica ideal de que en cuanto conectamos un ordenador a la red quedaremos expuestos a múltiples riesgos.
Me llamó la atención -por mucho que lo hayamos leído a lo largo de este año- que cada vez que enchufamos nuestros equipos y abrimos puertos, comenzamos a recibir intentos de conexión desde múltiples redes en Internet: Francia, Suiza, Corea,.... y otras desde la red de nuestra propia operadora.
Mejor demostración de la existencia de gusanos, auto-rooters, mass-rooters es difícil encontrarla.
imageimage
También creo que los honeypots constituyen la mejor demostración de la necesidad de instalar mecanismos de seguridad en nuestras redes locales, en ocasiones se puede ver las mismas ips -o rangos sospechosamente cercanos- como a lo largo del tiempo realizan escáneres en busca de puertos abiertos sin que snort lance ninguna advertencia (¿quién podría sospechar de escaneos tan lentos que son lanzados a lo largo de días?).
Por otro lado me gustaría comentar que un problema con el que me pasé horas batallando, consistía en que los banners de los sistemas no salían correctamente ( cuando en los scripts aparecía echo -e “...”, aparecía la “e” cuando se accedía al servicio desde el exterior aunque no en local) por lo que los escáneres de puertos no reconocían ni permitían una correcta interacción con el honeypot. Como el link entre sh y bash estaba creado, lo que hice fue llamar a los scripts directamente desde el fichero de configuración sin emplear sh y cambiar todos los scripts para que los interpretara como #!/bin/bash, incluyendo el “scripts/misc/base.sh” que es llamado desde otros.
Finalmente añado un par de imágenes en las que se puede ver parte del escaneo con zenmap a mi red (uned.dnsalias.com) y la página web que sería visible desde el exterior:
image
image

1 comentario:

  1. la única conclusión es que tienes más cara que espalda, todo el contenido de este blog es una copia de tecnoloxiaxa.blogspot.com.es
    vaya experto ...........

    ResponderEliminar