¿Qué es un ataque TCP SYN Flood?
El SYN Flood es uno de los ataques de denegación de servicio (DDoS) más antiguos y efectivos. Explota el saludo de tres vías (three-way handshake) del protocolo TCP: el atacante envía una avalancha de paquetes SYN falsificando la dirección de origen, el servidor responde con SYN-ACK y reserva recursos esperando un ACK que nunca llega. Al acumularse miles de conexiones a medio abrir, la tabla de conexiones se satura y el servidor deja de aceptar tráfico legítimo.
¿Cómo funciona paso a paso?
El atacante genera paquetes SYN con IP de origen falsificada (spoofing) para que las respuestas SYN-ACK se pierdan o vayan a víctimas terceras. Cada conexión a medio abrir consume memoria en la cola de backlog del sistema operativo. Sin defensas, bastan unos pocos miles de paquetes por segundo para agotar esa cola y provocar la caída del servicio, incluso desde una sola máquina con ancho de banda modesto.
¿Cómo mitigar un SYN Flood?
Las defensas clásicas son las SYN cookies (el servidor no reserva estado hasta completar el handshake), aumentar el tamaño del backlog, reducir el tiempo de espera de conexiones a medio abrir, y filtrar tráfico con firewalls y rate limiting. En volúmenes altos hace falta un servicio anti-DDoS en el borde (scrubbing) que absorba y limpie el tráfico antes de que llegue al origen.
Cómo funcionan las SYN cookies por dentro
En lugar de guardar la conexión a medio abrir en memoria, el servidor codifica la información necesaria dentro del propio número de secuencia que envía en el SYN-ACK: una marca de tiempo gruesa, el tamaño máximo de segmento y un hash criptográfico de las direcciones y puertos. Si el cliente responde, el ACK devuelve ese número incrementado, y el servidor reconstruye la conexión validando el hash sin haber reservado nada. El coste es perder algunas opciones de TCP negociadas en el handshake, por lo que muchos sistemas solo las activan cuando la cola de backlog empieza a llenarse.
¿Cómo se detecta mientras está ocurriendo?
La señal más directa es un número alto y sostenido de conexiones en estado SYN_RECV, visible con `ss -n state syn-recv | wc -l` o `netstat -an | grep SYN_RECV`. A eso se suman una proporción anómala de paquetes SYN frente a ACK, direcciones de origen que nunca completan el saludo y, en el registro del núcleo, mensajes de desbordamiento de la cola. Conviene vigilar que la CPU no esté saturada: a diferencia de un ataque volumétrico, un SYN Flood puede tumbar el servicio sin agotar el ancho de banda, lo que despista si solo se mira el gráfico de tráfico.
Por qué sigue funcionando después de treinta años
Porque no explota un fallo de programación que se pueda parchear, sino el diseño del propio protocolo: TCP necesita reservar estado para una conexión que todavía no está confirmada. Sus variantes se mantienen vigentes —SYN-ACK flood y ACK flood contra cortafuegos con estado, o la reflexión que usa a terceros como amplificadores— y el coste para el atacante sigue siendo mínimo, ya que los paquetes son pequeños y la IP de origen va falsificada. Por eso la defensa no consiste en eliminarlo sino en encarecerlo y absorberlo.
