¿Como funciona el servicio de firewall en VMware NSX?

Hola, en esta nota de hoy explicaré como funciona el servicio de firewall en VMware NSX y los servicios de firewall (cortafuegos) que ofrece VMware NSX.

El servicio de filtrado siempre fue un problema de difícil solución en el entorno virtual con las alternativas tradicionales, es decir con los firewall de borde, porque estos a lo sumo nos permitían proteger las VMs de una DMZ (zona desmilitarizada) siempre y cuando estuvieran un host aislado del resto de las VMs.

Eso incrementaba el coste, y en muchos casos era ineficiente por el consumo de procesador, memoria, disco que solo podían ser aprovechados por una limitada cantidad de VMs si queríamos cumplir con las auditorías de cualquier consultor de seguridad.

Por otro lado, se planteaba el problema del control de tráfico entre las VMs internas, que podían mantenerse separadas por áreas o departamentos mediante VLANs, pero que si necesitábamos controlar el tráfico dentro de una misma VLAN era prácticamente imposible. Las privates VLANs nunca han tenido mucho éxito y no tienen la granularidad de permitir o denegar el tráfico a nivel de aplicación, así que tampoco podíamos contar con ellas.

Las primeras respuestas a este problema fueron vShield (posteriormente llamado vCenter Network and Security 5.1 o vCNS) por parte de VMware y el Cisco Security Gateway (CSG) y posteriormente el ASA 1000v, que requerían tener instalado previamente el Nexus 1000v.

Ahora el NSX incluye los servicios heredados y mejorados de la solución de seguridad de VMware. El vShield Manager es reemplazado por el NSX Manager, el vCNS Edge (anteriormente vShield Edge) que ahora es el Edge Service Gateway y los demás componentes como el vShield App, las VXLANs, o los vCNS Virtual Wires reemplazado por el NSX Logical Switch.

El servicio de filtrado en el Edge Service Gateway es probablemente el más sencillo de entender, porque se trata de la misma VM que ofrece los servicios de routing entrante y saliente que he explicado en mi nota anterior (El servicio de routing en el NSX) y que permite establecer reglas de filtrado de nivel 3 y 4 de tipo stateful. Es el mismo concepto que encontramos en los apliance tradicionales pero en formato virtual.

Para aquellos que no están familiarizados con la tecnología de firewall, stateful significa que todo el tráfico saliente crea una regla automática en el cortafuego que permite que el tráfico que regresa pueda pasar.

Esta capacidad no solo la encontramos disponible para el tráfico Norte/Sur, sino también para el tráfico Este/Oeste en el firewall distribuido.

Quizás recuerden de notas anteriores que a nivel del kernel en el ESXi el NSX instala un componente que llamaremos kernel-embedded firewall. Se trata de un VIB que controla que el tráfico entrante o saliente de cada vNIC en cada VM para que cumpla con las políticas de filtrado establecidas a nivel del Logical Distributed Router, aunque el servicio de Firewall es independiente del de routing, que es controlado por otro agente VIB distinto.

El componente se comporta como un fail closed firewall, lo que significa que si llegara a fallar por motivos de saturación o falta de memoria su estado evitaría cualquier tráfico entrante o saliente a las VMs.

Por supuesto que el servicio es compatible con vMotion, por lo tanto independiente del host donde se ejecuta la VM soportando migraciones manuales o automáticas gracias al DRS.

Las reglas las configuramos desde el vSphere Web Client, o bien a través de REST APIs desde otra herramienta de más alto nivel, como el vCAC, para pasarlas al VMware NSX Manager quien las distribuye directamente a los Host ESXi. El NSX Controller no interviene en las funciones del firewall distribuido.

Las reglas se aplican antes de que el tráfico saliente sea encapsulado en una trama VXLAN, o después de de haber sido desencapsulado para el tráfico entrante.

Por supuesto que las reglas pueden contener direcciones IP (v4 y v6) y máscaras, pero también objetos del inventario, usuarios y grupos, objetos contenedores (Clusters, DataCenter, PortGroups, VXLAN), protocolos, vNICs, nombres de VMs, tags u otros atributos, lo que permite hacer reglas mucho más intuitivas y flexibles.

En la figura del encabezado de este post, puedes ver la interface que permite establecer reglas generales (nivel 3 y 4). El botón Ethernet permite en cambio definir reglas de nivel 2.

Las reglas se pueden agrupar por secciones, lo que es muy conveniente para diferenciar políticas para distintos departamentos o tiers o tenants.

En la siguiente figura podemos ver la sección de ingeniería, la de HR y otra llamada Default.

Las acciones que acompañan a las reglas son permitir, denegar. Las reglas se pueden aplicar a objetos específicos del inventario.

El firewall también soporta grupos dinámicos de elementos que cumplan con un criterio específico, por ejemplo que el nombre comience con RRHH*, o que el Sistema Operativo sea Windows 7, etc.

El control de tráfico se complementa con el servicio de monitorización de flujos (flow monitor) que permite analizar el tratamiento del tráfico (permitido o denegado) e incluso a partir del reporte crear o modificar las reglas del firewall, tal como lo muestra la siguiente figura.

El servicio de firewall permite que las organizaciones puedan aplicar las políticas de seguridad necesarias para cumplir con las regulaciones de cada industria.

Espero que esta nota les haya permitido comprender como el NSX es capaz de controlar cualquier tipo de tráfico asociado con las VMs. Los espero en mi próxima nota para seguir hablando sobre los servicios que ofrece el NSX.

Gracias por leer nuestro blog, participar y compartir.