DDoS-Scrubbing-Center: Architektur, Routing und Betrieb

Ein DDoS-Scrubbing-Center ist in vielen Provider- und Enterprise-Netzen die letzte Verteidigungslinie, wenn volumetrische Angriffe (UDP Amplification, GRE-Floods, TCP-ACK-Floods) oder state-orientierte Angriffe (SYN Floods gegen Firewalls/LBs) die Edge-Kapazität oder die Service-Perimeter überfordern. Während lokale Filter (ACLs, Policer, uRPF) am Rand schnell greifen können, stoßen sie bei Leitungssättigung oder hoher Source-Diversität an Grenzen: Der Traffic ist dann bereits „zu groß“, um ihn auf dem eigenen Backbone sauber zu verarbeiten. Genau hier setzt ein DDoS-Scrubbing-Center an: Es zieht den Angriffstraffic gezielt in eine Reinigungsinfrastruktur, separiert bösartigen von legitimen Paketen (Scrubbing) und leitet nur den bereinigten Verkehr zurück zum Ziel. Das klingt einfach, ist aber operativ anspruchsvoll. Ein Scrubbing-Center ist nicht nur eine Appliance, sondern eine Architektur aus Routing-Mechanismen (BGP, GRE/IPsec-Tunnel, Anycast), hoher Observability, klaren Runbooks und sicheren Fallback-Strategien, damit Mitigation nicht selbst zum Ausfall führt. Dieser Artikel erklärt DDoS-Scrubbing-Center praxisnah: die gängigen Architekturen, Routing- und Signalisierungsmodelle, Betriebsprozesse (Triage, Onboarding, Change, Tests) sowie typische Failure Modes und wie Sie sie vermeiden.

Was ein DDoS-Scrubbing-Center leistet

Ein Scrubbing-Center hat drei Kernaufgaben:

• Traffic-Diversion: Angriffstraffic wird vom ursprünglichen Pfad abgezogen und in die Scrubbing-Infrastruktur geführt.
• Mitigation/Scrubbing: Filtering und Rate-Control auf mehreren Ebenen (L3/L4 bis hin zu Protokollheuristiken), um Angriffsvektoren zu entfernen.
• Clean-Traffic-Delivery: der bereinigte Traffic wird zum Origin (Kundenstandort, Rechenzentrum, Anycast-Service) zurückgeführt – mit minimaler Latenz und ohne neue Engpässe.

Wichtig: Ein Scrubbing-Center ersetzt kein sauberes Security-Baseline-Engineering am Edge. Es ist ein Skalierungs- und Resilienzmechanismus für Worst-Case-Szenarien, in denen „lokale“ Maßnahmen nicht reichen oder die Leitung bereits gesättigt ist.

Scrubbing-Modelle im Überblick

In der Praxis haben sich drei Modelle etabliert, die sich in Routing, Latenz und Betriebsaufwand unterscheiden.

Always-On Scrubbing

Beim Always-On-Modell läuft der Traffic dauerhaft über die Scrubbing-Infrastruktur, oft als Teil eines globalen Anycast-Netzes oder als vorgelagertes Protection-Layer. Vorteil: Kein Umschaltmoment im Incident, geringes Risiko für Fehl-Diversion. Nachteil: Dauerhafte Zusatzlatenz, permanenter Betrieb von Mitigation-Policies, und eine höhere Anforderung an Transparenz (Logging, Fehlalarme).

• Geeignet für: große, ständig angegriffene Services (DNS, CDN, Login-Plattformen), öffentliche APIs.
• Operativer Fokus: False Positives minimieren, Policy-Updates kontrollieren, Kapazität laufend messen.

On-Demand Scrubbing

Beim On-Demand-Modell wird erst im Angriff umgeschaltet („divert“), typischerweise per BGP-Announcement oder Tunnel-Activation. Vorteil: Keine zusätzliche Latenz im Normalbetrieb, Policies können stärker „attack-driven“ sein. Nachteil: Umschaltlogik ist ein Risiko (Fehldiversion, Route Leaks, zweite Störung beim Zurückschalten).

• Geeignet für: Enterprises/Provider-Kunden, die selten angegriffen werden, oder für definierte Schutzpakete.
• Operativer Fokus: schnelle, sichere Diversion; klare Stop-/Rollback-Kriterien; Tests im Change Window.

Hybrid Scrubbing

Hybrid kombiniert Always-On für kritische Services (z. B. Anycast DNS) und On-Demand für andere Prefixe. Das ist häufig in Provider-Umgebungen sinnvoll, weil nicht jeder Dienst denselben Schutzbedarf hat.

Architektur-Bausteine eines Scrubbing-Centers

Unabhängig vom Modell besteht ein Scrubbing-Center typischerweise aus mehreren Schichten, die unterschiedliche Aufgaben abdecken. Eine robuste Architektur trennt diese Schichten klar, um Fehlersuche und Skalierung zu vereinfachen.

Edge Ingress und Traffic-Akquisition

• Peering/Transit: hohe Bandbreite, viele Wege, um Angriffstraffic aufzunehmen (diverse Upstreams).
• Anycast oder gezielte Diversion: Mechanismus, um den Traffic zuverlässig in die Scrubbing-Edge zu ziehen.
• Anti-Spoofing: uRPF/Ingress Filtering, um Spoofing-Anteile zu reduzieren (Best Practices siehe RFC 2827 und RFC 3704).

Mitigation Fabric

• Stateless Filtering: schnelle L3/L4-Filter (Ports, Protokolle, Fragment-Anomalien), PPS/BPS-Policer.
• Stateful/Heuristik: TCP-SYN-Validierung, Connection-Limits, Protokollvalidierung für DNS/NTP/CLDAP, Rate-Limits pro 5-tuple.
• Signatur-Management: definierte Policies pro Kunde/Service, plus dynamische Signaturen für aktuelle Angriffe.

Clean-Traffic Egress

• Return Path: Rückführung per GRE/IPsec, per BGP zurück zum Kunden, oder via direkte Private Interconnects.
• QoS/Protection: clean traffic muss priorisiert werden; Control-Plane muss stabil bleiben.
• Observability: klare Telemetrie „attack vs. clean“, Drops, Latenz, Jitter, False Positive Indizien.

Routing-Mechanismen: Wie Traffic ins Scrubbing kommt

Routing ist der Kern eines Scrubbing-Centers. Wenn das Routing falsch ist, „scrubben“ Sie entweder gar nichts (Traffic bleibt beim Opfer) oder Sie scrubben zu viel (Kollateralschaden). Im Folgenden die wichtigsten Routing-Optionen.

BGP-Diversion per Prefix Announcement

Der klassische On-Demand-Ansatz ist BGP-Diversion: Das Scrubbing-Center announct das betroffene Prefix (oder ein spezifischeres Prefix), sodass der Traffic zu den Scrubbing-POPs geroutet wird. Das funktioniert besonders gut bei Leitungssättigung, weil der Traffic schon vor dem Engpass „abgezogen“ wird. BGP-Grundlagen sind in RFC 4271 beschrieben.

• Vorteil: sehr effektiv gegen volumetrische Angriffe; global wirksam.
• Risiko: Route Leaks/Missannouncements; falsche Prefix-Länge; ungewollter globaler Shift.
• Guardrail: maximale Prefix-Länge und Communities, die nur gewünschte Upstreams/Peers ansprechen.

GRE- oder IPsec-Tunnel Return Path

Häufig wird der bereinigte Traffic über Tunnel zurückgeführt, insbesondere wenn der Kunde seine Prefixe nicht komplett an das Scrubbing-Center „abgeben“ möchte oder wenn man einen klaren Rückweg erzwingen will. GRE ist simpel und weit verbreitet; IPsec bietet Vertraulichkeit/Integrität, bringt aber Overhead und Betriebsaufwand.

• Vorteil: deterministischer Rückweg, schnelle Aktivierung, klare Trennung „scrubbed vs. normal“.
• Risiko: MTU/Fragmentation-Probleme, Tunnel-ECMP, Key-Management (bei IPsec).
• Ops-Pflicht: MTU-Standards, PMTUD, Monitoring für Tunnel Drops und Encapsulation-Overhead.

Anycast für Schutzservices

Anycast ist besonders geeignet für servicespezifischen Schutz (DNS, CDN Edge, Auth Gateways): Der Dienst wird global mit derselben IP announced, und Traffic geht zum „nächsten“ POP. Anycast kann gleichzeitig Lastverteilung und DDoS-Absorption bieten, wenn die Scrubbing-Kapazität über viele POPs verteilt ist.

• Vorteil: natürliche Verteilung; kein Umschaltmoment; Resilienz durch viele POPs.
• Risiko: Traffic Drift bei Routing-Änderungen; regionale Hotspots; komplexere Debugging-Anforderungen.

FlowSpec und RTBH als „schnelle Schienen“

Viele Betreiber ergänzen Scrubbing durch schnelle BGP-basierte Maßnahmen: RTBH (Traffic wird früh verworfen) und FlowSpec (distributive Filterregeln). Diese Mechanismen sind wertvoll, müssen aber streng kontrolliert werden, um Kollateralschäden zu vermeiden.

• RTBH: sinnvoll, wenn ein einzelnes Ziel temporär „unrettbar“ ist und Infrastrukturschutz Priorität hat.
• FlowSpec: nützlich für gezielte Filter (z. B. UDP Port X zu Prefix Y), aber erfordert klare Governance.

Dimensionierung: Kapazität und „Headroom“ richtig denken

Ein Scrubbing-Center wird oft mit „Tbps“ beworben. Operativ zählt jedoch, ob die Kapazität in den relevanten Dimensionen reicht:

• Bits/s: volumetrische Angriffe (Amplification) sättigen Leitungen.
• Packets/s: PPS-lastige Angriffe (kleine UDP-Pakete) sättigen Forwarding-ASICs.
• State/s: stateful Mitigation (SYN validation, connection tracking) benötigt CPU/Memory.
• Control Plane: BGP-Updates, Telemetrie, Signatur-Updates dürfen nicht kollabieren.

Einfaches Headroom-Kriterium (MathML)

$\mathrm{Headroom}=\mathrm{Capacity}-\mathrm{PeakLegit}-\mathrm{ExpectedAttack}$

Operativ sollte Headroom nicht „knapp über Null“ sein. Wenn Ihre Architektur bei jeder Diversion sofort in Congestion läuft, produziert die Mitigation einen zweiten Ausfall (Jitter/Loss für legitimen Traffic). Deshalb gehört Kapazitätsmodellierung (inklusive N-1-Szenarien) in jede Scrubbing-Planung.

Traffic-Muster und Policy-Design: Wie Scrubbing sicher filtert

„Sichere Mitigation“ heißt: bösartig raus, legitim rein – ohne zu raten. Dafür brauchen Sie ein Policy-Design, das sowohl generische Vektoren (UDP amplification, SYN flood) als auch kundenspezifische Legitimität abbildet.

Baselines und Allow-Listen

• Service-Ports: Welche Ports sind wirklich legitim für den Kundenservice?
• Protokollprofile: DNS-Responses (EDNS0), NTP, QUIC – was ist normal?
• Geo/ASN Erwartungen: wenn sinnvoll, definieren, wo legitimer Traffic herkommt.

Default-Deny vs. Default-Allow

Viele Scrubbing-Center arbeiten mit „Default-Allow + gezielte Drops“, weil Default-Deny im Internetbetrieb schnell legitimen Traffic kappt. Für besonders kritische Services kann jedoch ein stärker allow-list-basiertes Modell sinnvoll sein, wenn die Legitimität gut definierbar ist (z. B. B2B APIs mit festen Partner-ASNs).

Operationaler Betrieb: Runbooks, Rollen und Entscheidungsfluss

Ein Scrubbing-Center ist ein Produktionssystem. Ohne klare Prozesse ist die technische Architektur wenig wert. Im Betrieb haben sich diese Rollen und Abläufe bewährt:

• Triage (NOC/SOC): Angriff bestätigen, Scope bestimmen (Prefix, Ports, POPs), erste Mitigation wählen.
• Mitigation Engineer: Signaturen/Policies anpassen, Whitelists pflegen, False Positives minimieren.
• Routing Operator: Diversion aktivieren/rollbacken (BGP, Tunnel, communities), Guardrails überwachen.
• Customer Communication: Status, erwartete Effekte (Latenz, mögliche Geoblock-Effekte), Updates im festen Rhythmus.

Onboarding: Was vor dem ersten Angriff geklärt sein muss

• Prefix Ownership und Autorisierung: welche Prefixe dürfen vom Scrubbing-Center announced werden?
• Return Path: Tunnel-Endpunkte, MTU, Routing-Policy, Failover-Pfade.
• Legitime Serviceprofile: Ports/Protokolle, erwartete Spitzen, Partnerlisten.
• Kontakt- und Freigabeprozesse: wer darf RTBH aktivieren, wer darf globales BGP-Diversion triggern?

Change-Management: Warum Scrubbing-Changes besonders riskant sind

Scrubbing-Changes wirken oft global. Deshalb müssen Sie sie wie Backbone-Changes behandeln: Canary, Stufen, Rollback in Minuten. Typische riskante Änderungen:

• Neue BGP-Policies/Communities: können Traffic unerwartet umlenken.
• Neue Signaturen: können False Positives erzeugen, die „wie ein Ausfall“ wirken.
• Tunnel/MTU-Änderungen: können fragmentationsbedingte Blackholes erzeugen.

Tests und Drills: Wie Sie Scrubbing ohne echten Angriff validieren

• Diversion-Test: Prefix testweise umleiten, End-to-End SLIs messen (HTTP/TLS/DNS), dann zurückrollen.
• Mitigation-Test: synthetische „Attack“-Last (lab/sim) oder kontrollierte Rate-Limits, um Policy-Wirkung zu prüfen.
• N-1 Test: POP-Ausfall simulieren, um zu sehen, ob Anycast/Failover den Traffic sauber verteilt.

Observability: Pflicht-Dashboards für Scrubbing-Betrieb

Für E-E-A-T und belastbare RCAs brauchen Sie standardisierte Sicht auf Angriff, Mitigation und Kundenerlebnis. Mindestens:

• Attack vs. Clean Traffic: BPS/PPS getrennt, pro POP, pro Prefix, pro Port.
• Drops/Actions: welche Signatur droppt wie viel; Rate-Limits und deren Hit-Rates.
• Service SLIs: TCP connect success, TLS handshake time, DNS success rate – getrennt nach v4/v6.
• Routing Health: aktive Diversions, announced Prefixes, BGP session health, route propagation.
• Tunnel Health: encapsulation overhead, MTU, drops, jitter, latency.

Häufige Failure Modes im Scrubbing-Center und wie Sie sie vermeiden

• Fehldiversion: falsches Prefix, falsche Community, unerwartete globale Propagation → Guardrails und „two-person rule“ für kritische Aktionen.
• False Positives: legitimer Traffic wird gefiltert → baselined Policies, Whitelists, schnelle Rollbacks, Canary.
• Return Path Blackhole: Tunnel/Route zurück zum Origin kaputt → Monitoring, MTU-Standards, redundante Tunnel.
• Scrubbing Congestion: Clean-Traffic leidet, obwohl Attack gedroppt wird → Headroom, per-queue QoS, N-1 Planung.
• Control Plane Collapse: BGP/Telemetry bricht unter Attack → CoPP/Management-QoS, getrennte Managementpfade.

Evidence Pack für RCA und Kundenkommunikation

• Zeitlinie (UTC): Start, Diversion aktiv, Signaturen, Peak, Stabilisierung, Rollback.
• Routing-Beweise: Prefixes/Communities, betroffene POPs, Propagation-Status, Rückweg.
• Traffic-Metriken: Attack vs. Clean (BPS/PPS), Top Ports, Top Targets, Source-Diversität.
• Impact: SLI-Verläufe, Drops/Jitter, Kundenmeldungen nach Region.
• Lessons Learned: welche Guardrails/Automationen hätten die Reaktion beschleunigt?

Outbound-Ressourcen

• RFC 4271 (BGP-4, Routing-Grundlage für Diversion)
• RFC 2827 (BCP 38: Network Ingress Filtering gegen Spoofing)
• RFC 3704 (BCP 84: Ingress Filtering für Multihoming)
• RFC 7011 (IPFIX, Flow-Daten für DDoS-Triage)
• FIRST Incident Response Guides (Runbooks und IR-Methodik)
• MANRS (Mutually Agreed Norms for Routing Security, Best Practices für Provider)

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.