"¿Qué es esto?", es lo primero que uno se pregunta cuando escucha una palabra tan rara. En su web lo definen como un honeypot. Haciendo un extracto, podría decirse que, en términos informáticos, se trata de un software que simula ser algo que no es, con varios objetivos, tales como recoger información de posibles atacantes a un sistema, o despistarlos en sus malhechorías.

Como aficionado a la seguridad informática, me decidí a probar este elemento después de leer un post de barrapunto de cuyo nombre no quiero acordarme. Esto me llevó a echarle un vistazo por encima a Nessus, un escaner de vulnerabilidades Open Source, del cual quizás hablemos en otra ocasión.

¿Porqué me decidí por probar LaBrea, entre los varios tipos de honeypots existentes? Precisamente fue leyendo unos artículos de introducción a Nessus, que mencionaron la posibilidad de esta aplicación de detectar si la máquina analizada ejecuta un honeypot LaBrea. Como curiosidad, recomiendo leer la historia de su creación.

El modus operandi de LaBrea es el que sigue: usa las IP's de una red que están en desuso para crear la representación de lo que podrian ser varias máquinas con su software y sus servicios. Estas máquinas simuladas se encargan de responder a los intentos de conexión que se les realizan, con el propósito de que la máquina investigadora se queda mucho tiempo entretenida con las máquinas investigadas. ¿Cómo consigue esto? La aplicación vigila el tráfico ARP de la máquina en la que se ejecuta, y si pasado un tiempo prudencial después de una petición ARP, ésta no es resuelta, LaBrea crea una dirección MAC falsa y le asigna una IP. Desde este mismo momento, ya tenemos una máquina simulada creada, y podemos tener tantas como IP's libres tengamos en nuestro rango. También desde este mismo momento, la máquina simulada creada vigilará el tráfico TCP a ella dirigido, y responderá a las peticiones que se le hagan (aunque de forma muy limitada).

¿Qué casos de aplicación puede tener? Podemos tener un conjunto de servidores en una misma red de cara a Internet, y queremos ralentizar o incluso parar escaneos dirigidos a nuestras máquinas, ya sea por ahorrar ancho de banda, o bien por evitar ataques nuestros servicios reales. Otro ámbito de aplicación puede ser simple y llanamente el examen de las acciones que se llevan a cabo en un sistema -o conjunto de ellos- simulado, cuándo se realizan, con qué métodos, intenciones, y quién las realiza. En mi caso, estoy en el segundo grupo, pues mi máquina no ofrece -al menos no suele hacerlo- servicios de cara a Internet. Dispongo de un router, y para el experimento le indico una máquina DMZ (aquella a la que se le dirige todo el tráfico de aquellas peticiones que se realizan al router). Esto supone no tener ningún filtro entre Internet y mi máquina.

¿Cómo lo usamos? En la FAQ ya nos advierten que no es apto para cardíacos (ver el README). Sin la pista del FAQ, quién sabe si no hubiera sabido hacerme con él :o Primero de todo, sería necesario tener un fichero de configuración (en Debian está en /etc/labrea/labrea.conf), dónde se deben situar algunas preferencias, tales como:

• Direcciones IP que no deben ser capturadas núnca por LaBrea, por ejemplo, porque ya hay máquinas con esa IP (con la sintaxis x.x.x.x-y.y.y.y EXC para rangos).
• Direcciones IP que no deben ser ''hard-captured' (capturadas permanentemente) núnca (con sintaxis x.x.x.x HAR).
• Direcciones IP de las cuales queramos ignorar paquetes, por ejemplo, de máquinas nuestras (con sintaxis x.x.x.x/y IPI para rangos).
• Puertos a ignorar (no habrá tarpitting ni captura en ellos), (con sintaxis x-y POR para rangos).
• Puertos a vigilar (esta vez si tendran las anteriores atenciones), (con sintaxis x-y PMN para rangos).

Un ejemplo del fichero está descrito en el propio README disponible online, al final del documento. Con esto bien configurado para nuestro caso particular, antes de ejecutarlo prepararemos una instancia de tcpdump para volcar el tráfico ARP a la pantalla, analizarlo y ver cómo actúa LaBrea generando la MAC falsa. Una invocación sería tal que:

tcpdump -q -p -i eth0 arp

No es objeto de este artículo la explicación de tcpdump, pero baste saber que le estamos indicando que vigile el tráfico ARP del interfaz eth0 sin ponerla en modo promíscuo (cogeremos sólo los datos a ella dirigidos) y en modo no verboso. Dejamos ejecutando esto por un lado en una terminal, y no debería producir demasiada información. Sólo cabe destacar que quizás el router, al tener configurado un DMZ cuya IP se desconoce hasta el momento, vaya haciendo sucesivos requests de ARP acerca de la MAC de dicha IP con ansias de conocerla.

Por otro lado procedemos a ejecutar LaBrea (ojo, tus requisitos pueden ser distintos y los parámetros pueden variar):

labrea -z -s -o -b -p 10000 -i eth0 -v -a -h

Sin el parámetro -z no podremos usarlo. Esto parece ser puramente una prevención para no usar el programa sin conocer de los riesgos que comporta su uso (en la FAQ advierten que puede cargarse cosas en una red; apuesto a que habla de determinados servicios). El parámetro -s es para asegurarse de que una IP no está siendo usada en un entorno de varios switches, donde el host que ejecuta LaBrea puede no conocer todo el tráfico que circula por el switch. Con -o indicamos que queremos redirigir la salida a stdout, lo cual implica que el proceso quede 'enganchado' a la terminal donde se ejecuta. Con -b logueamos, minuto a minuto, el consumo del ancho de banda de la siguiente opción: -p, que significa el máximo del ancho de banda (en Bytes/s) que le queremos dedicar a LaBrea para la captura de intentos de conexión (si sobrepasa el límite, aún y sin capturar ese excedente, sigue ejerciendo su labor de frenar -tarpit- estos intentos). Con -i le indicamos la interfaz en la que la aplicación debe escuchar. Con -v aumentamos la 'verbosidad' del programa (y aún más con -vv). Con -h hacemos una 'hard-capture' de una IP; una vez que se captura una IP para ser usada como sistema simulado, se retiene permanentemente sin atender a timeouts de consultas ARP. Con -a podríamos cambiar el modo de actuación por defecto de la aplicación, que supone responder a los intentos de conexión (SYN/ACK) con RST, y responder a los pings.

Hecho esto, la aplicación empezará a monitorizar su inicialización y posteriores acciones por la terminal. En mi caso, es mi propio router quien activa el honeypot por su afán de conocer al poseedor de la IP del DMZ inexistente. En este momento, por consola deberíamos ver cómo LaBrea genera la "bogus MAC", con una dirección tal que 00:00:0f:ff:ff:ff. Ahora mi router ya sabe a quién mandarle las peticiones que recibe desde Internet.

A partir de este momento, LaBrea va registrando sucesivas conexiones a diferentes puertos. En mi caso, se trata de los puertos 135 (localizador de servicios tales como DHCP, DNS y WINS, aka loc-srv/epmap), 445 (SMB de NT5 ó superiores, aka microsoft-ds), 6883 (bittottent) y 31614 (¿?). Como dato estadístico, los fines de semana, las redes se ven copadas de p2p; concretamente del protocolo eDonkey (puerto local 4661 y sucesivos) y, cada vez más creciente, del protocolo bittorrent (puerto local 6881 y sucesivos). Interesantes son los mensajes de:

• "Additional Activity" y "Persist Activity", que se refieren al inicio o mantenimiento, respectivamente, de una conexión que simula cerrada y a la espera de podérsela abrir al que trata de conectar. Se le mantiene ocupado diciéndole periódicamente (hasta un máximo del bitrate indicado por -p) que se espere.
• "Initial Connect - tarpitting" y "Persist Trapping", que se refieren a que nuestro sistema simulado hace ver que inicia o mantiene, respectivamente, una comunicación producto de la demanda del sistema que trata de conectarnos, y dicho sistema trata infructuosamente de continuarla.

Por último, para tener una imagen más clara de lo que está pasando, visualizamos el tráfico con EtherApe, capturando paquetes TCP en el interfaz de interés (comunmente nuestra ethernet). Al cabo de un rato de estar ejecutando LaBrea (15 minutos) y un par de minutos de EtherApe, la cosa se puso seria y había gran cantidad de máquinas (apuesto eran usuarios) comunicándose con la mía simulada, como muestra esta captura. Se corresponde, claramente, con todas esas peticiones a los puertos 135 y 445 -mayormente- que registramos desde la salida de LaBrea. ¿Serán eso montones de máquinas Windows comunicándose de forma descontrolada?