Seguro que más de uno de vosotros emplea tecnologías de virtualización Hyper-V en cualquiera de sus versiones. Uno de los aspectos que mas nos preocupa a los administradores de sistemas, o debería, es la seguridad. Conocer en profundidad la arquitectura y componentes de un sistema es necesario para poder hacer un uso correcto de el, en todos los ámbitos, incluido por supuesta la seguridad.
En este artículo no os voy a soltar el típico python para explotar sistemas Hyper-v. Si lo tuviese seguro que lo podría vender por mi jubilación.
Creo recordar que el mayor fallo en cuanto a seguridad en virtualización en sistemas "modernos" fue un fallo descubierto en procesadores 64 bits de Intel en TODOS los hypervisores, pero corría el 2012 y por supuesto que los Vendors actualizaron su implementación para evadir el fallo.
Podemos ampliar esta información:
XEN
MICROSOFT
RED HAT
Curiosamente Vmware no se vio afectado por este fallo.
En este capítulo vamos a hablar de las funcionalidades relacionadas con la seguridad en Hyper-V para fortificar y conocer nuestro hypervisor favorito :-).
Lo más básico es elegir la versión concreta, o mejor dicho, pagarla. Podemos instalar un servidor 2012 hyper-v gratuito, sin interface gráfico, todo por consola Powershell. Sin lugar a duda esta es la opción más segura ya que sumar funciones innecesarias, como pueda ser el GUI aumenta la exposición del servidor y por consecuencia, la posibilidad de que aparezca una nueva vulnerabilidad que nos amargue el día.
El usar la version Core puede ser más seguro a priori, pero sin embargo, añade una capa de complejidad a las operaciones que pueden redundan en fallos de configuración, Por ejemplo, lo que sería crear una regla en el firewall mediante el GUI, algo sencillo, puede ser complicado en Powershell, por lo que hay administradores que prescinden de la funcionalidad...por comodidad...
Podemos ampliar esta perspectiva no solo al GUI, sino a todos los Roles y funciones que podemos instalar en nuestro Hyper-v. Cuanto menos servicios corriendo, menos servicios potencialmente vulnerables.
Uno de las funciones que debemos deshabilitar, en la medida de lo posible, es el tráfico SMB1.0 y anterior. Usado para versiones Nt4, xp y server 2003 es inseguro y permite ataques MiTM, por lo que si ejecutamos:
Get-SmbConnection y no tenemos carpetas compartidas de esa manera, podemos deshablitarlo.
En el caso de tener alguna carpeta conectada por SMB1.0 podemos trazar el equipo que lo usa con:
Get-SmbSession | Select Dialect,ClientComputerName,ClientUserName | ? Dialect -lt 2
Y por último deshabilitarlo con:
Set-SmbServerConfiguration –EnableSMB1Protocol $false
Ya que usamos todos los sistemas modernos xD y empleamos SMB3 vamos a habilitar el cifrado del tráfico (AES-CCM), algo que consumirá ciclos de CPU, pero que aumenta la seguridad para escenarios de Man In the Middle. Si es cierto que consume muchos menos recursos que el tráfico IPSEC. Podemos habilitarlo simplemente en el GUI del servidor de ficheros, en el carpeta compartida.
Una de las características que tenemos que tener en cuenta si ciframos el tráfico SMB3 es que si hay clientes que usan una versión de SMB inferior, la comunicación se realizará con la versión SMB compatible con el cliente, es decir, hace un "downgrade" para esa conexión, con lo que el cifrado se va al carajo.
Podemos comprobar nuestros clientes SMB2 por ejemplo con este comando:
Get-SmbSession | Select Dialect,ClientComputerName,ClientUserName | Where-Object {$_.Dialect –lt 2.00}
En el caso de no tener clientes "delicados" podemos deshabilitarlo por completo, para forzar a usar SMB3, con este comando:
Set-SmbServerConfiguration –EnableSMB1Protocol $false
Como cualquier Windows 2012, podemos usar el Security Compliance Manager disponible de Microsoft para implementar las medidas de seguridad generales del servidor Windows. Puedes ampliar la información aquí o en castellano en el blog de 1GBdeinformación.
Otra de las funciones que debemos configurar es en el caso de usar Replica para nuestro plan de recuperación de desastres, es usar ipsec como método de autenticación basado en certificados, y no kerberos, que implementa el tráfico http sin seguridad.
En el caso de contar con un cluster Hyper-v, todas las máquinas firman las comunicaciones, no las cifran, por lo que podemos emplear cifrado, incrementando notablemente el uso de CPU:
Get-Cluster clusterName | ForEach-Object \\{ $_.SecurityLevel = 2 \\}
Una de las opciones menos usadas por no estar disponible en el GUI es una Access Control List para el switch vitual. Podemos hacer de "firewall" dentro del switch, sin necesidad de enrutamiento interno. Podemos restringir el tráfico de entrada o salida hacia un puerto del switch, representado por la MAC de la VM conectada a el, para implementar la misma lógica que con reglas de firewall, pero dentro de la configuración del switch virtual. Por ejemplo, podemos hacer que un werb server solo se comunica a nivel de red con una máquina virtual con una base de datos, solo por el puerto indicado. Descargamos la red al evitar que los paquetes salgan hacia el router/firewall físico, fuera del switch virtual. Podéis configurar estas reglas con este sencillo manual.
Las recomendaciones de Microsoft respecto al software Anti virus o malware son las de no instalarlo en el host de virtualización, pero entiendo que es por cuestiones de rendimiento y aconsejan su uso en las propias máquinas virtuales. Si en tu caso decides instalar una solución AV en el host, pásate por esta dirección para excluir ciertas rutas. Si quieres conocer las rutas de exclusión recomendadas para otro tipo de servicios, puedes consultar el documento aquí.
Podemos contar con un escenario en el que tenemos en un servidor en la nube, en un vps o similar un host Hyper-V para publicar nuestras aplicaciones web. Para administrar nuestro hypervisor remoto podemos emplear cualquiera de estas configuraciones, pero SIEMPRE bajo una VPN que conecte nuestro host con nuestra sede.
Puede que emplear una vpn permanente en en host "muy expuesto" a Internet no sea del agrado de todo el mundo. Si contamos con una infraestructura PKI en nuestra organización, como vimos aquí mismo 1, 2, 3 podemos emplear autenticación remóta con certificados para Powershell. De esta manera tendremos un túnel al estilo ssh contra nuestra consola PowerShell. En el caso de no contar con servicios PKI podemos hacer uso de TrustedHosts.
Evidentemente habilitar el firewall en el host es algo que ni debería mencionar aquí. Otras opciones interesantes en la configuración de nuestras máquinas virtuales sobre Hyper-V es habilitar la protección contra dhcp y router .
En el caso de usar una cabina o dispositivo de almacenamiento externo, conectado por Iscsi, debemos usar todas las medidas de seguridad que nos ofrezca el fabricante. Por lo general la mayoría de cabinas cuentan con autenticación CHAP basada en usuario y contraseña. Los dispositivos de almacenamiento de gama alta suelen proporcionar tambien cifrado de comunicaciones IPSEC.
El iniciador Iscsi de Windows Server 2012 nos permite usar autenticación mediante RADIUS, pero la verdad es que no he visto nunca una cabina que ofrezca este servicio.
Algunas cabinas solo ofrecen autenticación basada en la configuración de extremos, como un filtrado MAC.
En muchos manuales recomiendan implementar BitLocker como solución de cifrado de disco, pero es algo que requiere mucha procesamiento y la verdad si usas cabinas de almacenamiento SAN, ellas proporcionan seguridad en los datos mediante cifrado, o con la simple virtualización que hacen del almacenamiento.
Si se me ocurren más recomendaciones o medidas iré actualizando el artículo.
Espero que os guste.
Gracias por leerme !!!