Auf dieser Seite
Das Wichtigste
- TCP ist statefulJede neue Session kann Zustand auf Server, Firewall oder Load Balancer verbrauchen.
- PPS zählt wie GbpsEin SYN-Flood kann eine TCP-Umgebung mit moderater Bandbreite, aber hoher Paketzahl brechen.
- Filterung muss früh erfolgenEine Server-Regel reicht nicht, wenn Port, Router oder Firewall vorher sättigen.
- Verfügbarkeit ist das ZielMitigation muss echte Handshakes erhalten, nicht nur Graphen verschönern.
Definition des Problems: Was ein SYN-Flood wirklich erschöpfen will
Ein SYN-Flood zielt auf den TCP-Verbindungsaufbau. Normal sendet ein Client SYN, der Server antwortet SYN-ACK und der Client bestätigt mit ACK. Während des Angriffs erhält die Zieladresse ungewöhnlich viele SYN-Pakete, oft von gespooften, verteilten oder instabilen Quellen. Server oder Zwischengeräte behalten dann Zustand für Verbindungen, die nie abgeschlossen werden.
Das Ergebnis ist nicht nur mehr Traffic. Es entsteht Druck auf Verbindungsressourcen: State Tables, TCP-Backlog, Firewall-CPU, Queues, Speicher, NAT, Load Balancer, Reverse Proxies oder Webserver. Selbst wenn die Gbps unter der beworbenen Kapazität bleiben, können Pakete pro Sekunde und unvollständige Zustände den Dienst unbrauchbar machen.
Moderne SYN-Floods können mit anderen Vektoren kombiniert werden. Eine UDP-Welle sättigt den Link, während SYN-Traffic stateful Komponenten erschöpft. Eine Verteidigung nur nach Durchschnittsbitrate oder pauschalem Port-Block reicht dann nicht. Man muss wissen, wo die Sättigung entsteht und welche Schicht zuerst entlastet werden muss.
- Backlog-Erschöpfung
- Zu viele unvollständige Handshakes verhindern, dass echte Clients Platz in der TCP-Queue bekommen.
- Druck auf stateful Geräte
- Firewalls, NAT und Load Balancer können vor dem Origin ausfallen.
- Gespoofte oder verteilte Quellen
- Pakete kommen von vielen IPs, teils gefälscht, sodass Quell-IP-Blocking unzuverlässig wird.
Warum das für online verkaufende Infrastruktur wichtig ist
Für Endnutzer wirkt ein SYN-Flood nicht wie ein Netzwerkangriff. Er wirkt wie eine nicht ladende Seite, ein Panel ohne Verbindung, eine API mit Timeout, ein instabiler Game-Service oder ein professioneller Dienst, der offline erscheint. Wenn der Dienst Leads, Kunden oder Umsatz erzeugt, reichen wenige Minuten Ausfall für Vertrauensverlust.
TCP ist überall: Websites, APIs, SSH, Panels, Proxies, Load Balancer, Tunnel und Business-Dienste. Zu aggressive Mitigation erzeugt schnell False Positives. Einen exponierten TCP-Port zu blockieren stoppt vielleicht den Angriffsgraphen, schaltet aber auch den Service ab. Das Design muss genügend Kapazität und Präzision erhalten, damit legitime Clients weiter Sessions aufbauen.
Für Wachstum über Online-Sichtbarkeit, LinkedIn oder X ist das besonders wichtig. Ein mühsam gewonnener Interessent muss erreichbare Infrastruktur vorfinden. DDoS-Schutz wird damit genauso kommerziell wie technisch: Er schützt Conversion, Glaubwürdigkeit und Kontinuität.
| Symptom | Zu einfache Deutung | Echte Priorität |
|---|---|---|
| TCP-Timeouts | Der Webserver ist langsam | Backlog, Firewall, Load Balancer und Upstream-Sättigung prüfen |
| Hohe Firewall-CPU | Mehr CPU reicht | Vor dem stateful Gerät filtern, wenn der Angriff dessen Rolle übersteigt |
| Wenig Gbps, Dienst down | Der DDoS ist nicht groß | PPS und unvollständige Zustände betrachten |
| Legitime Verbindungen abgelehnt | Härter blocken | Angriffssignaturen von plausiblen Öffnungen trennen |
Mögliche Lösungen gegen SYN-Floods
Die erste bekannte Antwort sind TCP-Schutzmechanismen auf Systemebene: SYN-Cookies, Backlog-Tuning und Kernel-Schwellenwerte. Sie sind nützlich, lösen aber nicht alles. Sie verhindern zu frühe Ressourcenreservierung am Server, schützen jedoch nicht Link, Router, Firewall oder Load Balancer, wenn der Angriff bereits zu tief in die Architektur gelangt.
Rate Limiting kann offensichtliches Rauschen reduzieren. Es wird riskant, wenn legitimer Traffic tatsächlich wächst oder der Angriff normale Öffnungen imitiert. Ein zu niedriger Schwellenwert blockt Nutzer, ein zu hoher schützt nicht. Rate Limiting muss pro Service, Port, erwartetem Verhalten und Kapazität kontextualisiert werden.
ACLs, stateless Filtering, Paketgrößen, TCP-Flags und Netzmerkmale können früh angewendet sehr effektiv sein. Sie müssen aber präzise sein. Eine zu breite Regel kappt Nutzer oder bricht spezielle Dienste. Deshalb werden Upstream-Filterung, Scrubbing und saubere Übergabe bei ernsthafter Exposition notwendig.
- SYN-Cookies und Kernel-Tuning
- Hilfreich zur Härtung des Origins, aber nicht genug gegen Upstream-Sättigung.
- Kontextuelles Rate Limiting
- Wirksam, wenn Schwellenwerte zum echten Service passen.
- Frühes stateless Filtering
- Reduziert Druck, bevor Geräte Zustand für Rauschen halten.
- Geschützter Transit oder Scrubbing
- Reinigt Traffic vor Produktion und liefert nur nutzbare Flows.
TCP-Filterung für den realen Dienst, nicht für eine generische Regel
Traffic kann je nach Architektur über Anti-DDoS-geschützten IP-Transit mit BGP, geschützte IPs, GRE/IPIP/VXLAN-Tunnel oder Cross-Connect eintreten. Der Wert liegt darin, Mitigation vor die empfindlichsten Kundengeräte zu setzen. Sauberer Traffic wird anschließend in einem lesbaren Handoff-Modell zurückgegeben.
Bei sehr volumetrischen oder High-PPS-Wellen kann die Filterung mit Upstream-Entlastung kombiniert werden. Der Einsatz muss präzise, temporär und verhältnismäßig bleiben: Es geht nicht darum, den Kunden zu blackholen, sondern den Angriff so zu reduzieren, dass feine Mitigation die Kontrolle behält.
Je nach Kunde kann dieselbe Logik BGP-fähigen IP-Transit, einen exponierten dedizierten Server, ein Webpanel, eine API oder einen Gaming-Dienst mit stabilen TCP-Verbindungen wie Minecraft schützen. Entscheidend ist der richtige Filterpunkt und das passende Modell für sauberen Traffic statt einer generischen Regel für die gesamte Infrastruktur.
- erkennen, wo Druck entsteht: Link, Firewall, Load Balancer, Kernel oder Anwendung
- klar illegitimen Traffic möglichst früh filtern
- teure stateful Logik auf dem Hot Path vermeiden
- saubere Übergabe per Cross-Connect, GRE, IPIP, VXLAN oder Router-VM erhalten
- Profil an den Service anpassen statt ein Modell für alle Kunden zu kopieren
Konkreter Use Case: Webservice und Kundenpanel unter SYN-Flood
Ein Hostinganbieter oder eine SaaS-Plattform betreibt Website, Kundenpanel und mehrere exponierte TCP-Dienste. Der Angriff startet mit moderaten Gbps, aber extrem vielen SYN pro Sekunde. Der Link ist nicht unbedingt voll, trotzdem sehen Kunden Timeouts. Die stateful Firewall verbraucht CPU und der Load Balancer hält zu viele unvollständige Zustände.
Das Ergebnis hängt von Service, Volumen, Pfad und legitimem Verhalten ab. Aber das Design wird sauberer: Der Kunde versucht nicht mehr allein, einen überfluteten Server zu retten, sondern erhält reduzierten, lesbaren Traffic, den die Anwendung realistischer verarbeiten kann.
Baseline
Normalen TCP-Traffic verstehen: Ports, Öffnungsrate, erwartete Peaks und Nutzerprofil.
Erkennung
SYN/ACK-Ungleichgewicht, instabile Quellen, anormale PPS oder Backlog-Druck erkennen.
Filterung
Unplausiblen Traffic früh verwerfen und stateful Schichten nicht auf Rauschen arbeiten lassen.
Übergabe
Sauberen Traffic über das passende Integrationsmodell zum Kunden zurückgeben.
Häufige Fehler vermeiden
Ein SYN-Flood wirkt simpel, deshalb wird er oft mit einer einzigen Regel behandelt. Das reicht selten. Die echte Frage ist, welche Ressource ausfällt und an welcher Stelle des Pfades entschieden werden muss.
Der zweite Fehler ist, Server-Härtung mit Netzwerkschutz zu verwechseln. Linux, Nginx oder HAProxy zu härten hilft, schützt aber keinen gesättigten Port und keine bereits überlastete Firewall. Der Server kann keine Pakete filtern, die ihn nicht mehr erreichen oder vorher eine Zwischenschicht brechen.
- nur Gbps beobachten und PPS ignorieren
- globales Rate Limit ohne Kenntnis legitimen Traffics aktivieren
- erste echte Verteidigung hinter eine fragile stateful Firewall setzen
- alle neuen Verbindungen blockieren und das Mitigation nennen
- saubere Traffic-Übergabe vor dem echten Angriff nicht testen
FAQ
Ist ein SYN-Flood immer ein großer Gbps-Angriff?
Nein. Er kann wenig Bandbreite, aber sehr viele Pakete pro Sekunde oder hohen TCP-State-Druck erzeugen.
Reichen SYN-Cookies aus?
Sie helfen am Server, schützen aber nicht Upstream-Kapazität, Firewalls, Load Balancer oder Transit-Ports.
Sollte man während des Angriffs alles TCP blockieren?
Nein. Kritische Dienste nutzen TCP. Mitigation muss plausible Verbindungen erhalten und unplausiblen Traffic blocken.
Sind SYN-Flood und TCP-Flood dasselbe?
Ein SYN-Flood ist ein TCP-Flood-Typ mit Fokus auf Verbindungsaufbau. Andere TCP-Floods zielen auf etablierte Sessions, Flags oder Anwendungen hinter TCP.
