¿Qué es un ataque TCP Out-of-State Flood? | Agotamiento de firewall con estado y conntrack

Un TCP Out-of-State Flood es un ataque DDoS de Capa 4 que envía paquetes TCP con combinaciones de flags que no corresponden a ninguna transición válida en la máquina de estados TCP para una conexión existente o esperada, forzando a los firewalls con estado y a los sistemas de seguimiento de conexión (conntrack) a clasificar y procesar grandes volúmenes de paquetes que no coinciden con ninguna sesión legítima. El ataque apunta a la CPU y a la capacidad de tabla de la propia capa de inspección con estado, en lugar de a la cola de conexiones o a la aplicación detrás de ella.

Resumen rápido — Las conexiones TCP siguen una máquina de estados definida (RFC 793/RFC 9293): SYN_SENT, SYN_RECV, ESTABLISHED, FIN_WAIT, CLOSE_WAIT, y así sucesivamente, cada una con un conjunto específico de combinaciones de flags entrantes válidas. Un TCP Out-of-State Flood envía paquetes —ACK, FIN, RST, PSH, o combinaciones de estos— que no coinciden con ninguna conexión rastreada ni con ninguna transición de estado válida para una que exista. Los firewalls con estado y conntrack deben evaluar y clasificar cada paquete como INVALID, consumiendo CPU y capacidad de tabla proporcional al volumen. A diferencia del SYN Flood, no llena la cola de backlog SYN; a diferencia de un ACK Flood puro, no se limita a un solo patrón de flags. La mitigación se apoya en descartar paquetes en estado INVALID lo más pronto posible, ajustar el tamaño y los timeouts de la tabla conntrack, y aplicar rate limiting por patrón de flag en el edge.

Última actualización: 2026-08-08

Cómo funciona un TCP Out-of-State Flood

1. Cada conexión TCP rastreada por un firewall con estado o por el sistema de seguimiento de conexiones del kernel se mueve a través de una secuencia definida de estados: NONE → SYN_SENT/SYN_RECV → ESTABLISHED → FIN_WAIT/CLOSE_WAIT → TIME_WAIT/CLOSED.
2. Cada estado solo acepta combinaciones específicas de flags entrantes como próximos pasos válidos. Un ACK solo se espera después de un SYN-ACK; un FIN solo se espera de una conexión establecida que se está cerrando; un RST puede llegar en casi cualquier punto para abortar una conexión.
3. Un paquete fuera de estado es cualquier segmento TCP cuyos flags no correspondan a una transición legal para el estado rastreado actual de la conexión, o que referencie una tupla de conexión sin ningún estado rastreado en absoluto.
4. El atacante genera un flujo de tales paquetes: ACK sin ningún SYN previo, FIN para conexiones que no están en estado establecido, RST para tuplas no rastreadas, o combinaciones PSH+ACK dirigidas a sesiones cerradas o inexistentes, a menudo mezclando varios patrones de flags en la misma inundación en lugar de apegarse a uno solo.
5. El módulo conntrack de Netfilter (o un motor con estado equivalente en cualquier firewall/load balancer) evalúa cada paquete contra su tabla de estado. Cualquier cosa que no coincida con una conexión rastreada o que viole la transición esperada se clasifica como INVALID.
6. A volumen de inundación, la sola cantidad de decisiones de clasificación —más, en algunas configuraciones, la agitación de la tabla conntrack por intentos de crear nuevas entradas de rastreo para el tráfico no coincidente— consume CPU y memoria en el firewall o en el stack de red del kernel.

Transiciones de estado TCP normales:
Cliente ──SYN──▶ Servidor              [estado: NONE → SYN_RECV]
Cliente ◀─SYN-ACK── Servidor
Cliente ──ACK──▶ Servidor              [estado: SYN_RECV → ESTABLISHED]
Cliente ──PSH,ACK (datos)──▶ Servidor  [válido: ESTABLISHED acepta PSH,ACK]
Cliente ──FIN,ACK──▶ Servidor          [válido: ESTABLISHED → FIN_WAIT]
Cliente ──ACK──▶ Servidor              [válido: cierra limpiamente]

TCP Out-of-State Flood:
Bot ──FIN,ACK (sin conexión rastreada)──▶ Servidor   [sin estado coincidente → INVALID]
Bot ──RST (sin conexión rastreada)──▶ Servidor        [sin estado coincidente → INVALID]
Bot ──ACK (sin SYN previo)──▶ Servidor                 [sin estado coincidente → INVALID]
Bot ──PSH,ACK (tupla nunca establecida)──▶ Servidor  [sin estado coincidente → INVALID]
... [millones de paquetes no coincidentes, patrones de flag mezclados]

Resultado: la CPU de conntrack/firewall se gasta clasificando paquetes INVALID;
        la cola de backlog SYN y la capa de aplicación nunca se tocan directamente

¿Cuál ataque de flag TCP es este? Tabla comparativa

La distinción con ACK Flood: Out-of-State Flood es la categoría más amplia; incluye a ACK Flood como una instancia pero también usa tráfico FIN, RST y de flags combinados para maximizar la variedad de discordancias que un defensor debe clasificar, lo que puede complicar el filtrado basado en firmas que solo vigila un patrón de flag. La distinción con TCP Invalid Packet: los paquetes fuera de estado típicamente tienen combinaciones de flags estructuralmente legales (un ACK solitario, un FIN solitario) que simplemente son inconsistentes con el estado de la conexión rastreada, mientras que los paquetes inválidos son ilegales a nivel de protocolo sin importar ningún estado rastreado (como SYN+FIN activados simultáneamente).

Variaciones del ataque

Rotación de flags mezclados. El atacante rota entre paquetes ACK, FIN-ACK, RST, y PSH-ACK a través de la inundación para evitar que cualquier regla de detección de un solo flag capture el ataque completo, forzando a los defensores a monitorear el contador INVALID agregado en lugar de una firma de flag específica.

Out-of-state flood dirigido a la agitación mid-sesión. En lugar de apuntar solo a conexiones inexistentes, algunas variantes envían paquetes fuera de estado referenciando tuplas que se cerraron recientemente (en TIME_WAIT), intentando interactuar con una entrada de seguimiento de conexión que está en proceso de expirar, agregando agitación a la lógica de limpieza de la tabla conntrack.

Combinado con tráfico low-and-slow legítimo. Los atacantes a veces mezclan paquetes fuera de estado con tráfico genuino de bajo volumen para hacer que el flujo malicioso sea más difícil de aislar del ruido de fondo en monitoreo de grano grueso.

Señales de detección y telemetría

# Resumen de sockets — no se ve afectado en un out-of-state flood puro ya que SYN_RECV no es el objetivo
ss -s

# Desglose completo de estado de conexión
ss -tan state all | awk '{print $1}' | sort | uniq -c

# Contador de paquetes inválidos de conntrack de Netfilter — la señal principal
conntrack -S

# Inspecciona las conexiones rastreadas actuales y la presión de la tabla
conntrack -L | wc -l
cat /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count

# Contadores del kernel TCP para anomalías no capturadas solo por conntrack
nstat -az

# nftables contando/descartando tráfico en estado inválido, desglosado por flag para diagnóstico
nft add rule inet filter input ct state invalid counter drop
nft add rule inet filter input tcp flags fin,ack / fin,ack ct state invalid counter
nft add rule inet filter input tcp flags rst / rst ct state invalid counter

# Equivalentes de iptables
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP

Técnicas de mitigación

Errores comunes y correcciones

Cómo implementarlo con Azion

La red distribuida de Azion puede absorber tráfico fuera de estado de flags mezclados antes de que llegue a la infraestructura de origen:

• DDoS Protection está diseñado para detectar anomalías de Capa 3/4, incluyendo tráfico que no coincide con ninguna transición de estado TCP válida, en el edge.
• Network Shield aplica filtrado a nivel de red que puede clasificar y descartar paquetes inconsistentes con el estado de conexión rastreado.
• Firewall soporta reglas personalizadas para bloqueo basado en estado y tasa.
• WAAP combina protección de red y de capa de aplicación para equipos que necesitan cobertura más amplia.

Como Azion puede terminar y rastrear el estado TCP en el edge, un servidor de origen detrás de él generalmente solo recibe tráfico que pertenece a sesiones que el propio edge validó; los paquetes fuera de estado se filtran upstream en lugar de agotar el conntrack o los recursos de firewall del origen. La protección real depende de tu configuración específica; valida el comportamiento contra tu perfil de tráfico.

Recursos relacionados

• ¿Qué es un ataque DDoS?
• Tipos de ataques DDoS
• ¿Qué es un ataque SYN Flood?
• ¿Qué es la protección y mitigación DDoS?
• ¿Qué es un ataque TCP SYN-ACK Flood?
• ¿Qué es un ataque TCP Invalid Packet?

Preguntas frecuentes

¿Qué es un ataque TCP Out-of-State Flood? Es un ataque DDoS que envía paquetes TCP cuyos flags no corresponden a ninguna transición válida en la máquina de estados TCP para una conexión rastreada, como un ACK sin ningún SYN previo, o un FIN para una conexión que no está establecida. Los firewalls con estado y conntrack deben clasificar cada uno, consumiendo CPU y capacidad de tabla.

¿En qué se diferencia Out-of-State Flood de un TCP ACK Flood? TCP ACK Flood usa un solo patrón de flag fijo (solo ACK). Out-of-State Flood es la categoría más amplia y típicamente mezcla múltiples patrones de flag —combinaciones de ACK, FIN, RST, PSH— específicamente para vencer la detección de una sola firma y estresar la lógica de clasificación de conntrack de forma más amplia.

¿En qué se diferencia esto de un SYN Flood? SYN Flood agota la cola de conexiones asignando estado semi-abierto para cada paquete SYN recibido. Out-of-State Flood no toca en absoluto el backlog SYN; apunta a la lógica de clasificación y gestión de tabla del firewall con estado con paquetes que no encajan en ninguna transición de estado legítima.

¿Qué significa “fuera de estado” en términos de TCP? Significa que los flags de un paquete no coinciden con un próximo paso legal para el estado actualmente rastreado de la conexión en la máquina de estados definida por RFC 793/RFC 9293; por ejemplo, recibir un FIN para una conexión de la que el firewall nunca vio una entrada SYN o ESTABLISHED.

¿Aumentar el tamaño de la tabla conntrack por sí solo puede detener este ataque? No. Aumentar nf_conntrack_max retrasa el agotamiento de tabla bajo volumen de ataque moderado pero no aborda el costo de CPU de clasificar cada paquete fuera de estado, y una inundación suficientemente grande todavía abrumará una tabla más grande. Debería combinarse con descartes de estado INVALID tempranos y filtrado upstream.

¿Se requiere IP spoofing para un TCP Out-of-State Flood? No. El ataque funciona ya sea que las IP de origen estén falsificadas o sean reales, ya que el mecanismo depende de discordancias de flag/estado en lugar de explotar un requisito de ruta de retorno. El spoofing todavía puede usarse para complicar la atribución y evadir el bloqueo basado en IP.

¿Cómo distingo un TCP Out-of-State Flood de un ataque TCP Invalid Packet? Los paquetes fuera de estado usualmente son legales a nivel de protocolo por sí solos (un ACK solitario, un FIN solitario) pero inconsistentes con el estado de la conexión rastreada. Los paquetes inválidos son ilegales a nivel de protocolo sin importar el estado —como SYN y FIN activados en el mismo paquete, o un checksum corrupto— y típicamente se capturan por lógica de parsing/validación en lugar de lógica de transición de estado.

¿Qué comando de Linux muestra los conteos de paquetes fuera de estado? conntrack -S muestra el contador invalid mantenido por el subsistema de seguimiento de conexión de Netfilter, que se incrementa cada vez que un paquete se clasifica como no coincidente con ninguna conexión rastreada o transición de estado válida.

¿Este ataque afecta directamente a la capa de aplicación? No directamente. El impacto principal está en la capa de inspección con estado —firewall, load balancer, o conntrack del kernel— antes de que el tráfico llegue a la aplicación. Si esa capa se satura, el tráfico legítimo (incluyendo hacia la aplicación) puede descartarse como daño colateral.

¿Este ataque se puede combinar con un SYN Flood? Sí. Los atacantes a veces combinan tráfico de SYN Flood con tráfico ACK/FIN/RST fuera de estado para presionar tanto la cola de backlog SYN como la lógica de clasificación del firewall con estado al mismo tiempo, requiriendo que los defensores apliquen SYN Cookies y filtrado de estado INVALID simultáneamente.

Fuentes

• IETF. “Transmission Control Protocol.” RFC 793. 1981.
• IETF. “Transmission Control Protocol (TCP) Specification.” RFC 9293. 2022.
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”