Segmentación, firewalls y diseño de flujos permitidos

La segmentación no es un dibujo: es una hipótesis sobre qué puede hablar con qué

Una organización quiere que el servicio de facturación consulte una base de datos, que los administradores puedan operar los servidores y que ningún equipo de usuario pueda iniciar una conexión directa hacia la base. El diagrama parece sencillo: tres cajas, tres colores y un firewall entre ellas. En operación, sin embargo, aparecen una red de gestión fuera del diagrama, una ruta IPv6 que no pasa por el filtro previsto, una regla temporal que precede a la regla de denegación y un proxy que termina una conexión y crea otra. «Está segmentado» describe una intención, no demuestra que esos caminos no existan.

Este capítulo trata la segmentación como diseño y verificación de flujos permitidos. La unidad de análisis no es la etiqueta de una red, sino una relación con origen, destino, servicio, dirección, condición, decisión, propietario y evidencia. Se distinguen zona, segmento, VLAN, VRF y subred; se compara el filtrado stateless, stateful y de proxy; y se sigue el estado de ida y retorno, incluidos los casos asimétricos. El resultado buscado es un claim acotado: qué flujo se permite, en qué punto, bajo qué política y qué rutas alternativas siguen fuera de la observación.

El capítulo usa un caso sintético, Northstar. No es una receta de configuración ni una autorización para probar redes ajenas. Las políticas y direcciones son ilustrativas; las propiedades atribuidas a estándares se citan y se mantienen dentro de su alcance.

Alcanzabilidad no equivale a seguridad.

Cinco palabras que no deben intercambiarse

En este capítulo, zona y segmento son categorías editoriales de diseño, no primitivas universales con una semántica normativa única. Una zona es aquí una agrupación lógica a la que se pretende aplicar una política común de confianza o exposición; puede abarcar varios segmentos físicos. Un segmento es aquí un dominio de conectividad definido por una tecnología o una topología concreta: por ejemplo, un dominio de enlace, un segmento de una red virtual o el tramo entre dos interfaces. Un segmento puede ser pequeño sin tener una política de seguridad independiente. La tabla siguiente es, por tanto, una síntesis editorial: sirve para preguntar qué propiedad aporta cada mecanismo, no para imponer terminología a todos los productos.

Una VLAN (Virtual Local Area Network), dentro del modelo de bridges y VLAN-aware systems de IEEE 802.1Q, clasifica pertenencia y reenvío de tramas mediante información de VLAN, incluido el VLAN Identifier de la etiqueta cuando está presente. Puede delimitar un dominio de broadcast y asociarse a una interfaz de capa 3, pero no autentica por sí sola los hosts ni obliga a que todo tráfico hacia otra VLAN atraviese un firewall dedicado. El trunk, el bridge, una función de routing local o una ruta alternativa pueden cambiar el camino efectivo. IEEE Std 802.1Q-2022, cláusulas 3, 6 y 9

Una subred es un conjunto de direcciones definido por un prefijo y una interpretación de alcanzabilidad IP. Ayuda al host y al router a decidir si un destino es local o requiere un siguiente salto. No es, por sí sola, una frontera de seguridad: dos subredes pueden compartir un dispositivo que reenvía sin la política esperada, y una misma subred puede contener hosts con controles de host diferentes. RFC 4291 define la estructura del identificador de subred en direcciones IPv6 globales; la conclusión de seguridad anterior es un límite editorial, no una garantía del formato de dirección. RFC 4291, §2.5.4

Una VRF (Virtual Routing and Forwarding) mantiene un contexto de routing separado, con sus propias tablas y, según la implementación, interfaces y políticas. RFC 4364 define una VRF en el alcance específico de VPN IP MPLS de proveedor; se usa aquí como fuente primaria de ese concepto, no como especificación universal de toda implementación que emplee el nombre VRF. Separar tablas reduce la conectividad accidental entre dominios, pero no equivale automáticamente a filtrado, autorización o aislamiento físico. Un route leaking, un servicio compartido o un plano de gestión pueden introducir un camino que el diagrama de VRF no muestra. RFC 4364, §3

La distinción práctica es esta:

Desliza horizontalmente para consultar todas las columnas.

Un diseño profesional puede usar los cinco conceptos, pero debe nombrar qué propiedad aporta cada uno y qué control adicional la hace efectiva.

Northstar: escribir la política antes de dibujar reglas

Northstar tiene cuatro grupos: usuarios, aplicacion, datos y gestion. La aplicación publica una API para clientes internos; necesita consultar la base de datos; los administradores operan mediante un bastion de gestión; todos los servidores deben obtener tiempo y resolver nombres; y la salida a internet sólo se permite a través de un proxy registrado. El objetivo no es que cada grupo sea «de confianza», sino que determinados flujos sean posibles y los demás sean detectables o rechazados.

Una matriz mínima evita convertir nombres de segmentos en política implícita:

Desliza horizontalmente para consultar todas las columnas.

La fila no debe usar «TCP 443» como sinónimo de aplicación. Un puerto identifica un punto de multiplexación del transporte; no prueba qué protocolo de aplicación habla, quién está autorizado ni que el flujo llegue al proceso esperado. La política puede usar el puerto como selector de red y exigir además validación TLS, identidad de workload, autorización de aplicación y una condición de tiempo. Si el servicio usa QUIC, una API alternativa o un proxy, la matriz debe describir esos caminos explícitamente.

También conviene registrar el propietario de cada fila y el cambio que la justifica. Una regla sin dueño se vuelve una excepción permanente; una regla sin evidencia de uso no permite saber si sigue siendo necesaria. La matriz es un contrato de diseño, no una fotografía de la configuración actual.

Tres mecanismos de firewall, tres objetos de decisión

El claim queda acotado al punto observado.

Un firewall es un punto o conjunto de puntos que aplica una política sobre tráfico. «Firewall» no nombra una única semántica. El control puede ejecutarse en un router, un host, un appliance, un balanceador, un gateway de aplicación o una función administrada; la decisión depende de la información visible, el estado conservado y la ruta efectiva. NIST SP 800-41 Rev. 1 ofrece una clasificación y recomendaciones de política útiles para este vocabulario, pero es una publicación de 2009 y no una especificación de todos los productos actuales. NIST SP 800-41 Rev. 1, §§2–3

Filtrado stateless

Un filtro stateless decide cada paquete de forma independiente. Puede comparar interfaz, dirección IP, protocolo, puerto, flags, clase de tráfico o cualquier campo disponible en esa capa. Una regla que permite api → datos:5432 debe contemplar el retorno según el diseño: permitir explícitamente los puertos efímeros de respuesta, usar una dirección de regla que represente ambos sentidos o aplicar una política equivalente en el punto de retorno. El filtro no sabe por sí mismo que un paquete de retorno pertenece a una conexión permitida antes.

Stateless no significa débil ni inseguro por definición. Es predecible y puede ser adecuado para controles simples, pero exige expresar toda la relación que se quiere hacer cumplir. Un allow de entrada basado sólo en dirección y puerto puede aceptar un paquete que no corresponde a una sesión legítima; un deny en un enlace puede no cubrir un segundo camino.

Filtrado stateful

Un firewall stateful conserva una asociación de estado, normalmente derivada de un flujo y de la decisión inicial. Cuando la ida crea un estado permitido, el retorno puede aceptarse si coincide con la asociación, el tiempo de vida y la zona o interfaz esperada. El estado no es universal: puede estar en un host, en un nodo, en un cluster, en un balanceador o en un dispositivo que no comparte tablas con su par.

El estado también tiene límites. Expira; puede ser desalojado; puede depender de una inspección parcial; y puede romperse cuando el retorno llega a otro miembro sin replicación. Un paquete con flags compatibles con una entrada no prueba que la aplicación esté autorizada, que el endpoint siga disponible o que el retorno atraviese el mismo camino. Stateful describe una relación de seguimiento, no una garantía de seguridad total.

La asimetría es el caso conductor. Si el SYN de api a datos entra por fw-a, pero el SYN-ACK vuelve por fw-b, fw-b debe conocer el estado o evaluar el retorno mediante una política explícita. Si no, el diseño puede descartar un flujo legítimo. La evidencia debe correlacionar 5-tuple, interfaces, timestamps, estado de ambos dispositivos y cualquier mecanismo de sincronización. Que una ruta exista en la tabla no prueba que el estado se haya aplicado ni que el paquete concreto haya sido transmitido.

Proxy o gateway de aplicación

Un proxy termina una conexión y crea otra. Puede interpretar HTTP, DNS, TLS u otro protocolo, exigir autenticación, normalizar mensajes o aplicar una política basada en identidad y contenido. En ese caso hay dos legs: cliente–proxy y proxy–origen. Un estado permitido en el primer leg no se propaga automáticamente al segundo; el proxy debe construir el nuevo contexto y el origen debe decidir qué identidad acepta.

Reachability, policy match, state y autorización no son sinónimos.

Un gateway de aplicación puede aplicar controles más cercanos a la semántica del servicio, pero no sustituye los controles de red, de host o de aplicación. Si el origen confía en una cabecera añadida por el proxy, la integridad y la autenticidad de esa cabecera son parte del diseño. Si se cifra extremo a extremo a través del proxy, el proxy puede no ver el contenido; si termina TLS, aparecen dos políticas de identidad y dos superficies de observación.

Planos y direcciones: el flujo permitido no vive sólo en el data plane

El data plane reenvía o filtra paquetes y aplica el estado que encuentra en el camino de datos. El control plane aprende o instala rutas, vecinos, políticas y asociaciones que el data plane consultará. El management plane permite administrar dispositivos, recolectar configuración y cambiar reglas. Un diagrama que muestra sólo el data plane puede ocultar que una cuenta de gestión accede a una interfaz distinta, que un controlador programa una excepción o que el estado de un cluster se replica por una red separada.

Hay dos direcciones de seguridad que suelen quedar fuera de la matriz:

• Egress: salidas desde una zona hacia otra red o hacia internet. El diseño debe separar qué capa decide cada propiedad: un control L3/L4 puede seleccionar direcciones, protocolos y puertos; la identidad del workload requiere un vínculo verificable con el principal o proceso; el resolver aplica su política sobre consultas y respuestas; el proxy decide sobre el leg y la semántica que realmente observa; y la aplicación autoriza la operación. Un nombre DNS, una respuesta del resolver o un SNI visible son señales dependientes del punto de observación: pueden faltar o cambiar por cifrado, caché, NAT o resolución alternativa y no sustituyen autenticación del workload ni autorización de aplicación.
• Lateral: comunicaciones entre recursos con una función semejante o entre servidores que comparten una zona. Permitir que todos los hosts de aplicacion se conecten entre sí amplía el blast radius aunque el perímetro esté filtrado. La matriz debe incluir las relaciones internas que se pretenden bloquear o limitar.

El control plane no es un canal «de confianza» por nombre. Un protocolo de routing, un canal de gestión o una API de un controlador necesita su propia autenticación, autorización, cifrado, logging y segmentación. De modo análogo, separar una VRF de usuarios no basta si el servidor de gestión tiene interfaces en ambas VRF y su identidad no se controla.

Default deny y allowlist: políticas útiles con límites concretos

Default deny significa que, después de evaluar las excepciones, la política implícita es rechazar lo que no coincide. Una allowlist enumera lo que se quiere permitir. Son decisiones de cobertura, no demostraciones de ausencia de riesgo. Una regla final de denegación no revela por sí sola si un proxy, una VPN, una ruta IPv6, un túnel, una interfaz de gestión, un host comprometido o un servicio de terceros ofrece otro camino.

Una allowlist necesita una definición de identidad y de condición suficientemente estable. 10.20.4.0/24 → 10.20.8.0/24:443 puede incluir una dirección reasignada, un proxy que oculta al origen o una aplicación distinta escuchando en el mismo puerto. La política debe especificar quién posee el prefijo, qué selector de identidad se valida, qué protocolo de aplicación se espera y qué evidencia se retiene. Si el requisito es «sólo la API de pagos», una regla L3/L4 es una parte del control, no la propiedad completa.

El retorno también debe ser una política explícita. En un stateful firewall, «permitir la conexión» normalmente incluye aceptar el tráfico de respuesta que coincide con el estado y no cualquier tráfico originado desde el destino. En un stateless, hay que expresar la relación inversa sin abrir más de lo necesario. El contrato debe declarar qué ocurre con retransmisiones, fragmentos, ICMP/ICMPv6 relacionado, errores de PMTU y timeouts. Bloquear todos los mensajes de control puede hacer que el sistema falle de forma opaca, no que se vuelva más seguro.

Para IPv6 CPE (Customer Premises Equipment), RFC 6092 describe recomendaciones de filtrado para equipos residenciales que reenvían tráfico IPv6 entre la LAN y el proveedor. Su alcance no es una política general para redes empresariales: trata el modelo de prefijos delegados, hosts internos y tráfico no solicitado de un CPE, y contempla excepciones y tráfico relacionado. RFC 6092, §§1–2, 4–5 Usarlo como prueba de que toda red IPv6 debe aplicar la misma lista sería extrapolar fuera de su contexto. La política empresarial debe revisar además extensiones IPv6, ICMPv6 necesario, múltiples prefijos, túneles y rutas internas.

IPsec y túneles: otra frontera de visibilidad, no una autorización automática

Cuando se menciona IPsec hay que distinguir la arquitectura de seguridad de la política concreta. RFC 4301 define una Security Policy Database (SPD) que determina qué tráfico se protege, descarta o pasa sin IPsec, una Security Association Database (SAD) para las asociaciones usadas por el procesamiento y una Peer Authorization Database (PAD) para vincular peers autenticados con autorizaciones de IKE. Los selectores pueden incluir direcciones, protocolo y puertos; la asociación y el modo túnel cambian qué observa un filtro intermedio. RFC 4301 está actualizado por RFC 6040 y RFC 7619; este capítulo usa únicamente su modelo SPD/SAD/PAD, selectores y túnel, no sus detalles actualizados de ECN ni una suite criptográfica contemporánea. RFC 4301, §§4.4.1–4.4.3, 5.1–5.2

Un túnel IPsec puede llevar un flujo de una zona a otra sin que el firewall intermedio vea los campos interiores. El endpoint del túnel pasa a ser el objeto visible, y los controles internos deben aplicarse en el punto que descapsula o sobre los selectores adecuados. Autenticar el peer IPsec no equivale a autorizar cada host o servicio que viaja dentro del túnel. Tampoco elimina la necesidad de controlar el plano de gestión que crea, renueva o cambia las asociaciones.

Reglas, shadowing y cambios: una política puede ser correcta en papel y distinta en ejecución

Muchos firewalls evalúan reglas en un orden definido y detienen la evaluación en la primera coincidencia, aunque la semántica exacta depende del producto. Una regla amplia anterior puede sombrear (shadow) una regla más específica posterior. También puede haber reglas de otro contexto, NAT previo, política de interfaz, inspección posterior o una cadena de host que cambie la decisión.

Para revisar un conjunto de reglas:

1. normalizar origen, destino, servicio, dirección, acción, zona, horario y propietario;
2. identificar el orden real y las políticas implícitas del motor;
3. buscar subconjuntos cubiertos por una regla anterior o solapamientos con acciones opuestas;
4. simular el flujo en ambos sentidos y en cada punto de enforcement;
5. comparar la configuración declarada con la efectiva en el dispositivo, datapath o nodo que reenvía;
6. registrar el cambio, la ventana, el rollback y la evidencia de que la regla se cargó.

Una excepción temporal debe tener expiración y criterio de retirada. Un cambio aprobado pero no instalado no es un control operativo; una regla instalada pero no observada no prueba que el tráfico la haya recorrido. El análisis de cambios debe conservar versión, diff, identidad del operador, ticket, resultado de validación y estado posterior.

Observabilidad: contar decisiones, no sólo paquetes

Un contador de hits demuestra que una regla vio tráfico que coincidió con su selector en un punto y ventana determinados. No demuestra que el paquete llegara al servicio, que el retorno fuera aceptado ni que una regla posterior o un host no lo bloqueara. Un contador en cero tampoco demuestra que no exista camino: puede haber un filtro incorrecto, otro dispositivo, una ruta diferente, tráfico IPv6 no instrumentado o una captura fuera del camino.

La telemetría mínima para un flujo material debería correlacionar:

• identidad y versión de la política, regla y dispositivo;
• timestamp sincronizado, interfaz, zona, VRF y dirección;
• origen y destino observados antes y después de NAT o proxy;
• protocolo, puertos, estado, acción, motivo y bytes/paquetes;
• identificador de sesión, trace o conexión cuando exista;
• decisión del host, proxy o aplicación y resultado de la operación.

Los logs también tienen límites de privacidad, retención, muestreo y pérdida. Un deny en el edge puede explicar que un SYN no avanzó, pero no por qué un cliente recibió un error de negocio si existe otro leg. Un log de aplicación puede probar que una petición fue parseada, no que el firewall permitió todos los paquetes que la transportaron.

Caso trabajado: tres afirmaciones y una ruta alternativa

El equipo de Northstar quiere afirmar: «usuarios no puede alcanzar datos». La revisión encuentra una regla que deniega usuarios → datos en el firewall entre VLAN y una prueba negativa que recibe timeout. Esa evidencia es insuficiente.

Primero se define el claim de forma verificable: «Desde el host U, en la VRF de usuarios, durante T, el flujo TCP X hacia la dirección IPv4 D y la dirección IPv6 E no alcanzó el servicio S en el punto de observación F; la política P registró una denegación». Después se comprueban tres caminos: el routing principal, el camino IPv6 y la interfaz de gestión. También se comprueba que D pertenece a datos, que no hay NAT o proxy que cambie el destino, y que el host no tiene una VPN que instale otra ruta.

El control positivo usa una relación que la matriz permite: api → datos con una identidad de workload válida y una solicitud sintética de lectura. Debe observarse el allow, el estado de retorno, la llegada al listener y el resultado de aplicación. El control negativo cambia sólo una dimensión —por ejemplo, un origen usuarios o un servicio no autorizado— y espera una denegación en el punto declarado. Si ambos controles fallan, el problema puede estar en ruta, servicio, identidad o prueba; no se adjudica al firewall sin una evidencia que los separe.

Un contraejemplo rompe la inferencia: el firewall bloquea IPv4 en el enlace principal, pero una dirección IPv6 global de datos es alcanzable por un router distinto que no tiene la misma política. Otro: el usuario no puede abrir TCP a la base, pero puede pedir al proxy permitido que el servicio api realice una operación de lectura; la ruta directa está bloqueada, aunque existe un flujo indirecto autorizado por la aplicación. Un tercero: el deny-all funciona, pero un agente de gestión con credenciales válidas puede cambiar las reglas. La segmentación redujo una superficie; no eliminó autorización ni riesgo residual.

Composición: host, red y cloud deben cubrirse sin duplicar supuestos

El control de host puede limitar procesos, identidades y puertos locales; el control de red puede filtrar alcanzabilidad y registrar flujos; un control cloud puede aplicar security groups, ACL, rutas, service endpoints, políticas de identidad o gateways según el proveedor. Estos controles no son intercambiables y su semántica depende de dónde se ejecutan. Una regla de red no sabe necesariamente qué proceso abrió un socket; una política de identidad no impide por sí sola una ruta de red; un security group no sustituye la autorización de la aplicación.

La composición debe responder cuatro preguntas: qué propiedad cubre cada control, qué selector observa, qué camino puede eludirlo y qué evidencia permite comprobarlo. Si un workload obtiene identidad de un proveedor cloud pero sale por NAT, el destino externo puede ver una dirección compartida; si un proxy termina TLS, el origen debe validar el contexto que recibe; si un host tiene dos interfaces, la política de red debe cubrir ambas. Las capas compensan fallos sólo cuando sus supuestos son independientes o, al menos, conocidos.

Zero Trust puede describir una arquitectura en la que la decisión se basa continuamente en identidad, contexto, recurso y política, pero la etiqueta no reemplaza el mecanismo. Para Northstar, una afirmación útil sería que el gateway exige identidad de workload y autorización por recurso antes de abrir el leg hacia datos, mientras la red limita alcanzabilidad y el host valida el proceso. No sería válido decir «la red es Zero Trust» porque tiene segmentos o «no confiamos en nada» sin describir qué principal se verifica, qué decisión se toma y cómo se observa.

Límites y transferencia

La segmentación no prueba aislamiento absoluto. Deben quedar explícitos los supuestos sobre rutas, interfaces, túneles, IPv4/IPv6, proxies, replicación de estado, configuración de host, control plane y cuentas de administración. Un firewall tampoco es una autorización de aplicación: puede seleccionar campos de red y mantener estado, pero no conoce todos los invariantes del negocio. Un proxy puede elevar el contexto de decisión, aunque crea otra relación de confianza que hay que asegurar.

Al transferir el modelo a una red cloud, un cluster o una planta industrial, se conserva la matriz —origen, destino, servicio, dirección, condición, decisión y evidencia— y se sustituyen los mecanismos concretos. En un cluster, un servicio puede tener identidad y una política de red separada del nodo; en cloud, una ruta o security group puede convivir con una política de identidad y un gateway; en OT, la disponibilidad y el proceso físico pueden imponer condiciones de cambio y observabilidad distintas. No se debe trasladar una regla de producto como si fuera una propiedad universal.

La pregunta final no es «¿hay firewall?», sino «¿qué camino permite esta operación, qué estado debe conservarse, quién puede cambiar la decisión y qué observación falsaría la afirmación?». Un diseño defendible responde esas preguntas por flujo y conserva sus límites. Default deny, una VLAN, una VRF o un contador pueden formar parte de la respuesta; ninguno la completa por sí solo.