Una herramienta que suelo usar habitualmente para probar técnicas de seguridad en redes es NETinVM (NETwork IN VirtualMachine), una máquina virtual SuSe que contiene en su interior una serie de switches virtuales y máquinas UML que forman una red virtual al estilo de la que podríamos encontrar en cualquier red con su segmento «Internet», su segmento Interno, su DMZ, su firewall y todo lo demás.
Sus autores, mi ex-profesor de sistemas operativos de la universidad, Carlos Pérez y su hermano David Pérez, al que todos conoceréis como GSE del SANS y co-fundador de la empresa Taddong.
El esquema que por defecto viene configurado en la máquina virtual es el siguiente:
En total, por defecto, tenemos 7 máquinas UML separadas en tres redes. Tanto las máquinas de la DMZ como las externas presentan algunos servicios típicos como servicios web o similares, con el fin de que podamos realizar todo tipo de pruebas. También tenemos un firewall con iptables con el que podremos realizar pruebas de todo tipo, y que tiene pre-instalado un Snort que puede ser utilizado para probar a crear nuevas reglas que creemos y ver que tal funciona la detección. Además, las máquinas virtuales son Debian, por lo que podemos instalar lo que necesitemos en ellas, incluso a través de aptitude.
El funcionamiento de la máquina está perfectamente explicado en la documentación oficial. No obstante, hay algunas modificaciones que podemos hacer sobre NETinVM que consideramos interesantes:
Elección de máquinas virtuales
Para la gran mayoría de las pruebas que vayamos a realizar, probablemente las 7 máquinas UML que se arrancan por defecto sean innecesarias y simplemente van a consumirnos recursos, así que resulta muy interesante poder elegir cuales de estas máquinas UML queremos que arranquen, y cuales no.
Para ello, editaremos el fichero /home/user1/uml/bin/uml_run_all.sh que es el encargado de lanzar todas las máquinas, y nos encontramos lo siguiente:
uml.sh -d 4 fw
uml.sh -d 2 a ext
uml.sh -d 3 b ext
uml.sh -d 8 a int
uml.sh -d 7 b int
uml.sh -d 5 a dmz
uml.sh -d 6 b dmz
Como podemos ver, el script es sencillo, hay llamadas a otro script uml.sh que es el encargado de lanzar cada una de las máquinas virtuales de forma individual. El parámetro -d nos deja elegir el escritorio de entre los 8 que tiene la máquina virtual SuSe en el que queremos que la máquina UML se situe, mientras que en el resto de parámetros elegimos la red en la que se encontrará (ext, int, dmz) y cual de las máquinas de esa red queremos arrancar.
Por poner un ejemplo, imaginad que queremos realizar una prueba de MitM en LAN, con lo que solo necesitamos 2 máquinas en una LAN y 1 máquina de otra LAN a la que conectar para hacer la prueba, y por supuesto el firewall, así que podríamos reducir la cantidad de máquinas arrancadas cambiando el fichero de la siguiente manera con lo que ahorramos muchos recursos:
uml.sh -d 4 fw
uml.sh -d 2 a ext
uml.sh -d 8 a int
uml.sh -d 7 b int
Para otro tipo de ejercicios esta configuración podría (y debería) cambiar, por supuesto.
Memoria de cada máquina UML
Otro de los parámetros que podemos querer variar es la memoria que es asignada a cada máquina UML, ya que podemos encontrarnos con que una de las máquinas no realiza realmente ninguna función y por tanto no necesita mucho, y que por contra otras requieren utilizar múltiples herramientas que funcionarían de una forma mucho más ágil con un poquito más de memoria.
Para hacerlo, la manera más fácil es realizar una copia del fichero /home/user1/uml/bin/uml.sh a, por ejemplo, /home/user1/uml/bin/uml512.sh (lo lógico es poner un nombre representativo de la cantidad de memoria que le vamos a asignar) y editar este último fichero, en el que podremos leer las siguientes lineas:
# Virtual machine configuration
XTERM=terminal.sh
MEM=128M
A simple vista podemos ver que cambiando el valor de la variable MEM podemos cambiar la cantidad de memoria asignada a la máquina. En nuestro caso, lo cambiamos por 512M y guardamos los cambios.
Por último, tenemos que elegir cual de las máquinas que arrancamos va a tener esta configuración «especial», y eso lo tendremos que hacer editando uml_run_all.sh, tal y como hacíamos antes, y cambiar la llamada a uml.sh por uml512.sh en aquellas máquinas a las que queramos aumentarlas la memoria. Por ejemplo, en un caso en el que queramos hacer pruebas con el Snort del firewall podríamos querer disponer en esta máquina de más memoria.
uml512.sh -d 4 fw
uml.sh -d 2 a ext
uml.sh -d 8 a int
Por supuesto, a la hora de asignar una memoria distinta a las máquinas, tened en cuenta que la memoria asignada a la máquina virtual SuSe que lo contiene todo la tenga disponible, sino tendréis que aumentar ésta también.
Switches en modo Switch o Hub
Por defecto, imagino que para facilitar los ejercicios de sniffing, los switches virtuales se encuentran configurados en modo hub, por lo que todo el tráfico que envía cada una de las máquinas UML llega al resto de máquinas que se encuentran en la misma LAN. Esto, sin embargo, puede ser un problema si queremos realizar técnicas de MitM como por ejemplo ARP-Spoofing, ya que nos vemos el comportamiento real que tendría un switch.
Para hacer que los switches funcionen de su forma habitual, tendremos que editar el fichero /home/user1/uml/bin/uml_switch.sh y buscar la cadena «hub», con lo que nos encontraremos con la siguiente linea:
COMMAND=»$UML_SWITCH -unix $SOCKET -hub -tap $TAP >/dev/null 2>&1″
Para cambiar el funcionamiento de hub a switch solo tenemos que eliminar la opción -hub de la llamada y guardar los cambios, y así la siguiente vez que arranquemos todos los switches funcionarán de la manera esperada
Via: http://www.pentester.es
