18 julio 2012

Securizando un entorno de máquinas virtuales con Virtualbox

La virtualización ha dejado de ser únicamente una moda, y, con los agravantes de los recortes por la crisis y la conciencia ecológica, se ha convertido en una forma de vida para todo tipo de organizaciones. Por esto, la seguridad ha tenido que reinventarse para poder adaptar conceptos como la correcta segmentación de redes, que anteriormente se hacía mediante diversas interfaces de red, VLANs y cables físicos conectados a una maraña de servidores, para definir políticas de acceso entre máquinas virtuales que corren en un mismo servidor físico.

Dentro de los sistemas de virtualización, hay una amplia elección profesional para elegir, por lo que las organizaciones que dispongan de recursos económicos para ello, pueden acudir a sus supermercado de productos de seguridad favorito, y hacerse con costosas licencias para crear entornos virtuales. En general, estas plataformas profesionales, permiten definir redes virtuales diferenciadas con políticas de seguridad que especifican el tráfico permitido entre ellas.

Como he dicho antes, para una organización más humilde o alguien que esté empezando una aventura empresarial (que las hay, incluso en España en 2012), la solución libre Virtualbox puede cubrir de sobra las necesidades de virtualización.  

Desde el prisma de un purista de la seguridad, tal cual explico en mi curso de Buenas Prácticas de Seguridad en Entornos Corporativos, el primer paso, para segmentar las redes que existirán en una organización, es identificar los diferentes servidores/servicios para decidir su distribución. Aquellos que necesiten tener una puerta por la que entre tráfico desde Internet, deberá ir en una DMZ de servicios públicos o frontend. La ubicación de los servidores que nutren estas aplicaciones públicas deben ir en una red diferente y protegida, o de backend. El tráfico a permitir entre todas estas redes habrá de ser el justo y necesario para evitar exposiciones de servicios/máquinas por error. Más o menos como se puede ver en el dibujo de abajo, y siguiendo los consejos que ya explicamos en "Cómo diseñar una política de cortafuegos"






"Bueno vale, después de la clase de pizarra que nos has soltado… cuéntanos esto del Virtualbox"

El problema de VirtualBox es que no dispone de una consola remota como tal, con la que gestionar las máquinas virtuales y con la que definir diferentes redes virtuales, así como asignar políticas de seguridad, por lo que habrá que inventarse algo por debajo, que supla esta carencia.

Partimos del caso de una organización pequeña en que disponemos de una máquina Linux, con recursos suficientes de RAM y disco duro, en la que instalaremos Virtualbox. Esta máquina dispone de conectividad a Internet (porque esté conectada al router ADSL o a una ONT de fibra óptica), y quizá conexión con una red LAN o wireless. Supongamos entonces que la máquina dispone únicamente de un par de interfaces físicos de red: uno conectado hacia Internet y otro hacia una red privada. 

Vamos a crear dos nuevas redes que permitan unir servidores de dos tipos: de frontend y de backend. Para ello, Linux provee de diferentes herramientas que permiten crear interfaces virtuales. En este caso vamos a definir dichos interfaces virtuales como tipo TAP [http://en.wikipedia.org/wiki/TUN/TAP]. 

Para ello, haremos, por cada red que queramos definir los siguientes pasos:



Si necesitamos más interfaces virtuales, repetiremos las dos líneas "tunctl" e "ifconfig" con un nuevo intefaz virtual y el direccionamiento a asignar a sucesivos tap1, tap2, etc,…

Se supone que esto crea un interfaz de red virtual "persistente" asignado al uid 0 (si ejecutamos como root la orden, claro). Sin embargo, deberemos repetir los pasos de la definición de interfaces cada vez que arranque la máquina física. Para ello crearemos un script, en el /etc/rcX.d que corresponda, para que se definan los interfaces de red ANTES de que arranquen las máquinas virtuales. Es decir, no lo hagáis en el /etc/rc.local, que como sabréis, se ejecuta como último script de los de arranque.

Lo siguiente que tenemos que hacer es definir el interfaz de red de la máquina virtual que quedamos, como "Bridged Adapter" y seleccionaremos el interfaz "tap" que hayamos definido para esa red. 



Repetiremos este proceso para todas las máquinas virtuales según nuestras necesidades de pertenecer a la DMZ pública o a la privada. El direccionamiento de red a asignar a las máquinas virtuales de ambas redes, deberá pertenecer al mismo que tiene cada interfaz virtual TAP. En el caso del ejemplo, deberían pertenecer al rango 192.168.5.0/24. 

De esta manera, las máquinas de la DMZ pública, que ofrezcan servicios a Internet, quedarán en una DMZ virtual y las de backend en otra.

Viajando a la paranoia extrema

"Oye, ¿y si me comprometen una máquina, no podrían saltar a otra de la misma red?" Pues la respuesta es "puede". Si te comprometen una máquina virtual, las posibilidades son las mismas que en una red DMZ física, por lo que si la seguridad de cada una de las máquinas, a nivel individual, no ha sido tenido en cuenta convenientemente, podemos tener un problema mayor.

Para reforzar este posible caso, si queremos, podemos darle una vuelta de tuerca más, haciendo incluso que, la opción de máquinas virtuales sea más segura que la opción de redes físicas. Para ello, lo que haremos, en vez de definir un interfaz virtual por cada red, será crear un interfaz TAP por cada máquina virtual. Asignaremos desde el panel de Virtualbox el interfaz TAP, en modo bridge a cada máquina y utilizaremos subnetting para optimizar el espacio de direcciones IP.

Si antes usábamos una red con máscara 24 (255.255.255.0), ahora usaremos una máscara 30 (255.255.255.252). Los 30 bits de máscara nos permite 4 direcciones IP: la primera es la dirección de red, la última el broadcast de esa red y las otras dos son las "usables" para asignar a dos interfaces de red, creando una conexión Punto-a-Punto. Una será para la máquina virtual que montaremos en esa red, y otra para el interfaz tapX de la máquina física (que actuará de default gateway para la máquina virtual).

En el caso de 192.168.5.0/30 por ejemplo, tendríamos la 192.168.5.0 como dirección de red, la 192.168.5.3 como dirección de broadcast y la 192.168.5.1 y 192.168.5.2 como direcciones asignables. Si os liáis con el subnetting, podéis usar este enlace para el cálculo online de direcciones IP



Así, para acceder a otras máquinas, habrá que pasar sí o sí, a través del firewall… por lo que una política de seguridad estricta, asegurará, que si nos comprometen cualquiera de las máquinas virtuales, no será sencillo saltar a una "de las de al lado". Desde el punto de vista de la gestión de máquinas virtuales puede llegar a ser más lioso, pero como siempre, seguridad y usabilidad, se llevan mal. Este esquema es lo más parecido a implementar las Private VLAN que permite la electrónica de red Cisco.

Y ahora me diréis… ¿y si te comprometen la máquina física desde el propio acceso a Internet?  Pues lleváis razón. Quien tenga acceso a la máquina física puede acceder a los datos de todos los servidores contenidos en ella.

De vosotros dependerá securizar convenientemente esa máquina física, o incluso crear una máquina virtual nueva, que sea la que haga las labores de firewall, con un interfaz de red asignado (bridge) a cada una de las nuevas redes que hemos creado.

Así, la máquina física, si logramos que no tenga servicios de ningún tipo hacia el exterior, será un bastión muy difícil de vulnerar.

8 comments :

Madrikeka dijo...

Me ha encantado el post, hace mucho que no toco virtualbox; tendré que recuperar un antiguo PC para probar estas cosillas!!
Muchas gracias por la explicación!!

SaulVerdal dijo...

Post de escuela!!! :-D estoy dando un curso de Ubuntu y usamos Virtualbox para virtualizar S.O. Usaré este post como una lección más de dicho curso.
Gracias.

SaulVerdal dijo...

Sé quen en este blog habeis hablado muuucho de que certificacíon de seguridad estudiar o cual otra. Yo ciertamente debo de ser algo lerdo por que aún no lo tengo claro. Y este post me viene fenomenal, al hilo de preguntar (además de por mi cuenta) dónde puedo aprender a hacer cosas así?? no hace mucho he terminado la carrera de Ing. Informática y este mundo me atrae muuucho, procuro estudiar todo lo que escribir aquí, lo que escribe Chema, elhacker,... pero me gustaria tener una certificación.

Gracias.

Lorenzo_Martinez dijo...

Pues ya sabes, si te pierdes en algo, levanta la mano! :D

Lorenzo_Martinez dijo...

Hola Saúl, te recomiendo encarecidamente estos posts http://www.securitybydefault.com/2009/05/certificaciones-de-seguridad.html y http://www.securitybydefault.com/2011/02/que-buscamos-en-una-certificacion-de.html que esperemos que te sirvan para orientarte... Saludos

☠ Dani Martinez ☠ dijo...

Mola el post Lorenzo!! No se si has intentado usar PHPVirtualBox, es un proyecto que te ayuda a montar todo esto con la propia configuración de VBox en remoto y de con cliente gráfico (como PROXMOX para KVM y XEN), creando 2 maquinas en "host-only" (A apache x ejemplo - B MySQL x ejemplo) y conectándolas a una interfaz que crees nueva desde el mismo VBox, todo esto gestionando el direccionamiento y el trafico con el exterior con IP-Tables, yo tengo un entorno así en una maquina remota y es cojonudo. En el anfitrión dejas a la escucha el apache por el 80 con el PHPVirtualBox, SOLO por la interfaz que crea la VPN x ejemplo tun0 de forma que accedas a la configuración solo conectándote a la VPN. De esta forma el sistema anfitrión hace de firewall. La pega es que confías toda la configuración de VLAN's (si las quisieras crear), interfaces y demás a cargo de Virtual Box en vez de a mano como comentas tu, para cacharrear es más que suficiente, y en PRE también.


Saludos y espero no haberme columpiado más que Heidi a Clara

Manuel dijo...

Hola, interesante post.
Yo me decantaría por crear una máquina virtual nueva ejerciendo funcionalidades de firewall con una tarjeta en modo bridge para salida/acceso a internet y otras dos en modo 'red interna'. Crearía una red interna para la DMZ pública, otra para la DMZ interna y el firewall con una interfaz conectada a la red interna de la DMZ pública y otra interfaz conectada a la red interna de la DMZ interna. Creo que en esta situación el uso de las redes internas es más sencillo que gestionar las taps.
Saludos

Guillermo dijo...

Tengo un problema con mi servidor en solaris, actualmente el servidor fisico tiene una dirección "10.162.153.129" y en este tengo dos maquinas virtuales con las siguientes direcciones "10.162.153.136" y "10.162.153.137"; accedo a estas por RCDT (putty) lo curioso es que puedo acceder a las dos maquinas virtuales sin problemas pero cuando trato de conectarme al servidor fisico me marca error de conexion, sin embargo desde otro servidor o desde las maquinas virtuales me responde el "ping" incluso me deje acceder al servidor via TELNET.

Ya verifique mi tabla de ruteo
Ya verifique mi archivo hosts
" " " " el netmasks
La interfaz y la submascara todo correcto
Reinicie la network
Verifique el archivo defaultrouter


y sigo con el mismo problema alguna sugerencia?