DDoS Topologie entscheidet in Telco- und Provider-Netzen darüber, ob ein Angriff zu einer kontrollierten Mitigation wird – oder zu einem großflächigen Incident mit Kollateralschäden. Denn DDoS ist nicht nur „viel Traffic“, sondern vor allem ein Problem der Pfade: Wo kommt der Traffic ins Netz? Welche Interconnects (IXP/PNI/Transit) sind betroffen? Wie schnell können Sie schädlichen Traffic von legitimen Strömen trennen, ohne dass Backbone, DCI oder Service-Edges kollabieren? Moderne DDoS-Abwehr basiert deshalb auf drei topologischen Grundbausteinen: Scrubbing Centers als leistungsfähige Reinigungspunkte, Anycast als Verteilmechanismus für globale Services und Ingress-Last, sowie Traffic Steering als kontrollierte Umleitung (z. B. via BGP Communities, RTBH, FlowSpec oder SR-TE). Der Kern ist ein abgestuftes Modell: leichte Angriffe werden möglichst edge-nah gefiltert, große volumetrische Angriffe werden früh abgefangen (Upstream/Edge), und komplexe Angriffe werden gezielt zu Scrubbing-Kapazität umgeleitet. Gleichzeitig muss die Architektur „betrieblich“ sein: Mitigation darf die Control Plane nicht überlasten, muss auditierbar sein, braucht klare Failure Domains und muss im N-1/N-2 Betrieb funktionieren. Dieser Artikel zeigt, wie Sie DDoS-Topologien in Telco-Netzen planen: von Scrubbing-Center-Platzierung über Anycast-Design und Steering-Mechanismen bis zu Capacity, Observability und Runbooks, damit Resilienz messbar wird.
Warum DDoS ein Topologieproblem ist und nicht nur ein Security-Problem
Ein DDoS-Angriff wirkt dort, wo er auf Kapazität und Steuerlogik trifft: an Ingress-Punkten, Engpässen und in Service Chains. Selbst wenn ein Zielservice robust ist, kann ein Angriff das Netz lahmlegen, wenn er Interconnect-Ports saturiert oder die Control Plane durch Abwehrmaßnahmen instabil macht. Die zentrale Frage lautet: Wie früh und wo genau trennen Sie „bad traffic“ von „good traffic“?
- Ingress entscheidet: Je früher Sie filtern, desto weniger Traffic belastet Backbone und Services.
- Engpässe bestimmen Kollateralschäden: IXP/Transit/DCI können zum Bottleneck werden, bevor Scrubbing greift.
- Steering verändert Pfade: Umleitungen können Hairpinning erzeugen und Latenzbudgets sprengen.
- Control-Plane Risiko: Zu viele Filterupdates oder falsche Policies können BGP/CPU destabilisieren.
Leitprinzip: DDoS-Abwehr ist Pfad-Engineering mit Guardrails
Ein gutes Design macht DDoS-Mitigation zu einer kontrollierten Pfadentscheidung: klarer Scope, klarer Trigger, klarer Rückweg – statt hektischer Ad-hoc-Änderungen.
DDoS-Grundtypen und ihre topologischen Implikationen
Für das Topologiedesign ist wichtig, welcher Angriffstyp dominiert. Volumetrische Angriffe zielen auf Bandbreite, Protokollangriffe auf Zustandsmaschinen und CPU, und Applikationsangriffe auf Servicekapazität. Jede Klasse verlangt andere Mitigation-Punkte.
- Volumetrisch (bps): UDP Floods, Reflection/Amplification; erfordern frühes Filtering und/oder Upstream-Scrubbing.
- Protokoll-/State-Angriffe (pps/cps): SYN Flood, fragment floods; erfordern Edge-Filtering, CoPP und state-aware Mitigation.
- Applikationsangriffe (L7): HTTP/HTTPS Flood; erfordern WAF/CDN/Rate-Limits nah am Service.
- Multi-Vektor: Kombinationen, die parallel Bandbreite und State angreifen; brauchen abgestufte Pipeline.
Designregel: Bps- und Pps-Kapazität getrennt planen
Ein Router kann bps-seitig ausreichend sein und trotzdem pps-seitig kollabieren. DDoS-Topologie muss deshalb Throughput, PPS, CPS und Control-Plane-Budgets berücksichtigen.
Scrubbing Centers: Rolle, Platzierung und Architekturvarianten
Scrubbing Centers sind spezialisierte Reinigungsstandorte, die Angriffstraffic aufnehmen, filtern und „sauberen“ Traffic zurück ins Netz liefern. Topologisch sind sie die „Abzweigung“ in einer DDoS-Servicekette: Traffic wird dorthin umgeleitet (redirect) oder landet durch Anycast/Steering automatisch dort. Die Platzierung bestimmt Latenz, Backhaul-Bedarf und Failoverfähigkeit.
- Zentrale Scrubbing Centers: Wenige große Standorte; effizient, aber mehr Hairpinning und höhere Latenz im Failover.
- Regionale Scrubbing PoPs: Mehr Standorte in Metro/Region; bessere Latenz, geringerer Backhaul, mehr OPEX/Komplexität.
- Hybrid: Regionale erste Stufe (volumetrisch/pps), zentrale zweite Stufe (komplexe L7/forensics).
- On-Net vs. Off-Net: Eigene Scrubbing-Infrastruktur vs. Cloud/Partner-Scrubbing; beeinflusst Steuerung und Vertrauensmodell.
Platzierungslogik: Nähe zu Ingress und Nähe zu Kunden
Scrubbing sollte nahe genug am Ingress sein, um Backbone zu schützen, und nahe genug an Kunden, um Latenzbudgets einzuhalten. In der Praxis bedeutet das oft: regional in großen Traffic-Zentren, ergänzt durch zentrale Kapazität.
Scrubbing-Datenpfade: Inbound, Outbound und Rückführung des sauberen Traffics
Ein Scrubbing-Center ist nur dann effektiv, wenn der Hin- und Rückweg sauber designt ist. Häufige Fehler sind asymmetrische Pfade (stateful Probleme), unklare Rückführung (traffic reinigt, kommt aber über falsche Region zurück), oder DCI/Backhaul-Engpässe, die durch den Scrubbing-Umweg erst entstehen.
- Inbound zur Scrubbing-Kante: Steering sorgt dafür, dass Angriffstraffic am richtigen Ingress in die Scrubbing-Kette geht.
- Scrubbing-to-Service Rückweg: Sauberer Traffic muss zum Zielservice gelangen, ohne neue Engpässe zu erzeugen.
- Symmetrie für stateful Dienste: Wenn Firewalls/CGNAT beteiligt sind, muss Hin- und Rückweg konsistent sein.
- MTU/QoS Konsistenz: Overhead (GRE, MPLS, VXLAN) kann MTU-Probleme verursachen; QoS muss kritische Klassen schützen.
Anti-Pattern: Scrubbing erzeugt Hairpinning über DCI
Wenn eine Region im Angriff plötzlich Traffic über eine entfernte Scrubbing-Site backhaulen muss, werden DCI und Core zur neuen Angriffsfläche. Regionale Scrubbing-Knoten oder regionales Steering reduzieren dieses Risiko.
Anycast im DDoS-Design: Lastverteilung, Resilienz und Risiken
Anycast ist ein mächtiges Topologiepattern: dieselbe IP/Prefix wird an mehreren Orten annonciert, und Routing liefert den „nächsten“ Standort. Für DDoS ist das attraktiv, weil Angriffs- und Nutztraffic verteilt wird. Gleichzeitig bringt Anycast Risiken: Pfade können bei Routingänderungen springen (jitter/latency), und im Angriffsfall kann Anycast Traffic in unerwünschte Regionen ziehen, wenn Policies nicht sauber sind.
- Anycast für DNS und Edge Services: Sehr verbreitet, weil Dienste stateless sind oder State gut verteilt werden kann.
- Anycast für Scrubbing Ingress: Traffic landet automatisch im nächstgelegenen Scrubbing PoP, wenn korrekt annoncierte Prefixe genutzt werden.
- Health-Gating: Anycast muss an echte Servicegesundheit gekoppelt sein (withdraw bei Überlast), sonst wird ein PoP zum Sinkhole.
- Policy-Steuerung: Inbound/Outbound Policies bestimmen, wo Anycast tatsächlich landet; Drift erzeugt Überraschungen.
Designregel: Anycast braucht Guardrails gegen „falsches Nah“
„Nächstgelegen“ ist ein Ergebnis von Routing, nicht von Geografie. Ohne definierte Policies und Health-Gates kann Anycast Traffic in suboptimale oder überlastete PoPs ziehen.
Traffic Steering: Wie DDoS-Mitigation topologisch aktiviert wird
Traffic Steering ist die kontrollierte Umleitung von Traffic in die Mitigation-Kette. In Telco-Netzen wird Steering typischerweise über BGP-Mechanismen umgesetzt, ergänzt durch SR-TE oder statische Redirect-Mechanismen. Ein gutes Steering-Design ist abgestuft: grob (RTBH) für schnelle Notbremsung, granular (FlowSpec) für selektives Filtern, und Redirect (Scrubbing) für nachhaltige Reinigung.
- RTBH: Extrem schnell, sehr grob; geeignet, um Ziele sofort zu schützen, aber mit Kollateralschaden (Ziel offline).
- FlowSpec: Granularer Filter/Rate-Limit; reduziert Kollateralschäden, braucht Governance und Limits.
- BGP Redirect to Scrubbing: Zielprefix wird so annonciert, dass Traffic im Scrubbing landet; Rückführung liefert „clean“ Traffic.
- SR-TE/Policy Steering: Im Backbone Pfade gezielt steuern, um DCI/Engpässe zu entlasten.
Designregel: Steering muss reversibel und auditierbar sein
Mitigation-Änderungen dürfen nicht „kleben bleiben“. Jede Maßnahme braucht Owner, Startzeit, Expiry/TTL und klare Rückbaukriterien.
Topologische Containment: Failure Domains für Mitigation definieren
DDoS-Topologien müssen verhindern, dass Mitigation selbst zum Incident wird. FlowSpec-Regeln dürfen nicht global eskalieren, RTBH darf nicht versehentlich ganze Bereiche blackholen, und Redirect darf nicht in falsche Regionen ziehen. Containment erreicht man über Domain-Grenzen (regionale Policies), separate RR-Distribution für FlowSpec, und klare Exportfilter.
- Regionale Mitigation: Mitigation wirkt zunächst nur in betroffenen Regionen/Ingress-PoPs.
- Separate Distribution: FlowSpec über dedizierte Control-Plane/Cluster, mit Max-Rule Limits.
- Export-Filter: Keine Mitigation-Communities/FlowSpec nach außen zu Peers/Kunden propagieren.
- Maintenance Domains: Scrubbing-Knoten und Edge-Cluster als Domains mit getesteten Failoverpfaden.
Anti-Pattern: Globaler „Big Red Button“ ohne Scope
Ein globaler Mitigation-Schalter ohne regionale Begrenzung kann unnötig große Kollateralschäden erzeugen. Besser ist progressives, topologisch begrenztes Eskalieren.
Kapazitätsplanung für DDoS: Headroom, PPS und Backhaul
Die DDoS-Topologie ist nur so gut wie ihre Kapazität. Dazu gehören nicht nur Scrubbing-Tbps, sondern auch Interconnect- und Transit-Headroom, DCI/Backhaul, PPS-Fähigkeit von Routern und Appliances, sowie Logging/Telemetry-Pipelines. Ein klassischer Fehler ist, Scrubbing groß zu dimensionieren, aber die Pfade dorthin nicht.
- Ingress-Headroom: Transit/Peering Kapazität, um Angriffstraffic nicht vor Scrubbing zu verlieren.
- Scrubbing-Headroom: bps und pps Kapazität, plus Reserven für Multi-Vektor-Angriffe.
- DCI/Backhaul: Kapazität für Redirect und Clean-Traffic-Rückführung; N-1/N-2 je nach SLO.
- Control-Plane Budgets: CoPP und Update-Limits, damit Mitigation-Regeln nicht die CPU destabilisieren.
Designregel: Kapazität im Failover messen, nicht nur im Normalbetrieb
Ein Angriff ist bereits ein Peak. Wenn parallel ein Link oder eine Region degradiert ist, muss die Mitigation trotzdem funktionieren. Das ist N-1 unter Stress.
Observability-by-Design: DDoS sichtbar machen und Mitigation bewerten
Ohne Sichtbarkeit wird DDoS-Abwehr zu Blindflug. Sie brauchen Telemetry, die sowohl Traffic (Flows/IPFIX) als auch Engpässe (Queue-Drops, Portauslastung) und Control-Plane-Health (BGP/CPU/CoPP Drops) abbildet. Zusätzlich benötigen Sie Mitigation-Status: welche RTBH/FlowSpec/Redirect-Regeln aktiv sind, wie lange, und mit welchem Effekt.
- Traffic Visibility: NetFlow/IPFIX nach ASN, Ziel, Protokoll, PPS/bps; hilft bei Angriffsklassifikation.
- Engpasssignale: Queue-Drops an Interconnect/DCI, p95/p99 Latenz und Loss zu Referenzzielen.
- Control-Plane Health: CoPP Counter, CPU, BGP Session Stability, Update-Raten.
- Mitigation Inventory: Aktive Regeln mit Owner, Scope, Startzeit, Expiry, und gemessener Wirkung.
High-Signal Alerts statt Alarmsturm
Alarmieren Sie nicht auf „Traffic hoch“, sondern auf „SLO-Impact + Engpasssignale + Mitigation nicht ausreichend“. Das reduziert Noise und beschleunigt Entscheidungen.
Runbooks und Betriebsmodell: Von „Stop the bleeding“ zu nachhaltiger Abwehr
Eine gute DDoS-Topologie braucht klare Betriebsstufen. In der ersten Minute zählt Geschwindigkeit (RTBH/initial steering), danach zählt Präzision (FlowSpec/Redirect/Scrubbing), und danach zählt Stabilität (Rückbau, forensics, Guardrail-Tuning). Runbooks sollten topologisch strukturiert sein: Ingress-PoPs, betroffene Regionen, betroffene Services.
- Stufe 1: Erkennen, klassifizieren, initiale Mitigation (RTBH oder schnelle Rate-Limits), SLO schützen.
- Stufe 2: Redirect zu Scrubbing, FlowSpec-Regeln verfeinern, Kollateralschäden minimieren.
- Stufe 3: Stabilisieren, Kapazität entlasten, Observability prüfen, Root Cause und Lessons Learned.
- Rückbau: Regeln laufen aus oder werden kontrolliert entfernt, mit Hysterese gegen Ping-Pong.
Designregel: Mitigation muss „expiry by default“ haben
Temporäre Regeln sollten automatisch auslaufen, wenn sie nicht aktiv verlängert werden. Das reduziert dauerhafte Kollateralschäden und vereinfacht Hygiene.
Typische Fallstricke und wie man sie vermeidet
- Scrubbing zu zentral, DCI kollabiert: Lösung: regionale Scrubbing-PoPs oder regionales Steering, DCI-Headroom und QoS.
- Anycast ohne Health-Gates: Lösung: withdraw bei Überlast, echte Health Checks, Policy-Konsistenz.
- FlowSpec global ohne Limits: Lösung: Scope/Regionalisierung, Rule Limits, separate Distribution, strikte Autorisierung.
- RTBH ohne Containment: Lösung: autorisierte Quellen, Zielbereiche begrenzen, Logging und automatische Expiry.
- Keine PPS-Planung: Lösung: pps/cps KPIs, CoPP, Rate-Limits, Plattformkapazität (nicht nur bps).
- Mitigation erzeugt Asymmetrie: Lösung: Service-Chain-Symmetrie, klare Rückführung, stateful Awareness.
- Keine Tests: Lösung: Failure Workshops und kontrollierte Chaos-Experimente in Canary-Domänen, Expected vs. Observed.
Praktische Leitlinien: DDoS Topologie mit Scrubbing, Anycast und Steering
- Ingress- und Failure Domains kartieren: Interconnect-Standorte, DCI, Hubs, SRLGs – als Grundlage für Mitigation-Containment.
- Scrubbing strategisch platzieren: Kombination aus regionalen und zentralen Scrubbing Centers, abhängig von Latenzbudgets und Traffic-Zentren.
- Anycast gezielt nutzen: Für DNS und geeignete stateless Services, mit Health-Gates und Policy-Konsistenz.
- Steering abstufen: RTBH für Sofortstopp, FlowSpec für selektive Filter, Redirect für Scrubbing – mit klaren Triggern.
- Containment erzwingen: Regionale Policies, dedizierte Distribution, Export-Filter, damit Mitigation nicht global eskaliert.
- Kapazität realistisch planen: bps/pps, DCI/Backhaul, Interconnect-Headroom, N-1/N-2 unter Stress.
- Observability-by-Design: Flows/IPFIX, Queue-Drops, Path-KPIs, CoPP Counter und Mitigation-Inventory als Standard.
- Runbooks operationalisieren: Rollen, Zuständigkeiten, Stop/Go Gates, Expiry by default, kontrollierter Rückbau.
- Regelmäßig testen: Canary-Mitigation, progressive Übungen, post-incident Reviews und kontinuierliches Tuning der Topologie.
