Honeynets Virtuales

Se da permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia Libre de Documentación GNU, versión 1.2 o cualquier versión posterior publicada por la Free Software Foundation (Fundación para el Software Libre); este documento no tiene secciones invariantes, textos de portada ni de contraportada. Se incluye una copia de dicha licencia en la sección titulada “Licencia de Documentación Libre GNU”.

 

Las Honeynets Virtuales son una solución que te permiten ejecutar una Honeynet completa con múltiples sistemas operativos en la misma máquina física. Discutidas por primera vez en el artículo Conoce a tu enemigo: Honeynets Virtuales, estas soluciones tienen la ventaja de ser más fáciles de desplegar y más sencillas de administrar. El Honeynet Project también ha encontrado en VMware un excelente entorno de desarrollo para tecnologías Honeynet. En este artículo, te contaremos paso a paso cómo construir y desplegar tal solución utilizando el software comercial VMware. En este caso, construiremos una Honeynet Virtual GenII (2a Generación) con cinco honeypots distintos. Se asume que has leído y entiendes los conceptos discutidos tanto en CTE: Honeynets Virtuales como en CTE: Honeynets. Además, si esta es la primera vez que trabajas con tecnologías Honeynet, te recomendamos encarecidamente que lo hagas en un ambiente de laboratorio. Por último, como ocurre con todo el software virtual, necesitas saber que existe el riesgo de que los atacantes identifiquen, y potencialmente salgan de, el entorno virtual. Has sido advertido.

Plan de Ataque
El formato de este artículo es similar al de CTE: User-Mode Linux, se divide en cinco partes. En la primera parte describiremos qué es VMware, cómo trabaja, y cómo se instala. En la segunda parte, describimos cómo configurar VMware e instalar tu honeypot. En la tercera parte describimos cómo implementar el Control de Datos en tu Honeynet VMware utilizando IPTables. En la cuarta parte describimos cómo implementar la Captura de Datos utilizando Snort. Finalmente, en la quinta parte, describimos cómo probar tu configuración.

VMware
VMware es un software de virtualización que te permite ejecutar múltiples sistemas operativos al mismo tiempo. Al contrario que User-Mode Linux, VMware te permite ejecutar diferentes sistemas operativos, mientras funcionen en la arquitectura Intel X86. Desarrollado y vendido por VMware Inc, hay en realidad tres productos diferentes que puedes escoger: Worstation, GSX, o ESX. De los tres, nosotros usaremos GSX. GSX es más potente que Workstations, diseñado para implementar más de dos sistemas operativos al mismo tiempo y soporta administración remota. No obstante, la mayoría de la información comentada aquí también es aplicable a Workstation. Para los propósitos de este artículo, vamos a construir nuestra Honeynet Virtual en un portátil, concretamente un IMB Thinkpad T23, utilizando un procesador PIII a 1Ghz y 768 MB de RAM. El sistema operativo de base es Red Hat 7.3.

VMware trabaja instalando software de virtualización en tu máquina. Este software permite luego arrancar y ejecutar múltiples sistemas operativos al mismo tiempo. El primer sistema operativo que está instalado, el sistema operativo de base, se llama HostOS. Este es el sistema operativo en el que instalas VMware. Una vez que hayas instalado el HostOS y el VMware, puedes instalar sistemas operativos adicionales que se ejecuten dentro del entorno virtual. Todos estos sistemas operativos adicionales se llaman GuestOS, ya que son “invitados” en el sistema operativo base (HostOS). Para comprender mejor cómo funciona esto, consulta la Figura 1. Instalar VMware en un HostOS Linux es muy fácil, simplemente instala un paquete RPM.

Hay paquetes adicionales que podemos instalar, tales como el paquete de administración remota. Sin embargo, nuestro portátil no lo necesita ya que toda la administración se hará localmente. Para más información sobre estos paquetes adicionales, consulta la documentación de VMware.

Control de Datos
Una vez que has configurado VMware y los honeypots, el siguiente paso es el Control de Datos. El objetivo del Control de Datos es controlar qué es lo que el atacante puede hacer en la entrada y salida de la Honeynet. Típicamente, permitimos cualquier cosa en la entrada a los sistemas Honeynet, pero limitamos la salida. En este artículo usaremos IPTables, un cortafuegos OpenSource que viene con Linux. IPTables es un cortafuegos altamente flexible, que incluye la habilidad de limitar conexiones, traducción de direcciones de red (NAT), registro, y muchas otras características. Configuraremos IPTables para que actúe como filtro en nuestro HostOS, contando los paquetes de salida. Una vez que se haya alcanzado el límite de conexiones de salida, cualquier intento posterior será bloqueado, previniendo que el honeypot comprometido dañe a otros sistemas. Configurar e implementar esas características puede ser extremadamente complejo. No obstante, el Honeynet Project ha desarrollado un script IPTables llamado rc.firewall que hace el trabajo por ti. Simplemente tienes que modificar las variables del script para que se adapten a tu Honeynet, y luego ejecutar el script.

La primera cosa que tienes que decidir es si quieres que tu pasarela funcione en modo de enrutamiento de nivel tres (“layer three routing mode”), o en modo puente de nivel dos (“layer two bridging mode”). El modo puente de nivel dos (también conocido como GenII, o segunda generación) es el método preferido. Cuando tu pasarela actúa como puente, no hay enrutamiento o decrementos de paquetes TTL (“time to live”), actúa como un dispositivo de filtro invisible, haciéndola más difícil de detectar ante atacantes. Sin embargo, para que las IPTables trabajen en modo puente, tu núcleo debe estar parcheado para que lo soporte. Por defecto, la mayoría de los núcleos no soportan IPTables en modo puente. El núcleo 2.4.18-3 de Red Hat es uno de los pocos que soportan esto por defecto. Si deseas parchear tu núcleo, puedes encontrar el parche en http://bridge.sourceforge.net/download.html. En este artículo, asumiremos que tu núcleo SOPORTA IPTables en modo puente. Si tu núcleo no lo soporta, consulta el artículo CTE: UML para más información sobre la configuración del script rc.firewall para el modo enrutamiento de nivel tres.

Vamos a comentar cómo configurar el script rc.firewall para implementar la funcionalidad GenII. Hay dos áreas críticas que configurar, los asuntos de red y los de conexión. En realidad, la red es más simple en modo puente que en modo de enrutamiento. En modo puente no hay enrutamiento, ni asuntos de Traducción de Direcciones de Red (NAT). Simplemente convertimos el HostOS en un puente, y los GuestOS interactúan directamente con otras redes. Para los asuntos de conexión, tenemos que configurar cuántas conexiones de salida permitimos. Estas opciones las tenemos que configurar como sigue. Primero, tienes que establecer las direcciones IP públicas de los sistemas operativos invitados. Esas son las IP que los “hackers” atacarán, las IP válidas de nuestros honeypots. Como tenemos cinco honeypots, necesitaremos enumerar las cinco direcciones IP. Los filtros del cortafuegos necesitan saber quienes son:

PUBLIC_IP="10.10.10.201 10.10.10.202 10.10.10.203

10.10.10.204 10.10.10.205"

Segundo, necesitarás identificar el nombre de las interfaces internos para el HostOS. Por defecto, este es eth1. No obstante, nosotros usamos la interfaz virtual vmnet1, y tenemos que modificar esta variable.

LAN_IFACE="vmnet1"

Tercero, como estamos construyendo una Honeynet GenII, deberías considerar probar las capacidades de Snort-Inline para tirar (“drop”) ataques salientes conocidos. Está más allá del alcance de este artículo describir los detalles del Snort-Inline, esto se discutirá en un artículo futuro Conoce a tu Enemigo: Honeynet GenII. Sin embargo, puede que consideres el utilizar el Honeynet Snort-Inline Toolkit, que tiene binarios estáticos, precompilados, ficheros de configuración, reglas preestablecidas (“rulebases”), y documentación, que podrás encontrar en la sección de Herramientas Honeynet. Si quieres probar esta característica, debes activar la opción QUEUE. NOTA: Si habilitas esta opción, DEBES tener Snort-Inline funcionando, o TODOS los paquetes de salida se eliminarán. Si no estás seguro de este punto, NO habilites esta característica.

#QUEUE="yes"

# Use experimental QUEUE support QUEUE="no"

# Do not use experimental QUEUE support

Esas son las mínimas variables que debes considerar, puede haber otras dependiendo de la configuración de tu sistema. Hay opciones adicionales que puedes actualizar, como administración remota, limitar las conexiones que puede iniciar el cortafuegos, y dar a tus honeypots acceso DNS sin restricciones. También, por defecto, el script limita a cada honeypot las siguientes conexiones de salida por hora: 9 conexiones TCP, 20 conexiones UDP, 50 conexiones ICMP, y 10 otras IP. Los detalles del script están más allá del alcance de este artículo. Para entender mejor essas variables, te recomendamos que revises el script en detalle y pruebes las diferentes opciones en un entorno de laboratorio. Una vez que hayas configurado el script rc.firewall, lo implementas ejecutándolo. Recuerda, vas a poner tu HostOS en modo puente. Para esto, tu HostOS debe tener las utilidades de puente. En sistemas Red Hat, son conocidas como “brigde-utils-0.9.3-4”.

Hay dos conceptos a tener en cuenta cuando se usa el modo puente. Primero, tienes que arrancar todos los GuestOS antes de habilitar el puenteo. Cuando los GuestOS arrancan, buscan y utilizan la interfaz vmnet1. Si esta interfaz ya está puesta en modo puente, el GuestOS no encontrará la interfaz y no podrá hablar con la red. Así que, inicia todos los honeypots ANTES de ejecutar el script rc.firewall. El segundo es el tiempo, lleva entre 10 y 30 segundos hacer que el puenteo tenga efecto. Tienes que dar tiempo al puente para que aprenda dónde están todas las direcciones MAC antes de que pueda puentear paquetes.

host #/.rc.firewall

Para confirmar que el script ha tenido éxito, hay varias cosas que comprobar. Primero, asegúrate de que el puente ha sido habilitado. Puedes confirmar esto revisando el fichero /var/log/messages, tu núcleo debería registrar que ha entrado en modo puente (“bridging mode”). Segundo, deberías tener una nueva interfaz llamada “br0”, que es tu puente. Tercero, utiliza el comando “brctl” para ver qué interfaces están unidas al puente. Cuarto, tus interfaces internas y externas no tendrán una dirección IP, ya que ahora están en modo puente. Por último, revista tus reglas de IPTables para asegurarte de que estás filtrando conexiones.

host #tail /var/log/messages

host #ifconfig -a

host #brctl show

host #iptables -L -n

Si todo es correcto, tu Control de Datos está en su lugar. Hay otras opciones en la implementación del Control de Datos como la regulación del ancho de banda (“bandwidth throttling”).

Captura de Datos
Una vez completado el Control de Datos, el siguiente paso es la Captura de Datos. El objetivo de la Captura de Datos es capturar toda la actividad del atacante, sin que lo sepa. Hay una variedad de métodos para implementar esto, sin embargo nos centraremos en dos, registros (“logs”) de IPTable y Snort. Los registros de IPTable son los registros generados por el cortafuegos tanto para las conexiones entrantes como salientes. Snort es un IDS OpenSource que utilizaremos para capturar toda la actividad de la red y generar alertas para ataques conocidos.

En IPTables, el asunto del registro ya ha sido configurado para nosotros por el script rc.firewall. Está configurado para registrar todas las conexiones entrantes y salientes en /var/log/messages. Cualquier conexión entrante es una indicación de un sondeo, escaneo, o ataque. Cualquier conexión saliente indica que un honeypot ha sido comprometido. El valor de los registros de IPTable es principalmente el de alertas. Los registros no tienen suficiente información para decirnos qué está haciendo el atacante. El Snort, lo configuramos para capturar todo paquete y su contenido que entra o sale de la Honeynet. Aquí está el fichero de configuración del Snort que inicia el Snort y usa el fichero de configuración recomendado del Snort. Asegúrate de actualizar el script de inicio para monitorizar la interfaz vmnet1 del HostOS. Probablemente quieras ejecutarlo diariamente, desde el cron.

host #./snort-start.sh

Como esta es una Honeynet GenII, deberías considerar utilizar técnicas más avanzadas de Captura de Datos, como Sebek. Esto te permite capturar las actividades del atacante desde el núcleo. Hay muchas otras opciones de implementar Capturas de Datos, cuya descripción no entra en los propósitos de este artículo. Para más opciones, comprueba la Sección de Herramientas Honeynet.

Probar  tu Honeynet  VMware
El quinto, y paso final, para la construcción de nuestro Honeynet VMware es probar nuestra configuración, específicamente el Control de Datos y la Captura de Datos. Queremos asegurarnos de que los requisitos de nuestra Honeynet se comportan según lo esperado. Probar el Control de Datos es relativamente simple. Queremos asegurarnos de que cualquier intento por parte del honeypot por iniciar una conexión saliente es tanto registrada como controlada. Todos los los intentos de conexión deberían registrar una entrada en /var/log/messages, alertándonos de que una conexión saliente ha sido iniciada, y el honeypot probablemente ha sido comprometido. También, una vez que el límite se ha alcanzado, queremos asegurarnos de que no se permiten más conexiones salientes. Hay un truco para probar nuestra Honeynet. Puesto que estamos puenteando necesitamos una segunda máquina, el atacante. Para aquellos que no tienen una segunda máquina, podéis ejecutar una segunda máquina virtualmente iniciando un sistema UML. El sistema UML se asociará a la interfaz virtual tap0, mientras que todos nuestros honeypots VMware se asociarán a la interfaz virtual vmnet1. De esta manera tu HostOS está puenteando dos diferentes redes virtuales. Recuerda, tendrás que modificar tu script rc.firewall haciendo que tap0 sea la interfaz externa. Para aprender más sobre el funcionamiento del UML, consulta el artículo CTE: UML. El UML puede ser el atacante, sondeando los honeypots VMware. En este artículo, ése es el concepto de prueba que demostraremos. Nuestro atacante UML tendrá la dirección IP 10.10.10.100.

Probaremos las conexiones TCP salientes, que por defecto están limitadas a 9 por hora. Para probar esto necesitaremos dos ventanas de terminal abiertas. Primero abrimos un terminal sobre el HostOS y monitorizamos los registros de IPTable en /var/log/messages. Cuando iniciamos conexiones salientes desde el GuestOS a través de nuestra pasarela HostOS, deberíamos ver los intentos registrados allí. Esta información es crítica en cuestiones de alertas, indicando que el honeypot ha sido hackeado, y el atacante (o herramienta automatizada) está haciendo conexiones salientes. Al empezar la 10a conexión saliente, las conexiones TCP deberían ser bloqueadas (se ha alcanzado el límite) y registradas. Abajo está el comando que debes ejecutar antes de intentar cualquier conexión saliente.

host #tail -f /var/log/messages

Luego, abre un terminal en el sistema honeypot, nuestro GuestOS. Inicia varias conexiones TCP salientes hacia la IP externa, en este caso 10.10.10.100 (nuestro sistema UML). Probablemente tengas que repetir estos intentos varias veces.

Trying 10.10.10.100...

telnet: connect to address 10.10.10.100: Connection refused

Si ves los intentos registrados, y bloqueados después del límite, has implementado con éxito el Control de Datos. Luego, vamos a asegurarnos de que la Captura de Datos tiene lugar, concretamente que el proceso Snort está capturando todos los paquetes y su contenido que entran y salen de la Honeynet. Un proceso Snort debería estar monitorizando la interfaz interna del HostOS, concretamente vmnet1. Para probarlo, intenta hacer un ping al sistema externo, en este caso otra vez 10.10.10.100.

guest #ping -c 3 10.10.10.100

El proceso Snort debería tener capturados tres paquetes ICMP Echo Request y su contenido completo. Debería haber registrado la actividad en registros de formato binario tcpdump. Para confirmarlo, revisa el fichero de registro, hay un ejemplo abajo. Lo crítico es que no sólo capturas cada paquete y su cabecera, sino que estás capturando el contenido completo de cada paquete.

host #snort -vdr *snort.log

¡Ya está! Acabas de completar una prueba muy sencilla de las capacidades del Control de Datos y Captura de Datos. Hay muchas más pruebas avanzadas que puedes intentar, como utilizar una segunda y separada máquina que actúe como un sistema en Internet y que interactúe con el honeypot. No obstante esto está fuera de los objetivos de este artículo.

Nota: Mientras este artículo estaba en la fase de revisión final, el Honeynet Project empezó a utilizar una de las otras características de VMware para análisis forenses avanzados. Concretamente, la característica Suspend (Suspender) de VMware. Suspender te permite literalmente suspender la imagen de un GuestOS (o honeypot). Congela todos los procesos y graba la imagen de la memoria en un fichero. Esto significa que puedes Suspender un honeypot, apagar el ordenador, encenderlo una semana después, traer de nuevo del honeypot, des-suspenderlo, y lo tendrías exactamente como lo habías dejado antes. Esto tiene increíbles aplicaciones forenses. El Project ha empezado grabando imágenes suspendidas de máquinas hackeadas, y luego enviándolas a otros para su análisis. Esto nos permite analizar un honeypot hackeado mientras aún está en estado de ejecución. Lo importante aquí es que al analizar imágenes suspendidas, tienes que asegurarte de que lo haces en una red aislada, o tu honeypot hackeado puede intentar conectarse con algún sistema con el que se comunicara antes de ser suspendido.

Conclusión
El objetivo de este artículo era describir paso a paso cómo construir una Honeynet virtual utilizando el software de virtualización VMware. La meta es construir una Honeynet entera en una sola máquina. La ventaja con VMware es que puedes ejecutar muchos y diversos tipos de sistemas operativos al mismo tiempo. Si deseas intentar construir tu propia honeynet VMware puedes conseguir una copia de evaluación.