SYN Flood.

Dans un SYN flood, l'attaquant ouvre — mais ne termine jamais — de très nombreuses connexions TCP. Chaque SYN usurpé ou non confirmé force le serveur à réserver une connexion semi-ouverte dans sa file de backlog et à répondre par un SYN/ACK, en attente d'un ACK final qui n'arrive jamais. Quand la file se remplit, le serveur refuse les nouvelles connexions légitimes. Un SYN flood peut venir d'un seul hôte ou, plus souvent, d'un botnet, avec des IP sources usurpées pour entraver le filtrage.

flowchart TD
  A[Attaquant] -->|"1. SYN (IP source usurpée)"| S[Serveur cible]
  S -->|"2. SYN/ACK vers l'IP usurpée"| V[Hôte inexistant / silencieux]
  S -.->|3. réserve une entrée semi-ouverte| Q[(File de backlog)]
  V -.->|l'ACK final n'arrive jamais| S
  A -->|répétition à haut débit| S
  Q -->|file pleine| R[Nouveaux clients légitimes refusés]

L'attaque a été rendue publique pour la première fois en 1996 via du code d'exploitation publié dans le magazine Phrack ; en septembre 1996, un flood a mis hors service pendant plusieurs jours les serveurs de messagerie du FAI new-yorkais Panix, donnant lieu à l'avis CERT CA-1996-21. La référence de fond est la RFC 4987 (2007), « TCP SYN Flooding Attacks and Common Mitigations », qui passe en revue les contre-mesures et leurs compromis. La défense la plus efficace côté hôte est l'usage des SYN cookies, conçus par Daniel J. Bernstein : au lieu de conserver un état, le serveur encode les paramètres de connexion dans le numéro de séquence initial du SYN/ACK et les reconstruit à partir de l'ACK du client, de sorte qu'aucune entrée de backlog n'est consommée tant que la poignée de main n'est pas terminée. Les autres mesures d'atténuation comprennent des files SYN plus grandes ou dimensionnées dynamiquement, la limitation du débit de connexions sur les pare-feu et les répartiteurs de charge, le filtrage sans état en bordure de réseau et le scrubbing DDoS en amont.