Sicheres Blackhole Routing: drei Prüfpunkte im eigenen Netz

Blackholing (RTBH, auch Blackhole Routing genannt) ist der schnellste Weg, Angriffsverkehr abzuschneiden, doch das bloße Aktivieren garantiert noch nichts. Unter sicherem Blackholing verstehen wir die Prüfung einiger konkreter Punkte im Netz: Erst wenn alle erfüllt sind, können Sie sicher sein, dass der Mechanismus vollständig greift und der Angriffsverkehr nicht dort landet, wo er den größten Schaden anrichtet.

Dieser Artikel zeigt zunächst, worauf Blackholing beruht, dann, an welchen Stellen es am häufigsten versagt, und schließlich, wie Sie jedes dieser Probleme nacheinander beseitigen.

Wie Blackhole Routing abläuft, Punkt für Punkt

1. Das Erkennungssystem identifiziert einen volumetrischen Angriff auf eine bestimmte Adresse in Ihrem Netz.
2. Die WanGuard-Konsole kündigt diese Adresse als Präfix (/32 bei IPv4) über eine BGP-Session an.
3. Das Präfix wird mit einer BGP-Community (z. B. 5617:666) markiert, an der der Upstream-Provider erkennt, dass es sich um ein BGP-Blackhole (RTBH) handelt.
4. Ihre Transit-Provider sehen diese BGP-Community und verwerfen den Verkehr zu dieser Adresse bereits bei sich, also bevor er Ihr Netz erreicht.
5. Ihr eigener Edge-Router verwirft, was trotzdem noch ankommt, sofern lokales RTBH eingerichtet ist.

Drei Prüfpunkte

Prüfen Sie die folgenden drei Bedingungen genau in dieser Reihenfolge; jede ist erst sinnvoll, wenn die vorherige erfüllt ist.

Punkt 1. Vollständiger Satz an BGP-Communities bei der Ankündigung

Dies ist die wichtigste Bedingung und zugleich die am häufigsten übersehene. Bei der Ankündigung eines Blackhole-Präfixes müssen alle BGP-Communities angehängt werden, die Ihre Provider und Ihre Peering-Partner verwenden. Jeder Betreiber hat eine eigene BGP-Community zur Signalisierung eines Blackholes und beachtet ausschließlich diese: Neben der Standard-Community 65535:666 sind netzspezifische Werte weiterhin verbreitet.

Die Folge ist eindeutig: Fehlt in der Ankündigung die BGP-Community eines Providers, verwirft dieser Provider den Verkehr nicht, und das gesamte Angriffsvolumen läuft über seine Leitung ein, obwohl die übrigen Provider korrekt reagiert haben. Blackholing wirkt dann „aktiv, aber wirkungslos“, während die Ursache allein in der fehlenden BGP-Community liegt.

Sobald der vollständige Satz an BGP-Communities abgedeckt ist, erreicht der Verkehr zur angegriffenen Adresse Ihr Netz nicht mehr. Beachten Sie jedoch, dass von Internetknoten (IXPs) noch ein Rest ankommen kann: Dort verhält sich Blackholing nicht immer wie auf Transitleitungen, weil manche Peering-Partner Blackhole-Communities gar nicht beachten oder eigene, abweichende Regeln anwenden. Genau deshalb sind die Punkte zwei und drei erforderlich.

Punkt 2. Der Next-Hop darf nicht auf die WanGuard-Konsole zeigen

In BGP trägt jedes Präfix das Attribut Next-Hop, das angibt, über welche nächste IP-Adresse das jeweilige Netz erreichbar ist. Ein Blackhole-Präfix erreicht den Router von der WanGuard-Konsole, daher zeigt sein Next-Hop standardmäßig auf die Adresse der Konsole.

Die Auswirkung zeigt sich genau im ungünstigsten Moment. Tritt trotz Blackholing erhöhter Verkehr auf Ihren Leitungen auf, etwa von einem Internetknoten wie oben beschrieben, behandelt der Router die Konsole als letztes Element des Pfads zur angegriffenen Adresse und leitet diesen Verkehr zu ihr. Die WanGuard-Konsole ist ein Management-System, kein Gerät zur Weiterleitung von Verkehr; bei ausreichendem Volumen verliert sie an Leistung, reagiert nicht mehr und kann die BGP-Session abbrechen, über die der gesamte Schutz des Netzes läuft. Damit geht der Schutz verloren, und der gesamte Verkehr des DDoS-Angriffs erscheint auf Ihren Leitungen.

Abhilfe: Schreiben Sie in der Import-Policy der BGP-Session mit der Konsole den Next-Hop eingehender Präfixe auf eine Adresse um, die zum Router gehört.

Punkt 3. Lokales Blackholing auf dem Router

Das Umschreiben des Next-Hops allein verlagert das Problem, statt es zu lösen: Der Verkehr fließt nicht mehr zur Konsole, kommt aber nun an einem Router an, der ihn nirgendwohin weiterleiten kann. Die als neuer Next-Hop eingetragene Adresse benötigt daher auf dem Router eine lokale Discard-Regel, also eine Route, die ausdrücklich festlegt, dass Verkehr zu dieser Adresse verworfen wird.

Dieses Element ist unverzichtbar, unabhängig davon, ob Sie einen Hardware- oder einen Software-Router betreiben. Eine korrekt konfigurierte Discard-Route lässt Pakete in der Forwarding-Ebene verschwinden, sodass sie die Control Plane nicht erreichen. Ohne sie beginnt der Router, den Verkehr in Software zu verarbeiten, was bei einem volumetrischen Angriff steigende CPU-Last, Probleme mit BGP-Sessions und Instabilität bedeutet: dieselbe Folge, die wir bei der Konsole vermeiden wollten, nur an eine andere Stelle verschoben.

Als Zieladresse für lokales Blackholing wählen Sie eine beliebige ungenutzte Adresse aus dem privaten Adressraum nach RFC 1918: 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16. In den folgenden Beispielen verwenden wir 10.255.255.1. Adressen aus diesen Bereichen werden im Internet nicht geroutet, sodass nichts Reales versehentlich abgeschnitten werden kann; zudem kollidieren sie nicht mit der Standardliste der Martians in Junos.

Das Ergebnis aller drei Punkte

Mit einem vollständigen Satz an BGP-Communities bei der Ankündigung, einem umgeschriebenen Next-Hop beim Import und lokalem Blackholing auf dem Router können Sie sicher sein, dass Angriffsverkehr:

• größtenteils bei den Providern verworfen wird, bevor er Ihre Leitungen erreicht,
• die WanGuard-Konsole nicht erreicht, sodass das Erkennungssystem weiterarbeitet und den Verlauf des Vorfalls erfasst,
• den Edge-Router nicht belastet, sondern als überflüssiger und gefährlicher Verkehr verworfen wird.

Konfiguration, Juniper MX

Nachfolgend die vollständige Konfiguration der Session mit der WanGuard-Konsole, die sowohl RTBH als auch BGP FlowSpec abdeckt:

set protocols bgp group eBGP-Wanguard type internal
set protocols bgp group eBGP-Wanguard description Wanguard
set protocols bgp group eBGP-Wanguard peer-as 65000
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 local-address 10.0.2.5
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 import import-Wanguard
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet unicast
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet flow no-validate NO-VALIDATION
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet6 unicast
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 family inet6 flow no-validate NO-VALIDATION
set protocols bgp group eBGP-Wanguard neighbor 10.0.2.66 export no-export

set policy-options policy-statement NO-VALIDATION then accept
set policy-options policy-statement REJECT-ALL term reject then reject
set policy-options policy-statement import-Wanguard term flowspec_import from rib inetflow.0
set policy-options policy-statement import-Wanguard term flowspec_import then accept
set policy-options policy-statement import-Wanguard term rtbh from protocol bgp
set policy-options policy-statement import-Wanguard term rtbh from community blackhole
set policy-options policy-statement import-Wanguard term rtbh then accept
set policy-options policy-statement import-Wanguard term last-deny-all then reject

set policy-options community blackhole members 5617:666

set routing-options rib inetflow.0 maximum-prefixes 5000
set routing-options flow term-order standard

Die letzte Klausel ist wichtig: Die Session mit der WanGuard-Konsole dient ausschließlich der Signalisierung von RTBH und BGP FlowSpec, daher wird alles abgelehnt, was nicht dem Muster entspricht.

Hinzu kommen zwei Elemente, die die Punkte zwei und drei umsetzen, nämlich das Umschreiben des Next-Hops beim Import und die Discard-Route:

set routing-options static route 10.255.255.1/32 discard

set policy-options policy-statement import-Wanguard term rtbh then next-hop 10.255.255.1

Junos kann den Verkehr statt auf eine statische Route auch auf ein Discard-Interface leiten. Diese Variante ist praktischer, wenn Sie den verworfenen Verkehr zählen oder samplen möchten, da sich an das Interface Filter binden lassen.

Konfiguration, Cisco

ip route 10.255.255.1 255.255.255.255 Null0

ip community-list standard BLACKHOLE permit 5617:666

ip prefix-list HOST-ROUTES permit 0.0.0.0/0 ge 32 le 32

route-map WANGUARD-IN permit 10
 match community BLACKHOLE
 match ip address prefix-list HOST-ROUTES
 set ip next-hop 10.255.255.1
route-map WANGUARD-IN deny 20

router bgp <ASN>
 neighbor <konsolen-adresse> route-map WANGUARD-IN in

Das Interface Null0 ist ein Pseudo-Interface, das immer aktiv bleibt und niemals Verkehr weiterleitet; Routen darauf zu richten ist auf Cisco-Plattformen die übliche Methode, lokales Blackholing umzusetzen.

Überprüfung

Drei Tests, idealerweise in Ruhe und außerhalb eines Angriffs durchgeführt.

BGP-Communities. Prüfen Sie nach dem Signalisieren eines Test-Blackholes bei jedem Provider, ob das Präfix angenommen wurde und bei ihm als Blackhole markiert ist. Nur so finden Sie eine fehlende BGP-Community, bevor ein Angriff sie aufdeckt.

Next-Hop. Prüfen Sie auf dem Router die Route zur getesteten Adresse. Der Next-Hop muss auf die Adresse des lokalen Blackholings zeigen und niemals auf die Adresse der Konsole. Dies ist der wichtigste einzelne Test der gesamten Implementierung.

Discard-Route. Auf Juniper sollte show route 10.255.255.1 einen Eintrag vom Typ Discard zeigen, auf Cisco sollte show ip route 10.255.255.1 auf Null0 verweisen. Die Zähler des Eingangsinterfaces sollten steigen, die des Ausgangsinterfaces nicht.

Checkliste

• Eine schriftliche Liste aller Provider und Peering-Partner mit den jeweils geforderten BGP-Communities.
• Die Konsole hängt bei der Ankündigung eines Blackhole-Präfixes den vollständigen Satz dieser BGP-Communities an.
• Die Import-Policy auf der Session mit der Konsole schreibt den Next-Hop auf eine lokale Adresse um.
• Die Policy wirkt nur auf Host-Präfixe mit der Blackhole-Community; alles andere wird abgelehnt.
• Die Adresse für lokales Blackholing hat eine Route discard bzw. Null0.
• Test durchgeführt: Der Next-Hop zeigt auf das lokale Blackholing, nicht auf die Konsole.
• Blackhole-Präfixe gelangen nicht über den vorgesehenen Ankündigungsbereich hinaus.

Referenzmaterial

• Cisco: Remotely Triggered Black Hole Filtering (technisches Whitepaper).
• Cisco: Remotely triggered blackhole filtering (BGP-Dokumentation, IOS XR).
• Juniper: discard (routing-options).
• Juniper: Example: Forwarding Packets to the Discard Interface.
• IETF: RFC 7999 (BLACKHOLE-Community 65535:666) und RFC 5635 (Remotely Triggered Black Hole Filtering).