¿Tráfico legítimo es bloqueado por el NSX Distributed Firewall?

Recientemente tuve la oportunidad de participar en un proyecto de microsegmentación con VMware NSX 6.2 en el que vi “saltar” los flags TCP del libro de texto a la realidad y además pude evidenciar que realmente el Distributed Firewall de NSX es stateful (bueno, no es que no lo creyese, pero verlo es diferente).

Pues bien, para tener visibilidad de éstos eventos lo primero es configurar la regla de DFW (ya sea creada directamente allí o a través de Service Composer) para que genere logs:

image

En el instante en que se guarden los cambios, los logs empezarán a redirigirse hacia la entidad externa de syslog. Dado que toda edición de NSX cuenta con vRealize Log Insight dentro del paquete de licencias y que el Content Pack de NSX para Log Insight da cuenta de una integración muy cercana entre los dos, puede ser quizá la mejor opción para el análisis de eventos de NSX el utilizar Log Insight, como lo veremos en éste caso.

El three-way handshake revisitado

Al iniciar con el análisis de los eventos generados para la regla default de una de las secciones que había creado para éste proyecto, empezaron a surgir conexiones cuyas características no daban para ser capturadas por la regla default sino por una de las reglas definidas a nivel superior. Por ejemplo, tendría una regla de éste estilo:

IP origen IP destino Puerto destino Acción
ANY 192.168.0.0/24 88 (TCP) ALLOW
ANY 192.168.0.0/24 ANY BLOCK

Sin embargo veía múltiples mensajes en los logs con éste tipo de información:

2017-03-03T16:22:22.313Z ESXi-host dfwpktlogs: 25833 INET match PASS domain-c8235/1024 IN 40 TCP 10.22.131.45/51495->192.168.0.10/88 RA

Veamos,

IP origen: no importa

IP destino: hace parte del rango definido en la regla

Puerto destino: 88 TCP, permitido

Entonces, ¿por qué lo habría de capturar la regla default?

Claro, en ése momento la regla por defecto estaba configurada para permitir todo (por ello el PASS) pero cuando se habilitara la acción de bloquear (como todo regla default en un firewall usando enfoque positivo) estos paquetes aparentemente legítimos empezarían a bloquearse.

La respuesta vino al revisar nuevamente la teoría. Dentro de la trama (frame) TCP estándar hay espacio para 6 posibles banderas (flags) –explicadas brevemente aquí– pero un firewall de tipo stateful (es decir, que mantiene registro de cada sesión/conexión y mantiene la inspección hasta que las sesión/conexión se cierre) va a cotejar un intento de conexión contra las reglas definidas siempre y cuando contenga el flag SYN, que es con el que se establece la conexión:

Image result for tcp 3 way handshake flags

Imagen tomada de resources.infosecinstitute.com

Sin embargo y como una de las ventajas precisamente de los firewall stateful, éste no permitirá un nuevo intento de conexión con la misma combinación de origen/destino mientras esté activa la conexión ya establecida (evitando session hijacking, que es a lo que estaría expuesto un firewall stateless).

Así que, visitando nuevamente nuestro críptico mensaje de log:

TCP 10.22.131.45/51495->192.168.0.10/88 RA

La comunicación se estableció en las siguientes etapas:

1. El equipo 10.22.131.45 solicita una sesión a la IP 192.168.0.10 y le solicita que se establezca por el puerto 88 (usando SOCKET API)

2. El Distributed Firewall validó esa conexión haciendo match con la regla configurada y por lo tanto la permitió pues estaba configurada para ello

3. El host destino (192.168.0.10) respondió al origen con los flags SYN+ACK para confirmar la recepción de la solicitud y establecer la sesión, pero lo envió por el puerto 51495 TCP

4. Ante esa respuesta, el origen (10.22.131.45) respondió con RST+ACK (de ahí el “RA” en los logs!) para rechazar la solicitud pues el puerto no está abierto. Esto no cierra la conexión, pero hace que el host 192.168.0.10 tenga que enviar su SYN+ACK por un puerto abierto según le informe el destino.

La razón por la que ese paquete con flags RST+ACK no es permitido por el DFW es la prueba reina sobre el caracter stateful del mismo: no permitió una solicitud de (re) establecer la sesión con la misma combinación origen destino pues la conexión ya se había establecido en el punto 3 (desde el punto de vista del firewall).

De manera que, por esa misma vía, el monitoreo de logs del DFW puede enfocarse en los paquetes con flag “S” y no en todo lo demás pues sólo corresponde al funcionamiento saludable y normal de TCP.

¿Por qué el destino enviaría una respuesta SYN+ACK por un puerto tan exótico? Esto depende enteramente de la aplicación, en éste caso se trataba de Kerberos y da luces sobre el desafío que implica traer microsegmentación a un mundo de aplicaciones que no contemplaron la posibilidad de que existiese un firewall este-oeste en la red.

Espero les sea de utilidad

Saludos!

Proxy ARP en VMware NSX: funcionamiento y consideraciones (2/2)

Continuando el tema que inicié hace un par de semanas, en éste post exploraremos un poco otro aspecto de la implementación de proxy ARP en la arquitectura de NSX, particularmente en la interacción entre redes VXLAN y redes “físicas” tradicionales (VLANs).

Hablaremos del DLR (Distributed Logical Router) que ejecuta, precisamente, funciones de enrutamiento desde el kernel space de los ESXi participantes del entorno NSX. Efectivamente y, como su nombre lo indica, es un router que está distribuido a lo largo de todos los hosts, todos ellos tienen el mismo router y tanto el plano de control como el de datos están distribuidos para no generar puntos únicos de falla. Como todo router lógico, sus interfaces también son lógicas, y son conocidas como LIFs (Logical Interfaces, –¿qué mas podrían ser? Winking smile ). Si requiero interconectar dos segmentos VXLAN, eso consume dos (2) LIFs y el enrutamiento se hace posible inmediatamente a lo largo de todos los hosts.

NSX 6.2 habilita, en éste sentido, un nuevo caso de uso: enrutamiento entre una red VXLAN y una red física (si, de las de VLAN). Como sabrán, la primera vez que se establezca dicha sesión, indefectiblemente tendrá que ocurrir una consulta ARP (“Tengo una IP, ¿donde está su MAC?) pero, ¿ésto significa que todos los hosts potencialmente estarán ejecutando ARP broadcast? Si la respuesta fuese si, no habría razón para éste post sino para hacer un Feature Request. Pero afortunadamente la respuesta es no, y es aquí donde el DRL hace uso de la Designated Instance.

Veamos de qué se trata.

He tomado prestado éste diagrama del buen Brad Hedlund y su post original al respecto del DLR con redes físicas. No teman, que ésto no es sólo una traducción, aportaré un enfoque diferente.

Figura 1. Entorno NSX con DLR conectado a red física. Tomado de bradhedlund.com

¿Se fijan cómo no hay hosts ESXi en éste diagrama? Bueno, para propósitos de claridad resulta útil que así sea, lo importante es que esa capa de NSX DLR está distribuida a lo largo de múltiples hosts y las tres LIF que utiliza están presentes en todos y cada uno de los hosts, hasta ahora todos son iguales.

1. La VM1 (que se ejecuta, digamos, en el host ESX1) requiere comunicarse con el equipo PH1 (quizá el proverbial ejemplo del servidor físico de base de datos) por primera vez, de manera que lanza una consulta ARP. La IP de PH1 es 192.168.0.100, por citar un ejemplo.

2. ¿Qué hará el host ESX1?.

Aquí nos detenemos un momento. Hay varias cosas que han sucedido antes que entráramos a la escena, y éstas son:

  • a. El controller cluster ha elegido a uno de los hosts ESXi para asignarle el rol de Designated Instance. El receptor de semejante honor tiene la responsabilidad de ejecutar todas las consultas ARP que vayan hacia/desde la red física y responderlas con su propia MAC (pMAC para ser preciso, que es una suerte de MAC address por LIF única por host). Ajá! allí estás proxy ARP. Curiosamente sólamente la documentación oficial se refiere al DI como un proxy ARP, y efectivamente lo es. En éste caso, vamos  a imaginar que el controller cluster eligió al host ESX3 para ser el DI de ésta red física específica.

b. El dispositivo físico (ya sea el servidor o router) cuenta con una ruta hacia la red de VXLAN cuyo next hop ó siguiente salto es la IP de la LIF del host ESX3 (la Designated Instance). Dicho en otras palabras, todo ésto es muy interesante pero no va a funcionar si hacemos tanto esfuerzo en enviar un paquete que luego no sabe cómo regresar.

— Dadas éstas consideraciones, podemos continuar:

El host ESX3 va a capturar la legítima consulta ARP que hace el ESX1 y, una vez tenga la respuesta va a actualizar su tabla ARP con una entrada que se vé así

IP Address MAC Address
192.168.0.100 (IP PH1) pMAC ESX3

3. Inmediatamente, el controller cluster publica la nueva entrada a todos los hosts en el clúster

4. Contrario a lo que podría pensarse, una vez que el paquete alcanza su destino, no retorna necesariamente por el ESX3 (Designated Instance). Si la VM1 está en el ESX1, entonces el paquete retornará directamente por el LIF3 del ESX1. SI la VM1 se mueve al host ESX3, entonces el paquete retornará por allí, pero sólo se debe a que la VM está presente allí. En otras palabras, el Designated Instance no hace parte de la ruta de regreso lo cual optimiza el enrutamiento de manera efectiva.

Como discutimos en la parte 1 de éste post, uno de los mayores argumentos contra proxy ARP es que crea una vulnerabilidad para ataques de tipo Man in the middle: si capturas al proxy ARP, entonces podrás falsificar toda comunicación de capa 2 y hacia arriba. Sin embargo NSX 6.2 incorpora un control para éste riesgo con el establecimiento de comunicación cifrada por SSL entre el controller cluster y los hosts ESXi; éste es el canal donde se transmite información sensible, como por ejemplo el host que ha sido elegido como Designated Instance.

Conclusiones

Utilizando funciones de proxy ARP, NSX puede entregar routing optimizado entre entornos virtuales y físicos así como una importante reducción en el tráfico broadcast debido a consultas ARP, lo cual agrega a los ya numerosos beneficios de la virtualización de redes.

Los comentarios son bienvenidos, saludos!

Proxy ARP en VMware NSX: funcionamiento y consideraciones (Parte 1/2)

Proxy ARP es un mecanismo utilizado en redes y seguridad desde hace décadas. Consiste en configurar un dispositivo de capa 3 (típicamente un router) para que responda a las solicitudes de ARP (traducción de IP a MAC address) con su propia MAC Address, evitando que el dispositivo que hizo la solicitud tenga que salir de la red para hacer la consulta y convirtiéndose, a su vez, en el punto designado por el cual se redirijan (forwarding) las subsiguientes sesiones de comunicación hacia la recién aprendida IP/MAC.

Dicho de otro modo, si dispositivos conectados en subredes diferentes requieren conectarse entre sí van a necesitar un router que actúe ademas como el default gateway para cada subred, esto es Networking 101 o menos para muchos. Pero ¿que pasa si no hay tal dispositivo? ¿Podría insertar un dispositivo que facilite esa comunicación incluso SIN configurar un gateway  para ninguna de las sub-redes? Esto es precisamente para lo que hace casi 30 años se concibió ProxyARP documentado inicialmente en el RFC 1027 (lectura interesante)

Utilidad

  • Introducir ProxyARP en la red no implica cambios en las tablas de enrutamiento de otros dispositivos en la red. Realmente, éste puede ser un beneficio que se pase por alto pero si hablamos de un entorno virtualizado donde es tán fácil crear VMs con múltiples vNICs, y si dicho entorno aun cuenta con un esquema tradicional de VLANs, entonces esas tablas pueden estar llegando a su límite operacional; que es más cercano de lo que pensamos como lo confirma el RFC 5556 (TRILL).
  • Por otro lado, habilita la creación de un modelo de red plana (flat-network) sin intervenir los dispositivos finales que, gracias a ProxyARP, piensan estar directamente conectados con dispositivos en las demás sub-redes. Esto puede habilitar el diseño de una DMZ en la cual los equipos no cuenten con un gateway configurado.

Dificultades

ProxyARP no es nada popular en muchos círculos, algunas de las razones que se esgrimen para ello son:

  • Afecta la confidencialidad de la red más de lo que la beneficia: si un atacante logra hacerse pasar como la MAC address del ARP Proxy (MAC-spoofing) entonces tendrá visibilidad de todo el tráfico de sesiones establecidas así como de consultas ARP.
  • Debido a que los dispositivos (por ejemplo máquinas virtuales) no pueden pasar a otra sub-red sus solicitudes ARP, la presencia del proxy a largo plazo eleva el volúmen de tráfico ARP que tiene que ir y regresar a la subred.
  • Como si no fuese suficiente, debido a que siempre habría una respuesta a una solicitud ARP, el dispositivo que originó la consulta confía en que efectivamente encontró el destino y continuará el envío de paquetes hacia allí. Sin embargo, en ningún punto el proxy verificó que efectivamente pudiese llegar al destino real. Esto crea el llamado efecto hoyo negro, pues se establecerá una “comunicación” que realmente no está llegando a ningún destino y los dispositivos no lo notan.

De aquí en adelante, ¿para qué hablar más de Proxy ARP? ¿Es completamente fallido? ¿Alguien lo sigue utilizando?

Veamos.

Proxy ARP en VMware NSX

Si eres nuevo en NSX, recomiendo ampliamente el webinar de arquitectura desarrollado por ipSpace (el hombre, la leyenda Ivan Pepelnjak)

En NSX, el plano de control es distribuido y el rol le pertenece a un cluster de Controllers (virtual appliances) que aprenden y distribuyen la información de forwarding a todos los VTEPs participando en la red para VXLAN.

Una de las funciones que provee el controller cluster se conoce como “ARP Supression” en la que habilita a los VTEPs instalados en los hosts ESXi para actuar como ARP Proxy cuando una VM hace una solicitud de ARP broadcast para resolver la MAC address de otra VM. Quizá sea más claro con una imagen (tomada de la guía de diseño de NSX-v):

image

Trataré de ampliar lo descrito por la guía de diseño (de otro modo, Google Translator habría sido en vano):

1. La VM1 pregunta “¿Dónde esta la dirección física de ésta dirección IP?”. Eso, en suma, es una solicitud ARP (“dónde ubico la MAC address corrrespondiente con ésta IP address). Normalmente esa amplia pregunta (broadcast) se hace en todo el dominio L2 de la VM, es decir, en su red VXLAN 5001 y, debido a que ésa red atravies múltiples hosts, la consulta se haría sobre múltiples puertos físicos. Esto es lo que tratará de evitar el “ARP supression”.

2. Antes de obedecer ciegamente la solicitud de la VM1 y pasarla a hacer broadcast a lo largo de todos los hosts en el Transport Zone, ESXi-1 le pasa la solicitud al Controller Cluster: “¿Dónde esta la dirección física de ésta dirección IP?”

3. El controller cluster recibe la solicitud. Nota para candidatos a VCIX-NV: el agente que lleva a cábo ésta comunicación se llama netcpa y se comunica con el Controller Cluster a través de un canal SSL establecido en el momento en que se prepara el cluster para NSX.

4. El controller hace lo que cualquier dispositivo L2 haría: consultar su tabla ARP local a ver si tiene ese registro.

5. En caso de contar con la respuesta, se la envía de vuelta al host ESXi-1

6. El host ESXi-1 hace lo que todo dispositivo de L2 en ése caso: recibe el mensaje del plano de control y actualiza su tabla local pero fíjense: lo que guarda en su tabla es la IP y MAC address del VTEP del host ESXI-2 donde se encuentra la VM2, no la información sobre la VM2 específicamente.

7. Aquí viene el truco: ESXi-1 fabrica una respuesta ARP en la cual la MAC address origen no es realmente la MAC de la VM2, sino la del VTEP del ESXi-2 que, de aquí en adelante, actuará como el ARP proxy para ésta comunicación.

Claro está, si en el paso 4 el controller determinó que NO cuenta con ésa entrada, entonces ejecutará el L2 broadcast y cuando tenga una respuesta de la red, actualizará su tabla y le informará el cambio a los hosts ESXi.

¿Qué pasa si la VM es migrada a otro host? En condiciones normales, al ejecutar vMotion ESXi envía, como parte del proceso, un ARP reverso (RARP) para actualizar las entradas ARP, por lo que una nueva comunicación entre VM1 y VM2 (que ahora está en el host ESXi-3) no debe pasar por el proceso de ARP descrito. En todo caso, tener en cuenta lo descrito en este KB, pues podría evitar el funcionamiento del RARP.

En la siguiente entrada, hablaremos más de funcionalidades similares que NSX despliega para la comunicación optimizada entre VXLAN y redes tradicionales basadas en VLAN.

Bienvenidos los comentarios!