Inundación SYN (SYN flood).

En una inundación SYN, el atacante abre —pero nunca termina— gran cantidad de conexiones TCP. Cada SYN falsificado o sin respuesta obliga al servidor a reservar una conexión semiabierta en su cola de backlog y responder con SYN/ACK, a la espera de un ACK final que nunca llega. Cuando la cola se llena, el servidor rechaza nuevas conexiones legítimas. Las inundaciones SYN pueden originarse en un único host o, más habitualmente, en una botnet, con direcciones IP de origen falsificadas para dificultar el filtrado.

flowchart TD
  A[Atacante] -->|"1. SYN (IP origen falsificada)"| S[Servidor objetivo]
  S -->|"2. SYN/ACK a la IP falsificada"| V[Host inexistente / silencioso]
  S -.->|3. reserva entrada semiabierta| Q[(Cola de backlog)]
  V -.->|el ACK final nunca llega| S
  A -->|repite a alta velocidad| S
  Q -->|cola llena| R[Clientes legítimos rechazados]

El ataque se hizo público por primera vez en 1996 a través de código de explotación en la revista Phrack; en septiembre de 1996 una inundación dejó fuera de servicio durante días los servidores de correo del ISP neoyorquino Panix, lo que motivó el aviso CERT CA-1996-21. La referencia definitiva es la RFC 4987 (2007), "TCP SYN Flooding Attacks and Common Mitigations", que repasa las contramedidas y sus compromisos. La defensa más eficaz del lado del host son las SYN cookies, ideadas por Daniel J. Bernstein: en lugar de almacenar estado, el servidor codifica los parámetros de la conexión en el número de secuencia inicial del SYN/ACK y los reconstruye a partir del ACK del cliente, de modo que no se consume ninguna entrada del backlog hasta que el handshake se completa. Otras mitigaciones incluyen colas SYN más grandes o de tamaño dinámico, limitación de la tasa de conexiones en firewalls y balanceadores de carga, filtrado sin estado en el borde de la red y servicios de scrubbing de DDoS en el operador.