Alles ist sehr schlecht oder eine neue Art der Verkehrsüberwachung

Am 13. März erhielt die RIPE-Arbeitsgruppe zur Bekämpfung von Missbrauch einen Vorschlag, die Entführung als Verstoß gegen die RIPE-Richtlinie zu betrachten. Wenn der Vorschlag angenommen würde, könnte der Internetanbieter, der durch Abfangen des Datenverkehrs angegriffen wird, eine spezielle Anfrage senden, um den Angreifer zu sauberem Wasser zu bringen. Wenn die Expertengruppe genügend Belege sammelt, wird ein solches LIR, das die Quelle für das Abfangen von BGP darstellt, als Eindringling betrachtet und könnte des LIR-Status beraubt werden. Es gab einige Argumente gegen diese Änderung.

In dieser Veröffentlichung möchten wir ein Beispiel für einen Angriff zeigen, bei dem nicht nur der tatsächliche Angreifer im Zweifel war, sondern die gesamte Liste der betroffenen Präfixe. Darüber hinaus wirft ein solcher Angriff erneut Fragen nach den Motiven für künftiges Abfangen dieser Art von Verkehr auf.

In den letzten Jahren wurden in der Presse nur Konflikte wie MOAS (Multiple Origin Autonomous System) als BGP-Intercepts gemeldet. MOAS ist ein Sonderfall, wenn zwei verschiedene autonome Systeme widersprüchliche Präfixe mit den entsprechenden ASN-Nummern in AS_PATH ankündigen (der erste ASN in AS_PATH, im Folgenden als Ursprungs-ASN bezeichnet). Wir können jedoch mindestens drei zusätzliche Arten der Verkehrsüberwachung nennen, mit denen ein Angreifer das AS_PATH-Attribut für verschiedene Zwecke manipulieren kann, unter anderem um moderne Ansätze zum Filtern und Überwachen zu umgehen. Die bekannte Art des Pilosov-Kapela-Angriffs ist die letzte Art eines solchen Abfangens, aber überhaupt nicht von Bedeutung. Es ist möglich, dass dies genau der Angriff ist, den wir in den letzten Wochen beobachtet haben. Ein solches Ereignis hat einen verständlichen Charakter und ziemlich schwerwiegende Folgen.

Wer eine TL; DR-Version sucht, kann zur Unterüberschrift „Perfect Attack“ scrollen.

Netzwerkhintergrund

(damit Sie die mit diesem Vorfall verbundenen Prozesse besser verstehen)

Wenn Sie ein Paket senden möchten und die Routing-Tabelle mehrere Präfixe enthält, die die Ziel-IP-Adresse enthalten, verwenden Sie die Route für das Präfix mit der maximalen Länge. Wenn in der Routing-Tabelle mehrere verschiedene Routen für ein Präfix vorhanden sind, wählen Sie die beste aus (gemäß dem Mechanismus zur Auswahl des besten Pfads).

Bestehende Filter- und Überwachungsansätze versuchen, Routen zu analysieren und Entscheidungen zu treffen, indem sie das AS_PATH-Attribut analysieren. Der Router kann dieses Attribut während der Ansage in einen beliebigen Wert ändern. Das Hinzufügen des Eigentümer-ASN am Anfang von AS_PATH (wie der Ursprungs-ASN) kann ausreichen, um die aktuellen Quellenüberprüfungsmechanismen zu umgehen. Wenn es eine Route vom angegriffenen Lieferavis zu Ihnen gibt, können Sie außerdem den AS_PATH dieser Route in Ihren anderen Ankündigungen extrahieren und verwenden. Jede Validierung von nur AS_PATH für Ihre gestalteten Ankündigungen wird schließlich bestanden.

Es gibt einige bemerkenswerte Einschränkungen. Erstens kann beim Filtern von Präfixen durch einen höheren Anbieter Ihre Route weiterhin gefiltert werden (auch mit dem richtigen AS_PATH), wenn das Präfix nicht zu Ihrem im Upstream konfigurierten Client-Kegel gehört. Zweitens kann ein gültiger AS_PATH ungültig werden, wenn die erstellte Route in die falsche Richtung angekündigt wird und somit gegen die Routing-Richtlinie verstößt. Und die letzte - jede Route mit einem Präfix, das die ROA-Länge verletzt, kann als ungültig betrachtet werden.

Vorfall

Vor einigen Wochen haben wir eine Beschwerde von einem der Benutzer erhalten. Wir haben Routen mit dem Ursprungs-ASN und / 25-Präfixen gesehen, während der Benutzer behauptete, sie nicht angekündigt zu haben.

^{TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||}
Beispiele für Ankündigungen Anfang April 2019

NTT während der Übertragung für das Präfix / 25 macht es besonders verdächtig. Während des Vorfalls wusste das LG NTT nichts über diese Route. Also ja, eine Art Operator erstellt einen vollständigen AS_PATH für diese Präfixe! Durch Testen auf anderen Routern können Sie einen speziellen Lieferavis hervorheben: AS263444. Bei der Betrachtung anderer Routen mit diesem autonomen System waren wir mit der folgenden Situation konfrontiert:

^{TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||}
Versuchen Sie zu erraten, was hier falsch ist

Es scheint, dass jemand das Präfix von der Route genommen, es in zwei Teile geteilt und die Route mit demselben AS_PATH für diese beiden Präfixe angekündigt hat.

^{TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||}
Beispiele für Routen für eines der Paare von geteilten Präfixen

Es stellen sich mehrere Fragen gleichzeitig. Hat jemand diese Art des Abfangens in der Praxis wirklich ausprobiert? Hat jemand diese Routen genommen? Welche Präfixe waren betroffen?

Hier beginnt unsere Reihe von Fehlern und eine weitere Runde der Enttäuschung über die aktuelle Gesundheit des Internets.

Der Weg des Scheiterns

Das Wichtigste zuerst. Wie können wir feststellen, welche Router solche abgefangenen Routen akzeptiert haben und wessen Verkehr heute umgeleitet werden kann? Wir dachten, wir sollten mit den Präfixen / 25 beginnen, weil sie "einfach keine globale Verteilung haben können". Wie Sie sich vorstellen können, haben wir uns sehr geirrt. Diese Metrik war zu verrauscht und Routen mit solchen Präfixen können sogar von Tier-1-Betreibern angezeigt werden. Zum Beispiel hat NTT ungefähr 50 solcher Präfixe, die es unter seinen eigenen Clients verteilt. Andererseits ist diese Metrik schlecht, da solche Präfixe herausgefiltert werden können, wenn der Operator kleine Präfixe in alle Richtungen filtert. Daher eignet sich diese Methode nicht für die Suche nach allen Betreibern, deren Datenverkehr infolge eines solchen Vorfalls umgeleitet wurde.

Eine andere gute Idee, die wir dachten, war, sich POV anzuschauen. Insbesondere auf Routen, die gegen die maxLength-Regel der entsprechenden ROA verstoßen. Auf diese Weise konnten wir die Anzahl der verschiedenen Ursprungs-ASNs mit ungültigem Status ermitteln, die für diesen AS sichtbar waren. Es gibt jedoch ein "kleines" Problem. Der Durchschnittswert (Median und Modus) dieser Zahl (die Anzahl der ASNs unterschiedlicher Herkunft) beträgt ungefähr 150, und selbst wenn wir kleine Präfixe herausfiltern, bleibt er über 70. Diese Situation hat eine sehr einfache Erklärung: Es gibt nur wenige Operatoren, die bereits ROA- verwenden. Filter mit der Richtlinie "Ungültige Routen zurücksetzen" an Einstiegspunkten. Wenn also eine Route mit einer ROA-Verletzung in der realen Welt angezeigt wird, kann sie sich in alle Richtungen ausbreiten.

Die letzten beiden Ansätze ermöglichen es uns, die Betreiber zu finden, die unseren Vorfall gesehen haben (da er ziemlich groß war), aber im Allgemeinen sind sie nicht anwendbar. Ok, aber können wir den Angreifer finden? Was sind die gemeinsamen Merkmale einer solchen AS_PATH-Manipulation? Es gibt mehrere Grundannahmen:

• Das Präfix wurde bisher nirgendwo gesehen.
• Ursprungs-Lieferavis (Erinnerung: erster Lieferavis in AS_PATH) ist gültig;
• Der letzte Lieferavis in AS_PATH ist der Lieferavis des Angreifers (wenn sein Nachbar den Lieferavis des Nachbarn auf allen eingehenden Routen überprüft).
• Der Angriff kommt von einem Anbieter.

Wenn alle Annahmen korrekt sind, wird auf allen falschen Routen der Lieferavis des Angreifers angezeigt (mit Ausnahme des Ursprungs des Lieferavis). Dies ist daher ein „kritischer“ Punkt. Unter den wahren Entführern war AS263444, obwohl es andere gab. Auch wenn wir die Vorfallrouten aus der Betrachtung gestrichen haben. Warum? Ein kritischer Punkt kann auch für korrekte Routen kritisch bleiben. Dies kann entweder auf eine schlechte Konnektivität in einer Region oder auf die Einschränkungen unserer eigenen Sichtbarkeit zurückzuführen sein.

Ergebnis: Es gibt eine Möglichkeit, einen Angreifer zu erkennen, jedoch nur, wenn alle oben genannten Bedingungen erfüllt sind und wenn das Abfangen groß genug ist, um die Überwachungsschwellen zu überschreiten. Wenn einer dieser Faktoren nicht beachtet wird, können wir dann die Präfixe herausgreifen, die von einem solchen Abfangen betroffen sind? Für bestimmte Betreiber ja.

Wenn ein Angreifer eine spezifischere Route erstellt, wird ein solches Präfix vom wahren Eigentümer nicht angekündigt. Wenn Sie eine dynamische Liste aller Präfixe haben, können Sie einen Vergleich durchführen und verzerrte, spezifischere Routen finden. Wir sammeln diese Liste von Präfixen mithilfe unserer BGP-Sitzungen, da wir nicht nur eine vollständige Liste der Routen erhalten, die für den Betreiber derzeit sichtbar sind, sondern auch eine Liste aller Präfixe, die er der Welt bekannt geben möchte. Leider gibt es jetzt mehrere Dutzend Radarbenutzer, die den letzten Teil nicht korrekt ausführen. In naher Zukunft werden wir sie benachrichtigen und versuchen, dieses Problem zu lösen. Alle anderen können jetzt unserem Überwachungssystem beitreten.

Wenn wir zum ursprünglichen Vorfall zurückkehren, wurden der Angreifer und das Verbreitungsgebiet von uns durch die Suche nach kritischen Punkten entdeckt. Überraschenderweise hat AS263444 nicht an alle Kunden fabrizierte Routen gesendet. Obwohl es einen merkwürdigeren Moment gibt.

^{BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||}
Ein aktuelles Beispiel für einen Versuch, unseren Adressraum abzufangen

Wenn spezifischere Präfixe für unsere Präfixe erstellt wurden, wurde das speziell erstellte AS_PATH verwendet. Dieser AS_PATH konnte jedoch keiner unserer vorherigen Routen entnommen werden. Wir haben nicht einmal eine Verbindung mit AS6762. Wir sehen uns andere Routen in dem Vorfall an: Einige von ihnen hatten einen echten AS_PATH, der früher verwendet wurde, während andere dies nicht taten, selbst wenn sie wie echt aussehen. Eine zusätzliche Änderung an AS_PATH ist praktisch nicht sinnvoll, da der Datenverkehr in jedem Fall an den Angreifer umgeleitet wird. Routen mit einem "schlechten" AS_PATH können jedoch von ASPA oder einem anderen Überprüfungsmechanismus gefiltert werden. Hier haben wir über die Motivation des Entführers nachgedacht. Jetzt haben wir nicht genügend Daten, um zu behaupten, dass dieser Vorfall ein geplanter Angriff war. Trotzdem ist es möglich. Versuchen wir uns eine hypothetische, aber möglicherweise durchaus reale Situation vorzustellen.

Perfekter Angriff

Was haben wir Angenommen, Sie sind ein Transitanbieter, der Routen für Ihre Kunden sendet. Wenn Ihre Kunden mehrfach präsent sind (Multihome), erhalten Sie nur einen Teil ihres Datenverkehrs. Aber je mehr Verkehr - desto mehr Ihr Einkommen. Wenn Sie daher Subnetzpräfixe derselben Routen mit demselben AS_PATH ankündigen, erhalten Sie den Rest des Datenverkehrs. Infolgedessen der Rest des Geldes.

Wird ROA hier helfen? Vielleicht ja, wenn Sie die Verwendung von maxLength ganz aufgeben möchten . Darüber hinaus ist es höchst unerwünscht, ROA-Einträge mit sich überschneidenden Präfixen zu haben. Für einige Betreiber sind solche Einschränkungen nicht akzeptabel.

In Anbetracht anderer Routing-Sicherheitsmechanismen hilft ASPA auch in diesem Fall nicht (da AS_PATH von einer gültigen Route verwendet wird). BGPSec ist aufgrund der geringen Akzeptanzrate und der verbleibenden Möglichkeit von Downgrade-Angriffen immer noch nicht die beste Option.

Somit haben wir einen klaren Gewinn für den Angreifer und einen Mangel an Sicherheit. Tolle Mischung!

Was muss ich tun?

Der naheliegendste und radikalste Schritt besteht darin, Ihre aktuelle Routing-Richtlinie zu überprüfen. Teilen Sie Ihren Adressraum in die kleinsten Teile (ohne Schnittpunkte) auf, die Sie nur ankündigen möchten. Signieren Sie ROAs nur für sie, ohne den Parameter maxLength zu verwenden. In diesem Fall kann der aktuelle POV Sie vor einem solchen Angriff bewahren. Für einige Betreiber ist dieser Ansatz jedoch aufgrund der ausschließlichen Verwendung spezifischerer Routen nicht sinnvoll. Alle Probleme des aktuellen Status von ROA- und Routenobjekten werden in einem unserer zukünftigen Materialien beschrieben.

Außerdem können Sie versuchen, solche Interceptions zu überwachen. Dazu benötigen wir zuverlässige Informationen zu Ihren Präfixen. Wenn Sie also eine BGP-Sitzung mit unserem Sammler einrichten und uns Informationen über Ihre Sichtbarkeit des Internets geben, können wir den Verteilungsbereich auch für andere Vorfälle finden. Für diejenigen, die noch nicht mit unserem Überwachungssystem verbunden sind - zunächst reicht uns eine Liste von Routen mit nur Ihren Präfixen. Wenn Sie eine Sitzung mit uns haben, überprüfen Sie bitte, ob alle Ihre Routen gesendet wurden. Leider ist dies in Erinnerung zu rufen, da einige Operatoren ein oder zwei Präfixe vergessen und somit unsere Suchmethoden stören. Wenn alles richtig gemacht wurde, verfügen wir über zuverlässige Daten zu Ihren Präfixen, die in Zukunft dazu beitragen werden, solche (und andere) Arten des Verkehrsabfangens für Ihren Adressraum automatisch zu erkennen und zu erkennen.

Wenn Sie in Echtzeit von einem solchen Abfangen Ihres Datenverkehrs erfahren, können Sie versuchen, dem selbst entgegenzuwirken. Der erste Ansatz besteht darin, Routen mit diesen spezifischeren Präfixen selbst anzukündigen. Im Falle eines neuen Angriffs auf diese Präfixe - wiederholen.

Der zweite Ansatz besteht darin, den Angreifer und diejenigen, für die er ein kritischer Punkt ist (für gute Routen), zu bestrafen, indem der Zugang Ihrer Routen zum Angreifer gesperrt wird. Dies kann erreicht werden, indem der Lieferavis des Angreifers zum AS_PATH Ihrer alten Routen hinzugefügt wird und diese AS vermieden werden, indem der in BGP integrierte Schleifenerkennungsmechanismus zu ihrem eigenen Vorteil verwendet wird .