DDoS Layer 3/4: Mitigation-Playbook vom Edge bis zum Scrubbing

Ein DDoS Layer 3/4 Mitigation-Playbook beschreibt nicht nur einzelne technische Maßnahmen, sondern einen durchgängigen Ablauf: von der schnellen Verifikation am Edge über gezielte Filter und Rate Limits bis hin zur Eskalation in ein Scrubbing-Center oder eine Cloud-Mitigation. Layer-3/4-DDoS-Angriffe zielen auf Netzwerk- und Transportebene (IP, ICMP, UDP, TCP) und versuchen, Bandbreite, Paketverarbeitung (pps), State-Tabellen, NAT-Kapazitäten oder Upstream-Links zu überlasten. Für NOC- und SecOps-Teams ist der entscheidende Punkt: Je früher Sie Traffic „vor“ Ihrer Infrastruktur reduzieren, desto geringer ist der Blast Radius. Gleichzeitig dürfen Maßnahmen nicht unkontrolliert legitimen Traffic beschädigen – besonders bei UDP-basierten Services, VPNs oder Echtzeitkommunikation. Dieser Artikel liefert ein operatives Playbook mit klaren Schritten und Entscheidungspunkten, damit Sie DDoS-L3/L4-Incidents strukturiert behandeln: Erkennen, stabilisieren, sauber mitigieren, Beweise sichern und danach die Abwehr so verbessern, dass der nächste Angriff weniger Zeit und weniger Kollateralschäden verursacht.

Layer 3/4 DDoS verstehen: Ziele, Muster und typische Angriffsarten

Layer-3/4-DDoS ist selten „nur viel Traffic“. In der Praxis gibt es unterschiedliche Lastprofile, die verschiedene Schwachstellen ausnutzen:

• Bandwidth Flood: Sehr hoher Durchsatz (bps), häufig volumetrisch (z. B. UDP Amplification). Ziel: Uplink und Providerkapazität erschöpfen.
• Packet-per-second Flood: Sehr viele kleine Pakete (pps), z. B. UDP-Flood oder ICMP-Flood. Ziel: Forwarding/Control-Plane und Paketverarbeitung überlasten.
• State Exhaustion: TCP-SYN-Flood oder Verbindungsaufbau-Missbrauch. Ziel: State-Tabellen von Firewalls, Load Balancern oder NAT-Gateways füllen.
• Protocol Abuse: Fragment-Floods, ICMP-Typ-Missbrauch, fehlerhafte Checksums, ungewöhnliche Flags. Ziel: CPU/Parsing und Reassembly belasten.

Die wichtigste operative Konsequenz: Ein Mitigation-Schritt, der bei Bandwidth Flood wirkt (z. B. Upstream-Scrubbing), ist nicht automatisch der beste erste Schritt bei State Exhaustion (z. B. SYN-Cookies/Proxying, Connection Limits). Das Playbook muss daher mit klaren Diagnoseschritten starten.

Erkennung und Verifikation: Was muss in den ersten Minuten passieren?

Bevor Sie filtern oder eskalieren, müssen Sie in wenigen Minuten die grundlegenden Parameter bestimmen. Das reduziert Fehlmaßnahmen und beschleunigt die richtige Eskalation.

Minimaler Erstcheck (5–10 Minuten)

• Welche Targets? Betroffene VIPs, öffentliche IPs, DNS, VPN-Gateways, Edge-Firewalls, Anycast-IPs.
• Was ist das Lastprofil? bps vs. pps, Inbound vs. Outbound, Peak-Werte und Trend.
• Welches Protokoll/Port? ICMP-Typen, UDP-Ports, TCP-Flags (SYN/ACK/RST), Fragmentierung.
• Impact auf Service? Fehlerquote, Timeouts, Login-/VPN-Failures, API-Latenz, Paketverlust.
• Wo entsteht die Sättigung? ISP-Uplink, Edge-Router, Firewall, Load Balancer, Link zum DC, Cloud-Interconnect.

Telemetriequellen dafür sind typischerweise Interface-Utilization, Drops/Discards, CPU/ASIC-Load, Firewall-Session-Statistiken, NetFlow/sFlow/IPFIX sowie synthetische Checks (von außen und innen). Wenn möglich, sollten Sie parallel einen kurzen PCAP-Schnappschuss am Edge ziehen, um Protokollmerkmale sicher zu bestätigen.

Decision Tree: Wann Edge-Maßnahmen reichen – und wann sofort Scrubbing?

Ein Playbook braucht klare Schwellen, die nicht diskutiert werden müssen, wenn es brennt. Sinnvoll ist eine Kombination aus Kapazität und Service-Impact.

Pragmatische Eskalationslogik

• Edge first, wenn: Angriff unterhalb Ihrer Upstream-/Uplink-Kapazität liegt, das Lastprofil klar identifiziert ist und gezielte Filter/Rate Limits möglich sind.
• Sofort Scrubbing, wenn: Ihre Uplink-Bandbreite oder Provider-Portkapazität sichtbar sättigt, Drops vor Ihrer Infrastruktur auftreten oder der Angriff stark verteilt/volumetrisch ist (klassisch bei Amplification).
• Hybrid, wenn: Ein Teil als volumetrischer Flood kommt, aber gleichzeitig State/CPU an Security-Geräten steigt. Dann parallel upstream entlasten und lokal härten.

Zur Orientierung kann ein einfaches Kapazitätsmodell helfen: Wenn ein Angriff dauerhaft über ~60–70% der nutzbaren Uplink-Kapazität liegt und bereits Paketdrops sichtbar sind, verschiebt sich der Nutzen stark Richtung Upstream-Mitigation. Gleichzeitig gilt: pps kann Ihre Geräte killen, auch wenn bps „harmlos“ aussieht.

Edge-Mitigation: Filter, Rate Limits und Schutzmechanismen (ohne Kollateralschaden)

Edge-Maßnahmen sind schnell, aber riskant, wenn sie zu grob sind. Ziel ist, die Angriffssignatur zu reduzieren, ohne geschäftskritische Protokolle zu brechen. In vielen Umgebungen ist „drosseln“ besser als „droppen“.

Grundprinzipien für sicheres Blocking

• Zielgenau statt global: Wenn möglich pro Ziel-IP/VIP oder pro Service-Subnetz begrenzen, nicht „alles UDP“.
• Stufenweise schärfen: Erst Rate Limit, dann enger filtern, erst zuletzt harte Drops.
• Stateless bevorzugen: Filters auf Routern/ACLs sind oft stabiler als stateful Regeln auf Firewalls unter Last.
• Messung nach jeder Änderung: bps/pps, Drops, CPU, Sessions, Applikationsmetriken.

Mitigation nach Angriffsart: Konkrete Maßnahmen auf Layer 3/4

ICMP Flood (Echo, Destination Unreachable, Fragmentation Needed)

• Rate Limiting auf ICMP, statt komplettes Blocken: ICMP ist wichtig für PMTUD und Fehlermeldungen.
• Typ-basiertes Filtering: Echo-Request ggf. stärker begrenzen als notwendige ICMP-Fehler (abhängig von Ihren Anforderungen).
• Control-Plane Protection aktivieren, damit ICMP nicht die CPU des Routers frisst.

ICMP-Funktion und Bedeutung für Fehlerdiagnose und PMTUD ist in RFC 792 (ICMP) sowie für ICMPv6 in RFC 4443 beschrieben.

UDP Flood und UDP Amplification

• Top-Port-Analyse: Dominierende UDP-Zielports identifizieren (z. B. 53, 123, 389, 1900).
• Wenn Service nicht benötigt: Zielport inbound am Perimeter blocken (z. B. UDP/1900 in vielen Enterprises).
• Wenn Service benötigt: Rate Limit pro Ziel-IP/VIP, optional nach Paketgröße (große Responses) oder nach Source-Cardinality.
• Fragmentierung beachten: Große UDP-Responses können Reassembly-Last erzeugen; fragmentierte Pakete ggf. stärker begrenzen.

Bei Reflection/Amplification ist Quell-IP-Blocking meist ineffizient, weil die Quellen Reflektoren sind. Hier wirkt Scrubbing besonders gut, weil es massiv skaliert und Muster besser herausfiltert.

TCP SYN Flood (State Exhaustion)

• SYN Cookies auf Servern/Load Balancern aktivieren, wo möglich.
• Connection Limits: pro Source-IP oder pro /24-/ /64-Präfix, abhängig von Kundenprofil.
• TCP Proxying am Edge/WAF/LB: Handshake terminieren, bevor er Ihre Applikation erreicht.
• Stateful Firewall entlasten: SYN-Floods können State-Tabellen füllen; stateless ACLs oder spezielle DDoS-Profile nutzen.

TCP-Verhalten und Flags sind in RFC 9293 (TCP) dokumentiert. Für viele Umgebungen ist die wichtigste Praxisregel: SYN-Flood-Mitigation möglichst nahe am ersten Gerät durchführen, das stateful wird.

Fragment Floods und Paket-Anomalien

• Fragment Rate beobachten: Sprünge in Fragmenten sind ein DDoS-Indikator.
• Reassembly schützen: Reassembly ist CPU-intensiv; Limits und Policies auf Geräten prüfen.
• Drop offensichtlicher Anomalien: ungültige Checksums, unmögliche Kombinationen von Flags, „teardrop“-ähnliche Muster (je nach Plattform).

Grundlagen der IP-Fragmentierung finden sich in RFC 791 (IPv4) sowie für IPv6 in RFC 8200.

Vom Edge zum Provider: Upstream-Optionen (BGP, RTBH, FlowSpec)

Wenn die Sättigung vor Ihrer Infrastruktur passiert, müssen Sie Traffic upstream reduzieren. Je nach Provider und Setup haben Sie unterschiedliche Hebel:

• Provider-Filter / ACLs: Der Provider filtert am Peering/Transit für Ihre Prefixes.
• RTBH (Remote Triggered Black Hole): „Not-Aus“ für einzelne IPs oder Prefixes – Traffic wird upstream verworfen.
• BGP FlowSpec: Granularere Filterregeln über BGP, z. B. match auf Port/Protokoll. Eignet sich für schnelle, zielgerichtete Mitigation – abhängig von Provider-Support.

RTBH und FlowSpec sind leistungsfähig, aber governance-intensiv: Sie benötigen klare Freigaberegeln, Monitoring und einen Rollback-Plan, damit Sie nicht versehentlich Produktivtraffic wegfiltern.

Scrubbing-Center und Cloud-DDoS: Wann es unverzichtbar wird

Scrubbing ist die skalierte Form der Mitigation: Traffic wird in ein Scrubbing-Center umgeleitet, dort gefiltert und „sauber“ zu Ihnen zurückgetunnelt. Das ist besonders wirksam bei volumetrischen Angriffen und Reflection-Kampagnen.

Typische Scrubbing-Architekturen

• Always-on: Ihre Prefixes sind dauerhaft über den Scrubbing-Anbieter annonciert. Vorteil: schnelle Reaktion, weniger Umschaltstress. Nachteil: permanenter Pfad über Drittanbieter.
• On-demand: Umschaltung erst im Angriff (BGP-Diversion). Vorteil: Normalbetrieb bleibt direkt. Nachteil: Aktivierungszeit und mögliche Umschaltfehler.
• Hybrid: Kritische Services always-on, rest on-demand.

Wichtig ist, dass Ihr Playbook die Umschaltprozedur konkret beschreibt: Wer darf BGP-Diversion auslösen? Welche Prefixes? Wie wird der Erfolg validiert? Wie ist der Rückweg (GRE/IPsec) dimensioniert?

Runbook-Schritte: Mitigation-Playbook als operativer Ablauf

Ein gutes Playbook ist eine Checkliste mit Entscheidungen, nicht ein Lehrbuch. Der folgende Ablauf ist in vielen Enterprise- und Provider-Umgebungen praxistauglich:

Phase 1: Triage und Stabilisierung

• Alarm verifizieren: bps/pps, betroffene Targets, Protokoll/Port, Service-Impact.
• Sichtbarkeit herstellen: Flow-Daten aktivieren, Edge-Interface-Stats, Firewall-Session-Stats, externe Checks.
• Kommunikation starten: Incident-Channel, Rollen (Incident Commander, Netzwerk, Security, Provider Liaison).

Phase 2: Sofortmaßnahmen am Edge

• Wenn möglich: stateless ACL/Policer am Border für dominante Signatur (Port/ICMP-Typ/Flags).
• Stateful Geräte schützen: Session-Limits, SYN-Schutz, CPU-Protection, Log-Rate reduzieren (Logging kann Geräte zusätzlich töten).
• Nachmessen: pps/bps/Drops/CPU und Applikationsmetriken.

Phase 3: Upstream/Eskalation

• Wenn Uplink sättigt: Provider kontaktieren, Mitigation anfordern, ggf. FlowSpec/ACLs aktivieren.
• Wenn einzelne VIP unhaltbar: RTBH für diese IP als Notbremse (bewusstes Opfer, um Rest zu retten).
• Wenn großflächig/volumetrisch: Scrubbing aktivieren (on-demand) oder Anbieter eskalieren (always-on prüfen).

Phase 4: Evidence Pack und Nachbereitung (ohne die Mitigation zu gefährden)

• PCAP-Schnappschuss (kurz, gezielt) und Flow-Reports sichern.
• Änderungen protokollieren: Zeitpunkt, Maßnahme, Effekt, Rollback-Plan.
• Nach Stabilisierung: Root-Cause-Analyse (Angriffsvektor, Eintrittspunkt, Wirksamkeit der Controls).

Monitoring und Thresholds: Was ein NOC für L3/L4-DDoS zwingend braucht

• bps und pps pro Uplink und pro VIP/Service (pps ist oft der unterschätzte Killer).
• Drops/Discards am Interface (in/out), Queue Drops, Policer Drops.
• CPU/ASIC und Control-Plane-Indikatoren auf Edge-Routern/Firewalls.
• Session/Conn-Tabellen (Firewall, NAT, Load Balancer) inkl. Auslastung und Rate.
• Flow-Cardinality: eindeutige Quellen, Zielports, ASNs – besonders hilfreich bei Reflection.

Als Designprinzip sollten Schwellenwerte nicht nur „High Utilization“ melden, sondern gleichzeitig Kontext liefern: Welcher Port? Welches Ziel? Welche Veränderung gegenüber Baseline? Das reduziert Alert Fatigue und beschleunigt die richtige Mitigation.

Hardening und Prävention: Maßnahmen, die DDoS-Mitigation messbar erleichtern

• Anti-Spoofing (BCP38) auf Egress: verhindert, dass Sie selbst als Ausgangspunkt für Reflection missbraucht werden. Referenz: RFC 2827 (BCP38).
• Expose-Minimierung: Keine unnötigen UDP-Dienste öffentlich, Management nur via sichere Pfade.
• Anycast/Verteilung für DNS oder globale Services: reduziert Hotspots und verteilt Last.
• Kapazitätsplanung: Uplink-Reserven, Headroom und klare Scrubbing-Verträge/Runbooks.
• Test der Umschaltung: Scrubbing on-demand und BGP-Runbooks regelmäßig üben (Game Days).

Outbound-Links für vertiefende Standards und Best Practices

• BCP38 / RFC 2827: Network Ingress Filtering (Anti-Spoofing)
• RFC 9293: Transmission Control Protocol (TCP)
• RFC 792: Internet Control Message Protocol (ICMP)
• RFC 791: Internet Protocol (IPv4)
• RFC 8200: Internet Protocol, Version 6 (IPv6)
• MANRS: Best Practices für Routing- und Netzwerksicherheit

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.