February 15, 2026

SYN-Flood vs. „normale“ L4-Probleme: So unterscheidest du es

Ein SYN-Flood zählt zu den häufigsten Ursachen für plötzliche, großflächige Verbindungsprobleme auf Layer 4 – und gleichzeitig zu den am leichtesten falsch eingeordneten. Denn aus Sicht der Anwendung sehen viele Störungen zunächst ähnlich aus: TCP-Verbindungen kommen nicht zustande, Clients melden „connection timed out“, Load Balancer werden träge, und Monitoring zeigt steigende Latenzen. Trotzdem ist die operative Antwort grundverschieden. Während ein SYN-Flood typischerweise eine absichtliche oder zumindest externe Lastspitze auf den TCP-Verbindungsaufbau ist, entstehen „normale“ L4-Probleme häufig durch Überlast, Fehlkonfiguration, kaputte Middleboxes, asymmetrisches Routing oder erschöpfte Ressourcen wie Ephemeral Ports und Connection Tracking. Wer diese Fälle verwechselt, verliert wertvolle Zeit und verschlimmert den Incident mit falschen Maßnahmen: Skalierung der Applikation hilft gegen einen SYN-Flood nur begrenzt, während aggressive DDoS-Maßnahmen bei internen L4-Fehlern unnötige Komplexität erzeugen. In diesem Artikel lernen Sie, wie Sie SYN-Floods anhand von Paketmustern, Countern und zeitlichen Verläufen von „normalen“ Layer-4-Störungen unterscheiden – so, dass Sie schnell die richtige Eskalationskette (NetOps, SecOps, Provider, Cloud-DDoS) aktivieren und zugleich die häufigsten L4-Fallen im Tagesgeschäft systematisch ausschließen.

Table of Contents

Grundprinzip: Warum der TCP-Handshake der Schlüssel zur Unterscheidung ist

Fast alle relevanten Signale liegen im TCP-Handshake. Ein Client sendet ein SYN, der Server antwortet mit SYN-ACK, der Client bestätigt mit ACK. Bei einem SYN-Flood zielt der Traffic auf genau diesen Mechanismus: Der Server oder ein vorgelagertes Gerät muss für viele eingehende SYNs Zustand speichern oder zumindest Rechenarbeit leisten. Bei „normalen“ L4-Problemen dagegen ist oft nicht die Menge an SYNs der Kern, sondern dass Handshake oder Datenphase durch andere Ursachen scheitern (Drops, falsche Policies, kaputte NIC, überlaufende Tabellen, Rate-Limits).

SYN-Flood: auffällige Häufung von SYNs, oft ohne korrespondierende ACKs, Anstieg von „half-open“ Zuständen.
Normale L4-Probleme: Handshake kann sporadisch funktionieren, oder SYN-ACKs sind sichtbar, werden aber nicht bestätigt; oft korreliert mit interner Last, Deployments, Changes oder Ressourcenlimits.

Als Referenz für TCP-Verhalten ist die Spezifikation hilfreich, insbesondere RFC 9293 (TCP).

Symptome im Frontend: Was die Anwendung sieht (und warum es täuscht)

Aus Applikationssicht sind die Fehlermeldungen oft unpräzise. Ein Connect-Timeout kann durch SYN-Flood entstehen, aber ebenso durch Routing-Blackholing, Firewall-Drops oder Überlast. Deshalb ist der erste operative Schritt: Symptome in Handshake-Phase und Datenphase trennen.

Handshake-Phase: Client kann keine Verbindung aufbauen (SYN bleibt unbeantwortet, SYN-ACK kommt nicht an, Reset).
Datenphase: Verbindung steht, aber Requests hängen (Retransmissions, Zero Window, Server-Delay, Proxy-Retries).

Ein SYN-Flood wirkt primär in der Handshake-Phase. Wenn hingegen viele Verbindungen erfolgreich aufgebaut werden, aber Requests timeouten, ist ein SYN-Flood als Hauptursache weniger wahrscheinlich.

Die schnellste Diagnose: Drei belastbare Fragen

In einem Incident brauchen Teams eine knappe Entscheidungslogik, bevor sie tief in Details gehen. Diese drei Fragen liefern häufig innerhalb weniger Minuten eine klare Richtung:

Steigt die SYN-Rate (SYN/s) abrupt und stark an? Wenn ja, ist ein SYN-Flood oder zumindest ein SYN-Sturm wahrscheinlich.
Steigt die Anzahl „half-open“ Verbindungen (SYN-RECV) stark an? Das ist ein klassisches SYN-Flood-Signal.
Sehen Sie ungewöhnlich viele unterschiedliche Source-IPs oder Spoofing-Indizien? Viele Quellen, unplausible Geos/ASNs, ungültige TTL-Muster – typisch für volumetrische Angriffe.

Wichtig: Eine hohe SYN-Rate allein beweist noch keinen Angriff. Auch Retry-Stürme aus Clients, Health-Check-Loops oder falsch konfigurierte Load Tests können SYN-Last erzeugen. Entscheidend ist die Kombination aus Rate, Zustandsbild und Herkunft.

Packet-Patterns: So sieht ein SYN-Flood im Mitschnitt aus

Packet Captures sind besonders aussagekräftig, wenn Sie an einem geeigneten Punkt messen (z. B. vor dem Load Balancer, am Edge, auf dem betroffenen Serverinterface). Ein SYN-Flood zeigt häufig die folgenden Muster:

Viele SYNs, wenige SYN-ACKs oder wenige abschließende ACKs: Der Server antwortet eventuell, aber die dritte Handshake-Nachricht bleibt aus.
Sehr kurze Interarrival-Zeiten: SYNs kommen in extrem dichter Folge, oft ohne typische Client-Verhaltensmuster.
Ungewöhnliche Source-Port/Sequence-Verteilungen: kann auf Spoofing oder Botnet-Tools hindeuten (ohne dass Sie sich darauf verlassen sollten).
Wenig oder keine Datenpakete: selbst wenn vereinzelte Handshakes durchkommen, folgt oft kein legitimer HTTP-Traffic.

In Wireshark ist ein schneller Filteransatz: nur SYN-Pakete anzeigen und dann Verhältnis und Verteilung betrachten. Entscheidend ist nicht nur „viel“, sondern „viel ohne Abschluss“.

Eine einfache Ratio, die schnell Orientierung gibt

Ein pragmatisches Signal ist das Verhältnis von eingehenden SYNs zu erfolgreich abgeschlossenen Handshakes (oder zu ACKs nach SYN-ACK). Als grobe Metrik:

$SYN_ACK_Ratio = \frac{Anzahl_SYN}{Anzahl_final_ACK}$

Ein stark steigender Wert kann auf SYN-Flood oder auf massives Client-Retry-Verhalten hindeuten. Die Metrik ist nicht „gerichtsfest“, aber operativ sehr nützlich, wenn sie im Zeitverlauf korreliert wird.

Counter und States: Welche Systemsignale SYN-Floods typisch machen

Da SYN-Floods den Verbindungsaufbau stressen, schlagen sie häufig in Zustands- und Backlog-Kennzahlen durch. Je nach Plattform finden Sie diese Signale auf dem Server, dem Load Balancer oder der Firewall:

Hohe SYN-RECV-Zahlen: viele Verbindungen im halboffenen Zustand.
SYN backlog / accept queue pressure: Backlog-Füllstand steigt, Drops nehmen zu.
SYN cookies aktiv: Aktivierung kann normal sein, aber ein Sprung in der Aktivität ist ein Indiz für Flood-Pressure.
State table pressure (Firewall/NAT): erhöhte Insert-Fails oder Drops bei neuen Flows.
CPU-Spikes in Edge-Komponenten: besonders bei Geräten, die per-Connection teure Checks machen.

Der Kern: Bei einem SYN-Flood sehen Sie häufig Pressure in genau den Komponenten, die „neue Verbindungen“ verwalten. Bei normalen L4-Problemen können stattdessen andere Ressourcen dominieren (z. B. Bandbreite, Paketverlust, MTU, oder Applikationslatenz).

„Normale“ L4-Probleme: Häufige Ursachen, die wie SYN-Flood wirken

Viele Layer-4-Störungen erzeugen SYN-Retransmits und Connect-Timeouts, ohne dass ein Angriff vorliegt. Die wichtigsten Kategorien sollten Sie systematisch prüfen, bevor Sie eine SYN-Flood-Eskalation ausrufen.

Ressourcenerschöpfung durch Connection Tracking oder NAT

Wenn Connection Tracking erschöpft ist, können neue Verbindungen nicht mehr zuverlässig angelegt werden. Das Ergebnis ist nahezu identisch zu einem SYN-Flood aus Sicht des Clients: SYN geht raus, es kommt nichts zurück oder der Rückweg wird verworfen. Hier unterscheiden sich die Begleitsignale:

Conntrack-Tabelle nahe Limit: starke Korrelation zwischen Eintragszahl und Fehlerrate.
Betroffene Scope: oft bestimmte Segmente oder Egress-Pfade; nicht zwingend globaler Internet-Traffic.
Traffic-Herkunft: häufig interne Quellen (Microservices, Jobs, Log-Pipelines), nicht viele externe IPs.

Server-Overload: Backlog voll, aber kein Angriff

Ein überlasteter Server kann SYNs zwar empfangen, aber nicht schnell genug akzeptieren. Auch das füllt Backlogs und erzeugt SYN-Timeouts. Typisch ist dann eine Korrelation mit CPU, Runqueue, Memory Pressure, GC-Pausen oder Disk I/O (je nach Service). Im Capture sehen Sie oft, dass SYN-ACKs noch erzeugt werden, aber die Datenphase leidet – oder dass die Service-Prozesse nicht hinterherkommen.

Indizien: gleichzeitige Erhöhung von Applikationslatenz, 5xx, Queueing, Systemload.
Abgrenzung: bei echtem SYN-Flood sehen Sie häufig keinen entsprechenden Anstieg legitimer Request-Last.

Firewall/ACL/Policy-Änderungen (stille Drops)

Ein klassischer Change-Failure: Eine neue Regel droppt SYNs oder SYN-ACKs. Das wirkt exakt wie ein SYN-Flood, nur ohne Volumen-Spike. Hier hilft der Zeitverlauf: Bei Policy-Fehlern beginnt das Problem oft schlagartig zu einem Change-Zeitpunkt und bleibt stabil, statt in Wellen zu kommen.

Indizien: klarer Startzeitpunkt, häufig nur bestimmte Ports/Ziele, keine ungewöhnliche Source-IP-Verteilung.
Messbar: ACL-Hit-Counter, Firewall-Logs (sofern aktiviert), Vergleich vor/nach Change.

Asymmetrisches Routing über stateful Geräte

Wenn Hin- und Rückweg durch unterschiedliche stateful Firewalls laufen, kann der Rückverkehr keinen passenden State finden und wird verworfen. Ergebnis: SYN geht rein, SYN-ACK kommt raus, wird aber irgendwo gedroppt – der Client retransmittiert. Dieses Muster ist in Captures sehr deutlich, wenn Sie vor und nach der Firewall messen.

Indizien: SYN-ACK sichtbar auf Serverseite, fehlt auf Clientseite; oft nach Routing-/BGP-/VRF-Changes.
Abgrenzung: kein großer SYN-Volumenanstieg notwendig; Ursache ist Pfad-/Policy-Topologie.

MTU/PMTUD-Probleme, die Handshakes indirekt stören

MTU-Probleme äußern sich häufiger in der Datenphase (z. B. TLS ClientHello/ServerHello), können aber als „Handshake-Timeout“ erscheinen. Dann sieht der TCP-Handshake normal aus, aber TLS hängt. Das ist kein SYN-Flood, sondern ein L3/L4-Interaktionsproblem (ICMP blockiert, Fragmentierung dropt, Overlays).

Indizien: TCP Handshake erfolgreich, danach Retransmissions großer Segmente; evtl. ICMP „Packet Too Big“ (wenn nicht gefiltert).

Vergleich im Zeitverlauf: Was der Graph verrät

Die Unterscheidung gelingt häufig am besten über Zeitreihen. Ein SYN-Flood zeigt oft ein anderes Muster als interne L4-Probleme.

SYN-Flood: plötzliche, sehr starke Spike(s) in SYN/s; häufig wellenförmig; hohe externe Quellvielfalt; steigende SYN-RECV; eventuell Bandbreiten- oder PPS-Limits werden erreicht.
Normaler L4-Failure: Korrelation zu Deployments/Changes, zu internen Batch-Jobs oder zu einem einzelnen Hotspot; häufig gradueller Anstieg, oder schlagartig aber ohne Volumen-Spike.
Server-Overload: SYN/s kann steigen, aber gleichzeitig steigen legitime RPS, CPU, Queueing und oft auch 5xx/Timeouts in der Datenphase.

Ein praxisnahes Signal ist der Gleichlauf von SYN/s und erfolgreichen Handshakes. Bei einem SYN-Flood steigt SYN/s stark, während erfolgreiche Handshakes nicht proportional steigen.

Was Sie auf Load Balancern sehen: L4-Frontend vs. L7-Symptome

Viele Umgebungen nutzen einen Load Balancer als Eintrittspunkt. Das kann die Diagnose vereinfachen, weil Load Balancer oft reichhaltige Metriken besitzen. Gleichzeitig kann es die Ursache verschleiern, wenn der Load Balancer selbst unter Druck gerät.

L4-LB unter SYN-Flood: steigende neue Verbindungen, steigende Drops/Resets, eventuell Schutzmechanismen (SYN proxy) greifen, Backend-Verbindungen bleiben vergleichsweise niedrig.
L7-LB unter „normaler“ Last: RPS steigt, Upstream-Latenz steigt, Retries nehmen zu, Health Checks flappen; SYN/s muss nicht extrem sein.
Fehlkonfiguration: Idle-Timeouts, Connection Reuse, falsch gesetzte Health Checks erzeugen interne Reconnect-Stürme.

Wenn der Load Balancer TLS terminiert, kann ein MTU-/Handshake-Problem ebenfalls wie ein L4-Problem wirken. Deshalb ist es wichtig, die Phase (TCP vs. TLS vs. HTTP) zu unterscheiden.

Operational Playbook: Schnelle Schritte zur Unterscheidung

Dieses Vorgehen ist so gestaltet, dass es ohne Spezialwissen über eine konkrete Plattform funktioniert. Es nutzt universelle Beobachtungen: Traffic-Raten, Zustände, Herkunft und Paketverläufe.

1) Prüfen Sie SYN/s und CPS: Steigt die Rate extrem? Wenn ja, in welchem Scope (global, einzelne VIP, einzelne Region)?
2) Prüfen Sie SYN-RECV/half-open: Steigt der Anteil halboffener Verbindungen stark an?
3) Vergleichen Sie Handshake-Erfolg: Bleibt Anzahl erfolgreicher Handshakes deutlich hinter SYN-Anstieg zurück?
4) Prüfen Sie Herkunft: Viele externe Quell-IPs und ungewöhnliche Verteilung → Angriff wahrscheinlicher. Interne Quellen/Jobs → normaler L4-Sturm wahrscheinlicher.
5) Prüfen Sie Conntrack/NAT: Tabellenlimits, Drops, Insert-Fails; besonders bei Egress- oder Firewall-Kanten.
6) Prüfen Sie Change-Korrelation: Startzeitpunkt deckt sich mit Deploy/Firewall-Regel/Routing-Change?
7) Capture an zwei Punkten: Vor und hinter der stateful Komponente (Firewall/LB), um Drops nachzuweisen.

Mitigation, ohne Schaden anzurichten: Was bei SYN-Flood sinnvoll ist (und was nicht)

Operativ ist die wichtigste Regel: Maßnahmen müssen proportional und reversibel sein. Bei einem tatsächlichen SYN-Flood sind die wirksamsten Schritte meist an der Netzwerkkante oder beim Provider zu finden, nicht in der Applikation.

Edge-DDoS-Schutz aktivieren/eskalieren: Provider/Cloud-Schutz, Scrubbing, Anycast-Kanten.
SYN-Proxy/SYN-Cookies nutzen: reduziert State-Pressure auf Backend (abhängig von Plattform).
Rate Limiting für neue Verbindungen: Schutz gegen CPS-Spikes; vorsichtig einstellen, um legitime Clients nicht zu blocken.
WAF hilft nur begrenzt: Bei reinem SYN-Flood kommt der Traffic oft nicht bis L7; WAF ist dann nicht der primäre Hebel.
Blindes Autoscaling ist riskant: Es kann Kosten explodieren lassen, ohne die Ursache zu lösen, und zusätzliche interne Abhängigkeiten belasten.

Mitigation bei „normalen“ L4-Problemen: Häufig die bessere Hebelwirkung

Wenn die Diagnose gegen SYN-Flood spricht, sind andere Maßnahmen deutlich effektiver und nachhaltiger:

Retry-Stürme bremsen: Exponential Backoff mit Jitter, Retry-Budget, Circuit Breaker.
Connection Reuse erhöhen: Keep-Alive, HTTP/2, Connection Pools, um CPS zu senken.
Conntrack/NAT skalieren oder sharden: mehr Gateways, mehr öffentliche IPs, bessere Segmentierung.
Time-Outs konsistent setzen: Idle-Timeouts entlang der Kette (Client, LB, Firewall, Server) abstimmen.
Policy/Routing zurückrollen: wenn Startzeitpunkt mit Change korreliert und Scope passt.

Typische Fehlklassifikationen: Warum Teams SYN-Flood „sehen“, wo keiner ist

In der Praxis sind folgende Situationen für Fehlklassifikationen verantwortlich:

Health-Check-Fehlkonfiguration: zu aggressive Checks erzeugen Verbindungsfluten, wenn Backends wackeln.
Client-Library-Retries: Standard-Retry ohne Jitter synchronisiert Tausende Clients und erzeugt CPS-Spikes.
Batch-Jobs und Cron-Wellen: periodische Lastspitzen sehen wie Angriffs-Wellen aus.
Asymmetrie nach Routing-Change: Drops wirken wie Flood, sind aber Pfadproblem.
Conntrack-Pressure durch UDP: lange UDP-Timeouts blockieren Tabellenplätze, TCP-Neuverbindungen scheitern dann scheinbar „ohne Grund“.

Die Gegenmaßnahme ist immer dieselbe: nicht nur „SYN hoch“ betrachten, sondern Zustand, Herkunft und Handshake-Erfolg zusammen auswerten.

Messdesign für E-E-A-T im Betrieb: Welche SLOs und Alarme helfen wirklich

Damit Sie nicht erst im Incident unterscheiden müssen, sollten Sie Metriken und Alarme so designen, dass SYN-Floods und normale L4-Probleme automatisch auseinanderlaufen. Bewährt haben sich:

SYN/s und CPS pro VIP/Service: Anomalieerkennung statt fixer Schwellen (Saisonalität berücksichtigen).
Handshake-Success-Rate: Anteil erfolgreicher TCP-Handshakes im Zeitfenster.
SYN-RECV-Anteil: Anteil halboffener Verbindungen als Frühwarnsignal.
Conntrack-Auslastung und Drops: harte Alarme auf „insert failed“ und schnelle Anstiege.
Scope-Korrelation: externe Quellenvielfalt (IP/ASN) vs. interne Top-Talker.

Eine einfache Handshake-Erfolgsquote lässt sich als Verhältnis ausdrücken:

$Handshake_Success = \frac{Erfolgreiche_Handshakes}{Beobachtete_SYN}$

Sinkt diese Quote stark, während SYN/s steigt, ist ein SYN-Flood wahrscheinlicher. Sinkt sie ohne SYN-Spike, ist ein normales L4-/Policy-/Ressourcenproblem wahrscheinlicher.

Outbound-Links für vertiefende Informationen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.