February 14, 2026

Angriffe auf Schicht 4: SYN-Flood und der Zusammenhang mit TCP

Ein SYN-Flood ist eine der bekanntesten Angriffsmethoden auf Schicht 4 (Transport Layer) und steht in direktem Zusammenhang mit dem Aufbau von TCP-Verbindungen. Ziel ist dabei nicht, eine Anwendung „auszulesen“ oder Daten zu stehlen, sondern einen Dienst unerreichbar zu machen, indem die Fähigkeit des Servers (oder einer vorgeschalteten Firewall/Load-Balancer), neue TCP-Verbindungen anzunehmen, überlastet wird. Besonders tückisch ist: Der Angriff nutzt keine exotische Schwachstelle, sondern einen normalen Mechanismus von TCP – den Verbindungsaufbau per Three-Way-Handshake. Wer das OSI-Modell kennt, kann SYN-Floods sauber einordnen: Die Attacke trifft primär die Transport-Schicht, ihre Auswirkungen werden jedoch häufig auf Schicht 7 sichtbar („Website lädt nicht“, „API timeoutet“). In diesem Artikel lernen Sie, wie TCP-Verbindungen entstehen, warum SYN-Floods funktionieren, welche Symptome typisch sind, wie man solche Angriffe erkennt und welche Gegenmaßnahmen in modernen Netzwerken am wirksamsten sind – ohne unnötige Komplexität, aber mit einem klaren Blick auf Praxis und Sicherheit.

Table of Contents

OSI-Schicht 4: Was macht die Transport Layer?

Die Transport Layer sorgt dafür, dass Daten zwischen zwei Endpunkten zuverlässig oder effizient übertragen werden. Im Alltag begegnen Ihnen vor allem zwei Protokolle:

TCP (Transmission Control Protocol): verbindungsorientiert, zuverlässig, geordnet (z. B. Web, E-Mail-Transport, Datenbanken).
UDP (User Datagram Protocol): verbindungslos, geringer Overhead, oft für Echtzeit oder spezielle Protokolle (z. B. DNS, Streaming-Teile, VoIP-Mechaniken).

Ein SYN-Flood ist ein Angriff, der spezifisch die Eigenschaften von TCP ausnutzt. Hintergrundwissen zu TCP finden Sie unter Transmission Control Protocol. Für den OSI-Kontext ist die Einordnung in die Transportschicht zentral: OSI-Modell.

TCP-Verbindungsaufbau: Der Three-Way-Handshake verständlich erklärt

TCP baut eine Verbindung nicht „einfach so“ auf. Stattdessen stimmen sich Client und Server über einen Three-Way-Handshake ab. Der Ablauf ist konzeptionell simpel:

SYN: Der Client fragt eine Verbindung an („Ich möchte verbinden“).
SYN-ACK: Der Server bestätigt und antwortet („Ich bin bereit, bitte bestätige“).
ACK: Der Client bestätigt („Verstanden, Verbindung steht“).

Erst nach diesem Ablauf gilt die Verbindung als etabliert. Zwischen SYN und dem finalen ACK hält der Server typischerweise einen Zwischenzustand vor: Er merkt sich, dass eine Verbindung angefragt wurde, und reserviert Ressourcen, um den Handshake abzuschließen. Genau dieser Zwischenzustand ist der Ansatzpunkt für SYN-Floods.

Was ist ein SYN-Flood?

Bei einem SYN-Flood wird ein Zielsystem mit einer großen Anzahl an TCP-SYN-Anfragen konfrontiert, ohne dass die Verbindungen sauber abgeschlossen werden. Das führt dazu, dass der Server (oder ein davorstehendes Gerät) viele halb-offene Verbindungen („half-open“) verwalten muss. Wenn die Kapazität für diese Zustände erschöpft ist, können legitime Clients keine neuen Verbindungen mehr aufbauen.

Wichtig ist die Einordnung: Ein SYN-Flood ist in der Regel ein Denial-of-Service-Problem (DoS) beziehungsweise in verteilten Varianten ein DDoS-Problem. Der Fokus liegt auf Verfügbarkeit, nicht auf Vertraulichkeit. Als Einstieg in die DoS-/DDoS-Thematik eignet sich Distributed Denial of Service.

Warum SYN-Floods funktionieren: Ressourcen, Backlog und Zustände

Damit ein Server TCP-Verbindungen handhaben kann, existieren interne Warteschlangen und Zustandslisten. Ein gängiges Modell ist eine Backlog-Queue für Verbindungsanfragen. Vereinfacht gesagt gilt: Wenn zu viele halb-offene Handshakes gleichzeitig offen sind, steigt die Wahrscheinlichkeit, dass neue legitime Anfragen abgewiesen oder verzögert werden.

Um das greifbar zu machen, hilft eine einfache Näherung: Die Anzahl der gleichzeitig offenen Handshakes hängt davon ab, wie viele SYN-Anfragen pro Sekunde eintreffen und wie lange ein Eintrag im „halb-offenen“ Zustand bestehen bleibt (Timeout). Eine grobe Beziehung lässt sich so ausdrücken:

$O \approx R \times T$

Dabei steht O für die ungefähre Anzahl gleichzeitig offener halb-offener Zustände, R für die Rate eingehender SYN-Anfragen (pro Sekunde) und T für die Zeit, bis ein unvollständiger Handshake verworfen wird (Timeout in Sekunden). Wird O größer als die Kapazität der Warteschlange bzw. der verfügbaren Ressourcen, wird die Annahme neuer Verbindungen instabil.

Zusammenhang mit IP-Spoofing: Warum die Herkunft oft „diffus“ wirkt

In vielen realen SYN-Flood-Szenarien tauchen extrem viele unterschiedliche Quell-IP-Adressen in Logs auf. Das kann zwei Gründe haben:

Verteilte Angriffe: Viele infizierte Geräte (Botnetze) senden SYNs von echten Quellen.
IP-Spoofing: In manchen Kontexten werden Quell-IPs gefälscht, um Filter zu umgehen oder die Rückverfolgung zu erschweren.

Das ist ein wichtiger OSI-Punkt: Der SYN-Flood trifft Schicht 4 (TCP), während IP-Spoofing auf Schicht 3 (IP) spielt. Für das Verständnis der IP-Ebene ist Internet Protocol hilfreich.

Typische Symptome: Wie ein SYN-Flood in der Praxis aussieht

Da die Attacke Schicht 4 trifft, zeigen sich die Symptome häufig als Verbindungsprobleme:

Neue Verbindungen hängen oder brechen beim Aufbau ab (Handshake kommt nicht zustande).
Timeouts in Clients, Browsern oder API-Clients, oft ohne klare Fehlermeldung.
Stark erhöhte Latenz bei gleichzeitig sinkender Erfolgsquote neuer Sessions.
Nur „bestehende“ Verbindungen funktionieren noch, neue sind betroffen (typisch bei Zustandsüberlast).
Spikes auf Load Balancern oder Firewalls, die viele Verbindungszustände führen müssen.

Auf Anwendungsebene wirkt es dann, als sei „die Website down“, obwohl CPU und RAM des Webservers möglicherweise noch nicht am Limit sind. Das ist ein Grund, warum das OSI-Modell im Troubleshooting so hilfreich ist: Es zwingt dazu, zwischen Netzwerk/Transport und Anwendung zu unterscheiden.

Erkennung: Woran erkennen Sie einen SYN-Flood zuverlässig?

Eine belastbare Diagnose entsteht meist aus der Kombination mehrerer Datenquellen. Achten Sie auf Indikatoren, die eindeutig zur Transportschicht passen:

Auffällige SYN-Raten und unausgewogene Flags

Sehr viele SYN-Pakete auf einem oder wenigen Zielports (z. B. 443, 80, 22).
Ungewöhnlich wenige abgeschlossene Handshakes im Verhältnis zu SYNs (wenig ACK/established).
Viele Verbindungen im Zwischenzustand („SYN-RECEIVED“ oder vergleichbare Zustände, je nach System).

State-Table-/Conntrack-Auslastung auf Netzwerkgeräten

In der Praxis sind nicht nur Server betroffen. Häufig kollabieren zuerst Geräte, die Zustände speichern müssen:

Firewalls mit Stateful Inspection
Load Balancer mit TCP-Termination
NAT-Gateways, die Verbindungszustände abbilden

Wenn die State-Table voll läuft, können auch andere Dienste neben dem eigentlichen Zielport leiden.

Flow-Daten und Metriken

Hohe Anzahl kurzer, unvollständiger Flows zum Ziel.
Viele unterschiedliche Quellen (bei DDoS/Botnetzen) oder auffällige Quell-IP-Muster.
Traffic-Spitzen, die zeitgleich mit Fehlern in Monitoring/SLAs auftreten.

SYN-Flood vs. ähnliche Probleme: Häufige Verwechslungen

Nicht jede Verbindungsstörung ist ein SYN-Flood. Folgende Ursachen können ähnlich aussehen:

Überlastete Anwendung/Server: CPU/RAM am Limit, Threads erschöpft, aber nicht zwingend viele SYNs.
DNS-Probleme: Domain wird nicht aufgelöst, wirkt wie „Website down“, ist aber Schicht 7.
Routing/Provider-Störung: Pakete erreichen das Ziel nicht oder nur sporadisch (Schicht 3).
MTU/Fragmentierungsprobleme: Bestimmte Verbindungen brechen, je nach Pfad und Paketgröße (Schicht 3/2, je nach Kontext).

Die wichtigste Unterscheidung ist: Bei einem SYN-Flood sehen Sie typischerweise unverhältnismäßig viele SYNs und zu viele halb-offene Zustände. Wenn diese Signale fehlen, liegt die Ursache oft woanders.

Schutzmaßnahmen: Was hilft wirklich gegen SYN-Floods?

Gegen SYN-Floods gibt es bewährte Gegenmaßnahmen. Welche Kombination sinnvoll ist, hängt von Größe und Kritikalität des Dienstes ab. Entscheidend ist der Grundsatz: Mitigation möglichst weit „vor“ dem Ziel (Upstream/Edge), damit das Ziel gar nicht erst in Zustandsnot gerät.

SYN Cookies und stateless Handshake-Strategien

SYN Cookies sind ein Mechanismus, bei dem ein Server den Zwischenzustand reduziert, indem er bestimmte Verbindungsinformationen kryptografisch in die Sequenznummer „kodiert“. Dadurch muss er nicht für jede SYN-Anfrage sofort Speicher reservieren. Das kann die Wirkung eines SYN-Floods deutlich abschwächen, weil die zentrale Schwachstelle – die Zustandsverwaltung – weniger angreifbar ist.

Rate Limiting und intelligente Filter am Edge

Rate Limits für SYN pro Quelle oder pro Ziel (vorsichtig konfigurieren, um legitimen Traffic nicht zu blockieren).
ACLs/Filter gegen offensichtlich ungültige Quellen (z. B. nicht routbare Netze).
Anti-Spoofing durch Ingress-/Egress-Filtering, um gefälschte Quellen zu reduzieren.

Gerade Anti-Spoofing ist wichtig, weil es die Qualität der Angriffsquelle beeinflusst. Als Referenzrahmen wird häufig BCP 38 genannt: BCP 38.

DDoS-Schutzdienste und Scrubbing

Wenn ein Angriff volumetrisch oder verteilt ist, reichen lokale Maßnahmen oft nicht. Dann sind Upstream-Mitigation, Anycast-basierte Infrastrukturen oder Scrubbing-Center entscheidend, um die Last zu absorbieren, bevor sie Ihre Anbindung oder Ihre Edge-Geräte überfordert.

Optimierung von Backlog, Timeouts und Ressourcen

In vielen Systemen lässt sich die Robustheit erhöhen, indem man Parameter sinnvoll anpasst. Dabei geht es nicht darum, „mehr zu vertragen um jeden Preis“, sondern um einen stabilen Betrieb:

Backlog-Größen und Grenzwerte realistisch dimensionieren
Timeouts für unvollständige Handshakes so konfigurieren, dass Ressourcen nicht unnötig lange gebunden werden
Monitoring auf halboffene Zustände und State-Table-Auslastung einrichten

Wichtig: Parameter-Tuning ist kein Ersatz für DDoS-Mitigation, aber ein wirksamer Baustein, um kleinere Angriffe oder Spikes abzufedern.

Load Balancing und Architekturmaßnahmen

Verteilung auf mehrere Frontends reduziert das Risiko, dass ein einzelner Host „zumacht“.
TCP-Termination an spezialisierten Geräten kann helfen, wenn diese ausreichend dimensioniert und geschützt sind.
Trennung von Diensten (z. B. Admin-Ports nicht öffentlich, separate Endpunkte) minimiert Angriffsfläche.

Wie SYN-Floods sich in der OSI-Logik nach oben auswirken

Obwohl der Angriff auf Schicht 4 stattfindet, melden Benutzer und Monitoring-Tools meist Symptome auf höheren Ebenen:

Schicht 7 (Application): HTTP 504/502, fehlgeschlagene API-Requests, Login-Probleme, „Service Unavailable“.
Schicht 6/5 (Presentation/Session): TLS-Handshakes schlagen fehl, Sessions werden nicht aufgebaut.
Schicht 3 (Network): Erreichbarkeit wirkt instabil, weil Verbindungen nicht zustande kommen.

Für Troubleshooting ist deshalb die Reihenfolge wichtig: Wenn neue Verbindungen schon auf TCP-Ebene scheitern, bringt es wenig, zuerst Anwendungslogs zu optimieren. Das OSI-Modell hilft, den Fokus richtig zu setzen.

Praxisnahe Mini-Checkliste: Erste Diagnose ohne Aktionismus

Wenn Sie den Verdacht auf einen SYN-Flood haben, sind diese Schritte meist hilfreich, ohne in operative Details zu gehen:

Überprüfen Sie die SYN/ACK-Relation (kommen viele SYNs, aber kaum etablierte Sessions?).
Prüfen Sie State-Tabellen auf Firewalls/Load Balancern (Auslastung, Drops, Limits).
Korrelieren Sie mit Nutzerfehlern (wann begannen Timeouts, welche Ports sind betroffen?).
Verifizieren Sie Upstream-Schutz (DDoS-Mitigation aktiv, Filterregeln, Kapazitätsstatus).
Dokumentieren Sie Baselines (normale SYN-Raten und normale Verbindungszahlen pro Dienst).

Outbound-Links zur Vertiefung

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.