Jetzt abonnieren, um Benachrichtigungen über neue Beiträge zu erhalten:

Wie Verizon und ein BGP Optimizer heute große Teile des Internets ausgeknockt haben

2019-06-24

Lesezeit: 5 Min.
Dieser Beitrag ist auch auf English, Français, 日本語, und 简体中文 verfügbar.

Gewaltiges Routen-Leak beeinträchtigt große Teile des Internets, einschließlich Cloudflare

Was ist passiert?

Heute um 10:30 Uhr UTC erlitt das Internet einen kleinen Herzinfarkt. Ein kleines Unternehmen in Nord-Pennsylvania wurde zum bevorzugten Pfad vieler Internetrouten über Verizon (AS701), einem großen Internet-Transitanbieter. Das war so, als würde ein Navigationssystem wie Waze den kompletten Verkehr einer Autobahn über eine innerstädtische Nebenstraße leiten – und es führte dazu, dass viele Websites auf Cloudflare und bei vielen anderen Anbietern für große Teile des Internets nicht erreichbar waren. Dies hätte niemals geschehen dürfen, denn Verizon hätte diese Routen niemals an den Rest des Internets weiterleiten dürfen. Wenn Sie verstehen möchten, warum, lesen Sie weiter.

Wir haben über derartige unschöne Ereignisse bereits in der Vergangenheit gebloggt, da sie gar nicht so selten sind. Diesmal war der Schaden weltweit zu spüren. Was das Problem heute noch verschärft hat, war die Einbindung eines sogenannten „BGP Optimizers“ von Noction. Dieses Produkt verfügt über eine Funktion, die empfangene IP-Präfixe in kleinere, beitragende Teile („spezifischere Routen“) aufteilt. So wurde beispielsweise unsere eigene IPv4-Route 104.20.0.0/20 in 104.20.0.0/21 und 104.20.8.0/21 umgewandelt. Das ist so, als würde das Straßenschild, das den Verkehr nach „Pennsylvania“ (PA) leitet, durch zwei Straßenschilder ersetzt, eines für „Pittsburgh, PA“ und eines für „Philadelphia, PA“. Die Aufteilung dieser großen IP-Blöcke in kleinere Teile stellt eine Möglichkeit für einen Anbieter dar, den Traffic innerhalb seines Netzwerks zu steuern, aber diese Aufteilung hätte nie der ganzen Welt bekannt gegeben werden dürfen. Dass das passiert ist, hat den heutigen Ausfall verursacht.

Um zu erklären, was als nächstes geschah, hier eine kurze Zusammenfassung, wie die zugrunde liegende „Karte“ des Internets funktioniert. „Internet“ bedeutet wörtlich ein Netzwerk von Netzwerken. Es besteht aus Netzwerken, die als Autonome Systeme (AS) bezeichnet werden, und jedes dieser Netzwerke hat eine eindeutige Kennung, seine AS-Nummer. Alle diese Netzwerke sind über ein Protokoll namens Border Gateway Protocol (BGP) miteinander verbunden. BGP verbindet diese Netzwerke und baut die „Karte“ des Internets auf, die es dem Datenverkehr ermöglicht, beispielsweise von Ihrem ISP zu einer beliebten Website auf der anderen Seite der Welt zu reisen.

Mit BGP tauschen Netzwerke Routeninformationen aus: wie man von wo auch immer zu ihnen gelangt. Diese Routen können entweder spezifisch sein, ähnlich wie das Auffinden einer bestimmten Stadt mit Ihrem Navigationssystem, oder sehr allgemein, wie wenn Sie im Navigationssystem ein Bundesland ansteuern. Dabei ist heute etwas schiefgelaufen.

Ein Internetanbieter in Pennsylvania (AS33154 – DQE Communications) hat in seinem Netzwerk einen BGP Optimizer eingesetzt, sodass es viele spezifischere Routen in seinem Netzwerk gab. Spezifische Routen überschreiben allgemeinere Routen (um bei der Waze-Analogie zu bleiben: eine Route zum Buckingham Palace ist spezifischer als eine Route nach London).

DQE hat diese spezifischen Routen an seinen Kunden (AS396531 – Allegheny Technologies Inc) weitergegeben. Alle diese Routinginformationen wurden dann an seinen anderen Transitanbieter (AS701 – Verizon) weitergeleitet, der das gesamte Internet über diese „besseren“ Routen informierte. Diese Routen waren angeblich „besser“, weil sie granularer und spezifischer waren.

Das Leak hätte bei Verizon enden sollen. Der Mangel an Filterung bei Verizon, der zahlreichen unten beschriebenen Best Practices widerspricht, machte dieses Leak jedoch zu einem großen Vorfall, der viele Internetdienste wie Amazon, Linode und Cloudflare betraf.

Es bedeutete, dass Verizon, Allegheny und DQE plötzlich mit einem Ansturm von Internetnutzern zu kämpfen hatten, die versuchten, über ihre Netzwerke auf diese Dienste zuzugreifen. Keines dieser Netzwerke war geeignet, mit dem drastischen Traffic-Anstieg fertigzuwerden, was zu Ausfällen führte. Selbst wenn sie über genügend Kapazität verfügen würden, dürften DQE, Allegheny und Verizon nicht behaupten, dass sie die beste Route zu Cloudflare, Amazon, Linode usw. haben.

BGP-Leak-Prozess mit einem BGP Optimizer

Während des Vorfalls beobachteten wir als Spitzenwert einen Verlust von etwa 15 % unseres weltweiten Traffics.

Traffic-Niveau bei Cloudflare während des Vorfalls.

Wie hätte dieses Leak verhindert werden können?

Es gibt mehrere Möglichkeiten, wie dieses Leak hätte vermieden werden können:

Eine BGP-Session kann mit einer festen Begrenzung der zu empfangenden Präfixe konfiguriert werden. Das bedeutet, dass ein Router entscheiden kann, eine Sitzung zu beenden, wenn die Anzahl der Präfixe den Schwellenwert überschreitet. Wenn Verizon ein solches Präfix-Limit gehabt hätte, wäre es nicht zu dem Vorfall gekommen. Es gehört zu den Best Practices, solche Limits zu haben. Es kostet einen Anbieter wie Verizon nichts, solche Limits zu haben. Und es gibt keinen guten Grund, außer Schlamperei oder Faulheit, dass Verizon keine solchen Limits hat.

Eine andere Möglichkeit, wie Netzbetreiber Leaks dieser Art verhindern können, ist die Implementierung einer IRR-basierten Filterung. IRR ist die Internet Routing Registry, und Netzwerke können Einträge zu diesen verteilten Datenbanken hinzufügen. Andere Netzbetreiber können dann aus diesen IRR-Einträgen spezifische Präfixlisten für die BGP-Sessions mit anderen Netzwerken generieren. Wenn die IRR-Filterung verwendet worden wäre, hätte keines der beteiligten Netzwerke die fehlerhaften, spezifischeren Routen akzeptiert. Wirklich schockierend ist aber, dass Verizon anscheinend in seiner BGP-Session mit Allegheny Technologies diese Filterung nicht genutzt hat, obwohl IRR-Filterung schon seit über 24 Jahren existiert (und gut dokumentiert ist). Eine IRR-Filterung hätte die Kosten für Verizon nicht erhöht und seinen Service in keiner Weise eingeschränkt. Auch hier ist die einzige für uns vorstellbare Erklärung, warum die Filterung nicht vorhanden war, Schlamperei oder Faulheit.

Das RPKI-Framework, das wir im vergangenen Jahr implementiert und weltweit bereitgestellt haben, soll diese Art von Leaks verhindern. Es ermöglicht die Filterung nach Ursprungsnetzwerk und Präfixgröße. Die Präfixe, die Cloudflare bekanntgibt, sind für eine maximale Größe von 20 signiert. RPKI zeigt dann an, dass ein spezifischeres Präfix nicht akzeptiert werden soll, unabhängig vom Pfad. Damit dieser Mechanismus wirksam wird, muss ein Netzwerk die BGP-Ursprungsvalidierung aktivieren. Viele Anbieter wie AT&T haben sie bereits erfolgreich in ihrem Netzwerk aktiviert.

Wenn Verizon RPKI verwendet hätte, hätten sie gesehen, dass die angebotenen Routen nicht gültig sind, und die Routen hätten automatisch vom Router entfernt werden können.

Cloudflare fordert alle Netzbetreiber auf, RPKI jetzt einzusetzen!

Verhindern von Routen-Leaks durch IRR, RPKI und Präfix-Limits

Alle oben genannten Vorschläge wurden zu MANRS (Mutually Agreed Norms for Routing Security – Gemeinsam vereinbarte Normen für die Routing-Sicherheit) zusammengefasst.

Wie es behoben wurde

Das Netzwerkteam von Cloudflare hat sich an die beteiligten Netzwerke gewandt, AS33154 (DQE Communications) und AS701 (Verizon). Wir hatten Schwierigkeiten, beide Netzwerke zu erreichen, was möglicherweise auf den Zeitpunkt des Vorfalls zurückzuführen war, denn es war an der Ostküste der USA noch früh am Morgen, als das Routen-Leak begann.

Screenshot der an Verizon gesendeten E-Mai

Einer unserer Netzwerkingenieure konnte schnell Kontakt mit DQE Communications herstellen und mit etwas Verzögerung konnte man uns mit jemandem in Kontakt bringen, der das Problem beheben konnte. DQE arbeitete mit uns über Telefon daran, dass Allegheny Technologies Inc. diese „optimierten“ Routen nicht weiter angeboten wurden. Wir sind dankbar für die Hilfe von DQE. Sobald dies vollbracht war, stabilisierte sich das Internet und die Dinge normalisierten sich wieder.

Screenshot der Kommunikationsversuche mit den Supports von DQE und Verizon

Es ist bedauerlich, dass wir – obwohl wir per E-Mail und Telefon versucht haben, Verizon zu erreichen – zum Zeitpunkt des Schreibens dieses Artikels (über 8 Stunden nach dem Vorfall) noch nichts von Verizon gehört haben und auch nicht wissen, ob man dort Maßnahmen zur Lösung des Problems ergriffen hat.

Wir bei Cloudflare wünschen uns, dass Ereignisse dieser Art nie stattfinden, aber leider trägt der aktuelle Zustand des Internets sehr wenig dazu bei, Vorfälle wie diesen zu verhindern. Es ist an der Zeit, dass die Branche eine bessere Routing-Sicherheit durch Systeme wie RPKI einführt. Wir hoffen, dass große Anbieter dem Beispiel von Cloudflare, Amazon und AT&T folgen und mit der Validierung von Routen beginnen werden. Ganz besonders haben wir dabei Verizon im Auge – und wir warten übrigens immer noch auf Ihre Antwort.

Obwohl der Vorfall durch Ereignisse verursacht wurde, die außerhalb unserer Kontrolle liegen, möchten wir uns für die Störung entschuldigen. Unserem Team liegt unser Dienst sehr am Herzen und wir hatten wenige Minuten nach Identifizierung des Problems Ingenieure in den USA, Großbritannien, Australien und Singapur online.

Wir schützen komplette Firmennetzwerke, helfen Kunden dabei, Internetanwendungen effizient zu erstellen, jede Website oder Internetanwendung zu beschleunigen, DDoS-Angriffe abzuwehren, Hacker in Schach zu halten, und unterstützen Sie bei Ihrer Umstellung auf Zero Trust.

Greifen Sie von einem beliebigen Gerät auf 1.1.1.1 zu und nutzen Sie unsere kostenlose App, die Ihr Internet schneller und sicherer macht.

Wenn Sie mehr über unsere Mission, das Internet besser zu machen, erfahren möchten, beginnen Sie hier. Sie möchten sich beruflich neu orientieren? Dann werfen Sie doch einen Blick auf unsere offenen Stellen.
BGP

Folgen auf X

Tom Strickx|@tstrickx
Cloudflare|@cloudflare

Verwandte Beiträge