SYN-Flood-Angriff: Funktionsweise – und warum er als Belastungstest wenig taugt

Ein SYN-Flood-Angriff bringt keine einzige Verbindung zustande. Er schickt das erste Paket des TCP-Handshakes, tausendfach pro Sekunde, von Absenderadressen, die es nicht gibt, und meldet sich danach nie wieder. Jedes dieser Pakete zwingt den Server, einen Platz für einen Client freizuhalten, der nie antworten wird.

Er gehört zu den ältesten Angriffen im Internet und ist noch immer einer der häufigsten. Cloudflares DDoS-Bericht für das zweite Quartal 2025, veröffentlicht am 15. Juli 2025, führt SYN-Floods mit 27 Prozent aller Angriffe auf Netzwerkebene auf Platz zwei der Vektoren, nach 31 Prozent im Quartal davor.

Dieser Beitrag ist ein Erklärstück und kein Teil unserer zehnteiligen Simulationsserie: Ein SYN-Flood gehört nicht zu den zehn Typen, die Obsidio ausführt, und der Grund dafür ist die nützlichste Erkenntnis dieses Textes. Wie die Vektorfamilien zusammenhängen, zeigt unser Überblick über die Arten von DDoS-Angriffen; wie Sie einen ersten autorisierten Durchlauf aufsetzen, beschreibt der Leitfaden zum Thema DDoS-Schutz testen.

Wie ein SYN-Flood technisch abläuft

Jede TCP-Verbindung beginnt mit einem Austausch in drei Schritten. Der Client sendet ein SYN und meldet damit an, dass er reden will. Der Server antwortet mit einem SYN-ACK, signalisiert Bereitschaft und reserviert Speicher für die kommende Verbindung. Der Client bestätigt mit einem abschliessenden ACK, und die Verbindung steht.

Zwischen Schritt zwei und Schritt drei ist die Verbindung halboffen: Der Server hat Zustand angelegt und wartet. Dieser Zustand liegt in einer Warteschlange pro Listener, üblicherweise SYN-Backlog genannt; unter Linux steht jeder Eintrag im Zustand SYN_RECV, bis das ACK eintrifft oder der Eintrag verfällt.

Ein SYN-Flood sendet Schritt eins und niemals Schritt drei. Jedes Paket umfasst rund 40 Byte und kostet den Absender praktisch nichts. Den Server kostet es einen Backlog-Eintrag, der so lange belegt bleibt, wie der Kernel das SYN-ACK wiederholt.

Unter Linux ist tcp_synack_retries die zuständige Stellschraube. Die Sysctl-Referenz des Kernels nennt den Standardwert 5; das entspricht 31 Sekunden bis zur letzten Wiederholung, bei einer anfänglichen RTO von 1 Sekunde («which corresponds to 31 seconds till the last retransmission with the current initial RTO of 1 second»). Eine halbe Minute Belegung pro Paket, ohne Aufwand für den Angreifer – und die Pakete kommen zu Tausenden.

Ist der Backlog voll, verwirft der Kernel weitere SYN-Pakete. Von aussen ist die Site schlicht nicht erreichbar. Von innen betrachtet: CPU niedrig, Bandbreite niedrig, Anwendungslogs ruhig. Defekt ist nichts – der Server nimmt nur keine neuen Verbindungen mehr an.

Stellen Sie sich einen Empfang vor, auf dessen Pult zwanzig Notizzettel Platz haben. Zwanzig Anrufer sagen «Moment, ich nenne Ihnen gleich meinen Namen» und melden sich nie wieder. Der Empfang ist nicht ausgelastet; das Pult ist voll, und der einundzwanzigste Anrufer wird abgewiesen.

Warum gefälschte Absenderadressen den Ausschlag geben

Der Angriff steht und fällt damit, dass die Antwort des Servers ins Leere geht. RFC 4987, «TCP SYN Flooding Attacks and Common Mitigations», veröffentlicht im August 2007, formuliert das unmissverständlich: «For an effective attack, it is important that the spoofed IP addresses be unresponsive to the SYN-ACK segments.» Gehört die gefälschte Adresse einem laufenden Host, erhält dieser ein SYN-ACK, das er nicht angefordert hat, kann es nicht zuordnen und schickt einen Reset. Der Reset gibt den Backlog-Eintrag sofort frei, und der Angriff bricht in sich zusammen.

Angreifer fälschen deshalb Adressen, hinter denen nichts steht: nicht zugewiesener Adressraum oder Bereiche, in denen kein Host lauscht. Daraus folgt dreierlei, das man im Kopf behalten sollte.

• Ratenbegrenzung pro Quelle findet nichts zum Zählen. Jedes Paket scheint von einer anderen Adresse zu kommen, und keine dieser Adressen sendet je ein zweites.
• Blocklisten sind nutzlos und obendrein riskant. Die Adressen in Ihren Logs haben den Verkehr nie gesendet. Wer sie sperrt, trifft unbeteiligte Netze und mitunter die eigenen Nutzer.
• Der Angriff setzt voraus, dass sich Absenderadressen überhaupt fälschen lassen. Das hängt von dem Netz ab, aus dem der Angreifer sendet, nicht von Ihrer Abwehr.

Die älteste strukturelle Gegenmassnahme liegt deshalb nicht beim Opfer. RFC 2827, besser bekannt als BCP 38, veröffentlicht im Mai 2000, verlangt von jedem Netz, den ausgehenden Verkehr so zu filtern, dass darin nur Absenderadressen aus den Bereichen vorkommen, die dem Netz tatsächlich zugeteilt sind. Nach einem Vierteljahrhundert ist die Umsetzung lückenhaft. Das Spoofer-Projekt von CAIDA misst laufend von freiwilligen Messpunkten aus, ob Netze gefälschte Absenderadressen durchlassen; seine Übersichtsseite wies am 29. Juli 2026 aus, dass sich aus 233 von 1’430 getesteten IPv4-Blöcken gefälschte Pakete versenden liessen, rund jeder sechste Block, wenn man die NAT-Fälle herausrechnet.

Ein Satz zur Vorgeschichte: Das CERT-Advisory CA-1996-21 dokumentierte SYN-Flooding und IP-Spoofing im September 1996, ausgelöst unter anderem von einem Angriff, der die Mailserver des New Yorker Providers Panix lahmlegte.

Dreissig Jahre später führt Cloudflares Bericht zum dritten Quartal 2025 vom 3. Dezember 2025 SYN-Floods weiterhin auf Platz drei der Netzwerkvektoren, hinter UDP- und DNS-Floods und vor ICMP. Zusammen machten diese vier gut die Hälfte aller Angriffe auf Netzwerkebene aus, in einem Quartal, in dem Cloudflare insgesamt 8,3 Millionen Angriffe abwehrte.

Welche Ihrer Schutzmassnahmen hätte das abfangen müssen?

Es lohnt sich, die ganze Kette abzuschreiten, auf die eine solche Last trifft. Bei den meisten Angriffen dieser Serie fällt die Antwort unbequem aus; hier fällt sie überwiegend beruhigend aus, und das klar zu sagen ist wichtiger, als jede Schutzschicht schlecht aussehen zu lassen.

Vergleichen Sie dieses Raster mit dem im Beitrag zu Slowloris: Die Urteile kehren sich weitgehend um. Volumenbasiertes Scrubbing ist gegen einen langsamen Angriff blind und gegen einen SYN-Flood entscheidend. Genau diese Umkehrung ist das Argument dafür, über die Vektorfamilien hinweg zu testen.

Wie wehrt man einen SYN-Flood ab?

Vier Massnahmen tragen fast das ganze Gewicht, und drei davon sind in einer aktuellen Standardinstallation bereits aktiv.

• SYN-Cookies. Statt Zustand für eine halboffene Verbindung zu speichern, codiert der Server das Nötige in die Sequenznummer seines eigenen SYN-ACK und vergisst die Verbindung. Trifft ein legitimes ACK ein, rekonstruiert er den Zustand aus der Zahl, die der Client zurückspiegelt. RFC 4987 nennt auch die Grenzen: Einige TCP-Optionen vertragen sich damit nicht, und Daten, die huckepack auf dem SYN mitkommen, werden nicht behandelt. Unter Linux steht tcp_syncookies standardmässig auf 1; die Kernel-Dokumentation beschreibt das so, dass Cookies verschickt werden, sobald die SYN-Backlog-Queue eines Sockets überläuft («when the syn backlog queue of a socket overflows») – normale Verbindungen bleiben also unberührt.
• Backlog-Dimensionierung. tcp_max_syn_backlog begrenzt pro Listener, wie viele SYN_RECV-Anfragen sich der Kernel merkt. Die Kernel-Dokumentation nennt ein Minimum von 128 auf Maschinen mit wenig Speicher, ansteigend mit dem verfügbaren Speicher. Den Wert zu erhöhen verschafft Spielraum, und nur Spielraum: Eine grosse Warteschlange läuft langsamer voll als eine kleine, aber sie läuft voll. Dass typische Standardwerte damals zwischen einem halben Dutzend und mehreren Dutzend lagen («from a half-dozen to several dozen»), wie es RFC 4987 anmerkt, erinnert daran, wie viel sich hier bereits verbessert hat.
• Schnelleres Verfallen halboffener Einträge. Ein niedrigeres tcp_synack_retries verkürzt, wie lange jeder unbeantwortete Handshake einen Platz belegt. Der Preis ist real: Clients in wirklich verlustreichen Mobilfunknetzen brauchen diese Wiederholungen mitunter. Das ist ein Kompromiss, kein Gewinn.
• SYN-Proxying am Netzrand. Ein Scrubbing-Dienst oder eine geeignete Appliance schliesst den Handshake stellvertretend ab und leitet nur Verbindungen weiter, die ein Client tatsächlich fertiggestellt hat. Das ist die stärkste Massnahme, weil die Flut auf Infrastruktur endet, die dafür dimensioniert ist. Sie hat dieselbe Voraussetzung wie jede andere Abwehr am Netzrand: eine Adresse des Ursprungsservers, die sich nicht daran vorbei erreichen lässt.

An genau dieser Voraussetzung scheitern reale Installationen. Ein geschützter Hostname vor einem Ursprungsserver, dessen Adresse weiterhin auf Port 443 antwortet, ist nicht geschützt, und kein Konfigurations-Review macht das sichtbar.

Warum ein SYN-Flood-Angriff die Verbindungskapazität nicht prüft

Jetzt zu dem Teil, der zählt, wenn Sie einen Resilienztest planen und kein Glossar lesen. Ein SYN-Flood misst genau eines: ob das erste Gerät, das TCP terminiert, es übersteht, sich Handshakes merken zu müssen, die nie fertig werden. 2026 lautet die Antwort meistens Ja, weil es SYN-Cookies gibt und Proxying am Netzrand funktioniert.

Vollständig aufgebaute Verbindungen sind ein anderes Problem. Eine etablierte, untätige TCP-Verbindung belegt auf dem Server einen Socket und einen File Descriptor, dazu einen Eintrag in der Connection-Tracking-Tabelle jedes zustandsbehafteten Geräts auf dem Pfad und einen Platz in jedem Verbindungslimit, ob pro IP oder global. Dagegen helfen SYN-Cookies nicht, denn aus Sicht des Stacks sind diese Verbindungen völlig legitim: Echte Hosts haben sie geöffnet und tatsächlich geantwortet.

Deshalb enthält Obsidios Katalog den TCP Connection Flood und keinen SYN-Flood. Die Simulation öffnet reine TCP-Verbindungen, schliesst den Handshake ab und hält jeden Socket bis zum konfigurierten Timeout untätig offen, bevor sie ihn durch einen neuen ersetzt, standardmässig zehn Minuten lang und mit bis zu hundert Sockets pro Worker. Weil der Verkehr von über 100’000 weltweit verteilten echten Geräten mit echten, routbaren Adressen stammt, treffen Verbindungslimits pro IP auf echte Quellenvielfalt statt auf eine Handvoll Rechenzentrums-Hosts, und die Conntrack-Tabellen aller Geräte auf dem Pfad füllen sich mit Einträgen, die kein Cookie-Trick wieder loswird.

Ein TLS-Flood geht eine Schicht weiter: Er schliesst die TLS-Aushandlung ab und lässt den Server rund das Fünfzehnfache der Kryptokosten des Clients aufwenden, bevor er die Verbindung abreisst. Halboffen, vollständig offen und vollständig ausgehandelt prüfen drei verschiedene Ressourcen.

Was Sie selbst prüfen können und wo die Prüfung täuscht

Zwei dieser Fragen können Sie heute ohne jeden Testverkehr beantworten. Es lohnt sich zu wissen, welche.

Lesen Sie die Konfiguration. Prüfen Sie, ob tcp_syncookies aktiv ist, sehen Sie sich Ihre tatsächlichen Backlog- und Retry-Werte an, und nehmen Sie die Limits der Zustandstabellen auf jedem zustandsbehafteten Gerät im Pfad dazu, nicht nur auf dem Server. Damit wissen Sie, dass die Einstellungen existieren. Sie wissen nicht, welches Limit das kleinste ist, und das kleinste entscheidet den Ausgang.

Sorgen Sie dafür, dass Ihr Ursprungsserver nicht direkt erreichbar ist. Wenn ein Dienst am Netzrand die Massnahme ist, auf die Sie sich verlassen, prüfen Sie von aussen, ob die Adresse des Ursprungsservers antwortet. Das ist ein echter Test einer echten Abhängigkeit, und er kommt ohne Angriffsverkehr aus.

Testen Sie die Alarmkette für sich. Lösen Sie einen synthetischen Alarm an den Pikettdienst aus und sehen Sie nach, ob jemand reagiert. Das prüft den Meldeweg. Ob es einen Schwellenwert für den TCP-Verbindungszustand gibt, also für das Signal, das sich hier bewegt hätte, sagt es nicht.

Interessanter ist, was ein kleiner Eigenversuch falsch einschätzt. Verkehr von ein oder zwei Hosts fangen quellenbasierte Massnahmen sofort ab, und der vordere Teil der Kette wirkt tadellos. Dieser Schluss steht auf dem Kopf: Gerade diese Massnahmen verhalten sich gegenüber echter Quellenvielfalt anders.

Wie Obsidio die Verbindungsschicht prüft

Obsidio führt Simulationen zur Verbindungserschöpfung als kontrollierte, autorisierte Tests gegen Infrastruktur aus, die dem Kunden gehört. Die Domain-Inhaberschaft wird per DNS-TXT-Eintrag verifiziert, bevor das erste Paket fliesst. Laut Plattform-FAQ beginnen die meisten Institute in einem kontrollierten Zeitfenster mit bewusst niedrig gesetzten Limits und steigern die Last schrittweise; über Live-Metriken lässt sich ein Durchlauf jederzeit sofort abbrechen.

Bei einem TCP-Connection-Flood-Test ist die Kurve der Anfragerate der falsche Ort zum Hinschauen: Sie zählt Socket-Öffnungen statt Durchsatz und bleibt gerade dann unscheinbar, wenn der Test gelingt. Beobachten Sie aktive und maximale gleichzeitige Verbindungen, und zwar zusammen mit der Auslastung der Verbindungstabellen auf Ihrem eigenen Load Balancer und Ihrer Firewall. Erst diese Kombination zeigt, welches Limit zuerst greift.

Zwei Antworten kann nur Ihre eigene Seite liefern. Obsidio kann berichten, was Ihre Abwehr am Netzrand getan hat und wie viele Verbindungen gehalten wurden; das ist von aussen beobachtbar. Ob Ihr SIEM etwas aufgezeichnet hat und ob jemand alarmiert wurde, steht nur in Ihren eigenen Konsolen, also muss während des Zeitfensters jemand hineinschauen.

Stärke wird bewiesen, nicht versprochen. Ein SYN-Flood fragt, ob Ihr Kernel einen Handshake vergessen kann. Die härtere Frage lautet, was geschieht, wenn hunderttausend echte Geräte einen abschliessen und sich weigern aufzulegen – und genau die misst Obsidio.

Wo der SYN-Flood in ein Testprogramm gehört

Behandeln Sie den klassischen SYN-Flood als Massnahme, die Sie verifizieren, und nicht als Szenario, das Sie proben. Prüfen Sie, ob Cookies aktiv sind, ob Ihr Netzrand Handshakes stellvertretend beantwortet und ob Ihr Ursprungsserver daran vorbei erreichbar ist, und gehen Sie weiter. Cloudflares Bericht zum vierten Quartal 2025 vom 5. Februar 2026 zählte 47,1 Millionen DDoS-Angriffe im Jahr; die Angriffe auf Netzwerkebene stiegen auf 34,4 Millionen, nach 11,4 Millionen im Jahr 2024. Das Volumen ist also real. Die Abwehr ist aber ebenso ausgereift, und ein Testfenster ist hier schlecht investiert.

Die Erschöpfungstests, die ein Zeitfenster wert sind, setzen an legitimen Verbindungen an, denn kein Cookie, keine Challenge und keine Reputationsliste kann sie von Ihren Kunden unterscheiden. In solchen Durchläufen zeigt sich, ob ein Limit pro IP, ein Conntrack-Limit oder die Session-Tabelle eines Load Balancers die Zahl ist, an der die Verfügbarkeit Ihres Dienstes hängt.

Für regulierte Institute muss der Durchlauf zudem eine Spur hinterlassen. Obsidio erstellt kryptografisch attestierte Berichte, bei denen jede nachträgliche Änderung erkennbar ist, erzeugt in Trusted Execution Environments und mit Zuordnung zu FINMA, DORA und NIS2. Das Ergebnis eines Tests ist damit ein Nachweis zum Ablegen und kein Screenshot, für den jemand bürgen muss.

Wenn Sie eine autorisierte Simulation zur Verbindungserschöpfung gegen Ihre eigene Infrastruktur planen möchten, finden Sie mehr zur Obsidio-Plattform, oder nehmen Sie Kontakt mit dem Team auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.