Wie wir Route-Leaks erkennen und unser neuer Cloudflare Radar-Dienst für Route-Leaks

Heute stellen wir die Route-Leak-Daten und die API von Cloudflare Radar vor, damit sich alle Interessierten über Routen-Lecks im Internet informieren können. Wir haben ein umfassendes System entwickelt, das sowohl Daten aus öffentlichen Quellen einbezieht als auch Cloudfares Sicht auf das Internet, die aus unserem riesigen globalen Netzwerk stammt. Das System liefert jetzt Route-Leak-Daten auf den ASN-Seiten von Cloudflare Radar und über die API.

Dieser Blogbeitrag besteht aus zwei Teilen. Zunächst geht es um BGP und Route-Leaks, gefolgt von Details zu unserem System zur Erkennung von Route-Leaks und wie es Cloudflare Radar mit Daten speist.

Inter-Domain Routing, d. h. der Austausch von Erreichbarkeitsinformationen zwischen Netzwerken, ist entscheidend für die Funktionsfähigkeit und Performance des Internets. Das Border Gateway Protocol (BGP) ist das de facto Routing-Protokoll, das Routing-Informationen zwischen Organisationen und Netzwerken austauscht. Im Kern geht BGP davon aus, dass die ausgetauschten Informationen echt und vertrauenswürdig sind, was im heutigen Internet leider nicht mehr der Fall ist. In vielen Fällen machen Netzwerke Fehler oder täuschen absichtlich Informationen über die Erreichbarkeit vor und verteilen diese an den Rest des Internets. Solche Vorfälle führen zu erheblichen Störungen des Normalbetriebs des Internets. Eine solche Störung sind Route-Leaks.

Wir betrachten Route-Leaks als die Verteilung von Routenankündigungen über ihren beabsichtigten Umfang hinaus (RFC7908). Route-Leaks führen zu erheblichen Störungen für Millionen von Nutzern, wie wir bei vielen bemerkenswerten Vorfällen in der Vergangenheit gesehen haben. So wurde im Juni 2019 durch eine Fehlkonfiguration in einem kleinen Netzwerk im US-Bundesstaat Pennsylvania (AS396531 – Allegheny Technologies Inc) versehentlich ein Cloudflare-Präfix an Verizon geleakt, das daraufhin die falsch konfigurierte Route an den Rest seiner Peers und Kunden verteilte. Infolgedessen wurde der Traffic eines großen Teils des Internets durch die kapazitätsbeschränkten Leitungen eines kleinen Netzwerks gequetscht. Die daraus resultierende Überlastung führte dazu, dass der Großteil des Traffics von und zu dem betroffenen IP-Bereich von Cloudflare verworfen wurde.

Ein ähnlicher Vorfall im November 2018 führte zu einer weitreichenden Nichtverfügbarkeit von Google-Diensten, als ein nigerianischer ISP (AS37282 – Mainone) versehentlich eine große Anzahl von Google-IP-Präfixen an seine Peers und Provider leakte und damit das Prinzip der Valley-Free-Prinzip verletzte.

Diese Vorfälle zeigen nicht nur die großen Auswirkungen von Route-Leaks, sondern auch den Schneeballeffekt, den Fehlkonfigurationen in kleinen regionalen Netzwerken auf das globale Internet haben können.

So kritisch es auch ist, Route-Leaks sofort zu erkennen und zu beheben, werden sie oft erst erkannt, wenn Nutzer über die spürbaren Auswirkungen der Leaks berichten. Die Herausforderung bei der Erkennung und Prävention von Route-Leaks liegt darin, dass die AS-Geschäftsbeziehungen und BGP-Routing-Richtlinien in der Regel nicht offengelegt werden und das betroffene Netzwerk oft weit von der Ursache des Route-Leaks entfernt ist.

In den letzten Jahren wurden Lösungsansätze zur Prävention der Verteilung von Route-Leaks vorgeschlagen. Zu diesen Vorschlägen gehören RFC9234 und ASPA, die BGP erweitern, um Sitzungen mit dem Beziehungstyp zwischen den beiden verbundenen AS-Netzwerken zu kennzeichnen, sodass Route-Leaks aufgespürt und verhindert werden können.

Ein anderer Vorschlag zur Implementierung einer ähnlichen Signalisierung von BGP-Rollen ist die Verwendung von BGP-Communities, einem transitiven Attribut zur Kodierung von Metadaten in BGP-Ankündigungen. Obwohl diese Ansätze langfristig vielversprechend sind, befinden sie sich noch in einem sehr frühen Stadium und mit einer baldigen Umsetzung in großem Maßstab ist nicht zu rechnen.

Bei Cloudflare haben wir ein System entwickelt, das Route-Leak-Events automatisch erkennt und sie mit Benachrichtigungen an mehrere Kanäle sichtbar macht. Wir bemühen uns weiterhin, der Öffentlichkeit mehr relevante Daten zur Verfügung zu stellen und geben mit Freude bekannt, dass wir heute eine offene Daten-API für unsere Route-Leak-Erkennungsergebnisse starten und die Ergebnisse in die Seiten von Cloudflare Radar integrieren.

Doch bevor wir näher auf die Entwicklung unserer Systeme eingehen, erklären wir zunächst kurz, was ein Route-Leak ist und warum er unbedingt erkannt werden muss.

Zur Definition von Route-Leaks beziehen wir uns auf das von der IETF veröffentlichte Dokument RFC7908 „Problem Definition and Classification of BGP Route Leaks“.

> Ein Route-Leak ist die Propagierung von Routenankündigungen über den beabsichtigten Geltungsbereich hinaus.

Der beabsichtigte Geltungsbereich wird oft konkret als Inter-Domain-Routing-Richtlinien definiert, basierend auf Geschäftsbeziehungen zwischen Autonomen Systemen (AS). Diese Geschäftsbeziehungen lassen sich grob in vier Kategorien einteilen: Kunden, Transit Provider, Peers und Siblings, aber auch komplexere Arrangements sind möglich.

Bei einer Kunden-Anbieter-Beziehung vereinbart das Kunden-AS mit einem anderen Netzwerk, seinen Traffic in die globale Routing-Tabelle zu übertragen. In einer Peer-to-Peer-Beziehung vereinbaren zwei AS einen freien bilateralen Traffic-Austausch, allerdings nur zwischen ihren eigenen IPs und den IPs ihrer Kunden. AS, die derselben Verwaltungseinheit angehören, werden als Siblings betrachtet, und ihr Traffic-Austausch unterliegt oft keinen Beschränkungen.  Die folgende Abbildung zeigt, wie sich die drei wichtigsten Beziehungstypen auf die Exportrichtlinien auswirken.

Indem wir die Arten von Beziehungen auf AS-Ebene und ihre Auswirkungen auf die Propagierung von BGP-Routen kategorisieren, können wir mehrere Phasen einer Präfix-Ursprungsankündigung während der Propagierung definieren:

• upward: alle Pfadsegmente während dieser Phase sind vom Kunden zum Provider

• Peering: ein Peer-Peer-Pfadsegment

• downward: alle Pfadsegmente in dieser Phase sind von Provider zu Kunde

Ein AS-Pfad, der dem Prinzip des Valley-Free-Routing folgt, hat Upward-, Peering- und Downward-Phasen, die alle optional sind, aber in dieser Reihenfolge erfolgen müssen. Hier ist ein Beispiel für einen AS-Pfad, der dem Valley-Free-Routing entspricht.

In RFC7908, „Problem Definition and Classification of BGP Route Leaks“ definieren die Autoren sechs Arten von Route-Leaks, auf die wir uns bei unserem Systemaufbau beziehen. Im Folgenden stellen wir die einzelnen Typen von Route-Leaks vor.

> Ein Multihomed-AS lernt eine Route von einem Upstream-ISP und verteilt sie einfach an einen anderen Upstream-ISP (was im Wesentlichen einer Serpentine ähnelt).  Weder das Präfix noch der AS-Pfad werden in der Aktualisierung geändert.

Ein AS-Pfad, der ein Provider-Kunden- und ein Kunden-Provider-Segment enthält, gilt als Typ-1-Leak. Das folgende Beispiel: AS4 → AS5 → AS6 bildet ein Typ-1-Leak.

Typ 1 ist die bekannteste Art von Route-Leaks und hat große Auswirkungen. In vielen Fällen ist eine Kundenroute besser als eine Peer- oder Provider-Route. In diesem Beispiel wird AS6 den Traffic wahrscheinlich lieber über AS5 als über seine anderen Peer- oder Provider-Routen schicken, wodurch AS5 ungewollt zum Transit-Provider wird. Dies kann die Performance des Traffics im Zusammenhang mit dem geleakten Präfix erheblich beeinträchtigen oder zu Ausfällen führen, wenn das geleakte AS nicht für die Bewältigung eines großen Traffic-Aufkommens ausgelegt ist.

Im Juni 2015 hat Telekom Malaysia (AS4788), ein regionaler ISP, über 170.000 von seinen Providern und Peers erlernte Routen an seinen anderen Provider Level3 (AS3549, jetzt Lumen) geleakt. Level3 akzeptierte die Routen und verteilte sie weiter an seine nachgelagerten Netzwerke, was wiederum weltweit zu erheblichen Netzwerkproblemen führte.

Ein Typ-2-Leak ist definiert als die Verteilung von Routen, die von einem Peer zu einem anderen Peer erhalten wurden, wodurch zwei oder mehr aufeinanderfolgende Peer-to-Peer-Pfadsegmente entstehen.

Hier ist ein Beispiel: AS3 → AS4 → AS5 bildet einen Typ-2-Leak.

Ein Beispiel für solche Leaks ist das Auftreten von mehr als drei sehr großen Netzwerken in Folge. Sehr große Netzwerke (wie z. B. Verizon und Lumen) kaufen keine Transitleistungen voneinander, und wenn mehr als drei solcher Netzwerke nacheinander auf dem Pfad auftauchen, ist das oft ein Hinweis auf ein Route-Leak.

In der Praxis ist es jedoch nicht ungewöhnlich, dass mehrere kleine Peering-Netzwerke Routen austauschen und sich gegenseitig weiterleiten. Für diese Art von Netzwerkpfad gibt es legitime wirtschaftliche Gründe. Diese Art von Route-Leaks macht uns weniger Sorgen als Typ 1.

Bei diesen beiden Arten werden die Routen von einem Provider oder einem Peer nicht an einen Kunden, sondern an einen anderen Peer oder Provider verteilt. Hier sind die Illustrationen der beiden Arten von Leaks:

Wie in dem bereits erwähnten Beispiel hat ein nigerianischer ISP, der mit Google zusammenarbeitet, versehentlich seine Route zu seinem Provider AS4809 geleakt und damit ein Route-Leak vom Typ 4 erzeugt. Da Routen über Kunden in der Regel anderen vorgezogen werden, leitete der große Provider (AS4809) seinen Traffic über seinen Kunden, d. h. den „durchgesickerten“ ASN, zu Google um, überwältigte den kleinen ISP und legte Google für über eine Stunde lahm.

Bisher haben wir uns die vier in RFC7908 definierten Arten von Route-Leaks angeschaut. Allen vier Arten von Route-Leaks ist gemeinsam, dass sie über AS-Beziehungen definiert sind, d. h. über Peers, Kunden und Provider. Wir fassen die Arten von Leaks zusammen, indem wir die Propagierung der AS-Pfade danach kategorisieren, woher die Routen gelernt werden und wohin sie verteilt werden. Die Ergebnisse sind in der folgenden Tabelle dargestellt.

Routet von / verteilt zum

Routes from / propagates to	To provider	To peer	To customer
From provider	Type 1	Type 3	Normal
From peer	Type 4	Type 2	Normal
From customer	Normal	Normal	Normal

Zum Provider

Zum Peer

Zum Kunden

Vom Provider

Typ 1

Typ 3

Normal

Vom Peer

Typ 4

Typ 2

Normal

Vom Kunden

Normal

Normal

Normal

Wir können die gesamte Tabelle in einer einzigen Regel zusammenfassen: Routen, die von einem Nicht-Kunden-AS stammen, können nur an Kunden propagiert werden.

Hinweis: Route-Leaks vom Typ 5 und 6 sind definiert als Re-Originierung von Präfixen und Ankündigung privater Präfixe. Typ 5 steht in engerem Zusammenhang mit Präfix-Hijackings, auf die wir unser System in den nächsten Schritten ausweiten wollen, während Leaks vom Typ 6 außerhalb des Rahmens dieser Arbeit liegen. Mehr dazu finden Sie in den Abschnitten 3.5 und 3.6 von RFC7908.

Nachdem wir nun wissen, was ein Route-Leak ist, schauen wir uns an, wie wir unser System zur Erkennung von Route-Leaks entwickelt haben.

Auf einer sehr hohen Ebene unterteilen wir unser System in drei verschiedene Komponenten:

1. Modul zur Sammlung von Rohdaten: verantwortlich für das Sammeln von BGP-Daten aus verschiedenen Quellen und die Bereitstellung des BGP-Nachrichtenstroms für nachgelagerte Verbraucher.

2. **Modul zur Erkennung von Leaks:**Es erkennt, ob es sich bei einem bestimmten Pfad auf AS-Ebene um ein Route-Leak handelt, schätzt das Konfidenzniveau der Bewertung ab, aggregiert alle externen Beweise, die für die weitere Analyse des Events benötigt werden, und stellt sie bereit.

3. **Modul zur Speicherung und Benachrichtigung:**verantwortlich für den Zugriff auf erkannte Route-Leaks-Events und das Versenden von Benachrichtigungen an relevante Parteien. Dies könnte auch den Aufbau eines Dashboards für den einfachen Zugriff und die Suche nach vergangenen Events sowie die Bereitstellung der Nutzeroberfläche für die Analyse des Events auf höchster Ebene umfassen.

Wir berücksichtigen drei Arten der Dateneingabe:

1. Historisch: BGP-Archivdateien für eine bestimmte Zeitspanne in der Vergangenheita. RouteViews und RIPE RIS BGP-Archive

2. Semi-Echtzeit: BGP-Archivdateien, sobald sie verfügbar sind, mit einer Verzögerung von 10–30 Minutena. RouteViews und RIPE RI-Archive mit Datenbroker, der regelmäßig neue Dateien prüft (z. B. BGPKIT Broker)

3. Echtzeit: echte Echtzeit-Datenquellena. RIPE RIS Liveb. Cloudflare-interne BGP-Quellen

In der aktuellen Version verwenden wir die Semi-Echtzeit-Datenquelle für das Erkennungssystem, d. h. die BGP-Update-Dateien von RouteViews und RIPE RIS. Der Vollständigkeit halber verarbeiten wir die Daten aller öffentlichen Collectors dieser beiden Projekte (insgesamt 63 Collectors und über 2.400 Collector-Peers) und implementieren eine Pipeline, die in der Lage ist, die BGP-Daten zu verarbeiten, sobald die Datendateien verfügbar sind.

Für die Indizierung und Verarbeitung der Dateien haben wir eine lokale BGPKIT-Broker-Instanz mit aktiviertem Kafka-Feature für die Nachrichtenübermittlung und eine benutzerdefinierte Pipeline eingerichtet, für die gleichzeitige Verarbeitung von MRT-Daten auf der Grundlage des BGPKIT Parser Rust SDK. Das Modul zur Datensammlung verarbeitet MRT-Dateien und konvertiert die Ergebnisse in einen BGP-Nachrichtenstrom mit über zwei Milliarden BGP-Nachrichten pro Tag (etwa 30.000 Nachrichten pro Sekunde).

Das Modul zur Erkennung von Route-Leaks arbeitet auf der Ebene der einzelnen BGP-Ankündigungen. Die Erkennungskomponente untersucht eine BGP-Nachricht nach der anderen und schätzt ab, wie wahrscheinlich es sich bei einer bestimmten BGP-Nachricht um das Ergebnis eines Route-Leaks-Events handelt.

Wir stützen unseren Erkennungsalgorithmus hauptsächlich auf das Valley-Free-Modell – wir glauben, dass damit die meisten bemerkenswerten Route-Leaks erkannt werden können. Wie bereits erwähnt, liegt der Schlüssel zu einer geringen Anzahl falsch-positiver Ergebnisse bei der Erkennung von Route-Leaks mit dem Valley-Free-Modell in genauen Beziehungen auf AS-Ebene. Obwohl diese Beziehungstypen nicht von jedem AS veröffentlicht werden, gibt es bereits seit über zwei Jahrzehnten Forschungsarbeiten zur Ableitung der Beziehungstypen unter Verwendung öffentlich beobachteter BGP-Daten.

Zwar haben sich moderne Algorithmen zur Ableitung von Beziehungen als sehr genau erwiesen, doch selbst eine geringe Fehlermarge kann bei der Erkennung von Route-Leaks noch zu Ungenauigkeiten führen. Um solche Artefakte zu vermeiden, fassen wir mehrere Datenquellen für die Ableitung von Beziehungen auf AS-Ebene zusammen, darunter die CAIDA/UCSD AS-Beziehungsdaten und unseren selbst erstellten AS-Beziehungsdatensatz. Aufbauend auf den beiden AS-Beziehungen erstellen wir einen wesentlich detaillierteren Datensatz auf der Ebene der einzelnen Präfixe und der einzelnen Peers. Mit dem verbesserten Datensatz können wir die Frage beantworten, wie die Beziehung zwischen AS1 und AS2 in Bezug auf das Präfix P aussieht, das von Collector Peer X beobachtet wird. Dies beseitigt einen Großteil der Mehrdeutigkeit in Fällen, in denen Netzwerke mehrere unterschiedliche Beziehungen auf der Grundlage von Präfixen und geografischen Standorten haben, und reduziert so die Anzahl der falsch-positiven Ergebnisse im System. Neben den AS-Beziehungsdatensätzen verwenden wir auch den AS-Hegemonie-Datensatz von IHR IIJ, um falsch-positive Ergebnisse weiter zu reduzieren.

Nach der Verarbeitung jeder BGP-Nachricht speichern wir die generierten Route-Leak-Einträge in einer Datenbank zur langfristigen Aufbewahrung und Auswertung. Außerdem fassen wir einzelne BGP-Ankündigungen von Route-Leaks zusammen und gruppieren relevante Leaks aus demselben Leak-ASN innerhalb eines kurzen Zeitraums zu Route-Leak-Events. Die Route-Leak-Events können dann von verschiedenen nachgelagerten Anwendungen genutzt werden, z. B. Web-UIs, einer API oder Warnmeldungen.

Cloudflare möchte zu einem besseren Internet beitragen, und dazu gehört auch, dass wir unsere Arbeit an der Überwachung und Sicherung des Internet-Routings teilen. Heute geben wir unser System zum Erkennen von Route-Leaks als öffentliche Beta-Version frei.

Ab heute finden Nutzer auf den ASN-Seiten von Cloudflare Radar eine Liste der Route-Leaks, die diese AS betreffen. Wir gehen davon aus, dass eine AS betroffen ist, wenn die Leaker-AS in irgendeiner Richtung einen Hop von ihr entfernt ist, egal ob davor oder danach.

Die ASN-Seite von Cloudflare Radar ist direkt über https://radar.cloudflare.com/as{ASN} zugänglich. Gehen Sie zum Beispiel auf https://radar.cloudflare.com/as174, um die Übersichtsseite für Cogent AS174 anzuzeigen. Die ASN-Seiten zeigen jetzt eine spezielle Karte für Route-Leaks, die für den aktuellen ASN innerhalb des ausgewählten Zeitraums erkannt wurden.

Nutzer können auch unsere öffentliche Daten-API verwenden, um Route-Leak-Events in Bezug auf einen beliebigen ASN abzurufen. Unsere API unterstützt die Filterung der Ergebnisse von Route-Leaks nach Zeitspannen und beteiligten AS. Hier sehen Sie einen Screenshot der API-Dokumentationsseite zu Route-Leak-Events auf der neu aktualisierten API-Docs-Seite.

Was die Erkennung von Route-Leaks betrifft, haben wir noch viel mehr geplant. Weitere Features wie eine globale Ansichtsseite, Route-Leaks-Benachrichtigungen, erweiterte APIs, benutzerdefinierte Automatisierungsskripte und historische Archivdatensätze werden im Laufe der Zeit auf Cloudflare Radar verfügbar sein. Ihr Feedback und Ihre Vorschläge sind ebenfalls sehr wichtig für uns, damit wir unsere Erkennungsergebnisse weiter verbessern und der Öffentlichkeit bessere Daten zur Verfügung stellen können.

Darüber hinaus werden wir unsere Arbeit an anderen wichtigen Themen der Internet-Routing-Sicherheit weiter ausbauen. Dazu gehören die globale Erkennung von BGP-Hijacks (nicht auf unsere Kundennetzwerke beschränkt), die Überwachung der RPKI-Überprüfung, Open-Sourcing-Tools und Architekturdesigns sowie ein zentrales Web-Gateway für Routing-Sicherheit. Unser Ziel ist es, den Communities die besten Daten und Tools für Routing-Sicherheit zur Verfügung zu stellen, damit wir gemeinsam ein besseres und sichereres Internet aufbauen können.

In der Zwischenzeit haben wir einen Radar-Raum auf unserem Developers Discord Server eröffnet. Treten Sie bei und sprechen Sie mit uns. Das Team freut sich auf Ihr Feedback und beantwortet gerne Ihre Fragen.

Besuchen Sie Cloudflare Radar für weitere Einblicke in das Internet. Folgen Sie uns auch gerne auf Twitter für weitere Radar-Updates.