USER MODE LINUX


http://user-mode-linux.sourceforge.net/










split@splitcc.net










1. ¿Qué es User Mode Linux?



User Mode Linux o UML, es una aplicación que nos proporciona una máquina virtual (VM) para poder ejecutar procesos (y kernels) sobre ella, es decir, varias instancias de linux sobre el mismo sistema. UML proporcionará a dicha VM un entorno de ejecución con sus correspondientes dispositivos hardware emulados (tales como discos duros, tarjetas de red, tarjeta de sonidos...), de tal forma que el sistema operativo se ejecute como si sobre un ordenador normal se tratase.


La ventaja de estas máquinas virtuales es que nada de lo que se realice sobre ellas, podrá dañar el hardware de la máquina real que las alberga o modificar el software de ésta, disponiendo de parámetros de seguridad, como la posibilidad de ejecutar dicho sistema emulado sobre una 'jaula' o chroot de tal modo que no afecte a los demás procesos que están en la memoria de la máquina real.


User Mode Linux está limitado a sistemas Linux, como su propio nombre indica, pero existen otras alternativas (aunque no libres) como VMWare que permite la instalación de gran cantidad de sistemas operativos (desde WindowsXP hasta Solaris, pasando por freeBSD por ejemplo), proporcionando hasta una BIOS virtual.


A partir de esta idea de que nada del software real es modificable, podemos pensar diferentes funcionalidades que podemos darles a estas máquinas virtuales. En concreto, UML es utilizado en muchas ocasiones con el fin de 'debuggear' kernels linux que estén en desarrollo o probar diferentes programas que se encuentren en fases de desarrollo.

Pero hay otros campos en el que puede ser útil, los Honeypots.



  1. Honeypots



Un Honeypot o "tarro de miel", se podría definir como un recurso que es expuesto al exterior para un posterior análisis de las operaciones que se realizan sobre él. La función principal suele ser poner dicho Honeypot de cebo, que puede ser por ejemplo, un sistema operativo instalado sobre una máquina virtual como UML, de tal forma que sea objeto de ataques de posibles intrusos y conocer así sus técnicas de ataque, nuevas formas de intrusión... con el fin de posteriormente asegurar nuestros sistemas reales o 'no-virtuales' ante éstos.


A partir de esto, podemos crear una Honeynet o un conjunto de sistemas intercomunicados, los cuales son Honeypots por separado pero que actuan conjuntamente en base a una red. De esta forma, la red que los compone está totalmente controlada y todo el tráfico es capturado en todo momento para conocer qué es los que hace el posible atacante en cada momento. Para hacer todo esto, disponemos de varias herramientas como los míticos sniffers (snort, tcpdump, sniffit...), ya a un nivel de kernel, parches como el de:


http://www.axehind.com/honeynet/

para éste de tal modo que capture las pulsaciones de los usuarios que están conectados a la máquina virtual o también parches para la shell bash :


http://project.honeynet.org/papers/honeynet/tools/bash.patch


de tal forma que loguea en el syslog todos los comandos utilizados por los usuarios para posteriormente poderlos revisar.


También disponemos de "herramientas forenses", con el fin de analizar una vez producido un ataque, todos los datos recogidos por el Honeypot. Una de las más conocidas en este campo es la aplicación TASK :


http://www.atstake.com/research/tools/task/


que permite entre otras cosas, recuperar archivos ya borrados de las particiones de datos ( por ejemplo, en el caso de que el intruso haya borrado lloos gs del sistema con el fin deeno djar huellas de su estancia en la máquina atacada), generación de informes y demás.


Una buena combinación de todas estas herramientas nos permitirá conocer al detalle todos los pasos que el intruso habría utilizado para llevar a cabo el ataque sobre la máquina.


A parte de User Mode Linux y el ya comentado VMWare, existen otras alternativas para implementar los Honeypots. A continuación se muestra una lista de algunas de ellos:


-BackOfficer Friendly: es un Honeypot para Windows cuyo origen fue un detector de intrusiones del troyano BackOriffice. En la actualidad puede ejecutar servicios emulados como telnet, pop3, ftp, imap2, http y smtp.


-The Bait and Switch Honeypot: consiste en un "redireccionador" del tráfico que pueda ser dañino para los hosts reales, hacia algún Honeypot de la red.


-HoneyWeb: es un proyecto para emular los diferentes servidores webs existentes, servicios que están siendo los más atacados en los últimos años.


-Deception Toolkit: es un conjunto de herramientas escritas en Perl y en C, que pretenden emular a servicios de red. Señalar que fue uno de los pioneros en éste área.


-Honeyd: este es uno de los más desarrollados y también Open Source. Es un conjunto de herramientas escritas en C y para plataformas UNIX, que son capaces de emular una gran variedad de sistemas (desde sistemas operativos normales hasta routers Cisco...) y de servicios.



Por lo tanto, tenemos como vemos una gran variedad de aplicaciones donde elegir y así poder disponer un amplio volumen de datos sobre los diversos ataques que se puedan producir.

  1. Ejecutando UML


Vamos a continuación a poner en práctica todo esto ejecutando un Honeypot, como es User Mode Linux.


Para poder ejecutar User Mode Linux, tan solo hay que bajar el programa de la web que el proyecto dispone:


http://user-mode-linux.sourceforge.net/


Ya se encuentra empaquetado en formatos RPM y DEB, para una mayor facilidad de instalación. Si nos encontramos en una distribución Debian SID, más fácil aún ejecutando el comando:


#apt-get install user-mode-linux


Una vez instalado por los medios habituales el programa, vemos que ha creado un ejecutable en la ruta /usr/bin/linux . Ese será por tanto el lanzador del kernel de la máquina virtual. Tenemos bastantes parámetros de ejecución, por lo que sería conveniente hacer un 'man linux' antes de ejecutar nada.


Lo que hace falta a continuación es un sistema de ficheros sobre el que ejecutar User Mode Linux. Aquí nos encontramos con dos posibilidades, crear uno vacío, es decir, sin ninguna distribución instalada o bajarse de internet un sistema de ficheros ya creado y con una distribución linux ya perfectamente preparada y configurada. En la misma web de UML, disponemos de varios sistemas de ficheros listos para que el kernel sea ejecutado en ellos. Los podemos bajar de :


http://user-mode-linux.sourceforge.net/dl-sf.html


pudiendo elegir entre varias distribuciones como Red Hat, Mandrake... todas ellas con sus servicios de SMTP,POP3,SAMBA,NFS...arrancados al inicio.

Si queremos disponer de una distribución Debian Woody, en esta otra URL también es posible hacerse con ella:


http://people.debian.org/~mdz/uml/


Una vez elegido el sistema de ficheros con el que arrancará nuestro kernel, deberemos configurar lo necesario para que la red funcione en la máquina virtual. Hay que tener en cuenta que la tarjeta de red emulada en el UML, no tiene conexión directa a la red, por lo que habrá que emular también su conexión para que se pueda disponer de los servicios de red.


Aquí es donde entra en juego las interfaces TUN/TAP. Podemos definir TUN como un dispositivo virtual punto a punto. El driver TUN está diseñado en el kernel de linux para proporcionar túneles IP y proporciona dos interfaces, el 'character device' (o dispositivo orientado al carácter, como lo son también los dispositivos para la impresora lp0,lp1...) llamado /dev/tunX y la interfaz punto a punto virtual, tunX. Por lo tanto, las aplicaciones escribirán los datagramas IP a /dev/tunX y que será recibido por el kernel a través del tunX.

TAP es sin embargo, un dispositivo de red virtual. Mediante este driver, el kernel soportará tunneling de tramas Ethernet. También proporciona el /dev/tapX y tapX para manejar dichos datos de red.


Lo primero que habrá que hacer por tanto, es habilitar TUN/TAP en el kernel del linux donde vayamos a ejecutar UML. Para ello, en la sección 'Network device support' de los kernels 2.4.X, habilitamos como módulo la opción '<M> Universal TUN/TAP device driver support' y recompilamos e instalamos con:


# make modules modules_install


Una vez hecho esto, antes de ejecutar UML, habrá que ejecutar unos cuantos comandos para que el enrutamiento y el tunel se lleve acabo (como root). Vamos a dar la IP 192.168.1.12 al sistema UML y 192.168.1.11 a nuestra interfaz tap0 (que se encontrará en la máquina real):


Lo primero que hacemos es hacer propietario de tap0 al usuario que usemos, en mi caso 'split':

#tunctl -u split


Levantamos la interfaz tap0 con una IP, por ejemplo 192.168.1.11

#ifconfig tap0 192.168.1.11 up


Habilitamos el 'fordwarding' o enrutamiento de paquetes IPv4

#bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'


Añadimos una ruta de tal modo que los paquetes que vayan dirigidos al host 192.168.1.12, que será la IP del UML, sean enviados por la interfaz tap0

#route add -host 192.168.1.12 dev tap0


Habilitamos a continuación ARP para tap0 y el host virtual:

#bash -c 'echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp'

#arp -Ds 192.168.1.12 eth0 pub


Declaramos la variable de entorno $TAP

#TAP=`tunctl -u 1000 -b`


Y damos todos los permisos al interfaz tun

#chmod 666 /dev/net/tun



Una vez hecho todo esto, ya tendríamos la interfaz tap0 levantanda en nuestra máquina anfitriona. Lo podemos comprobar haciendo:




split@BASAJAUN:~$ /sbin/ifconfig tap0

tap0 Link encap:Ethernet HWaddr 00:FF:FE:32:17:C5

inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:100

RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)



Vemos por tanto, que el interfaz tap0 tiene la IP 192.168.1.11, como le habíamos indicado.


Vamos a continuación a arrancar el UML. Para ello, hay que pasarle unos cuantos parámetros:


linux mem=40M ubd0=Debian-3.0r0.ext2 eth0=tuntap,tap0,C0:FF:EE:C0:FF:EE,192.168.11


De esta forma, le estamos diciendo que el sistema que ejecute el UML, dispondrá de 40 MB de memoria, su partición raíz será la contenida en el archivo Debian-3.0r0.ext2 que como hemos indicado antes, es un sistema de ficheros que nos hemos bajado de internet y por último, le decimos que el interfaz eth0 del sistema operativo de la máquina virtual, usará TUN/TAP con la interfaz tap0 de la máquina real, tendrá la dirección MAC indicada y la ip del tap0 es 192.168.1.11.


Una vez arrancado, habrá que ejecutar en el sistema operativo del UML:


#ifconfig eth0 192.168.1.12 netmask 255.255.255.0 up


para levantar la interfaz eth0 en dicho sistema y habilitar así la red.


El proceso de arranque del UML es el que se muestra a continuación:


BASAJAUN:/home/split/Proyectos/HoneyPots# linux mem=40M ubd0=Debian-3.0r0.ext2 eth0=tuntap,tap0,C0:FF:EE:C0:FF:EE,192.168.1.11

Checking for the skas3 patch in the host...not found

Checking for /proc/mm...not found

tracing thread pid = 641

Linux version 2.4.19-50um (mdz@mizar) (gcc version 3.2.2) #1 SMP Thu Feb 6 22:57 :55 EST 2003

On node 0 totalpages: 10240

zone(0): 10240 pages.

zone(1): 0 pages.

zone(2): 0 pages.

Kernel command line: mem=40M ubd0=Debian-3.0r0.ext2 eth0=tuntap,tap0,C0:FF:EE:C0 :FF:EE,192.168.1.11 root=/dev/ubd0

Calibrating delay loop... 460.80 BogoMIPS

Memory: 37228k available

Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)

Inode cache hash table entries: 4096 (order: 3, 32768 bytes)

Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)

Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)

Page-cache hash table entries: 16384 (order: 4, 65536 bytes)

Checking for host processor cmov support...Yes

Checking for host processor xmm support...No

Checking that ptrace can change system call numbers...OK

Checking that host ptys support output SIGIO...No, enabling workaround

Checking that host ptys support SIGIO on close...No, enabling workaround

POSIX conformance testing by UNIFIX

All CPUs are go!

Waiting on wait_init_idle (map = 0x0)

All processors have done init_idle

Linux NET4.0 for Linux 2.4

Based upon Swansea University Computer Society NET3.039

Initializing RT netlink socket

Starting kswapd

VFS: Diskquotas version dquot_6.4.0 initialized

Journalled Block Device driver loaded

devfs: v1.12a (20020514) Richard Gooch (rgooch@atnf.csiro.au)

devfs: boot_options: 0x0

pty: 256 Unix98 ptys configured

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

loop: loaded (max 8 devices)

Initializing software serial port version 1

mconsole (version 2) initialized on /root/.uml/6c6dxl/mconsole

Partition check:

ubda: unknown partition table

Initializing stdio console driver

Netdevice 0 (c0:ff:ee:c0:ff:ee) : TUN/TAP backend - IP = 192.168.1.11

NET4: Linux TCP/IP 1.0 for NET4.0

IP Protocols: ICMP, UDP, TCP, IGMP

IP: routing cache hash table of 512 buckets, 4Kbytes

TCP: Hash tables configured (established 2048 bind 2048)

Linux IP multicast router 0.06 plus PIM-SM

NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.

VFS: Mounted root (ext2 filesystem) readonly.

INIT: version 2.84 booting

Activating swap.

Checking root file system...

fsck 1.27 (8-Mar-2002)

/dev/ubd0: clean, 11137/15808 files, 61385/61389 blocks

System time was Tue Feb 25 15:44:13 UTC 2003.

Setting the System Clock using the Hardware Clock as reference...

hwclock is unable to get I/O port access: the iopl(3) call failed.

System Clock set. System local time is now Tue Feb 25 15:44:15 UTC 2003.

Calculating module dependencies... depmod: Can't open /lib/modules/2.4.19-50um/m odules.dep for writing

done.

Loading modules:

modprobe: Can't open dependencies file /lib/modules/2.4.19-50um/modules.dep (No such file or directory)

Checking all file systems...

fsck 1.27 (8-Mar-2002)

Setting kernel variables.

Mounting local filesystems...

nothing was mounted

Running 0dns-down to make sure resolv.conf is ok...done.

Setting up IP spoofing protection: rp_filter.

Configuring network interfaces: done.


Setting the System Clock using the Hardware Clock as reference...

hwclock is unable to get I/O port access: the iopl(3) call failed.

System Clock set. Local time: Tue Feb 25 15:44:23 UTC 2003


Cleaning: /tmp /var/lock /var/run.

Initializing random number generator... done.

Recovering nvi editor sessions... done.

INIT: Entering runlevel: 2

Starting system log daemon: syslogd.

Starting kernel log daemon: klogd.

Starting internet superserver: inetd.

Starting deferred execution scheduler: atd.

Starting periodic command scheduler: cron.



Debian GNU/Linux 3.0 UML tty1


UML login:



Con lo que ya tendremos el sistema UML arrancado y completamente operativo para la ejecución de programas, instalación, pruebas...


Si queremos a continuación arrancar otra máquina virtual, solamente tendremos que configurar otra interfaz TAP, como tap1 y dos direcciones IP distintas a las que ya se están usando, con lo que el proceso es exactamente el mismo solo que cambiando dichos parámetros.


Señalar en este punto que hay bastantes más parámetros interesantes para ejecutar UML, basta con mirar la página 'man linux'. Uno de ellos, es la opción jail que proporciona una protección de la memoria usada por el kernel de los procesos, evitando asi posibles el 'exploit' de desbordamientos de bufferes y demás. Con la opción 'debug' , iniciaremos el kernel bajo el gdb, que es el debugger por excelencia de los sistemas Linux.


Además, como vemos en las primeras lineas de ejecución del UML, vemos que sale un mensaje tal que:


Checking for the skas3 patch in the host...not found

Checking for /proc/mm...not found


El parche SKAS ("Separate Kernel Address Space" ) se aplica sobre el kernel de la máquina real, es decir, desde donde va a ejecutarse el UML Se puede encontrar en:


http://prdownloads.sourceforge.net/user-mode-linux/host-skas3.patch


Lo que se consigue con este parche es una mejora de rendimiento en el UML y otras centradas en la seguridad, como que el thread del kernel del UML corre en espacio de direcciones diferente a la del kernel de la máquina real. Para ello el kernel del UML debe tener habilitado la opción CONFIG_MODE_SKAS. Si una vez aplicado el parche al kernel, al arrancar obtenemos este mensaje, es que ya se está ejecutando en modo "skas":


Checking for the skas3 patch in the host...found

Checking for /proc/mm...found



Una situación con la que podemos encontrarnos es querer hacer más grande la partición donde tenemos instalado el sistema operativo "virtual". Como el sistema de ficheros lo tenemos en un archivo, una solución que tenemos es crear un sistema mayor en otro archivo (o bajarlo directamente ya hecho de http://www.stearns.org/mkrootfs/ ) y copiar los datos a él.


Para ello, imaginemos que tenemos un sistema de ficheros llamado Debian-3.0r0.ext2 con un sistema GNU/Linux Debian instalado en él. Nos bajamos por ejemplo de


http://www.stearns.org/mkrootfs/emptyfs.ext2.2048.bz2


un sistema ext2 de 2 GB vacío. Tendremos que montar ambos archivos, del siguiente modo:


#mount -o loop Debian-3.0r0.ext2 /mnt/uml/

#mount -o loop emptyfs.ext2.2048 /mnt/uml2/


y posteriormente copiar los datos de /mnt/uml a la partición vacia situada en /mnt/uml2. Se desmontan ambos sistemas, y ya tenemos la antigua Debian en un sistema de ficheros de 2 GB, de tal forma que disponemos de espacio adicional para instalar programas y demás.





4. Conclusión


Hemos podido ver por tanto que los Honeypots pueden servir para proporcionarnos una gran información sobre los ataques de los que podríamos ser objetivo, pudiendo luego tomar las medidas oportunas para poder defendernos posteriormente de dichos ataques.


Es un campo que está en continuo desarrollo y más en cuanto a las herramientas libres se refiere, por lo que habrá que estar atento ante posibles nuevas funcionalidades o características de estos sistemas.




5. Links


User Mode Linux: http://user-mode-linux.sourceforge.net/


The HoneyNet Project: http://project.honeynet.org/


Sistemas de Ficheros:

http://user-mode-linux.sourceforge.net/dl-sf.html

http://people.debian.org/~mdz/uml/








CC
Alvaro Marin, 2004. Algunos derechos reservados.
http://creativecommons.org/licenses/by-nc-sa/2.0/