RTBH und Flowspec: DDoS-Baseline für BGP-basierte Abwehr

RTBH und Flowspec gehören zu den wichtigsten Werkzeugen, wenn Provider und große Netzbetreiber DDoS-Angriffe schnell und netzwerknah abwehren müssen. Beide Verfahren sind BGP-basiert und zielen darauf ab, schädlichen Traffic so früh wie möglich zu stoppen oder gezielt zu filtern – idealerweise bevor Links überlaufen, State-Tabellen kollabieren oder Downstream-Systeme in die Knie gehen. Im Telco- und ISP-Umfeld ist Geschwindigkeit entscheidend: Minuten können über SLA-Verletzungen, Kundenausfälle und massive Folgeeffekte entscheiden. Gleichzeitig ist BGP ein sensibles Steuerinstrument; falsch gesetzte Policies können mehr Schaden anrichten als der Angriff selbst. Genau deshalb braucht es eine klare DDoS-Baseline für BGP-basierte Abwehr: definierte Trigger, saubere Route-Policies, Guardrails gegen Fehlannouncements, standardisierte Communities, klare Ownership und einen disziplinierten Rückbau. Dieser Artikel erklärt verständlich, wie RTBH (Remote Triggered Black Hole) und BGP Flowspec funktionieren, worin sie sich unterscheiden und wie Sie beide als robuste, auditierbare Baseline in Provider-Netzen einsetzen, ohne Betriebsrisiken zu erhöhen.

Warum BGP-basierte DDoS-Abwehr im Provider-Design so wirksam ist

Viele DDoS-Probleme entstehen nicht in der Applikation, sondern im Netz: Links werden voll, Router-Queues laufen über, Paketverluste steigen, und selbst legitimer Traffic kommt nicht mehr durch. BGP-basierte Verfahren setzen genau dort an, wo der Schaden entsteht – an der Routing- und Weiterleitungsebene. Statt erst hinter Firewalls, Load Balancern oder im Rechenzentrum zu reagieren, können Provider Traffic bereits am Edge, am Peering oder sogar upstream beeinflussen.

• Früher Stopp: Schädlicher Traffic wird vor der Überlastung verworfen oder gefiltert.
• Skalierung: Routing- und Forwarding-Ebenen sind auf hohe PPS und Durchsatz ausgelegt.
• Granularität: Flowspec kann präzise auf Protokolle, Ports und weitere Header-Merkmale zielen.
• Automationsfähigkeit: Trigger lassen sich standardisieren und in Playbooks integrieren.
• Komplementär: RTBH und Flowspec ergänzen Scrubbing, WAF und API-Gateway-Limits.

Begriffe und Grundkonzepte: RTBH vs. Flowspec

RTBH (Remote Triggered Black Hole) ist das „grobe, schnelle“ Werkzeug: Es sorgt dafür, dass Traffic zu einem Zielpräfix (häufig ein Host- oder /32-/128-Präfix, manchmal ein kleineres Subnetz) verworfen wird. Das kann lokal im eigenen Netz (intra-AS) oder in Kooperation mit Upstreams passieren. Flowspec ist das „präzise, flexible“ Werkzeug: Statt ganze Ziele zu nullrouten, verteilt Flowspec Filterregeln über BGP, die z. B. nur UDP/53 zu einem Ziel oder nur TCP-SYNs auf einen Port begrenzen oder droppen.

• RTBH: Ziel wird (teilweise) unreachbar gemacht, dafür extrem schnell und einfach.
• Flowspec: gezielte Filterung, weniger Kollateralschaden, aber höhere Komplexität.
• Beide brauchen Guardrails: strikte Policies, Scope-Begrenzung und sauberes Monitoring.

RTBH als Baseline: Wann Blackholing sinnvoll ist (und wann nicht)

RTBH ist besonders nützlich, wenn ein Angriff so groß ist, dass Scrubbing nicht rechtzeitig greift oder die Anbindung unmittelbar gefährdet ist. Es ist außerdem sinnvoll, wenn das Ziel ohnehin „opferbar“ ist, etwa ein einzelnes angegriffenes IP-Ziel ohne kritische Abhängigkeiten, oder wenn ein kurzfristiger Ausfall besser ist als ein flächendeckender Impact. In Telco- und Provider-Umgebungen ist RTBH oft der erste Notnagel – aber er muss kontrolliert eingesetzt werden.

• Geeignet: sehr große volumetrische Angriffe, schnelle Stabilisierung der Infrastruktur.
• Geeignet: einzelne Ziele/Hosts, die den Backbone gefährden oder einen regionalen Engpass erzeugen.
• Weniger geeignet: kritische Plattformdienste (z. B. DNS, Auth, zentrale Portale), bei denen „Down“ nicht akzeptabel ist.
• Weniger geeignet: wenn nur ein bestimmter Port/Protokoll-Vektor stört – hier ist Flowspec oft besser.

Baseline-Regel: RTBH nur für eng definierte Präfixe

Eine der wichtigsten Baseline-Regeln lautet: Blackholing darf niemals „breit“ sein. In der Praxis bedeutet das, dass RTBH idealerweise für Host-Routen (IPv4 /32, IPv6 /128) oder sehr kleine, klar dokumentierte Präfixe genutzt wird. Große Netze zu blackholen kann massive Kollateralschäden verursachen.

RTBH-Mechanik: Wie die Umleitung technisch funktioniert

RTBH nutzt BGP, um eine Route zu einem Zielpräfix so zu markieren oder so anzukündigen, dass Router im Forwarding diesen Traffic in ein Null-Interface (Discard) schicken. Typischerweise wird dafür eine spezielle Community verwendet, die auf Edge-Routern eine Routing-Policy triggert: „Wenn Community X, dann next-hop auf Null setzen“ oder „Route in spezielle Blackhole-VRF leiten“. Viele Provider nutzen dafür standardisierte BGP Communities (z. B. interne Blackhole-Communities oder Upstream-spezifische Blackhole-Communities).

• Intra-AS RTBH: Blackholing innerhalb des eigenen Netzes, schnelle Stabilisierung der eigenen Infrastruktur.
• Upstream RTBH: Blackholing beim Transitprovider, um Bandbreite schon vor dem eigenen Edge zu sparen.
• Community-gesteuert: Policies entscheiden, wo und wie Blackholing greift.
• Scope-Kontrolle: z. B. nur in bestimmten PoPs, Regionen oder Edge-Gruppen anwenden.

Flowspec als Baseline: Präzise Filterung ohne Total-Ausfall

BGP Flowspec ermöglicht es, Filterregeln über BGP zu verteilen, die anhand von Traffic-Merkmalen matchen: Zielpräfix, Quellpräfix, Protokoll, Ports, TCP-Flags und weitere Kriterien. Die Aktion kann je nach Plattform Drop, Rate Limit, Marking oder Redirect sein. Für DDoS-Baselines ist Flowspec besonders attraktiv, weil es Kollateralschäden reduzieren kann: Statt ein Ziel komplett unreachbar zu machen, filtern Sie nur den Angriffsvektor.

• Vektor-spezifisch: z. B. nur UDP/53 zum Ziel droppen, nicht den gesamten Verkehr.
• Rate Limiting möglich: legitimer Traffic bleibt teilweise durch, Attack-Noise wird gedämpft.
• Regionale Anwendung: Policies können auf bestimmte Edge-Routergruppen begrenzt werden.
• Skalierbar: schneller Rollout von Regeln über das Netz, wenn sauber automatisiert.

Baseline-Falle: Flowspec ist mächtig – und kann das Netz destabilisieren

Flowspec wirkt direkt auf Forwarding-Entscheidungen. Zu viele Regeln, zu breite Matches oder schlecht getestete Policies können CPU/TCAM-Ressourcen belasten, Convergence verlangsamen oder legitimen Traffic treffen. Eine Baseline muss deshalb Limits und Qualitätsregeln definieren: maximale Regelanzahl, erlaubte Match-Kombinationen, vordefinierte Templates und klare Gültigkeitsdauern.

Guardrails als Baseline: Schutz vor Fehlkonfigurationen und Routing-Risiken

RTBH und Flowspec sind nur dann sicher, wenn das Kontrollmodell stimmt. Eine Provider-Baseline sollte Guardrails verbindlich machen, die Fehlannouncements abfangen, Missbrauch verhindern und den Rückbau erzwingen. Dazu gehören sowohl technische Filter als auch Prozessregeln.

• Prefix-Listen und Max-Prefix: nur erlaubte Präfixe dürfen blackholed oder per Flowspec gefiltert werden.
• Policy-Linting: automatische Prüfung von Flowspec-Regeln gegen erlaubte Templates.
• RPKI/ROA-Disziplin: Ankündigungen müssen zur Routing-Policy passen; unautorisierte Routen sind zu verhindern.
• Scope-Steuerung: Regeln nur auf definierte Routergruppen/PoPs ausrollen, nicht unkontrolliert „global“.
• TTL und Auto-Rollback: Maßnahmen laufen automatisch aus, wenn sie nicht aktiv verlängert werden.
• Approval-Modelle: Standardmaßnahmen schnell, riskante Maßnahmen mit Vier-Augen-Prinzip.

Trigger-Definition: Wann RTBH, wann Flowspec, wann Scrubbing?

Eine DDoS-Baseline ist nur praxistauglich, wenn sie Entscheidungen vereinfacht. Dafür braucht es klare Trigger, die sich aus Telemetrie ableiten: Bandbreite, PPS, Session-Exhaustion, Service-KPIs. In vielen Provider-Playbooks ist die Abfolge: Flowspec für präzise Vektoren, RTBH als Notbremse, Scrubbing für große oder komplexe Angriffe. Die Baseline sollte das als Standardpfad definieren – mit Ausnahmen für kritische Dienste.

• Flowspec zuerst, wenn: der Angriff vektor-spezifisch ist (z. B. UDP auf einen Port), und legitimer Traffic geschützt werden soll.
• RTBH zuerst, wenn: der Angriff die Infrastruktur akut gefährdet und schnelle Stabilisierung wichtiger ist als Verfügbarkeit des Zielhosts.
• Scrubbing aktivieren, wenn: Volumen zu groß ist, Links überlaufen oder mehrere Vektoren gleichzeitig auftreten.
• WAF/API Limits ergänzen, wenn: L7-Angriffe oder Abuse von Login/API-Endpunkten erkennbar ist.

Operationalisierung: Templates, Automatisierung und sichere Bedienbarkeit

In großen Provider-Netzen ist es unrealistisch, dass jede Flowspec-Regel im Incident „von Hand“ entworfen wird. Eine Baseline sollte deshalb auf Templates setzen: vordefinierte Regelmuster für typische Angriffsvektoren, inklusive erlaubter Parameterbereiche. Das beschleunigt die Reaktion und reduziert Fehlkonfigurationen.

• Template-Katalog: z. B. UDP reflection Ports, SYN-Flood-Profiles, DNS-Query-Spikes, NTP/SSDP-Muster.
• Automatisierte Activation: aus Monitoring-Alerts oder SOC-Workflows heraus, mit Guardrails.
• Change-Nachweis: jede Aktivierung hat Ticket/Incident-ID, Owner, Scope und Zeitstempel.
• Auto-Expiry: Regeln laufen nach definierter Zeit aus, wenn sie nicht verlängert werden.
• Rollback-Runbook: klare Schritte für Rückbau und Validierung nach Stabilisierung.

Monitoring und Erfolgskriterien: Wie Sie Wirksamkeit messbar machen

Eine BGP-basierte Mitigation muss in Echtzeit sichtbar sein: Ist der Angriff gedämpft? Treffen wir legitimen Traffic? Ist das Netz stabil? Eine Baseline sollte Mindestmetriken definieren, die während des Incidents verfolgt werden, um Entscheidungen zu validieren und Collateral Damage zu begrenzen.

• Netzmetriken: Link Utilization, Drops, Queueing, Latency/Jitter vor/nach Maßnahme.
• Attack Metrics: Gbps/PPS vor/nach, Top Ports/Protokolle, Top Prefixes/ASNs.
• Mitigation Metrics: Rule-Hits, dropped vs. passed, Rate-Limit-Auslastung, Anzahl aktiver Regeln.
• Service KPIs: DNS RCODEs, HTTP 5xx/Timeouts, SIP Response Codes, Login Failure Rates.
• Stabilität: Router CPU/TCAM/Forwarding-Ressourcen, BGP Convergence, Control-Plane-Health.

Governance: Rezertifizierung und Cleanup – damit DDoS-Regeln nicht „ewig“ bleiben

In der Praxis bleiben DDoS-Maßnahmen oft länger aktiv als nötig, weil niemand den Rückbau priorisiert. Das führt zu versteckten Kollateralschäden, schwer erklärbaren Traffic-Mustern und langfristiger Komplexität. Eine Baseline muss deshalb Rezertifizierung und Cleanup verbindlich machen.

• TTL-Pflicht: RTBH und Flowspec-Regeln haben ein Ablaufdatum und laufen automatisch aus.
• Post-Incident Review: Bewertung der Maßnahmen, False Positives, Optimierungsbedarf.
• Template-Verbesserung: neue Erkenntnisse fließen in Standardprofile ein.
• Auditierbarkeit: wer hat wann was geschaltet, mit welchem Scope und welchem Ergebnis.

Baseline-Checkliste: RTBH und Flowspec für BGP-basierte DDoS-Abwehr

• Klare Trigger: definierte Schwellen (Gbps/PPS/State Exhaustion), wann RTBH/Flowspec/Scrubbing greift.
• RTBH-Disziplin: nur eng definierte Präfixe (idealerweise /32-/128), dokumentierte „sacrificial“ Ziele.
• Flowspec-Templates: erlaubte Regelmuster, Parametergrenzen, maximale Regelanzahl pro Scope.
• Guardrails aktiv: Prefix-Listen, Max-Prefix, Policy-Linting, Scope-Steuerung, RPKI-Disziplin.
• Automatisierung sicher: Standardmaßnahmen schnell schaltbar, riskante Änderungen mit Approval und Safety Checks.
• Observability vorhanden: Rule-Hits, dropped/passed, Netz-Health, Service-KPIs, BGP-Events korrelierbar.
• Rollback und TTL: Rückbaukriterien, Auto-Expiry, Post-Incident Review und Cleanup-Prozess.
• Ownership und Prozesse: klare Rollen (NOC/SOC), Incident-ID/Ticketpflicht, dokumentierte Eskalation.

Mit einer solchen Baseline werden RTBH und Flowspec zu verlässlichen Bausteinen einer Provider-DDoS-Strategie: RTBH als schnelle Notbremse, Flowspec als präzise, skalierbare Filterebene – jeweils mit klaren Guardrails, messbarer Wirksamkeit und einem disziplinierten Rückbau, damit die Abwehr im Alltag nicht zum Betriebsrisiko wird.

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.