Conoce a tu enemigo:
Honeynets

Qué es una Honeynet, su uso, como funciona, y los problemas/cuestiones relacionadas.

Traducción del texto: Know your enemy (Honeynet), disponible en
Honeynet Project
http://www.honeynet.org
Última modificación: 25 de Julio del 2003

Licencia de la traducción

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"


El Honeynet Project es una organización de investigación no lucrativa dedicada al aprendizaje de las herramientas, tácticas y motivos de la comunidad blackhat y a compartir las lecciones aprendidas. La herramienta primaria utilizada para recoger esta información es la Honeynet. El propósito de este texto es discutir que es una Honeypot, su uso, detallar como trabaja y los riesgos/cuestiones que implica. Esperamos que la comunidad de la seguridad pueda tomar las tecnologías aquí tratadas, y no sólo utilizarlas para sus propios propósitos de investigación, sino que ayuden a desarrollar y mejorar esas tecnologías. Sin embargo, queremos asegurarnos que las organizaciones son conscientes de la cantidad de riegos y cuestiones implicadas en esta tecnología.

Qué es una Honeynet
Una Honeynet no es nada más que un tipo de honeypot. Expresamente, es un honeypot con mucha interacción designado principalmente para la investigación, recogiendo información del enemigo. Muchos honeypota tradicionales han sido para engañar o detectar ataques. Normalmente están compuestas por un único sistema que emula otros sistemas, emula servicios conocidos o vulnerabilidades, o crea entornos cerrados. Para aprender más sobre honeypots, la página http://www.tracking-hackers.com está dedicada a las tecnologías honeypot.

Una Honeynet es diferente de los honeypots tradicionales, es lo que clasificaríamos como un honeypot para la investigación. Esto no lo hace una mejor solución que los honeypots tradicionales, simplemente tiene un propósito diferente. En vez de darle uso siendo detectado o engañando a los agresores, su uso es recoger información de las amenazas. Las dos principales diferencias de diseño respecto a los honeypots tradicionales son:

  • No es un sólo sistema sino una red de varios sistemas y aplicaciones las cuales son investigadas y atacadas por los blackhats. Las Honeynets pueden utilizar varios sistemas al mismo tiempo, como Solaris, Linux, Windows NT, router Cisco, conmutadores Alteon, etc. Esto crea un entorno de red que refleja de forma más realista una red productiva. Además, al tener diferentes sistemas con diferentes aplicaciones, como un servidor DNS en Linux, un servidor Web Windows IIS, y un servidor de bases de datos en Solaris, podemos aprender sobre diferentes herramientas y tácticas. Quizás algunos blackhats se centran en sistemas específicos, aplicaciones o vulnerabilidades. Teniendo una variedad de sistemas operativos y aplicaciones, somos capaces de trazar con más exactitud el perfil de las tendencias y rasgos de los blackhat.
  • Todos los sistemas situados dentro de una Honeynet son sistemas comerciales estándar. Estos son sistemas y aplicaciones reales, los mismos que puede encontrar en Internet. Nada es emulado ni se hace nada para que los sistemas sean menos seguros. Los riegos y vulnerabilidades encontradas en una Honeynet son las mismas que existen hoy en muchas organizaciones. Uno simplemente puede tomar un sistema de un entorno comercial y situarlo dentro de una Honeynet.

Estas son dos diferencias de diseño que hacen de la Honeynet principalmente una herramienta para la investigación. Puede ser usada como un honeypot tradicional, detectando actividades no autorizadas, sin embargo una Honeynet requiere bastante más trabajo, riegos y administración. Simplemente no merece la pena hacer todo el esfuerzo de construir y mantener una honeypot sólo para detectar ataques.

Uso de una Honeynet
Tradicionalmente, la información sobre seguridad ha sido puramente defensiva. Cortafuegos, Sistemas de Detección de Intrusiones, cifrado; todos estos mecanismos se usan defensivamente para proteger los recursos de alguien. La estrategia es defender la organización de alguien tan bien como sea posible, detectar posibles fallos en la defensa y entonces reaccionar a esos fallos. El problema de esta situación es puramente defensivo, el enemigo está al ataque. Las Honeynets intentan cambiar esto. El principal propósito de una Honeynet es recoger información sobre las amenazas existentes. Nuevas herramientas pueden ser descubiertas, pueden determinarse patrones de ataque, y los motivos del agresor estudiados.

Las Honeynets no son más que una herramienta, y como tal puede ser usada para otros fines. Un ejemplo, las organizaciones pueden utilizar Honeynets para comprobar y desarrollar su capacidad de Respuesta ante Incidentes. Las ventajas que se obtienen analizando estos sistemas comprometidos es que se obtienen la mayoría de las respuestas. Puede tratar el sistema comprometido como un 'reto', donde comprobará sus habilidades para determinar qué pasó utilizando diversas técnicas forenses. Entonces puede comparar estos resultados con los datos capturados dentro de la Honeynet. Ejemplos de esto son los numerosos retos avalados por el Honeynet Project. Las Honeynets son simplemente una herramienta, encuentra su utilidad allá donde usted decida usarlas. Sin embargo, su principal propósito y diseño está basado en la investigación de amenazas.

Como funciona
Conceptualmente, las Honeynets son un mecanismo simple. Usted crea una red parecida a una pecera, donde puede ver todo lo que ocurre dentro de ella. Igual que a un pez, puede observar a los hackers interactuar con su entorno virtual. Además igual que en una pecera, puede poner allí casi todo lo que quiera. Esta red controlada se convierte en su Honeynet. Las actividades capturadas le enseñan las herramientas, tácticas y motivos de la comunidad blackhat.

Tradicionalmente, el gran problema de los profesionales de la seguridad reside en que la detección y captura de actividad blackhat supone una sobrecarga de información. El reto para muchas organizaciones es determinar de entre una enorme cantidad de información qué es tráfico productivo y qué es actividad maliciosa. Herramientas y técnicas como los Sistemas de Detección de Intrusiones, análisis forenses de las máquinas, o los análisis de los registros del sistema intentan resolver esto mediante una base de datos de marcas conocidas o algoritmos para determinar qué es tráfico de producción y qué es actividad maliciosa. Sin embargo, la sobrecarga de información, la contaminación de los datos, actividades no descubiertas, falsos positivos y falsos negativos puede hacer el análisis y la determinación de las actividades algo extremadamente difícil.

Como todos los honeypots, las Honeynets resuelven este problema de la sobrecarga de información a través de la simplicidad. Una Honeynet es una red diseñada para ser comprometida, no para ser usada por tráfico productivo. Así, cualquier tráfico entrando o saliendo de nuestra red es sospechoso por definición. Cualquier conexión iniciada desde fuera de la Honeynet hacia dentro de la red es probablemente algún tipo de sondeo, ataque u otra actividad maliciosa. Cualquier conexión iniciada desde dentro de la Honeynet hacia otra red de fuera indica que un sistema fue comprometido. Un agresor ha iniciado una conexión desde su recién atacada computadora y ahora está saliendo a Internet. Este concepto de ningún tráfico productivo simplifica enormemente la captura de datos y el análisis.

Requisitos
Para construir su Honeynet de forma satisfactoria, hay dos requisitos críticos; Control de Datos y Captura de Datos. Si hay algún fallo en cualquier requisito, entonces hay un fallo en la Honeynet. Las Honeynets pueden construirse y desarrollarse en cantidad de maneras diferentes, de forma que dos Honeynets nunca son iguales. A pesar de esto, todas deben reunir los requisitos sobre Control de Datos y Captura de Datos.

El Control de Datos es una actividad de contención. Cuando tratamos con blackhats siempre hay riegos, debemos reducir este riesgo. Queremos asegurarnos de que una vez comprometida, un honeypot no puede ser utilizado para dañar a algún sistema que no sea la Honeynet. Sin embargo, el reto es controlar el flujo de datos sin que el blackhat sospeche. Una vez que el sistema está comprometido, el blackhat a menudo querrá conectarse a Internet, para descargar herramientas, establecer conexiones IRC o enviar correos electrónicos. Tenemos que darle flexibilidad para ejecutar estas acciones, y estos pasos son los que queremos aprender y analizar. Además, los blackhats pueden sospechar si observan que no pueden realizar conexiones al exterior. Cometimos este mismo error con nuestra primera Honeynet. No permitimos conexiones salientes hacia Internet. El blackhat sólo necesitó quince minutos para darse cuenta de que algo no iba bien, limpiar el disco duro y abandonar la red. Así que, el truco es darle al blackhat la flexibilidad para ejecutar lo que necesite, pero sin permitir que utilice el sistema comprometido para atacar a otros, con ataques de Denegación de Servicio, escaneos de sistemas y exploits. En general, cuanto más permita al blackhat salir hacia el exterior, más aprenderá, pero más grande será el riesgo.

La Captura de Datos es la captura de todas las actividades del blackhat. son las actividades que se analizan para aprender las herramientas, tácticas y motivos de la comunidad blackhat. El reto es capturar tantos datos como sea posible, sin que el blackhat sospeche que cada acción está siendo capturada. Esto se hace con las menores modificaciones posibles, si las hay, a los honeypots. Además, los datos capturados no pueden guardarse localmente en el honeypot. La información guardada localmente puede ser potencialmente detectada por el blackhat, alertándole de que el sistema es una Honeynet. Los datos guardados pueden ser también perdidos o destruidos. No sólo tenemos que capturar cada movimiento del blackhat sin su conocimiento, sino que tendremos que guardar la información de forma remota. La clave está en capturar los datos por capas. No puede depender sólo de la información de una capa. Debe recoger datos de varios recursos. Así, de forma combinada, estas capas le permitirán pintar el gran cuadro.

Hay un tercer requisito, la Recolección de Datos, pero es sólo para organizaciones que tienen varias Honeynets en entornos distribuidos. Muchas organizaciones tendrán una sola Honeynet, así que todo lo que necesitan es Controlar y Capturar Datos. Sin embargo, las organizaciones que poseen varias Honeynets lógica o físicamente distribuidas alrededor del mundo, como la Honeynet Research Alliance tienen que recolectar todos los datos capturados y guardarlos de forma centralizada. Esta forma de captura de datos puede ser combinada, de forma exponencial incrementando su alcance. Consulte la Figura 1 para ver como la "Honeynet Research Alliance" lo ha conseguido. El requisito de Recolección de Datos proporciona el medio seguro para recolectar de forma centralizada toda la información capturada en las Honeynets distribuidas.

El Honeynet Project ha creado un documento que define estos tres requisitos extensa y detalladamente. El propósito del documento es dar a las organizaciones la flexibilidad para construir una Honeynet adaptada a su entorno y objetivos. Sin embargo, el documento asegura que las Honeynets son desarrolladas con eficiencia y seguridad, permitiendo la interacción de diferentes Honeynets. Para cualquier organización que considere el desarrollo de su propia Honeynet esta ALTAMENTE recomendado el seguimiento de estos requisitos. Le recomendamos que se tome un tiempo para revisar estos requisitos.

Definiciones sobre Honeynets, Requisitos y Normas.

Ahora vamos a revisar como el Honeynet Project ha implementado estos requisitos. Esto lo hemos separado en dos secciones, GenI y GenII. GenI (para la primera generación) explica como el Honeynet Project implementó por primera vez estos requisitos, desde 1999 al 2001. Basto y simple a la vez, fue muy efectivo en su tarea, capturando la mayoría de los ataques que se produjeron en Internet; gusanos, script kiddies, sondeos automáticos, etc. En el 2002 el Honeynet Project empezó a desarrollar nuevas herramientas y técnicas, llamadas GenII (en referencia a la segunda generación). Estas técnicas, siguiendo sus mismos requisitos, han ampliado enormemente sus capacidades. Las tecnologías de GenII dan a las organizaciones la habilidad de capturar las actividades de agresores más avanzados.

1a Generación (GenI)
Las tecnologías GenI implementan el Control de Datos y la Captura de Datos con medidas simples pero eficaces. La mayoría de los textos de la colección Conoce a tu enemigo fueron escritos utilizando estas tecnologías. Si nunca ha desarrollado una Honeynet, o no está seguro de lo que hace, las tecnologías GenI son con las que debe empezar. No son tan efectivas como las GenII, pero a través de su simplicidad y de la cantidad de pruebas hechas durante años, potencialmente poco pueden fallar. Primero trataremos como controlaremos a los agresores, y después como capturar sus actividades.

En la Figura 2 tenemos un mapa detallado de la red perteneciente a una Honeynet GenI. Esta es la Honeynet más usada en la colección de textos Conoce a tu enemigo. En el diagrama, puede ver un cortafuegos de capa tres separando la Honeynet en tres redes diferentes. Concretamente, la Honeynet, Internet y la red Administrativa. Cualquier paquete entrando o saliendo de la Honeynet tiene que pasar a través del cortafuegos y del router. El cortafuegos es nuestra principal herramienta para controlar las conexiones entrantes y salientes. El router se usa como suplemento a este filtrado. Nuestro cortafuegos está diseñado para permitir cualquier conexión entrante, pero controla las conexiones salientes.

El cortafuegos mantiene una traza de cuantas conexiones se realizan desde un honeypot (sistemas en amarillo en la Figura 2) saliendo a Internet. Una vez que un honeypot ha alcanzado un determinado límite de conexiones salientes, el cortafuegos bloqueará cualquier nuevo intento. Esto proporciona al blackhat la flexibilidad para ejecutar aquello que necesite, mientras que nos ofrece una protección automática contra el abuso. No hay un número correcto o incorrecto de conexiones a las que permitir. Esto depende de la funcionalidad que se busque. Si quiere capturar ataques automatizados, como los auto-rooters o los gusanos, entonces probablemente no necesitará conexiones salientes. Los ataques automatizados simplemente comprometen uno de los honeypots y entonces el cortafuegos bloquea todas las conexiones salientes, deteniendo así la reproducción de los ataques automáticos. De esta forma puede atrapar a las herramientas utilizadas para los ataques sin poner en riesgo a otros sistemas. Sin embargo, si desea descubrir actividad manual de los blackhat, o qué ocurre después de que un sistema sea comprometido, entonces probablemente necesitará permitir algún tipo de conexiones hacia el exterior. Una vez más, cuanta más actividad saliente permita, más podrá aprender pero mayores serán los riesgos.

Creemos que entre cinco y diez conexiones salientes por hora puede ser un buen número para mantener la felicidad del blackhat, mientras protegemos a otros de sus ataques. Esto protege a la Honeynet de ser usada como plataforma para escanear, sondear o atacar a otros sistemas. Algunas organizaciones no requerirán esta funcionalidad. Si puede permitirse el tener a alguien monitorizando la Honeynet 24 horas al día, entonces puede permitirse el permitir conexiones salientes ilimitadas. Si se identifica un ataque de Denegación de Servicio, la persona que monitoriza la Honeynet puede simplemente deshabilitar el ataque. Sin embargo, recomendamos la implementación de medios automatizados para hacer esto, puesto que muchas organizaciones no pueden permitirse una vigilancia de 24 horas al día.

Adicionalmente, un router se ha colocado entre el cortafuegos y la Honeynet. Esto se hace por dos razones. Primera, el router oculta al cortafuegos. Cuando una honeypot es comprometida, los blackhats encontrarán un router productivo entre ellos y las redes exteriores. Esto crea un entorno más realista y esconde al cortafuegos para no ser descubierto. El segundo fin del router es actuar como una segunda unidad de control de acceso. El router puede complementar al cortafuegos, asegurándose de que los honeypots comprometidos no se usan para atacar sistemas fuera de la Honeynet.

Actualmente hay bastantes herramientas diferentes que le permiten llevar la cuenta de las conexiones salientes. En principio construimos esta funcionalidad utilizando un cortafuegos CheckPoint Firewall-1 y un programa (un "shell script") que cuenta el número de conexiones salientes iniciadas. Cuando se llega al límite (en nuestro caso 5 conexiones) el script configura el cortafuegos para bloquear cualquier conexión adicional desde el honeypot comprometido. El script puede enviar una alerta cuando esto ocurra, notificando que un honeypot comprometido ha sido bloqueado. Datos concretos de como configurar esta funcionalidad, incluyendo el código fuente del script, pueden encontrarse en Detección de Intrusiones con FireWall-1. Otra opción es usar IPTables con la opción del límite. IPTables, un cortafuegos OpenSource que viene gratuito con Linux, puede usarse para contar las conexiones salientes y bloquear la actividad cuando se llega a cierto límite. El script automatizado rc.firewall implementa esta funcionalidad por usted. Simplemente configure las variables del script para adaptarlo a su Honeynet, entonces ejecute el script de IPTables. Éste configura IPTables por usted implementando el Control de Datos. Una tercera opción es el pf de OpenBSD, o filtro de paquetes (packet filter). Un parche para pf ha sido desarrollado, dándole la posibilidad para contar conexiones y deshabilitarlas cuando se ha alcanzado un límite. La ventaja con las modificaciones de pf es que pueden aplicarse a una pasarela de la capa tres, o a una pasarela de capa dos en modo puente (tratado con más detalle en la sección GenII). Estos tres ejemplos representan diferentes opciones para llevar a cabo el Control de Datos. Lo crítico no es como implemente el Control de Datos, sino que cumpla los requisitos del Control de Datos.

El router actúa como un control de acceso en la capa dos, ninguna Honeynet debe depender de una sola fuente para el Control de Datos. En principio utilizamos esto para protegernos del spoofing, DoS, o ataques basados en ICMP. El router sólo permite ser atravesado por los paquetes que tengan la dirección IP de origen de la Honeynet. En nuestro ejemplo, significa que sólo los paquetes con IP de origen en la red 172.16.1.0/24 pueden abandonar la Honeynet. Esto protege contra muchos ataques basados en el spoof, como el SYN Flooding o ataques SMURF. Además bloquearemos el tráfico ICMP saliente. Esto se lleva a cabo porque algunos de los cortafuegos tienen problemas con los estados de seguimiento de tráfico ICMP. Otras organizaciones no tienen que limitar ICMP de tal forma. Limitando el ICMP protegemos contra ataques como SMURF, reconocimiento de la topología de la red, o el Ping de la Muerte (sí, todavía vemos esto "en vivo"). Más abajo hay un ejemplo de una ACL básica para el filtrado en GenI.

router#show ip access-list 100
Extended IP access list 100
  deny icmp any any (5446314 matches)
  permit ip 172.16.1.0 0.0.0.255 any (66372 matches)
  deny ip any any log (59990 matches)

La combinación del cortafuegos y el router crea una técnica efectiva para controlar el tráfico saliente, en la que se da a los blackhats la flexibilidad para ejecutar la mayor parte de lo que necesitan realizar, mientras que limita ataques que pueden lanzarse contra otros sistemas.

Una vez que ha implementado el Control de Datos, el siguiente paso es la Captura de Datos. La primera capa de las actividades de captura es el cortafuegos. Antes, hemos tratado como podemos usar el cortafuegos para controlar los datos. Este mismo cortafuegos puede ser usado para capturar datos. El cortafuegos registra todas las conexiones iniciadas hacia y desde la Honeynet. Esta información es crítica, porque todas las conexiones son sospechosas. Hemos diseñado nuestro cortafuegos no sólo para que registre todas las conexiones, sino que además nos alerte cuando se intente realizar una conexión. Por ejemplo, si alguien intenta conectarse mediante telnet a un sistema en la Honeynet, el cortafuegos lo registrará y nos alertará del evento. Esto es muy útil para rastrear los escaneos. Otro uso es para las puertas traseras o los puertos propietarios. Muchos exploits crean una shell o una puerta trasera en el sistema. Estas puertas traseras son fáciles de detectar cuando el cortafuegos alerta sobre una conexión a un sistema en algunos puertos altos y aleatorios. El cortafuegos también nos alerta cuando un honeypot de la Honeynet inicia una conexión saliente. El cortafuegos una vez más registra y nos alerta de esta actividad. Sin embargo, esta alerta es de mayor prioridad ya que indica que un sistema ha sido comprometido. Tal alarma sería enviada por correo electrónico y a un busca.

Otra capa crítica es el sistema IDS, que tiene dos propósitos. El primero, y de lejos el más importante, es capturar toda la actividad en la red. Su principal tarea es capturar y registrar cada paquete y su carga que circula por nuestra red. Si volvemos a la Figura 2 podrá ver que el sensor IDS está en una zona físicamente compartida por todos los otros sistemas en la Honeynet. El sistema IDS reside en un 'puerto de monitorización', así que puede registrar toda la actividad de la red. Estos registros son utilizados para analizar las actividades del blackhat. La segunda función del sensor IDS es alertarnos de cualquier actividad sospechosa. Muchos IDS tienen una base de datos de marcas, así cuando un paquete en la red concuerda con una de las marcas, se genera una alerta. Esta función no es tan crítica para una Honeynet, ya que cualquier actividad es sospechosa por naturaleza. Sin embargo, los IDS pueden ofrecer información detallada sobre una conexión específica.

El Honeynet Project ha obtenido un fenomenal rendimiento con un IDS OpenSource llamado snort. Hemos configurado snort para que capture toda la actividad de la red en un fichero binario. Estos registros binarios son críticos, ya que capturan cada paquete que entra y sale de la Honeynet. Además, snort registra todas las comunicaciones ASCII (como teclas pulsadas durante una sesión FTP) en ficheros separados. Tanto los ficheros binarios como los ASCII son registrados en su propio directorio para cada día. Esto hace más fácil revisar y analizar los registros teniendo una base diaria. Para llevar a cabo estos registros diarios, hemos configurado un script de inicio el cual se ejecuta mediante 'cron' cada día, reinicia snort y guarda los registros en un nuevo directorio. En tercer lugar, todas las alertas de snort son reenviadas al servidor 'syslog'. Por último, utilizamos una base de datos común para recolectar las alertas desde las Honeynets distribuidas.

La tercera capa son los mismos sistemas, queremos capturar toda la actividad producida por parte del sistema y del usuario. El primer método para esto es tener todos los registros del sistema no sólo guardados localmente, sino que también en un servidor de registros remoto. Para los sistemas Unix y muchas unidades de la red, se consigue simplemente añadiendo una entrada para el servidor 'syslog' remoto en el fichero de configuración. Para sistemas basados en Windows hay aplicaciones de terceros que pueden registrar la información remotamente. Además, los registros del sistema pueden escribirse a un NFS o SMB compartido en el servidor de registros remoto. NT requiere el uso de software de terceros para tener la capacidad de escribir información del sistema a 'syslog', pero sí puede escribirlo en un sistema de ficheros de red (NFS). De esta forma, información crítica del sistema como la actividad de los procesos, conexiones del sistema, y exploits intentados es copiada de forma segura a un sistema remoto. No queremos realizar ningún intento de ocultar el uso de un servidor 'syslog' remoto. Si el blackhat lo detecta, lo peor que puede hacer es deshabilitar 'syslogd' (lo que es un comportamiento estándar para muchos blackhats). Esto significa que no tendremos registros muy continuos, sin embargo tendremos al menos información de como consiguieron acceso y desde donde.

Blackhats más avanzados intentarán comprometer el servidor 'syslog' remoto intentando cubrir sus huellas. Esto es exactamente lo que queremos que ocurra. El servidor 'syslog' normalmente es un sistema bastante más seguro. Esto significa para el blackhat que para tomar el control de dicho sistema deberá utilizar técnicas más avanzadas, las cuales capturaremos y aprenderemos de ellos. Si es servidor 'syslog' resulta comprometido, no hemos perdido nada. Sí, el blackhat puede conseguir el control del sistema y limpiar los registros. Sin embargo, no lo olviden. nuestro IDS que está en la red ha capturado pasivamente y almacenado todos los registros de la actividad llevada a cabo en la red. En realidad, el sistema IDS actúa como un sistema secundario registro remoto, ya que de forma pasiva captura todos los datos de la red.

Un segundo método para capturar datos del sistema el modificarlo para que capture pulsaciones de teclas y capturas de pantalla y que reenvíe estos datos de forma remota. Un ejemplo de esto es una versión modificada de 'bash'. Esta shell, desarrollada por Antonomasia, puede usarse para reemplazar el binario /bin/bash. La shell modificada reenvía las pulsaciones del usuario a syslogd, el cual entonces lo reenvía al servidor de registros remoto. Aunque sencillo, este método puede ser descubierto mediante un sniffer. También puede ser fácilmente deshabilitado matando al proceso 'syslogd', o no usando 'bash'. Anton Chuvakin mejoró esta capacidad parcheando /bin/bash para que no hag falta utilizar 'syslogd'. Esta capacidad para capturar toda actividad en una máquina no está limitada a Unix. Floydman ha creado una aplicación para Windows, llamada ComLog, que captura comandos ejecutados mediante la interfaz de 'command.exe'. Como este binario es uno de los métodos más comunes para administrar remotamente un sistema comprometido, es una forma excelente para capturar las actividades del agresor en una computadora basada en Windows.

2a Generación (GenII)
Los mecanismos que acabamos de describir para el Control de Datos y la Captura de Datos son efectivos, pero creemos que pueden ser mejorados. La finalidad de las Honeynets GenII es crear una solución que sea más fácil de desarrollar y aún más difícil de detectar. El Control de Datos en GenII ofrece al agresor mayores posibilidades para interactuar con los sistemas comprometidos, teniendo mayor control sobre sus actividades y haciendo más difícil que este control sea detectado. Esperamos que al darle al agresor más flexibilidad en sus acciones, especialmente en conexiones salientes, podamos recoger mayor información de ellas. Esto se consigue creando una respuesta más inteligente y flexible a las acciones del blackhat. A continuación expondremos los conceptos de la tecnología GenII. Para aprender paso a paso cómo desarrollar una tecnología de este tipo, lea el documento Concoce a Tu Enemigo: Honeynets GenII.

Las Honeynets GenII poseen todos los requisitos combinados en un único dispositivo. Esto significa que todo el Control de Datos, Captura y Recolección se llevará a cabo desde un mismo recurso. Esto hará mucho más fácil el desarrollo y mantenimiento de una Honeynet. Este dispositivo único será una pasarela de capa2, que actuará como puente. Esto nos ofrece diversas ventajas. El hecho de que el dispositivo sea de la capa2 lo hará mucho más difícil de detectar, ya que no posee pila IP. No hay enrutamiento de tráfico ni decrementos en el TTL. El dispositivo está bastante más oculto, así que los chicos malos nunca deberían saber que su tráfico está siendo analizado y controlado. La segunda ventaja es que, como pasarela, todo tráfico entrante o saliente debe pasar a través del dispositivo. De esta forma podemos capturar y controlar tanto el tráfico entrante como el saliente desde un único dispositivo. En la Figura 3 tiene un ejemplo de un posible desarrollo.

El primer avance en el Control de Datos será nuestra capacidad para detectar actividad no autorizada. En vez de simplemente rastrear la actividad hacia el exterior del agresor contando el número de conexiones salientes, añadiremos más inteligencia averiguando qué tipo de actividad es. Identificaremos actividad no autorizada a través de sus acciones e intenciones. Si intenta realizar treinta conexiones FTP salientes, no habrá ningún problema. Sin embargo, si intenta llevar a cabo un sólo exploit FTP hacia el exterior contra un sistema que no sea una Honeynet, entonces esta actividad debe ser controlada. Queremos añadir más inteligencia analizando las actividades del agresor, no simplemente contando su número de conexiones.

El segundo avance el modo en que responder a la actividad no autorizada. En vez de simplemente bloquear las conexiones, queremos modificar o regular la actividad del agresor. El ataque sale de la Honeynet, pero sin ser efectivo. Se pretende que estas respuestas sean mucho más difíciles de detectar por el agresor. La regulación la haremos modificando los paquetes cuando pasen a través de la pasarela de capa2. Por ejemplo, una vez que un agresor ha tomado control de un sistema dentro de la Honeynet, e intenta lanzar un exploit FTP contra un sistema que no sea una Honeynet. Con la tecnología GenI, el Control de Datos es limitado, después de quinto intento saliente, toda futura actividad, incluyendo cualquier exploit, será bloqueada. Sin embargo, con la tecnología GenII, la tentativa de exploit será identificada y modificada para hacer el ataque ineficaz. La pasarela de capa2 modificará diversos bytes pertenecientes al código del exploit, deshabilitando su funcionalidad, entonces permitirá continuar al ataque inválido. El agresor deberá ver que el ataque se lanzó y que obtuvo tráfico de vuelta, pero no entenderá porqué su exploit nunca funcionó. Conseguimos mayor control sobre las acciones del agresor sin su conocimiento. Además tenemos la capacidad de falsear respuestas, como bloqueando conexiones enteras, devolviéndole paquetes RST al agresor, forzando la caída de la conexión.

Al igual que el Control de Datos, las tecnologías GenII mejora considerablemente las capacidades de la Captura de Datos. Con las tecnologías GenI, la mayoría de los datos eran obtenidos a nivel de red, como los sniffers o cortafuegos. No obstante, el extendido uso del cifrado, como SSH, invalida esta capacidad. Algunos intentos se realizaron para obtener los datos desde los propios honeypots, como versiones modificadas de /bin/bash, pero estas soluciones tenían una capacidad limitada. Con GenII se mejoran estas capacidades capturando los datos desde el núcleo del SO. Esto asegura que a pesar del medio de comunicación utilizado, como SSH, SSL o IPSEC, esta información es igualmente capturada.

Otra área en la que el Honeynet Project está investigando es en el uso de Honeynets virtuales. Las Honeynets Virtuales combinan todos los elementos de una Honeynet en un único sistema físico. No sólo se reúnen los tres requisitos de Control de Datos, Captura de Datos y Recolección de Datos, sino que los propios honeypots se ejecutan en un único sistema. Las Honeynets Virtuales soportan tecnologías GenI y GenII. Ahora los honeypots son realmente sistemas operativos. Nada es emulado. La ventaja aquí es en coste y eficiencia. Es mucho más barato utilizar un único sistema para ejecutar todos los elementos de la Honeynet, y es mucho más sencillo de desarrollar y mantener. Puede aprender más sobre las Honeynets Virtuales en el texto Conoce a tu Enemigo: Definiendo Honeynets Virtuales.

Página de herramientas
De acuerdo, hemos tratado muchos conceptos y soluciones software para Honeynets. Para hacer más sencillo el proceso de construcción, hemos creado una
Página de Herramientas. El propósito de esta página es tener un único sitio donde "recurrir" para cualquier necesidad de su Honeynet. Esta página también contiene enlaces a otras herramientas de Control de Datos y Captura de Datos que no hemos comentado. Si está considerando construir su propia Honeynet, le recomendamos que visite la Página de Herramientas en busca de tecnologías para su Honeynet.

Cuidados, introducción de datos y riesgos
Las Honeynets no son soluciones para "enchufar y olvidar". son un complejo tipo de honeypot que requiere mantenimiento constante, administración y vigilancia. Para la máxima efectividad, necesita detectar y reaccionar a los incidentes tan pronto como sea posible. Observando las actividades de los blackhat en tiempo real, puede maximizar las capacidades de captura de datos y análisis. Además, para detectar los desconocidos, se requiere una revisión constante de las actividades sospechosas. Esto requiere mucho tiempo y capacidad de análisis. Por ejemplo, en sólo 30 minutos un blackhat puede hacer el suficiente daño a un honeypot comprometido que requiera 30-40 horas para entender completamente qué ha ocurrido. El mantenimiento constante es requerido para mantener la operabilidad de la Honeynet. Si algo va mal (y siempre hay algo) esto puede causar un fallo dentro de la honeynet. Sus procesos de alerta terminarán, los discos pueden llenarse, las firmas IDS pueden caducar, los ficheros de configuración corromperse, los registros del sistema necesitarán ser revisados, los cortafuegos necesitarán ser actualizados y parcheados. Esto representa algunos de los cuidados constantes e introducción de datos que se requiere para un correcto funcionamiento de la Honeynet. Su trabajo no hace más que empezar cuando construye una Honeynet.

Además, hay riesgos implícitos en la construcción e implementación de una Honeynet. Tenemos blackhats atacando y comprometiendo nuestros sistemas. Estableciendo una red para ser comprometida, nos exponemos nosotros mismos, y a otros a un cierto riesgo. Usted asume la responsabilidad de asegurarse de que la Honeynet, una vez comprometida, no puede ser usada para atacar o dañar otros sistemas. No obstante, con un entorno como este, siempre hay un riesgo potencial de que algo vaya mal. Hemos implementado diversas medidas para reducir este riesgo. Sin embargo, es posible que un blackhat desarrolle un método o herramienta que le permita saltarse nuestros métodos de control de acceso. Además, se necesita actualizar y comprobar constantemente el entorno para asegurarnos de que las medidas de control funcionan correctamente. Nunca subestime el poder creativo de la comunidad blackhat. El uso de un cortafuegos, routers y otras técnicas ayudan a reducir el riesgo del uso de la Honeynet para dañar otros sistemas. Aún así, todavía hay riesgos.

Por último, las honeynets no solucionarán sus problemas de seguridad. Recomendamos encarecidamente que las organizaciones se centren primero en mejores prácticas como la autenticación fuerte, uso de protocolos cifrados, revisión de registros del sistema, y versiones seguras del sistema. Mediante la prioridad en políticas y procedimientos adecuados, las organizaciones pueden reducir considerablemente los riesgos. Las Honeynets no reducen los riesgos, es más probable que los aumenten. Si su organización está interesada en las capacidades de detección o engaño de los honeypots, le recomendamos la lectura de honeypot whitepaper y de los productos tratados al principio de este artículo. Las Honeynets son un honeypot diseñado principalmente para la investigación, para recoger información del enemigo. No solucionarán los problemas de su servidor poco seguro, no solucionará malos procesos o procedimientos.

Cuestiones legales
Va más allá del alcance de este texto el tratar las cuestiones legales de las tecnologías Honeynet. Deberá referirse a sus propios asesores jurídicos antes de construirla. El Honeynet Project está trabajando con miembros del Departamento de Justicia (US) para ayudar a identificar y documentar estas cuestiones. Una vez documentadas, publicaremos un texto de Conoce a tu Enemigo sobre estas cuestiones. El libro Tracking Hackers tiene un capítulo entero dedicado a cuestiones legales sobre honeypots, muchas de las cuales de aplican a las Honeynets.

Conclusión
Las Honeynets son un tipo de honeypot diseñadas para recoger información, específicamente las herramientas, tácticas y motivos de la comunidad blackhat. Esta información es usada para proteger a las organizaciones contra diversas amenazas. Por ahora hay dos enfoques para el desarrollo de Honeynets, GenI y GenII. Ambos enfoques cumplen las Definiciones, Requisitos y Normas. Las Honeynets requieren una gran sobrecarga administrativa. El administrador de la honeynet tiene la responsabilidad de que ningún otro sistema vaya a ser atacado desde la Honeynet comprometida. Sin una administración apropiada, los riesgos pueden ser mayores que la recompensa. Esta herramienta no es la panacea de la seguridad, y no debe ser una solución para ninguna organización. El Honeynet Project recomienda encarecidamente que las organizaciones se centren primero en asegurar su organización, parcheando los sistemas o deshabilitando servicios. Una vez aseguradas, las organizaciones pueden entonces ser capaces de usar Honeynets como una poderosa herramienta para tomar la iniciativa y aprender más sobre el enemigo y ellos mismos. A pesar de ello, se recomienda a las organizaciones que consulten a sus asesores jurídicos sobre las cuestiones legales que pueden existir, antes de construir una Honeynet. A individuos u organizaciones interesados en aprender más sobre las tecnologías Honeynet, se les recomienda la lectura del libro Conoce a tu Enemigo, escrito por el Honeynet Project.


The Honeynet Project