¿Qué es un ataque TCP FIN Flood?

Un TCP FIN flood es un ataque DDoS basado en protocolo que envía grandes volúmenes de segmentos TCP con el flag FIN (finish) activado hacia un objetivo, forzando al stack receptor y a cualquier firewall con estado en la ruta a procesar la lógica de terminación de conexión para sesiones que frecuentemente no existen. Como los paquetes FIN disparan transiciones de estado de cierre y actualizaciones de tabla de seguimiento de conexión, los FIN floods sostenidos pueden agitar las tablas de firewall y conntrack incluso sin completar primero un handshake real.

Resumen rápido — TCP usa el flag FIN para señalar el cierre ordenado de una dirección de una conexión, moviendo la sesión a través de estados de cierre (FIN_WAIT, CLOSE_WAIT, TIME_WAIT) antes de eliminarla de las tablas de seguimiento. Un FIN flood envía altos volúmenes de paquetes FIN, usualmente con direcciones de origen falsificadas, para conexiones que nunca existieron o que el atacante está intentando cerrar prematuramente. Los dispositivos con estado deben buscar el estado de conexión para cada paquete FIN, y las tablas pueden agitarse o llenarse bajo volumen. La mitigación se apoya en la validación con estado de paquetes FIN contra sesiones rastreadas, ajuste de tabla de conexión, rate limiting, y terminación TCP basada en edge.

Última actualización: 2026-08-08

Cómo funciona un TCP FIN Flood

El rol de FIN en el cierre de conexión TCP

Las conexiones TCP se cierran a través de un intercambio de cuatro pasos definido en RFC 793 y RFC 9293:

Secuencia de cierre TCP normal:
Cliente → Servidor: FIN (el cliente no tiene más datos que enviar)
Servidor → Cliente: ACK (confirma el FIN del cliente)
Servidor → Cliente: FIN (el servidor no tiene más datos que enviar)
Cliente → Servidor: ACK (confirma el FIN del servidor)
[La conexión se cierra por completo después de que ambos lados envían FIN y ACK]

Cada FIN transiciona la conexión a través de estados intermedios —FIN_WAIT_1, FIN_WAIT_2, CLOSE_WAIT, LAST_ACK, TIME_WAIT— antes de que la entrada finalmente se elimine de la tabla de conexión. TIME_WAIT específicamente mantiene el estado por un intervalo definido (comúnmente el doble de la vida máxima del segmento) para manejar de forma segura paquetes retrasados o duplicados.

Cómo explota el flood el procesamiento de cierre

Un atacante envía un flujo continuo de paquetes FIN, comúnmente con direcciones IP de origen falsificadas y a menudo apuntando a tuplas puerto/conexión que no corresponden a ninguna sesión real:

Tráfico normal:
Cliente ──FIN──▶ Servidor   [El servidor busca la conexión coincidente, procesa el cierre]

FIN flood:
Bot (IP falsificada: 203.0.113.1) ──FIN──▶ Servidor  [búsqueda de estado: sin coincidencia, o cierre forzado]
Bot (IP falsificada: 203.0.113.2) ──FIN──▶ Servidor  [búsqueda de estado: sin coincidencia, o cierre forzado]
Bot (IP falsificada: 203.0.113.3) ──FIN──▶ Servidor  [búsqueda de estado: sin coincidencia, o cierre forzado]
... [millones más por segundo]

Resultado: Las entradas de la tabla de estado de conntrack/firewall se agitan
        o se llenan; la CPU gastada en búsquedas aumenta; el cierre
        legítimo puede retrasarse

El ataque tiene dos efectos distintos dependiendo de si la conexión objetivo existe:

1. Contra conexiones inexistentes: cada paquete FIN todavía requiere que el stack receptor o un firewall inline con estado realice una búsqueda contra las conexiones rastreadas. A suficiente volumen, esto consume CPU y, en dispositivos que crean entradas de tabla provisionales para segmentos no coincidentes, puede agitar la propia tabla de conexión.
2. Contra conexiones existentes: si un atacante puede adivinar u observar números de secuencia para una sesión activa (más factible en atacantes off-path o on-path, o en redes con aleatorización débil de números de secuencia), un FIN falsificado puede terminar prematuramente una conexión legítima, interrumpiendo la capa de aplicación sin necesariamente generar grandes volúmenes de tráfico.

Por qué los FIN floods son efectivos contra middleboxes

Los firewalls con estado, load balancers, y sistemas de prevención de intrusiones deben rastrear el estado TCP para aplicar políticas correctamente. A diferencia de un filtro de paquetes simple, estos dispositivos mantienen sus propias tablas de conexión independientes del kernel del servidor de origen. Un FIN flood fuerza a cada uno de estos dispositivos intermedios a realizar búsquedas de estado y actualizaciones de tabla, lo que significa que el cuello de botella puede aparecer en la infraestructura mucho antes de que aparezca en el propio servidor de origen.

TCP FIN Flood vs. Floods relacionados basados en flags

Señales de detección y telemetría

# Estados de socket — los estados relacionados con FIN deberían ser una fracción pequeña y predecible
ss -ti state fin-wait-1 state fin-wait-2 state closing state last-ack state time-wait

# Contadores TCP — verifica contadores anómalos relacionados con cierre
nstat -az | grep -i tcp

# Conntrack de Netfilter: busca entradas atascadas en estados relacionados con FIN
conntrack -L -p tcp --state FIN_WAIT
cat /proc/sys/net/netfilter/nf_conntrack_count

# Contadores de iptables en reglas que rastrean paquetes solo-FIN o FIN-sin-SYN-previo
iptables -L -v -n

# Ventana de captura corta para inspeccionar la proporción del flag FIN contra el tráfico TCP total (evitar en ataques de PPS alto)
tcpdump -i eth0 -c 20000 'tcp[tcpflags] & tcp-fin != 0' -nn

Técnicas de mitigación

Sequence number validation matters specifically for FIN floods aimed at hijacking or prematurely closing active sessions: un stack receptor solo debería honrar un FIN cuyo número de secuencia caiga dentro de la ventana de recepción actual de esa conexión, lo que limita drásticamente la inyección ciega (off-path, falsificada) de FIN.

Errores comunes

Cómo implementarlo con Azion

Azion gestiona el ciclo de vida de la conexión TCP en el edge de red, cambiando dónde se absorbe y valida el tráfico de FIN flood:

• DDoS Protection brinda detección y mitigación siempre activa para floods de protocolo, incluyendo patrones anómalos de tráfico FIN, antes de que lleguen al origen.
• Network Shield aplica reglas programables a nivel de red para bloquear orígenes asociados con tráfico de inundación basados en IP, CIDR y ASN.
• Firewall permite reglas personalizadas para validación de estado de conexión y filtrado basado en tasa.
• WAAP combina protecciones de red y de capa de aplicación para entornos que enfrentan ataques mezclados.

Como Azion termina y rastrea las sesiones TCP en puntos de presencia distribuidos, los paquetes FIN que no coinciden con una sesión validada en el edge se manejan antes de que puedan agitar las tablas de conexión del lado del origen.

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?
• Azion DDoS Protection

Preguntas frecuentes

¿Qué es un ataque TCP FIN flood? Un TCP FIN flood envía grandes volúmenes de segmentos TCP con el flag FIN activado hacia un objetivo, a menudo para conexiones que no existen o con direcciones de origen falsificadas. Cada FIN fuerza una búsqueda de estado de conexión y potencial procesamiento de cierre, lo que puede agitar las tablas de firewall y conntrack a suficiente volumen.

¿En qué se diferencia un FIN flood de un RESET flood? FIN señala un cierre ordenado y mueve una conexión a través de múltiples estados de cierre (FIN_WAIT, TIME_WAIT, y otros) antes de la eliminación. RST fuerza una terminación inmediata y abrupta sin el handshake de cierre de múltiples pasos. Los FIN floods principalmente agitan las transiciones de máquina de estados y las entradas de tabla a lo largo del tiempo; los RESET floods terminan las sesiones instantáneamente al recibirlas.

¿Un FIN flood puede apuntar a una conexión existente y activa? Sí. Si un atacante puede forjar un FIN con un número de secuencia que caiga dentro de la ventana de recepción actual de una conexión, el stack receptor puede honrarlo como legítimo, cerrando prematuramente una sesión activa. Esto requiere conocimiento o predicción de números de secuencia, lo cual una aleatorización fuerte de números de secuencia hace sustancialmente más difícil.

¿Un FIN flood requiere IP spoofing? No, pero el spoofing es común porque complica el bloqueo basado en origen y, para floods contra conexiones inexistentes, no tiene desventaja funcional para el atacante. Los FIN floods no falsificados desde una botnet con IP reales también son posibles y se mitigan con rate limiting por origen.

¿Cómo difiere un FIN flood de un SYN flood? El SYN flood apunta al establecimiento de conexión, agotando la memoria del kernel con conexiones semi-abiertas. El FIN flood apunta al cierre de conexión, agotando la CPU y la capacidad de tabla de conexión en búsquedas de estado y transiciones de cierre. Las SYN cookies abordan el SYN flood pero no tienen efecto en el FIN flood.

¿Por qué los firewalls con estado tienen problemas con los FIN floods? Los firewalls con estado mantienen sus propias tablas de seguimiento de conexión independientes del servidor de origen. Cada paquete FIN requiere una búsqueda contra esa tabla, y a suficiente volumen la propia tabla y CPU del firewall pueden convertirse en el cuello de botella antes de que el servidor de origen se vea afectado en absoluto.

¿Qué es TIME_WAIT y por qué importa para el análisis de FIN flood? TIME_WAIT es el estado que entra una conexión después de que ambos lados intercambiaron FIN y ACK, mantenido por un intervalo definido para manejar de forma segura paquetes retrasados o duplicados. Un pico desproporcionado en TIME_WAIT u otros estados relacionados con FIN en relación con el tráfico real es una señal fuerte de actividad de FIN flood.

¿El rate limiting por sí solo puede detener un FIN flood? El rate limiting por IP de origen es efectivo contra floods no falsificados de un conjunto limitado de orígenes. Contra FIN floods altamente distribuidos o falsificados, el rate limiting por IP tiene efecto limitado porque cada paquete puede parecer originarse de una dirección de origen distinta, a menudo de un solo uso.

¿Aumentar el tamaño de la tabla de conexión corrige la exposición al FIN flood? Retrasa la saturación pero no resuelve el problema subyacente. Un flood suficientemente grande eventualmente saturará cualquier aumento del tamaño de tabla. El ajuste de tabla es una medida de contención que debería combinarse con rate limiting, validación de número de secuencia, y filtrado upstream o basado en edge.

¿Cómo ayuda la terminación TCP basada en edge contra los FIN floods? Cuando una red distribuida completa y gestiona las sesiones TCP en nombre del origen, solo las sesiones validadas en el edge se reenvían. Los paquetes FIN falsificados o fuera de sesión son absorbidos y procesados por la infraestructura de la red edge, que está construida para manejar esta carga de estado, en lugar de por la tabla de conexión del origen.

Fuentes:

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