Site icon bintorosoft.com

SYN Flood vs. Connection Exhaustion: Unterscheidung anhand von Telemetrie

Red Snapper

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.

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.

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:

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

HandshakeAnteil = HalfOpen HalfOpen + Established

Je höher HandshakeAnteil ist, desto wahrscheinlicher ist ein SYN-Fokus. Je niedriger der Wert (bei gleichzeitig hoher Gesamtsessionzahl), desto wahrscheinlicher ist Connection Exhaustion. Wichtig: Dieser Indikator muss an der richtigen Stelle gemessen werden (z. B. am Terminierungspunkt).

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.

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“.

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:

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

Firewall/NAT Telemetrie

Host-Kernel Telemetrie

NetFlow/IPFIX und Packet Evidence

Wenn Sie Flussdaten und/oder PCAP (auch kurzzeitig) haben, können Sie SYN Flood vs. Exhaustion besonders sauber unterscheiden:

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.

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.

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

Mitigation bei Connection Exhaustion

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:

SYNRateRatio = SYN HandshakeSuccess+1

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?

Outbound-Quellen für technische Tiefe und saubere Terminologie

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:

Lieferumfang:

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.

 

Exit mobile version