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:
modprobe tun #Cargaremos el driver "tun"
tunctl -t tap0 #Creamos el interfaz tap0
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
Entradas
