Firewalls con estado vs sin estado, y NGFW explicado.

«Firewall» es una palabra que en las últimas tres décadas ha significado varias tecnologías genuinamente distintas, y la mayoría de las explicaciones pasan por alto cuál de ellas están describiendo en realidad. Eso importa, porque una regla que funciona perfectamente en un tipo de firewall puede ser un agujero de seguridad o un quebradero de cabeza innecesario en otro. La verdadera línea divisoria no es «firewall sí o firewall no»: es si el dispositivo que evalúa tu tráfico recuerda algo sobre la conexión de la que forma parte. Esa única distinción es lo que separa el filtrado de paquetes sin estado de los firewalls con estado que casi todo el mundo ejecuta hoy en la práctica, y es el cimiento sobre el que se asienta todo lo que añade un firewall de nueva generación (NGFW).

Qué aplica realmente un firewall

En esencia, un firewall es un motor de políticas situado entre dos redes (o dos zonas de la misma red) que decide, paquete a paquete o conexión a conexión, qué puede pasar y qué se descarta. Todo firewall hace esto inspeccionando alguna combinación de: dirección IP de origen y destino, puerto de origen y destino, y protocolo (TCP, UDP, ICMP, etcétera). Lo que cambia entre generaciones de firewalls es cuánto contexto se aplica a esa decisión: ninguno, algo, o mucho.

Firewalls sin estado: filtrado de paquetes sin memoria

Un firewall sin estado, también llamado firewall de filtrado de paquetes, evalúa cada paquete individual contra una lista estática de reglas, sin ninguna conciencia de qué paquetes vinieron antes o después. Cada paquete es una pregunta nueva y aislada: ¿coincide esta combinación de IP de origen, IP de destino, puerto y protocolo con una regla de «permitir»? Si sí, pasa; si no, se descarta. El firewall no tiene ningún concepto de «conexión»: solo paquetes individuales que coinciden o no con reglas.

Esto tiene una consecuencia real y estructural: como el firewall no puede reconocer un paquete de respuesta como perteneciente a una solicitud que se acaba de enviar, un administrador tiene que escribir reglas explícitas para ambas direcciones de cada tipo de tráfico que quiera permitir. La navegación web saliente necesita una regla de salida que permita tráfico al puerto 443, y una regla de entrada separada que permita las respuestas de vuelta, que, como llegan por el puerto alto que le tocara al cliente, normalmente significa abrir todo el rango de puertos efímeros en lugar de un puerto concreto.

• Puntos fuertes: extremadamente rápidos, poca sobrecarga de memoria y CPU, sencillos de implementar en hardware; por eso siguen apareciendo como listas de control de acceso (ACL) en routers y switches.
• Puntos débiles: los conjuntos de reglas crecen mucho y son propensos a errores; los amplios rangos de entrada abiertos para permitir el «tráfico de vuelta» pueden ser abusados por paquetes no solicitados que simplemente afirman venir de un puerto permitido; no hay capacidad de distinguir una respuesta legítima de una falsificada.

Firewalls con estado: rastrear la conversación

Un firewall con estado resuelve esto manteniendo una tabla de estados (a veces llamada tabla de conexiones): un registro vivo de cada conexión que ya ha aprobado, indexado por la tupla de cinco elementos formada por IP de origen, puerto de origen, IP de destino, puerto de destino y protocolo, junto con el estado actual de la conexión (nueva, establecida o relacionada con una ya existente; la terminología que popularizó netfilter/conntrack de Linux).

Cuando se inicia una nueva conexión saliente y coincide con una regla de permiso, el firewall crea una entrada en la tabla de estados para ella. Todo paquete posterior –en cualquier dirección– que coincida con una entrada existente se permite automáticamente, sin necesitar su propia regla explícita. Un paquete que dice ser una respuesta pero no coincide con ninguna entrada de la tabla se descarta, sin importar de qué puerto diga venir. Por eso normalmente basta con una sola regla de salida («permitir que esta red llegue a internet»): el propio firewall se ocupa de cada paquete de vuelta.

• Puntos fuertes: conjuntos de reglas muchísimo más simples, una postura por defecto mucho más sólida (no entra nada que no se haya iniciado específicamente desde dentro, o que no esté explícitamente permitido), el comportamiento por defecto detrás del NAT de prácticamente cualquier router doméstico y de todo firewall empresarial actual.
• Puntos débiles: la tabla de estados consume memoria y debe mantenerse por conexión, lo que crea un recurso que se puede atacar: inundar un firewall con nuevos intentos de conexión puede agotar su tabla. Además, sigue razonando únicamente sobre direcciones, puertos y estado de la conexión; no tiene ni idea de qué hay realmente dentro del payload.

Firewalls de nueva generación (NGFW): inspeccionar el payload

Un NGFW conserva todo lo que hace un firewall con estado y añade visibilidad sobre el contenido y la identidad del tráfico, no solo sobre su direccionamiento:

• Inspección profunda de paquetes (DPI): mirar dentro del propio payload del paquete, no solo sus cabeceras, para identificar el protocolo y el contenido reales que transporta, detectando, por ejemplo, tráfico disfrazado para parecer otra cosa en el cable.
• Reconocimiento de aplicaciones: identificar la aplicación concreta que genera el tráfico (una videollamada, un cliente de sincronización de archivos, un producto SaaS concreto) sin importar qué puerto use, ya que las aplicaciones modernas cada vez tunelizan más todo por el puerto 443.
• Prevención de intrusiones integrada (IPS): comparar el tráfico en tiempo real con una base de datos de firmas de ataque conocidas y patrones de comportamiento, y bloquear las coincidencias en línea en lugar de limitarse a registrarlas.
• Reconocimiento de usuario e identidad: vincular las reglas a usuarios o grupos autenticados en lugar de solo a direcciones IP, algo que importa enormemente en cuanto el DHCP y los dispositivos móviles hacen poco fiable el mapeo entre IP y persona.
• Inspección TLS: en despliegues empresariales, terminar y restablecer las conexiones cifradas en el propio firewall para que la DPI y el IPS puedan ver realmente dentro de un tráfico que, de otro modo, sería opaco; una capacidad que conlleva sus propias contrapartidas de privacidad y confianza.

Los productos NGFW comerciales –la serie PA de Palo Alto Networks, la línea FortiGate de Fortinet y Cisco Firepower entre ellos– se construyen todos exactamente sobre esta misma pila: el rastreo de conexiones con estado como capa base, con DPI, identificación de aplicaciones y prevención de intrusiones superpuestas encima. La misma estratificación aparece en formato open source cuando un firewall con estado como pfSense se combina con un motor IPS como Suricata o Snort.

Donde un firewall con estado responde a «¿se permite que exista esta conexión?», un NGFW responde además a «¿qué transporta realmente esta conexión, y coincide con algo que hemos decidido bloquear?».

Ejemplo resuelto: un handshake TCP, dos firewalls

Supongamos que un cliente interno en 10.0.0.15 abre una conexión HTTPS a un servidor web en 203.0.113.50, usando el puerto de origen efímero 51823. Así es como se gestiona el mismo handshake de tres paquetes bajo cada modelo.

Firewall sin estado

Regla 1 (salida, obligatoria):
  allow  src=10.0.0.0/24  dst=any        dport=443

Regla 2 (entrada, obligatoria para dejar entrar la respuesta):
  allow  src=any:443      dst=10.0.0.0/24  dport=1024-65535

Paquete 1: 10.0.0.15:51823 -> 203.0.113.50:443   SYN       coincide con la Regla 1, pasa
Paquete 2: 203.0.113.50:443 -> 10.0.0.15:51823   SYN-ACK   coincide con la Regla 2, pasa
Paquete 3: 10.0.0.15:51823 -> 203.0.113.50:443   ACK       coincide con la Regla 1, pasa

Fíjate en la Regla 2: como el firewall no tiene ni idea de que hay realmente una conexión pendiente hacia 203.0.113.50, tiene que permitir cualquier paquete que diga venir del puerto 443 hacia cualquier host interno en cualquier puerto efímero. Un host malicioso, desde cualquier sitio, podría fabricar un paquete con puerto de origen 443 y colarlo a través de la Regla 2 aunque nunca se hubiera solicitado una conexión real; el firewall simplemente no puede notar la diferencia.

Firewall con estado

Regla (salida, la única regla necesaria):
  allow  src=10.0.0.0/24  dst=any  dport=443

Paquete 1: 10.0.0.15:51823 -> 203.0.113.50:443   SYN
  -> coincide con la regla de salida, pasa, la tabla de estados recibe una entrada nueva:
     [10.0.0.15:51823 <-> 203.0.113.50:443, TCP, state=NEW]

Paquete 2: 203.0.113.50:443 -> 10.0.0.15:51823   SYN-ACK
  -> no necesita ninguna regla de permiso; coincide con la entrada existente en la tabla de estados, pasa
     el estado se actualiza a ESTABLISHED

Paquete 3: 10.0.0.15:51823 -> 203.0.113.50:443   ACK
  -> coincide con la entrada de la tabla de estados, pasa

Paquete no solicitado de un host no relacionado que dice venir del puerto 443,
con destino 10.0.0.15:51823, sin ningún SYN previo registrado:
  -> ninguna entrada coincidente en la tabla de estados -> se descarta, sin importar el puerto de origen que diga tener

El firewall con estado necesitó exactamente una regla, y el paquete falsificado se descarta automáticamente porque no corresponde a ninguna conexión que el firewall haya visto iniciarse de verdad. Esa es toda la ventaja resumida en una comparación: el firewall sin estado tiene que confiar en los metadatos que declara cada paquete; el firewall con estado confía en su propia memoria de lo que ya aprobó.

Comparativa de un vistazo

Estas tres capas no son alternativas mutuamente excluyentes: la mayoría de las redes reales ejecutan más de una a la vez. Las ACL de un router (sin estado) pueden filtrar tráfico obviamente malformado justo en el borde antes de que llegue siquiera a un firewall con estado que hace el rastreo real de conexiones, que a su vez puede estar detrás o junto a un NGFW haciendo inspección profunda sobre el tráfico que cruza hacia una zona más sensible. Combinarlas en capas aprovecha los puntos fuertes de cada una: el filtrado sin estado es barato y rápido para un rechazo grueso, el filtrado con estado gestiona con eficiencia el grueso del tráfico legítimo, y la inspección NGFW se reserva para el tráfico y las zonas donde su coste extra está de verdad justificado.

Firewalls de host: el mismo modelo en tu propia máquina

Todo lo anterior describe firewalls de red situados entre redes, pero el mismo modelo con estado se ejecuta localmente en casi todos los sistemas operativos modernos, protegiendo un único host en lugar de una red entera. Linux usa netfilter, configurado a través de iptables o del más reciente nftables, ambos con su propia tabla de rastreo de conexiones (conntrack), exactamente análoga a la tabla de estados descrita antes. Windows viene con Windows Defender Firewall, y macOS tiene su Application Firewall más el filtro de paquetes pf subyacente, heredado de BSD.

# Un firewall de host con estado mínimo en nftables:
# permitir de vuelta el tráfico established/related, descartar todo lo demás no solicitado
$ sudo nft add rule inet filter input ct state established,related accept
$ sudo nft add rule inet filter input ct state invalid drop
$ sudo nft add rule inet filter input drop

Esa primera línea hace precisamente lo que hacía la tabla de estados del ejemplo resuelto anterior: ct state established,related le dice al kernel que permita automáticamente cualquier paquete que coincida con una conexión que este host ya inició, sin necesitar una regla separada para la dirección de respuesta. Los firewalls de host importan incluso dentro de una red que ya tiene un firewall perimetral, porque contienen el radio de impacto si otro dispositivo de la misma red se ve comprometido: un firewall de red por sí solo no hace nada para detener el movimiento lateral entre dos máquinas que ya están dentro de él.

Probar tus propias reglas de firewall desde fuera

La única forma de saber si una regla de firewall hace realmente lo que pretendías es probarla desde un punto de vista ajeno a tus propias suposiciones, idealmente desde una red completamente distinta. Un escaneo de puertos básico contra tu propia IP pública muestra qué es realmente accesible, sin importar lo que diga el archivo de reglas:

# Desde un host externo, escanea los puertos TCP más comunes
$ nmap -Pn tu.ip.publica.aqui

PORT     STATE    SERVICE
22/tcp   filtered ssh
443/tcp  open     https
8080/tcp closed   http-proxy

open significa que un servicio respondió a la conexión, lo esperable para cualquier cosa que hayas expuesto deliberadamente, como un servidor web en el 443. closed significa que el host es accesible pero no hay nada escuchando en ese puerto, así que se rechazó activamente. filtered significa que no volvió ninguna respuesta en absoluto, que es lo que produce un firewall con estado bien configurado para un puerto sin ninguna regla de permiso que coincida: el paquete SYN simplemente se descarta, sin dar a un atacante externo ninguna confirmación de que el host siquiera existe en ese puerto. Ver «filtered» en lugar de «closed» en puertos que no pretendías exponer es una forma rápida y práctica de confirmar que tus reglas están haciendo de verdad su trabajo, y no solo pareciendo correctas sobre el papel.

Dónde sigue apareciendo cada tipo hoy

El filtrado sin estado no ha desaparecido: sigue vivo como ACL rápidas y baratas en routers y switches, a menudo usadas como primer filtro grueso antes de que el tráfico llegue siquiera a un dispositivo con estado, precisamente porque es muy ligero. La inspección con estado es la suposición por defecto en casi todo lo demás: el NAT de tu router doméstico, iptables/nftables con conntrack en Linux, Windows Defender Firewall y la capa base de prácticamente todo appliance de firewall comercial que se vende hoy. La capacidad NGFW se sitúa encima de esa base con estado en el perímetro de red y dentro de los centros de datos, allí donde una organización necesita ver qué es realmente el tráfico y no solo adónde dice que va; consulta nuestro laboratorio práctico de segmentación de red con pfSense para ver un ejemplo funcionando de reglas de firewall con estado segmentando una red real.

La conclusión

Los firewalls sin estado filtran paquetes de forma aislada y necesitan reglas explícitas para cada dirección del tráfico, lo que obliga a abrir puertos de entrada amplios que debilitan el propio modelo que se supone que deben aplicar. Los firewalls con estado arreglan eso recordando las conexiones en una tabla de estados, dejando que una sola regla de salida autorice implícitamente su propio tráfico de vuelta, motivo por el que se convirtieron en la opción por defecto en casi todas partes. Los NGFW se construyen sobre esa base con estado y añaden la capacidad de leer realmente lo que hay dentro del tráfico: la identidad de la aplicación, las firmas de intrusión y, en entornos empresariales, el propio contenido descifrado. Ninguna de estas capas sustituye a las demás; entender cuál está protegiendo realmente una red dada es el primer paso para configurarla correctamente.

Preguntas frecuentes