Site icon bintorosoft.com

DDoS Topologie: Scrubbing Centers, Anycast und Traffic Steering

Red Snapper

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“?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Praktische Leitlinien: DDoS Topologie mit Scrubbing, Anycast und Steering

Exit mobile version