Instalación y configuración de Sebek 0.4
Un ejemplo práctico

por TageTora (Proyecto HIS)
http://his.sourceforge.net
8 Marzo del 2003

Licencia del documento

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".


1. Introducción

El motivo de este texto es exponer las experiencias del autor sobre una instalación real del paquete Sebek. En medio de la configuración de una red trampa (honeynet) de 2a generación, nos encontramos con que toda la documentación sobre la instalación y configuración de Sebek se reduce al fichero "readme" que contiene el propio paquete. Así que decidimos ir recogiendo en un texto nuestras experiencias en cuanto a los posibles problemas de configuración y también respecto a las posibilidades que nos ofrece el paquete. Todos los pasos realizados se llevaron a cabo en un entorno real que más abajo descibiremos y a partir de la documentación original de Sebek.

En este texto vamos a hablar continuamente de equipos trampa y redes trampa, si no conoce estos términos, le recomendamos que lea primero los textos del Honeynet Project, especialmente el texto sobre Honeynets.

2. ¿Qué es Sebek?

Podemos dividir Sebek en dos partes. La primera consiste en un rootkit que recoge información dentro de un equipo trampa (honeypot), y que envía los datos obtenidos a un recolector (esta es la 2a parte). El programa recolector se ejecuta en una máquina separada, que puede ser la máquina de control, o en la máquina que hace de "syslog" remoto (claro que puede ser en cualquier otra máquina, pero esto es lo más recomendable para tener un control de datos centrado en un mismo equipo).

El funcionamiento es simple, el rootkit instalado es una versión del conocido Adore, que recoge las pulsaciones de teclas o incluso ficheros copiados mediante scp desde o hacia el equipo trampa. Estos datos capturados los recoge el SDM (Monitor del Dispositivo Sebek) el cual los empaqueta, los cifra mediante el algoritmo Blowfish y los envía en un paquete UDP con direcciones IP y MAC de origen falsas. Estos paquetes los recoge el sniffer instalado en la máquina recolectora.

Sebek ha sido desarrollado por Edward Balas, miembro del Honeynet Project, y puede descargarlo de la página de herramientas del Honeynet Project en http://www.honeynet.org/papers/honeynet/tools/

3. Entorno de trabajo

Como hemos mencionado antes, disponemos de una red trampa de 2a generación, es decir, tenemos un conjunto de equipos trampa a los cuales se accede a través de la máquina de control, que está a la entrada de la subred funcionando en modo puente. Podemos verlo más claro en el siguente esquema:

Sin entrar en muchos detalles, decir que la máquina de control es una Red Hat 8.0 que utiliza bridge y ebtables para el control de tráfico, mientras que la captura se realiza a través de Snort (captura + IDS), una configuración típica. Por otra parte, el equipo trampa es una Debian Woody 3.0r0 que básicamente ofrece los servicios HTTP/HTTPS y SSH. El hecho de que trabajemos con estos protocolos cifrados, y que no nos importe que se pueda descubrir la instalación de Sebek (nos interesa más el momento del ataque que el uso posterior que le dé el intruso), nos ha llevado a elegir este paquete para recolectar datos en claro (sin cifrar).

Puede parecer contradictorio el que usemos una Red Hat para la máquina de control y una Debian como máquina "vulnerable", pero hay que tener en cuenta que la Red Hat será una máquina transparente (será complicado que la detecten y por lo tanto más complicado aún que la ataquen) y además es una máquina de control compartida con los "administradores" de los otros equipos trampa, y RH resultó ser la mejor opción para todos.

4. Instalación de Sebek

Primero debemos preparar los requisitos del programa, que esencialmente son tres:

Es importante tener en cuenta que las fuentes del núcleo deben ser de la versión con la que trabajará el rootkit de Sebek, de lo contrario no funcionará (aunque compilaria sin problemas, daria errores al ejecutarlo).

Una vez todo preparado, vamos a por la instalación, que vamos a dividir en dos partes. La primera parte es común para la instalación de Sebek en la máquina trampa como en la de control, pero hay un último paso que depende de la máquina en la que nos encontremos. Primero descargamos la herramienta (si no lo habíamos hecho ya) y la descomprimimos en un directorio:

tora:˜$ wget http://www.honeynet.org/papers/honeynet/tools/sebek-0.4.tar.gz
tora:˜$ tar xzvf sebek-0.4.tar.gz

ahora simplemente tenemos que movernos al directorio donde se ha descomprimido y compilar:

tora:˜$ cd sebek-0.4
tora:sebek-0.4$ make

En nuestro caso de ejemplo tuvimos un pequeño problema al compilar, ya que obteniamos un error al intentar abrir la libreria pcap. Concretamente el error lo daba el fichero sebeksniff.c, línea 47:

tora:˜$ cd sniff
tora:sniff$ vi sebeksniff.c
...
47: #include <pcap/pcap.h>

Así que nos toca averiguar dónde se encuentra exactamente la cabecera pcap.h:

tora:sniff$ whereis pcap
pcap: /usr/include/pcap.h /usr/share/man/man3/pcap.3.gz

La forma más simple de hacerlo funcionar es editar el fichero sebeksniff.c y modificar la línea 47 para que no busque la cabecera en el directorio pcap, quedaria así:

tora:sniff$ vi sebeksniff.c
...
47: #include <pcap.h>

Y efectivamente funciona, así que ahora tenemos dos archivos .tar, uno para la máquina trampa (sebek.tar) y otro para la máquina de control (collector.tar). En principio si las dos máquinas són iguales, lo que hemos explicado hasta ahora se puede realizar en una sola máquina y pasar el tar resultante a la otra. Sin embargo, como nuestras máquinas son diferentes, se ha compilado Sebek en cada una de ellas, eligiendo sólo el archivo resultante apropiado. Veamos esa segunda parte de la instalación:

Máquina de control

Aquí simplemente nos queda llevar el archivo collector.tar al directorio que queramos y descomprimirlo allí. Como resultado se nos creará un subdirectorio llamado collector que contiene las herramientas para recolectar y presentar los datos enviados por el SDMde la máquina trampa.

Máquina trampa

El archivo que nos interesa aquí es sebek.tar. Debemos llevarlo a /tmp y descomprimirlo allí. Por último debemos hacer ejecutable el guión de comandos (del inglés shell script):

tora:˜$ mv sebek.tar /tmp/
tora:˜$ cd /tmp
tora:tmp$ tar xvf sebek.tar
tora:tmp$ cd sebek
tora:sebek$ chmod 700 sebek.sh
tora:sebek$ vi sebek.sh
... pero esto ya es parte de la configuración ;)

Nota: si en el sistema de la máquina trampa, el directorio /tmp se limpia periódicamente, debemos asegurarnos de quitarle permisos de escritura mediante el comando chmod 500 /tmp/sebek.

5. Configuración

La configuración se realiza exclusivamente en la máquina trampa. Los parámetros que aquí se establezcan se tranforman en argumentos añadidos al comando que se ejecutará en la máquina de control. Dicha configuración se realiza a través del fichero /tmp/sebek/sebek.sh (si se ha realizado la instalación siguiendo los pasos anteriores). Vamos a seguir las opciones de configuración según el orden en que aparecen en el fichero (para no perdernos), así que empecemos:

Las dos primeras opciones se refieren al directorio de instalación donde se encuentra este mismo fichero que estamos editando, junto a los ejecutables ava y sdm entre otras cosas, y al dispositivo mediante el que se pasarán los datos del núcleo al SDM. Si hemos realizado una instalación estándar (como la nuestra) no debemos cambiar nada. La siguiente opción es la contraseña con la que el SDM cifrará los datos mediante el algoritmo Blowfish, así que como en todos los programas, es importante no dejar la contraseña por defecto:

PASSWORD="t3stsebek";

El siguiente punto és importante, ya que trata de las direcciones de origen y destino utilizadas por el SDM para enviar los datos. Debemos elegir una dirección de origen distinta a la nuestra para evitar sospechas de un posible intruso (sobre la dirección de destino de la máquina de control da igual, porque no tiene ninguna dirección IP). También tenemos en cuenta que debemos utilizar direcciones significativas para que la máquina de control pueda fácilmente evitar que se propaguen hacia el exterior de la red trampa. Teniendo en cuenta esto y la opción de puerto destino que explicamos más abajo, nos queda la siguiente configuración:

DST_NET="192.168.222.17/32"
SRC_NET="192.168.222.0/24"

Hay que comentar que las direcciones reales de los equipos trampa son direcciones públicas de clase B, y que en la red interna no se utiliza ningún tipo de dirección privada del estilo 192.168.x.x, así que estos paquetes podrán ser identificados fácilmente. Esta configuración hará parecer la red como un conjunto de nodos comunicándose con un único punto (¿servidor?). En combinación con esto, elegimos también un puerto de destino (la siguiente opción) en el que hubiera un servicio UDP que no fuese muy habitual y que no interfiriera con los servicios del resto de la red. En nuestro caso elegimos SNMP.

En el caso de que se quiera algo más de libertad en cuanto a los puertos utilizados, entonces habrá que utilizar el número mágico, que puede usarse de dos formas:

La elección de una u otra forma depende de la configuración de la red que tengamos y de lo que nos preocupe que ese tráfico pueda ser identificado. Volviendo a nuestro caso, como queríamos que siempre utilizara el mismo puerto, no utilizamos el magic_number:

DST_PORT="161"
#MAGIC_NO="7777"

Tan sólo añadir sobre direcciones y puertos que esta combinación nos servirá para detectar de forma instantánea el compromiso del equipo trampa (siempre que el intruso obtenga una línea de comandos -shell-, no en el caso de ataques DoS por ejemplo), ya que será fácil hacer que Snort nos alerte al detectar tráfico de estas características (direcciones 192.168.x.x, UDP, puerto destino 161...), lo cual indica que hay un intruso "trabajando" dentro de nuestro equipo trampa.

Nos queda un último parámetro, la frecuencia con que el SDM enviará paquetes (si tiene datos para enviar, claro). Para que no le lleguen grandes ráfagas de paquetes a la máquina de control, establecemos un retraso de 1.5 segundos entre envíos:

PKT_DELAY="1500000"

Bueno, pues ya lo tenemos instalado y configurado ¿verdad que no ha sido tan difícil?

6. Resultados

Llegados a este punto sólo nos falta hacer pruebas con Sebek para ver que funciona de forma correcta. Primero arrancaremos el colector en la máquina de control, para ello ejecutaremos:

control:collector$ ./sebeksniff -d eth1 -p 161 -s t3stsebek

Simplemente especificamos la interfaz donde está conectada la máquina trampa (eth1), el puerto de destino de los paquetes que envía el SDM (161, puerto para SNMP), y la contraseña utilizada para así poder descifrar los mensajes.Cabe destacar que todos los paquetes UDP con puerto de destino 161 que lleguen a la interfaz eth1 serán procesados por Sebek. Lo mismo ocurriria de haber establecido el número mágico, ya que todos los paquetes UDP con una diferencia de [puerto_origen = num.mágico - puerto_destino] (en caso de especificar -p y -m, número de puerto y número mágico) o de [puerto_origen + puerto_destino = num.mágico] (en caso de no especificar nada -caso por defecto "-m 7777"- o de utilizar sólo el número mágico) serían también procesados por Sebek.

Ahora sólo nos queda ejecutar el rootkit en la máquina trampa, así que simplemente tenemos que ejecutar:

tora:sebek$ ./sebek.sh start

Si todo ha ido bien, nos informará que ha ocultado los ficheros de forma satisfactoria, y si hacemos un ls para comprobarlo veremos que todos los ficheros, excepto las guías de instalación (README, sebek.html), ¡han desaparecido! De la misma forma, si intentamos buscar los procesos ava (de Adore) y el sdm no podremos encontrarlos.

Por otro lado, mientras intentamos descubrir algún indicio de los fichero, directorios o procesos de Sebek en la máquina trampa, podremos observar como a cada acción nuestra, sebeksniff nos informa de la llegada de nuevos datos, pertenecientes a las pulsaciones de teclas en la máquina trampa (no sólo desde la línea de comandos, sino que también incluye pulsaciones dentro de editores de texto, sesiones ftp/ssh/loquesea, etc...).

7. Ejemplo

Como comentamos unas lineas más arriba, justo después de ejecutar Sebek, ejecutamos algunos comandos/acciones de test, para comprobar que Sebek se había ocultado correctamente y que la captura de datos era correcta. Los comandos en sí no tienen mucho interés, lo importante es observar como Sebek nos presenta los resultados.

Primero ejecutamos el programa colector como hemos descrito unas líneas más arriba:

control:collector$ ./sebeksniff -d eth1 -p 161 -s t3stsebek

y luego ejecutamos Sebek:

tora:sebek$ ./sebek.sh start

Ejecutamos algunos comandos y lo paramos todo para observar los datos con tranquilidad. Suponiendo que la dirección de nuestro equipo trampa fuese 10.0.0.2 (dirección ficticia), se habrá creado en el directorio donde se encuentra el programa recolector un fichero con ese mismo nombre: "10.0.0.2". Esto nos resulta muy cómodo si estamos recolectando datos de diferentes equipos. Si editamos el fichero no nos enteraremos de mucho, así que mejor utilizamos la herramienta sbdump, que encontraremos en el directorio collector:

control:collector$ ./sbdump -c 10.0.0.2

18:06:06-2003/03/06 [0:bash:195:vc/1:0]ls
18:06:16-2003/03/06 [0:bash:195:vc/1:0]cd ..
18:07:49-2003/03/06 [0:bash:195:vc/1:0]cd /etc  ^?^?^?^?^?^?ddddddddddddddddddddddddddddddddd^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?av                             ^?^?cd /tmp     se      ^?^?^?^?^?^?^?^?^?ebek
18:11:16-2003/03/06 [0:bash:195:vc/1:0]./sebek.h ^?^?sh stop
18:11:26-2003/03/06 [0:bash:195:vc/1:0]a^?killall -HUP ava
18:11:42-2003/03/06 [0:bash:195:vc/1:0]d^?vi ebe^?^?^?sebek.h
18:11:54-2003/03/06 [0:vi:703:vc/1:0]11:q
18:13:35-2003/03/06 [0:bash:195:vc/1:0]vi e^?sebek.sh
18:13:40-2003/03/06 [0:vi:704:vc/1:0]11xxi10^?5^?^[r5:wq
18:14:31-2003/03/06 [0:bash:195:vc/1:0]./ebe^?^?^?se^?^?^?^?d
18:14:36-2003/03/06 [0:bash:195:vc/1:0].^?^?vi READ
18:14:40-2003/03/06 [0:vi:706:vc/1:0]11:q
18:14:46-2003/03/06 [0:bash:195:vc/1:0]killall -HUP dm^?^?sdm
18:14:54-2003/03/06 [0:bash:195:vc/1:0]./sebek stat^?rt
18:15:01-2003/03/06 [0:bash:195:vc/1:0]^[[A^[[D^[[D^[[D^[[D^[[D^[[D.sh
18:15:14-2003/03/06 [0:bash:195:vc/1:0]ls
18:15:21-2003/03/06 [0:bash:195:vc/1:0]ddddddddddddddddddddddd^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?e^?reboot^?^?^?^?^?^?^?^?^?shut     -h now

Ahora ya se ve algo más claro... o no. En principio podemos ver la marca de tiempo de cada acción. Después tenemos, por orden de aparición, primero el UID del usuario que ha ejecutado la acción (en este caso es root, uid = 0), el proceso dentro del cual se ha ejecutado, el PID de dicho proceso (195 para la línea de comandos, 70X para las ediciones con el vi), la terminal donde se ejecutó y por último el descriptor de fichero.

Al observar estos datos, comprobamos que se han capturado hasta los comandos ejecutados dentro del editor vi (hay un par de :q, un :wq, carácteres borrados con x y reemplazados con r). Para no volverse locos con este conjunto de datos, recomendamos volcar la salida de sbdump a un fichero y ayudarse de un editor hexadecimal, e ir substituyendo los carácteres de borrado (0x7F), los tabuladores para completar comandos (0x09), cursor arriba para acceder al historial de comandos (0x1B 0x5B 0x41), etc... por sus posibles cadenas resultantes. Como ejemplo, hemos "restaurado" la salida anterior de sbdump:

18:06:06-2003/03/06 [0:bash:195:vc/1:0]ls
18:06:16-2003/03/06 [0:bash:195:vc/1:0]cd ..
18:07:49-2003/03/06 [0:bash:195:vc/1:0]cd sebek
18:11:16-2003/03/06 [0:bash:195:vc/1:0]./sebek.sh stop
18:11:26-2003/03/06 [0:bash:195:vc/1:0]killall -HUP ava
18:11:42-2003/03/06 [0:bash:195:vc/1:0]vi sebek.h
18:11:54-2003/03/06 [0:vi:703:vc/1:0]11:q
18:13:35-2003/03/06 [0:bash:195:vc/1:0]vi sebek.sh
18:13:40-2003/03/06 [0:vi:704:vc/1:0]11xxi10[BS]5[BS][BS][CUR]r5:wq
18:14:31-2003/03/06 [0:bash:195:vc/1:0]d
18:14:36-2003/03/06 [0:bash:195:vc/1:0]vi README
18:14:40-2003/03/06 [0:vi:706:vc/1:0]11:q
18:14:46-2003/03/06 [0:bash:195:vc/1:0]killall -HUP sdm
18:14:54-2003/03/06 [0:bash:195:vc/1:0]./sebek start
18:15:01-2003/03/06 [0:bash:195:vc/1:0][ARR][IZQ][IZQ][IZQ][IZQ][IZQ][IZQ].sh
equivalente a
18:15:01-2003/03/06 [0:bash:195:vc/1:0]./sebek.sh start
18:15:14-2003/03/06 [0:bash:195:vc/1:0]ls
18:15:21-2003/03/06 [0:bash:195:vc/1:0]shutdown -h now

Ahora sí, tenemos muy claro qué y cuando ha sucedido, pero tenemos que admitir que es costoso, quizá demasiado, ya que hay que tener en cuenta que estos son unos pocos comandos de ejemplo, pero en un caso real podríamos estar trabajamdo con sesiones de 15, 30 minutos o incluso más (depende de cuanto tardemos en cortar la comunicacción).

8. Trabajo futuro.

A pesar de lo bien que funciona Sebek, no deja de tener algunos aspectos "mejorables" a nuestro parecer, que exponemos a continuación:

De todas formas, dentro de poco saldrá una nueva versión de Sebek, así que esperemos que en la revisión de este texto no tengamos nada de qué quejarnos ;)


Honeynet in Spanish, Marzo del 2003