SYN Flood vs. Connection Exhaustion zu unterscheiden ist eine der wichtigsten Fähigkeiten in der operativen Netzwerksicherheit, weil beide Muster auf den ersten Blick gleich wirken können: Nutzer melden „Service nicht erreichbar“, Monitoring zeigt steigende Fehlerquoten, und die erste Reaktion lautet oft „DDoS“. In der Praxis sind es jedoch zwei unterschiedliche Problemklassen, die andere Telemetrie-Signale, andere Engpässe und damit andere Gegenmaßnahmen haben. Ein SYN Flood zielt primär auf den TCP-Verbindungsaufbau und die Ressourcen für halb offene Verbindungen (Handshake-Phase). Connection Exhaustion (auch Connection Flood oder Session Exhaustion) zielt dagegen auf vollständige Verbindungen und die Ressourcen, die im laufenden Betrieb pro Connection gehalten werden – auf Load Balancern, Firewalls, Proxies, Hosts oder in der Applikation. Wer beide Fälle anhand von Telemetrie sauber auseinanderhält, reduziert False Positives, vermeidet überbreite Blockmaßnahmen und kann schneller die richtige Mitigation auswählen (SYN-Proxy, Rate-Limits, Timeout-Tuning, Connection Caps, Fairness-Regeln). Dieser Artikel zeigt eine praxistaugliche Unterscheidung anhand messbarer Signale – vom Edge über den Load Balancer bis zum Host – inklusive typischer Fallen (NAT, Keepalives, asymmetrische Pfade) und einer schnellen Diagnose-Checkliste. Für die TCP-Grundlagen ist RFC 9293 (TCP) eine solide Referenz; speziell zu SYN-Flooding und gängigen Gegenmaßnahmen ist RFC 4987 hilfreich.
Begriffe sauber trennen: Was genau ist ein SYN Flood?
Ein SYN Flood ist ein Angriff auf den TCP-Handshake. Der Angreifer sendet eine große Anzahl von SYN-Paketen an einen Dienstport, wodurch die Zielkomponente (Server, Load Balancer oder Firewall) Ressourcen für ausstehende Handshakes reserviert. Die Verbindungen werden absichtlich nicht oder nur selten abgeschlossen (kein gültiges ACK), sodass viele Einträge in der SYN-Queue oder in einer „half-open“-Tabelle verbleiben. Selbst wenn Bandbreite und CPU noch „okay“ aussehen, kann der Dienst keine neuen legitimen Verbindungen mehr annehmen, weil das System den Aufbau nicht mehr zuverlässig abarbeiten kann.
- Primäres Ziel: Ressourcen für halb offene TCP-Verbindungen (SYN backlog, SYN cache, Handshake-State).
- Typisches Symptom: Viele Verbindungen im Zustand SYN-RECEIVED oder ein auffällig hohes SYN/SYN-ACK-Verhältnis.
- Häufige Mitigation: SYN Cookies, SYN Proxy, Rate-Limits für neue Verbindungen (CPS), frühzeitiges stateless Filtering.
Begriffe sauber trennen: Was genau ist Connection Exhaustion?
Connection Exhaustion bedeutet, dass Verbindungsressourcen für abgeschlossene Sessions knapp werden. Der Angreifer baut echte TCP-Verbindungen auf (Handshake vollständig) und hält sie offen, eröffnet massenhaft neue Sessions oder nutzt Keepalive-Mechanismen aus. Dadurch werden Session-Tabellen, File Descriptors, Memory pro Connection, Worker-Threads, Proxy-Pools oder NAT-/Firewall-States erschöpft. Anders als beim SYN Flood ist der Handshake nicht der Engpass – die Maschine „kann verbinden“, aber sie kann die Menge aktiver Sessions nicht mehr effizient bedienen.
- Primäres Ziel: Ressourcen für etablierte Sessions (ESTABLISHED, LB connection tables, conntrack, App worker/FD).
- Typisches Symptom: Stark steigende Anzahl ESTABLISHED-Verbindungen und/or steigende Latenzen durch Queueing.
- Häufige Mitigation: Connection Limits pro Source/Prefix, Idle-Timeout-Tuning, Fairness-Policies, Kapazitätsaufteilung (Pools), Shielding über Proxy/LB.
Warum die Unterscheidung anhand von Telemetrie oft scheitert
In vielen Umgebungen ist die Telemetrie unvollständig oder nicht korrelierbar: Firewalls loggen nur Drops, Load Balancer liefern nur Summenmetriken, und Host-Metriken werden nicht mit Edge-Signalen zusammengeführt. Zusätzlich maskieren Architektur-Details die Sicht:
- Asymmetrische Pfade: SYN geht über Gerät A, ACK über Gerät B – State-Metriken werden uneindeutig.
- NAT und Proxies: Viele Nutzer teilen sich Quell-IPs; „per-IP“-Limits erzeugen False Positives.
- Connection Reuse: HTTP/2, gRPC oder Keepalive reduzieren Connection-Anzahl; gleichzeitig kann ein Angreifer gezielt neue Connections erzwingen.
- Mehrere Terminierungspunkte: TLS/L7-Termination am Proxy kann L4-Signale auf dem Backend verzerren.
Die Kernfrage der Triage: Entsteht der Schaden beim Handshake oder nach dem Handshake?
Eine praxistaugliche Unterscheidung beginnt mit einem einfachen Gedanken: Beim SYN Flood ist die Mehrheit der „versuchten“ Verbindungen nicht etabliert. Bei Connection Exhaustion sind sehr viele Verbindungen etabliert oder zumindest erfolgreich durch die Handshake-Phase gekommen. Das lässt sich mit Telemetrie messbar machen.
Ein Telemetrie-Indikator: Verhältnis von halboffenen zu etablierten Sessions
Je höher
Telemetrie-Signaturen für SYN Flood
Folgende Signale treten bei SYN-Flood-ähnlichen Situationen besonders häufig gemeinsam auf. Einzelne Werte können täuschen; die Kombination ist entscheidend.
- Hoher Anteil SYN-RECEIVED: Auf Host oder LB steigen halboffene Verbindungen deutlich an.
- SYN/SYN-ACK-Auffälligkeit: Viele eingehende SYNs, aber im Verhältnis weniger erfolgreiche Handshakes.
- Steigender SYN-Backlog / Drops: Metriken zeigen Backlog-Auslastung oder Drops wegen Queue-Limits.
- Mehr Retransmits in der Handshake-Phase: SYN-ACKs werden wiederholt gesendet, ACK bleibt aus.
- Neue Verbindungen scheitern, bestehende laufen weiter: Typisch, wenn nur der Aufbau blockiert ist.
Telemetrie-Signaturen für Connection Exhaustion
Connection Exhaustion wirkt „stabiler“, aber zerstörerischer im Betrieb: Handshakes gelingen, nur die Menge aktiver Sessions ist zu hoch oder zu „klebrig“.
- Stark steigende ESTABLISHED-Zahlen: Auf LB/Proxy/Host wachsen aktive Connections kontinuierlich.
- File Descriptor / Socket Limits: Host erreicht ulimit/FD-Grenzen; Accept() oder neue Sockets werden langsam oder scheitern.
- Thread/Worker-Sättigung: Applikation hat keine freien Worker, Backpressure steigt, Latenzen explodieren.
- Hohe Idle-Connection-Last: Viele Verbindungen übertragen wenig, bleiben aber lange offen (Keepalive/Slow patterns).
- State-Tabellen in Firewall/NAT/LB: Sessiontable-Auslastung steigt bis nahe Limit; Drops wegen „table full“ oder „resource exhausted“.
Wo Sie messen müssen: Terminierungspunkt ist König
Die wichtigste praktische Regel lautet: Messen Sie dort, wo TCP wirklich termininiert oder State erzeugt wird. Wenn Ihr Load Balancer TCP terminiert, sind Host-Metriken im Backend nur bedingt aussagekräftig. Wenn die Firewall „stateful“ ist und SYN Proxy macht, sehen Server möglicherweise gar keine halboffenen Zustände. Typische Terminierungspunkte:
- Edge DDoS/Proxy: Terminierung oder Scrubbing vor dem Perimeter.
- Load Balancer / Reverse Proxy: Häufigster Terminierungspunkt in modernen Architekturen.
- Host-Kernel: Wenn Services direkt exponiert sind oder LB nur L4-Passthrough macht.
- Firewall/NGFW: Wenn sie Session-Tracking oder SYN-Mechanismen erzwingt.
Konkrete Telemetrie-Quellen und wie man sie richtig liest
Für eine belastbare Unterscheidung sollten Sie mindestens drei Perspektiven kombinieren: (1) Edge/LB, (2) Host, (3) Netzwerkfluss/Packet-Sicht. Das Ziel ist Korrelation, nicht einzelne „Gold-Metriken“.
Load Balancer / Proxy Telemetrie
- New Connections per Second (CPS): Steigt CPS stark, ohne dass Requests proportional steigen, ist L4 verdächtig.
- Handshake-Failure Rate: Wenn verfügbar, ist das ein direkter SYN-Flood-Indikator.
- Active Connections: Starker Anstieg bei Connection Exhaustion; besonders relevant getrennt nach „active“ vs. „idle“.
- Queue/Backlog Metriken: Hinweise auf Handshake- oder Accept-Engpässe.
Firewall/NAT Telemetrie
- Session Table Utilization: Näher am Limit deutet auf Exhaustion; bei SYN Flood ggf. „half-open“/embryonic counters.
- Drop Reasons: „SYN rate exceeded“, „embryonic limit“, „state table full“ sind klare Hinweise.
- NAT Port Utilization: Bei Outbound-Problemen (z. B. Egress) kann NAT-State der Engpass sein.
Host-Kernel Telemetrie
- TCP State Counts: SYN-RECEIVED vs. ESTABLISHED als schnelle Einordnung.
- Listen/Accept Queues: Wenn Accept-Queue voll, sind Handshakes ggf. okay, aber App nimmt nicht an (Exhaustion/Backpressure).
- FD-Auslastung: Hohe FD-Auslastung korreliert häufig mit Connection Exhaustion.
- CPU pro Paket (pps): Bei ACK/RST-Floods oder hohem SYN-Rate kann CPU limitieren, selbst ohne Bandbreitensättigung.
NetFlow/IPFIX und Packet Evidence
Wenn Sie Flussdaten und/oder PCAP (auch kurzzeitig) haben, können Sie SYN Flood vs. Exhaustion besonders sauber unterscheiden:
- SYN-only Flows: Viele Flows mit nur SYN und ohne Folgepakete sprechen für SYN Flood.
- Kurze, echte Sessions: Viele vollständige Handshakes, aber extrem kurze Dauer kann auf aggressive Connection-Floods hindeuten.
- Lange Idle-Sessions: Viele Flows mit langer Dauer, wenig Bytes, wenig Paketen deuten auf „hold open“/Keepalive-Missbrauch.
Ein praktisches Entscheidungsraster: Welche Metriken zuerst prüfen?
In der Triage hilft ein festes Raster, das Sie als Runbook verankern können. Es reduziert Diskussionen und erhöht die Geschwindigkeit.
- 1) CPS vs. Active Connections: Steigt CPS stark, aber Active Connections nicht? Eher SYN/Handshake. Steigen Active Connections massiv? Eher Exhaustion.
- 2) SYN-RECEIVED vs. ESTABLISHED: Viele halboffene Zustände? SYN-Fokus. Viele etablierte? Exhaustion.
- 3) Drop Reasons: „Embryonic“/Backlog/Handshake-Failures vs. „table full“/FD/Worker exhaustion.
- 4) Bestehende Sessions: Laufen alte Sessions normal, während neue scheitern? Häufig SYN/Handshake. Wird alles langsam? Häufig Exhaustion/CPU/App.
Typische Fehlinterpretationen und wie Telemetrie sie entlarvt
Ein häufiger Fehler ist, SYN Flood und Connection Exhaustion zu verwechseln, weil beide „zu viele Verbindungen“ bedeuten. In Wirklichkeit ist die Art der Überlastung unterschiedlich.
- „Es ist SYN Flood, weil Nutzer nicht verbinden“: Wenn ESTABLISHED stark steigt und FD/Worker am Limit sind, ist es eher Exhaustion.
- „Es ist Exhaustion, weil die Sessiontable voll ist“: Wenn die Tabelle vor allem aus embryonic/half-open besteht, ist der Engpass handshake-nah.
- „Bandbreite ist niedrig, also kein DDoS“: Layer-4-Angriffe können pps- und state-basiert sein und wenig bps benötigen.
- „Pro-IP blocken löst es“: Bei NAT kann das ganze Büros oder Mobilfunk-Nutzer ausschließen; Telemetrie muss NAT-Realitäten berücksichtigen.
Mitigation ableiten: Welche Maßnahmen passen zu welchem Muster?
Die beste Telemetrie ist wertlos, wenn die abgeleiteten Maßnahmen nicht zum Angriffsmuster passen. Das Ziel ist, möglichst früh „billige“ Maßnahmen zu wählen, die keinen zusätzlichen State erzeugen.
Mitigation bei SYN Flood
- SYN Proxy / Handshake Offload: Terminierung am Edge/LB, Backend sieht nur valide Handshakes.
- SYN Cookies: Reduziert Server-State für half-open Verbindungen.
- Rate-Limits für neue Verbindungen: CPS-Limits pro Source/Prefix/Region (mit NAT-Awareness).
- Stateless Filtering: Offensichtliche Anomalien droppen, bevor State entsteht.
Mitigation bei Connection Exhaustion
- Connection Caps und Fairness: Limits pro Source, pro Tenant, pro API-Key, pro Region.
- Idle-Timeout-Tuning: Kürzere Keepalive/Idle-Timeouts für nicht kritische Pfade, ohne legitime Clients zu brechen.
- Backpressure-Strategien: Graceful Degradation, Queue-Limits, priorisierte Endpunkte.
- Pool- und IP-Segmentierung: Kritische Clients/Services über getrennte Listener, VIPs oder NAT-Pools führen.
Messbare Schwellenwerte: Wie Sie Alerts definieren, ohne alles zu alarmieren
Für Google-optimierte, aber vor allem betrieblich sinnvolle Regeln sollten Sie nicht nur „absolute Zahlen“ nehmen, sondern Verhältnisse und Trendbrüche. Ein einfaches Verhältnis ist das SYN-zu-ACK-/Handshake-Verhältnis, sofern Ihre Telemetrie es abbildet:
Ein weiteres, oft sehr robustes Signal ist die Divergenz zwischen steigender CPS und ausbleibender Steigerung in legitimen Requests (z. B. RPS) am Applikationslayer. Auch wenn das über Layer 4 hinausgeht, hilft es, echte Nutzerlast von L4-Missbrauch zu trennen.
Runbook-Checkliste: SYN Flood oder Connection Exhaustion in unter 10 Minuten?
- Terminierungspunkt identifizieren: Wo endet TCP wirklich (Edge, LB, Host)?
- Erste Sicht: CPS, Active Connections, Drop Reasons am Terminierungspunkt.
- State-Verteilung prüfen: SYN-RECEIVED vs. ESTABLISHED (oder embryonic vs. established).
- Host/Backend abgleichen: FD/Worker/CPU/Accept-Queue; passt es zu SYN oder Exhaustion?
- Packet/Flow-Stichprobe: SYN-only Flows oder viele lange Idle-Sessions?
- Mitigation gezielt wählen: SYN Proxy/Rate-Limit (Handshake) vs. Connection Caps/Timeouts (Established).
- False-Positive-Schutz: NAT-Quellen, Proxies, bekannte Großkunden/Carrier berücksichtigen.
Outbound-Quellen für technische Tiefe und saubere Terminologie
- RFC 9293: Transmission Control Protocol (TCP) (aktuelle TCP-Spezifikation, inklusive Verbindungsaufbau und Zustände)
- RFC 4987: TCP SYN Flooding Attacks and Common Mitigations (Mechanismen, Symptome und Gegenmaßnahmen)
- RFC 793: Transmission Control Protocol (historische Basis, hilfreich für State-Modelle und klassische Begriffe)
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.
