• Tweet

Uno de los grandes retos de las tecnologías de seguridad, incluyendo honeypots, es la configuración. Pero una vez que ha sido implantado, el trabajo no ha acabado, requiere del monitoreo y mantenimiento necesario para su correcto funcionamiento. Uno de los problemas en la implantación de honeypots, es el cómo se comportará nuestro honeypot, qué características deberá tener, si deberá ser un sistema Windows, Linux, Solaris etc. Una vez que el sistema operativo ha sido elegido, ¿qué servicios queremos que ejecute: correo, web, ftp o una base de datos en red- Si cometemos un error en la configuración de los servicios, podríamos perdernos de ataques, pruebas o escaneos de gran valor.

Además de la implantación de los honeypots, el mantenimiento y la actualización de éstos es un trabajo agotador. Si realizamos actualizaciones en nuestra infraestructura de red, como por ejemplo la instalación de un nuevo sistema operativo para el servidor de Web de un departamento en especial, nos gustaría mapear este equipo a nuestra infraestructura de honeypots, dicha actualización nos llevará tiempo.

Los honeypots dinámicos son el sueño de cualquier especialista en esta área, y es considerado el futuro de esta tecnología. Su objetivo es ser una solución que al momento de conectarla a la red, aprenda de ella, de sus características y su entorno, y conforme a esto, implante automáticamente el número de honeypots necesarios con las características que se asemejen a los equipos de la red de la cual aprendió. ¿Suena como un sueño- Pues no lo es, la tecnología existe, sólo tenemos que reunirla para formar una solución de este tipo.

Primero que nada, un honeypot dinámico tiene que estudiar y aprender del comportamiento de nuestra red: con qué sistemas y/o servicios contamos en la red y cómo son utilizados. Posteriormente de una u otra forma, el honeypot con la información recaudada debe ser capaz de emular dicho servicio o sistema de manera casi idéntica. Existen varias herramientas que en conjunto podrían lograr una infraestructura dinámica robusta, una de estas herramientas es Honeyd.

Honeyd y la emulación de servicios

Honeyd es una herramienta que nos permite implantar un honeypot de baja interacción en sistemas Unix. Desarrollado por Neils Provos de la Universidad de Michigan, Honeyd es una herramienta OpenSource que nos permite simular servicios e implementaciones de pilas TCP/IP de diversos sistemas operativos en uno solo. Para lograr esto, Honeyd utiliza como base de datos los patrones utilizados por herramientas como Nmap, p0f y Xprobe. El intruso no tiene un sistema operativo con el cual interactuar, sólo servicios emulados. Al ser una herramienta OpenSource puede ser personalizada de acuerdo a las necesidades que tengamos, por ejemplo diseñar un servicio a emular por honeyd. Sin embargo, honeyd no tiene la capacidad de monitorear, ya sea de manera activa o pasiva, la red en busca de cambios en los sistemas de una organización para mapear por completo ese comportamiento al honeypot. Una nueva herramienta que se encarga de ese trabajo se llama Honeybee.

Interpretación dinámica con Honeybee

Honeybee es un proyecto realizado en la Universidad RWTH (Rheinisch-Westfälische Technische Hochschule) en la ciudad de Aachen, Alemania que permite recolectar las características (fingerprintings) de ciertos servicios en nuestra red para que posteriormente se genere un emulador de dicho servicio que es compatible con Honeyd. La idea principal detrás de Honeybee es contar con un scanner para cada protocolo que interactúe con un equipo a emular para aprender de sus respuestas y sus reacciones a ciertos comandos y/o estímulos de red. Este comportamiento que llamaremos "la personalidad del servidor" es almacenada en una base de datos que es consultada por un emulador que intentará comportarse de manera similar al servidor original a partir de sus respuestas y reacciones almacenadas en la base de datos. Un ejemplo podría ser el banner de bienvenida que contiene el nombre y la versión del software que se está utilizando.

De igual manera que las pilas de red de los sistemas operativos, los servicios de red también cuentan con huellas (fingerprintings) que permiten diferenciarlos entre si. Sin embargo el número de reacciones y situaciones que necesitan ser probadas para obtener el comportamiento fiel del servicio son infinitas. Honeybee soluciona este problema mediante la ejecución de un numero finito de pruebas clasificadas en clases, esto sin perjudicar la calidad de información que tendrá el emulador en la base de datos para interactuar con los clientes. Por ejemplo, la mayoría de las respuestas de comandos que son erróneos para un servicio pertenecerán a una clase llamada "respuestas erróneas". Para el emulador será fácil saber cómo responder a un comando que encaje en esta clase, debido a que siempre que se ejecute un comando no reconocido por el servicio contestará con el mismo mensaje de error asignado a dicha clase.

Los datos que se almacenan en la base de datos consisten en dos campos. Una clave y una cadena de respuesta. La clave contiene tres porciones de información fundamentales: el comando utilizado contra el servicio, información sobre los parámetros utilizados e información sobre el estado del servidor en ese momento.

El emulador que utiliza Honeybee es capaz de emular cualidades que son utilizadas por las herramientas de fingerprinting populares como Nmap, Vmap, Amap, Smtpscan etc. Sin embargo el nivel de similitud necesario para engañar a este tipo de herramientas dependerá del tipo de pruebas que realizan, dichas pruebas pueden variar entre versiones de dichas herramientas. Por ejemplo, si la herramienta de fingerprinting detecta la versión de un servicio en base a expresiones regulares aplicadas a una cadena de texto, bastaría con armar una cadena con las características similares que busca la herramienta, sin embargo si el banner de bienvenida se muestra al usuario, este podrá hacer una validación mas precisa que incluya patrones léxicos, sintácticos e incluso semánticos, dependiendo del nivel de interacción del usuario con las respuestas remotas del servidor.

Otro de los problemas a los que se enfrenta Honeybee es el hecho del contenido dinámico en las respuestas de algunos servicios, este contenido bien puede ser la fecha, hora, el nombre del equipo, zona horaria etc. Sin embargo scanner de Honeybee es capaz de diferenciar el contenido dinámico del estático en la mayoría de las respuestas.

Tanto el scanner y el emulador propuesto por Honeybee son orientados a protocolo, esto quiere decir que las pruebas realizadas por el scanner dependerán del servicio que se intente emular, y es esta parte una de las desventajas de Honeybee debido a que la creación de pruebas y de rutinas de parseo de las respuestas para un protocolo personalizado, es una tarea desgastante. La mayoría de la información necesaria para probar el comportamiento de un cierto servicio podemos encontrarla en los RFC's de dicho servicio, sin embargo la diversidad de metodologías de programación implica que muchos desarrolladores no sigan al pie de la letra las recomendaciones hechas en los RFC's.

Conclusiones

Honeybee es una nueva herramienta que gracias a ser OpenSource irá madurando poco a poco, posiblemente hasta convertirse en una parte fundamental de honeyd, sin embargo existen diversas formas de hacer un reconocimiento de los servicios y sistemas localizados en una red determinada, por lo que Honeybee tendrá que luchar por sobresalir.

Una alternativa para el reconocimiento de los servicios y sistemas en nuestra red ser puede realizar mediante el tráfico de red capturado. No necesitamos que nuestro honeypot utilice una herramienta activa para determinar los equipos de nuestra red, debido a que generará trafico no deseado en nuestra red, para solucionar lo anterior, usamos el tráfico que capturamos por medio de un firewall y l Fuente: UNAM-CERT  DJD/