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:

Data provided by Pastebin.com - Download Raw - See Original

1. modprobe tun   #Cargaremos el driver "tun"
2. tunctl -t tap0 #Creamos el interfaz tap0
3. ifconfig tap0 192.168.5.1 netmask 255.255.255.0 up #Asignamos direccionamiento de red al interfaz y lo levantamos

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.

 

Fuente:

http://www.securitybydefault.com/2012/07/securizando-un-entorno-de-maquinas.html