DDoS Schutzarchitektur: Scrubbing, RTBH und Flowspec explained

Eine moderne DDoS Schutzarchitektur entscheidet darüber, ob geschäftskritische Online-Services bei Angriffen erreichbar bleiben oder ob ein einzelnes Ereignis zu stundenlangen Ausfällen, Umsatzverlust und Reputationsschäden führt. Distributed Denial of Service (DDoS) ist dabei kein „Spezialfall“ mehr: Angriffe sind heute häufig, automatisiert, oft kurz („hit and run“) und kombinieren mehrere Vektoren wie volumetrische Floods, Protokollmissbrauch und applikationsnahe Überlast. Eine belastbare DDoS Schutzarchitektur setzt deshalb nicht auf eine einzelne Maßnahme, sondern auf ein abgestuftes Design aus Erkennung, schneller Traffic-Umleitung, gezielter Filterung und sauberer Betriebsorganisation. Besonders verbreitet und praxistauglich sind drei Mechanismen, die in vielen Enterprise- und Provider-Netzen zusammenwirken: Scrubbing (Traffic-Reinigung in spezialisierten Zentren), RTBH (Remotely Triggered Black Hole, gezieltes Verwerfen von Traffic) und BGP Flowspec (granulare Filterregeln über BGP). Dieser Artikel erklärt Scrubbing, RTBH und Flowspec verständlich, zeigt typische Architekturpatterns, benennt Trade-offs (Sicherheit vs. Verfügbarkeit) und gibt konkrete Hinweise, wie Sie DDoS Schutzarchitektur so umsetzen, dass sie im Ernstfall nicht nur auf dem Papier funktioniert.

DDoS-Grundlagen: Warum eine Architektur nötig ist

DDoS ist kein einzelner Angriffstyp, sondern ein Spektrum an Techniken, die gemeinsam ein Ziel verfolgen: Ressourcen erschöpfen. Das kann Bandbreite sein (volumetrische Angriffe), Zustände in Geräten (State Exhaustion) oder CPU/Threads in Anwendungen (Layer-7-Überlast). Die wichtigste Konsequenz für das Design: Je nach Vektor greift eine andere Schutzmaßnahme, und der beste Schutzpunkt ist nicht immer „im eigenen Rechenzentrum“.

• Volumetrisch: UDP Floods, Amplification (DNS/NTP/CLDAP/Memcached), große Gbit/s-Raten – Ziel ist die Leitung/Upstream-Kapazität.
• Protokoll-/State-Angriffe: SYN Flood, fragmentierte Pakete, Connection-Stürme – Ziel sind Session Tables, CPS und Control Plane.
• Applikationsnah (Layer 7): HTTP Flood, Login-Bruteforce, expensive requests – Ziel sind Webserver, WAF-Regeln oder Backend-Dienste.

Eine DDoS Schutzarchitektur muss daher beantworten: Wo erkennen wir Angriffe? Wo können wir sie am schnellsten und kosteneffizientesten stoppen? Und wie vermeiden wir, dass Schutzmaßnahmen selbst zum Ausfall führen?

Architekturprinzip: Defense-in-Depth für DDoS

Im DDoS-Kontext bedeutet Defense-in-Depth: mehrere Schutzschichten an unterschiedlichen Punkten im Netz. Typischerweise besteht eine reife Architektur aus:

• Edge-Controls: Anti-Spoofing, BGP-Filter, Rate Limits, Basis-ACLs am Provider-/Internet-Edge.
• Upstream-Schutz: Scrubbing via Provider oder spezialisierten DDoS-Partner, um Volumen vor dem eigenen Anschluss zu reduzieren.
• In-Path Filtering: RTBH für Notfälle, Flowspec für präzisere Drops/Policer, ggf. in mehreren Ebenen.
• Application Controls: WAF, Bot-Management, Caching/CDN, App-Rate-Limits, Auth-Controls.
• Operational Readiness: Runbooks, klare Verantwortlichkeiten, getestete Umleitungspfade, Monitoring und Nachweise.

Scrubbing erklärt: Traffic-Reinigung außerhalb Ihrer Leitung

Scrubbing bedeutet, dass der angegriffene Traffic zu einem Scrubbing Center umgeleitet wird. Dort wird „schlechter“ Traffic herausgefiltert, und nur „guter“ Traffic wird zu Ihrem Service weitergeleitet. Der entscheidende Vorteil: Volumen wird bereits vor Ihrem Internetanschluss reduziert. Das ist bei großen Amplification-Angriffen oft die einzige realistische Option, weil lokale Firewalls zwar filtern könnten, die Leitung aber längst gesättigt ist.

Scrubbing-Modelle

• Always-on: Der Traffic läuft dauerhaft über den Scrubbing/Protection-Dienst (z. B. via Anycast/CDN oder permanente GRE/IPsec-Tunnel). Vorteil: schnellste Reaktion, weniger Umleitungsrisiko. Nachteil: Dauerhafte Abhängigkeit, potenziell mehr Latenz und Kosten.
• On-demand: Scrubbing wird bei Angriffen aktiviert, meist per BGP-Ankündigung (Traffic wird zum Scrubber gezogen). Vorteil: normaler Betrieb ohne Umweg. Nachteil: Aktivierungszeit, BGP-Konvergenz, Risiko von Fehlkonfiguration.
• Hybrid: Kritische Dienste always-on (z. B. Web über CDN/WAF), andere on-demand (z. B. APIs, spezielle TCP-Services).

Scrubbing-Design: Was wirklich wichtig ist

• Klare Umleitungsmechanik: BGP-Ankündigung Ihrer Präfixe zum Scrubber oder DNS/Anycast-Steuerung – mit dokumentierten Präferenzregeln.
• Saubere Rückführung: Gereinigter Traffic muss zuverlässig zurück zu Ihren Origins (z. B. GRE-Tunnel, private Interconnects, MPLS, IPsec).
• Kapazität und SLA: Scrubbing muss größer sein als erwartete Angriffsspitzen; auch Rückführungskapazität zählt.
• Erkennung und Trigger: Wann wird umgeleitet? Automatisch (Thresholds) oder manuell (NOC/SOC)?
• Whitelist-Strategie: Bei on-demand muss klar sein, welche legitimen Protokolle/Ports im Scrubber erlaubt sind, sonst filtern Sie sich selbst weg.

RTBH erklärt: Remotely Triggered Black Hole als Notbremse

RTBH (Remotely Triggered Black Hole) ist eine DDoS-Gegenmaßnahme, bei der Traffic zu einem Zielpräfix oder einer Ziel-IP gezielt verworfen wird. Der Sinn ist nicht „Service retten“, sondern „Netz stabil halten“, wenn die Alternative ein kompletter Kollaps der Leitung oder der Edge-Infrastruktur wäre. RTBH ist damit die Notbremse, die Sie bewusst und kontrolliert einsetzen sollten.

Wie RTBH technisch funktioniert

Im Kern basiert RTBH auf BGP: Sie announcen eine Route (meist ein Hostroute-Präfix, z. B. /32 bei IPv4 oder /128 bei IPv6) mit einem Next-Hop oder einer Community, die im Netz als „blackhole“ interpretiert wird. Upstream oder Ihre eigenen Router leiten Traffic dann in ein Null-Interface oder verwerfen ihn in Hardware. Das verhindert, dass Angriffstraffic weiter Ihre Infrastruktur belastet.

• Vorteil: Sehr schnell, sehr effektiv gegen volumetrische Attacken auf ein einzelnes Ziel.
• Nachteil: Das Ziel ist offline (Collateral Damage ist beabsichtigt, aber kontrolliert).
• Typischer Einsatz: Einzelne angegriffene VIPs, nicht ganze Services, wenn das Geschäftsrisiko akzeptabel ist.

Als Referenz für Blackhole-Communities und Operationalisierung ist RFC 7999 hilfreich.

RTBH Best Practices

• Nur autorisierte Trigger: RTBH darf nur von klar definierten Systemen/Teams ausgelöst werden (z. B. DDoS-Controller oder NOC-Accounts), niemals „jeder Router“.
• Scope minimieren: Bevorzugt Hostroutes statt große Präfixe, um Kollateralschäden zu begrenzen.
• Expiry/Timeout: Blackholes müssen automatisch oder prozessual wieder entfernt werden; keine „vergessenen“ Drops.
• Logging und Nachweise: Wer hat wann welches Ziel geblackholed und warum? Das gehört in ein Ticket/Incident.
• Vorab-Test: RTBH im Nicht-Produktivfenster testen, inklusive Rückbau und Monitoring.

BGP Flowspec erklärt: Granulare Filterregeln über BGP

BGP Flowspec (Flow Specification) erweitert BGP um die Fähigkeit, Traffic-Filterregeln zu verteilen: nicht nur „Route zu Präfix“, sondern „Traffic, der auf bestimmte Header-Merkmale passt, wird gedroppt oder rate-limited“. Das ist besonders wertvoll, wenn Sie nicht gleich den ganzen Host blackholen wollen, sondern gezielt einen Angriffsvektor stoppen möchten, z. B. UDP/53 Flood, TCP SYN Flood auf einen Port, oder bestimmte Fragmente.

Was Flowspec matchen kann

• Destination Prefix: Zielnetz oder Host (z. B. /32).
• Source Prefix: optional, z. B. wenn ein Angriff aus einem klaren Bereich kommt (mit Vorsicht).
• Protokoll: TCP/UDP/ICMP.
• Ports: Zielport, Quellport, Portbereiche.
• TCP Flags: z. B. SYN-only Muster.
• Fragmentation und Packet Length: nützlich gegen bestimmte Flood-Profile.

Die normative Referenz für Flowspec ist RFC 8955 (IPv4 Flowspec; für IPv6 existiert ein entsprechendes Dokument).

Flowspec Actions: Drop, Rate-Limit, Marking

• Traffic-rate (Policer): Begrenzen statt komplett verwerfen – hilfreich, wenn etwas legitimer Traffic durchkommen soll.
• Traffic-action (Drop): Harte Abwehr gegen klar bösartigen Traffic.
• Redirect: In manchen Designs kann Traffic umgeleitet werden (z. B. zu Scrubbing oder Analyse), je nach Plattform.

Flowspec Best Practices in der Praxis

• Scope eng halten: Regeln auf konkrete Ziele und Ports beschränken. „Zu breite“ Flowspec-Regeln können selbst Ausfälle verursachen.
• Change Control: Flowspec ist mächtig wie eine ACL im Backbone. Regeln müssen versioniert, geloggt und zeitlich begrenzt sein.
• Validation: Nur autorisierte Controller dürfen Flowspec announcen; auf Routern sollten Policies festlegen, welche Regeln akzeptiert werden.
• Monitoring: Erfolg messen (Drops/Policer Hits, Latenz, Service-Health) und Regeln nach Ende des Angriffs entfernen.

Scrubbing vs. RTBH vs. Flowspec: Wann gewinnt welches Werkzeug?

In einer sauberen DDoS Schutzarchitektur haben alle drei Werkzeuge ihren Platz, aber mit unterschiedlichen „Zielen“.

• Scrubbing: Beste Wahl bei volumetrischen Angriffen, die Ihre Leitung sättigen, oder bei komplexen Multi-Vektor-Angriffen, die lokale Geräte überfordern würden.
• RTBH: Beste Wahl als Notbremse, wenn ein einzelnes Ziel das Netz gefährdet und kurzfristig geopfert werden kann.
• Flowspec: Beste Wahl für gezielte Mitigation, wenn Sie Traffic selektiv droppen oder limitieren wollen, ohne den Service komplett zu verlieren.

In vielen reifen Umgebungen sieht der Ablauf so aus: Frühphase mit Flowspec-Policern, Eskalation zu Scrubbing bei Volumen, und RTBH nur als letzter Schritt, wenn ein Ziel sonst die gesamte Edge-Stabilität gefährdet.

Erkennung und Trigger: Ohne saubere Signale bringt die beste Architektur wenig

DDoS-Maßnahmen müssen schnell ausgelöst werden, sonst ist die Auswirkung bereits eingetreten. Dafür braucht es Erkennung auf mehreren Ebenen:

• NetFlow/IPFIX: Volumen, PPS (Packets per Second), Top Talkers, Protokollverteilungen.
• Interface Telemetrie: Auslastung, Drops, Errors, Queue-Overruns an Edge/Peering-Links.
• Firewall/Load Balancer KPIs: CPS, SYN-Backlog, Session Table Utilization, TLS Handshake Errors.
• Application Metrics: HTTP 5xx, Latenz, Queue-Längen, Thread-Pools, Datenbank-Timeouts.

Best Practice ist, Trigger nicht nur auf „Bandbreite“ zu setzen, sondern auch auf PPS und CPS. Ein SYN Flood kann Ihre Infrastruktur töten, obwohl die Bandbreite niedrig wirkt.

Fail-Safe Design: Schutzmaßnahmen dürfen nicht schlimmer sein als der Angriff

Eine häufige operative Falle ist, dass Mitigation-Regeln zu breit sind oder zu lange aktiv bleiben. DDoS Schutzarchitektur braucht deshalb Guardrails:

• Timeboxing: Flowspec- und RTBH-Maßnahmen haben standardmäßig eine Ablaufzeit.
• Blast Radius Control: Regeln sind so präzise wie möglich (Zielhost statt /24; Port statt „all“).
• Approval Paths: Automatische Maßnahmen nur bis zu einer bestimmten Schwelle; Eskalationen erfordern Freigabe.
• Rollback Runbook: Entfernen der Maßnahmen ist genauso wichtig wie das Setzen.

DDoS und BGP Security: Filter, RPKI und Anti-Spoofing sind Teil der Schutzarchitektur

Scrubbing, RTBH und Flowspec wirken deutlich besser, wenn Ihre Edge-BGP-Policies sauber sind. Sonst riskieren Sie Route Leaks oder unbeabsichtigte Umleitungen. Ebenso reduziert Anti-Spoofing (BCP38) die Möglichkeit, dass Ihr Netz selbst als Amplification-Quelle missbraucht wird.

• Prefix Filter: Nur erwartete Prefixes von Nachbarn akzeptieren und announcen.
• RPKI/ROV: Schutz gegen Origin Hijacks, damit Mitigation nicht durch falsche Routen sabotiert wird.
• BCP38/uRPF: Source Address Validation reduziert Spoofing-basierten Missbrauch.

Für RPKI/ROV ist RFC 6811 eine gute Referenz, und für Anti-Spoofing das Grunddokument BCP 38.

Operational Readiness: Runbooks, Rollen und Übungen

Eine DDoS Schutzarchitektur ist nur so gut wie ihre Bedienbarkeit. In der Praxis sind Angriffe oft außerhalb der Kernarbeitszeit, und die ersten Minuten entscheiden. Deshalb braucht es klare Runbooks und Rollen:

• Rollen: Wer entscheidet über Scrubbing-Aktivierung? Wer darf Flowspec/RTBH announcen? Wer kommuniziert mit dem Provider?
• Runbooks: Schrittfolgen für „Volumenangriff“, „SYN Flood“, „HTTP Flood“, inklusive Monitoring-Checks und Rollback.
• Kontaktketten: Provider NOC, DDoS-Partner, interne App-Owner, Incident Commander.
• Übungen: Geplante Tests (Tabletop + technische Drills) für RTBH/Flowspec/Scrubbing, damit Bedienfehler im Ernstfall minimiert werden.

Dokumentation und Nachweise: Evidence-by-Design für DDoS-Maßnahmen

DDoS-Ereignisse sind häufig audit- und compliance-relevant, spätestens wenn Kunden betroffen sind oder SLA-Verletzungen auftreten. Eine saubere Dokumentation hilft auch bei Postmortems und Verbesserungen.

• Incident Timeline: Erkennung, Maßnahmen, Änderungen, Rückbau.
• Technische Parameter: Angriffsvektoren, Peak-Bandbreite/PPS, Top Targets, Mitigation-Regeln.
• Wirksamkeit: Welche Maßnahme hat welchen Effekt gehabt (Drops, Policer Hits, Stabilisierung der KPIs)?
• Lessons Learned: Welche Filterlisten, Thresholds oder Runbooks müssen angepasst werden?

Als Prozessrahmen für auditierbare Verantwortlichkeiten kann ISO/IEC 27001 dienen; für operative Kontrollen zu Monitoring und Change Management sind die CIS Controls hilfreich.

Typische Stolpersteine und robuste Gegenmaßnahmen

• RTBH zu großzügig eingesetzt: Gegenmaßnahme: Hostroute-Blackholes, striktes Timeboxing, Freigabeprozess für große Präfixe.
• Flowspec ohne Validation: Gegenmaßnahme: nur signierte/autorisiert akzeptierte Flowspec-Sources, Policy-Filter für zulässige Matches.
• Scrubbing ohne Rückführungskapazität: Gegenmaßnahme: Tunnel/Interconnect dimensionieren, Rückweg testen, MTU/MSS berücksichtigen.
• Trigger nur auf Bandbreite: Gegenmaßnahme: PPS/CPS/Session KPIs ergänzen, weil viele State-Angriffe wenig Bandbreite brauchen.
• Kein Rollback-Plan: Gegenmaßnahme: Runbooks mit „Remove Rules“-Schritten und klaren Ownerships.

Praktische Checkliste: DDoS Schutzarchitektur in Enterprise-Qualität

• 1) Kritische Services klassifizieren: Welche Targets müssen always-on geschützt werden, welche können im Notfall geblackholed werden?
• 2) Scrubbing-Option festlegen: Always-on, On-demand oder Hybrid; Rückführung testen und dokumentieren.
• 3) RTBH als Notbremse implementieren: Autorisierte Trigger, Hostroutes, Expiry, Logging, regelmäßige Drills.
• 4) Flowspec kontrolliert einführen: Validierung, erlaubte Match-Templates, Timeboxing, Monitoring der Wirksamkeit.
• 5) Detection aufbauen: NetFlow/IPFIX, Edge-Telemetrie, CPS/Session KPIs, App-Metriken.
• 6) BGP/Edge-Hygiene: Prefix Filter, RPKI/ROV, Max-Prefix, Anti-Spoofing (BCP38).
• 7) Runbooks und Rollen: Incident Commander, NOC/SOC, Provider-Kontakte, App-Owner – inklusive 24/7 Bereitschaft.
• 8) Üben und verbessern: Tabletop + technische Tests, Postmortems, kontinuierliches Tuning.

Outbound-Quellen für Standards und Vertiefung

• RFC 4271 (BGP-4) für die BGP-Grundlagen, auf denen RTBH und Flowspec aufsetzen.
• RFC 7999 für Blackholing per BGP Community (RTBH-Referenz).
• RFC 8955 für BGP Flowspec (IPv4) und die Logik von Flow-Matches und Actions.
• RFC 6811 für RPKI Route Origin Validation als Ergänzung zur Edge-Security.
• BCP 38 (Network Ingress Filtering) für Anti-Spoofing als grundlegende DDoS-Minderung gegen Spoofing-basierte Amplification.

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.