12 septiembre 2008

Creación de laboratorios virtuales con Netkit (I)


Avanzar en el campo de la Ingeniería de Seguridad requiere un aprendizaje constante en múltiples disciplinas. Este aprendizaje es en gran parte teórico pero para ser plenamente efectivo necesita ponerse en práctica. Un ingeniero de seguridad debe ser capaz de ponerse en el lugar de un atacante y predecir con razonable certeza cual será su próximo paso. Pero esto resulta complicado ya que un ingeniero no puede ir por ahí atacando redes con la excusa de que está aprendiendo cómo lo hacen los malos de la película.

Hasta hace poco, la única opción de la que disponían los estudiosos de la seguridad era montar un laboratorio en casa juntando ordenadores de bajo coste y equipamiento de red. Desgraciadamente esto era caro, consumía un espacio cada vez más escaso en las casas modernas y ponía en tu contra a la pareja/conyuge/padre/madre que no entendían a qué venía tanto cable. Por suerte, la era de la virtualización acudió al rescate con lo que hoy en día es posible montar complejos laboratorios virtuales dentro de nuestro ordenador.

La opción más sencilla son las máquinas virtuales individuales del tipo VMWare o VirtualBox, que resultan ideales para probar herramientas, rootkit, vulnerabilidades, etc en distintos sistemas operativos sin poner en peligro nuestro propio ordenador. Iniciando varias de estas máquinas virtuales se pueden hacer pruebas de red simulando una LAN. Incluso circulan por ahí tutoriales para simular topologías más complejas mediante VMWare. Sin embargo, llevar hasta ese punto tales herramientas puede exigir consumir unos recursos a nuestro ordenador con los que puede que no contemos.

La otra opción se llama Netkit, desarrollado en la Universidad de Roma. Está enfocado no tanto a la emulación de equipos concretos sino de redes completas. Netkit nos permite definir una topología de red y hacer pruebas con ella. Para ello iniciaremos una serie de nodos que no son sino instancias virtuales de Linux Debian ultraligeros y los configuraremos según el papel que jueguen dentro de la red que queremos simular (router, switch o equipo final).

Su instalación es muy sencilla. Primero hay que descargar tres ficheros:
Una vez descargados deben ser descomprimidos todos juntos en el directorio que elijamos (supondremos que /usr/share/netkit) (ver actualización al final del artículo) y luego prepararemos unas cuantas variables de entorno para que quede constancia de donde hemos instalado el Netkit. Para ello, lo más recomendable es añadir al final de /etc/profile las siguientes líneas:

NETKIT_HOME="/usr/share/netkit"
MANPATH="$MANPATH:$NETKIT_HOME/man"
PATH="$PATH:$NETKIT_HOME/bin"
export NETKIT_HOME MANPATH PATH

Una vez hecho esto hay que reiniciar el equipo para que funcionen las variables de entorno que acabamos de configurar. Y ya está, para comprobar que no falla nada ejecutamos un script de comprobación que incluye netkit:

dante@Hades:/usr/share/netkit$ ./check_configuration.sh > Checking path correctness... passed. > Checking environment... passed. > Checking for availability of man pages... passed. > Checking for proper directories in the PATH... passed. > Checking for availability of auxiliary tools: awk : ok basename : ok date : ok dirname : ok find : ok getopt : ok grep : ok head : ok id : ok kill : ok ls : ok lsof : ok ps : ok readlink : ok wc : ok port-helper : ok tunctl : ok uml_mconsole : ok uml_switch : ok passed. > Checking for availability of terminal emulator applications: xterm : found konsole : found gnome-terminal : not found passed. [ READY ] Congratulations! Your Netkit setup is now complete! Enjoy Netkit!


Llegados a este punto empieza lo realmente interesante.

Vamos a arrancar dos máquinas virtuales conectadas al mismo dominio de colisión (equivalente pincharlos en el mismo hub) y vamos a hacer ping entre ellas.

dante@Hades:~/netkit_labs$ vstart --eth0=CD-A -M 100 PC-1 dante@Hades:~/netkit_labs$ vstart --eth0=CD-A -M 100 PC-2 dante@Hades:~/netkit_labs$ ls -l total 1136 -rw-r--r-- 1 dante dante 1074012160 2008-09-11 23:26 PC-1.disk -rw-r--r-- 1 dante dante 470 2008-09-11 23:25 PC-1.log -rw-r--r-- 1 dante dante 1074012160 2008-09-11 23:26 PC-2.disk -rw-r--r-- 1 dante dante 470 2008-09-11 23:26 PC-2.log

Con el parámetro --eth0 se asigna a dicho interfaz al dominio de colisión CD-A (podemos llamarlos como deseemos), y con el parámetro -M le adjudicamos 100 MB de memoria RAM a la máquina. Se puede ver que Netkit crea un archivo .disk por cada máquina virtual creada, donde guarda su sistema de ficheros. Cada sistema de ficheros usa 1'1GB por defecto así que mejor asegurarse de tener espacio de sobra antes de iniciar un experimento con muchas máquinas.

Al hacer cada uno de los vstart aparece una ventana de xterm con la consola del equipo virtual que hemos lanzado.


Es ahí donde configuramos cada una de las máquinas:

PC-1:~# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up PC-2:~# ifconfig eth0 192.168.0.2 netmask 255.255.255.0 up

Si ahora hacemos ping entre las dos máquinas veremos que hay respuesta.

Ahora vamos a hacer un experimento muy sencillo, para que no se diga que en este artículo no se ha tratado la seguridad informática. Vamos a remontarnos a hace más de 10 años, cuando las redes se basaban en su mayor parte en hubs, es decir, cuando todos los PCs de la red se conectaban al mismo dominio de colisión. En aquellos tiempos era muy fácil realizar escuchas (sniffing) ya que los hubs replicaban todo lo que recibían por un puerto al resto de los puertos con lo que si alguien ponía su interfaz en modo promíscuo podía evitar que su tarjeta de red descartase los paquetes que no fuesen dirigidos a él y visualizarlos en un programa como tcpdump. Para simular lo que habría hecho un atacante de aquellos tiempos vamos a crear su PC de la misma manera que los anteriores pero llamándolo PC-3 y asignándole la dirección IP 192.168.0.3. Esto sería como pinchar el PC del intruso al hub de los espiados. Ahora arrancamos un tcpdump en PC-3 y vemos si podemos captar el ping que vamos a lanzar desde PC-2 a PC-1:

Como se puede ver en la imagen le hemos dado tiempo a PC-2 a enviar dos ping a PC-1 y este ha respondido correctamente. ¿Y que ha visto PC-3?, pues todo, la consulta arp de PC-2, la respuesta de PC-1, los ICMP-request de PC-2 (pings de ida) y los ICMP-reply de PC-1 (pings de vuelta). Vamos, que PC-3 se ha enterado de toda la "conversación" entre PC-2 y PC-1. Si esto no hubiese sido un mero ping sino una sesión de telnet, PC-3 podría haberse enterado del nombre de usuario y la contraseña de la persona que accediese desde PC-2 a PC-1. De ahí la importancia de cifrar las sesiones de terminal mediante SSH.

Para apagar las máquinas virtuales, se puede hacer un halt desde dentro de cada una ellas o bien con vhalt desde nuestra línea de comandos real:

dante@Hades:~/netkit_labs$ vhalt PC-1 Halting virtual machine "PC-1" (PID 29271) owned by dante [.... ] dante@Hades:~/netkit_labs$ vhalt PC-2 Halting virtual machine "PC-2" (PID 30824) owned by dante [.... ] dante@Hades:~/netkit_labs$ vhalt PC-3 Halting virtual machine "PC-3" (PID 28568) owned by dante [.... ] dante@Hades:~/netkit_labs$

Si posteriormente quisiéramos reiniciar las máquinas sólo tendríamos que usar el comando vstart (siempre y cuando no hayamos borrado los fichero .disk). Por ejemplo, para arrancar PC-1 haríamos: vstart PC-1

Bueno, no está mal para empezar, hemos montado un experimento con tres PCs y un hub sin tener ninguna de las cuatro cosas ... más no se puede pedir, ¿o sí?. En mi próximo (o proximos) artículo profundizaré en las posibilidades de Netkit para elaborar experimentos más complejos e interesantes.


Actualización 2010-01-01: En la nueva versión de Netkit han cambiado el sistema de ficheros (la imagen de Debian con la que se carga cada una de la máquinas virtuales) a una de 10 GB. Afortunadamente, si usamos particiones con sistemas de ficheros serios (ext, ReiserFS, XFS, JFS o NTFS) no hay que preocuparse ya que lo tratará como un fichero sparse y no ocupará ni una fracción de ese tamaño. De lo único que habrá que asegurarse es de que al descomprimir los ficheros descargados de la web de Netkit en /user/share/netkit se utilice la orden: sudo tar -xjSf siendo la S precisamente para tratar los ficheros como sparse.

11 septiembre 2008

Sitios donde aprender programación en ensamblador


Reconozco que la programación en ensamblador es una de mis asignaturas pendientes. Conocerla resulta primordial para investigar temas como las vulnerabilidades de desbordamiento de pila o el desarrollo de shellcodes que las exploten. Sin embargo todos los tutoriales que he encontrado hasta el momento sobre ensamblador o son extremadamente complejos o son inconexos y desactualizados.

Por fortuna, en una de las listas de correo a las que estoy apuntado se han mencionado dos direcciones web que ofrecen interesantes posibilidades:
  • La web del Doctor Paul Carter: Ofrece un tutorial sobre ensamblador bastante completo, didáctico, actualizado, en formato PDF, multiplataforma y con una versión traducida al español.
  • La web de Iczelion: A primera vista parece centrada exclusivamente en el desarrollo en ensamblador para Windows. Puede resultar interesante para encontrar un IDE adecuado para esta plataforma.