Störung des Cloudflare-Diensts 1.1.1.1-am 27. Juni 2024

Am 27. Juni 2024 hat eine kleine Gruppe von Nutzern auf der ganzen Welt möglicherweise bemerkt, dass der Dienst 1.1.1.1 nicht erreichbar war oder nicht richtig funktioniert hat. Die Hauptursache dafür war eine Kombination aus BGP (Border Gateway Protokoll)-Hijacking und einem Route-Leak.

Cloudflare hat schon früh begonnen, der Resource Public Key Infrastructure (RPKI) zur Validierung des Routenursprungs (Route Origin Validation – ROV) zu benutzen. Mit RPKI können Eigentümer von IP-Präfixen Eigentümerinformationen sicher speichern und übermitteln. Aandere Betreiber können BGP-Ankündigungen validieren, indem sie empfangene BGP-Routen mit den Daten abgleichen, die in Form von Route Origin Authorizations (ROA) gespeichert sind. Wenn die Route Origin Validation von den Netzwerken ordnungsgemäß durchgesetzt wird und die Präfixe mittels ROA signiert werden, sind die Auswirkungen der Kaperung von BGP sehr begrenzt. Obwohl RPKI seit einigen Jahren auf dem Vormarsch ist und es sich bei 1.1.1.0/24 um eine signierte Ressource handelte, wurde 1.1.1.1/32 während des Vorfalls von ELETRONET SA (AS267613) angekündigt und von mehreren Netzwerken akzeptiert. Dazu zählte mindestens ein großer Provider der 1.1.1.1/32 als Blackhole-Route akzeptierte. Das führte dazu, dass die DNS-Auflösungsadresse aus über 300 Netzwerken in 70 Ländern sofort unerreichbar war, obwohl die Auswirkungen auf den Gesamtanteil der Nutzer recht gering waren (zum Beispiel weniger als 1 Prozent der Nutzer in Großbritannien und Deutschland), und in einigen Ländern haben die Nutzer gar keine Auswirkungen registriert.

Route-Leaks waren bei Cloudflare schon öfter Thema und leider sind heute nur „Best Effort“-Schutzmaßnahmen weit verbreitet, etwa die Filterung der IRR (Internet Routing Registry)-Präfixlisten nach Providern. Im gleichen Zeitraum wie der 1.1.1.1/32-Hijack wurde 1.1.1.0/24 von Nova Rede de Telecomunicações Ltda (AS262504) irrtümlich upstream geleakt. Das Datenleck wurde durch den Peering-1 Global Internet Exchange (AS1031) weiter verbreitet, was auch zu den von den Kunden während des Vorfalls registrierten Auswirkungen beitrug.Wir entschuldigen uns für die Auswirkungen von 1.1.1.1 auf die Nutzer und nehmen den Betrieb des Dienstes sehr ernst. Obwohl die Hauptursache für die Auswirkungen außerhalb von Cloudflare lag, werden wir unsere Erkennungsmethoden weiter verbessern, um kürzere Reaktionszeiten zu erzielen, und unsere Position innerhalb der Internet -Community nutzen, um die Einführung von RPKI-basierten Hijack- und Leak-Präventionsmechanismen weiter zu fördern wie Route Origin Validation (ROV) und Autonomes System Provider Authorization (ASPA)-Objekte für BGP.

2018 ist die Einführung von 1.1.1.1, dem öffentlichen DNS-Auflösungsdienst von Cloudflare, erfolgt. Dieser ist seitdem zu einer der beliebtesten Resolver-IP-Adressen geworden, die von jedem kostenlos genutzt werden können. Mit der Popularität und der leicht erkennbaren IP-Adresse gehen einige betriebliche Schwierigkeiten einher. Diese ergeben sich aus der historischen Verwendung von 1.1.1.1 durch Netzwerke in Laboren oder als Test-IP-Adresse, was zu unerwartetem Traffic oder zu Black Hole Routing führte. Aus diesem Grund ist Cloudflare der Umgang mit den Folgen von fehlgeleitetem Traffic bei BGP-Routing nicht fremd. Auf zwei solcher Fälle werden wir nun näher eingehen.

Ein Teil der Schwierigkeiten entsteht durch mögliches Hijacking von Routen von 1.1.1.1. Wenn beispielsweise fiktive FooBar-Netzwerke einem ihrer Router 1.1.1.1/32 zuweisen und dieses Präfix in ihrem internen Netzwerk weitergeben, werden ihre Kunden Schwierigkeiten haben, zu dem 1.1.1.1-DNS-Dienst weiterzuleiten. Wenn sie das Präfix 1.1.1.1/32 außerhalb ihres unmittelbaren Netzwerks verkünden, können die Auswirkungen sogar noch größer sein. Der Grund, aus dem 1.1.1.1/32 anstelle des von Cloudflare verkündeten BGP 1.1.1.0/24 ausgewählt würde, ist das Longest Prefix Matching (LPM). Während viele Präfixe in einer Routing-Tabelle mit der 1.1.1.1-Adresse übereinstimmen könnten – etwa 1.1.1.0/24, 1.1.1.0/29 und 1.1.1.1/32 –, wird 1.1.1.1/32 von dem LPM-Algorithmus als die längste Übereinstimmung angesehen, weil es die höchste Anzahl identischer Bits und die längste Subnetzmaske aufweist, während es mit der Adresse 1.1.1.1 übereinstimmt. Einfach ausgedrückt würden wir 1.1.1.1/32 als die spezifischste Route bezeichnen, die für 1.1.1.1 verfügbar ist.

An 1.1.1.1 gerichteter Traffic wird also nicht mittels Anycast zu einem der weltweit von Cloudflare betriebenen Server geleitet, sondern landet stattdessen irgendwo auf einem Gerät innerhalb von FooBar Networks. Dort wird 1.1.1.1 beendet und es wird keine legitime Antwort an die Clients zurückgesendet. Dies würde als von den Netzwerkbetreibern innerhalb von FooBar Networks absichtliches oder versehentlich durchgeführtes Kapern (Hijacking) von Anfragen an 1.1.1.1 eingestuft.

Eine weitere Quelle der Beeinträchtigung, mit der wir manchmal bei 1.1.1.1 konfrontiert sind, sind BGP-Route-Leaks. Diese treten auf, wenn ein Netzwerk in Bezug auf eine BGP-Ankündigung zum Upstream für ein Netzwerk wird, für das dies nicht vorgesehen ist.

Es folgt Beispiel für ein Routen-Leak, bei dem ein Kunde Routen, die er von einem Provider erfahren hat, an einen anderen weiterleitet. Dadurch wird ein Leak des Typ 1 verursacht (in RFC7908 definiert).

Wenn genügend Netzwerke innerhalb der Default Free Zone (DFZ) ein Routenleck akzeptieren, kann es in großem Umfang für die Weiterleitung von Traffic über den schlechten Pfad verwendet werden. Dies führt häufig zu einer Überlastung des Netzwerks, das die Präfixe leakt, weil es nicht auf den Umfang des globalen Traffics vorbereitet ist, den es jetzt anzieht. Wir haben von einem großen Route-Leak berichtet, das einen großen Teil des Internet zum Erliegen gebracht hat: Ein Provider in Pennsylvania hat Traffic zu Zielen weltweit geleitet, für die er das normalerweise nie getan hätte. Obwohl Cloudflare insgesamt mit über 13.000 Netzwerken aus der ganzen Welt verbunden ist, kann die BGP-Local-Preference, die einer durchgesickerten Route zugewiesen wird, höher sein als die Route, die ein Netzwerk direkt von Cloudflare erhält. Das klingt zwar kontraproduktiv, kann aber leider passieren.

Zur Erklärung dieses Phänomens ist es hilfreich, sich BGP als Engine für Unternehmensrichtlinien zusammen mit dem Routing-Protokoll für das Internet vorzustellen. Ein Transit-Provider hat Kunden, die ihn für die Beförderung ihrer Daten bezahlen, sodass diesen logischerweise eine höhere lokale BGP-Präferenz zugewiesen wird als Verbindungen mit privatem Peering oder Internet Exchange-Peering. Folglich wird die Verbindung, für die bezahlt wird, am meisten genutzt. Stellen Sie sich lokale Präferenz als eine Möglichkeit vor, die Priorität der ausgehenden Verbindung zu beeinflussen, an die der Traffic gesendet werden soll. Verschiedene Netzwerke können sich außerdem dafür entscheiden, Private Network Interconnects (PNI) Internet Exchange (IX)-Routen vorzuziehen. Ein Grund dafür ist die Zuverlässigkeit, denn eine private Verbindung kann als Punkt-zu-Punkt-Verbindung zwischen zwei Netzwerken ohne dazwischen liegende verwaltete Struktur eines Drittanbieters betrachtet werden, über die man sich Gedanken machen müsste. Kosteneffizienz könnte ein weiterer Grund sein: Wenn Sie sich die Mühe gemacht haben, einen Router-Port zuzuweisen und für eine Querverbindung zwischen sich und einem anderen Peer zu bezahlen, möchten Sie aus dieser natürlich den größtmöglichen Nutzen ziehen.

Es sei darauf hingewiesen, dass sowohl BGP-Hijacking als auch Route-Leaks bei jeder IP-Adresse und jedem Präfix im Internet auftreten können, nicht nur bei 1.1.1.1. Diese Adresse hat aber wie bereits erwähnt einen so hohen Wiedererkennungswert und wurde bereits so häufig missbraucht, dass sie tendenziell anfälliger für versehentliches Hijacking oder Leaks ist als andere IP-Ressourcen.

Während des Vorfalls mit 1.1.1.1 von Cloudflare, der sich am 27. Juni 2024 ereignet hat, mussten wir letzten Endes die Folgen sowohl eines BGP-Hijackings als auch eines Route-Leaks bekämpfen.

Alle Zeitstempel sind in MESZ angegeben.

27.6.2024, 20:51 Uhr AS267613 (Eletronet) beginnt mit der Ankündigung von 1.1.1.1/32 für Peers, Provider und Kunden. 1.1.1.1/32 wird mit der Ursprungs-AS-Nummer AS267613 angekündigt.

27.6.2024, 20:52 Uhr AS262504 (Nova) leakt 1.1.1.0/24, auch empfangen von AS267613, upstream an AS1031 (Peering 1 Global Internet Exchange) mit dem AS-Pfad „1031 262504 267613 13335“.

27.6.2024, 20:52 Uhr AS1031 (Nova vorgelagert) verteilt 1.1.1.0/24 an verschiedene Internet-Exchange-Peers und Route-Server, was die Auswirkungen des Lecks verstärkt.

27.6.2024, 20:52 Uhr Ein Tier-1-Provider erhält die Ankündigung 1.1.1.1/32 von AS267613 als RTBH (Remote Triggered Blackhole)-Route, was Blackholing von Traffic für alle Kunden des Tier-1-Providers verursacht.

27.6.2024, 22:03 Uhr Cloudflare meldet internen Vorfall aufgrund von Problemen bei der Erreichbarkeit von 1.1.1.1 aus verschiedenen Ländern.

27.6.2024, 22:08 Uhr Cloudflare deaktiviert einen Partner-Peering-Standort mit AS267613, der an 1.1.1.0/24 gerichteten Traffic empfängt.

27.6.2024, 22:08 Uhr Das Cloudflare-Team kontaktiert den Peering-Partner AS267613 wegen des Vorfalls.

27.6.2024, 22:10 Uhr AS262504 leakt 1.1.1.0/24 mit einem neuen AS-Pfad, „262504 53072 7738 13335“, der ebenfalls von AS1031 neu verteilt wird. Der Traffic wird auf diesem Pfad erfolgreich an Cloudflare übermittelt, allerdings mit hoher Latenz für die betroffenen Clients.

27.6.2024, 22:17 Uhr Cloudflare befasst sich mit AS262504 bezüglich des Route-Leaks von 1.1.1.0/24 an die Upstream-Provider.

27.6.2024, 22:56 Uhr Cloudflare-Techniker deaktivieren einen zweiten Peering-Punkt mit AS267613, der Traffic für 1.1.1.0/24 von mehreren Ursprüngen außerhalb Brasiliens empfängt.

28.6.2024, 00:16 Uhr AS262504 leakt erneut 1.1.1.0/24 und zieht Traffic zu einem Cloudflare-Peering-Punkt mit AS267613 in São Paulo. Einige 1.1.1.1-Anfragen werden deshalb mit höherer Latenz beantwortet, aber der Hijack von 1.1.1.1/32 und das Traffic-Blackholing scheinen behoben.

28.6.2024, 04:28 Uhr AS262504 behebt das Route-Leak von 1.1.1.0/24 vollständig.

Die Auswirkungen für die Kunden zeigten sich auf zwei Arten: 1) 1.1.1.1 konnte überhaupt nicht erreicht werden; 2) 1.1.1.1 konnte erreicht werden, allerdings mit hoher Latenz pro Anfrage.

Da AS267613 die Adresse 1.1.1.1/32 irgendwo im eigenen Netzwerk gekapert hat, sind viele Anfragen bei einem Gerät in dem autonomen System der Firma fehlgeschlagen. Während des Vorfalls wurden Anfragen an den 1.1.1.1-Dienst zeitweise erfolgreich an die Cloudflare-Rechenzentren weitergeleitet, allerdings mit hoher Latenz.

Betrachtet man zwei Ursprungsländer während des Vorfalls – Deutschland und die Vereinigten Staaten –, sah der betroffene, an 1.1.1.1 gerichtete Traffic folgendermaßen aus:

Ursprungsland der Nutzer:

Dies mag zwar insgesamt einer relativ kleinen Anzahl von Anfragen pro Ursprungsland entsprechen, aber normalerweise würden überhaupt keine Anfragen für 1.1.1.1 aus den USA oder Deutschland nach Brasilien weitergeleitet werden.

Stadt mit Cloudflare-Rechenzentrum

Ein Blick auf die Diagramme zeigt, dass Anfragen an 1.1.1.1 in brasilianischen Rechenzentren eintreffen. Die Lücken zwischen den Spitzen entstehen, wenn 1.1.1.1-Anfragen vor oder innerhalb von AS267613 blockiert werden. Die Spitzen selbst entstehen, wenn der Traffic mit hoher Latenz für die Anfrage und die Antwort an Cloudflare übermittelt wird. Die kurzen Spitzen bei Datenverkehr, der mit AS267613 erfolgreich zum Cloudflare-Peering-Standort übermittelt wurde, könnten darauf zurückzuführen sein, dass bei 1.1.1.1/32 die Routing-Angabe innerhalb des eigenen Netzwerks immer wieder wechselt (Flapping) und somit Traffic gelegentlich zu Cloudflare durchgelassen wird, anstatt dass er irgendwo im Zwischenpfad landet.

Normalerweise wird eine Nutzer-Anfrage an 1.1.1.1 mittels BGP Anycast zum nächstgelegenen Rechenzentrum geleitet. Während des Vorfalls kündigte AS267613 (Eletronet) 1.1.1.1/32 den eigenen Peers und Upstream-Providern an. AS2504 leakte 1.1.1.0/24 upstream, wodurch sich der normale Pfad von BGP Anycast für mehrere Nutzer-Netzwerke drastisch veränderte.

Mit öffentlichen Route-Kollektoren und dem Monocle-Tool können wir nach nicht autorisierten BGP-Updates suchen.

Wir sehen oben, dass AS398465 und AS13760 den Route-Views-Kollektoren gemeldet haben, dass sie 1.1.1.1/32 von AS267613 erhalten haben, als die Auswirkungen begannen. Normalerweise ist das längste IPv4-Präfix, das in der Default-Free-Zone (DFZ) akzeptiert wird, ein /24. In diesem Fall haben wir jedoch beobachtet, dass mehrere Netzwerke die Route 1.1.1.1/32 von AS267613 zur Weiterleitung verwendet haben. Dies wurde durch das Blackholing des Traffics deutlich, der nie an einem Cloudflare-POP (Point of Presence) angekommen ist. Der Ursprung von 1.1.1.1/32 durch AS267613 ist ein BGP-Routen-Hijack. Das Präfix wurde mit dem Ursprung AS267613 angekündigt, obwohl die Route Origin Authorization (ROA) nur für den Ursprung AS13335 (Cloudflare) mit einer maximalen Präfixlänge von /24 signiert ist.

Wir haben sogar BGP-Updates für 1.1.1.1/32 registriert, als wir uns unsere eigenen BMP (BGP Monitoring Protokoll)-Daten bei Cloudflare angeschaut haben. Von mindestens ein paar verschiedenen Routen-Servern haben wir unsere eigene 1.1.1.1/32-Ankündigung über BGP erhalten. Glücklicherweise lehnt Cloudflare diese Routen beim Import sowohl als RPKI Invalid als auch als DFZ Invalid ab, da AS-Ursprung und Präfixlänge ungültig sind. Die BMP-Daten werden vor der Richtlinie angezeigt. Deshalb können wir sehen, wo wir das BGP-Update in einer Peering-Sitzung erhalten, obwohl wir die Route abgelehnt haben.

Mehrere Netzwerke akzeptieren also nicht nur Präfixe, die nicht in der globalen Routing Tabelle existieren sollten, sondern auch eine RPKI (Resource Public Key Infrastructure) Invalid-Route. Erschwerend kam hinzu, dass ein Tier-1-Transit-Provider die 1.1.1.1/32-Ankündigung als RTBH (Remote-Triggered Blackhole)-Route von AS267613 akzeptierte und jeglichen Traffic an seiner Edge verwarf, der normalerweise zu Cloudflare geleitet würde. Dies allein hatte weitreichende Folgen, da alle Netzwerke, die diesen Tier-1-Provider für das Routing zu 1.1.1.1 nutzten, die IP-Adresse während des Vorfalls nicht erreichen konnten.

monocle search --start-ts 2024-06-27T18:51:00Z --end-ts 2024-06-27T18:55:00Z --prefix '1.1.1.1/32'

A|1719514377.130203|206.126.236.209|398465|1.1.1.1/32|398465 267613|IGP|206.126.236.209|0|0||false|||route-views.eqix
–
A|1719514377.681932|206.82.104.185|398465|1.1.1.1/32|398465 267613|IGP|206.82.104.185|0|0|13538:1|false|||route-views.ny
–
A|1719514388.996829|198.32.132.129|13760|1.1.1.1/32|13760 267613|IGP|198.32.132.129|0|0||false|||route-views.telxatl

Für diejenigen, die mit Remote-Triggered Blackholing nicht vertraut sind: Es handelt sich um eine Methode, einem Provider eine Reihe von Zielen innerhalb seines Netzwerks zu nennen, für die Traffic verworfen werden soll. Sie dient als schlichte Methode zur Abwehr von DDoS-Angriffen. Wenn Sie auf einer bestimmten IP-Adresse oder einem bestimmten Präfix angegriffen werden, können Sie Ihren Upstream-Provider anweisen, den gesamten Traffic in Richtung dieser Ziel-IP-Adresse oder dieses Präfixes zu absorbieren. Dies geschieht, indem er ihn verwirft, bevor er Ihren Netzwerk-Port erreicht. Das Problem bei diesem Vorfall war, dass AS267613 nicht autorisiert war, 1.1.1.1/32 zu blockieren. Nur Cloudflare sollte das Recht haben, RTBH für das Verwerfen von an AS13335 gerichteten Traffic zu nutzen, was wir in Wirklichkeit niemals tun würden.

Als Nächstes schauen wir uns die BGP-Updates für 1.1.1.0/24 an, bei denen mehrere Netzwerke das Präfix von AS262504 erhalten und akzeptiert haben.

Auch hier achten wir wieder auf den AS-Pfad. Dieses Mal ist AS13335 das ursprünglich AS ganz am Ende der Ankündigungen. Diese BGP-Ankündigung ist RPKI Valid, da der Ursprung korrekterweise AS13335 ist. Es handelt sich hier jedoch um ein Routen-Leak von 1.1.1.0/24, da der Pfad selbst ungültig ist.

Betrachtet man einen Beispielpfad, „199524 1031 262504 267613 13335“, dann ist AS267613 13335 funktional ein Peer von AS13335. Dieser sollte die Ankündigung 1.1.1.0/24 nicht an seine Peers oder seine Upstreams weitergeben, sondern nur an seine Kunden (AS Cone). AS262504 ist Kunde von AS267613 und der nächsten benachbarten AS-Nummer im Pfad, sodass diese konkrete Ankündigung bis zu diesem Punkt in Ordnung ist. Der Fehler von 1.1.1.0/24 schleicht sich bei AS262504 ein, wo das Präfix dem vorgelagerten AS1031 bekannt gegeben wird. Darüber hinaus übermittelt AS1031 die Ankündigung an die eigenen Peers.

~> monocle search --start-ts 2024-06-27T20:10:00Z --end-ts 2024-06-27T20:13:00Z --prefix '1.1.1.0/24' --as-path ".* 267613 13335" --include-sub

.. some advertisements removed for brevity ..

A|1719519011.378028|187.16.217.158|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|187.16.217.158|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views2.saopaulo
–
A|1719519011.629398|45.184.147.17|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|45.184.147.17|0|0|1031:1031 1031:4209 1031:4259 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519036.943174|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|route-views.amsix
–
A|1719519037|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|rrc03
–
A|1719519087.4546|45.184.146.59|199524|1.1.1.0/24|199524 1031 262504 267613 13335|IGP|45.184.147.17|0|0||false|13335|162.158.177.1|route-views.fortaleza
A|1719519087.464375|45.184.147.74|264409|1.1.1.0/24|264409 1031 262504 267613 13335|IGP|45.184.147.74|0|0|65100:7010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519096.059558|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3
–
A|1719519128.843415|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3

Somit ist AS262504 das Leaking-Netzwerk. AS1031 hat das Leak des Kunden AS262504 akzeptiert und durch die Verteilung der Route auf mehrere Peering-Standorte weltweit weitreichende Folgen verursacht. AS1031 (Peering-1 Global Internet Exchange) bezeichnet sich selbst als globalen Peering-Knoten. Cloudflare ist kein Kunde von AS1031, daher hätte 1.1.1.0/24 niemals an Peers, Route-Server oder vorgelagerte Server von AS1031 weiterübermittelt werden dürfen. Es zeigt sich, dass AS1031 keine umfassende Filterung für BGP-Sitzungen von Kunden durchführt, sondern stattdessen nur die Adjacency (in diesem Fall AS262504) abgleicht und alles weiterverteilt, was diese Kriterien erfüllt. Dies ist leider im Hinblick auf AS1031 unverantwortlich und hat direkte Auswirkungen auf 1.1.1.1 und möglicherweise auf andere Dienste, die der ungeschützten Routen-Weiterübermittlung zum Opfer fallen. Während das ursprünglich geleakte Netzwerk AS262504 war, wurden die Auswirkungen durch AS1031 und andere erheblich verstärkt, als diese das Hijacking oder das Leak akzeptierten und die Ankündigungen weiter verbreiteten.

Während eins Großteils des Vorfalls führte das Leak durch AS262504 dazu, dass letztendlich Anfragen AS267613 erreichten, wo 1.1.1.1/32-Traffic irgendwo im Netzwerk verworfen wurde. AS262504 hat durch das vorgelagerte Leaken von Routen die Auswirkungen in Bezug auf die Nichterreichbarkeit von 1.1.1.1 nur noch verstärkt.

Um die Auswirkungen des Route-Leaks zu begrenzen, hat Cloudflare das Peering mit AS267613 an mehreren Standorten deaktiviert. Das Problem ließ sich jedoch nicht vollständig beheben, da AS262504 immer noch einen veralteten, auf São Paulo verweisenden Pfad leakte. In São Paulo eingehende Anfragen konnten zugestellt werden, allerdings mit einer langen Round-Trip Time. Cloudflare hat mit allen in diesem Beitrag erwähnten Netzwerken im Hinblick auf das Leck und zukünftige Präventionsmechanismen sowie mit mindestens einem Tier-1-Transit-Provider zusammengearbeitet, der 1.1.1.1/32 von AS267613 als von Cloudflare nicht autorisierte Blackhole-Route akzeptierte hatte, was weitreichende Folgen hatte.

RPKI-UrsprungsvalidierungRPKI hat vor Kurzem einen wichtigen Meilenstein von 50 Prozent Implementierung in Bezug auf die von Route Origin Authorization (ROA) signierten Präfixe erreicht. RPKI trägt sicherlich dazu bei, die Verbreitung eines gekaperten BGP-Präfixes im gesamten Internet zu begrenzen. Doch alle Netzwerke müssen ihren Teil dazu beitragen, insbesondere große Netzwerke mit einer hohen Anzahl nachgelagerter autonomer Systeme (AS). Während des Hijackings von 1.1.1.1/32 haben mehrere Netzwerke die von AS267613 angekündigte Route für die Traffic-Weiterleitung akzeptiert und verwendet.

RPKI und Remote-Triggered Blackholing (RTBH)Ein erheblicher Teil der Auswirkungen dieses Vorfalls war darauf zurückzuführen, dass ein Tier-1-Provider 1.1.1.1/32 als Blackhole-Route von einem Drittanbieter akzeptierte, bei dem es sich nicht um Cloudflare handelte. Dies stellt an sich schon ein Hijacking von 1.1.1.1 dar, und zwar ein sehr gefährliches. RTBH ist ein nützliches Tool, das von vielen Netzwerken eingesetzt wird, wenn sie dringend einen Schutz vor großen DDoS-Angriffen suchen. Das Problem ist, dass die für RTBH verwendete BGP-Filterung lax ist und sich oft nur auf AS-SET-Objekte in Internet-Routing-Registrys stützt. Eine Route Origin Authorization (ROA) wäre für die RTBH-Filterung nicht praktikabel, da dabei für ein Netzwerk von der Größe von Cloudflare Tausende von potenziellen ROA erstellt werden müssten. Darüber hinaus besteht durch die Erstellung spezifischer /32-Einträge die Möglichkeit, dass eine einzelne Adresse wie 1.1.1.1/32 von jemandem, der vorgibt, AS13335 zu sein, angekündigt wird, dann zur besten Route zu 1.1.1.1 im Internet wird, was schwerwiegende Folgen nach sich zieht.

Die AS-SET-Filterung ist nicht repräsentativ für die Befugnis, eine Route wie 1.1.1.1/32 einem Blackholing zu unterziehen. Nur Cloudflare sollte in der Lage sein, ein Ziel zu blockieren, für das wir über die Betriebsrechte verfügen. Eine Möglichkeit, die laxe Filterung von Anbietern in RTBH-Sitzungen zu beheben, wäre wiederum die Verwendung eines RPKI. Um ein Beispiel der IETF zu nennen: Der inzwischen abgelaufene draft-spaghetti-sidrops-rpki-doa-00-Vorschlag spezifizierte ein Discard Origin Authorization (DOA)-Objekt, das verwendet werden würde, um nur bestimmten Ursprüngen zu erlauben, eine Blackhole-Aktion für ein Präfix zu autorisieren. Wenn ein solches Objekt signiert worden wäre und RTBH-Anfragen anhand des Objekts validiert worden wären, wäre der nicht autorisierte Blackhole-Versuch von 1.1.1.1/32 durch AS267613 ungültig und vom Tier-1-Anbieter nicht akzeptiert worden.

Best Practices für BGPDie einfache Befolgung der von MANRS festgelegten Best Practices für BGP und die Ablehnung von IPv4-Präfixen, die länger als ein /24 in der Default-Free-Zone (DFZ) sind, hätte die Auswirkungen für 1.1.1.1 reduziert. Die Ablehnung ungültiger Präfixlängen innerhalb des übergordneten Internet sollte bei allen Netzwerken Teil einer Standard-BGP-Richtlinie sein.

Route-Leaks sind für Cloudflare heute nicht unvermeidlich. Doch das Internet ist für Interconnections naturgemäß auf Vertrauen angewiesen. Deshalb werden wir einige Schritte unternehmen, um die Folgen zu begrenzen.

Wir haben die Datenquellen für unser Route-Leak-Erkennungssystem ausgeweitet, um mehr Netzwerke abzudecken. Außerdem sind wir dabei, Echtzeitdaten in das Erkennungssystem einzubinden, um künftig schneller auf ähnliche Ereignisse reagieren zu können.

Wir werden uns weiterhin für die Einführung von RPKI in die auf AS-Pfaden basierende Route-Leak-Prävention einsetzen. ASPA (Autonomous System Provider Authorization)-Objekte ähneln ROA. Das AS selbst wird jedoch nicht mit einem autorisierten Ursprungs-AS signiert, sondern mit einer Liste von Provider-Netzwerken, die die Routen weiterverbreiten dürfen. Im Fall von Cloudflare würden also nur gültige vorgelagerte Transit-Provider die Signatur erhalten, wonach sie autorisiert sind, AS13335-Präfixe wie 1.1.1.0/24 anzukündigen.

In dem Beispiel des Route-Leaks, bei dem AS262504 (Kunde von AS267613) 1.1.1.0/24 vorgelagert weiterverbreitet hat, würde BGP ASPA dieses Leak erkennen, wenn AS267613 die autorisierten Provider mit einer Signatur versehen und AS1031 die Pfade anhand dieser Liste validiert hätte. Ähnlich wie bei der RPKI-Ursprungsvalidierung ist dies jedoch ein langfristiges Unterfangen. Damit das Verfahren funktioniert, müssen außerdem Netzwerke, insbesondere solche von großen Providern, ungültige AS-Pfade anhand von ASPA-Objekten ablehnen.

Es gibt alternative Ansätze zu ASPA, die sich in verschiedenen Stadien der Einführung befinden und möglicherweise von Interesse sind. Eine Garantie, dass die folgenden Ansätze im Internet zu gegebener Zeit weite Verbreitung finden, besteht jedoch nicht.

RFC9234 beispielsweise verwendet ein Konzept von Peer-Rollen innerhalb von BGP-Funktionen und -Attributen. Je nach Konfiguration des Routers entlang eines Pfads für Updates kann Präfixen ein „Only-To-Customer“ (OTC)-Attribut hinzugefügt werden, welches die Upstream-Verbreitung eines Präfixes wie 1.1.1.0/24 entlang eines geleakten Pfads verhindert. Der Nachteil hierbei ist, dass die BGP-Konfiguration abgeschlossen sein muss, um jeder Peering-Sitzung die verschiedenen Rollen zuzuweisen. Zudem muss die Akzeptanz bei den Anbietern vollständig geklärt sein, damit dies für den tatsächlichen Einsatz unter Produktivbedingungen mit positiven Ergebnissen umgesetzt werden kann.

Wie bei allen Ansätzen zur Behebung von Route-Leaks ist auch hier für den Erfolg die Zusammenarbeit zwischen Netzwerkbetreibern im Internet erforderlich.

Der 1.1.1.1.-Dienst von Cloudflare zur DNS-Auflösung ist gleichzeitig Opfer eines BGP-Hijackings und eines BGP-Route-Leaks geworden. Obwohl das Vorgehen externer Netzwerke nicht der direkten Kontrolle von Cloudflare unterliegt, wollen wir sowohl innerhalb der Internet-Community als auch intern jeden Schritt unternehmen, um Auswirkungen schneller zu erkennen und die Folgen für unsere Nutzer abzumildern.

Langfristig unterstützt Cloudflare weiterhin die Einführung der RPKI-basierten Ursprungsvalidierung sowie der AS-Pfadvalidierung. Erstere wird in einer Vielzahl der größten Netzwerke der Welt eingesetzt, und Letzteres befindet sich bei der IETF (Internet Engineering Task Force) noch im Entwicklungsstadium. Um in der Zwischenzeit zu überprüfen, ob Ihr ISP eine RPKI-Ursprungsvalidierung durchsetzt, können Sie isbgpsafeyet.com aufrufen und dort Ihren ISP testen.