Scrubbing Center Design: Baseline-Architektur für große Provider

Ein belastbares Scrubbing Center Design ist für große Provider eine der wichtigsten Grundlagen, um volumetrische DDoS-Angriffe kontrolliert abzuwehren, ohne die eigene Backbone- und Peering-Infrastruktur oder die Kundendienste zu gefährden. Während kleinere Umgebungen häufig auf externe Mitigation-Services setzen, benötigen große Netzbetreiber eine Baseline-Architektur, die sowohl technisch skalierbar als auch betrieblich schnell aktivierbar ist: Traffic muss bei Bedarf in Sekunden bis Minuten umgeleitet, „gereinigt“ und als Clean Pipe zuverlässig zurückgeführt werden. Dabei geht es nicht nur um Durchsatz, sondern auch um Paketverarbeitungsraten (PPS), Latenz, Session-Handling, Multi-Tenancy, Routing-Sicherheit und saubere Prozesse für Aktivierung und Rückbau. Eine Telco-taugliche Baseline definiert deshalb klare Designentscheidungen: zentrale vs. verteilte Scrubbing-Standorte, BGP-Steuerung, Anycast, GRE- oder MPLS-Transport, Filterhierarchien, Observability, Automatisierung und Notfallverfahren. Dieser Artikel zeigt, wie Sie eine Scrubbing-Center-Architektur für große Provider so aufbauen, dass sie unter realen Angriffslasten funktioniert und im Betrieb nicht zum Risiko wird.

Warum ein Scrubbing Center bei großen Providern anders geplant wird

In Provider-Netzen sind DDoS-Angriffe selten ein einzelnes Ereignis, sondern eine wiederkehrende Betriebsrealität. Große Provider haben zusätzlich eine besondere Ausgangslage: Sie sehen Traffic früher (an Peering- und Transit-Kanten), sie betreiben häufig eigene DNS-/CDN-Komponenten, und sie müssen Mitigation nicht nur für eigene Dienste, sondern oft auch als Service für Unternehmenskunden anbieten. Daraus ergeben sich Anforderungen, die über klassische Enterprise-DDoS-Konzepte hinausgehen.

• Skalierung in Gbps und PPS: Volumen und paketlastige Angriffe erfordern Hardware- und Architekturreserven.
• Mehrere Angriffspunkte: Peering, Transit, regionale Aggregation, Anycast-Dienste.
• Multi-Tenancy: unterschiedliche Kunden und Dienste müssen isoliert mitigiert und abgerechnet werden können.
• Routing-Sicherheit: BGP-Umleitungen dürfen keine Instabilität oder Hijacks begünstigen.
• Betriebsgeschwindigkeit: Aktivierung, Tuning und Rückbau müssen standardisiert und teilautomatisiert sein.

Baseline-Ziele: Was eine Scrubbing-Center-Architektur liefern muss

Bevor man über Technologien spricht, sollte eine Baseline die messbaren Ziele festlegen. In großen Provider-Umgebungen ist es entscheidend, dass Mitigation nicht nur „Traffic blockt“, sondern legitimen Traffic mit minimalem Kollateralschaden weiterleitet. Gleichzeitig muss das System stabil unter Stress bleiben.

• Time-to-Mitigation: Umleitung und erste Filterwirkung in Minuten, idealerweise automatisierbar.
• Clean Pipe Qualität: legitimer Traffic bleibt erreichbar; False Positives werden schnell korrigiert.
• Kapazität: ausreichender Durchsatz, PPS und Session-Handling für erwartete Peak-Szenarien.
• Resilienz: keine Single Points of Failure; Wartung und Failover ohne Service-Impact.
• Transparenz: Telemetrie, Logs, Rule-Entscheidungen und eindeutige Kundenzuordnung.
• Governance: standardisierte Aktivierungs- und Rückbauprozesse, Rezertifizierung von Ausnahmen.

Architekturmodelle: zentral, verteilt oder hybrid

Die Standortstrategie entscheidet über Latenz, Kosten und Angriffstoleranz. Eine Baseline sollte definieren, wann zentrale Scrubbing-Center ausreichen und wann verteilte PoPs (Points of Presence) nötig sind. In der Praxis setzen große Provider häufig auf ein hybrides Modell: mehrere Scrubbing-Standorte, strategisch nahe an großen Peering-Knoten, kombiniert mit regionalen Mitigation-Fähigkeiten für bestimmte Dienste.

• Zentrales Scrubbing: einfacher Betrieb, hohe Konzentration von Kapazität, aber potenziell höhere Umleit-Latenz.
• Verteiltes Scrubbing: näher am Angriffsursprung, weniger Backbone-Belastung, aber komplexer Betrieb und Kapazitätsverteilung.
• Hybrid: zentrale High-Capacity-Standorte plus regionale „First-Line“-Filter (z. B. Flowspec/ACL) zur Entlastung.

Baseline-Kriterium: Wo entsteht der Engpass?

Wenn Ihre Anbindung oder Peering-Kanten bei großen Volumenangriffen überlaufen, ist Scrubbing nahe an den Kanten entscheidend. Wenn hingegen primär Plattformressourcen (State Tables, Firewalls, Load Balancer) erschöpft werden, kann ein zentraler Scrubbing-Punkt mit gezielten L3/L4-Filtern und L7-Ergänzungen ausreichend sein.

Traffic-Steuerung: BGP als Kernmechanismus (mit Sicherheitsleitplanken)

In Provider-Designs ist BGP die Standardmethode, um Traffic zum Scrubbing Center zu lenken. Die Baseline muss hier besonders streng sein, weil falsche Routenankündigungen zu großflächigen Störungen führen können. Entscheidend sind klare Route Policies, Filter, RPKI-Strategien und ein kontrollierter Workflow für Mitigation-Announcements.

• Umleitung per spezifischer Präfixe: während eines Angriffs werden spezifischere Routen announced, um Traffic zum Scrubbing zu ziehen.
• Communities und Policy-Steuerung: standardisierte Communities für „scrub“, „no-export“, „blackhole“.
• Routenfilterung: strikte Prefix-Listen und maximale Prefix-Anzahlen, um Fehlannouncements abzufangen.
• RPKI/ROA-Disziplin: saubere Autorisierung der annoncierten Präfixe, um Hijack-Risiken zu reduzieren.
• Rollback-Prinzip: jede Umleitung hat klare Rückbaukriterien und einen getesteten Rückweg.

Transport der Umleitung: GRE, IP-in-IP, MPLS oder direkte Anycast-Ansätze

Nachdem Traffic zum Scrubbing Center gelangt, muss er als Clean Pipe zurück zum Ziel. Dafür gibt es mehrere technische Ansätze, die in einer Baseline klar geregelt werden sollten. Entscheidend sind Latenz, MTU/Fragmentierung, Betriebskomplexität und Skalierbarkeit.

• GRE-Tunnel: weit verbreitet, flexibel, aber MTU- und Fragmentierungsmanagement ist kritisch.
• IP-in-IP: ähnlich GRE, teils einfacher, aber mit eigenen Tooling- und Visibility-Anforderungen.
• MPLS/VRF-Transport: sauber für Multi-Tenant-Modelle, oft gut integrierbar in Provider-Backbones.
• Direct Return / L2 Extension: seltener, kann jedoch in bestimmten Metro-Designs sinnvoll sein.
• Anycast-basiert: besonders für DNS/CDN-nahe Dienste; Scrubbing kann an Anycast-PoPs andocken.

Baseline-Regel: MTU- und Fragmentierungsstrategie ist Pflicht

Tunnelbasierte Scrubbing-Designs scheitern häufig an MTU-Problemen: Paketdrops, TCP-MSS-Probleme und schwer debuggbare „sporadische“ Fehler. Eine Baseline sollte daher zwingend festlegen, wie MTU-Ende-zu-Ende gemanagt wird (MSS-Clamping, Path MTU Discovery, definierte Tunnel-MTUs) und wie diese Parameter überwacht werden.

Filter-Pipeline: Mehrstufige Mitigation statt „eine große Regel“

Ein Scrubbing Center muss unter Last stabil bleiben. Dafür ist eine hierarchische Filterpipeline entscheidend: erst grobe, sehr schnelle Filter (stateless), dann feinere (stateful) und erst am Ende ressourcenintensive Prüfungen. Die Baseline sollte diese Pipeline als Standard definieren, damit Angriffe nicht die Scrubbing-Komponenten selbst überlasten.

• Stufe 1: Stateless Filtering: einfache Header-/Protokollregeln, Spoofing-Indikatoren, ungültige Flags, Fragment-Anomalien.
• Stufe 2: Rate Controls: PPS- und Bandbreitenlimits pro Ziel, Port oder „Traffic Class“.
• Stufe 3: Stateful Protections: SYN-Flood-Schutz, Challenge/Proxy-Mechanismen, Session-Table-Management.
• Stufe 4: Service-spezifische Filter: DNS-Query-Patterns, SIP-Rate Patterns, HTTP/HTTPS-basierte Regeln (ggf. integriert oder via separate Layer).

Service-spezifische Baselines: DNS, SIP und Web unterscheiden

Große Provider betreiben häufig Anycast-DNS, VoIP/SIP-Infrastrukturen und Web-/API-Dienste. Ein Scrubbing Center Design sollte deshalb service-spezifische Baselines enthalten, damit schnelle Standardmaßnahmen verfügbar sind. Das reduziert Tuning-Zeit im Incident.

• DNS: Schutz vor Query Floods, NXDOMAIN-Spikes, Reflection; Whitelisting/Allowlisting für legitime Resolverpfade mit Vorsicht.
• SIP/VoIP: Schutz vor REGISTER/INVITE Floods, Stateful Controls an SBC-nahen Komponenten, klare Limits pro Source/Trunk.
• Web/API: L7-Schutz typischerweise über WAF/API Gateway ergänzen; im Scrubbing Center Fokus auf L3/L4 und Rate Controls.

Multi-Tenancy und Kundenseparation: Baseline für Provider-Services

Wenn Scrubbing als Managed Service angeboten wird, sind Isolation und klare Zuordnung Pflicht. Eine Baseline sollte definieren, wie Kundenverkehr identifiziert wird (Präfixe, VRFs, SNI/Hostnames in L7-Szenarien) und wie Policies pro Kunde getrennt werden. Zusätzlich braucht es ein sauberes Exceptions- und Rezertifizierungsmodell, damit temporäre Kundenausnahmen nicht dauerhaft werden.

• VRF-/Tenant-Modelle: getrennte Routing- und Policy-Räume, um Cross-Tenant-Risiken zu vermeiden.
• Policy-Templates pro Serviceklasse: Standardprofile (z. B. „DNS Anycast“, „Web Portal“, „API“) als Startpunkt.
• Customer Ownership: klarer Owner pro Policy, definierte Supportfenster, dokumentierte Kontaktketten.
• TTL für Ausnahmen: Whitelists, Limit-Erhöhungen und Sonderregeln laufen ab und müssen aktiv verlängert werden.

Observability als Baseline: Telemetrie, die im Angriff wirklich hilft

Ein Scrubbing Center ist nur dann effektiv, wenn es in Echtzeit sichtbar macht, was passiert: Angriffsvektoren, Top Talkers, Wirksamkeit der Filter und Auswirkungen auf legitimen Traffic. Eine Baseline sollte definieren, welche Metriken, Logs und Dashboards zwingend bereitstehen – und wie diese Informationen in NOC/SOC-Prozesse eingebunden werden.

• Kapazitätsmetriken: Durchsatz (Gbps), PPS, Drops, CPU/ASIC-Auslastung, Session Tables.
• Mitigation-Metriken: blocked vs. passed, Rule-Hits, Rate-Limit-Aktivität, top vectors/ports.
• Traffic-Transparenz: Top Prefixes, ASNs, Geo, Protokollmix, Fragmentation-Anteile.
• Service-KPIs: für geschützte Dienste (DNS RCODEs, HTTP 4xx/5xx, SIP Response Codes), sofern verfügbar.
• Korrelation: Incident-Timeline, BGP-Events, Changes, Kundenimpact und Ticketing-Referenzen.

Automatisierung und Playbooks: Baseline für schnelle Aktivierung

Bei großen Providern sind manuelle Schritte im Incident ein Risiko. Eine Baseline sollte deshalb definieren, welche Aktionen standardisiert und automatisiert werden dürfen: etwa das Setzen von Communities, das Aktivieren von Flowspec-Templates oder das Umschalten von Scrubbing-Profilen. Gleichzeitig müssen Guardrails verhindern, dass Automation falsche Präfixe oder zu breite Filter verteilt.

• Template-Ansatz: vordefinierte Mitigation-Profile pro Angriffstyp und Serviceklasse.
• Approval-Modelle: „fast path“ für Standardmaßnahmen, „slow path“ für riskante Änderungen.
• Safety Checks: Prefix-Validation, Max-Prefix-Limits, Policy-Linting vor Aktivierung.
• Rollback-Automation: definierte Rückbaujobs nach Stabilisierung oder nach TTL.

Resilienz und Kapazitätsplanung: Baseline für Failure und Wartung

Scrubbing-Center-Designs müssen nicht nur Angriffe abwehren, sondern auch Wartung und Ausfälle verkraften. Eine Baseline sollte Kapazitätsreserven und Failure-Domains definieren: Was passiert, wenn ein Scrubbing-Standort ausfällt? Wie wird Last verteilt? Wie wird Software aktualisiert, ohne die Mitigation-Fähigkeit zu verlieren?

• N+1-Design: Kapazität so planen, dass ein Standort oder eine große Komponente ausfallen kann.
• Geo-Redundanz: mehrere Scrubbing-Standorte mit getesteter Umschaltung.
• Wartungsfenster: Rolling Updates, Canary-Ansätze, klare Fallbacks.
• Capacity Headroom: Reserven für Peak-Angriffe plus legitime Peaks, nicht nur Durchschnittslast.
• Peering-Strategie: ausreichend diverse Transit-/Peering-Pfade, um Umleitungen nicht zu verengen.

Governance: Rezertifizierung, Cleanup und Qualitätssicherung

Mitigation-Regeln wachsen über Zeit. Ohne Governance entstehen dauerhafte Ausnahmen, veraltete Kundenprofile und unübersichtliche Filtersets. Eine Baseline sollte daher Prozesse definieren, die den Scrubbing-Betrieb langfristig sauber halten: regelmäßige Reviews, Cleanup ungenutzter Regeln und standardisierte Dokumentation.

• Rezertifizierung: regelmäßige Überprüfung von Kundenprofilen, Whitelists und Sonderregeln.
• TTL-Pflicht: temporäre Maßnahmen laufen ab, statt „für immer“ aktiv zu bleiben.
• Post-Incident Reviews: Vektoren, Wirksamkeit, Collateral Damage, Verbesserungsaufgaben.
• KPI-Tracking: Time-to-Detect, Time-to-Mitigate, Clean-Pipe-Qualität, False Positive Rate.

Baseline-Checkliste: Scrubbing Center Design für große Provider

• Standortstrategie definiert: zentral/verteilt/hybrid mit klaren Kriterien (Engpass, Latenz, Peering).
• BGP-Guardrails aktiv: Prefix-Listen, Communities, Max-Prefix, RPKI-Disziplin, getestete Rollbacks.
• Transportmodell klar: GRE/IP-in-IP/MPLS/Anycast – inklusive MTU/MSS-Strategie und Monitoring.
• Filterpipeline standardisiert: stateless, rate controls, stateful, service-spezifisch – mit Templates.
• Multi-Tenancy gelöst: VRFs/Policy-Räume, Kundenzuordnung, TTL für Ausnahmen, Owner-Pflicht.
• Observability verpflichtend: Gbps/PPS, Rule-Hits, Drops, Top Talkers, Korrelation mit Routing/Incidents.
• Automatisierung sicher: Templates, Approval, Safety Checks, Rollback-Automation.
• Resilienz geplant: N+1, Geo-Redundanz, Wartungsfähigkeit, Capacity Headroom.
• Governance etabliert: Rezertifizierung, Cleanup, Post-Incident Reviews, KPI-Tracking.

Mit einer solchen Baseline-Architektur wird ein Scrubbing Center nicht zur komplexen Speziallösung, die nur wenige Experten bedienen können, sondern zu einem standardisierten Betriebsbaustein für große Provider. Die entscheidenden Erfolgsfaktoren sind dabei nicht einzelne Filterregeln, sondern das Zusammenspiel aus Routing-Steuerung, skalierbarer Filterpipeline, sauberem Transport zurück zum Ziel, durchgängiger Telemetrie und klaren Prozessen für schnelle, sichere Entscheidungen im Incident.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.