RTBH & Flowspec Baseline: Routing-basierte DDoS Abwehr im Telco-Netz

Eine saubere RTBH & Flowspec Baseline ist im Telco-Netz eine der wirkungsvollsten Methoden, DDoS-Angriffe schnell und skalierbar zu dämpfen – direkt über Routing-Mechanismen, bevor Firewalls, Load Balancer oder Services selbst zum Engpass werden. RTBH (Remote Triggered Black Hole) und BGP FlowSpec sind routing-basierte Abwehrwerkzeuge, die im Provider-Umfeld besonders gut passen: Sie sind schnell aktivierbar, lassen sich netzweit ausrollen und können in Incident-Playbooks standardisiert werden. Gleichzeitig sind sie hochriskant, wenn sie ohne Guardrails betrieben werden: Ein falsch gesetzter Blackhole-Trigger kann legitimen Traffic großflächig „wegwerfen“, FlowSpec-Regeln können CPU/TCAM-Ressourcen belasten oder – bei falscher Governance – als Missbrauchsvektor dienen. Eine professionelle Baseline definiert deshalb klare Aktivierungskriterien, sichere Policy-Templates, Authentisierung und Scope-Kontrollen, Observability sowie ein kontrolliertes Rollback. Dieser Artikel erklärt, wie Telcos RTBH und FlowSpec korrekt einsetzen, welche Architektur- und Policy-Entscheidungen notwendig sind und wie man routing-basierte DDoS-Abwehr mit Scrubbing, Firewalls und SOC/NOC-Prozessen sauber koordiniert.

Warum routing-basierte DDoS-Abwehr im Carrier-Netz so gut funktioniert

DDoS-Lagen sind im Telco-Umfeld häufig nicht nur ein Bandbreitenproblem, sondern ein Ressourcenproblem entlang der Kette: Links, Edge-Router, Session Tables, pps-Queues, Logging-Pipelines und stateful Firewalls können überlasten. RTBH und FlowSpec wirken dort, wo es am meisten bringt: auf der Routing-Ebene. Das bedeutet:

• Frühe Abwehr: Traffic wird vor nachgelagerten Systemen verworfen oder gedrosselt.
• Schnelle Reaktion: BGP-basierte Signale lassen sich in Sekunden bis Minuten netzweit ausrollen.
• Skalierung: statt viele einzelne Firewalls zu konfigurieren, wirkt eine zentrale Trigger-Policy über das Routing.
• Failure Domains: gezielte Maßnahmen pro Präfix, pro Ziel, pro POP/Region sind möglich.

Damit das zuverlässig und sicher funktioniert, müssen RTBH/FlowSpec Teil einer Baseline sein – nicht „ein Trick im Notfall“.

RTBH vs. FlowSpec: Was wofür gedacht ist

Obwohl beide BGP nutzen, lösen sie unterschiedliche Aufgaben. Eine Baseline sollte diese Trennung klar machen, sonst wird FlowSpec als „Blackhole 2.0“ missverstanden oder RTBH zu oft eingesetzt.

• RTBH: „harte Kante“ – Traffic zu einem Ziel (oder Präfix) wird verworfen (Blackhole), häufig an Edge-Routern oder upstream. Sehr effektiv bei volumetrischen Angriffen, aber mit hohem Kollateralschaden, wenn zu breit.
• FlowSpec: „feingranulare Steuerung“ – matcht Flows (z. B. dst-prefix + protocol + port) und setzt Aktionen (drop, rate-limit, redirect in Scrubbing), je nach Plattform. Ideal gegen spezifische Vektoren, kann aber komplex und ressourcenintensiv sein.

Ein praxistaugliches Telco-Prinzip lautet: RTBH für „Schutz der Infrastruktur“ und Notbremsen, FlowSpec für präzise Mitigation, wenn der Service weiterhin erreichbar bleiben soll.

Baseline-Ziele: Sicherheit, Geschwindigkeit und Missbrauchsschutz

RTBH und FlowSpec sind mächtig. Eine Baseline muss daher nicht nur technische Defaults definieren, sondern auch Missbrauch verhindern. Die wichtigsten Ziele sind:

• Minimierter Blast Radius: Maßnahmen wirken so eng wie möglich (präziser Scope, befristet, reviewbar).
• Kontrollierte Aktivierung: nur autorisierte Systeme/Teams dürfen Trigger setzen (PAM/JIT, RBAC).
• Verlässliches Rollback: schnelle Rücknahme ohne Nebenwirkungen, inklusive „Proof of Calm“.
• Beobachtbarkeit: jede Trigger-Aktion ist im NOC/SOC sichtbar (Logs, Telemetrie, Nachweise).
• Interoperabilität: Zusammenspiel mit Scrubbing, Firewalls, Customer Edge Policies und Peering-Regeln.

Architektur für RTBH: Trigger-Pfade, Blackhole-Next-Hop und Scope

RTBH funktioniert typischerweise, indem ein spezieller Next-Hop (oder eine spezielle Community) im Netz signalisiert: „Dieses Präfix blackholen.“ Die Umsetzung variiert je nach Provider-Design, aber die Baseline sollte stets definieren:

• Trigger-Quelle: welches System setzt RTBH (DDoS-Plattform, NOC-Tool, Scrubber-Controller)?
• Propagation: wie weit darf RTBH propagiert werden (nur innerhalb AS, bis Upstream, bis Peers)?
• Blackhole-Ort: wo wird gedroppt (Edge, Aggregation, Scrubbing-Edge) – je früher, desto besser für Infrastruktur.
• Scope-Regeln: welche Präfixlängen sind erlaubt (z. B. nur /32 oder /128 für Host-Blackhole, oder definierte Präfix-Grenzen)?

Telco-taugliche RTBH-Baselines bevorzugen häufig Host-Blackholing (sehr spezifisch), statt ganze Kundennetze zu blackholen. Wenn großflächiges Präfix-Blackhole nötig ist, muss es als High-Risk-Action behandelt werden.

RTBH Guardrails: Damit Blackhole kein Self-DoS wird

Der größte RTBH-Fail ist nicht, dass es „nicht wirkt“, sondern dass es zu breit wirkt. Eine Baseline sollte deshalb harte Guardrails enthalten.

Empfohlene RTBH-Guardrails

• Prefix-Length Limits: nur definierte Präfixlängen zulassen (z. B. /32 für IPv4, /128 für IPv6) – Ausnahmen nur per High-Risk-Freigabe.
• Allow-List für Ziele: nur Präfixe, die im eigenen Netz/bei Kunden legitim sind, dürfen getriggert werden (kein beliebiges Internet-Ziel).
• Timeboxing: RTBH-Trigger automatisch mit Ablaufdatum, Rezertifizierungspflicht.
• Rate-Limit für Trigger: Begrenzung, wie viele RTBH-Routen pro Zeit gesetzt werden dürfen, um Fehlbedienung zu begrenzen.
• Two-Person Control: für große Präfixe oder kritische Services (Vier-Augen-Prinzip).

Zusätzlich sollte jeder RTBH-Trigger automatisch dokumentiert werden (Ticket/Incident-ID, Owner, Zeitpunkt, Ziel, Grund).

FlowSpec Grundlagen: Matching, Actions und Ressourcen

BGP FlowSpec (Flowspec) ermöglicht die Verteilung von Flow-Regeln über BGP. Eine Regel kann z. B. ein Zielpräfix, Protokoll, Port und weitere Kriterien matchen und dann eine Aktion auslösen. Genau hier liegt die Stärke – und das Risiko: FlowSpec kann sehr präzise sein, aber viele Regeln oder komplexe Matches können Router-Ressourcen belasten (TCAM, CPU, Policy Engines).

Typische FlowSpec Actions im Provider-Betrieb

• Drop: verwirft Traffic, ähnlich RTBH, aber präziser nach L4-Merkmalen.
• Rate Limit: drosselt Traffic auf definierte Raten, um Services am Leben zu halten.
• Redirect: leitet Traffic in Scrubbing/Filterpfade um (architekturabhängig).
• Marking: setzt Markierungen für QoS/Policy (wenn unterstützt und sinnvoll).

Eine Baseline sollte klar festlegen, welche Actions erlaubt sind und in welchen Zonen/Edges sie eingesetzt werden dürfen.

FlowSpec Baseline: Scope, Templates und sichere Defaults

FlowSpec darf in Telco-Netzen nie „frei“ sein. Eine Baseline definiert sichere Defaults, die Missbrauch verhindern und Betriebsrisiken minimieren.

Scope-Guardrails für FlowSpec

• Nur definierte Zielpräfixe: FlowSpec-Regeln dürfen nur auf own/customer Prefixes zielen (Allow-List), nicht auf beliebige Internet-Ziele.
• Max Rules: harte Obergrenze pro Router/Region/Controller, um Ressourcen zu schützen.
• Prefix-Length Constraints: z. B. keine zu breiten Ziele ohne High-Risk-Freigabe.
• Port/Protocol Whitelist: erlaubte Match-Kombinationen pro Serviceklasse (DNS, NTP, Web, Gaming, VoIP).
• Timeboxing: jede Regel hat TTL/Ablaufdatum, automatische Cleanup-Jobs.

Template-Ansatz: „Mitigation Profiles“ statt Einzelregeln

• DNS Reflection Profile: UDP/53 spezifisch, rate-limit oder drop nach Muster, bevorzugt nahe Edge.
• NTP Abuse Profile: UDP/123, striktere Limits, klare Ausnahmen für legitime Quellen.
• SYN Flood Profile: TCP/SYN nach dst, rate-limit/connection-limit, kombiniert mit Edge-SYN-Protection.
• HTTP Request Flood Profile: eher WAF/API-Gateway als FlowSpec; FlowSpec nur als ergänzende L4-Drossel.

Templates machen Maßnahmen schneller, konsistenter und reviewbar – und sie reduzieren die Gefahr von „einmaligen“ Sonderregeln, die später vergessen werden.

Koordination mit Scrubbing und Firewalls: Wer macht welche Arbeit?

RTBH und FlowSpec sind keine Konkurrenz zu Scrubbing und Firewalls, sondern ergänzen sie. Ein robustes Telco-Design weist jeder Schicht klare Aufgaben zu:

• RTBH: Notbremse zum Schutz der Infrastruktur oder wenn ein Service temporär geopfert werden muss, um das Netz zu schützen.
• FlowSpec: präzise Mitigation, um Services möglichst online zu halten und Angriffsvektoren gezielt zu dämpfen.
• Scrubbing: volumetrische Reinigung und komplexe Filterung außerhalb stateful Firewalls.
• Firewalls: Zonen-/Trust-Boundary-Policies, Outbound-Kontrolle, Segmentierung, Logging/Forensik.

In der Baseline sollte festgelegt sein, wann man von FlowSpec zu Scrubbing eskaliert (z. B. wenn pps/CPS trotz Rate-Limits zu hoch bleibt) und wann RTBH als „Last Resort“ genutzt wird.

Governance: Wer darf triggern – und wie wird Missbrauch verhindert?

Routing-basierte Mitigation ist mächtig genug, um als Angriffsvektor zu dienen, wenn sie schlecht abgesichert ist. Deshalb ist Governance Teil der technischen Baseline.

Governance-Bausteine, die in Telcos funktionieren

• RBAC/JIT: Trigger-Rechte nur für definierte Rollen, zeitlich begrenzt, über PAM.
• Source of Truth: Trigger werden aus einem kontrollierten System heraus gesetzt, nicht aus ad hoc Router-CLI.
• Approval für High-Risk: große Präfixe, Interconnect-nahe Maßnahmen oder globale Policies mit Vier-Augen-Prinzip.
• Audit Logging: jeder Trigger, jede Änderung, jede Rücknahme wird protokolliert (inkl. Owner, Ticket, TTL).
• Rezertifizierung: regelmäßige Prüfung von Templates, Limits und Ausnahmen.

Observability: RTBH/FlowSpec muss sichtbar und messbar sein

Eine Baseline ist nur so gut wie ihre Beobachtbarkeit. Für RTBH und FlowSpec sollten Telcos zwingend messen und loggen:

• Activated Rules: welche RTBH/FlowSpec-Regeln sind aktiv, mit TTL, Owner, Ziel, Match-Parametern?
• Traffic Impact: mitigated Gbps/pps, Drops, Rate-Limit-Hits, Top Talkers.
• Router Health: TCAM/Policy Ressourcen, CPU, BGP Stability, Control Plane Drops.
• Service SLOs: Erreichbarkeit/Latenz des betroffenen Services während Mitigation.
• SIEM Korrelation: Verknüpfung von Trigger-Events mit DDoS-Alerts, Firewall Drops und Scrubbing-Telemetrie.

Damit wird sichtbar, ob eine Mitigation wirkt, ob sie legitimen Traffic trifft und ob sie Routerressourcen gefährdet.

Playbooks: Aktivieren, Eskalieren, Deaktivieren

RTBH und FlowSpec sind am sichersten, wenn sie in Incident Response Playbooks eingebettet sind. Ein Telco-Playbook sollte eine klare Eskalationsleiter enthalten.

Pragmatische Eskalationslogik

• Stufe 1: FlowSpec Rate-Limit für spezifischen Vektor (z. B. UDP/53), enges Ziel, kurze TTL.
• Stufe 2: Redirect in Scrubbing oder Scrubbing-Aktivierung für das Zielpräfix, wenn volumetrisch/pps zu hoch.
• Stufe 3: RTBH Host-Blackhole, wenn Infrastruktur gefährdet ist oder Service geopfert werden muss.
• Stufe 4: größere Scopes nur mit High-Risk-Freigabe und klarer Kunden-/Servicekommunikation.

Deaktivierung (Proof of Calm)

• Traffic beruhigt: definierte Zeit ohne Peaks, stabile SLOs.
• Stufenweise Rücknahme: erst RTBH entfernen, dann FlowSpec lockern, Scrubbing zurückfahren – jeweils mit Monitoring.
• Cleanup: abgelaufene Regeln entfernen, Ausnahmen rezertifizieren, Postmortem Evidence sichern.

Typische Fehler bei RTBH/FlowSpec und wie die Baseline sie verhindert

• Zu breite Blackholes: ganze Kundennetze weg; Baseline erzwingt Prefix-Length Limits und High-Risk-Freigaben.
• FlowSpec ohne Limits: Routerressourcen kippen; Baseline setzt Max Rules und Ressourcenmonitoring.
• Trigger ohne Governance: Missbrauch möglich; Baseline nutzt RBAC/JIT, Audit Logging und Source-of-Truth.
• Keine Timeboxing: Regeln bleiben ewig; Baseline verlangt TTL/expiry und automatische Cleanup-Jobs.
• Fehlende Observability: Wirkung unklar; Baseline fordert Traffic Impact, Router Health und Service SLOs.
• Keine Koordination mit Scrubbing/Firewalls: Double Mitigation oder Lücken; Baseline definiert klare Layer-Verantwortung.

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.