Anycast Scrubbing gilt als eine der elegantesten Methoden, DDoS-Traffic zu absorbieren, weil es „von selbst“ skaliert: Derselbe Service-Prefix wird von vielen Scrubbing-PoPs via BGP annonciert, und der Internet-Traffic landet automatisch am topologisch „nächsten“ Standort. Im Idealfall entsteht dadurch keine harte Umschaltkante wie beim klassischen On-Demand-Diversion – und volumetrische Angriffe verteilen sich auf viele Standorte, statt einen einzelnen Edge zu sättigen. In der Praxis ist Anycast Scrubbing jedoch kein Selbstläufer. Die größte operative Herausforderung ist nicht die reine Kapazität, sondern das Zusammenspiel aus Policy Routing (BGP-Policies, Communities, Traffic-Engineering) und dem Risiko von Collateral Damage: Legitimer Traffic wird mitgefiltert, falsch umgeleitet oder durch unkontrollierte Pfadwechsel (Traffic Drift) in Regionen geführt, die dafür nicht ausgelegt sind. Genau hier entscheidet sich, ob Anycast Scrubbing SLA-schonend wirkt oder ob die Mitigation selbst zum Incident wird. Dieser Artikel erklärt praxisnah, wie Anycast Scrubbing funktioniert, welche Policy-Routing-Mechanismen typischerweise eingesetzt werden, wo das Collateral-Damage-Risiko entsteht und wie Operations-Teams es mit Telemetrie, Guardrails und Runbooks messbar reduzieren können.
Anycast Scrubbing in einem Satz: Was wird „anycasted“?
Beim Anycast Scrubbing wird ein Schutzprefix (meist das Zielprefix des Kunden oder ein vorgelagertes Schutzprefix) an mehreren geografischen Standorten parallel annonciert. Angriffs- und Legittraffic werden dadurch in das Scrubbing-Netz eingespeist. Der Traffic wird dort gefiltert, und nur der „clean traffic“ wird entweder lokal terminiert (Always-on-Protection) oder über einen definierten Rückweg zum Origin geführt (z. B. per GRE/IPsec-Tunnel, Private Interconnect oder internes Backbone). BGP als Routinggrundlage ist in RFC 4271 beschrieben. Der wesentliche Anycast-Effekt entsteht, weil Upstreams und Peers den „besten“ Pfad nach ihren Policies wählen – häufig nahe am Quellnetz.
Warum Policy Routing bei Anycast Scrubbing so entscheidend ist
In Anycast-Architekturen ist das Routing gleichzeitig die Mitigation. Sie steuern nicht nur „wohin Traffic geht“, sondern indirekt auch die Angriffslastverteilung, die Latenzprofile, die Wahrscheinlichkeit von Fragmentation/MTU-Problemen und die Fehlertoleranz bei PoP-Ausfällen. Policy Routing umfasst dabei typischerweise:
- BGP Path Selection beeinflussen: Local Preference, AS-PATH Prepending, MED, Communities und Peer-spezifische Policies.
- Announcement-Scope steuern: nur bestimmte Upstreams/Peers oder Regionen announcen (z. B. über Communities).
- Traffic Engineering fürs Scrubbing: Lastverteilung zwischen PoPs, Abgrenzen von Fault Domains, Schutz vor Überlast einzelner Standorte.
Die Kehrseite: Jede Policy-Änderung kann globale Auswirkungen haben. Ein kleiner Community-Fehler kann Traffic plötzlich weltweit auf einen PoP ziehen oder legitimen Traffic in eine Region verschieben, die keinen ausreichenden Rückweg hat. Collateral Damage ist daher nicht nur ein Filter-Problem, sondern oft ein Routing-Problem.
Architekturvarianten: Anycast Scrubbing ist nicht gleich Anycast Scrubbing
Für den Betrieb ist wichtig zu unterscheiden, in welchem Modell Sie Anycast einsetzen. Die Risiken und Mitigation-Optionen unterscheiden sich deutlich.
Always-on Anycast Scrubbing
Der Service ist dauerhaft anycasted und wird an jedem PoP „geschützt“ ausgeliefert. Typische Beispiele sind Anycast DNS oder öffentliche API-Frontdoors. Vorteil: Kein Umschalten im Angriff. Risiko: False Positives treffen sofort den produktiven Traffic, und Policy-Fehler wirken dauerhaft.
On-demand Anycast Scrubbing
Im Normalbetrieb läuft Traffic direkt zum Origin. Im Angriff wird das Prefix (oder ein spezifischeres) zusätzlich über das Anycast-Scrubbing-Netz annonciert. Vorteil: Keine zusätzliche Latenz im Normalbetrieb. Risiko: Umschaltfehler, Route Leaks, instabile Drift beim Zurückschalten.
Hybrid: Anycast für Absorption, Unicast für Clean Return
Ein gängiger Ansatz ist: Angriffstraffic wird per Anycast in den Scrubber gezogen, aber der Clean Traffic wird über dedizierte Rückwege zum Origin geführt. Operativ ist das oft am stabilsten, weil Sie Return-Paths deterministisch machen können – allerdings steigt dann das MTU- und Tunnel-Management-Risiko.
Collateral Damage: Was genau kann schiefgehen?
Collateral Damage bezeichnet im DDoS-Kontext den ungewollten Schaden an legitimen Verbindungen durch Mitigation. Bei Anycast Scrubbing hat Collateral Damage typische Muster, die sich wiederholen.
Risiko 1: False Positives durch aggressive Signaturen
Wenn Scrubbing-Policies zu grob sind (z. B. Port-basierte Blockaden oder Paketgrößenfilter ohne Kontext), kann legitimer Traffic als Angriff klassifiziert werden. Besonders gefährdet sind Protokolle mit großen, legitimen Antworten (z. B. DNS mit DNSSEC) oder UDP-basierte moderne Protokolle (z. B. QUIC/HTTP3 über UDP/443). DNS-Grundlagen sind in RFC 1035 und DNSSEC-Erweiterungen in RFC 4035 beschrieben.
Risiko 2: Traffic Drift und regionale Service-Degradation
Anycast ist dynamisch. Wenn sich BGP-Entscheidungen ändern (Upstream-Flap, Peering-Änderung, Routing-Policy, Congestion), kann Traffic plötzlich zu einem anderen PoP wandern. Das wirkt wie „zufällige“ Latenzsprünge oder regionale Ausfälle. Besonders kritisch ist Drift, wenn:
- PoPs unterschiedliche Filterprofile haben (Policy Drift),
- PoPs unterschiedliche Kapazität oder unterschiedliche Rückwege besitzen,
- ein PoP unter Angriff „übersteuert“ und andere PoPs plötzlich den Traffic übernehmen.
Risiko 3: Unkontrollierte Lastverteilung (Hotspots im Scrubbing-Netz)
Anycast verteilt nicht automatisch „fair“. Best Path Selection kann dazu führen, dass ein großer Anteil des globalen Traffics an wenigen PoPs landet. In Angriffssituationen kann das den Scrubbing-PoP sättigen und die Mitigation destabilisieren.
Risiko 4: Return-Path-Probleme (Tunnel, MTU, Asymmetrie)
Wenn Clean Traffic über Tunnel (GRE/IPsec) oder über dedizierte Backhauls zurückgeführt wird, entstehen neue Fehlerquellen: MTU-Overhead, Fragmentation, PMTUD-Blockaden, asymmetrische Pfade und ECMP-Partial-Failures. Ein klassisches Muster ist: „Scrubbing wirkt, aber Anwendungen brechen“, weil große Pakete im Tunnelpfad droppen.
Risiko 5: Policy Routing Fehler (Communities, Scope, Route Leaks)
Die gefährlichsten Collateral-Damage-Vorfälle sind oft Routingfehler: falsche Communities, falsche Prefixlängen oder ungewollte Propagation an Peers/Upstreams. Das kann Traffic in falsche Regionen ziehen oder sogar Prefix-Hijack-ähnliche Situationen erzeugen. Daher sind Anti-Spoofing- und Routing-Sicherheitspraktiken wie BCP 38/84 wichtig (RFC 2827, RFC 3704) und organisatorische Guardrails (Change-Disziplin, Freigaben).
Policy Routing im Detail: Die wichtigsten Hebel und ihre Nebenwirkungen
Operations-Teams sollten die Policy-Hebel so verstehen, dass sie nicht nur „Traffic verschieben“, sondern den Collateral-Schaden minimieren.
Local Preference und Peer-Priorisierung
Local Preference wirkt innerhalb eines AS und entscheidet, welchen Exit/Ingress Ihr Netz bevorzugt. Für Anycast Scrubbing ist das relevant, wenn Sie bestimmte PoPs bevorzugen (z. B. PoPs mit mehr Kapazität). Der Nachteil: Sie können damit regionale Balance verschlechtern, weil Traffic „unnatürlich“ zu bevorzugten Standorten wandert.
AS-PATH Prepending
Prepending macht einen Pfad „unattraktiver“ für externe AS. Das ist ein grobes, aber häufig genutztes Werkzeug, um Traffic von einem PoP wegzuschieben. Die Nebenwirkung ist, dass es nicht deterministisch ist: Nicht alle Netzbetreiber bewerten AS-PATH gleich, und manche ignorieren Prepend in bestimmten Situationen.
Communities als Steuerkanal
Viele Provider nutzen Communities, um Announcement-Scope zu steuern (z. B. „announce only to upstream A“, „no-export“, „announce only in region X“). Communities sind operativ mächtig, aber fehleranfällig: falsches Tagging kann globale Effekte haben. Als Governance-Prinzip sollte jede Community eine dokumentierte Bedeutung haben, und Änderungen sollten in Canary-Schritten erfolgen.
Prefix-Granularität: /32 vs. /24 und der Blast Radius
Je spezifischer ein Prefix, desto gezielter können Sie mitigieren – aber desto höher ist das Risiko von BGP-Policy-Konflikten und unerwarteter Propagation. Zudem gibt es praktische Grenzen: Viele Netzbetreiber filtern zu spezifische Prefixe. Im IPv4-Internet ist /24 häufig eine praktische Untergrenze, während /32 nur in speziellen Kontexten (z. B. Host-Routes in kontrollierten Umgebungen) sinnvoll ist.
Collateral Damage messbar machen: Kennzahlen, die Ops wirklich helfen
Anycast Scrubbing darf nicht „nach Gefühl“ betrieben werden. Sie brauchen Metriken, die Collateral Damage quantitativ sichtbar machen. Bewährt haben sich diese Kategorien:
- Traffic-Metriken: Attack vs. Clean (BPS/PPS) pro PoP, pro Zielprefix, pro Port.
- Service-SLIs: TCP Connect Success, TLS Handshake Success/Time, HTTP Success Rate, DNS Success Rate – getrennt nach Regionen und IPv4/IPv6.
- False-Positive-Indikatoren: Drops auf Whitelist-Traffic, plötzliche Fehlerzunahme ohne Attack-BPS-Anstieg.
- Drift-Indikatoren: Anteil des Traffics, der den PoP wechselt (PoP-Churn), plus Latenzsprünge pro Region.
Collateral-Damage-Rate als praktischer KPI (MathML)
Die Herausforderung liegt in der Bestimmung von
PoP-Drift-Rate (MathML)
Ein hoher DriftRate-Wert während einer Mitigation ist ein Warnsignal: Entweder destabilisiert die Policy das Anycast-Verhalten, oder ein PoP nähert sich seiner Kapazitätsgrenze und Traffic „flüchtet“ über BGP-Entscheidungen.
Sichere Mitigation im Anycast Scrubbing: Guardrails statt „Big Switch“
Das Ziel ist, Angriffsvektoren zu entfernen, ohne den legitimen Traffic zu zerstören. Dafür braucht es abgestufte Maßnahmen und klare Stop-Kriterien.
Guardrail 1: Stufenweise Policy-Aktivierung (Canary)
Ändern Sie niemals gleichzeitig alle PoPs. Ein bewährtes Muster ist:
- Policy in einem PoP (oder einer Region) aktivieren,
- Service-SLIs und CollateralRate beobachten,
- erst dann ausrollen, wenn die Wirkung eindeutig positiv ist.
Guardrail 2: PoP-spezifische Kapazitätslimits und automatische Entlastung
Wenn ein PoP seine PPS/BPS-Grenzen erreicht, sollte das System definierte Reaktionen haben: entweder Traffic kontrolliert umverteilen (Policy), oder die Mitigation aggressiver machen (mehr Drops), aber mit SLA-Priorisierung. Ohne solche Regeln kommt es zu unkontrollierten Hotspots und Drift.
Guardrail 3: Whitelist und „Keep-the-lights-on“-Traffic
Ein häufig unterschätztes Risiko ist, dass Mitigation Monitoring und Management-Traffic mitkappt. Mindestens folgende Klassen müssen geschützt werden:
- Health Checks und synthetische Probes: sonst verlieren Sie Sichtbarkeit genau im Incident.
- Customer-critical Dependencies: DNS zu eigenen Resolvern, Auth-Endpunkte, Payment-APIs (wenn relevant).
- Routing/Control Plane: BGP und Managementpfade, damit Sie nicht „blind“ werden.
Guardrail 4: Rückschalten kontrollieren, Second Outage vermeiden
Anycast Scrubbing hat oft einen „Second Outage“-Risikozeitpunkt: beim Deaktivieren einer Mitigation oder beim Zurücknehmen von Prepend/Community-Scopes. Traffic kann schlagartig zurückspringen, Hotspots erzeugen und legitime Services erneut destabilisieren. Eine sichere Praxis ist:
- Stabilitätsfenster definieren: z. B. 15–30 Minuten stabile SLIs, bevor zurückgeschaltet wird.
- Rollback in Stufen: Policies schrittweise lockern, nicht global entfernen.
- Peakzeiten vermeiden: nicht kurz vor erwarteten Trafficpeaks zurückschalten.
Policy-Routing-Runbook für Ops: Anycast Scrubbing ohne Kollateralschaden betreiben
Ein Runbook macht Anycast Scrubbing beherrschbar, weil es Entscheidungen standardisiert und Beweise erzwingt.
Schritt: Angriff bestätigen und Serviceprofil prüfen
- Vektor: UDP Amplification, SYN Flood, ACK Flood, GRE Flood – was dominiert?
- Ports/Ziele: welche Zielprefixe und Ports sind betroffen?
- Legitimität: welche Ports/Protokolle sind für den Service wirklich nötig?
Schritt: Anycast-Verteilung analysieren
- PoP-Last: Attack vs. Clean pro PoP (BPS/PPS).
- Drift: wandert legitimer Traffic unerwartet zwischen PoPs?
- Rückwege: sind Return-Paths stabil (Tunnels/Interconnects/Backbone)?
Schritt: Policy-Routing-Maßnahme auswählen
- Scope reduzieren: Communities nutzen, um bestimmte Upstreams/Regionen zu entlasten.
- Last verschieben: moderates Prepending, aber nur mit Beobachtung der SLIs.
- PoP schützen: lokale Rate-Limits, bevor der PoP kollabiert.
Schritt: Collateral Damage aktiv überwachen
- SLIs: Connect/TLS/DNS Success Rate pro Region.
- Whitelist: Hits und Drops für definierte „must pass“-Flows.
- Fehlerbudget: wenn CollateralRate steigt, Policy zurücknehmen oder verfeinern.
Schritt: Dokumentation und Evidence Pack
- Routing-Änderungen: welche Communities, welche Prefixe, welche PoPs?
- Signaturen: welche Filter/Rate-Limits waren aktiv?
- Impact: SLI-Verläufe, DriftRate, CollateralRate, Kundenregionen.
Praktische Empfehlungen, um Collateral-Damage-Risiko dauerhaft zu senken
- Policy-Drift verhindern: zentrale Policy-Templates, regelmäßige Diff-Checks zwischen PoPs.
- Baseline pro Region: normale Latenz/Success-Profile pro PoP kennen, um Drift schnell zu erkennen.
- Attack-Simulationen: Drills mit kontrollierten Lasten, um Guardrails und Rollback zu üben.
- Routing-Sicherheit: klare Communities, Freigabeprozesse, und Best Practices wie BCP 38/84 im Netz verankern.
- Transparente Onboarding-Daten: Service-Ports, Abhängigkeiten, erwartete Peaks, Partnerlisten – damit Signaturen nicht „im Blindflug“ erstellt werden.
Outbound-Ressourcen
- RFC 4271 (BGP-4)
- RFC 2827 (BCP 38: Network Ingress Filtering gegen Spoofing)
- RFC 3704 (BCP 84: Ingress Filtering für Multihomed Networks)
- RFC 1035 (DNS Fundamentals)
- RFC 4035 (DNSSEC Protocol Modifications)
- RFC 7011 (IPFIX: Flow-Export für DDoS-Triage)
- MANRS (Best Practices für Routing Security und Provider-Normen)
- FIRST Incident Response Guides (Runbook-Methodik)
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.
