SYN-Flood.

Bei einem SYN-Flood öffnet der Angreifer sehr viele TCP-Verbindungen, schließt sie aber nie ab. Jedes gespoofte oder unbeantwortete SYN zwingt den Server, einen halb offenen Eintrag in seiner Backlog-Queue anzulegen und mit SYN/ACK zu antworten, während er auf ein finales ACK wartet, das nie eintrifft. Ist der Backlog voll, weist der Server neue legitime Verbindungen ab. SYN-Floods können von einem einzelnen Host ausgehen oder, häufiger, aus einem Botnet, wobei die Quell-IPs gespooft werden, um die Filterung zu erschweren.

flowchart TD
  A[Angreifer] -->|"1. SYN (gespoofte Quell-IP)"| S[Zielserver]
  S -->|"2. SYN/ACK an gespoofte IP"| V[Nicht existenter / stiller Host]
  S -.->|3. legt halb offenen Eintrag an| Q[(Backlog-Queue)]
  V -.->|finales ACK trifft nie ein| S
  A -->|Wiederholung mit hoher Rate| S
  Q -->|Queue voll| R[Neue legitime Clients abgewiesen]

Der Angriff wurde erstmals 1996 durch Exploit-Code im Magazin Phrack öffentlich bekannt; im September 1996 legte ein Flood tagelang die Mailserver des New Yorker ISP Panix lahm, was die CERT-Empfehlung CA-1996-21 auslöste. Die maßgebliche Referenz ist RFC 4987 (2007), "TCP SYN Flooding Attacks and Common Mitigations", die Gegenmaßnahmen und ihre Kompromisse aufzeigt. Die wirksamste Verteidigung auf Host-Seite sind SYN-Cookies, entwickelt von Daniel J. Bernstein: Statt Zustand zu speichern, kodiert der Server die Verbindungsparameter in die initiale Sequenznummer des SYN/ACK und rekonstruiert sie aus dem ACK des Clients, sodass erst nach Abschluss des Handshakes ein Backlog-Eintrag belegt wird. Weitere Gegenmaßnahmen sind größere oder dynamisch dimensionierte SYN-Queues, Connection-Rate-Limiting an Firewalls und Load Balancern, zustandsloses Filtern am Netzrand sowie Upstream-DDoS-Scrubbing.