BGP Hijacking & Routing Security

BGP-Grundlagen — warum das Internet auf Vertrauen basiert

Das Border Gateway Protocol Version 4 (BGP-4, RFC 4271) ist das einzige Exterior Gateway Protocol des Internets und verbindet über 75.000 autonome Systeme (AS) weltweit. Jedes AS — sei es ein ISP, ein Unternehmen oder ein Cloud-Provider — hat eine eindeutige AS-Nummer (ASN), zugewiesen von einer der fünf Regional Internet Registries (RIR): RIPE NCC (Europa), ARIN (Nordamerika), APNIC (Asien-Pazifik), LACNIC (Lateinamerika) und AFRINIC (Afrika). BGP-Router tauschen über TCP-Port 179 sogenannte UPDATE-Nachrichten aus, die Präfixe (IP-Adressblöcke) und den zugehörigen AS-Pfad enthalten. Das fundamentale Problem: BGP wurde 1989 entworfen, als das Internet aus einer Handvoll vertrauenswürdiger Universitäts- und Militärnetzwerke bestand. Es gibt keinerlei eingebauten Mechanismus, um zu verifizieren, ob ein AS tatsächlich berechtigt ist, ein bestimmtes Präfix anzukündigen. Jeder BGP-Peer kann behaupten, der legitime Ursprung für beliebige IP-Bereiche zu sein — und seine Nachbarn werden diese Ankündigung im Normalfall akzeptieren und weiterverbreiten.

Was die meisten Netzwerk-Administratoren nicht wissen: Die BGP-Entscheidungslogik bevorzugt spezifischere Präfixe. Wenn ein AS das Präfix 203.0.113.0/24 ankündigt und ein Angreifer gleichzeitig 203.0.113.0/25 und 203.0.113.128/25 ankündigt, werden die spezifischeren /25-Routen immer bevorzugt — unabhängig vom AS-Pfad oder anderen Attributen. Dies macht das sogenannte Sub-Prefix Hijacking extrem effektiv und nahezu unmöglich zu überstimmen, solange der legitime Betreiber nicht ebenfalls auf /25 oder kleiner herunterbricht. Zusätzlich unterstützen die meisten ISPs keine Präfixe kleiner als /24 in ihren Filtern, was bedeutet, dass ein /25-Hijack oft nur teilweise propagiert wird — was die Diagnose erheblich erschwert, da nur bestimmte Teile des Internets betroffen sind.

• AS-Pfad-Manipulation: Ein Angreifer kann seinen eigenen AS-Pfad mit Fake-ASNs verlängern (AS-Path Prepending) oder verkürzen, um die Pfadauswahl zu beeinflussen. Besonders tückisch: Das Einfügen der ASN des legitimen Präfix-Inhabers in den Pfad (AS-Path Poisoning), um zu verhindern, dass der legitime Betreiber seine eigene Route über den Angreifer-Pfad zurückbekommt.
• BGP Session Hijacking: Da BGP über TCP läuft, kann ein Angreifer mit Zugriff auf den Netzwerkpfad zwischen zwei BGP-Peers die TCP-Session übernehmen (TCP Sequence Number Prediction). Gegenüberliegende Peers authentifizieren sich standardmäßig nicht — nur über die Quell-IP-Adresse. Die optionale MD5-Authentifizierung (RFC 2385) wird von weniger als 30 % aller BGP-Sessions weltweit genutzt.
• Route Leak (RFC 7908): Kein Angriff im eigentlichen Sinne, aber ebenso verheerend: Ein Transit-AS leitet versehentlich Routen weiter, die es nicht weiterleiten sollte — z. B. wenn ein Kunde-AS alle von einem Upstream-Provider erhaltenen Routen an einen anderen Upstream weitergibt. Der berühmteste Fall: Im Juni 2019 leakte ein kleiner ISP in Pennsylvania (AS396531) über 20.000 Präfixe, was einen erheblichen Teil des europäischen Verkehrs über China Telecom umleitete.
• BGP Community Abuse: BGP Communities (RFC 1997) sind optionale transitive Attribute, die Routing-Policies steuern. Angreifer können bekannte Communities (z. B. NO_EXPORT, NO_ADVERTISE) an Routen anhängen, um die Propagation zu manipulieren. Einige ISPs verwenden „Blackhole Communities“ (z. B. ASN:666) — ein Angreifer, der die richtige Community kennt, kann legitime Präfixe effektiv vom Netz nehmen.

Angriffstechniken — wie BGP-Hijacking in der Praxis funktioniert

BGP-Hijacking-Angriffe lassen sich in drei Kategorien einteilen, die sich in Aufwand und Auswirkung erheblich unterscheiden. Die einfachste und häufigste Form ist das Origin Hijacking: Der Angreifer kündigt ein fremdes Präfix mit seiner eigenen ASN als Origin an. Dies erfordert lediglich Zugang zu einem BGP-Router und einer bestehenden Peering-Session. In der Praxis nutzen Angreifer dafür kompromittierte Router, gefälschte LOA (Letter of Authorization) bei nachlässigen Hosting-Providern oder sogar Zombie-ASNs — längst aufgegebene, aber nie aus den IRR-Datenbanken entfernte autonome Systeme. Der vielleicht bekannteste Vorfall ereignete sich 2018, als AS10297 (eine kleine russische ISP-Tochter) für ca. 2 Stunden die Präfixe von Amazon Route 53 DNS-Servern hijackte und den Traffic auf eine gefälschte MyEtherWallet-Seite umleitete — ein gezielter Kryptowährungsdiebstahl via BGP-Hijacking.

Die zweite Kategorie — Man-in-the-Middle via BGP — ist technisch deutlich anspruchsvoller, aber verheerend: Der Angreifer kündigt das Opfer-Präfix an, leitet den empfangenen Traffic durch sein Netzwerk, inspiziert oder modifiziert ihn und tunnelt ihn dann über eine GRE- oder IPIP-Verbindung zum legitimen Ziel weiter. Da die Antwortpakete direkt vom Ziel zum Client gehen (asymmetrisches Routing), fällt der Umweg nur durch erhöhte Latenz und veränderte TTL-Werte auf. Der Sicherheitsforscher Alex Pilosov demonstrierte diese Technik erstmals 2008 auf der DefCon und zeigte, dass sie über Stunden unbemerkt bleiben kann.

Die dritte und subtilste Form ist das Route Leak mit strategischer Wirkung: Ein Transit-Provider gibt Routen weiter, die er nicht weiterleiten sollte, und wird dadurch unbeabsichtigt zum „billigsten“ Pfad für einen großen Teil des Internets. Im April 2020 verursachte ein Route Leak durch AS12389 (Rostelecom) die Umleitung von Traffic für Google, Cloudflare, AWS und über 200 weitere CDNs über russische Netze. Ob dies ein versehentlicher Fehler oder ein gezielter Angriff war, ist bis heute umstritten.

• Crypto-Hijacking-Muster: Seit 2017 häufen sich BGP-Hijacks, die gezielt DNS-Server oder Kryptobörsen angreifen. Das Muster: Hijacke die IP-Adresse eines autoritären DNS-Servers → beantworte DNS-Queries für die Zieldomain mit der IP eines Phishing-Servers → erbeute Zugangsdaten. Da das TLS-Zertifikat nicht passt, nutzen Angreifer zusätzlich eine gültige Let’s-Encrypt-Ausstellung während des Hijacks (DV-Zertifikate validieren nur per HTTP/DNS — beides steht während des Hijacks unter Kontrolle des Angreifers).
• Staatlich gesteuerte Umleitung: China Telecom (AS4134) kündigt regelmäßig Präfixe an, die nicht zu seinem Kundenstamm gehören, wodurch Traffic über chinesische Netzwerke geleitet wird. Das US Naval War College und Wissenschaftler der Universität Tel Aviv dokumentierten 2018, dass systematisch Traffic von US-Militärstandorten und verbündeten Nationen durch China geroutet wurde — über Jahre hinweg, ohne Korrektur.
• Accidental Hijacks — die häufigste Variante: Im Oktober 2021 verursachte ein Facebook-Mitarbeiter während routinemäßiger Wartungsarbeiten den Entzug aller BGP-Routen für AS32934 — Facebook, Instagram, WhatsApp und Oculus verschwanden für über 6 Stunden aus dem Internet. Da auch die internen DNS-Server über BGP erreichbar waren, konnten Mitarbeiter nicht einmal die internen Tools zur Fehlerbehebung erreichen. Physischer Zugang zu den Rechenzentren war erforderlich, um den Fehler zu beheben.
• Monitoring-Tools: BGPStream (CAIDA/OpenBMP) und RIPE RIS bieten Echtzeit-Monitoring aller BGP-Updates weltweit. Cloudflare Radar visualisiert BGP-Anomalien. Für eigene Präfixe: BGPalerter (Open Source) überwacht RIPE RIS und RouteViews und sendet Alerts bei unerwarteten Origin-Änderungen. Konfiguration: npm install -g bgpalerter && bgpalerter --prefixes 203.0.113.0/24 --asn 64500.

Verteidigung — RPKI, ROA und die Zukunft der Routing-Sicherheit

Die wichtigste Verteidigungsmaßnahme gegen BGP-Hijacking ist RPKI (Resource Public Key Infrastructure), definiert in RFC 6480. RPKI ermöglicht es Präfix-Inhabern, kryptographisch signierte Route Origin Authorizations (ROA) zu erstellen, die festlegen, welche ASN berechtigt ist, ein bestimmtes Präfix zu ankündigen, und mit welcher maximalen Präfixlänge. Wenn ein ISP Route Origin Validation (ROV) durchführt, werden BGP-Updates gegen die ROA-Datenbank geprüft: Updates, deren Origin-ASN nicht mit der ROA übereinstimmt, erhalten den Status „Invalid“ und können verworfen werden. Stand 2024 haben über 50 % aller IPv4-Präfixe eine gültige ROA, aber nur etwa 35 % der Netzwerke führen tatsächlich ROV durch und verwerfen invalide Routen — die Lücke zwischen Signierung und Validierung bleibt das größte Problem.

Was RPKI nicht löst: Es schützt nur den Origin — nicht den AS-Pfad. Ein Angreifer kann immer noch behaupten, den Traffic über seinen AS zum korrekten Origin zu leiten (AS-Path Manipulation). Dafür wird BGPsec (RFC 8205) benötigt, das jeden Hop im AS-Pfad kryptographisch signiert. BGPsec ist jedoch in der Praxis kaum deploybar: Jeder Router auf dem Pfad muss kryptographische Operationen durchführen, was bei Hunderttausenden von Updates pro Sekunde die CPU-Kapazität heutiger Router übersteigt. Realistischere Alternativen sind ASPA (Autonomous System Provider Authorization, Draft RFC) und die Verwendung von IRR-Filtern (Internet Routing Registry) in Kombination mit RPKI.

• ROA erstellen (RIPE NCC): Loggen Sie sich im RIPE LIR-Portal ein → Ressourcen → RPKI → „ROA erstellen“. Wählen Sie Ihr Präfix (z. B. 203.0.113.0/24), die autorisierte Origin-ASN (z. B. AS64500) und die maximale Präfixlänge (empfohlen: exakt /24, keine längeren Präfixe — ein maxLength von /24 verhindert Sub-Prefix-Hijacks). Achtung: Eine falsch konfigurierte ROA mit zu restriktivem maxLength kann Ihre eigenen Routen als Invalid markieren — testen Sie immer zuerst mit dem RIPE RPKI Validator.
• ROV auf eigenen Routern (Cisco IOS-XR): router bgp 64500 / address-family ipv4 unicast / rpki server 192.0.2.1 / rpki origin-as validation enable / route-policy rpki-validation / if validation-state is invalid then drop endif. Für Juniper JunOS: set routing-options validation group rpki-validators session 192.0.2.1 / set policy-options policy-statement rpki-reject term invalid from validation-database invalid / then reject.
• Prefix-Filter mit IRRDB: Generieren Sie automatische Prefix-Filter aus IRR-Datenbanken mit bgpq4 (Nachfolger von bgpq3): bgpq4 -4 -A -l customer_prefixes AS64500 erzeugt eine Access-Liste aller von AS64500 registrierten Präfixe. Wenden Sie diese als Inbound-Filter auf alle Kunden-Sessions an. Aktualisieren Sie die Filter automatisch per Cron (täglich). Kombiniert mit RPKI-ROV bietet dies den stärksten verfügbaren Schutz.
• MANRS (Mutually Agreed Norms for Routing Security): Die Internet Society betreibt MANRS als freiwillige Initiative, in der ISPs sich zu vier Grundprinzipien verpflichten: Filterung (keine invaliden Routen weiterleiten), Anti-Spoofing (BCP38/uRPF), Koordination (aktuelle Kontaktdaten in PeeringDB) und globale Validierung (RPKI-ROV). Über 1.000 Netzwerke weltweit sind MANRS-Mitglied — prüfen Sie, ob Ihr Upstream-Provider dabei ist.
• BGP-Monitoring für KMU: Auch ohne eigenes AS können Sie Ihre IP-Präfixe überwachen: Cloudflare Radar Route Leak Detection (kostenlos), RIPE RIPEstat (zeigt BGP-Routing-History für jedes Präfix), ThousandEyes (kommerziell, BGP + Traceroute-Korrelation). Für DNS: Überwachen Sie mit DNSViz, ob Ihre DNSSEC-Chain intakt ist — ein BGP-Hijacker, der Ihren DNS-Server-Präfix übernimmt, kann keine gültige DNSSEC-Signatur fälschen.
• DNSSEC als letzte Verteidigungslinie: Selbst wenn ein BGP-Hijack gelingt, schützt DNSSEC vor gefälschten DNS-Antworten: Die kryptographischen Signaturen sind an den privaten Schlüssel des Zone-Inhabers gebunden, den der Angreifer nicht besitzt. In Kombination mit Certificate Transparency (CT) Monitoring (z. B. via crt.sh oder Facebook CT Monitor) erhalten Sie Alerts, wenn jemand während eines Hijacks ein DV-Zertifikat für Ihre Domain ausstellt.