Am 13. März erhielt die RIPE-Arbeitsgruppe zur Bekämpfung von Missbrauchsvorschlägen BGP-Hijacking (hjjack) als Verstoß gegen die RIPE-Politik zu betrachten. Im Falle der Annahme des Vorschlags hätte der Internetanbieter, der durch den Verkehrshijack angegriffen wurde, die Möglichkeit, eine spezielle Anfrage zu stellen, um den Angreifer zur Rechenschaft zu ziehen. Wenn die Expertengruppe genügend bestätigende Beweise sammelt, würde ein solcher LIR, der die Quelle des BGP-Hijackings ist, als Täter angesehen 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 präsentieren, bei dem nicht nur der tatsächliche Angreifer in Frage stand, sondern auch die gesamte Liste der betroffenen Präfixe. Darüber hinaus wirft ein solcher Angriff erneut Fragen zu den Motiven zukünftiger Verkehrshijacks dieser Art auf.
In den letzten Jahren wurden in der Presse nur Konflikte vom Typ MOAS (Multiple Origin Autonomous System) als BGP-Hijack betrachtet. MOAS ist ein Sonderfall, bei dem zwei verschiedene autonome Systeme konkurrierende Präfixe mit entsprechenden ASN-Nummern im AS_PATH ankündigen (das erste ASN im AS_PATH, nachfolgend origin ASN genannt). Wir können jedoch mindestens von Verkehrshijacks benennen, die es dem Angreifer ermöglichen, das Attribut AS_PATH mit unterschiedlichen Zielen zu manipulieren, einschließlich der Umgehung moderner Filter- und Überwachungsansätze. Ein bekannter Angriffstyp, ist der letzte Typ eines solchen Hijacks, aber keineswegs der unwichtigste. Es ist durchaus möglich, dass wir genau einen solchen Angriff in den letzten Wochen beobachtet haben. Dieses Ereignis hat eine nachvollziehbare Natur und ernsthafte Konsequenzen.
Wer die TL;DR-Version sucht, kann zum Untertitel "Perfekter Angriff" scrollen.
Netzwerkhintergrund
(damit Sie die Prozesse, die an diesem Vorfall beteiligt sind, besser verstehen können)
Wenn Sie ein Paket senden möchten und mehrere Präfixe in der Routingtabelle vorhanden sind, die die Ziel-IP-Adresse enthalten, verwenden Sie die Route für das Präfix mit der maximalen Länge. Wenn es in der Routingtabelle jedoch mehrere verschiedene Routen für ein Präfix gibt, wählen Sie die beste (gemäß dem Mechanismus zur Auswahl des besten Pfades).
Die bestehenden Ansätze zur Filterung und Überwachung versuchen, Routen zu analysieren und Entscheidungen zu treffen, indem sie das Attribut AS_PATH bewerten. Der Router kann dieses Attribut während der Ankündigung auf einen beliebigen Wert ändern. Das einfache Hinzufügen der ASN des Eigentümers zu Beginn des AS_PATH (als origin ASN) kann ausreichen, um die aktuellen Quellverifizierungsmechanismen zu umgehen. Darüber hinaus, wenn es eine Route vom angegriffenen ASN zu Ihnen gibt, besteht die Möglichkeit, das AS_PATH dieser Route in anderen Ihrer Ankündigungen zu extrahieren und zu verwenden. Jede Überprüfung der Authentizität nur des AS_PATH für Ihre gefälschten Ankündigungen wird letztendlich bestanden.
Es gibt auch einige erwähnenswerte Einschränkungen. Erstens kann Ihr Weg durch den übergeordneten Anbieter immer noch gefiltert werden (selbst mit einem korrekten AS_PATH), wenn der Präfix nicht zu Ihrem Client-Kegel gehört, der bei Upstream eingerichtet ist. Zweitens - ein gültiger AS_PATH kann ungültig werden, wenn die erstellte Route in falsche Richtungen angekündigt wird und somit die Richtlinien zur Routensteuerung verletzt. Und schließlich - jede Route mit einem Präfix, das die ROA-Länge verletzt, kann als ungültig betrachtet werden.
Vorfälle
Vor einigen Wochen erhielten wir eine Beschwerde von einem der Benutzer. Wir sahen Routen mit seiner origin ASN und Präfixen /25, während der Benutzer behauptete, dass er sie nicht angekündigt hatte.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|UNVOLLSTÄNDIG|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|UNVOLLSTÄNDIG|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|UNVOLLSTÄNDIG|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|UNVOLLSTÄNDIG|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|UNVOLLSTÄNDIG|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|UNVOLLSTÄNDIG|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|UNVOLLSTÄNDIG|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|UNVOLLSTÄNDIG|xxx|0|0||NAG||
Beispiele für Ankündigungen zu Beginn des April 2019
NTT auf dem Weg für Präfix /25 macht es besonders verdächtig. Während des Vorfalls wusste LG NTT nichts über diese Route. Also ja, irgendein Betreiber erstellt einen vollständigen AS_PATH für diese Präfixe! Überprüfungen auf anderen Routern heben einen besonderen ASN hervor: AS263444. Bei der Betrachtung anderer Routen mit diesem autonomen System stießen wir auf die 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 nicht stimmt
Es scheint, dass jemand den Präfix aus der Route genommen, ihn in zwei Teile geteilt hat und eine 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 einer der Paare geteilter Präfixe
Es stellen sich mehrere Fragen. Hat wirklich jemand versucht, diese Art von Abfangen in der Praxis zu testen? Hat jemand diese Routen akzeptiert? Welche Präfixe waren betroffen?
Hier beginnt unsere Reihe von Misserfolgen und eine weitere Runde der Enttäuschung über den aktuellen Gesundheitszustand des Internets.
Der Weg der Misserfolge
Alles der Reihe nach. Wie können wir feststellen, welche Router solche abgefangenen Routen akzeptiert haben und welcher Verkehr bereits heute umgeleitet werden kann? Wir dachten, wir fangen mit den Präfixen /25 an, denn sie „können einfach nicht global verbreitet sein“. Wie Sie erraten können — wir lagen total falsch. Diese Metrik stellte sich als zu verrauscht heraus und Routen mit solchen Präfixen können sogar von Tier-1-Anbietern stammen. Zum Beispiel hat NTT etwa 50 solcher Präfixe, die es unter seinen eigenen Kunden verbreitet. Andererseits ist diese Metrik schlecht, weil solche Präfixe gefiltert werden können, wenn der Anbieter , in alle Richtungen anwendet. Daher eignet sich diese Methode nicht zur Auffindung aller Anbieter, deren Verkehr infolge eines solchen Vorfalls umgeleitet wurde.
Eine weitere gute Idee schien uns, die zu betrachten. Insbesondere bei Routen, die gegen die maxLength-Regel des entsprechenden ROA verstoßen. Auf diese Weise könnten wir die Anzahl der verschiedenen Origin-ASNs mit dem Status Ungültig finden, die diesem AS sichtbar waren. Dennoch gibt es ein „kleines“ Problem. Der Mittelwert (Median und Modus) dieser Zahl (Anzahl der verschiedenen Origin-ASNs) liegt bei etwa 150 und selbst wenn wir kleine Präfixe herausfiltern, bleibt er über 70. Diese Situation hat eine ganz einfache Erklärung: Es gibt nur wenige Anbieter, die bereits ROA-Filter mit der Politik „Ungültige Routen zurücksetzen“ an den Eingabepunkten anwenden, weshalb, wo immer in der realen Welt eine Route gegen ROA verstößt, sie in alle Richtungen verbreitet werden kann.
Die letzten beiden Ansätze ermöglichen es, die Anbieter zu finden, die unseren Vorfall bemerkt haben (da er groß genug war), aber insgesamt sind sie nicht anwendbar. Gut, aber können wir den Angreifer finden? Was sind die allgemeinen Merkmale einer solchen Manipulation des AS_PATH? Es gibt einige grundlegende Annahmen:
- Das Präfix wurde zuvor nirgendwo gesehen;
- Der Origin ASN (zur Erinnerung: der erste ASN im AS_PATH) ist gültig;
- Der letzte ASN im AS_PATH ist der ASN des Angreifers (falls sein Nachbar den ASN des Nachbarn bei allen eingehenden Routen überprüft);
- Der Angriff geht von einem Anbieter aus.
Wenn alle Annahmen zutreffen, wird ASN des Angreifers (außer dem origin ASN) auf allen fehlerhaften Routen angezeigt und stellt damit einen „kritischen“ Punkt dar. Unter den echten Hijackern befand sich auch AS263444, obwohl es noch andere gab. Selbst als wir die Routen des Vorfalls aus der Betrachtung ausschlossen. Warum? Der kritische Punkt kann auch für korrekte Routen kritisch bleiben. Er kann entweder das Ergebnis schlechter Konnektivität in einer bestimmten Region oder Einschränkungen unserer eigenen Sichtbarkeit sein.
Als Ergebnis: Es gibt einen Weg, den Angreifer zu erkennen, aber nur wenn alle oben genannten Bedingungen erfüllt sind und nur wenn die Abfangung groß genug ist, um die Überwachungsgrenzen zu überschreiten. Wenn einige dieser Faktoren jedoch nicht erfüllt sind, können wir dann die von einer solchen Abfangung betroffenen Präfixe identifizieren? Für bestimmte Betreiber – ja.
Wenn ein Angreifer eine more specific Route erstellt, wird dieses Präfix nicht vom eigentlichen Eigentümer angekündigt. Falls Sie von ihm eine dynamische Liste seiner Präfixe haben, können Sie jedoch einen Vergleich durchführen und die verfälschten more specific Routen finden. Wir sammeln diese Präfixliste über unsere BGP-Sitzungen, da uns nicht nur die vollständige Liste der Routen, die der Betreiber derzeit sieht, sondern auch die Liste aller Präfixe, die er der Welt ankündigen möchte, übermittelt wird. Leider gibt es derzeit mehrere Dutzend Radar-Benutzer, die diesen letzten Teil nicht ganz korrekt umsetzen. Bald werden wir sie benachrichtigen und versuchen, dieses Problem zu lösen. Alle anderen können sich derzeit direkt unserem Überwachungssystem anschließen.
Wenn wir zum ursprünglichen Vorfall zurückkehren, wurden sowohl der Angreifer als auch das Verbreitungsgebiet von uns durch die Suche nach kritischen Punkten erkannt. Erstaunlicherweise versendete AS263444 gefälschte Routen nicht an alle seine Kunden. Obwohl es noch einen seltsameren Punkt 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 den Versuch, unseren Adressraum abzufangen.
Als die spezifischeren 'more specific' für unsere Präfixe erstellt wurden, wurde ein speziell erstellter AS_PATH verwendet. Dieser AS_PATH konnte jedoch nicht von einem unserer vorherigen Routen stammen. Wir haben nicht einmal eine Verbindung zu AS6762. Lassen Sie uns die anderen Routen im Vorfall betrachten: Einige von ihnen hatten einen echten AS_PATH, der zuvor verwendet wurde, während andere keinen hatten, auch wenn sie wie ein echter aussahen. Eine zusätzliche Änderung des AS_PATH hat keinen praktischen Sinn, da der Verkehr in jedem Fall an den Angreifer umgeleitet wird, aber Routen mit einem „schlechten“ AS_PATH könnten durch ASPA oder ein anderes Überprüfungsmechanismus herausgefiltert werden. Hier haben wir über die Motivation des Hijackers nachgedacht. Im Moment fehlen uns die Daten, um zu behaupten, dass dieser Vorfall eine geplante Attacke war. Dennoch ist dies möglich. Lassen Sie uns versuchen, eine hypothetische, aber potenziell sehr reale Situation vorzustellen.
Der perfekte Angriff
Was haben wir? Angenommen, Sie sind ein Transitprovider, der Routen für seine Kunden überträgt. Wenn Ihre Kunden mehrere Präsenz haben (multihome), erhalten Sie nur einen Teil ihres Verkehrs. Aber je mehr Verkehr — desto mehr Einkommen haben Sie. Wenn Sie also beginnen, die Präfixe von Subnetzwerken dieser Routen mit demselben AS_PATH anzukündigen, erhalten Sie den verbleibenden Teil ihres Verkehrs. Folglich den restlichen Teil des Geldes.
Hilft hier ROA? Möglicherweise ja, wenn Sie sich entscheiden, die Nutzung vollständig aufzugeben . Darüber hinaus ist es äußerst unerwünscht, ROA-Einträge mit sich überschneidenden Präfixen zu haben. Für einige Betreiber sind solche Einschränkungen inakzeptabel.
Wenn wir andere Sicherheitsmechanismen für das Routing betrachten, wird auch ASPA in diesem Fall nicht helfen (da AS_PATH von einer gültigen Route verwendet wird). BGPSec ist nach wie vor keine optimale Wahl aufgrund der geringen Akzeptanzquote und der verbleibenden Möglichkeit von Downgrade-Attacken.
So haben wir einen klaren Gewinn für den Angreifer und einen Mangel an Sicherheit. Eine hervorragende Mischung!
Was ist zu tun?
Ein offensichtlicher und radikaler Schritt ist die Überprüfung Ihrer aktuellen Routing-Politik. Teilen Sie Ihren Adressraum in die kleinsten Teile (ohne Überlappungen) auf, die Sie nur ankündigen möchten. Zeichnen Sie ROA nur für diese auf, ohne den Parameter maxLength zu verwenden. In diesem Fall kann Ihnen der aktuelle POV möglicherweise vor einem solchen Angriff schützen. Für einige Betreiber ist ein solcher Ansatz jedoch nicht sinnvoll, da er eine außergewöhnliche Nutzung von more specific-Routen zur Folge hat. Alle Probleme des aktuellen Zustands der ROA und der Routing-Objekte werden in einem unserer künftigen Materialien behandelt.
Darüber hinaus können Sie versuchen, ähnliche Abfangen zu überwachen. Dazu benötigen wir vertrauenswürdige Informationen über Ihre Präfixe. Wenn Sie also eine BGP-Sitzung mit unserem Collector einrichten und uns Informationen über Ihre Internet-Sichtbarkeit übermitteln, können wir das Verbreitungsgebiet auch für andere Vorfälle finden. Für diejenigen, die noch nicht mit unserem Überwachungsdienst verbunden sind, reicht zu Beginn eine Liste von Routen mit Ihren Präfixen aus. Wenn Sie jedoch bereits eine Sitzung mit uns haben, überprüfen Sie bitte, ob alle Ihre Routen gesendet wurden. Leider ist es notwendig, daran zu erinnern, da einige Betreiber einen oder zwei Präfixe vergessen und so unsere Suchmethoden stören. Wenn alles richtig gemacht wird, verfügen wir über zuverlässige Daten zu Ihren Präfixen, die in Zukunft helfen, solche (und andere) Arten der Verkehrsabfangung für Ihren Adressraum automatisch zu identifizieren und zu erkennen.
Wenn Sie in Echtzeit von einem solchen Abfangen Ihres Verkehrs erfahren haben, können Sie versuchen, selbst gegenzusteuern. Der erste Ansatz besteht darin, die Routen mit diesen more specific Präfixen selbst anzukündigen. Im Falle eines neuen Angriffs auf diese Präfixe wiederholen Sie den Vorgang.
Der zweite Ansatz besteht darin, den Angreifer und diejenigen, für die er einen kritischen Punkt darstellt (für gute Routen), zu bestrafen, indem Sie den Zugriff Ihrer Routen auf den Angreifer unterbrechen. Dies kann erreicht werden, indem die ASN des Angreifers in den AS_PATH Ihrer alten Routen eingefügt wird, wodurch sie diese AS meiden, indem sie den eingebauten Mechanismus zur Erkennung von Schleifen im BGP nutzen. .
Quelle: habr.com
