13. März an die RIPE-Arbeitsgruppe zur Missbrauchsbekämpfung Betrachten Sie BGP-Hijacking (hjjack) als Verstoß gegen die RIPE-Richtlinie. Sollte der Vorschlag angenommen werden, hätte der durch Traffic Interception angegriffene Internetprovider die Möglichkeit, eine Sonderanfrage zu senden, um den Angreifer zu enttarnen. Wenn das Überprüfungsteam genügend unterstützende Beweise sammeln würde, würde der LIR, der die Quelle des BGP-Abfangens war, als Eindringling betrachtet und könnte seinen LIR-Status verlieren. Es gab auch einige Argumente Änderungen
In dieser Veröffentlichung möchten wir ein Beispiel für einen Angriff zeigen, bei dem nicht nur der echte Angreifer in Frage kam, sondern auch die gesamte Liste der betroffenen Präfixe. Darüber hinaus wirft ein solcher Angriff erneut Fragen nach den Motiven für das künftige Abfangen dieser Art von Datenverkehr auf.
In den letzten Jahren wurde in der Presse nur über Konflikte wie MOAS (Multiple Origin Autonomous System) als BGP-Abfangmaßnahmen berichtet. MOAS ist ein Sonderfall, bei dem zwei verschiedene autonome Systeme widersprüchliche Präfixe mit entsprechenden ASNs in AS_PATH bekannt geben (die erste ASN in AS_PATH, im Folgenden als Ursprungs-ASN bezeichnet). Wir können jedoch zumindest einen Namen nennen Das Abfangen des Datenverkehrs ermöglicht es einem Angreifer, das AS_PATH-Attribut für verschiedene Zwecke zu manipulieren, einschließlich der Umgehung moderner Filter- und Überwachungsansätze. Bekannter Angriffstyp - die letzte Art eines solchen Abfangens, aber überhaupt nicht von Bedeutung. Es ist durchaus möglich, dass es sich um genau die Art von Angriff handelt, die wir in den letzten Wochen erlebt haben. Ein solches Ereignis ist verständlicher Natur und hat durchaus schwerwiegende Folgen.
Wer die TL;DR-Version sucht, kann zum Untertitel „Perfect Attack“ scrollen.
Netzwerkhintergrund
(um Ihnen zu helfen, die an diesem Vorfall beteiligten Prozesse besser zu verstehen)
Wenn Sie ein Paket senden möchten und in der Routing-Tabelle mit der Ziel-IP-Adresse mehrere Präfixe vorhanden sind, verwenden Sie die Route für das Präfix mit der längsten Länge. Wenn in der Routing-Tabelle mehrere unterschiedliche Routen für dasselbe Präfix vorhanden sind, wählen Sie die beste aus (gemäß dem besten Pfadauswahlmechanismus).
Bestehende Filter- und Überwachungsansätze versuchen, Routen zu analysieren und Entscheidungen durch Analyse des AS_PATH-Attributs zu treffen. Der Router kann dieses Attribut während der Ankündigung auf einen beliebigen Wert ändern. Das einfache Hinzufügen der ASN des Eigentümers am Anfang von AS_PATH (als Ursprungs-ASN) kann ausreichen, um die aktuellen Mechanismen zur Ursprungsprüfung zu umgehen. Wenn es außerdem eine Route von der angegriffenen ASN zu Ihnen gibt, ist es möglich, den AS_PATH dieser Route zu extrahieren und in Ihren anderen Ankündigungen zu verwenden. Jede reine AS_PATH-Validierungsprüfung für Ihre gestalteten Ankündigungen wird irgendwann erfolgreich sein.
Es gibt noch einige erwähnenswerte Einschränkungen. Erstens: Im Falle einer Präfixfilterung durch den Upstream-Anbieter kann Ihre Route immer noch gefiltert werden (auch mit dem richtigen AS_PATH), wenn das Präfix nicht zu Ihrem beim Upstream konfigurierten Client-Kegel gehört. Zweitens kann ein gültiger AS_PATH ungültig werden, wenn die erstellte Route in falsche Richtungen angekündigt wird und somit gegen die Routing-Richtlinie verstößt. Schließlich kann jede Route mit einem Präfix, das die ROA-Länge verletzt, als ungültig betrachtet werden.
Zwischenfall
Vor einigen Wochen erhielten wir eine Beschwerde von einem unserer Benutzer. Wir haben Routen mit seiner Ursprungs-ASN und den Präfixen /25 gesehen, während der Benutzer behauptete, dass er sie nicht beworben habe.
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 für Anfang April 2019
NTT im Pfad für das Präfix /25 macht es besonders verdächtig. LG NTT war sich dieser Route zum Zeitpunkt des Vorfalls nicht bewusst. Also ja, irgendein Operator erstellt einen vollständigen AS_PATH für diese Präfixe! Die Überprüfung anderer Router zeigt eine bestimmte ASN: AS263444. Nachdem wir uns andere Routen mit diesem autonomen System angesehen hatten, stießen wir auf folgende Situation:
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
Offenbar hat jemand das Präfix aus der Route übernommen, es in zwei Teile geteilt und die Route mit demselben AS_PATH für diese beiden Präfixe angekündigt.
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||
Beispielrouten für eines der geteilten Präfixpaare
Es tauchen mehrere Fragen gleichzeitig auf. Hat jemand diese Art des Abfangens tatsächlich in der Praxis ausprobiert? Hat jemand diese Routen genommen? Welche Präfixe waren betroffen?
Hier beginnt unsere Reihe von Misserfolgen und eine weitere Runde der Enttäuschung über den aktuellen Zustand des Internets.
Der Weg des Scheiterns
Das wichtigste zuerst. Wie können wir feststellen, welche Router solche abgefangenen Routen akzeptiert haben und wessen Datenverkehr heute umgeleitet werden könnte? Wir dachten, wir würden mit /25-Präfixen beginnen, weil sie „einfach keine globale Verbreitung haben können“. Wie Sie sich vorstellen können, haben wir uns sehr geirrt. Diese Metrik erwies sich als zu verrauscht und Routen mit solchen Präfixen können sogar von Tier-1-Betreibern angezeigt werden. NTT verfügt beispielsweise über etwa 50 solcher Präfixe, die es an seine eigenen Kunden verteilt. Andererseits ist diese Metrik schlecht, da solche Präfixe herausgefiltert werden können, wenn der Betreiber sie verwendet , in alle Richtungen. Daher ist diese Methode nicht geeignet, alle Betreiber zu finden, deren Verkehr infolge eines solchen Vorfalls umgeleitet wurde.
Eine weitere gute Idee, die wir uns ansehen sollten, war unserer Meinung nach . Insbesondere für Routen, die gegen die maxLength-Regel des entsprechenden ROA verstoßen. Auf diese Weise konnten wir die Anzahl der verschiedenen Ursprungs-ASNs mit dem Status „Ungültig“ ermitteln, die für einen bestimmten AS sichtbar waren. Allerdings gibt es ein „kleines“ Problem. Der Durchschnitt (Median und Modus) dieser Zahl (die Anzahl der ASNs unterschiedlicher Herkunft) liegt bei etwa 150 und bleibt, selbst wenn wir kleine Präfixe herausfiltern, über 70. Dieser Sachverhalt hat eine sehr einfache Erklärung: Es gibt nur eine Es gibt nur wenige Betreiber, die bereits ROA-Filter mit der Richtlinie „Ungültige Routen zurücksetzen“ an Einstiegspunkten verwenden, sodass sich eine Route mit einer ROA-Verletzung in der realen Welt überall dort ausbreiten kann, wo sie in alle Richtungen auftritt.
Die letzten beiden Ansätze ermöglichen es uns, Bediener zu finden, die unseren Vorfall gesehen haben (da er ziemlich groß war), aber im Allgemeinen sind sie nicht anwendbar. Okay, aber können wir den Eindringling finden? Was sind die allgemeinen Merkmale dieser AS_PATH-Manipulation? Es gibt einige Grundannahmen:
- Das Präfix war zuvor nirgendwo zu sehen;
- Ursprungs-ASN (zur Erinnerung: erste ASN in AS_PATH) ist gültig;
- Die letzte ASN in AS_PATH ist die ASN des Angreifers (falls sein Nachbar die ASN des Nachbarn auf allen eingehenden Routen überprüft);
- Der Angriff geht von einem einzigen Anbieter aus.
Wenn alle Annahmen richtig sind, stellen alle falschen Routen die ASN des Angreifers dar (mit Ausnahme der Ursprungs-ASN) und daher ist dies ein „kritischer“ Punkt. Zu den wahren Entführern gehörte AS263444, obwohl es noch andere gab. Auch wenn wir die Unfallrouten außer Acht gelassen haben. Warum? Ein kritischer Punkt kann auch bei korrekten Routen kritisch bleiben. Dies kann entweder auf eine schlechte Konnektivität in einer Region oder auf Einschränkungen unserer eigenen Sichtbarkeit zurückzuführen sein.
Dadurch gibt es eine Möglichkeit, einen Angreifer zu erkennen, allerdings nur, wenn alle oben genannten Bedingungen erfüllt sind und nur wenn der Angriff groß genug ist, um die Überwachungsschwellenwerte zu überschreiten. Wenn einige dieser Faktoren nicht erfüllt sind, können wir dann die Präfixe identifizieren, die von einem solchen Abfangen betroffen waren? Für bestimmte Betreiber – ja.
Wenn ein Angreifer eine spezifischere Route erstellt, wird ein solches Präfix vom wahren Eigentümer nicht bekannt gegeben. Wenn Sie über eine dynamische Liste aller Präfixe verfügen, ist es möglich, einen Vergleich durchzuführen und verzerrte, spezifischere Routen zu finden. Wir sammeln diese Liste von Präfixen mithilfe unserer BGP-Sitzungen, da wir nicht nur die vollständige Liste der derzeit für den Betreiber sichtbaren Routen erhalten, sondern auch eine Liste aller Präfixe, die er der Welt bekannt geben möchte. Leider gibt es mittlerweile mehrere Dutzend Radar-Benutzer, die den letzten Teil nicht korrekt abschließen. Wir werden sie in Kürze benachrichtigen und versuchen, das Problem zu beheben. Alle anderen können ab sofort unserem Überwachungssystem beitreten.
Kehren wir zum ursprünglichen Vorfall zurück, so wurden sowohl der Angreifer als auch das Verbreitungsgebiet von uns durch die Suche nach kritischen Punkten erkannt. Überraschenderweise hat AS263444 nicht an alle seine Kunden erfundene Routen gesendet. Obwohl es einen seltsameren 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
Als spezifischere Präfixe für unsere Präfixe erstellt wurden, wurde ein speziell erstellter AS_PATH verwendet. Dieser AS_PATH konnte jedoch keiner unserer vorherigen Routen entnommen werden. Wir haben nicht einmal Kommunikation mit AS6762. Betrachtet man die anderen Routen des Vorfalls, so hatten einige von ihnen einen echten AS_PATH, der zuvor verwendet wurde, während andere dies nicht taten, auch wenn er wie der echte aussieht. Darüber hinaus macht eine Änderung von AS_PATH praktisch keinen Sinn, da der Datenverkehr ohnehin zum Angreifer umgeleitet wird, Routen mit einem „schlechten“ AS_PATH jedoch durch ASPA oder einen anderen Prüfmechanismus gefiltert werden können. Hier denken wir über die Motivation des Entführers nach. Derzeit liegen uns nicht genügend Informationen vor, um zu bestätigen, dass es sich bei diesem Vorfall um einen geplanten Angriff handelte. Dennoch ist es möglich. Versuchen wir uns eine zwar noch hypothetische, aber möglicherweise durchaus reale Situation vorzustellen.
Perfekter Angriff
Was wir haben? Nehmen wir an, Sie sind ein ÖPNV-Anbieter, der Routen für Ihre Kunden überträgt. Wenn Ihre Kunden über mehrere Präsenzen (Multihome) verfügen, erhalten Sie nur einen Teil ihres Datenverkehrs. Aber je mehr Verkehr, desto höher ist Ihr Einkommen. Wenn Sie also beginnen, Subnetzpräfixe derselben Routen mit demselben AS_PATH anzukündigen, erhalten Sie den Rest ihres Datenverkehrs. Infolgedessen der Rest des Geldes.
Hilft ROA hier? Vielleicht ja, wenn Sie sich entscheiden, es ganz nicht mehr zu verwenden . Darüber hinaus ist es höchst unerwünscht, ROA-Datensätze mit sich überschneidenden Präfixen zu haben. Für einige Betreiber sind solche Einschränkungen nicht akzeptabel.
Unter Berücksichtigung 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 Akzeptanzraten und der verbleibenden Möglichkeit von Downgrade-Angriffen immer noch keine optimale Option.
Wir haben also einen klaren Vorteil für den Angreifer und einen Mangel an Sicherheit. Tolle Mischung!
Was soll ich tun?
Der offensichtlichste und drastischste Schritt besteht darin, Ihre aktuelle Routing-Richtlinie zu überprüfen. Teilen Sie Ihren Adressraum in die kleinsten Abschnitte (ohne Überschneidungen) auf, die Sie bewerben möchten. Signieren Sie ROA nur für sie, ohne den Parameter maxLength zu verwenden. In diesem Fall kann Ihr aktueller POV Sie vor einem solchen Angriff bewahren. Allerdings ist dieser Ansatz für einige Betreiber aufgrund der ausschließlichen Nutzung spezifischerer Routen nicht sinnvoll. Alle Probleme mit dem aktuellen Status von ROA und Routenobjekten werden in einem unserer zukünftigen Materialien beschrieben.
Darüber hinaus können Sie versuchen, solche Abhörvorgänge zu überwachen. Dazu benötigen wir verlässliche Informationen über Ihre Vorwahlen. Wenn Sie also eine BGP-Sitzung mit unserem Collector einrichten und uns Informationen über Ihre Internet-Sichtbarkeit bereitstellen, können wir den Spielraum für andere Vorfälle finden. Für diejenigen, die noch nicht mit unserem Überwachungssystem verbunden sind, reicht zunächst eine Routenliste nur mit Ihren Präfixen. Wenn Sie eine Sitzung bei uns haben, überprüfen Sie bitte, ob alle Ihre Routen gesendet wurden. Leider lohnt es sich, dies zu bedenken, da einige Operatoren ein oder zwei Präfixe vergessen und dadurch unsere Suchmethoden beeinträchtigen. Bei korrekter Vorgehensweise verfügen wir über zuverlässige Daten über Ihre Präfixe, die uns in Zukunft dabei helfen werden, diese (und andere) Arten der Verkehrsüberwachung für Ihren Adressraum automatisch zu identifizieren und zu erkennen.
Sollten Sie von einem solchen Abfangen Ihres Datenverkehrs in Echtzeit erfahren, können Sie versuchen, selbst dagegen vorzugehen. Der erste Ansatz besteht darin, Routen mit diesen spezifischeren Präfixen selbst anzukündigen. Im Falle eines erneuten Angriffs auf diese Präfixe wiederholen Sie den Vorgang.
Der zweite Ansatz besteht darin, den Angreifer und diejenigen, für die er ein kritischer Punkt (für gute Routen) ist, zu bestrafen, indem Sie den Zugang Ihrer Routen zum Angreifer sperren. Dies kann erreicht werden, indem Sie die ASN des Angreifers zum AS_PATH Ihrer alten Routen hinzufügen und ihn so dazu zwingen, diesen AS mithilfe des integrierten Schleifenerkennungsmechanismus in BGP zu umgehen .
Source: habr.com