La Honeynet (red trampa) GenII (2a generación) es el siguiente paso en la evolución de las tecnologías honeynet. Basada en la combinación de viejas y nuevas técnicas, la Honeynet GenII puede mejorar la flexibilidad, gestión, y seguridad de los desplieges de las honeynets. Este documento introduce la tecnología y puede ser utilizado como una guía paso a paso para construir una honeynet GenII. No obstante, antes de seguir, se asume que ya has leído y comprendes perfectamente los conceptos, riesgos y asuntos sobre honeynets descritos en Conoce a tu enemigo: Honeynets. Es crítico que comprendas los fundamentos de las honeynets antes de explicar los detalles técnicos.

Este artículo hace un repaso general de los componentes de una Honeynet GenII. La primera sección introduce el concepto de un Honeywall, el mecanismo de administración centrado en nuestra capacidad de gestión de la red. En la sección de Control de datos discutiremos el proceso de limitar las acciones que los hackers llevarán a cabo en nuestra red. La tercera sección, Captura de datos, detalla los métodos para capturar la actividad de los atacantes a nivel de máquina (host) y de red. La sección sobre Alarmas automatizadas cubre métodos para notificar a los administradores sobre ataques con éxito. Por último, la sección de Pruebas presenta varias formas de comprobar la configuración de los pasos anteriores. El desarrollo descrito está basado en un Honeywall sobre un kernel Linux 2.4 en un hardware x86 estándar. No es necesario utilizar las herramientas o métodos discutids aquí, puedes utilizar con libertad aquellas tecnologías con las que te encuentres más cómodo, siempre que proporcionen las mismas funcionalidades.

La arquitectura
Una Honeynet no es un producto, no se instala simplemente un software desde un CDROM para ponerse luego en funcionamiento. Como hemos comentado en Conoce a tu enemigo: Honeynets, una Honeynet es una arquitectura, una red altamente controlada para contener y analizar atacantes en vivo. Cómo implementar esa arquitectura depende de ti. Hemos escrito el documento titulado Honeynet: Definiciones, Requisitos y Estándares, que detalla los requisitos para instalaciones de Honeynets. Ese artículo describe un método específico para cumplir esos requisitos.

El elemento clave de cualquier Honeynet es el gateway (puerta de enlace), que separa los sistemas Honeynet del resto del mundo. El gateway actúa como un muro, de hecho, podemos denominar al gateway como un Honeywall. Todo el tráfico entrante o saliente de la Honeynet debe pasar a través de este Honeywall. Este elemento es el centro de control de la Honeynet; toda la magia ocurre aquí. Puedes ver un ejemplo de nuestra propuesta de arquitectura Honeynet en la figura A. En este ejemplo, nuestro gateway es un bridge (puente) de nivel dos. Puede utilizarse un router de nivel tres, pero es preferible utilizar un puente, ya que es más difícil de detectar. En nuestro diagrama, la Honeynet ha sido instalada en una red interna 192.168.1.0/24. En el pasado, la mayoría de las Honeynets se instalaban tradicionalmente en redes externas o perimetrales. Con el uso de un gateway de nivel dos, las Honeynets pueden integrarse en redes internas, como la nuestra. Esto nos permite registrar y aprender no sólo de las amenazas externas, sino también de las internas.

El Honeywall (el gateway puente) separa los sistemas de producción de la red Honeynet, alimentada por nuestros objetivos víctimas. La interfaz externa de nuestro gateway (eth0) está conectada a la red de sistemas de producción. El interfaz interno de nuestro gateway (eth1) está conectado a la red de sistemas Honeynet. Como es un puente, tanto el interfaz externo como el interno están en la misma red IP. También tenemos una tercera interfaz (eth2). El propósito de esta interfaz es para realizar tareas de administración remota del gateway, incluyendo el traslado de registros o datos capturados a algún punto centralizado. Las interfaces interna y externa están en modo puente, de forma que no tienen dirección IP asignada a las mismas. Sin embargo, la tercera interfaz (eth2) tiene una pila IP asignada; en este ejemplo la dirección IP 10.1.1.1. Esta es una red separada y segura, para labores de administración. Las ventajas de esta arquitectura consisten en que el gateway es difícil de detectar, ya que no hay saltos de enrutamiento, no hay decrementos TTL (tiempo de vida), ni direcciones MAC asociadas al gateway. Además, simplificamos el desarrollo de la Honeynet combinando el Control de datos y la Captura de datos en un sólo gateway. El siguiente paso consiste en construir un gateway que soporte esta arquitectura. Para nuestro gateway estamos utilizando una instalación minimizada y segura de Linux. Es crítico que este sea un sistema de confianza, al que ningún atacante pueda acceder. A continuación, tenemos que asegurarnos de que nuestro gateway soporta funciones de puente (bridging). La mayoría de distribuciones Linux soportan funciones de puente por defecto. Si tu sistema no, puedes obtener rpm de bridging o el código fuente desde http://bridge.sf.net.

gateway #rpm -q bridge-utils
bridge-utils-0.9.3-4

Por desgracia, aunque muchas distribuciones soportan bridging, la mayoría no soportan IPTables en modo puente. IPTables es crítico, no sólo ayudan asegurando nuestro gateway, sino que pueden ser utilizados para el Control de datos (discutido más adelante). Para poder utilizar IPTables mientras se está en modo puente, probablemente tendrás que parchear y recompilar el kernel para que lo soporte [1]. Puedes bajar el último parche para el kernel aquí. De nuevo, el parche para el kernel se puede obtener en http://bridge.sf.net. Una vez comprobado que el bridging está instalado, y que el kernel está parcheado para soportar IPTables en modo puente, se puede empezar la configuración del gateway. Esto es realmente más sencillo de lo que parece. El Proyecto Honeynet ha desarrollado lo que denomina rc.firewall script. Este script (guión) implementa casi todos los elementos críticos de tu gateway. Iremos haciendo referencias a este guión a lo largo del artículo. Para nuestro gateway, el guión implementará las funciones de bridging, cortafuegos, configurará una interfaz de gestión, controlará quién podrá administrar el gateway, cómo y desde dónde, el registro de la actividad de red, e implementa el Control de datos. Como puedes ver, este script es importante, ya que configura tu gateway para que cumpla la mayoría de requisitos de la Honeynet. Para utilizar este script (y configurar tu Honeywall) tan sólo tienes que configurar las variables del mismo, y luego ejecutarlo (es muy importante que no ejecutes el script hasta que hayas terminado de leer el artículo entero). En vez de describir cada variable en detalle y cómo funciona (el script lo hace por ti) enlazado aquí hay un guión completo utilizado por la arquitectura que hemos descrito arriba.

Control de datos
Como hemos comentado en el artículo Conoce a tu enemigo: Honeynets, el propósito del Control de datos es el de evitar que los atacantes no utilicen la Honeynet para atacar o dañar otros sistemas que no pertenezcan a la Honeynet. Con el Control de datos, una de las preguntas que debes hacer es ¿cuánta actividad saliente controlas? Cuanto más permitas hacer al atacante, más podrás aprender. Sin embargo, cuantas más cosas permitas hacer al atacante, más daño podrá potencialmente hacer. De modo que tienes que contener sus acciones lo suficiente como para evitar que perjudiquen a otros colegas, pero no puedes contenerlas demasiado o aprenderás poco. Cuánto permitas hacer al atacante depende en última instancia de los riesgos que estés dispuesto a asumir. Para complicar más las cosas, tenemos que limitar las acciones de los atacantes sin que se percaten de ello. Para lograr esto, implementaremos dos tecnologías, conteo de conexiones y NIPS. El conteo de conexiones permite limitar el número de conexiones salientes que un honeypot (sistema trampa) puede iniciar. El NIPS (Sistema de Prevención de Intrusiones de Red) puede bloquear (o deshabilitar) ataques conocidos. Combinadas, estas dos tecnologías constituyen un potente y flexible mecanismo de control de datos. Implementaremos ambas tecnologías en nuestro gateway de nivel dos. Realizaremos el Control de datos aquí porque es por donde pasa todo el tráfico entrante y saliente; es el punto donde se concentra la actividad de los atacantes.

Una vez que hayas configurado tu gateway según la primera parte, el siguiente paso consiste en implementar la limitación de conexiones. Podemos controlar el número de conexiones que un atacante puede iniciar desde un honeypot. El propósito aquí consiste en contar las conexiones salientes y, cuando se ha alcanzado un límite concreto, bloquear cualquier conexión adicional. Esto se hace principalmente para deducir el riesgo de escaneos masivos, o ataques de denegación de servicio (DoS); actividades que requieren gran número de conexiones salientes. Para esto utilizamos IPTables, configurado e implementado por el script rc.firewall nombrado antes. En el script, especificamos cuántas veces puede un atacante iniciar una conexión saliente TCP, UDP, ICMP, u OTHER. El número de conexiones permitidas depende del riesgo que estás dispuesto a asumir. Limitar el número de conexiones salientes evita que los atacantes utilicen la Honeynet para escanear gran número de sistemas, o lanzar ataques de DoS. Es difícil de hacer mucho daño cuando te limitan el número de conexiones salientes que puedes iniciar. No obstante, ten en cuenta que esto también puede convertirse en una seña de identidad. Un atacante puede ser capaz de detectar tu Honeynet simplemente iniciando conexiones salientes, y observando si son bloqueadas despúes de cierto número. Los límites de conexiones por defecto del script rc.firewall son como sigue. Nótese que la variable OTHER significa cualquier protocolo IP que NO SEA TCP, UDP, o ICMP (como IPsec, túneles IPv6, Protocolo de Voz de Red, etc.).

### Set the connection outbound limits for different protocols.
SCALE="day"
TCPRATE="15"
UDPRATE="20"
ICMPRATE="50"
OTHERRATE="15"

Así es como IPTables implementa el límite de conexiones. Cuando un atacante entra en un honeypot puede iniciar conexiones salientes por varias razones (descargar toolkits, configurar bots automáticos, abrir sesiones IRC, enviar correos electrónicos, etc.). Cada vez que se inicia una de estas conexiones salientes, es contada por el firewall. Cuando se alcanza el límite, IPTables bloquea cualquier conexión posterior desde ese honeypot. Entonces, IPTables se reinicia a sí mismo, permitiendo tantas conexiones salientes por intervalo de tiempo permitidas. Por ejemplo, digamos que podemos definir un límite de 25 conexiones TCP salientes por día. Cuando el atacante entre en nuestro honeypot, se le permitirán 24 conexiones TCP salientes. Cuando alcance el límite de 25 conexiones TCP, no podrá iniciar ninguna más. Entonces IPTables se reinicia a sí mismo permitiendo 25 conexiones más una vez cumplido el tiempo definido, en nuestro caso 24 horas. Si hemos definido un período de una hora, entonces una vez se cumple el límite, se volverán a permitir otras 25 conexiones durante la siguiente hora, o una cada 2,4 minutos. Para ver un ejemplo real de este comportamiento, véase estos registros de IPTables de un honeypot Win2000 infectado con el gusano Code Red II, y sus intentos de escaneo externos. Una característica importante de IPTables, cuando se alcanza el límite TCP, es que no afecta en absoluto al tráfico UDP, ICMP u OTRO tráfico, hasta que sus límites también se alcanzan.

Una vez implementada la limitación de conexiones con el script rc.firewall, el siguiente paso consiste en implementar la funcionalidad NIPS. Recuerda, el objetivo de nuestro NIPS es el de identificar y bloquear ataques conocidos. Esto lo hace investigando cada paquete que viaja a través de nuestro gateway. Si algún paquete concuerda con alguna de las reglas del IDS, no sólo se genera una alarma (como un NIDS tradicional), sino que el paquete puede ser eliminado (bloqueando el ataque) o modificado (deshabilitando el ataque). La ventaja es que reducimos dramáticamente el riesgo de que un ataque saliente tenga éxito. La desventaja es que esto sólo funciona con ataques conocidos. En el caso del valor límite, estamos permitiendo por defecto unas 15 conexiones TCP salientes por día ¿Qué ocurre si nuestra Honeynet es infectada con un gusano, y esas 15 primeras conexiones son intentos de infectar a otros sistemas? Aunque el valor límite ha reducido el número de sistemas que puede infectar, sigues teniendo ese riesgo. La idea de un NIPS es la de que puede bloquear o deshabilitar cualquier ataque identificado en esas primeras 15 conexiones. Para ello, el Proyecto Honeynet utiliza snort_inline, una versión modificada de Snort que puede descartar o modificar paquetes.

Para que snort_inline pueda trabajar como un NIPS (en modo gateway) debe tener algo que le encamine los paquetes, ya que snort_inline no sabe hacer de router (ip_forward). Así que debemos tener algo que encamine los paquetes hacia el snort_inline, para que los pueda analizar. Una vez que el snort_inline ha terminado con el paquete, lo devuelve al proceso de encaminamiento. Este proceso es IPTables. Configuramos IPTables para tomar los paquetes que redirige, enviarlos al espacio de usuario de snort_inline para su análisis, y luego IPTables continúa su encaminamiento. Esta característica de IPTables se denomina user-space queuing (cola de espacio de usuario), ya que necesita que el módulo ip_queue esté cargado en el kernel. Para activar esta característica, tan sólo debemos activar QUEUE en nuestro script rc.firewall (que también activará el módulo ip_queue del kernel). Una cosa a tener en cuenta cuando se combina snort_inline y las capacidades de conteo de IPTables, es que IPTables contará las conexiones salientes sin importar si snort_inline permite pasar el paquete o lo bloquea. Esto ocurre porque todos los paquetes pasan a través de la interfaz interna antes de ser analizados por snort_inline. La conexión ha sido contada antes de que snort_inline pueda verla.

Si activas las capacidades de snort_inline, entonces DEBES tener funcionando snort_inline. Si no tienes snort_inline funcionando, o por alguna razón snort_inline muere, ningún paquete será encaminado a través de IPTables (esto es una medida de seguridad, no un bug :). Por esta razón, nuestro siguiente paso consiste en configurar el snort_inline. Es muy similar al Snort, salvo que utiliza una rulebase (conjunto por defecto de reglas) diferente. Ten en cuenta que nuestro objetivo no es descartar todo el tráfico saliente, sino sólo los ataques. De modo que queremos un conjunto de reglas que sólo contengan ataques reales o exploits. No queremos bloquear peticiones salientes de información, como ICMP echoes, peticiones de finger, o un simple comando HTTP GET. Si utilizásemos TODAS las reglas de Snort, el atacante no sería capaz de hacer nada hacia el exterior. Por eso sólo utilizamos las reglas de Snort que definen ataques reales. Cada organización puede tener una definición distinta de lo que es un ataque, por lo que recomendamos que revises y modifiques las reglas de snort_inline antes de utilizarlas. Además, nuestro conjunto de reglas tiene que ser invertido con respecto a las reglas de Snort, ya que estas se centran en ataques internos. Con snort_inline, nos concentrarnos en los ataques salientes. El objetivo consiste en proteger el mundo exterior de la Honeynet. Por último, las reglas son diferentes, ya que no avisamos sobre las actividades, sino que en realidad descartamos o modificamos ataques. El objetivo de un conjunto de las reglas drop (descartar) es el de analizar paquetes, y en caso de reconocer un ataque saliente, bloquear o descartar el paquete que contiene el ataque. Puedes observar un ejemplo específico de esto en el descarte del ataque del Code Red II mencionado antes. El conjunto de reglas replace (reemplazar) no bloquean ataques. En vez de ello, modifican el contenido del ataque real, inhabilitando el exploit. Este método es potencialmente más difícil de ser detectado por el atacante. Los atacantes podrán ver cómo sus ataques alcanzan sus objetivos, pero no sabrán por qué sus ataques están fallando. La herramienta snortconfig es un script flexible que convierte las reglas estándar de Snort en reglas con capacidades de snort_inline, como drop, sdrop, o replace. Esta herramienta es muy importante para mantener actualizadas las reglas de snort_inline.

Para el propósito de nuestro desarrollo, instalaremos las reglas drop y nuestro fichero de configuración snort_inline.conf en /etc/snort_inline. Utilizamos un directorio separado de /etc/snort para no confundirnos. Para arrancar snort_inline, utilizamos el script de inicio snort_inline. Este script está preconfigurado con todas las variables necesarias para mantener snort_inline funcionando adecuadamente. Para hacerte la vida más sencilla, todos los ficheros de configuración de snort_inline, reglas, scripts de inicio, e incluso un binario precompilado, están incluidos en el Honeynet snort_inline Toolkit. Utilizar este Toolkit debería hacer la implementación de tu snort_inline más sencilla. No olvides que la combinación de estas tecnologías puede reducir los riesgos, pero no lo eliminan por completo. Siempre que tengas atacantes invitados en tu casa, las cosas pueden ir mal.

Captura de datos
Una vez que hemos implementado el Control de datos, podemos pasar a la Captura de datos. El propósito de las Captura de datos es registrar toda la actividad de los atacantes. Este es el mayor objetivo de la Honeynet, recoger información. Sin la Captura de datos, nuestra Honeynet no tiene valor. La clave de la Captura de datos es la recopilación de información a tantos niveles como sea posible. Ningún nivel de forma aislada nos lo dice todo. Por ejemplo, mucha gente cree que todo lo que necesitas son las pulsaciones de teclado de los atacantes, sin embargo esto no es cierto ¿Qué pasa cuando el atacante lanza una herramienta, cómo sabrás qué hace la herramienta si no capturas la actividad de la misma, o el tráfico de red? El Proyecto Honeynet ha identificado tres capas o niveles críticos de la Captura de datos: registros del cortafuegos, tráfico de red, y actividad de sistema. Describiremos cómo implementar cada una de ellos.

Los registros del cortafuegos son muy sencillos. Ya hemos hecho esa parte. Mediante la implementación del script rc.firewall ya estamos registrando todas las conexiones entrantes y salientes a /var/log/messages. Esta información es crítica, ya que es nuestra primera indicación de lo que está haciendo un atacante. También es nuestra primera alarma que nos dice cuándo se han iniciado los ataques salientes. Según la experiencia del Proyecto, los registros de cortafuegos han demostrado ser críticos a la hora de identificar nuevos o no conocidos comportamientos. El script identificaba cuatro diferentes tipos de tráfico: TCP, UDP, ICMP, y OTRO. Al igual que el Control de datos, OTRO representa cualquier protocolo no-IP de tipo de tráfico 1, 6, o 17. También tiende a ser el más interesante. Cuando alguien está utilizando tráfico IP no estándar, normalmente suele significar que está intentando un nuevo ataque o un método no publicado antes (como en el canal de puerta trasera (backdoor channel) visto en el Scan of the Month 22).

El segundo elemento consiste en capturar cada paquete y con su contenido completo (payload) que entra o sale de la Honeynet. Mientras el proceso snort_inline podría hacer esto, no queremos poner todos nuestros huevos en una sola cesta. En vez de ello, configuramos y ejecutamos un segundo proceso para capturar toda esta actividad. Hacemos esto utilizando el fichero de configuración estándar snort.conf. Este fichero de configuración captura todo el tráfico IP a un fichero de registro tcpdump para su futuro análisis. También queremos rotar los registros que captura cada día, cosa que haremos con el script de inicio snort.sh. Este script de inicio se ejecuta con el cron cada día. Nótese cómo en el script de inicio asociamos el sniffer al interfaz interno, eth1. Esto es crítico.  Si por equivocación asocias el sniffer al interfaz externo (eth0) no sólo registrarás los datos de la Honeynet, sino también los de toda la red externa. Esto puede contaminar los datos que capturas. Mediante la monitorización del interfaz interno, sólo capturarás el tráfico entrante y saliente de la Honeynet, que es exactamente lo que quieres. Otra ventaja del script de inicio es que estandariza dónde se registra la actividad capturada, cosa de vital importancia si tienes múltiples Honeynets registrando a una localización central (comentada más adelante en este artículo).

El tercer elemento es el que más desafíos supone; capturar toda la actividad del atacante ocurrida en el propio honeypot. Hace años esto era sencillo, ya que la la mayoría de la interacción remota con sistemas se hacía sobre protocolos de texto en claro, como FTP, HTTP, o Telnet. Tan sólo había que monitorizar las conexiones para capturar las pulsaciones de teclado. No obstante, los atacantes, como tú, han adoptado el cifrado. Hoy en día suelen utilizar canales SSH o 3DES para comunicarse con las máquinas comprometidas. Ya no podemos capturar las pulsaciones de teclado monitorizando el segmento de red, en vez de ello tenemos que obtenerlas directamente del sistema. Una ventaja de este sistema es que la mayoría de lo que se cifra se descifra en el sistema de destino, en nuestro caso el honeypot. Si podemos capturar los datos descrifrados en el honeypot, podemos evitar las comunicaciones cifradas. Sebek es una herramienta diseñada para hacer eso. Sebek es un módulo (o parche) oculto del kernel capaz de registrar las pulsaciones de teclado de los atacantes. Una vez instalado en un honeypot, el cliente Sebek se ejecuta en el kernel. La información recogida por Sebek no se almacena en el honeypot, donde podría ser descubierta por el atacante. En vez de ello, Sebek transmite sus datos mediante UDP a una máquina de monitorización (como el Honeywall gateway local, o un sistema de registro remoto en otra red). Los atacantes no pueden ver o rastrear estos paquetes, ya que el cliente de Sebek en los honeypots lo esconden. Incluso si los atacantes descargan o utilizan sus propias herramientas de rastreo, la actividad de Sebek estará oculta para ellos. Esto se consigue modificando el honeypot de forma que no pueda ver o monitorizar ningún paquete que tenga un número mágico preasignado y un puerto UDP. Entonces, Sebek simplemente descarga la información del atacante recogida de la red, capturada por el gateway. Como todos los honeypots están controlados por Sebek, ninguno de ellos puede ser utilizado para monitorizar otras pulsaciones de teclado puestas en la red. Ten en cuenta que si tienes un honeypot que no tiene Sebek instalado (o mal configurado), y un atacante toma el control del sistema, entonces puede monitorizar los paquetes de Sebek que pertenezcan a otros sistemas, ya que los paquetes no están escondidos.

Como Sebek se ejecuta en el kernel, debe ser compilado para el SO específico y la versión del kernel de tu honeypot. Aunque cada versión de cliente es diferente para cada sistema operativo, todos vienen con el mismo fichero de configuración, como el ejemplo de abajo. Instalar Sebek2 es muy sencillo, ya que sólo tienes cinco opciones en el script de instalación. Instalamos el nuestro como se puede ver abajo. El objetivo del fichero de configuración es determinar qué información se recogerá, y qué información se envía a la red. Por defecto, Sebek captura toda la actividad del sistema, sin embargo puedes escoger capturar sólo la actividad de teclado. La combinación del número mágico (específico de Sebek) y el puerto UDP de destino determinan qué paquetes estarán ocultos. Todos los honeypots del mismo grupo deben compartir la misma combinación para funcionar correctamente.

#----- INTERFACE:
INTERFACE="eth0"

#----- DESTINATION_IP:
DESTINATION_IP="10.0.0.1"

#----- DESTINATION_MAC:
DESTINATION_MAC="FF:FF:FF:FF:FF:FF"

#----- SOURCE_PORT:
SOURCE_PORT=1101

#----- DESTINATION_PORT:
DESTINATION_PORT=0

#----- MAGIC_VAL
MAGIC_VAL=0

#----- KEYSTROKE_ONLY:
KEYSTROKE_ONLY=0

#----- TESTING:
TESTING=0

Una vez configurado, Sebek envía toda la actividad de sistema a la red. Estos paquetes son entonces utilizados para reconstruir la actividad del atacante, y el impacto que ha tenido en el sistema. Para aprender más sobre Sebek, acuda al artículo Conoce a tu enemigo: Sebek.

Alarmas
Hay un último elemento que puedes querer considerar antes de finalizar tu Honeynet; las alarmas. Que alguien entre en tu Honeynet puede ser una gran experiencia de aprendizaje, a menos que no sepas que alguien ha entrado en la misma. Asegurarte de que serás notificado de un ataque (y responder al mismo) es crítico para una buena Honeynet. Lo ideal sería contar con una monitorización periódica a cargo de administrador experimentado. No obstante, para las organizaciones que no cuentan con personal 24/7, una alternativa es la de las alertas automáticas. Una opción para la monitorización automática es Swatch, the Simple Watcher. Swatch es una herramienta de monitorización automática muy completa capaz de avisar a los administradores de posibles ataques con éxito en la Honeynet. Swatch monitoriza ficheros de registro en busca de patrones indicados en un fichero de configuración. Cuando encuentra un patrón puede de forma nativa enviar alarmas mediante correo electrónico, system bells, llamadas de teléfono, y puede ser ampliado para ejecutar otros comandos/programas. Una regla sencilla de Swatch contiene el patrón que debe encontrar seguido de una lista de acciones a tomar. El siguiente ejemplo de configuración está basado en Swatch 3.0.

watchfor /Firewall:  OUTBOUND CONNECTION/
     echo normal
     mail=admin@honeynet.org,subject=------ ALERT! OUTBOUND CONN --------
     throttle 10:0:0

La acción "mail=" contiene una lista de direcciones de correo electrónico a las que enviar la alarma mientras que el comando throotle limita el número de veces por Hora:Minuto:Segundo que se pueden tomar las acciones por cada regla. Esto es bastante útil para prevenir el atasco del correo cuando se ejecutan las reglas. La configuración de arriba monitoriza el fichero de registro /var/log/messages, donde IPTables registra las conexiones entrantes y salientes. Nuestro fichero de configuración busca cualquier conexión saliente, una buena señal de que nuestra Honeynet ha sido comprometida. Cuando la firma o patrón coincide, se envía un correo electrónico al administrador del honeypot. En esta configuración, los correos de aviso son enviados a razón de no más de 10 por hora. Los patrones buscados y las acciones tomadas variarán según la implementación de cada honeynet. Más importantes que los aspectos prácticos del fichero de configuración de Swatch son la comprensión de los eventos recogidos en una Honeynet que un administrador debería vigilar y la información que se debería incluir en cada alarma. El objetivo de las alertas automáticas es el de proporcionar a los administradores tanta información como sea posible para responder ante un ataque con éxito. Cualquier alerta enviada por Swatch debería contener al menos: la dirección IP origen y destino del paquete recogido, la fecha/hora en la que el evento tuvo lugar, y suficiente información para que el administrador pueda tomar las acciones pertinentes. Por defecto, Swatch incluye la línea en el fichero que registro que coincide con la regla utilizada. Un ejemplo del email para la regla de arriba tendría el siguiente aspecto:

To:  admin@honeynet.org
From:  yourdatacontrol@yourdomain.org                                                                                               
Subject:  ------ ALERT!: OUTBOUND CONN --------                                                                                          
                                                                                                                                    
Apr  6 17:19:05 honeywall FIREWALL:OUTBOUND CONN UDP:IN=br0                                                                        
PHYSIN=eth1 OUT=br0 PHYSOUT=eth2 SRC=192.168.1.101
DST=63.107.222.112 LEN=123 TOS=0x00 PREC=0x00 TTL=255 ID=43147
PROTO=UDP SPT=5353 DPT=79 LEN=103  

Incluso con las herramientas automáticas descritas en la sección de Control de datos, una Honeynet requiere supervisión constante. Si se configura adecuadamente, Swatch puede ser utilizado para notificar rápidamente a los administradores de los eventos de su red. No obstante, no dependas sólo de las conexiones salientes como única fuente de datos de alerta. Por ejemplo, un atacante puede haber comprometido el sistema y no intentar iniciar una conexión saliente. Asegúrate de monitorizar otras fuentes de información, como las pulsaciones de teclado recogidas por los clientes Sebek.

Pruebas
Una vez que tenemos configurado el Control de datos y la Captura de datos, el siguiente paso será probar el gateway. Para probarlo, necesitaremos un sistema en la interfaz externa al que llamaremos sistema de pruebas. Basado en la figura A, utilizaremos el sistema 192.168.1.20 como nuestro sistema de pruebas. Empezamos probando primero del Control de datos ¿Controla correctamente nuestra Honeynet la actividad entrante y saliente? Primero iniciamos una conexión desde el sistema de pruebas a uno de los honeypots dentro de la Honeynet. Según nuestro conjunto de reglas, esta conexión debería ser permitida. Si es así, deberías tener una entrada similar a esta en /var/log/messages:

Mar 23 20:55:09 honeywall kernel: INBOUND TCP: IN=br0 PHYSIN=eth0 OUT=br0 PHYSOUT=eth1 SRC=192.168.1.20 DST=192.168.1.101 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=48699 DF PROTO=TCP SPT=36797 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0

Una vez que hayas confirmado que la actividad entrante funciona, el siguiente paso es comprobar la saliente. Empezamos accediendo a alguno de los honeypots de detrás del gateway (te recomendamos que accedas a los honeypots desde la consola, ya que el honeypot registrará localmente todas las conexiones remotas, como SSH). Ahora iniciamos múltiples conexiones salientes contra el sistema de pruebas. Esto simulará que uno de los honeypots habrá sido comprometido, y un atacante está intentando iniciar conexiones salientes, y potencialmente un ataque. Las conexiones deberían ser registradas en /var/log/messages del Honeywall. En nuestro caso, podemos intentar múltiples conexiones FTP salientes contra el sistema de pruebas en la red de producción. Cuando se llega a nuestro límite de 15 conexiones TCP, se registrará una entrada "Drop TCP". Deberías tener entradas similares a esta:

Mar 23 17:45:36 laptop kernel: OUTBOUND CONN TCP: IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=192.168.1.101 DST=192.168.1.20 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=36399 DF PROTO=TCP SPT=1026 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Mar 23 21:14:07 laptop kernel: Drop TCP after 15 attempts IN=br0 PHYSIN=eth1 OUT=br0 PHYSOUT=eth0 SRC=192.168.1.101 DST=192.168.1.20 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63391 DF PROTO=TCP SPT=1030 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0

Luego tenemos que confirmar que nuestra tecnología NIPS, snort_inline, está funcionando. Afortunadamente, el toolkit de snort_inline vienen con reglas de prueba, diseñadas específicamente para pruebas. Asegúrate de activar esas reglas antes de probar snort_inline. El conjunto de reglas que estás ejecutando también determinará qué prueba utilizar. Si estás utilizando el las reglas drop, puedes hacer pruebas simplemente al activar la regla de pruebas por defecto, reiniciar snort_inline mediante el script de inicio snort_inline.sh, y luego intentar una conexión saliente de Telnet. snort_inline debería detectar, descartar, y registrar el intento. Tu intento de Telnet no debería funcionar, debería superar el tiempo límite. Si estas ejecutando las reglas replace, puedes probarlo al activar la regla de pruebas por defecto, reiniciar snort_inline, y luego intentar un comando HTTP GET. snort_inline debería detectar, modificar, y registrar el intento. Para confirmar que ha ocurrido la modificación, asegúrate de monitorizar la interfaz EXTERNA eth0. NO monitorices la interfaz interna eth1, ya que el comando GET no es modificado hasta que pasa a través de la interfaz interna, pero antes de salir por la interfaz externa. Asegúrate de que una vez que has terminado de hacer pruebas, has desactivado las reglas (o los chicos malos también podrán ejecutar esas pruebas por defecto).

03/23-21:21:05.915340 [**] [1:0:0] Dropping Telnet connection [**] [Priority: 0] {TCP} 192.168.1.101:39528 -> 192.168.1.20:23
03/23-21:21:24.054533 [**] [1:0:0] Modifying HTTP GET command [**] [Priority: 0] {TCP} 192.168.1.101:38533 -> 192.168.1.20:80

Una vez que hemos confirmado el Control de datos tenemos que asegurarnos de que la Captura de datos funciona. Recuerda, si nuestra Honeynet no está registrando toda la actividad, no tiene ningún valor. Confirmamos la Captura de datos mirando los registros ¿La Honeynet ha capturado las pruebas que hemos hecho? Empezamos con los registros del cortafuegos. Esta prueba es sencilla; todas nuestras conexiones deberían ser registradas en  /var/log/messages. Concretamente, deberíamos ver un mensaje de alarma que indique que se ha alcanzado el límite saliente, y todas las conexiones siguientes deberán ser descartadas. Ya hemos hecho esta prueba cuando confirmamos el Control de datos.

Luego revisamos los registros de red. Queremos asegurarnos de que capturamos cada paquete y su contenido de cada conexión, tanto entrante como saliente. Según nuestro script de inicio, deberíamos encontrar estos registros en /var/log/snort/$DAY, donde la variable $DAY indica el día específico. Según la experiencia, hemos visto que lo mejor es rotar los registros diariamente. En este caso, encontramos los registros en /var/log/snort/Mar_23. El registro en que estamos interesados principalmente es el de la captura de registro binaria (binary log capture), denominado snort.log.*. Además, podrás encontrar varios directorios con nombres de direcciones IP. Estos directorios contienen cada paquete saliente que tenga contenido ASCII, como comandos FTP o una página .html. Puedes confirmar que Snort registró todos los paquetes analizando el fichero de registros binario como a continuación:

honeywall #snort -vdr snort.log.*

Por último, revisamos los registros de Sebek. Estas son las pulsaciones de teclado capturadas por el módulo de kernel Sebek, enviadas luego a la red. Estos paquetes deberían haber sido recogidos por el sniffer de red (Snort) y pueden ser recuperadas desde el mismo fichero de registro binario que acabamos de analizar. Ya está. Si has sido capaz de recoger los datos, ¡tu Captura de datos está funcionando correctamente! Comprueba también tu correo. Deberías haber sido avisado de las pruebas que has hecho. Swatch debería haberte enviado las alertas de las pruebas que acabas de realizar. Ahora, ya que eres un auténtico profesional de la seguridad, sabemos que vas a reiniciar tu Honeynet gateway, y comprobar el Control de datos y la Captura de datos una vez más, sólo para estar seguro. :)

Conclusiones
Hemos terminado paso a paso cómo construir e implementar una Honeynet GenII basada en un gateway en modo puente utilizando Linux. Esta implementación representa algunas de las más avanzadas características de la tecnologías Honeynet. Sin embargo, ten en cuenta que la seguridad de la información es parecida a la carrera armamentística, en el sentido de que mientras publicamos nuevas tecnologías para capturar la actividad de los atacantes, estos pueden desarrollar sus propias contramedidas. En el futuro, esperamos desarrollar y publicar GUIs (interfaces de usuario gráficas) para administrar Honeynets y analizar los datos que recogen. Esperamos también publicar un CDROM Honeywall de arranque que tenga todas las capacidades que hemos comentado.

1. Los kernels 2.6.X soportan funciones de brigding por defecto.