¿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:

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:

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!