Traducción
del texto: Know your enemy (Motives), disponible en
Honeynet Project
http://www.honeynet.org
Last Modified: 25 November , 2002
Las Honeynets pueden ser extremadamente difíciles de configurar, además de necesitar muchos recursos, requiriendo múltiples sistemas para construir e instaurar. Muchos usuarios de organizaciones que quieren investigar las tecnologías Honeynet puede que no posean suficientes computadores para crear una Honeynet. Por lo tanto, este artículo se centrará en construir una Honeynet usando un único computador y programas libres y OpenSource. Será llevado a cabo construyendo una Honeynet Virtual, usando la solución OpenSource User-Mode Linux (a menudo llamada UML). El formato de este artículo es un HOWTO, describirá paso a paso cómo construir una Honeynet en una única computadora usando UML, (incluyendo la pasarela Honeywall y honeypots), y luego discutirá un método de instaurar el Control de Datos y la Captura de Datos de la Honeynet. Este artículo supone que ya has leído y comprendido los conceptos en
CTE: Honeynets y el artículo CTE: Honeynets Virtuales.
Este artículo no irá en detalle sobre como instaurar tecnologías avanzadas de Honeynet. Eso vendrá más tarde en el artículo futuro Conoce Tu Enemigo: Honeynet GenII. Al contrario, este artículo cubrirá en detalle cómo construir un entorno de pruebas Honeynet usando algunas tecnologías Honeynet básicas.
Plan de Ataque
Este artículo está divido en cinco partes. En la primera parte describiremos que es UML, cómo funciona, y como instalarlo y configurarlo. En la segunda parte describiremos cómo crear una red de múltiples sistemas en tu misma computadora, incluyendo todas las cosas de red. En la tercera parte describiremos cómo implementar el Control de Datos en tu Honeynet UML usando IPTables. En la cuarta parte describiremos cómo implementar la captura de datos usando Snort. Finalmente, en la quinta parte, describiremos cómo probar tu configuración.
Parte I: User Mode Linux
Al contrario que VMware, UML no requiere ningún programa adicional de virtualización. Es más, simplemente parcheas el núcleo de Linux de SO invitado con el parche de UML. Este parche convierte al núcleo en un binario ejecutable llamado 'linux', que permite al núcleo ejecutarse en tu sistema Anfitrión como un sistema operativo separado. Cuando ejecutas este núcleo parcheado con UML, todo lo que necesitas es darle un sistema de archivos para usar, y entonces tienes un sistema Linux independiente ejecutándose en tu computadora, dos por el precio de uno! Este nuevo núcleo es una aplicación en espacio de usuario ejecutándose en el núcleo real (SO Anfitrión). El núcleo UML recibe las llamadas al sistema de sus aplicaciones y las manda/pide al núcleo Anfitrión. Hay también herramientas adicionales para el manejo y red que puedes instalar en tu computadora que te hará la vida más fácil.
Algunas de las mejores características que han sido recientemente añadidas a UML
están diseñadas específicamente para honeypots. Estas opciones mejoran
significativamente
nuestra Honeynet UML. Nos centraremos en tres de estas opciones, sin embargo
puedes encontrar
los detalles técnicos y un HOWTO en
http://user-mode-linux.sf.net/honeypots.html.
Lo que haremos es construir nuestra Honeynet UML usando un rpm ya hecho. RPM es un gestor de paquetes para Red Hat Linux, permitiéndonos instalar de forma fácil paquetes de programas. El paquete UML hará dos cosas por nosotros. Primero, instalará un núcleo ya hecho 2.4.19 con el parche UML incluido, que es instalado como el binario ejecutable 'linux'. Esto nos permitirá ejecutar otro Linux con el núcleo 2.4.19. Además, el paquete contiene todas las utilidades UML. Puedes descargar todos los binarios UML y el código fuente de Lugar de Descarga de UML.
A continuación está el comando usado para instalar el rpm. Puedes observar qué ficheros y utilidades instala.
host #rpm -ivh user_mode_linux-2.4.19.5um-0.i386.rpm
host #rpm -ql user_mode_linux-2.4.19.5um-0.i386
Eso es todo! Al instalar este RPM has conseguido dos cosas. Primero, has instalado el núcleo ejecutable (/usr/bin/linux), que es nuestro núcleo invitado. Segundo, has instalado varias utilidades UML. Si quieres ejecutar otros núcleos a la vez, simplemente tienes que descargar los núcleos UML ya hechos, o usar el parche UML en el código fuente del núcleo. (** NOTA: Basándonos en nuestras pruebas, parece ser que el RPM de UML versión 2.4.19-5 sólo puede ejecutar un núcleo a la vez. Si quieres ejecutar múltiples núcleos, necesitarás descargar el último parche UML.)
Vale, ya sólo queda un último paso para nuestro núcleo invitado, un sistema de ficheros. ¿Para qué sirve tener otro núcleo cuando no hay un sistema de archivos donde el atacante pueda interactuar? Una vez más, vamos a Lugar de Descarga UML y encontramos una
imagen de un sistema de archivo. O si lo prefieres, puedes construirte tú mismo una haciendo una dd(1)
imagen de un sistema de archivos existente. Para el propósito de este HOWTO, instalamos y usamos la imagen de un sistema de archivos de un servidor RedHat 7.2 (65 MB comprimido). Hemos modificado este sistema de archivos para incluir los binarios telnet(1), vi(1), y pico(1). Una vez que has
descargado la imagen, no necesitas más configuración. Para arrancar tu nuevo sistema operativo invitado, simplemente descomprimes la
imagen del sistema de archivos, y ejecutas tu binario linux usando el sistema de archivos. Los comandos son:
host #gunzip root_fs.rh-7.2-server.pristine.20021012.gz
Cuando ejecutes el comando 'linux', verás en tu terminal un nuevo sistema operativo arrancando. Debería de terminar pidiéndote que entraras (login). Entra con el usuario 'root' y la contraseña 'root', dándote acceso al sistema operativo. Felicidades, lo conseguiste! Ahora, expliquemos lo que acabas de hacer, y que hacemos ahora.
Parte II: Configurando la Red
La parte eth0 del comando crea la interfaz eth0 en el SO invitado, diciendo que la interfaz manda los paquetes a través de tap0 en el sistema anfitrión. La única cosa que nos queda es dar a eth0 en nuestro SO invitado una dirección IP en el interfaz eth0. Esto ya está hecho en el sistema de archivos. En el caso de nuestro servidor Red Hat, la dirección IP de eth0 es 192.168.0.144. Si quieres cambiar alguna
función en el servidor Red Hat invitado, simplemente haz esas modificaciones como lo harías en cualquier otro sistema. Para confirmar esta configuración, ejecuta en el SO invitado los comandos:
guest #ifconfig -a
Para ver mejor cómo es tu red, observa el Dibujo 2.
El paso siguiente es confirmar que el sistema anfitrión puede hablar y comunicarse a través de la pasarela. Esto significa que lo que primero tienes que hacer es un ping a la dirección IP de la pasarela por defecto, en este caso 192.168.0.254, que es en realidad la interfaz tap0 en el sistema anfitrión. Una vez que confirmes que puedes hacer un ping a la interfaz interna, inténtalo a la interfaz externa del sistema anfitrión (generalmente la dirección IP de eth0). Esto te asegura que te comunicas a través del sistema anfitrión. Si el ping no ha funcionado, comprueba que no estás ejecutando ningún cortafuegos en el anfitrión, y que tu configuración de red en el anfitrión e invitado es correcta. Para confirmarlo, ejecuta en el SO invitado los comandos:
Parte III: Control de Datos
Usar todas estas características puede ser bastante complejo. Sin embargo, el Honeynet
Project ha desarrollado un script IPTables que lo hace todo por ti, simplemente tienes que
modificar las variables del script para tu Honeynet. El script es
rc.firewall. El script puede poner a tu cortafuegos en modo de
enrutamiento (routing mode) de capa 3, o en modo
bridge de capa 2. De los dos, la segunda opción es considerada superior, ya que es más
difícil de detectar. No se decrementa el TTL de los paquetes que se enrutan, y la pasarela
no tiene ni pila IP ni dirección MAC. Además, el modo bridge es más fácil de implantar, ya
que no hay problemas de NAT. Sin embargo, para que las IPTables funcionen en modo
bridge,
tu núcleo tiene que ser parcheado para soportarlo. El núcleo 2.4.18-3 de Red Hat lo soporta
por defecto, pero la mayoría de los otros no. Si quieres parchear tu núcleo para que lo
soporte, puedes encontrar un parche en
http://bridge.sourceforge.net/download.html. Para el propósito de este artículo, asumiremos
que tu núcleo NO soporta IPTables en modo bridge. Así que describiremos cómo usar el script
rc.firewall con tu sistema en modo
de enrutamiento usando NAT.
El objetivo es configurar las variables en el script rc.firewall. Una vez configuradas,
simplemente ejecutas el script y él implementará tus requerimientos de control de datos. Veamos
esas variables. Como en la mayoría de los scripts, cualquier cosa que empiece con un '#'
es un comentario y no se ejecuta ni se usa en el script. Hay dos áreas críticas de configurar,
la parte de red y la parte de control. Para la red, tenemos que identificar las direcciones IP y
las redes de los sistemas Anfitrión e Invitado. Las variables siguientes han sido configuradas
para la configuración UML que hemos descrito. Hay sólo dos variables que probablemente serán
diferentes en tu sistema, y las tendrás que modificar.
Específicamente,
PUBLIC_IP
(la dirección IP externa del SO Invitado que usarás para NAT)
El propósito de este artículo es ayudarte a aprender cómo construir tu propia Honeynet Virtual. La ventaja de los métodos que vamos a discutir es que es una solución muy fácil y barata, excelente para practicar o entender mejor las tecnologías con las que contamos. Puedes usar esta plataforma para probar,
desarrollar o modificar tecnologías Honeynet. Desafortunadamente, esta solución está limitada sólo a Linux; así que, la discusión estará basada en Linux.
User-Mode Linux es una máquina virtual, creada por Jess Dike y mantenida en su página
Web http://user-mode-linux.sourceforge.net.
UML te permite ejecutar múltiples instancias de Linux en el mismo sistema a la vez. Esta característica es similar a
VMware, sin embargo, UML está actualmente limitado a Linux. UML está diseñado para una variedad de propósitos, como deputar el núcleo, probar aplicaciones, etc. Nosotros vamos a usarlo para ejecutar una Honeynet en una única computadora, más concretamente una única pasarela con un Honeypot detrás. Para esto, explicaremos cómo instalar y ejecutar UML en un sistema Red Hat 7.3. Usaremos la misma terminología usada en el programa VMware, más concretamente el sistema Anfitrión es el sistema operativo original que corre en la máquina. Cualquier otro sistema operativo añadido (los sistemas operativos virtuales) serán llamados Invitados. Para ver esta configuración, visita el Dibujo 1 en el artículo CTE: Honeynets Virtuales.
/usr/bin/jailtest
/usr/bin/linux <- binario ejecutable que es realmente el núcleo UML, el SO Invitado
/usr/bin/tunctl
/usr/bin/uml_mconsole
/usr/bin/uml_moo
/usr/bin/uml_net
/usr/bin/uml_switch
/usr/lib/uml/config
/usr/lib/uml/modules-2.2.tar
/usr/lib/uml/modules-2.4.tar
/usr/lib/uml/port-helper
host #linux ubd0=root_fs.rh-7.2-server.pristine.20021012 eth0=tuntap,,,192.168.0.254
Vale, ahora que estamos ejecutando dos sistemas operativos, el paso siguiente es conseguir que el SO invitado, nuestro Honeypot, conecte con nuestra pasarela y salga a Internet. Esto significa que si alguien quiere hablar con nuestro SO invitado, primero tiene que ir a través del anfitrión. Puede que no te des cuenta, pero ya has configurado todo esto. Comprueba el último comando que hemos ejecutado más arriba, donde ejecutamos el comando 'linux', sobre todo la parte eth0=tuntap,,,192.168.0.254. Este comando hace dos cosas. Primero, crea una nueva interfaz lógica en el sistema Anfitrión llamada tap0. Esta interfaz lógica es ahora la pasarela para el SO invitado, nuestro Honeypot. La dirección IP de la interfaz tap0, y la pasarela por defecto del SO invitado, es 192.168.0.254. La única cosa que puede ser diferente es la dirección IP de eth0 en el sistema anfitrión, que dependerá de cómo lo hayas configurado. En el caso de nuestro ejemplo, es 192.168.1.1. Para confirmar esta configuración, ejecuta en el sistema anfitrión el comando:
guest #netstat -nr
Una vez que has configurado el UML y la red, el siguiente paso es el Control de Datos.
El propósito del Control de Datos es controlar lo que el atacante pueda hacer desde y
hacia el Honeynet. Típicamente, permitimos todo hacia los sistemas Honeynet, pero
limitamos las conexiones hacia fuera. Para el propósito de este artículo, usaremos
IPTables, un cortafuegos OpenSoure que viene con Linux. IPTables es un cortafuegos con
control de estado muy flexible, incluyendo la capacidad de limitar conexiones, traducciones
de direcciones de red, logging, y otras muchas características.
INET_IP
(la dirección IP externa del SO Anfitrión)
----- rc.firewall-gen1 variables -----
### Si tienes múltiples direcciones IP públicas, usa esta variable
ARCH="multiple"
# Una lista separadas por espacios de las IP externas de los honeypots (IP públicas)
PUBLIC_IP=( 192.168.1.144 )
# Una lista separadas por espacios de las IP internas de los honeypots (IP privadas)
HPOT_IP="192.168.0.144"
### Variables para la red interna
LAN_IFACE="tap0" # Interfaz del Cortafuegos en la red interna
LAN_IP="192.168.0.254" # IP Privada del Cortafuegos en la red interna
MASK="255.255.255.0" # Máscara de red de la red interna
LAN_IP_RANGE="192.168.0.0/24" # Rango IP de la red interna
LAN_BCAST_ADRESS="192.168.0.255" # Rango IP de Difusión para la red interna
### Variable for external network
INET_IFACE="eth0" # Interfaz público del Cortafuegos
INET_IP="192.168.1.1" # IP pública del Cortafuegos
INET_BCAST_ADRESS="192.168.1.255" # Rango IP de Difusión para la red externa
### El script de IPTables puede ser usado con Hogwash o el modo inline de Snort
QUEUE="no" # No uses el soporte experimental QUEUE
### Configura los límites de conexiones hacia el exterior para los diferentes protocolos.
SCALE="hour" # segundos, minutos, horas, etc.
TCPRATE="9" # Número de conexiones TCP por $SCALE
UDPRATE="20" # Número de conexiones UDP por $SCALE
ICMPRATE="50" # Número de conexiones ICMP por $SCALE
OTHERRATE="10" # Número de otras conexiones IP por $SCALE
### Localización de iptables
IPTABLES="/sbin/iptables"
Una vez configurado, todo lo que tienes que hacer es implementar el Control de Datos es ejecutar el
script
en el sistema Anfitrión. Esto se hace ejecutando el comando:
host #/.rc.firewall-gen1
Para confirmar que has ejecutado con éxito el script, hay dos cosas que puedes comprobar.
Primeo, asegúrate que la traducción de direcciones está funcionando. Puedes confirmarlo si una nueva
interfaz lógica ha sido añadida al sistema Anfitrión. Después, revisa las reglas de IPTables.
Una vez confirmado, tu Control de Datos está activo.
Hay una gran variedad de herramientas para implementar el Control de Datos. Por ejemplo, puedes
usar Snort-Inline para bloquear o modificar ataques conocidos. Esto se puede hacer aprovechando la
opción QUEUE en el script de IPTables. Otras opciones incluyen el control del ancho de banda.
Sin embargo, estas opciones están más allá del alcance de este artículo. Para opciones adicionales,
visita la Sección de Herramientas sobre Honeynet.
Parte IV: Captura de Datos
Para IPTables, los logs ya han sido configurados con el script rc.firewall-gen1. Está configurado
para guardar todas las conexiones entrantes y salientes en /var/log/messages. Cualquier conexión
entrante es una indicación de un escaneo o un ataque. Cualquier conexión saliente indica que el
sistema ha sido comprometido. El valor de los logs de IPTables es sobre todo para alertar. Los
logs
no tienen suficiente información para decirnos lo que está haciendo el atacante. Para Snort,
lo configuramos para capturar cada paquete y todo su contenido que entre o salga de la Honeynet.
Aquí hay un fichero de configuración de Snort
.
Snort debería estar escuchando en la interfaz interna del sistema Anfitrión, tap0. Encontrarás
un sencillo script de arranque de Snort usado por el Proyecto
y usa el fichero de configuración de Snort recomendado. Asegúrate que modificas el
script para
monitorizar el interfaz tap0. Seguramente querrás ejecutar este script diariamente, ejecutando
el script desde cron.
host #./snort-start.sh
Hay también otras herramientas para implantar la Captura de Datos que están más allá del
objetivo de este artículo. Para opciones adicionales, visita la
Sección de Herramientas sobre Honeynet.
Parte V: Comprobando tu Honeynet UML
Primero abrimos un terminal en el sistema Anfitrión y monitorizamos los logs de IPTables en
/var/log/messages. Cuando iniciamos conexiones hacia fuera desde el sistema Invitado a través de
nuestro sistema pasarela, deberíamos ver los intentos guardados allí. Esta información es
crítica para propósitos de alertas, ya que indica que el honeypot ha sido comprometido, y el
atacante (o la herramienta automática) está intentando conexiones hacia fuera. Cuando llegue
al décimo intento de conexión hacia fuera, las conexiones TCP deberían de ser bloqueadas (han
llegado al límite) y guardadas. Más abajo está el comando que querrás ejecutar antes de intentar
alguna conexión hacia fuera.
host #tail -f /var/log/messages
Ahora, abre un terminal en el sistema honeypot, nuestro sistema Invitado. Desde allí iniciarás
unas conexiones TCP hacia fuera. Por ejemplo, desde el sistema Invitado intenta hacer un telnet a
diferentes sistemas en la red externa 192.168.1.0/24. No importa si estos sistemas existen o no,
ya que se intenta la conexión. Los paquetes deberían ser enrutados a través de la interfaz tap0
en nuestro sistema Anfitrión y guardadas por el Cortafuegos IPTables en /var/log/messages. Deberíamos
ver nueve conexiones aceptadas hacia fuera, después las restantes no permitidas. Todos los intentos
deberían ser guardados.
guest #telnet 192.168.1.105
guest #telnet 192.168.1.220 21
guest #telnet 192.168.1.5 80
guest #telnet 192.168.1.115 6667
Si ves los intentos guardados, y bloqueados después del límite, entonces tu Control de Datos
está implementado con éxito.
Ahora, queremos asegurarnos que funciona la Captura de Datos, sobre todo que el proceso de
Snort está capturando todos los paquetes y su contenido que entran y salen de la Honeynet. El
proceso de Snort debería estar monitorizando el interfaz interno del sistema Anfitrión, tap0.
Para comprobarlo, intentamos hacer un ping a varios sistemas en la red 192.168.1.0/24.
guest #ping -c 3 192.168.1.105
El proceso de Snort debería haber capturado los tres paquetes ICMP Echo Request y su contenido.
Debería haber guardado la actividad en formato binario de tcpdump, en el directorio
/opt/ids/snort/logs, en la fecha específica. Para confirmarlo, ejecuta los siguientes comandos:
host #cd /var/logs/snort/logs/($month_$date)/
Eso es todo! Acabas de completar una comprobación básica de tu Control de Datos y Captura de Datos.
Hay bastantes más comprobaciones que puedes hacer, sin embargo están más allá del objetivo
de este artículo.
Conclusión
Una vez que hemos completado el Control de Datos, el siguiente paso es la Captura de Datos. El
propósito de la Captura de Datos es capturar toda la actividad del atacante, sin que se entere.
Hay varios métodos para implementarlo, sin embargo nos centraremos en dos, los
logs de IPTables y
Snort. Los logs de IPTables son los logs generados por el Cortafuegos cuando hay una conexión
entrante o saliente. Snort es un IDS OpenSource que usaremos para capturar toda la actividad en
la red. UML tiene también una opción para capturar toda la actividad de la TTY en el espacio del
núcleo, sin embargo esta opción no es muy fiable y está más allá del objetivo de este artículo.
El quinto y paso último, de construir nuestra Honeynet UML es comprobar nuestra configuración,
específicamente el Control de Datos y la Captura de Datos. Queremos asegurarnos que nuestros
requerimientos de la Honeynet se están comportando como esperábamos. Comprobar el Control de
Datos es relativamente simple. Queremos asegurarnos que cualquier intento del honeypot de iniciar
una conexión hacia el exterior es guardada y controlada. Al guardarla, todos los intentos de
conexión deberían estar guardados en /var/log/messages, alertándonos cuando una conexión hacia el
exterior es iniciada, y que el honeypot seguramente ha sido comprometido. También, una vez
que se ha llegado al límite, queremos asegurarnos que no se permiten más conexiones hacia el
exterior. Para los propósitos de este artículo, comprobaremos conexiones hacia el exterior TCP,
que por defecto están limitadas a 9 intentos por hora. Para comprobarlo, necesitaremos dos
terminales abiertos.
Trying 192.168.1.105...
Trying 192.168.1.220...
Trying 192.168.1.5...
Trying 192.168.1.115...
host #ls *snort.log
host #snort -vdr *snort.log
El propósito de este artículo era cubrir cómo construir un entorno de Honeynet virtual usando
User Mode Linux. UML es una solución OpenSource que te permite ejecutar múltiples sistemas
operativos Linux a la vez. Esta es una excelente manera de comprobar y desarrollar tecnologías y ficheros
de configuración de Honeynet sin tener que gastar dinero en otros elementos.