SYN Flood: Angriff vs. normaler Traffic-Spike unterscheiden

Ein SYN Flood ist eine der bekanntesten Formen von Denial-of-Service gegen TCP-basierte Dienste – und gleichzeitig eine der häufigsten Ursachen für Fehlalarme im NOC. Denn ein starker Nutzeransturm, ein Release-Rollout, ein fehlerhafter Health-Check oder ein Retry-Sturm nach einem kurzen Outage kann auf den ersten Blick genauso aussehen: viele neue TCP-Verbindungen, steigende SYN-Raten, volle Load-Balancer-Queues und wachsende Latenzen. Der entscheidende Unterschied liegt nicht in „viel Traffic“, sondern in den Mustern des TCP-Handshakes, in der Qualität der Verbindungsabschlüsse und in der Verteilung der Quellen. Wer Angriff und normalen Traffic-Spike sauber trennen kann, reagiert schneller, vermeidet unnötige Mitigationen (die legitime Nutzer treffen) und reduziert Incident-Zeit. Dieser Leitfaden erklärt praxisnah, wie Sie anhand von Metriken, Flow-Daten, Packet Evidence und Systemzuständen erkennen, ob ein SYN Flood vorliegt – oder ob es „nur“ ein legitimer Peak ist, der Kapazität, Rate Limits oder Applikations-Tuning erfordert.

Was ist ein SYN Flood – technisch, aber verständlich

TCP baut eine Verbindung über den Drei-Wege-Handshake auf: Client sendet SYN, Server antwortet mit SYN-ACK, Client bestätigt mit ACK. Beim SYN Flood wird dieser Ablauf ausgenutzt, indem extrem viele SYN-Pakete gesendet werden, ohne den Handshake sauber abzuschließen. Der Server (oder Load Balancer, Firewall, Proxy) reserviert dabei Ressourcen für „halboffene“ Verbindungen, bis eine Grenze erreicht ist (Backlog/State-Table/Queue). Ab diesem Punkt werden legitime Verbindungsaufbauten verzögert oder verworfen.

Hintergrund und gängige Gegenmaßnahmen sind in RFC 4987 zu TCP SYN Flooding und Mitigations beschrieben. Für den grundlegenden TCP-Mechanismus ist RFC 793 (TCP) eine zentrale Referenz.

Warum SYN-Spikes nicht automatisch ein Angriff sind

In der Realität sieht ein NOC viele Situationen, die SYN-lastig sind, ohne dass eine bösartige Absicht dahintersteckt. Typische legitime Auslöser:

• Flash Crowd: Marketing-Kampagne, Breaking News, Ticket-Verkaufsstart – viele echte Nutzer gleichzeitig.
• Retry-Sturm: Nach kurzem Outage versuchen Clients, SDKs oder Upstream-Systeme aggressiv neu zu verbinden.
• Fehlerhafte Health Checks: Zu kurze Intervalle, fehlendes Keepalive, viele verteilte Checker erzeugen SYN-Wellen.
• Autoscaling/Rescheduling: Viele neue Pods/VMs starten gleichzeitig und initialisieren Verbindungen.
• DNS/Service-Discovery-Effekt: Änderungen führen zu kurzfristig vielen neuen Ziel-IP/Port-Kombinationen.

Das Ziel ist daher nicht „SYN-Raten senken“, sondern die Frage: Wie viele SYNs führen zu erfolgreichen Handshakes und zu stabilen Sessions?

Die Kernfrage: Handshake-Qualität statt reine SYN-Rate

Der wichtigste Indikator ist die Differenz zwischen eingehenden SYNs und erfolgreich abgeschlossenen Verbindungen. Praktisch betrachten Sie:

• SYN-In: Anzahl eingehender SYN pro Sekunde (oder pro 10s/1min).
• SYN-ACK-Out: Antworten der Gegenstelle (zeigt, ob das System noch reagiert).
• Final-ACK: Bestätigungen, die den Handshake abschließen.
• Established: Anzahl neuer „ESTABLISHED“-States pro Sekunde.

Ein einfacher, hilfreicher Quotient

Um schnell ein Gefühl zu bekommen, kann ein „Handshake Completion Ratio“ dienen. Je näher an 1, desto mehr SYNs werden sauber abgeschlossen; je näher an 0, desto wahrscheinlicher ist ein SYN Flood oder ein massives Client-/Netzproblem.

$\mathrm{HCR}=\frac{\mathrm{ACK} \mathrm{abgeschlossen}}{\mathrm{SYN} \mathrm{eingehend}}$

Interpretation in der Praxis: Ein legitimer Spike kann hohe SYN-Raten haben, aber typischerweise auch einen hohen Anteil an abgeschlossenen Handshakes (sofern Backends nicht am Limit sind). Ein SYN Flood zeigt oft ein starkes Missverhältnis: SYN-In hoch, aber Final-ACK/Established deutlich niedriger.

Symptome eines SYN Flood – und was daran „anders“ ist

Ein SYN Flood hinterlässt charakteristische Spuren, die Sie in Kombination bewerten sollten:

• Viele halboffene Verbindungen (SYN-RECV / half-open) auf Server/Load Balancer/Firewall.
• Backlog-/State-Table-Druck: Zunehmende Drops, „SYN backlog overflow“, steigende Retransmits.
• Geringe Abschlussquote: Kaum Final-ACKs im Verhältnis zu SYNs.
• Unplausible Source-Verteilung: Sehr viele Quellen, gespoofte IPs oder auffällige ASN/Geo-Muster.
• Port-/Service-Fokus: Überwiegend ein einzelner Port (z. B. 443) oder wenige VIPs.

Wichtig: Auch ein legitimer Spike kann Backends überlasten. Der Unterschied ist dann häufig, dass die Clients „ehrlich“ reagieren: Viele Handshakes schließen ab, aber Applikationslatenz steigt, oder es folgen reguläre HTTP/TLS-Fehler – nicht primär ein Meer aus halboffenen TCP-States.

So sieht ein normaler Traffic-Spike typischerweise aus

Bei legitimen Peaks sind die Muster meist „runder“:

• Mehr SYNs, aber auch mehr ESTABLISHED: Die Kurven steigen gemeinsam.
• Mehr Datenverkehr nach dem Handshake: Höhere Bytes/s und Requests/s korrelieren mit der SYN-Rate.
• Client-Population plausibel: Quellen passen zu Ihrer Nutzerbasis (bekannte Länder/ASNs/CDNs/Enterprises).
• Saubere TLS/HTTP-Verläufe: Handshakes und Requests laufen überwiegend durch; Fehler sind eher 429/503/Timeouts durch Kapazitätsgrenzen.
• Timing passend zu Ereignissen: Deployment, Newsletter, Cron-Jobs – oft korrelierbar mit internen Changes.

Die wichtigsten Telemetriequellen im NOC

Eine robuste Unterscheidung gelingt selten mit nur einer Metrik. Kombinieren Sie mindestens zwei Ebenen: Netztelemetrie (Flows/Packets) und Systemzustand (LB/Firewall/Server).

• Load Balancer: New connections/s, SYN rate, resets, queue/backlog, SYN cookies (falls verfügbar), handshake failures.
• Firewall/Edge: Session table usage, embryonic connections, SYN-proxy Statistiken, drops/policer hits.
• Server: SYN-RECV Counts, listen queue overflow, CPU softirq, conntrack (falls relevant).
• Flow-Daten (NetFlow/sFlow/IPFIX): Anzahl Flows, neue Flows/s, Source-IP-Cardinality, Ports, Flags (wenn exportiert).
• Packet Capture: Stichproben zur Handshake-Vollständigkeit, MSS/Window, Retransmits, TTL-Pattern.

Konkrete Indikatoren: Angriff vs. Spike in 10 Minuten einordnen

Wenn es schnell gehen muss, helfen klare Checks. Die folgenden Heuristiken sind in der Praxis sehr belastbar:

1) Verhältnis „SYN zu Established“

Steigt SYN/s stark, aber Established/s bleibt flach oder fällt sogar? Das ist ein starkes Angriffssignal – oder ein Hinweis, dass das Zielsystem keine neuen Verbindungen mehr annehmen kann (Backlog/State voll). Im zweiten Fall sehen Sie aber oft zusätzlich erhöhte Retransmits und ggf. RST/Timeouts bei legitimen Clients.

2) Source-IP-Cardinality und „Verteilung“

Ein SYN Flood kann extrem viele Quellen haben (oft gespooft) oder eine kleinere Menge an kompromittierten Hosts (Botnet). Ein legitimer Spike hat ebenfalls viele Quellen, aber oft in bekannten Mustern (z. B. Mobilfunk-ASNs, Firmen-Proxy-ASNs, CDN-Egress). Verdächtig sind z. B.:

• Sehr viele neue, nie zuvor gesehene ASNs/Netzblöcke in kurzer Zeit.
• Quellen, die „geografisch“ unplausibel sind (z. B. plötzlich 90% aus Regionen, in denen Sie keine Nutzer haben).
• Viele Quellen mit identischen TCP-Optionen/TTL-Pattern (spricht für ein einheitliches Tooling).

3) Ungewöhnliche TCP-Optionen und konstante Paketmuster

In PCAPs sind SYN Floods oft auffällig „monoton“: gleiche MSS, gleiche Window-Size, gleiche Options-Reihenfolge, gleiche TTL. Echter Nutzerverkehr ist heterogener (verschiedene OS/Stacks/Netze). Das ist kein alleiniger Beweis, aber ein starkes Indiz.

4) SYN-ACK-Reaktionen: Kann das Ziel noch antworten?

Wenn Ihr Load Balancer/Server weiterhin SYN-ACKs sendet, aber kaum Final-ACKs zurückkommen, spricht das für SYN Flood oder Spoofing. Wenn hingegen bereits SYN-ACK-Out einbricht, ist das System möglicherweise überlastet oder die Rückwege sind gestört (Routing/Firewall/Upstream-Problem).

5) Bytes pro Flow und „Post-Handshake“-Traffic

Legitime Peaks erzeugen nach dem Handshake Daten: TLS-Handshake, HTTP-Requests, Responses. SYN Flood erzeugt oft extrem kleine Flows (kaum Payload, kurze Dauer, keine Folgepakete). Flow-Tools zeigen dann viele sehr kleine „Verbindungen“ oder embryonische States.

False Positives: Wenn es wie SYN Flood aussieht, aber keiner ist

Mehrere Szenarien imitieren SYN-Flood-Symptome, ohne dass ein Angriff vorliegt:

• Asymmetrisches Routing: SYN kommt rein, SYN-ACK geht raus, aber ACK kommt über einen anderen Weg zurück und wird verworfen (z. B. stateful Firewall). Ergebnis: viele halboffene Verbindungen.
• Upstream-Rate-Limits: SYN-ACKs oder Rückpakete werden upstream gedrosselt, wodurch Handshakes nicht schließen.
• Client-Timeout-/Retry-Bug: Ein fehlerhaftes SDK startet ständig neue Verbindungen statt wiederzuverwenden.
• Health-Check-Missdesign: Checks öffnen TCP, schließen aber nicht sauber oder zu häufig; vor allem bei vielen Checkern.
• DNS-/Service-Discovery-Flapping: Clients verbinden ständig neu, weil Targets wechseln.

Evidence aus PCAP: Was Sie wirklich sehen wollen

Ein kurzer PCAP (z. B. 30–120 Sekunden) an der richtigen Stelle ist extrem aussagekräftig. Für die Unterscheidung sind vor allem diese Beobachtungen relevant:

• Handshake-Sequenzen: Sehen Sie SYN, SYN-ACK, ACK in konsistenter Folge – oder bleiben viele Sequenzen bei SYN/SYN-ACK stehen?
• Retransmissions: Häufige SYN- oder SYN-ACK-Retransmits deuten auf Paketverlust, Filterung oder Überlast.
• RST-Verhalten: Viele RSTs können auf aktive Mitigation, LB-Überlauf oder Applikationsablehnung hinweisen.
• Timing: SYNs im konstanten „Maschinen-Takt“ (sehr gleichmäßig) sind verdächtiger als burstiges, menschliches Nutzungsverhalten.

Wenn Sie tiefer in TCP-Mechanik und Retransmission-Logik einsteigen möchten, sind die Grundlagen in den TCP-RFCs verankert (z. B. RFC 793), während SYN-Flood-spezifische Betrachtungen in RFC 4987 zusammengefasst sind.

Mitigation-Mechanismen verstehen, um Signale richtig zu interpretieren

Ein häufiger Stolperstein: Mitigationen verändern Telemetrie. Wenn Sie z. B. SYN Cookies oder SYN Proxy aktivieren, sinkt die Zahl halboffener States, obwohl die SYN-Rate hoch bleibt. Das ist nicht „Problem gelöst“, sondern „Problem abgepuffert“. Typische Mechanismen:

• SYN Cookies: Server codiert State in Sequenznummer, reduziert Speicherbedarf. (Konzept wird häufig in Betriebssystemen genutzt und in RFC 4987 diskutiert.)
• SYN Proxy/SYN Authentication: Ein Gerät terminiert den Handshake und lässt nur abgeschlossene Verbindungen zum Backend durch.
• Rate Limiting: Policer/ACL begrenzen SYNs pro Quelle/Interface; kann legitime Peaks treffen, wenn falsch dimensioniert.
• DDoS-Scrubbing/CDN: Verschiebt den Traffic, Quellen werden „normalisiert“ (z. B. nur noch CDN-Egress sichtbar).

Ein pragmatischer Response-Plan: Entscheidungsschritte ohne Overkill

Um Angriff vs. Spike sauber zu trennen, hilft ein standardisierter Ablauf, der in Minuten funktioniert:

• Schritt 1: Symptomklassifikation – Ist es Verbindungsaufbau (SYN/Handshake) oder Applikation (Requests/Errors)?
• Schritt 2: Completion Ratio – Verhältnis SYN zu Established/ACK prüfen; starkes Missverhältnis ist Warnsignal.
• Schritt 3: Source-Analyse – ASNs/Geo/Cardinality, „neu vs. bekannt“, ungewöhnliche Konzentrationen.
• Schritt 4: Systemzustand – Backlog/State-Table/CPU/Queue, Drops, SYN-Proxy/Cookies-Status.
• Schritt 5: PCAP-Stichprobe – 60 Sekunden Evidence am Edge oder am VIP sammeln, Handshake-Vollständigkeit validieren.
• Schritt 6: Maßnahme wählen – Bei Angriff: Mitigation (SYN proxy, scrubbing, rate limit, upstream). Bei legitimer Last: Kapazität/Autoscaling, Client-Retry-Tuning, Keepalive, LB-Settings.

Praxis-Tuning für legitime Peaks: Damit SYN-Spikes stabil bleiben

Wenn sich herausstellt, dass es kein Angriff ist, ist die richtige Reaktion nicht „DDoS-Button drücken“, sondern Stabilisierung der Plattform. Häufige Hebel:

• Connection Reuse: Keepalive/HTTP/2/HTTP/3 sinnvoll nutzen, statt ständig neue TCP-Verbindungen zu öffnen.
• Retry-Backoff: Exponentielles Backoff und Jitter in Clients/SDKs, um Retry-Stürme zu vermeiden.
• LB-Backlog/Timeouts: Sinnvoll dimensionieren, ohne zu große State-Halden zu erzeugen.
• Health-Checks: Frequenz reduzieren, Checks konsolidieren, echte Service-Signale prüfen statt nur TCP open/close.
• Autoscaling: Skalierung auf „new connections/s“ oder „queue depth“ ergänzen, nicht nur CPU.

Security-Sicht: Wann ein SYN Flood sehr wahrscheinlich ist

Wenn mehrere der folgenden Punkte gleichzeitig auftreten, ist ein SYN Flood als Ursache sehr plausibel:

• Extrem hoher SYN-In ohne korrelierenden Anstieg an Established/Request-Traffic.
• Viele halboffene Verbindungen und Backlog-/State-Table-Sättigung.
• Quellenverteilung unplausibel (neu, breit, gespooft wirkend) oder stark bösartig konzentriert.
• Sehr monotone TCP-SYN-Profile (Optionen/TTL/MSS) über große Traffic-Anteile.
• Upstream meldet DDoS-Indikatoren oder Scrubbing-Trigger (falls vorhanden).

Dokumentation und Learnings: Was Sie fürs nächste Mal speichern sollten

Unabhängig davon, ob es Angriff oder Spike war, lohnt sich ein kleines „Evidence Pack“ für zukünftige Incidents. Mindestens:

• Grafiken: SYN/s, Established/s, Drops/Backlog/State-Usage, Latenz/Fehlerraten.
• Top Sources/ASNs/Geos (vor und nach Mitigation).
• 60–120 Sekunden PCAP an der relevanten Stelle (Edge oder VIP).
• Konfig-Status: SYN proxy/cookies, Rate Limits, WAF/CDN/Scrubbing aktiv ja/nein.
• Korrelation: Deployments, Marketing-Aktionen, Upstream-Events, Client-Retry-Änderungen.

Als fachliche Vertiefung für die Abgrenzung und typische Gegenmaßnahmen ist RFC 4987 zu SYN Flooding und Mitigations besonders hilfreich; die TCP-Basis liefert RFC 793. Diese Quellen geben Ihnen eine stabile Grundlage, um Alarmmuster im Betrieb nicht nur „aus dem Bauch heraus“, sondern strukturiert und nachvollziehbar zu bewerten.

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.