DDoS Runbooks: Playbooks für schnelle Reaktion und Kommunikation

DDoS Runbooks sind der Unterschied zwischen „wir reagieren irgendwie“ und einer kontrollierten, schnellen Abwehr mit klarer Kommunikation. In vielen Organisationen ist die Technik für DDoS-Schutz vorhanden – Scrubbing-Option beim Provider, RTBH/Flowspec-Mechanismen, WAF-Regeln, Rate Limits –, aber im Ernstfall fehlen die Playbooks: Wer entscheidet? Wer setzt welche Maßnahme? Welche Daten braucht das NOC/SOC? Wie informieren wir Management, Support, Kunden und Provider, ohne Chaos zu erzeugen? Genau deshalb sind DDoS Runbooks nicht nur ein Dokument, sondern ein operatives System: vordefinierte Rollen, Checklisten, Eskalationspfade, technische Schritte, Kommunikationsvorlagen und klare Kriterien für „weiter eskalieren“ oder „zurückbauen“. Das Hauptkeyword „DDoS Runbooks“ steht damit für eine praktische Incident-Fähigkeit, die sich üben und kontinuierlich verbessern lässt. Dieser Artikel zeigt, wie Sie Playbooks für schnelle Reaktion und Kommunikation entwickeln, welche Inhalte wirklich zählen, wie Sie technische Maßnahmen in Stufen ausrollen und wie Sie die typischen Fehler vermeiden, bei denen Schutzmaßnahmen selbst zum Ausfall führen.

Was ein DDoS Runbook leisten muss und was nicht

Ein gutes Runbook ist kein Lehrbuch über DDoS, sondern eine Anleitung für konkrete Entscheidungen und Handgriffe in den ersten Minuten eines Angriffs. Es beantwortet vier Fragen:

• Erkennen: Ist es wirklich ein DDoS? Welcher Vektor? Welche Services sind betroffen?
• Entscheiden: Welche Maßnahme ist in welcher Eskalationsstufe erlaubt und sinnvoll?
• Handeln: Wer setzt technisch um (und wie), inklusive Rollback?
• Kommunizieren: Wen informieren wir wann – intern und extern – mit welchen Aussagen?

Was ein Runbook nicht sein sollte: eine Sammlung ungetesteter „Ideen“. Jede Maßnahme im Runbook muss in Ihrer Umgebung praktisch umsetzbar sein, inklusive Berechtigungen, Tools, Kontaktwegen und Zeitbedarf.

Grundstruktur eines DDoS Runbooks

Bewährt hat sich eine modulare Struktur, damit Teams nicht im Dokument suchen müssen, sondern direkt zum passenden Playbook springen:

• Runbook-Übersicht: Rollen, Kontaktlisten, Entscheidungsbefugnisse, Eskalationsstufen
• Detection & Triage: Checkliste zur Einordnung (Volumen, PPS, CPS, Layer 7)
• Playbooks nach Vektor: z. B. volumetrisch, SYN/State, DNS/NTP Amplification, HTTP Flood
• Playbooks nach Ziel: z. B. Internet Edge, Web/CDN, API, VPN/Remote Access, DNS
• Kommunikationspaket: Vorlagen für interne Updates, Provider-Tickets, Kundenstatus, Managementbriefing
• Post-Incident: Rückbau, Nachweise, Lessons Learned, KPI-Review

Ein wichtiger Punkt: Das Runbook ist so gut wie seine Aktualität. Kontaktlisten, Communities, Prefixes, Scrubbing-Parameter und Eskalationsregeln müssen regelmäßig rezertifiziert werden.

Rollenmodell: Wer darf was entscheiden?

DDoS-Ereignisse sind zeitkritisch. Wenn bei jeder Maßnahme erst „jemand gefragt“ werden muss, verlieren Sie Minuten. Gleichzeitig sind Maßnahmen wie RTBH oder Flowspec hochriskant, wenn sie falsch eingesetzt werden. Ein klares Rollenmodell löst diesen Konflikt:

• Incident Commander: trifft Entscheidungen, koordiniert, priorisiert, dokumentiert
• NOC Lead: Netzwerkmaßnahmen, Providerkoordination, Routing/Edge
• SOC Lead: Security-Bewertung, Indikatoren, Missbrauchsanalyse, Forensik
• App/Service Owner: Gesundheitszustand der Anwendung, WAF-/App-Tuning, Feature Flags
• Comms/PR: externe Kommunikation, Statuspage, Kundenupdates (bei Bedarf)
• Management Liaison: Management-Updates, Entscheidungen zu Risiko/Verfügbarkeit (z. B. „RTBH zulässig?“)

Best Practice ist eine „RACI“-Logik (Responsible, Accountable, Consulted, Informed) pro Eskalationsstufe, damit es im Ernstfall keine Diskussionen über Zuständigkeiten gibt.

Eskalationsstufen: Von „beobachten“ bis „Notbremse“

Runbooks funktionieren am besten, wenn sie nicht mit der härtesten Maßnahme starten. Stattdessen definieren Sie Stufen mit klaren Triggern und erlaubten Aktionen. Ein praxistaugliches Modell:

• Stufe 0 – Normalbetrieb: Baseline-Monitoring, vorbereitete Tools, getestete Umleitung
• Stufe 1 – Verdacht: Triage, Verifikation, erste Limits/Signaturen, Kommunikation intern
• Stufe 2 – Confirmed DDoS: gezielte Filters (WAF/Rate Limits), Flowspec/Policer, Provider-NOC informieren
• Stufe 3 – Severe: Scrubbing aktivieren (on-demand) oder Traffic auf Always-on-Pfad schieben
• Stufe 4 – Critical: RTBH für einzelne Ziele (Notbremse), wenn Netzstabilität gefährdet ist
• Stufe 5 – Recovery: Rückbau, Beobachtung, Postmortem, Verbesserung

Die Trigger sollten messbar sein (z. B. Bandbreite, PPS, CPS, Error Rate, Timeouts), nicht nur „fühlt sich schlimm an“.

Detection & Triage: Die ersten 5 Minuten

Das wichtigste Playbook ist die Triage-Checkliste. Sie soll in wenigen Minuten einordnen, ob es DDoS ist und welcher Typ. Beispielhafte Triage-Schritte:

• Service-Sicht: Welche Services sind betroffen (Web, API, DNS, VPN)? Welche Symptome (5xx, Timeouts, Login-Fails)?
• Netz-Sicht: Interface-Auslastung, PPS, Drops, Queue-Overruns, Fehlerzähler am Edge/Load Balancer
• State-Sicht: CPS, Concurrent Sessions, SYN backlog, NAT Allocation Failures (falls relevant)
• Traffic-Muster: Top Protocols, Top Destination Ports, Top Talkers, Geo-Verteilung, ungewöhnliche User-Agents
• Abgrenzung: DDoS vs. interner Incident (z. B. DB down, DNS fehlerhaft, Zertifikat abgelaufen)

Wenn Sie NetFlow/IPFIX nutzen, ist das oft der schnellste Weg zur Einordnung. Für strukturierte Sicherheitskontrollen rund um Monitoring und Incident Management sind die CIS Controls eine gute Referenz.

Playbook: Volumetrischer Angriff (Leitung/Upstream gesättigt)

Volumetrische Angriffe erkennen Sie typischerweise an sehr hoher Bandbreite (Gbit/s) oder PPS, die Ihre Uplinks oder Peering-Ports an die Grenze bringt. Lokale Firewalls können dann wenig ausrichten, weil die Leitung bereits voll ist. Das Runbook muss hier stark auf Upstream und Umleitung setzen:

• Schritt 1: Verifizieren, welche Präfixe/Targets betroffen sind (Destination IPs, Ports)
• Schritt 2: Provider-NOC kontaktieren (vorbereitete Ticketvorlage, klare Daten: Targets, Zeitpunkt, Peaks)
• Schritt 3: On-demand Scrubbing aktivieren (BGP-Umleitung), falls nicht always-on
• Schritt 4: Falls Scrubbing nicht schnell genug greift: temporär RTBH für einzelne Hostroutes als Schutz der Gesamtkonnektivität
• Schritt 5: Monitoring: Stabilisieren sich Interfaces, RTT, Loss? Werden legitime Flows durchgelassen?

Wichtig: Das Runbook muss enthalten, welche Präfixe Sie zum Scrubber announcen dürfen, welche Communities zu setzen sind und wie Sie anschließend wieder zurückschwenken.

Playbook: SYN Flood und State Exhaustion (CPS/Session Tables)

State-Angriffe können Ihr Netz lahmlegen, obwohl die Bandbreite nicht extrem wirkt. Typische Indikatoren sind steigende CPS, hohe SYN-Raten, Session Table Pressure und Drops auf stateful Geräten. Maßnahmen sind oft lokal wirksam:

• Schritt 1: Prüfen: SYN rate, TCP flags, CPS, drops „no session“, SYN cookies (falls sichtbar)
• Schritt 2: Edge-ACL/Flowspec: SYN-only Traffic auf betroffene Ziele/Ports droppen oder policen
• Schritt 3: Load Balancer/WAF: Connection Limits, per-IP Rate Limits, aggressive timeouts nur gezielt
• Schritt 4: Scrubbing eskalieren, wenn Angriff so groß ist, dass lokale Geräte an Grenzen kommen

Hier ist Flowspec besonders nützlich, weil es sehr gezielt auf „TCP SYN to destination port X“ matchen kann. Für Flowspec-Details ist RFC 8955 eine robuste Referenz.

Playbook: Amplification (DNS/NTP/CLDAP) – Reflexionsangriffe

Amplification-Angriffe basieren häufig auf Spoofing und erzeugen hohen Traffic zu Ihrem Ziel. Das Runbook sollte eine Kombination aus Upstream-Scrubbing und gezielten Filtern vorsehen:

• Schritt 1: Identifizieren: Zielport (typisch UDP/53, UDP/123), Paketgrößenmuster, PPS
• Schritt 2: Provider/Scrubber aktivieren (weil Volumen oft hoch ist)
• Schritt 3: Flowspec/ACL: UDP-Port gezielt droppen oder policen (nur für angegriffene Zielhosts/Services)
• Schritt 4: Falls Ihr eigener DNS betroffen ist: Response Rate Limiting (RRL), Anycast, WAF/CDN-Entlastung, getrennte Resolver

Ein zentraler Präventionsbaustein ist Anti-Spoofing (BCP38). Als Standardreferenz ist BCP 38 (Network Ingress Filtering) relevant.

Playbook: HTTP Flood und Bot-basierte Layer-7-Überlast

Layer-7-DDoS sieht oft wie „viel legitimer Traffic“ aus. Bandbreite kann moderat sein, aber CPU/Threads im Webstack, Caches oder Backends brechen. Hier sind WAF/CDN und App-Maßnahmen entscheidend:

• Schritt 1: App-KPIs prüfen (5xx, Latenz, Queue-Längen, DB-Timeouts) und Scope definieren
• Schritt 2: CDN/WAF aktivieren oder Policy verschärfen: Bot-Management, Challenge, Rate Limits
• Schritt 3: Schutz nach Endpunkt: teure URLs/Methoden (Search, Login, Export) härter limitieren
• Schritt 4: Feature Flags: nicht essentielle Funktionen temporär deaktivieren (z. B. Reports, große Exporte)
• Schritt 5: Scrubbing ist hier nur begrenzt hilfreich; Fokus liegt auf Applikationskontrollen

Das Runbook sollte dazu eine „WAF-Policy-Library“ enthalten: vordefinierte Rulesets für unterschiedliche Angriffsprofile, die schnell aktivierbar sind.

RTBH Runbook: Die Notbremse sicher beherrschen

RTBH ist effektiv, aber riskant, weil Sie Traffic bewusst verwerfen. Das Runbook muss deshalb besonders streng sein:

• Zulässige Ziele: Nur Hostroutes oder klar definierte Präfixgrößen (z. B. maximal /32) – keine „großen“ Blackholes ohne Managementfreigabe
• Autorisierte Trigger: Nur definierte Systeme/Accounts dürfen RTBH announcen
• Timeboxing: Standardmäßig Ablauf nach z. B. 15–30 Minuten, mit Verlängerung nur nach Review
• Kommunikation: Interner Hinweis an Support/Service Owner („Ziel bewusst offline, um Netz stabil zu halten“)
• Rollback: Entfernen des RTBH und Verifikation, dass normale Routen wieder greifen

Für BGP-Blackholing per Community ist RFC 7999 eine hilfreiche Referenz.

Flowspec Runbook: Guardrails gegen „selbst verursachte Ausfälle“

Flowspec ist mächtig, weil Sie sehr granular filtern können. Genau deshalb braucht es Guardrails im Runbook:

• Regel-Templates: Vordefinierte, geprüfte Matches (z. B. UDP/53 to host X drop; TCP SYN to port Y policer)
• Scope-Kontrolle: Jede Regel muss ein Zielpräfix oder Host enthalten; keine globalen „drop UDP/53“ Regeln
• Approval-Grenzen: Bestimmte Actions (Drop vs. Policer) erfordern unterschiedliche Freigaben
• Expiry: Jede Flowspec-Regel hat ein Ablaufdatum und wird automatisch/prozessual entfernt
• Messung: Hit-Counter, PPS/BW-Reduktion, Service-Health prüfen, bevor eskaliert wird

Kommunikation: Das zweite Standbein jedes DDoS Runbooks

DDoS ist immer auch ein Kommunikationsereignis. Ohne klare Kommunikation entsteht intern Panik, extern Vertrauensverlust und beim Provider ineffiziente Zusammenarbeit. Ein Runbook sollte Kommunikationswege und Vorlagen enthalten.

Interne Kommunikation in drei Zielgruppen

• Technische Teams (NOC/SOC/App): Fakten, Metriken, geplante Maßnahmen, konkrete Tasks
• Management: Impact, Risiko, ETA (nur wenn belastbar), Maßnahmenstatus, Entscheidungsbedarf (z. B. RTBH-Freigabe)
• Support/Customer Success: Kundensicht, Workarounds, Statuspage-Text, Ticket-Handling

Externe Kommunikation: kurz, konsistent, faktenbasiert

• Statuspage-Updates: Was ist betroffen (Service), welche Symptome, seit wann, was tun wir
• Kundenkommunikation: Verfügbarkeit, Workarounds, keine technischen Spekulationen
• Provider/Partner: Präzise technische Daten (Targets, Zeiten, Peaks, gewünschte Maßnahmen)

Kommunikationsvorlagen, die ins Runbook gehören

• Initial Alert (intern): „Confirmed DDoS, betroffen: X, Startzeit: Y, Peak: Z, nächste Maßnahme: …“
• Provider Ticket: Targets (IPs/Ports), Zeitfenster, Metriken (BW/PPS), gewünschte Aktion (Scrubbing/Blackhole), Rückrufnummer
• Statuspage: „Wir sehen erhöhte Fehlerraten/Verzögerungen für …, Ursache: Netzwerküberlast durch externe Traffic-Spitzen, Mitigation läuft.“
• Post-Incident Update: „Mitigation aktiv, Service stabil, Monitoring verstärkt, nächste Updates alle X Minuten.“

Entscheidungsmatrix: Welche Maßnahme wann?

Damit Entscheidungen nicht ad hoc getroffen werden, hilft eine einfache Matrix im Runbook. Beispielhaft:

• Bandbreite am Uplink > 80% und steigend: Scrubbing eskalieren (on-demand), ggf. temporäre RTBH-Hostroutes
• PPS/CPS extrem hoch, Bandbreite moderat: Flowspec/ACL gegen spezifische Ports/Flags, Edge-Rate Limits
• HTTP 5xx steigt, Edge normal: WAF/CDN/Rate Limits/Challenge, App-Feature Flags
• Einzelnes Ziel gefährdet Gesamtnetz: RTBH für Hostroute mit Timebox

Die Matrix sollte an Ihre Architektur gekoppelt sein (Scrubbing verfügbar? Flowspec im Netz erlaubt? CDN/WAF vorhanden?).

Dokumentation und Evidence: Warum Postmortems ohne Daten wertlos sind

Ein DDoS Runbook sollte festlegen, welche Daten während des Incidents gesichert werden, damit Sie später verbessern können:

• Timeline: Start, Erkennung, Maßnahmen, Eskalationen, Stabilisierung, Rückbau
• Metriken: Peak BW/PPS/CPS, betroffene Targets, Top Ports/Protocols, geographische Muster
• Maßnahmen: Welche Flowspec/RTBH/Scrubbing-Änderungen wurden gesetzt (inkl. IDs/Communities), von wem, warum
• Wirkung: Vorher/Nachher-Service-Health, Drops/Policer-Hits, RTT-Änderungen
• Kommunikation: Wann wurde intern/extern informiert, welche Aussagen wurden gemacht

Für auditierbare Verantwortlichkeiten und Incident-Prozesse kann ISO/IEC 27001 als Referenz dienen.

Übungen und Drills: Runbooks müssen trainiert werden

Runbooks sind nur dann schnell, wenn Teams sie geübt haben. Sinnvolle Formate:

• Tabletop Exercise: Szenarien durchspielen (z. B. volumetrisch vs. HTTP Flood), Rollen und Kommunikation testen
• Technische Drills: RTBH setzen und entfernen, Flowspec-Regel aktivieren, Scrubbing umschalten (im Wartungsfenster)
• Kommunikationsdrill: Statuspage-Update, Management-Update, Provider-Ticket innerhalb von 10 Minuten
• Post-Drill Review: Was war unklar? Welche Daten fehlten? Welche Berechtigungen/Tools waren nicht verfügbar?

Ein gutes Ziel ist, dass ein On-Call-Team die Kernmaßnahmen ohne Expertenwissen aus dem Kopf, aber entlang des Runbooks sicher ausführen kann.

Typische Fehler in DDoS Runbooks und wie Sie sie vermeiden

• Zu technisch, zu wenig operativ: Gegenmaßnahme: Checklisten, Trigger, klare Schritte, keine Theorieblöcke
• Kontaktlisten veraltet: Gegenmaßnahme: quartalsweise Rezertifizierung, automatisierte Ownership
• Maßnahmen ohne Rollback: Gegenmaßnahme: jeder Schritt hat „remove/rollback“ und Verifikationschecks
• Keine Guardrails für RTBH/Flowspec: Gegenmaßnahme: Scope-Limits, Timeboxing, autorisierte Trigger
• Kommunikation improvisiert: Gegenmaßnahme: Vorlagen, definierte Update-Frequenzen, ein Sprecher
• Trigger nur auf Bandbreite: Gegenmaßnahme: PPS/CPS/Session KPIs und App-Metriken einbeziehen

Praktische Checkliste: DDoS Runbooks in Enterprise-Qualität erstellen

• 1) Architektur inventarisieren: Scrubbing verfügbar? RTBH/Flowspec möglich? WAF/CDN? Welche Providerkontakte?
• 2) Rollen und Befugnisse definieren: Incident Commander, autorisierte Trigger, Freigabegrenzen
• 3) Eskalationsstufen festlegen: messbare Trigger, erlaubte Aktionen pro Stufe
• 4) Playbooks schreiben: Volumen, State, Amplification, HTTP Flood, DNS/VPN-Sonderfälle
• 5) Kommunikationspaket bauen: interne/externe Vorlagen, Statuspage-Texte, Provider-Ticket-Template
• 6) Guardrails einbauen: Timeboxing, Scope-Limits, Rollback, Verifikationschecks
• 7) Monitoring-KPIs definieren: BW/PPS/CPS, Drops, Service-Health, Route-Changes, Logpipeline-Health
• 8) Drills planen: Tabletop + technische Tests, mindestens halbjährlich
• 9) Postmortem-Prozess: Evidence-Sammlung, Lessons Learned, Maßnahmen-Backlog
• 10) Rezertifizierung: quartalsweise Review von Kontakten, Communities, Prefixes, Runbook-Version

Outbound-Quellen für Standards und Vertiefung

• RFC 7999 für Blackholing per BGP Community als Grundlage für RTBH-Runbooks.
• RFC 8955 für BGP Flowspec (IPv4) und die Logik von Flow-Matches und Actions.
• BCP 38 (Network Ingress Filtering) für Anti-Spoofing als Basiskontrolle gegen spoofing-basierte Amplification.
• CIS Controls für praxisnahe Kontrollen zu Incident Response, Monitoring und Change-Management.
• ISO/IEC 27001 Überblick für auditierbare Verantwortlichkeiten, Prozesse und Nachweise im Security-Betrieb.

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.