DDoS-Design: Scrubbing, RTBH, Flowspec und Playbooks

DDoS-Design: Scrubbing, RTBH, Flowspec und Playbooks ist für Betreiber von Internetdiensten, Unternehmensnetzwerken und Cloud-Plattformen ein unverzichtbarer Architekturbaustein. Distributed-Denial-of-Service-Angriffe sind längst nicht mehr nur ein „Provider-Problem“, sondern treffen auch mittelgroße Organisationen, E-Commerce, Medien, SaaS-Plattformen und öffentliche Einrichtungen. Besonders gefährlich ist, dass DDoS selten nur Bandbreite „wegdrückt“: Moderne Angriffe kombinieren volumetrische Fluten (z. B. UDP-Floods) mit Protokoll- und State-Angriffen (z. B. SYN-Floods) sowie Application-Layer-Attacken (z. B. HTTP-Floods), die Reverse Proxies, Load Balancer oder Backends überlasten. Ein wirksames DDoS-Design setzt daher nicht auf eine einzelne Maßnahme, sondern auf ein abgestuftes, wiederholbares Konzept: Detektion über Telemetrie und Flow-Daten, schnelle Mitigation über Scrubbing-Center, RTBH (Remote Triggered Black Hole) oder BGP FlowSpec sowie klar definierte Playbooks, damit das Team im Incident nicht improvisieren muss. Dieser Beitrag zeigt, wie Sie DDoS-Schutz strukturiert planen, welche Mechanismen wofür geeignet sind und wie Sie Sicherheit und Verfügbarkeit gleichzeitig erreichen, ohne dass Betrieb und Governance aus dem Ruder laufen.

DDoS-Grundlagen: Angriffsarten und typische Ziele

Für ein belastbares Design müssen Sie verstehen, welche Angriffsklassen sich technisch unterscheiden und welche Komponenten jeweils zum Engpass werden. In der Praxis lassen sich DDoS-Angriffe grob in drei Kategorien einteilen:

• Volumetrische Angriffe: Ziel ist, Leitungen oder Router-Queues zu füllen (z. B. UDP-Floods, Amplification-Angriffe). Der Engpass ist oft Bandbreite oder Upstream-Kapazität.
• Protokoll-/State-Angriffe: Ziel ist, Zustandsressourcen zu erschöpfen (z. B. SYN-Floods, Connection Tables auf Firewalls/Load Balancern). Der Engpass ist häufig State, CPU oder spezielle Offload-Kapazität.
• Application-Layer-Angriffe: Ziel ist, Anwendungsschichten zu überlasten (z. B. HTTP-Floods, Login-Stürme). Der Engpass liegt oft in Reverse Proxies, App-Threads, DBs oder externen Abhängigkeiten.

Viele Vorfälle sind Mischformen: Ein volumetrischer Angriff dient als „Nebelwand“, während parallel ein Application-Layer-Angriff auf kritische Endpunkte trifft. Ein DDoS-Blueprint muss daher mehrere Ebenen abdecken: Netz, Transport, Applikation und Betrieb.

Designziele: Was ein gutes DDoS-Konzept leisten muss

DDoS-Schutz ist nicht nur „Traffic filtern“, sondern ein Serviceversprechen. Ein praxistaugliches Zielbild umfasst:

• Verfügbarkeit sichern: Kritische Services bleiben erreichbar oder degradieren kontrolliert.
• Time-to-Mitigation minimieren: Von Detektion bis wirksamer Abwehr sollen Minuten, nicht Stunden vergehen.
• Blast Radius reduzieren: Angriffe auf einen Dienst dürfen nicht die gesamte Plattform lahmlegen.
• Fehlersichere Prozesse: Playbooks, Rollen und Freigaben sind klar; Mitigations sind reversibel.
• Messbarkeit: Metriken für Traffic, Drops, Latenz, Fehlerraten, Kundenimpact und Mitigation-Erfolg.

Damit diese Ziele erreichbar sind, brauchen Sie sowohl technische Mechanismen (Scrubbing, RTBH, FlowSpec) als auch organisatorische Bausteine (Runbooks, Incident-Kommunikation, Postmortems).

Detektion: Ohne schnelle, verlässliche Signale keine wirksame Mitigation

Ein wiederkehrendes Problem ist, dass DDoS zwar „spürbar“ ist, aber nicht schnell genug technisch bestätigt wird. Für ein robustes DDoS-Design sollten Sie Detektion auf mehreren Ebenen aufbauen:

• Traffic-Telemetrie: Interface-Utilization, PPS (Packets per Second), Drops, Queue-Depth, CPU.
• Flow-Daten: NetFlow/IPFIX für Top-Talker, Zielpräfixe, Ports, Protokolle und zeitliche Muster. Für IPFIX als Standard ist RFC 7011 (IPFIX) eine hilfreiche Referenz.
• Service-Symptome: p95/p99-Latenz, 4xx/5xx-Raten, Timeouts, TLS-Handshake-Fehler.
• Edge-Signale: WAF/Reverse Proxy-Metriken, Rate-Limit-Hits, Bot- und Anomalie-Detektion.

Wichtig ist Korrelation: Ein volumetrischer Angriff zeigt sich in PPS/Bandbreite, ein State-Angriff in SYN/Sessions, ein L7-Angriff in Request-Raten und Backend-Fehlern. Gute Detektion erkennt die Angriffsklasse schnell genug, um die passende Mitigation zu wählen.

Scrubbing: Der Standard für volumetrische Angriffe

Scrubbing bezeichnet die Umleitung des Traffics zu einem Scrubbing-Center, das bösartigen Verkehr filtert und nur „bereinigten“ Traffic zum Origin weiterleitet. Das kann über Provider-Dienste oder spezialisierte DDoS-Anbieter erfolgen. Zwei Grundmuster sind verbreitet:

• Always-on: Traffic läuft dauerhaft über das Scrubbing-Netz (häufig via Anycast/Edge). Vorteil: schnelle Mitigation, weniger Umstellungsrisiko. Nachteil: Kosten und potenziell zusätzliche Latenz.
• On-demand: Umleitung nur im Angriff (BGP-Announcement/Traffic Diversion). Vorteil: günstiger im Normalbetrieb. Nachteil: Umschaltzeit, komplexere Playbooks.

Scrubbing ist besonders geeignet, wenn Ihr eigener Upstream nicht genug Kapazität hat, um den Angriff „auszusitzen“. Entscheidend ist jedoch die saubere Integration: Umleitung darf nicht zu Routing-Loops, asymmetrischen Pfaden oder MTU-Problemen führen. Für Anycast als Edge-Prinzip bietet das Anycast-Lexikon von Cloudflare einen gut verständlichen Einstieg.

Scrubbing-Designentscheidungen, die in der Praxis zählen

• Diversion-Methode: BGP-basiert (Präfix-Announcements) oder DNS/Anycast-basiert (für bestimmte Dienste).
• Routen- und Prefix-Strategie: Welche Präfixe werden im Angriff umgeleitet (nur VIPs/Services vs. gesamter Block)?
• Return Path: Sicherstellen, dass Rückverkehr korrekt läuft (Asymmetrie vermeiden).
• Kapazitätsmodell: Scrubbing-Kapazität und Provider-SLAs müssen zum eigenen Risiko passen.
• Observability: Sichtbarkeit über gefilterten vs. durchgelassenen Traffic, inklusive False-Positive-Handling.

RTBH: Wenn Verfügbarkeit bedeutet, gezielt zu „schneiden“

RTBH (Remote Triggered Black Hole) ist eine BGP-basierte Methode, um Traffic zu bestimmten Zielen zu verwerfen, bevor er die eigene Infrastruktur überlastet. Das klingt drastisch, ist aber ein bewährtes Notfallwerkzeug: Wenn ein Angriff so groß ist, dass er Leitungen oder Edge-Komponenten saturiert, kann RTBH verhindern, dass der gesamte Standort oder die gesamte Plattform ausfällt.

Was RTBH leistet und was nicht

• Stärke: Extrem schnell, simpel, wirksam gegen volumetrische Fluten auf ein Ziel.
• Schwäche: Das Ziel ist für legitime Nutzer ebenfalls nicht erreichbar (Blackhole).
• Typischer Einsatz: Schutz des restlichen Netzwerks, wenn nur ein Dienst angegriffen ist und Scrubbing nicht rechtzeitig greift.

RTBH sollte in Playbooks klar als „Last Resort“ definiert sein: Wann darf es ausgelöst werden, welche Ziele sind zulässig, wer gibt frei, und wie wird zurückgerollt? Besonders wichtig: Präzision in Prefix-Längen. Ein zu grobes Blackhole kann mehr Services treffen als nötig.

BGP FlowSpec: Granulare Filterregeln über BGP verteilen

BGP FlowSpec ermöglicht es, Filterregeln für Traffic-„Flows“ (z. B. Zielpräfix + Port + Protokoll) über BGP zu verteilen, sodass Router oder DDoS-Systeme gezielt droppen, rate-limiten oder umleiten können. Dadurch ist FlowSpec deutlich feiner als RTBH, weil nicht gleich ein ganzes Ziel „verschwindet“, sondern bestimmte Angriffsmerkmale gefiltert werden.

FlowSpec ist besonders attraktiv für wiederkehrende Muster wie UDP-Floods auf bestimmte Ports oder Reflexionsangriffe, die sich gut über Merkmale beschreiben lassen. Eine technische Grundlage bietet RFC 8955 (Flow Specification v2).

Designregeln für FlowSpec, um Risiken zu minimieren

• Policy-Governance: Wer darf FlowSpec-Regeln announcen? Mit welcher Authentisierung?
• Scope begrenzen: Nur bestimmte Prefixe/Peerings/Router akzeptieren FlowSpec, um Missbrauch zu verhindern.
• Default Deny: FlowSpec-Input streng filtern, Max-Regelanzahl und Rate Limits setzen.
• Lebensdauer: Regeln befristen (Timeouts), damit Notfallfilter nicht „für immer“ bleiben.
• Observability: Logging, welche Flows gefiltert wurden, um False Positives zu erkennen.

FlowSpec kann sehr wirksam sein, birgt aber operationales Risiko: Eine falsche Regel kann legitimen Traffic blocken. Deshalb ist ein kontrolliertes Operating Model zwingend.

Abwehrarchitektur als Stufenmodell: Defense-in-Depth gegen DDoS

Ein robustes DDoS-Design kombiniert mehrere Ebenen, die jeweils unterschiedliche Angriffsklassen abfangen. Ein bewährtes Stufenmodell sieht so aus:

• Edge/Anycast/WAF: L7-Schutz, Bot- und Anomalieerkennung, Rate Limiting, TLS-Offload.
• Scrubbing: Volumetrische Filterung und Protokoll-Filter auf hoher Kapazität.
• Provider/Backbone Controls: Upstream-Filter, ggf. FlowSpec/Blackholing nahe am Ursprung des Traffics.
• On-Prem/Cloud Edge: Stateful Schutz (SYN-Cookies, Conntrack-Tuning), Limitierung und Schutz von Control Planes.
• Backend Resilience: Skalierung, Caching, Circuit Breaker, Schutz besonders teurer Endpunkte.

Je nach Unternehmensprofil ist die Schwerpunktsetzung anders: Ein SaaS-Anbieter braucht oft stärkere L7-Mechanismen und Edge-Scaling, während ein ISP stärker auf volumetrische Abwehr und Routing-Mechanismen setzt.

Cost Models: DDoS-Schutz zwischen Risiko und Budget balancieren

DDoS-Abwehr hat Kosten – nicht nur für Services, sondern auch für Betriebsaufwand und Komplexität. Ein praxistaugliches Kostenmodell betrachtet:

• Fixkosten: Always-on Edge/Scrubbing, zusätzliche Uplinks, Hardware/Appliances.
• Variable Kosten: On-demand Scrubbing, Pay-per-GB, Incident-Services, Cloud-Egress beim Umleiten.
• Risikokosten: Ausfallzeit, SLA-Strafen, Reputationsschaden, Produktivitätsverlust, Incident-Aufwand.

Entscheidend ist, DDoS-Schutz in Serviceklassen zu denken: Nicht jeder Dienst benötigt die gleiche Abwehrstufe. Kritische Auth- und Payment-Services brauchen oft Always-on Schutz, während weniger kritische Seiten ggf. mit On-demand und RTBH-Optionen auskommen.

Playbooks: Der Unterschied zwischen „wir haben Schutz“ und „wir sind handlungsfähig“

Technik allein reicht nicht. DDoS ist ein Zeitproblem: In den ersten Minuten entscheidet sich, ob der Angriff kontrolliert wird oder eskaliert. Playbooks beschreiben, wer was wann tut – inklusive technischer Maßnahmen, Kommunikation und Dokumentation.

Playbook-Struktur für DDoS-Incidents

• Trigger: Welche Signale lösen das Playbook aus (PPS, Bandbreite, 5xx-Rate, WAF-Anomalien)?
• Classification: Volumetrisch, State, L7 oder Mischform? Welche Ziele sind betroffen?
• Mitigation Ladder: Reihenfolge der Maßnahmen (WAF Rules → Rate Limits → Scrubbing → FlowSpec → RTBH).
• Kommunikation: Incident Channel, interne Stakeholder, Provider/DDoS-Anbieter, ggf. Kundenstatusseite.
• Rollback: Wie und wann werden Maßnahmen zurückgenommen, wie wird Stabilität verifiziert?
• Postmortem: Was war Root Cause, was fehlte, welche Guardrails/AutomatisICHS sind nötig?

Ein wichtiger Punkt ist die klare Rollenverteilung: Wer hat die technische „Tastatur“ für BGP/FlowSpec? Wer entscheidet über RTBH? Wer kommuniziert mit dem Provider? Ohne Rollen entsteht gefährliche Parallelaktion.

RTBH- und FlowSpec-Playbooks: Safe-Guards gegen Fehlbedienung

Besonders Routing-basierte Mitigation ist mächtig und riskant. Daher sollten Playbooks technische Sicherungen enthalten:

• Vorab genehmigte Prefix-Listen: Nur definierte Ziele dürfen geblackholed oder per FlowSpec gefiltert werden.
• Change-IDs und Vier-Augen-Prinzip: Mindestens für kritische Aktionen (RTBH ganzer /24 etc.).
• Time-to-Live: Automatisches Auslaufen von Regeln nach X Minuten, wenn nicht aktiv verlängert.
• Simulation/Tests: Regelmäßige Game Days, um Prozess und Technik zu üben.
• Monitoring: Sofortige Sichtbarkeit, ob Mitigation wirkt (Drops, PPS sinkt, SLOs erholen sich).

False Positives und Kollateralschäden: Wenn Schutz legitimen Traffic trifft

DDoS-Mitigation kann legitimen Traffic beeinträchtigen, besonders bei aggressiven Rate Limits oder ungenauen Signaturen. Ein gutes Design reduziert dieses Risiko:

• Graduelle Maßnahmen: Erst milde Limits, dann verschärfen, statt sofort „hart“ zu blocken.
• Allowlisting kritischer Clients: z. B. Partnernetze, Admin-IPs, Healthchecks – aber streng kontrolliert.
• Segmentierung: Schutzmaßnahmen nur auf betroffene VIPs/Services anwenden, nicht global.
• Observability: Separat messen, wie viele legitime Requests abgewiesen werden (4xx/429, Fehlerquoten, Abbruchraten).

Gerade bei L7-Angriffen ist die Zusammenarbeit mit Applikationsteams wichtig: Manche Endpunkte sind teuer (Suche, Login), andere sind gut cachebar. Ein gemeinsames „Critical Endpoint“-Register hilft, Schutz gezielt zu priorisieren.

Integration mit Monitoring und SLOs: DDoS als messbarer Betriebszustand

DDoS-Design wird deutlich stabiler, wenn es mit Monitoring-Architektur verknüpft ist. Praktisch bedeutet das:

• SLIs: p95-Latenz, Fehlerquoten, Erfolgsrate von Logins, DNS-Resolution-Time, TLS-Handshakes.
• Guardrails: PPS/Bandbreiten-Schwellen, Drops/Queueing, Session-Counts auf Firewalls.
• Burn-Rate-Alerts: Wenn SLOs „zu schnell“ reißen, wird früh eskaliert.

Für das Denken in SLOs und Error Budgets kann das Google SRE Book als Orientierung dienen, auch wenn DDoS-Schutz eine spezielle Domäne ist. Es hilft, Alarmierung und Incident-Prozesse auf Nutzerimpact zu fokussieren.

Häufige Anti-Patterns im DDoS-Design und wie Sie sie vermeiden

• Nur „mehr Bandbreite“: Volumen ist nur ein Teil; State- und L7-Angriffe bleiben wirksam. Lösung: mehrstufiges Modell (Edge/WAF, Scrubbing, Routing-Mechanismen, Backend-Resilience).
• On-demand ohne Übungen: Umschaltungen klappen im Ernstfall nicht. Lösung: regelmäßige Tests, dokumentierte Playbooks, Game Days.
• RTBH ohne Governance: Ein falsches Prefix schaltet zu viel ab. Lösung: Prefix-Listen, Vier-Augen-Prinzip, TTL.
• FlowSpec ohne Schutz: Missbrauch oder Fehlregeln blocken legitimen Traffic. Lösung: strikte Filter, Limits, Authentisierung, Observability.
• Kein Egress-Fokus: C2 und Exfiltration werden übersehen. Lösung: Egress-Telemetrie, DNS/HTTP-Kontrollen, NDR/Flow-Korrelation.
• Keine klare Zuständigkeit: Während des Angriffs handeln zu viele oder niemand. Lösung: Rollenmodell, Incident-Kommunikation, Escalation-Paths.

Praxis-Checkliste: DDoS-Design mit Scrubbing, RTBH, FlowSpec und Playbooks

• Definieren Sie Serviceklassen und Schutzbedarf: Welche Dienste brauchen Always-on Schutz, welche On-demand, welche dürfen im Notfall per RTBH geopfert werden?
• Implementieren Sie Detektion mehrschichtig: Interface/PPS, Drops/Queueing, Flow-Daten (IPFIX), Service-Metriken und WAF-Signale.
• Planen Sie Scrubbing als Primärmaßnahme gegen Volumen: Diversion-Methode, Prefix-Strategie, Return Path, Observability und SLA.
• Definieren Sie RTBH als Notfallwerkzeug: erlaubte Prefixe, Freigaben, TTL/Timeouts, klare Rollback-Schritte.
• Nutzen Sie BGP FlowSpec für granulare Filter: Governance, Input-Filter, Max-Regeln, Befristung und Logging.
• Stellen Sie Defense-in-Depth sicher: Edge/WAF/Rate Limits, Scrubbing, Upstream-Kooperation, Backend-Resilience und Capacity Guardrails.
• Erstellen Sie Playbooks: Trigger, Klassifizierung, Mitigation Ladder, Kommunikation, Provider-Kontaktwege, Rollback und Postmortem.
• Üben Sie regelmäßig: Game Days für Scrubbing-Umschaltung, FlowSpec-Deploy, RTBH-Drills (in kontrollierter Umgebung).
• Verknüpfen Sie Schutz mit SLOs: Impact-orientierte Alarme, klare Erfolgskriterien („Service wieder stabil“), saubere Incident-Dokumentation.

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.