Scrubbing-Center-Architektur: Komponenten aufs OSI-Modell mappen

Das Hauptkeyword „Scrubbing-Center-Architektur: Komponenten aufs OSI-Modell mappen“ beschreibt einen Ansatz, der im Provider- und Rechenzentrumsbetrieb enorm hilfreich ist: Statt ein Scrubbing-Center als „Blackbox gegen DDoS“ zu betrachten, zerlegen Sie es entlang des OSI-Modells in klar greifbare Bausteine. Das hat zwei direkte Vorteile. Erstens wird Architektur- und Kapazitätsplanung deutlich präziser, weil Sie Bandbreite, Paketraten, State-Tabellen, Signatur-Engines und Applikationslogik getrennt bewerten können. Zweitens wird der Betrieb stabiler, weil Incident-Response nicht in Panikaktionen endet („Alles droppen!“), sondern entlang der Layer schrittweise, reproduzierbar und mit minimalem Collateral Damage erfolgt. Ein Scrubbing-Center ist im Kern eine spezialisierte Traffic-Verarbeitungskette, die schädlichen Verkehr erkennt, isoliert und entfernt, während legitimer Verkehr mit möglichst wenig zusätzlicher Latenz und ohne Funktionsverlust zum Ziel zurückgeführt wird. Je nach Einsatz (ISP-Backbone, Data-Center-Edge, Multi-Tenant-Cloud, Enterprise) unterscheidet sich die Ausprägung, aber die Grundlogik bleibt: Traffic-Steering hinein, Filter-/Mitigation-Pipeline durch, saubere Rückführung heraus – inklusive Telemetrie, Orchestrierung und Governance. In diesem Artikel werden die wichtigsten Komponenten eines Scrubbing-Centers strukturiert erklärt und pro OSI-Layer „gemappt“, sodass Planung, Fehlersuche und Change-Management in großen Netzen deutlich einfacher werden.

Was ein Scrubbing-Center operativ leisten muss

Ein Scrubbing-Center schützt typischerweise vor volumetrischen Angriffen (Gbps), paketgetriebenen Angriffen (pps), state-orientierten Angriffen (z. B. SYN-Floods, Connection-Tracking-Exhaustion) und – je nach Tiefe – vor Applikationsangriffen (L7, WAF). In Provider-Umgebungen kommt ein weiteres Ziel hinzu: Das Netz selbst muss stabil bleiben. Das bedeutet, dass nicht nur die Kundenpräfixe geschützt werden, sondern auch die Infrastruktur (Peering, Transit, Core, Control Plane, Telemetrie-Systeme).

• Steering: Traffic schnell und kontrolliert ins Scrubbing bringen (ohne Routing-Chaos).
• Mitigation: Angriffsverkehr entfernen oder drosseln, legitimen Verkehr erhalten.
• Return: „Clean Traffic“ zuverlässig zurück zum Ziel – ohne Asymmetrien, Loops oder MTU-Fallen.
• Observability: Wirkung messen (Drops, Latenz, Fehlerquoten), nicht nur „weniger Gbps“ sehen.
• Automation: Regeln, Kapazitäten und Policies schnell ausrollen und sauber zurückrollen.

Warum das OSI-Modell hier mehr ist als Theorie

Im Alltag werden DDoS-Schutz, Firewalling, Routing und Telemetrie oft vermischt, was zu Fehlentscheidungen führt: pps-Probleme werden mit bps-Limits gelöst, Layer-7-Probleme werden mit Blackholing bekämpft, und das eigentliche Bottleneck liegt in State-Tabellen oder Logging. Das OSI-Mapping zwingt zu einer sauberen Fragestellung pro Layer: Wo genau entsteht der Engpass, welche Komponente ist dafür zuständig, und welche Mitigation ist am wenigsten invasiv?

Layer 1 im Scrubbing-Center: Physik, Optik und Kapazitätsreserven

Layer 1 wirkt banal („Link up/down“), ist aber im Scrubbing-Kontext entscheidend, weil volumetrische Angriffe die physische Kapazität zuerst treffen. Scrubbing ist nur dann wirksam, wenn Ihre Ingress-Kapazität, Interconnects und Fabric-Uplinks das Angriffsvolumen plus Headroom tragen können.

• Transceiver/Optik: 100G/400G-Ports, DOM/DDM-Werte, FEC-Profile, Reserve gegen Degradation.
• WDM/Interconnect: DWDM/Metro-Verbindungen zwischen Scrubbing-PoPs und Backbone.
• MTU und Fehlertoleranz: Vor allem relevant, wenn Encapsulation (GRE/IP-in-IP) genutzt wird.
• Physische Redundanz: Diverse Paths und getrennte PoPs, um Blast Radius zu reduzieren.

Operativ ist Layer 1 auch dort kritisch, wo Scrubbing als „immer verfügbar“ verkauft wird: Wenn ein einzelner PoP überlastet oder degradiert, muss Steering auf andere Standorte umschalten können, ohne dass Rückwege brechen.

Layer 2: Switching-Fabric, Segmentierung und Mitigation nahe der Hardware

Auf Layer 2 liegt die interne Transportlogik: Leaf-Spine-Fabric, L2-Segmentierung, VLAN/EVPN, QoS-Queues, ACL-Offloads. Viele Scrubbing-Designs setzen auf eine hochperformante Switching-Fabric, damit Filter- und Analyse-Nodes horizontal skaliert werden können.

• DC-Fabric: Leaf/Spine mit ausreichend ECMP-Pfaden für East-West-Traffic.
• Segmentierung: getrennte Domains für Ingress, Processing, Management, Return.
• Hardware-ACLs: erste, grobe Drops („garbage filtering“) direkt in ASICs.
• Storm-Control/Protection: Broadcast-/Multicast-Noise darf die Fabric nicht destabilisieren.

Wenn EVPN eingesetzt wird (als L2-Control-Plane), ist es hilfreich, die Grundprinzipien zu kennen, bevor man Troubleshooting betreibt. Eine technische Einstiegssicht liefert die EVPN-Beschreibung in RFC 7432. Für VXLAN als gängige Encapsulation im DC-Kontext ist RFC 7348 eine Referenz.

Layer 3: Routing, Steering und Rückführung des Clean Traffic

Layer 3 ist das Herzstück der Scrubbing-Center-Architektur, weil hier entschieden wird, welcher Traffic wohin läuft. In der Praxis dominieren BGP-basierte Mechanismen, weil sie global steuerbar, standardisiert und im Provider-Umfeld etabliert sind. Die Basis für BGP ist RFC 4271.

Traffic-Steering: Wie der Angriff ins Scrubbing gelangt

• More-Specific Announcements: Das Scrubbing-Center announced ein spezifischeres Präfix des Kunden, um Traffic anzuziehen.
• BGP Communities/Policy: gezielte Steuerung über Peers/Transits, Blackholing als Notbremse.
• Anycast-Modelle: Traffic landet am „nächsten“ Scrubbing-PoP, wenn Anycast genutzt wird.
• On-demand vs. Always-on: on-demand reduziert Normal-Latenz, always-on vereinfacht Betriebsmodelle und verhindert Umschaltstress.

Clean-Traffic-Return: Wie der bereinigte Verkehr zurückkommt

Nach der Mitigation muss der legitime Verkehr zum eigentlichen Ziel zurück. Dafür sind zwei Muster besonders verbreitet:

• GRE-Tunnel: robuste, einfache Encapsulation; Referenz: GRE (RFC 2784).
• IP-in-IP: ebenfalls gängig, oft leichter; Referenz: IP-in-IP (RFC 2003).

Das Return-Design scheitert in der Praxis selten an Routing, sondern an Details: MTU, Fragmentierung, asymmetrische Pfade, ECMP-Hashing, falsche Source-IP beim Return oder fehlende Policy-Routen am Ziel-Edge. Deshalb gehört Layer 3 im Scrubbing-Center immer mit einem klaren „Path-Validation“-Konzept zusammen: Sie müssen belegen können, dass der bereinigte Traffic wirklich die gleiche Servicequalität erreicht wie im Normalbetrieb.

Layer 4: State, SYN-Protection und „Session Health“

Layer 4 ist in Scrubbing-Centern der Bereich, in dem viele Angriffe operativ kippen: SYN Floods, ACK Floods, UDP Floods, State Exhaustion, NAT/Conntrack-Überlast. Selbst wenn Bandbreite vorhanden ist, können Session-Create-Raten oder State-Tabellen kollabieren. Ein gutes Scrubbing-Center hat daher eine explizite L4-Mitigation-Schicht.

• SYN-Proxy/SYN-Cookies: schützt Server und Firewalls vor halb-offenen Verbindungen.
• Rate Limiting für new sessions: pro Source, pro Ziel, pro Serviceklasse; mit sinnvollen Bursts.
• State-Offload: möglichst früh „stateless“ filtern, bevor stateful Komponenten belastet werden.
• UDP-Handling: Timeout-Profile und pps-Limits, um Reflexions-Noise zu bändigen.

Für Transportgrundlagen ist TCP in RFC 9293 beschrieben. Für DiffServ/QoS-Logik, die bei L4/L3-Policyentscheidungen oft mitspielt, ist RFC 2475 hilfreich.

Layer 5 und 6: Sessions, TLS und Protokollnormalisierung

In der Praxis werden Layer 5 und 6 im OSI-Modell oft zusammen behandelt, weil viele Scrubbing-Systeme hier „Session Awareness“ und Kryptologie berühren. Besonders relevant wird das, wenn Sie L7-Angriffe erkennen wollen, aber der Traffic verschlüsselt ist. TLS-Terminierung kann helfen, ist aber ein massiver Eingriff und nicht immer gewünscht oder möglich.

• TLS-Offload/Inspection: möglich in bestimmten Managed-Security-Szenarien, aber komplex hinsichtlich Zertifikaten und Datenschutz.
• Handshake-Telemetrie: selbst ohne Decryption ist das Erkennen von Handshake-Anomalien wertvoll.
• Protocol Sanitization: ungültige Flags, Fragment-Anomalien, „abnormale“ Sequenzen früh verwerfen.

Wenn TLS eine Rolle spielt, ist TLS 1.3 (RFC 8446) eine solide Referenz für Handshake-Mechanik und Eigenschaften.

Layer 7: Signaturen, WAF und anwendungsnahe Mitigation

Layer 7 ist die teuerste, aber oft notwendigste Schicht – insbesondere bei HTTP-Floods, Bot-Angriffen, API-Abuse oder komplexen Angriffsmustern, die auf Applikationslogik zielen. Ein Scrubbing-Center, das L7 übernimmt, braucht klare Leitplanken, damit Mitigation nicht mehr Schaden als Nutzen erzeugt.

• HTTP-Rate Limiting: pro Path, pro Host, pro Token/Client-Fingerprint; Bursts berücksichtigen.
• WAF-Regeln: Signaturen gegen bekannte Exploits und Payloads; Tuning gegen False Positives.
• Bot-Management: Challenges, Fingerprinting, Reputation – je nach Geschäftsmodell.
• Cache/Shielding: Content-Caching und Origin-Shield, um den Origin zu entlasten.

Für HTTP/2 als häufige Realität in modernen Services ist RFC 9113 eine nützliche Referenz. Für QUIC/HTTP/3-nahe Angriffsflächen ist das QUIC-Basisdokument RFC 9000 relevant, weil sich Traffic-Muster und Mitigation deutlich von klassischem TCP unterscheiden können.

Cross-Layer-Komponenten: Orchestrierung, Policy-Engine und Change-Sicherheit

Die effektivsten Scrubbing-Center scheitern selten an „fehlender Filter-Idee“, sondern an fehlender Orchestrierung: Regeln werden unkoordiniert ausgerollt, Rückrollpfade fehlen, und unterschiedliche Teams interpretieren Scope und Impact unterschiedlich. Eine Policy- und Orchestrierungsebene ist daher ein eigenes, zentrales Architekturelement.

• Policy-Repository: versionierte Regeln, Freigabeprozesse, Audit Trail.
• Automation: schnelles Ausrollen über PoPs hinweg, inklusive Staged Rollouts.
• Guardrails: automatische Limits gegen zu breite Regeln (z. B. „niemals global DNS droppen“).
• Playbooks: standardisierte Abläufe für volumetrische, pps- und L7-Lagen.

Cross-Layer-Komponenten: Telemetrie, Flow-Daten und „Wirkungsnachweis“

Ein Scrubbing-Center ohne belastbare Observability erzeugt ein gefährliches Gefühl von Kontrolle: „Wir haben gefiltert“ ist kein Beweis, dass Kunden wieder funktionieren. Deshalb benötigen Sie Telemetrie, die pro Layer Wirkung und Nebenwirkung sichtbar macht.

• L1/L2: Interface Errors, FEC, Drops in Queues, Congestion-Signale.
• L3: BGP-Status, Route-Propagation, Tunnel-Health, MTU/Fragmentation.
• L4: new sessions/s, SYN/ACK-Raten, conntrack utilization, drop reasons.
• L7: HTTP status codes, latency percentiles, origin health, false positive rate.

Flow-Daten sind dabei besonders wertvoll, weil sie Muster schnell quantifizierbar machen. Der Standardrahmen für IPFIX ist RFC 7011. Für praxisnahe DDoS-Grundlagen (inklusive Scrubbing- und Mitigation-Konzepten) ist außerdem ein Überblick wie DDoS-Erklärungen und Angriffsarten hilfreich, um Begriffe und Muster konsistent zu verwenden.

Mitigation-Pipeline als Datenpfad: Von „coarse“ zu „fine“

Eine robuste Architektur arbeitet wie eine Filterpyramide: früh billig, später teuer. Das reduziert Kosten, schützt State-Systeme und senkt Collateral Damage, weil spätere, feinere Regeln nur auf den verbleibenden Traffic angewendet werden.

• Stufe 1 (L2/L3): grobe Drops (offensichtlicher Müll, Spoofing-Indikatoren, klare Missmatches), Hardware-nah.
• Stufe 2 (L3/L4): vektorbasierte Limits (pps, ports, new flows), SYN-Protection, UDP-Timeout-Tuning.
• Stufe 3 (L7): Signaturen, Bot-Management, WAF-Policies, Applikationslogik.

Wenn Sie dynamische Filterregeln im Netz verteilen, kann BGP FlowSpec eine Rolle spielen; als Referenz eignet sich RFC 8955. Wichtig ist dabei immer: FlowSpec ist mächtig, aber riskant, wenn Regeln zu breit sind. Ein Scrubbing-Center sollte FlowSpec eher als präzises Skalierungswerkzeug nutzen, nicht als Ersatz für saubere Mitigation-Logik.

Kapazitätsplanung: Gbps reicht nicht – pps und State sind gleich wichtig

Scrubbing-Kapazität wird häufig nur in Gbps geplant. In der Realität entscheidet jedoch oft die Paketrate oder State-Create-Rate. Eine einfache, aber nützliche Kennzahl ist die durchschnittliche Paketgröße (zur Einordnung, ob ein Angriff pps- oder bps-dominiert ist):

$\mathrm{AvgPacketSize}=\frac{\mathrm{BitsPerSecond}}{\mathrm{PacketsPerSecond}}$

Für State-Systeme (z. B. L4-Proxies, conntrack-basierte Filter, NAT in Managed-Angeboten) ist außerdem die Beziehung zwischen neuen Flows und durchschnittlicher Lebensdauer (Timeout) wichtig:

$\mathrm{Entries}\_\mathrm{avg}\approx \mathrm{NewFlowsPerSecond}\times \mathrm{Timeout}\_\mathrm{avg}$

Diese beiden Größen verhindern Fehlplanung: Ein Scrubbing-Center kann „1 Tbps“ schaffen und trotzdem bei 200 Mpps oder bei Session-Create-Spitzen kollabieren, wenn die Pipeline nicht dafür gebaut ist.

Fehlermodi und OSI-typische Troubleshooting-Hinweise

Die OSI-Zuordnung ist besonders wertvoll, wenn Dinge schiefgehen. Viele Scrubbing-Probleme sind keine DDoS-Probleme, sondern Design- oder Betriebsfehler im Steer/Return.

• Layer 1: Uplinks überlastet, Optik degradiert, FEC korrigiert „zu viel“, Interconnect instabil.
• Layer 2: falsche VLAN/EVPN-Zuordnung, ECMP-Hashing verteilt ungleich, Fabric-Queues droppen.
• Layer 3: More-Specifics nicht korrekt propagiert, Route-Leaks, Tunnel-MTU falsch, Rückführung asymmetrisch.
• Layer 4: SYN-Protection zu aggressiv, new-flow-limits treffen legitime Peaks, UDP-Timeouts zu lang.
• Layer 7: WAF False Positives, Bot-Regeln blockieren echte Clients, Rate-Limits ohne Burst killen legitime Bursts.

Best Practices: Wie Sie das Scrubbing-Center „betriebsfest“ machen

Technische Komponenten sind nur die halbe Miete. Betriebsfestigkeit entsteht durch Standards, Tests und klare Verantwortlichkeiten.

• Always-on oder „warm on-demand“: Wenn on-demand, dann mit regelmäßig getesteter Umschaltung und klarer MTU/Return-Validierung.
• Chaos- und Load-Tests: nicht nur bps, sondern pps und session create testen.
• Regel-Hygiene: jede Regel mit Scope, Owner, Ablaufdatum, Rückrollplan.
• Schutz der Schutzsysteme: Telemetrie, Logging und Control-Plane müssen selbst DDoS-resistent sein.
• Minimierung von Collateral Damage: zuerst präzise Limits, dann eskalieren; QoS-Klassen schützen Echtzeit.

Outbound-Links für Standards und vertiefende Informationsquellen

• BGP (RFC 4271) als Grundlage für Steering, More-Specifics und Policy-Design
• BGP FlowSpec (RFC 8955) für dynamische Filterregeln im Netzbetrieb
• GRE (RFC 2784) als gängige Tunnel-Encapsulation für Clean-Traffic-Return
• IP-in-IP (RFC 2003) als Alternative für Return-Tunnel und Encapsulation
• IPFIX (RFC 7011) für Flow-Telemetrie, Mustererkennung und Wirkungskontrolle
• DiffServ (RFC 2475) für Serviceklassen und priorisierte Behandlung im Mitigation-Kontext
• TLS 1.3 (RFC 8446) für Session- und Handshake-Grundlagen bei verschlüsseltem Traffic
• HTTP/2 (RFC 9113) als Referenz für moderne L7-Traffic-Muster und mögliche Flood-Varianten
• QUIC (RFC 9000) für UDP-basierten Transport und abweichende Mitigation-Anforderungen
• DDoS-Grundlagen und Angriffsarten als Kontext für Scrubbing-Strategien und Failure Modes

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.