Despliegue de honeypots de forma ágil y económica con SmartHive

SmartHive se trata de un proyecto cuyo principal objetivo es simplificar la creación de redes de honeypots a bajo coste, mediante una plataforma que permite la gestión, explotación y despliegue ágil de honeypots en Internet.

Un proyecto que nació en el evento de seguridad CyberCamp 2015 gracias al Hackathon organizado por INCIBE y sobre todo al equipo de valientes que no dudaron en ningún momento en participar: Gonzalo de la Torre, Emilio J. Grande, Francisco J. Rodríguez y el que escribe estas líneas.

Hace ya aproximadamente más de un mes que os contamos una Crónica del Hackathon en CyberCamp 2015, sin embargo, apenas nos detuvimos en explicaros SmartHive puesto que íbamos a reservar un artículo exclusivo para ello.

En este artículo os vamos a contar todos los detalles de SmartHive, desde su motivación, su aportación como proyecto, su arquitectura, hasta una demo sobre su funcionamiento.

Motivación de un despliegue ágil de honeypots

Es posible que en nuestra organización tengamos la necesidad de hacer un despliegue de honeypots para obtener información de los atacantes y mejorar nuestros sistemas de detección, o bien a nivel personal simplemente tengamos curiosidad por saber cómo funcionan y qué tipo de información podemos recoger.

En cualquiera de los casos se sabe que el despliegue y la gestión de honeypots a gran escala es un trabajo arduo y costoso. Principalmente por varios motivos:

Existen pocas soluciones honeypot que se encuentren paquetizadas, dificultando su instalación.
Necesidad de configurar cada uno de los honeypots, en especial el reenvío de toda la información recabada por ellos a un servidor central que agregue todos los eventos recibidos.
Heterogeneidad en la información disponible en cada honeypot, requiriendo un análisis por separado y un proceso de normalización.

Por todo ello surgió la idea y la necesidad de comenzar el desarrollo de un proyecto donde todas estas tareas fueran transparentes para el usuario, de tal manera que pudiera centrar sus esfuerzos en la explotación de la información obtenida por la red de honeypots.

¿Qué nos podría aportar SmartHive?

En este apartado se comentan todas aquellas funcionalidades que vimos interesante incluir en el roadmap del proyecto antes de comenzar el Hackathon. Sin embargo, tal y como se verá al final del artículo (en la demo), a la finalización de la competición pudimos cerrar una versión funcional (cuyo código se encuentra en GitHub) pero muy reducida respecto a todo lo que habíamos pensado desarrollar.

Despliegue de honeypots en Internet

Hemos visto que gracias a SmartHive nos podemos despreocupar de todo el proceso de instalación y configuración de honeypots, así como del reenvío de eventos y la agregación y normalización de los mismos. ¿Pero qué más nos podría ofrecer?

Respecto al despliegue de honeypots:
- Posibilidad de despliegue de diferentes tipos de honeypots y sistemas de detección de intrusos (IDS) como Snort o Suricata, por mencionar algunos. En la versión actual de SmartHive solo se permite el despliegue de los siguientes tipos de honeypots de baja/media interacción:
  - Amun. Honeypot de baja interacción escrito en Python que permite emular una amplia variedad de servicios: SMB, DCOM, FTP, WINS, UPnP, HTTP, etc.
  - TELNET Honeypot. Honeypot de baja interacción escrito en Python que básicamente permite emular un servicio TELNET.
  - Cowrie. Honeypot de media interacción escrito en Python y basado en Kippo que permite registrar ataques SSH de fuerza bruta, y sobre todo, la interacción del atacante con la shell emulada.
  - Tom’s Honeypot. Honeypot de baja interacción escrito en Python por la compañía InGuardians capaz de emular los siguientes servicios: RDP, MSSQL, VNC, Radmin y SIP.
- Posibilidad de despliegue en distintas ubicaciones. En este proyecto se utilizó DigitalOcean (el enlace incluye nuestro código de referencia 🙂 ) como IaaS, permitiendo la creación de VPSs a bajo coste (desde 5 dólares al mes) en Nueva York, Ámsterdam, San Francisco, Singapur, Londres, Frankfurt y Toronto.
Respecto a la identificación de ataques:
- Identificación, geolocalización y categorización de ataques en función de los eventos recibidos en el servidor central.
- Identificación de nuevos ataques mediante la correlación de los eventos recibidos por todas las sondas (o VPSs).
- Aportación de valor añadido a los ataques con información procedente de diferentes fuentes de datos externas (e.g., listados de reputación).
Respecto a la información recogida de los ataques:
- Creación de listados de reputación propios sobre direcciones IP, dominios, URLs y muestras de malware, que podrían tener varios casos de uso:
  - Desde un punto de vista individual de una organización que contara con SmartHive, sus sistemas de detección podrían hacer uso de estos listados para consultar la reputación de un recurso cualquiera y tomar una decisión al respecto.
  - Desde un punto de vista global en el que varias organizaciones utilizaran SmartHive, se podrían combinar todos los tipos de listados de reputación correspondientes para que todas las organizaciones pudieran beneficiarse de la información recogida de los atacantes en su totalidad. Además, en este caso también se podría averiguar, comprobando los listados, si una organización estuviera siendo víctima de un ataque automatizado o dirigido.
- Aportación de información sobre atacantes a la Comunidad. Se podría contribuir a la Comunidad simplemente difundiendo estos listados de reputación; y por lo que respecta a las muestras, estas podrían ser analizadas por analistas de malware.
Respecto a la representación gráfica de la información:
- Visualización de los ataques en tiempo real en un mapa.
- Visualización de tendencias de ataque en tiempo real.
- Visualización de estadísticas por servicio expuesto, país, puerto, dirección IP, organización, firma, honeypot, sonda, etc.

Despliegue de honeypots en redes internas

Aunque hasta ahora solo hemos hablado del despliegue de honeypots en Internet, también vimos interesante incluir en el proyecto la posibilidad de desplegar sondas en la red interna de una organización como sistemas de alerta temprana. Y para ello pensamos en utilizar Raspberry Pis para que un despliegue de este tipo estuviera al alcance de cualquier pyme o particular.

Por una parte, estos dispositivos se podrían equipar con adaptadores inalámbricos para que pudieran detectar posibles ataques contra la red Wi-Fi de una organización: suplantación de puntos de acceso mediante puntos de acceso falsos (rogue APs), intentos de autenticación y/o asociación de clientes no autorizados, ataques de denegación de servicio a los clientes de la red, etc.

Y por otra parte, en la misma línea del subapartado anterior, estas sondas podrían venir perfectamente preparadas con una serie de honeypots que permitieran no solo la detección de equipos comprometidos que estuvieran realizando escaneos de red, sino también la de aquellos equipos que llegaran a interactuar con los servicios expuestos internamente por los honeypots. En este sentido, convendría hacer un despliegue en distintas subredes y configurar adecuadamente los honeypots habilitando aquellos servicios que más sentido tendría dentro de la propia subred (respecto a los servicios habilitados en el resto de equipos de la subred).

En cualquier caso, estas sondas ya estarían preparadas con todo el software instalado y preconfiguradas para que empezaran a funcionar automáticamente nada más conectarlas a la red.

Dado que los usuarios de la organización no deberían de conocer la existencia de estos sensores, cualquier tipo de tráfico que llegara a los mismos procedente de la red interna debería de ser considerado como sospechoso y generar una alerta para que fuera investigado.

Arquitectura de la solución

A continuación se muestra un esquema de la arquitectura que tomamos como punto de partida para el desarrollo de SmartHive:

Arquitectura de SmartHive

Una posible solución que estaría compuesta por los siguientes componentes:

smarthive-frontend. Este componente estaría formado por una aplicación web desarrollada con la plataforma Meteor y una base de datos NoSQL como MongoDB. Desde la web, por una parte se daría la posibilidad de desplegar una serie de honeypots en distintas ubicaciones de forma rápida y sencilla, y por otra parte, se visualizaría en tiempo real toda la información relacionada con los ataques: representación de los ataques en un mapa, tendencias de ataque, estadísticas por servicio, puerto, país, organización, etc.
smarthive-sensors. Estaría formado por todas las sondas (VPSs) utilizadas para el despliegue de honeypots. Proveedores como DigitalOcean o AWS podrían proporcionar estas sondas.
smarthive-manager. Este componente estaría formado a su vez por:
- Un elemento que se ocuparía de gestionar todos los eventos recibidos por las sondas. Es decir, se encargaría de procesar todos los eventos recibidos para almacenarlos en una base de datos y, mediante el análisis de los mismos, trataría de identificar los ataques que se representarían en la aplicación web.
- Y otro elemento que se limitaría únicamente a la gestión de las sondas (creación, configuración, destrucción) donde se desplegarían los honeypots.
smarthive-rabbitmq. Se encargaría de gestionar la comunicación entre todos los componentes de la plataforma a través de RabbitMQ. RabbitMQ es un sistema de mensajería de código abierto que implementa el protocolo AMQP diseñado para el intercambio de información a través de mensajes.
smarthive-raspberry-pis. Estaría formado por todas las Raspberry Pis que se desplegarían dentro de la red interna de la organización.

SmartHive en funcionamiento

Una vez visto con detalle los fundamentos de SmartHive, para finalizar este artículo e intentar aclarar todo lo posible el funcionamiento de la plataforma, se incluye a continuación una demo de la última versión que llegamos a cerrar al finalizar el Hackathon:

Imagen del artículo: Top 10 Animal Crafts And Activities For Kids

Acerca de
Últimas entradas

Pedro Castillo

Ingeniero Informático apasionado por la seguridad y la tecnología. Incansable perseguidor de retos. En constante reciclaje.

Ver descripción | Ver perfil en LinkedIn

Últimas entradas de Pedro Castillo (ver todo)