BGP Hijack vs. Route Leak: Unterschiede, Impact und Mitigation

Ein BGP Hijack und ein Route Leak gehören zu den bekanntesten Ursachen für großflächige Störungen im Internet-Routing – und sie werden im Alltag dennoch häufig verwechselt. Beide Ereignisse basieren darauf, dass Border Gateway Protocol (BGP) Routeninformationen zwischen autonomen Systemen (AS) austauscht und Entscheidungen nach Policy und Pfad-Attributen trifft. Der entscheidende Unterschied liegt in der Intention und im Mechanismus: Beim BGP Hijack wird ein Prefix (oder ein Teil davon) so angekündigt, dass Traffic in ein falsches Netz umgeleitet wird – oft mit dem Ziel, Daten abzugreifen, zu stören oder umzuleiten. Ein Route Leak entsteht dagegen typischerweise durch Fehlkonfiguration oder fehlende Export-Policies, bei der Routen „aus Versehen“ in eine Richtung propagiert werden, in der sie nie erscheinen sollten. Für Betreiber ist das nicht nur akademisch: Die Impact-Muster unterscheiden sich, die Detektion folgt anderen Signalen, und die Mitigation setzt an unterschiedlichen Stellen an – von Prefix-Filtering über RPKI bis hin zu BGP Roles, Max-Prefix-Limits und strengen Export-Policies. Dieser Artikel erklärt praxisnah, woran Sie Hijack und Route Leak unterscheiden, welche Schäden realistisch sind und welche Maßnahmen im Betrieb (NOC/SecOps/NetOps) wirklich helfen.

Grundlagen: Was BGP eigentlich tut (und warum das Risiken schafft)

BGP ist ein Policy-basiertes Routing-Protokoll für den Austausch von Reachability-Informationen zwischen autonomen Systemen. Ein AS kündigt Prefixes an und stellt Attribute bereit (z. B. AS_PATH, NEXT_HOP, LOCAL_PREF, MED, Communities). Nachbarn übernehmen diese Routen, wenden lokale Policies an und propagieren sie weiter. Das Internet funktioniert deshalb, weil sich die meisten Netzbetreiber an Routing-Hygiene halten: Präfixe werden nur dann angekündigt, wenn man sie besitzen oder legitim weiterleiten darf, und Export-Richtungen folgen kommerziellen und technischen Rollen (Customer, Provider, Peer).

Das Risiko entsteht aus zwei Eigenschaften: Erstens vertraut BGP historisch darauf, dass Ankündigungen „ehrlich“ sind; zweitens sind Fehlkonfigurationen auf AS-Ebene schnell global sichtbar, weil Routen in wenigen Minuten weitreichend verteilt werden. Moderne Schutzmechanismen wie RPKI/ROV und Best Practices wie BCPs reduzieren das Risiko, eliminieren es aber nicht vollständig. Einen guten Einstieg in die Grundbegriffe und Attribute bietet die Dokumentation der IETF Datatracker sowie die Übersicht von RFC Editor für die relevanten Standards.

Definitionen: BGP Hijack vs. Route Leak in klaren Worten

Um in Incidents schnell richtig zu handeln, hilft eine saubere Definition.

• BGP Hijack: Ein AS kündigt ein Prefix an, das es nicht (oder nicht in dieser Form) kontrolliert. Dadurch wird Traffic falsch geroutet. Hijacks können vollständig (kompletter Prefix) oder partiell (Subprefix-Hijack) sein und können zur Störung oder zum Abgriff genutzt werden.
• Route Leak: Ein AS propagiert Routen über eine BGP-Beziehung, über die diese Routen nicht exportiert werden sollten. Meist entsteht das aus falschen Export-Policies oder fehlerhaften Route-Maps/Filters, z. B. wenn Provider-Routen an einen Peer oder Provider weitergegeben werden.

In der Praxis gibt es Überschneidungen: Ein Leak kann so wirken, als würde „falsches“ Routing stattfinden, und ein Hijack kann wie „Policy-Chaos“ aussehen. Der Weg zur Unterscheidung führt über Symptome, Pfad-Attribute und die Richtung der Propagation.

Typische Ursachen und Auslöser

Beide Incident-Typen haben wiederkehrende Muster. Wer diese Muster kennt, erkennt schneller, ob er es mit einem Sicherheitsvorfall, einer Konfigurationspanne oder einem Downstream-Problem zu tun hat.

Häufige Auslöser für BGP Hijacks

• Fehl-Origination: Ein AS originiert ein Prefix ohne Autorisierung (falsche Network-Statements, Redistribution, Automation-Fehler).
• Subprefix-Ankündigung: Ein kleineres Prefix (z. B. /24 innerhalb eines /23) wird angekündigt, weil längere Präfixe im Internet oft bevorzugt werden (Longest Prefix Match).
• Man-in-the-Middle: Traffic wird nicht nur blackholed, sondern weitergeleitet (Intercept), um Inhalte mitzulesen oder umzuschreiben.
• Gezielte Störung: Hijack mit Absicht, um Dienste zu unterbrechen oder DDoS-Umleitungen zu erleichtern.

Häufige Auslöser für Route Leaks

• Fehlende Export-Policy: „Accept all / advertise all“ zwischen Sessions, besonders bei neuen Peering-Setups.
• Falsche Rollenannahme: Peer wird wie Customer behandelt oder umgekehrt; Routen werden in die falsche Richtung verteilt.
• Community-Fehler: Communities zur Steuerung (no-export, local-pref) fehlen oder werden falsch gemappt.
• Automation/Template Drift: Konfigurationsgenerierung ändert Filterlisten, Prefix-Listen oder Route-Maps unbemerkt.

Unterschiede in Symptomen: So sieht es „auf der Leitung“ aus

Im NOC zählt, was messbar ist. Die folgenden Symptome helfen bei der schnellen Einordnung, bevor tiefe Forensik startet.

Symptom-Muster bei BGP Hijacks

• Erreichbarkeitsverlust: Ziele im betroffenen Prefix werden plötzlich unreachbar oder enden in Timeouts.
• Traffic-Shift: NetFlow/IPFIX zeigt plötzliche Abflüsse in Richtung eines unerwarteten AS.
• AS_PATH-Anomalie: Der Origin-AS ändert sich, oder das AS_PATH wirkt „zu kurz“ bzw. unplausibel.
• Subprefix gewinnt: Ein kleines Prefix zieht Traffic an, obwohl das größere Prefix weiterhin existiert.

Symptom-Muster bei Route Leaks

• Umwege und Latenz: Traceroutes zeigen plötzlich längere Pfade, weil Traffic durch ein „Transit-AS“ geleitet wird, das nicht Transit sein sollte.
• Überlastung: Das leaky AS wird ungewollt zum Transit und bekommt massiv mehr Traffic (Congestion, Packet Loss, Queue Drops).
• Breite Betroffenheit: Viele Prefixes/ASNs sind indirekt betroffen, nicht nur ein einzelnes Ziel-Prefix.
• Policy-Attribut-Mismatch: Communities, Local-Pref oder bekannte Peering-Policies passen nicht mehr zur beobachteten Propagation.

Impact: Was wirklich kaputtgeht (Security, Availability, Performance)

Der Impact hängt stark davon ab, ob Traffic nur umgelenkt, verworfen oder weitergeleitet wird. Für die Bewertung lohnt eine Aufteilung in Verfügbarkeit, Integrität/Vertraulichkeit und Performance.

Impact bei Hijacks

• Blackholing: Traffic wird ins Nirwana geroutet. Ergebnis: Outage für betroffene Dienste.
• Intercept (MITM): Traffic wird angenommen und weitergeleitet. Ergebnis: Risiko für Datenabgriff, Session-Hijacking, Manipulation (besonders ohne Ende-zu-Ende-Verschlüsselung oder bei schwachen TLS-Setups).
• Service-Degradation: Teilweise Erreichbarkeit, weil nur bestimmte Regionen/AS-Pfade betroffen sind.

Impact bei Route Leaks

• Massive Umleitungen: Datenströme nehmen unerwartete Transitwege, was Latenz und Jitter erhöht.
• Congestion und Kollateralschäden: Das leaky AS überlastet Links, was auch andere Services beeinträchtigen kann.
• Instabilität: Route-Churn, Flaps, erhöhte CPU auf Routern durch viele Updates.

Für eine grobe, aber nützliche Abschätzung der „Schwere“ kann man den Anteil des betroffenen Traffics am Gesamttraffic als Kennzahl nutzen. Wenn Sie beispielsweise den durchschnittlichen Throughput T für ein Prefix oder eine Service-Gruppe kennen, lässt sich eine Impact-Schätzung pro Zeitfenster als Fläche unter der Kurve modellieren:

$I=T\times \Delta t$

In der Praxis ersetzen Sie T durch gemessene Werte (BPS/PPS) aus Telemetrie und multiplizieren mit der Dauer der Beeinträchtigung. Das ist kein exakter Business-Schaden, aber ein belastbarer technischer Indikator für RCA und Priorisierung.

Wie Sie Hijack und Leak sauber unterscheiden: Entscheidungsbaum für den Betrieb

Statt lange zu diskutieren, hilft ein pragmatischer Prüfpfad, der in Minuten eine robuste Hypothese liefert.

• Schritt 1: Ist ein konkretes Prefix „falsch“? Wenn ein bestimmtes Prefix plötzlich von einem anderen Origin-AS angekündigt wird, ist Hijack wahrscheinlicher.
• Schritt 2: Gibt es Subprefix-Ankündigungen? Wenn ein längeres Prefix den Traffic anzieht, ist das ein starkes Hijack-Signal.
• Schritt 3: Breite oder punktuelle Betroffenheit? Viele unerwartete Pfade/Prefixes deuten eher auf Leak als auf einen einzelnen Hijack.
• Schritt 4: Richtung der Propagation prüfen: Wird Traffic über ein AS geleitet, das laut Peering-Policy nie Transit sein sollte? Dann Leak-Verdacht.
• Schritt 5: Validierung mit RPKI/ROV: Wenn RPKI-Status „invalid“ ist, stärkt das den Hijack-Verdacht (oder ein legitimer, aber falsch gepflegter ROA).

Detection: Praktische Signale und Tools für NOC/SecOps

Detektion ist am effektivsten, wenn Sie interne Telemetrie mit externen Sichtdaten kombinieren. Ziel ist nicht „schöne Dashboards“, sondern schneller, belastbarer Nachweis.

Interne Detection-Signale

• BGP Monitoring: Alerts auf Origin-AS-Wechsel, neue AS_PATHs, unerwartete Communities, Route Flaps.
• Max-Prefix Alarme: Plötzliche Prefix-Spikes pro Peer sind ein klassisches Leak-Signal.
• Traffic-Anomalien: NetFlow/IPFIX Top-N Sources/Destinations, ungewöhnliche Transit-Last, Link-Utilization-Spikes.
• End-to-End Synthetics: Regionale Checks zeigen, ob nur bestimmte Pfade betroffen sind.

Externe Sicht und Validierung

Externe BGP-Collector- und Routing-Statusseiten helfen, den Scope zu verstehen: Kommt die falsche Route global an oder nur in bestimmten Regionen? Für RPKI-Status und Route-Origin-Validierung bieten sich Quellen wie Cloudflare RPKI Validator an. Für Community- und Best-Practice-Rahmen rund um Routing-Sicherheit ist MANRS eine etablierte Referenz. Für die grundlegende Beschreibung von Route Leaks und gängige Gegenmaßnahmen ist auch RIPE NCC als Wissensquelle hilfreich.

Mitigation bei BGP Hijacks: Was kurzfristig hilft (und was nachhaltig schützt)

Mitigation teilt sich in Sofortmaßnahmen (Incident) und strukturelle Maßnahmen (Prävention). Bei Hijacks ist die Zeit kritisch, weil Traffic aktiv fehlgeleitet wird.

Sofortmaßnahmen im Incident

• Kontaktpfad: Upstream/Peer/NOC des auffälligen AS informieren; viele Fälle sind Fehlkonfigurationen und lassen sich schnell zurückrollen.
• De-Preferencing: Routen über den auffälligen Pfad lokal depriorisieren (Local-Pref, Communities) oder gezielt filtern.
• More-Specific Announcement: Wenn möglich, ein legitimes längeres Prefix announcen, um Traffic zurückzuziehen (mit Vorsicht: Aggregation, Policies, nur wenn operational sauber).
• Blackhole/RTBH: Bei DDoS-ähnlichen Hijack-Effekten kann RTBH die Auswirkungen begrenzen (Trade-off: Verfügbarkeit vs. Schutz anderer Komponenten).

Nachhaltige Prävention gegen Hijacks

• RPKI/ROV: ROAs für eigene Prefixes erstellen und Route Origin Validation bei Ingress anwenden. Einstieg und Spezifikation finden Sie über IETF SIDROPS.
• Prefix-Filtering: Ingress-Filter pro Kunde/Downstream: nur autorisierte Prefixes akzeptieren (IRR/RPKI als Quelle).
• Strict Peering Policies: Keine „accept all“-Sessions ohne definierte Filter- und Policy-Sets.
• Monitoring auf Origin-Change: Alerts bei Origin-AS-Change für eigene Präfixe sind Pflicht.

Mitigation bei Route Leaks: Wie Sie Transit-Unfälle stoppen

Bei Route Leaks ist das Problem selten ein einzelnes Prefix, sondern die ungewollte Transit-Funktion. Daher sind Maßnahmen wirksam, die Propagation begrenzen und Policies korrekt durchsetzen.

Sofortmaßnahmen im Incident

• Max-Prefix greifen lassen: Wenn Max-Prefix korrekt dimensioniert ist, kappt es Leak-Schwemme frühzeitig (mit klaren Alarmen und Runbook).
• Peer/Provider Session dämpfen: Temporär Outbound-Advertisements einschränken oder Session neu bewerten (nur mit klarer Risikoabwägung).
• Community-basierte Einschränkung: no-export/no-advertise Communities einsetzen, sofern im Upstream/Peer-Ökosystem verstanden.
• Targeted Filtering: Verdächtige Routenfamilien oder unerwartete AS_PATH-Pattern filtern, bis die Root Cause behoben ist.

Nachhaltige Prävention gegen Leaks

• BGP Roles und korrekte Export-Policies: Customer/Provider/Peer konsequent abbilden; niemals Provider- oder Peer-Routen an andere Provider/Peers exportieren.
• Peer Locking / Route Maps: Whitelists für erlaubte Routen je Session (Customer-Prefixes, eigene Aggregate).
• Graceful Templates: Automations-Templates mit Tests (CI) gegen Policy-Regressionen.
• Monitoring auf Prefix-Spikes: Frühwarnung, bevor es global eskaliert.

Als konzeptionelle Grundlage zur Vermeidung von Route Leaks und zur Rollenmodellierung sind Best-Practice-Ressourcen von Operator-Communities hilfreich; ein Einstieg über RIPE NCC Trainingsmaterial bietet praxisnahe Perspektiven.

RPKI, IRR und Filtering: Wie Sie die Bausteine sinnvoll kombinieren

Eine robuste Mitigation-Strategie kombiniert mehrere Mechanismen, weil jeder Ansatz blinde Flecken hat. RPKI schützt zuverlässig gegen falsche Origin-AS-Ankündigungen, wenn ROAs korrekt gepflegt und ROV breit aktiviert ist. IRR-basierte Filtersätze können zusätzlich helfen, sind aber abhängig von Datenqualität und Pflege. Klassische Prefix-Listen pro Kunde sind operativ stark, benötigen jedoch sauberes Lifecycle-Management (Onboarding, Renumbering, Multi-Site).

• Minimum: Eigene ROAs + ROV inbound, plus Kunden-Prefix-Filter inbound.
• Erweitert: IRR/RPKI-basierte automatische Filtergenerierung mit Review und Rollback.
• Operativ: Max-Prefix-Limits, Session-Guardrails, Alerting auf Policy-Drift.

False Positives und typische Stolperfallen in der Praxis

Nicht jede „falsche“ Route ist ein Angriff. Häufige Stolperfallen führen zu Fehlalarmen oder zu Mitigation, die mehr schadet als nützt.

• Legitime Traffic-Shift durch Provider-Changes: Neue Peering-Policies, Wartungen, TE-Änderungen können wie Leak wirken.
• RPKI invalid durch falsche ROAs: Ein korrektes Prefix kann invalid erscheinen, wenn ROAs nicht aktuell sind (MaxLength, ASN, neue Aggregate).
• Anycast und verteilte Origins: Anycast-Setups können ungewöhnliche Pfade zeigen, ohne dass ein Hijack vorliegt.
• Partial Visibility: Interne Beobachtung zeigt nur einen Ausschnitt; externe Collector-Daten sind nötig, um Scope zu validieren.

Incident Response: Minimaler Response-Plan für BGP Hijack und Route Leak

Ein operierbarer Response-Plan verhindert Panik-Aktionen und beschleunigt Recovery. Die folgenden Schritte sind bewusst minimal gehalten, aber in vielen Umgebungen ausreichend, um von „Alert“ zu „stabil“ zu kommen.

• Triaging: Betroffene Prefixes/Services identifizieren, Scope regional vs. global einschätzen, Change-Korrelation prüfen.
• Klassifikation: Origin-AS-Wechsel/Subprefix? → Hijack-Verdacht. Prefix-Spike/Transit-Anomalie? → Leak-Verdacht.
• Evidenz: BGP Updates, AS_PATH-Änderungen, RPKI-Status, Flow/Utilization, Traceroutes aus mehreren Regionen.
• Mitigation: De-prefer/filter/Max-Prefix/Communities nach Plan, nicht ad hoc.
• Kommunikation: Upstream/Peer kontaktieren, Status intern/extern kommunizieren, ETA vermeiden, stattdessen Messwerte.
• Stabilisierung: Route Dampening vorsichtig einsetzen (plattformabhängig), nach Fix die Normalisierung beobachten.

Operative Checkliste: Pflicht-Controls, die beides reduzieren

• RPKI: ROAs für eigene Prefixes, ROV inbound aktiv, ROA-Lifecycle-Prozess (Änderungen, MaxLength, neue ASN).
• Prefix-Filtering: Strikte Ingress-Filter pro Customer/Downstream; keine unkontrollierten Exporte.
• Max-Prefix-Limits: Pro Session dimensioniert, mit Alarmen und dokumentiertem Runbook.
• BGP Policy Templates: Standardisierte Rollenmodelle (Customer/Peer/Provider) und Export-Regeln.
• Monitoring: Alerts auf Origin-AS-Change, Subprefix-Ankündigungen, Prefix-Spikes, Flap-Rate, Route-Churn.
• Externe Validierung: Regelmäßige Checks von ROA/ROV-Status und Sichtbarkeit über unabhängige Quellen (z. B. RPKI-Validatoren, Operator-Communities).

Für weiterführende, praxisnahe Sicherheitsprinzipien rund um Routing-Security und Zusammenarbeit zwischen Netzbetreibern sind MANRS und die Dokumente in der IETF SIDROPS Working Group sehr hilfreiche Ausgangspunkte.

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.