Ataque SYN Flood | Agotamiento de Estado TCP y Defensa L4

Un ataque SYN Flood es una forma de DDoS que explota el proceso de establecimiento de conexión TCP para agotar las estructuras de estado pendiente del kernel del servidor objetivo, impidiendo que se acepten conexiones legítimas.

¿Cómo funciona un ataque SYN Flood?

El handshake de tres vías y las colas de conexión

El handshake de tres vías (three-way handshake) es el proceso que establece cualquier conexión TCP. El cliente envía un segmento TCP con la bandera SYN activa, señalando su deseo de conectar. El servidor responde con SYN-ACK y registra la solicitud como una conexión pendiente, esperando el ACK final del cliente. Solo después de recibir ese ACK la conexión se promueve al estado ESTABLISHED y se notifica a la aplicación.

En Linux, existe una distinción conceptual importante entre dos colas que operan en este proceso:

1. Cola de solicitudes SYN (SYN queue o cola de conexiones incompletas): mantiene las solicitudes de conexión que recibieron un SYN y esperan la finalización del handshake con el ACK final. El parámetro net.ipv4.tcp_max_syn_backlog está asociado con la presión en esta cola.
2. Cola de accept (accept queue o cola de conexiones completas): mantiene las conexiones ya establecidas que esperan que la aplicación ejecute accept(). Su tamaño efectivo está limitado por el menor valor entre el argumento listen(backlog) de la aplicación y net.core.somaxconn.

El SYN Flood presiona principalmente la cola de solicitudes SYN. En ataques de gran volumen, los efectos se propagan: CPU, softirq, conntrack de Netfilter, capacidad del firewall y ancho de banda también pueden agotarse.

Los detalles internos de estas estructuras — nombres, tamaños y comportamientos — varían según la versión del kernel, la distribución Linux y la configuración aplicada. Los conceptos descritos aquí reflejan el comportamiento general; valida siempre en tu entorno específico.

La asimetría que hace eficiente el ataque

El atacante envía segmentos TCP con la bandera SYN activa — encapsulados en paquetes IP, con tamaño variable según las opciones TCP negociadas y cualquier encapsulamiento adicional. El coste para el atacante es mínimo: enviar y olvidar.

Por cada SYN recibido, el kernel debe asignar memoria y temporizadores asociados al handshake — estructuras internas cuya implementación varía según la versión del kernel, las opciones negociadas, el estado de Netfilter/conntrack, los módulos cargados y la política de SYN Cookies activa. El servidor mantiene estas estructuras durante todo el período de espera del ACK final.

Con falsificación de IP (IP spoofing) — direcciones de origen fabricadas por el atacante — el ACK final nunca llega. Cada solicitud ocupa la cola de solicitudes SYN hasta expirar. Cuando la cola se satura, los nuevos SYNs se descartan y los usuarios legítimos comienzan a recibir errores de conexión.

El ataque en operación

El atacante envía un flujo continuo de paquetes SYN con direcciones de origen falsificadas. El servidor responde a cada SYN con un SYN-ACK dirigido a la IP falsificada, que no devuelve el ACK. La cola de solicitudes SYN se satura en segundos. Los servicios que dependen de TCP — HTTP/S, SSH, bases de datos, APIs — quedan inaccesibles aunque el hardware del servidor funcione con normalidad.

La tabla siguiente muestra indicadores que diferencian el tráfico normal de un SYN Flood en curso. Los valores son ejemplos iniciales; calibra con el baseline histórico de tu entorno antes de usarlos como umbral de alerta.

Variaciones del ataque

SYN Flood distribuido mediante botnet

En lugar de un único host con IP falsificada, el atacante usa una botnet de dispositivos comprometidos, cada uno enviando SYNs con su IP real. Las direcciones de origen son genuinas, lo que limita la efectividad de BCP38 como única defensa. La detección requiere análisis conductual: patrones de timestamps, volumen por IP y ausencia de ACKs posteriores son los indicadores relevantes.

SYN-ACK Flood reflejado

El atacante envía SYNs con la IP de la víctima como dirección de origen a servidores públicos de terceros. Esos servidores responden con SYN-ACKs dirigidos a la IP de la víctima, que recibe volúmenes masivos de SYN-ACKs no solicitados. A diferencia del SYN Flood clásico — que agota las colas de conexión —, el SYN-ACK Flood agota el ancho de banda y fuerza el procesamiento de paquetes no solicitados. La mitigación requiere inspección stateful para descartar SYN-ACKs que no correspondan a conexiones iniciadas localmente.

ACK Flood

Inunda el objetivo con paquetes ACK para conexiones TCP inexistentes. Por cada paquete, la pila TCP debe realizar una búsqueda de estado y clasificar el paquete. Dependiendo de la pila TCP, el estado local y las reglas del firewall, los paquetes ACK inválidos pueden descartarse silenciosamente, clasificarse como inválidos, registrarse o resultar en una respuesta TCP en contextos específicos. El efecto principal es el coste de procesamiento de paquetes y la presión sobre la CPU y los dispositivos stateful — no necesariamente la generación de RSTs.

SYN Flood como distracción en campañas de intrusión

En algunas campañas de extorsión e intrusión, los ataques DDoS pueden usarse como distracción operacional mientras se realizan en paralelo otras actividades maliciosas — exfiltración de datos, abuso de APIs internas, instalación de ransomware. Las organizaciones sin segmentación efectiva de alertas y sin correlación de eventos son particularmente vulnerables a este patrón.

La recomendación es correlacionar alertas DDoS con otras fuentes de telemetría: EDR, SIEM, logs de identidad, logs de API y telemetría de red. Un SYN Flood aislado en el perímetro, combinado con actividad anómala en sistemas internos, es señal de una campaña coordinada.

Técnicas de defensa en capa 4

SYN Cookies — RFC 4987

La técnica más efectiva contra SYN Floods con IPs falsificadas. Definida formalmente en la RFC 4987, SYN Cookies reduce o elimina la necesidad de mantener estado de handshake pendiente antes de la validación del cliente.

En lugar de asignar estructuras de estado para cada SYN recibido, el servidor codifica información verificable directamente en el Initial Sequence Number (ISN) del SYN-ACK, usando un hash criptográfico: ISN = hash(src_ip, src_port, dst_ip, dst_port, timestamp, secret_key).

Cuando el cliente responde con el ACK, el número de acknowledgment debe ser ISN + 1. El servidor recalcula el hash y valida que el cliente genuinamente recibió el SYN-ACK — confirmando que la IP de origen es real. Solo entonces crea el estado completo necesario para la conexión. Las IPs falsificadas nunca devuelven el ACK correcto y, por lo tanto, nunca fuerzan la asignación de memoria.

Los SYN Cookies son particularmente efectivos contra SYN Floods con spoofing, donde el ACK final no regresa al objetivo. No resuelven directamente ataques de botnets que usan IPs reales y completan el handshake — en esos casos se necesitan técnicas complementarias como rate limiting por IP, detección conductual y limitación de conexiones concurrentes.

Limitaciones y compromisos: el espacio disponible en el ISN (32 bits) limita la cantidad de información que puede codificarse. El manejo de opciones TCP como Window Scaling, SACK y timestamps depende de la implementación y la versión del sistema operativo. Las implementaciones modernas pueden preservar algunas de estas opciones en determinados escenarios; otras puede que no. Evalúa el comportamiento en tu kernel y distribución específicos antes de depender de esa preservación.

Los SYN Cookies deben usarse como protección bajo presión, no como sustituto de la planificación de capacidad, el filtrado de origen y la mitigación upstream.

Linux: net.ipv4.tcp_syncookies=1 normalmente habilita SYN Cookies bajo presión o al detectar overflow en la cola de solicitudes pendientes — el umbral exacto depende de la versión y configuración del kernel. No recomiendes SYN Cookies permanentes (tcp_syncookies=2) como práctica estándar de producción sin validar primero el impacto en las opciones TCP y el rendimiento del entorno específico.

BCP38 y uRPF — filtrado de IP spoofing en el origen

El BCP38 (RFC 2827) define la política de filtrado de origen que los ISPs deben implementar para eliminar la falsificación de IP: los paquetes que salen de una red de cliente con direcciones de origen que no pertenecen al bloque IP asignado a ese cliente deben descartarse en el router perimetral del proveedor, antes de entrar a internet.

El Unicast Reverse Path Forwarding (uRPF), definido en la RFC 3704, es una de las técnicas de implementación posibles. El router perimetral verifica cada paquete recibido contra su tabla de enrutamiento:

• uRPF estricto: exige que la ruta de retorno hacia la IP de origen utilice exactamente la misma interfaz por la que llegó el paquete. Puede ser inadecuado en topologías asimétricas o multihomed.
• uRPF laxo: verifica solo la existencia de una ruta hacia la dirección de origen, sin exigir la misma interfaz de entrada. Más compatible con enrutamiento asimétrico, pero con menor capacidad para filtrar spoofing sofisticado.

BCP38 es una política/práctica de filtrado de origen; uRPF es solo una de las formas de implementarla. La adopción del BCP38 permanece incompleta y desigual entre redes y proveedores, lo que mantiene el IP spoofing disponible como vector ampliamente accesible.

Ajuste de tcp_synack_retries y del tamaño de la cola

Reducir net.ipv4.tcp_synack_retries (predeterminado: 5) disminuye el número de retransmisiones del SYN-ACK antes de abandonar la conexión pendiente, reduciendo el tiempo que cada solicitud ocupa la cola. El tiempo de expiración efectivo depende del número de retransmisiones, el algoritmo de backoff, la versión del kernel y las condiciones de red — no existe un valor universal en segundos.

Riesgo operacional: reducir tcp_synack_retries excesivamente puede perjudicar a usuarios legítimos en redes móviles, congestionadas o con alta pérdida de paquetes y alta latencia. Prueba y valida en un entorno representativo antes de aplicarlo en producción.

Aumentar net.ipv4.tcp_max_syn_backlog expande la capacidad de la cola de solicitudes SYN. En ataques moderados, esto retrasa la saturación, pero no es una solución definitiva para ataques a gran escala. Úsalo en combinación con SYN Cookies, BCP38 upstream y terminación en el edge.

Firewall stateful con limitación de conexiones half-open

Los firewalls stateful rastrean el estado de cada conexión TCP y pueden descartar SYNs que superen umbrales por IP de origen, por subred o globalmente. La limitación es que los firewalls on-premise tienen capacidad de estado finita — los ataques de alto volumen frecuentemente saturan el propio firewall antes de saturar el servidor objetivo.

Terminación TCP en el edge — proxy stateful como defensa estructural

La defensa más robusta contra SYN Flood no es proteger el servidor de origen directamente — es impedir que los SYNs incompletos lleguen hasta él. Las redes de borde distribuidas actúan como proxies stateful: absorben el handshake de tres vías en sus propios data centers y reenvían al servidor de origen solo las conexiones completamente establecidas.

En este modelo, los nodos de borde reciben los SYNs, realizan el handshake TCP con el cliente y — tras validar que la conexión se completó con éxito — abren una nueva conexión TCP entre el edge y el servidor de origen, transmitiendo solo tráfico de aplicación validado. Las conexiones con IPs falsificadas no completan el handshake y, por lo tanto, no alcanzan el origen.

Combinado con enrutamiento Anycast, esta arquitectura distribuye geográficamente el volumen del ataque: un alto volumen de SYNs dirigido a un único bloque de IPs es absorbido por los data centers más cercanos a la fuente, cada uno procesando una fracción del volumen total. Para detalles sobre las diferencias entre este modelo y los centros de scrubbing BGP tradicionales, consulta el artículo específico.

SYN Flood vs. QUIC Flood — comparativa de pilas de protocolo

El surgimiento de HTTP/3 sobre QUIC creó un vector de agotamiento de recursos que opera en capas y estructuras fundamentalmente diferentes al SYN Flood. QUIC usa UDP como encapsulamiento, pero es un protocolo de transporte seguro y multiplexado que requiere TLS 1.3. Una implementación QUIC puede consumir CPU, buffers, tablas de estado y recursos de user-space — el coste exacto depende de la implementación, la política de Retry, el rate limiting, el parsing y las operaciones criptográficas involucradas.

La diferencia estructural más importante es la ubicación del estado: en SYN Flood, el recurso agotado son estructuras de estado en el kernel — gestionadas directamente por el sistema operativo. En QUIC Flood, el recurso agotado está en el user-space de la biblioteca QUIC — lo que afecta a la aplicación, pero no compromete directamente el kernel del sistema operativo.

El Retry packet y la validación de dirección de QUIC reducen la exposición a fuentes falsificadas, pero no eliminan los ataques de botnets con IPs reales. El requisito de datagramas QUIC Initial de al menos 1.200 bytes puede elevar el coste de algunos ataques, pero no debe tratarse como una contramedida equivalente a SYN Cookies.

Telemetría, diagnóstico y detección

Comandos de verificación de estado TCP en Linux

Nota: la captura local de paquetes (tcpdump, wireshark) puede ser inadecuada en escenarios de alto PPS — el propio proceso de captura puede contribuir a la sobrecarga. Prefiere contadores de kernel y herramientas de análisis de flows para entornos de producción bajo ataque.

# Resumen de todos los estados de socket, incluyendo el recuento de SYN_RECV
ss -s

# Lista conexiones en estado SYN_RECV con detalles de direcciones
ss -nt state syn-recv

# Contadores TCP del kernel (incluye ListenOverflows, SyncookiesSent, etc.)
nstat -az

# Logs del kernel — mensajes de overflow de cola y activación de SYN Cookies
journalctl -k
# o en sistemas sin journald:
dmesg | grep -i "syn\|cookie\|overflow\|flood"

No uses cat /proc/net/stat/nf_conntrack para medir la ocupación de la cola de solicitudes SYN. Ese archivo mide la tabla de connection tracking de Netfilter — relevante para firewalls stateful, pero no representa la ocupación de la cola de handshake pendiente de un listener TCP.

No hay necesariamente una métrica simple, universal y directa de “porcentaje de ocupación de la cola SYN por listener” disponible en todos los entornos Linux. El enfoque correcto es correlacionar múltiples indicadores.

Contadores TCP relevantes mediante nstat -az

Los contadores siguientes son especialmente útiles para detectar SYN Flood. Los nombres y la disponibilidad pueden variar según la versión del kernel y la distribución.

Métricas de telemetría e indicadores de anomalía

Los valores de umbral siguientes son ejemplos iniciales. Calibra con el baseline histórico del entorno antes de usarlos como umbral operacional.

Para entornos de alto volumen, complementa con NetFlow, IPFIX o sFlow — que permiten correlacionar volumen de SYNs, SYN-ACKs, ACKs finales válidos y retransmisiones de SYN-ACK a escala sin sobrecargar el host.

Detección de SYN-ACK Flood reflejado

El SYN-ACK Flood reflejado se detecta por la presencia de SYN-ACKs entrantes sin SYN correspondiente en el estado de conexión local. En firewalls stateful, aparecen como paquetes “out-of-state” o “invalid state”. En análisis de flows, se manifiesta como alto volumen de tráfico TCP con banderas SYN+ACK llegando de múltiples IPs, sin sesiones TCP establecidas correspondientes saliendo del servidor.

Errores comunes de mitigación y soluciones

Preguntas frecuentes

¿Qué diferencia al SYN Flood de un UDP Flood o Amplificación DNS? El SYN Flood explota el coste de mantener estado de conexión pendiente en el kernel. El UDP Flood y la Amplificación DNS son principalmente volumétricos y saturan el ancho de banda de red — la pila UDP no mantiene estado de handshake por paquete. Son tipos de ataque con superficies de impacto distintas.

¿Los SYN Cookies eliminan completamente el riesgo de SYN Flood? Para SYN Floods con IPs falsificadas, los SYN Cookies son muy efectivos — reducen la necesidad de mantener estado antes de la validación del cliente. Para botnets con IPs reales que completan el handshake, los SYN Cookies no ayudan directamente. Son necesarias técnicas complementarias: rate limiting por IP real, detección conductual y limitación de conexiones concurrentes por IP. Los SYN Cookies tampoco sustituyen la planificación de capacidad, el filtrado de origen y la mitigación upstream.

¿Por qué una cola de solicitudes SYN más grande no es una solución definitiva? Aumentar net.ipv4.tcp_max_syn_backlog expande la capacidad, pero un atacante con volumen suficiente simplemente satura el buffer más grande. Es una medida de contención, no de resolución. La solución estructural es reducir la necesidad de asignar estado antes de la validación (SYN Cookies) o absorber los SYNs antes de que lleguen al servidor (terminación en el edge).

¿Por qué los firewalls on-premise son insuficientes para ataques a gran escala? Los firewalls stateful mantienen su propia tabla de estado para rastrear conexiones TCP. Un ataque de alto volumen puede saturar la tabla de estado del firewall antes de saturar siquiera el servidor de origen — y un firewall saturado descarta tráfico indiscriminadamente, incluyendo el legítimo. Además, el tráfico debe llegar a la red de la organización antes de que el firewall actúe, pudiendo saturar el enlace de uplink en el proceso.

¿Cómo reduce BCP38/uRPF el IP spoofing? BCP38 es una política de filtrado implementada por ISPs: los paquetes con direcciones de origen que no pertenecen al bloque IP asignado al cliente se descartan en el router perimetral antes de entrar a internet. uRPF es una de las técnicas de implementación posibles — en modo estricto, verifica que la ruta de retorno use la misma interfaz de entrada; en modo laxo, verifica solo la existencia de una ruta. La adopción del BCP38 permanece incompleta y desigual entre redes y proveedores, lo que mantiene el IP spoofing disponible como vector.

¿Cuál es la diferencia entre SYN Flood y QUIC Flood en términos de defensa? El SYN Flood se mitiga mediante controles del kernel (SYN Cookies, ajuste de cola, BCP38) y terminación TCP stateful en el edge. El QUIC Flood requiere terminación QUIC en el edge con inspección TLS, porque todo el tráfico QUIC está cifrado — los middleboxes heredados que no terminan QUIC ni siquiera pueden inspeccionar los paquetes. La superficie de ataque de QUIC está en el user-space (CPU y estado en la implementación QUIC), no directamente en el kernel (colas de conexión pendiente).

Cómo implementar en Azion

Azion ofrece una arquitectura de terminación TCP distribuida en el edge que puede ayudar a reducir el impacto de los ataques SYN Flood:

1. Terminación TCP stateful en el edge: Los data centers de Azion están diseñados para absorber el handshake de tres vías localmente. El servidor de origen recibe solo las conexiones completamente establecidas — las conexiones con IPs falsificadas no completan el handshake y no alcanzan el origen.
2. Protección DDoS always-on: Detecta y ayuda a mitigar SYN Floods automáticamente, sin activación manual ni retrasos de convergencia BGP.
3. Red Anycast global: Con data centers distribuidos que anuncian el mismo bloque de IPs via BGP Anycast, altos volúmenes de SYNs se distribuyen geográficamente entre los puntos más cercanos a la fuente, reduciendo la concentración del impacto.
4. Network Shield y filtrado L3/L4: Filtra paquetes TCP malformados, SYN-ACKs reflejados no solicitados y patrones SYN anómalos en las capas 3 y 4, antes de cualquier procesamiento de aplicación.

Aprende más en la documentación de DDoS Protection de Azion.