Am 13. März wurde in die Arbeitsgruppe RIPE zur Bekämpfung von Missbrauch ein Vorschlag eingebracht BGP-Hijacking (hjjack) als Verstoß gegen die RIPE-Richtlinien zu betrachten. Im Falle einer Annahme des Vorschlags hätte der Internetprovider, der durch den Hijacking-Angriff betroffen ist, die Möglichkeit, eine spezielle Anfrage zur Identifizierung des Angreifers zu stellen. Sollte die Expertengruppe genügend Beweise sammeln, würde ein solcher LIR, der für BGP-Hijacking verantwortlich ist, als Regelbrecher gelten und könnte seinen LIR-Status verlieren. Es gab jedoch auch einige Argumente Änderung.
In diesem Artikel möchten wir ein Beispiel für einen Angriff zeigen, bei dem nicht nur der tatsächliche Angreifer infrage gestellt wurde, sondern auch die gesamte Liste der betroffenen Präfixe. Darüber hinaus wirft ein solcher Angriff erneut Fragen zu den Motiven zukünftiger Verkehrshijacking-Angriffe auf.
In den letzten Jahren wurden in den Medien als BGP-Angriffe hauptsächlich Konflikte vom Typ MOAS (Multiple Origin Autonomous System) behandelt. MOAS ist ein spezieller Fall, in dem zwei verschiedene autonome Systeme widersprüchliche Präfixe mit den entsprechenden ASN-Nummern im AS_PATH ankündigen (der erste ASN im AS_PATH wird als origin ASN bezeichnet). Allerdings können wir mindestens von Traffic-Intercepts nennen, die es Angreifern ermöglichen, das AS_PATH-Attribut zu manipulieren, zu verschiedenen Zwecken, einschließlich der Umgehung moderner Filter- und Überwachungsmethoden. Ein bekannter Angriffstyp ist der neueste Typ eines solchen Angriffs, jedoch keineswegs unwichtig. Es ist durchaus möglich, dass wir genau diesen Angriff in den letzten Wochen beobachtet haben. Ein solches Ereignis hat eine nachvollziehbare und ernsthafte Konsequenz.
Für diejenigen, die eine TL;DR-Version suchen, können Sie zum Untertitel «Die perfekte Attacke» scrollen.
Netzwerk-Hintergrund
(damit Sie die Prozesse, die an diesem Vorfall beteiligt sind, besser verstehen).
Wenn Sie ein Paket senden möchten und mehrere Präfixe in der Routing-Tabelle vorhanden sind, die die Ziel-IP-Adresse enthalten, werden Sie die Route mit dem längsten Präfix verwenden. Sollten in der Routing-Tabelle mehrere unterschiedliche Routen für dasselbe Präfix existieren, wählen Sie die beste Route (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 AS_PATH-Attribut untersuchen. Der Router kann dieses Attribut während der Ankündigung auf beliebige Werte ändern. Ein einfaches Hinzufügen der ASN des Eigentümers zu Beginn des AS_PATH (als Ursprung ASN) kann ausreichen, um die aktuellen Validierungsmechanismen zu umgehen. Darüber hinaus, wenn eine Route von der angegriffenen ASN zu Ihnen besteht, besteht die Möglichkeit, das AS_PATH dieser Route in anderen Ankündigungen von Ihnen abzuziehen und zu verwenden. Jede Überprüfung der Validität nur des AS_PATH für Ihre modifizierten Ankündigungen wird letztendlich bestanden.
Es gibt noch einige erwähnenswerte Einschränkungen. Erstens kann Ihre Route im Falle einer Präfixfilterung durch den übergeordneten Anbieter trotzdem herausgefiltert werden (selbst mit einem korrekten AS_PATH), wenn das Präfix nicht zu Ihrem bei Upstream konfigurierten Kundenkegel gehört. Zweitens kann ein gültiger AS_PATH ungültig werden, wenn die erstellte Route in falsche Richtungen angekündigt wird und somit die Routing-Richtlinie verletzt. Und schließlich kann jede Route mit einem Präfix, das die ROA-Längenregel verletzt, für ungültig erklärt werden.
Incident
Vor einigen Wochen erhielten wir eine Beschwerde von einem Benutzer. Wir haben Routen mit seiner Origin-ASN und Präfixen von /25 gesehen, während der Benutzer behauptete, dass er diese 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 April 2019
NTT auf dem Weg für das Präfix /25 macht es besonders verdächtig. Während des Vorfalls wusste LG NTT nichts über diese Route. Es scheint also, dass ein Betreiber einen kompletten AS_PATH für diese Präfixe erstellt! Eine Überprüfung an anderen Routern zeigt ein besonderes ASN: AS263444. Betrachtet man weitere Routen mit diesem autonomen System, sind wir auf folgende Situation gestoßen:
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 das Präfix aus der Route genommen, es in zwei Teile aufgeteilt 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 eines der Paare getrennter Präfixe
Es tauchen sofort mehrere Fragen auf. Hat wirklich jemand diesen Typ von Abfangversuch in der Praxis ausprobiert? 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
Lassen Sie uns die Dinge der Reihe nach betrachten. Wie können wir herausfinden, welche Router solche abgefangenen Routen angenommen haben und dessen Verkehr möglicherweise bereits heute umgeleitet werden kann? Wir dachten daran, mit den /25-Präfixen zu beginnen, da diese "einfach keine globale Verbreitung haben können". Wie Sie sich vorstellen können, lagen wir damit völlig daneben. 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 er unter seinen eigenen Kunden verbreitet. Auf der anderen Seite ist diese Metrik problematisch, da solche Präfixe gefiltert werden können, wenn der Anbieter , in alle Richtungen anwendet. Daher ist diese Methode nicht geeignet, um alle Anbieter zu finden, deren Verkehr infolge eines solchen Vorfalls umgeleitet wurde.
Eine weitere gute Idee schien uns, einen Blick auf . Besonders bei Routen, die die maxLength-Regel des entsprechenden ROA verletzen. Dadurch könnten wir die Anzahl der verschiedenen origin ASN mit dem Status Invalid ermitteln, die von diesem AS gesehen wurden. Es gibt jedoch ein „kleines“ Problem. Der Durchschnitt (Median und Modus) dieser Zahl (Anzahl verschiedener origin ASN) liegt bei etwa 150, und selbst wenn wir kleine Präfixe herausfiltern, bleibt sie über 70. Diese Situation lässt sich recht einfach erklären: Nur wenige Betreiber setzen bereits ROA-Filter mit der Politik „Invalid-Routen zurücksetzen“ an den Eingangs-Punkten ein, weshalb Routen, die im realen Umfeld gegen ROA verstoßen, sich in alle Richtungen ausbreiten können.
Die letzten beiden Ansätze ermöglichen es, Betreiber zu finden, die unser Ereignis bemerkt haben (da es groß genug war), sind jedoch insgesamt nicht anwendbar. Gut, aber können wir den Angreifer finden? Was sind die allgemeinen Merkmale einer solchen AS_PATH-Manipulation? Es gibt einige grundlegende Annahmen:
- Der Präfix wurde nirgendwo zuvor gesehen;
- Der Origin ASN (Erinnerung: der erste ASN im AS_PATH) ist gültig;
- Das letzte ASN im AS_PATH ist das ASN des Angreifers (wenn sein Nachbar das ASN des Nachbarn in allen eingehenden Routen überprüft);
- Der Angriff stammt von einem Anbieter.
Wenn alle Annahmen zutreffen, wird in allen fehlerhaften Routen das ASN des Angreifers (außer dem Origin ASN) angezeigt, was somit einen "kritischen" Punkt darstellt. Unter den tatsächlichen Hijackern befand sich auch AS263444, obwohl es auch andere gab. Selbst nachdem wir die Routen des Vorfalls aus der Betrachtung ausgeschlossen haben. Warum? Ein kritischer Punkt kann selbst bei korrekten Routen kritisch bleiben. Er kann entweder auf schlechte Konnektivität in einer bestimmten Region oder auf Einschränkungen unserer eigenen Sichtbarkeit zurückzuführen sein.
Das Ergebnis: Es gibt eine Möglichkeit, den Angreifer zu erkennen, aber nur unter der Voraussetzung, dass alle oben genannten Bedingungen erfüllt sind und nur wenn die Abfangen ausreichend groß ist, um die Überwachungsgrenzen zu überschreiten. Wenn jedoch einige dieser Faktoren nicht eingehalten werden, können wir dann die von einem solchen Abfangen betroffenen Präfixe hervorheben? Für bestimmte Betreiber – ja.
Wenn ein Angreifer eine spezifischere Route erstellt, wird ein solches Präfix nicht vom tatsächlichen Eigentümer kommuniziert. Wenn Sie von ihm eine dynamische Liste aller seiner Präfixe haben, besteht die Möglichkeit eines Vergleichs, um verzerrte spezifischere Routen zu finden. Wir sammeln diese Präfixliste über unsere BGP-Sitzungen, da uns nicht nur die vollständige Liste der Routen, die dem Betreiber derzeit sichtbar sind, übergeben wird, sondern auch die Liste aller Präfixe, die er der Welt mitteilen möchte. Leider gibt es derzeit mehrere Dutzend Radar-Nutzer, die diesen letzten Teil nicht korrekt umsetzen. In naher Zukunft werden wir sie benachrichtigen und versuchen, dieses Problem zu lösen. Alle anderen können sich jetzt direkt unserem Überwachungssystem anschließen.
Wenn wir zu dem ursprünglichen Vorfall zurückkehren, wurden sowohl der Angreifer als auch der Verbreitungsbereich von uns mithilfe der Suche nach kritischen Punkten entdeckt. Erstaunlicherweise hat AS263444 gefälschte Routen nicht an alle seine Kunden gesendet. Es gibt jedoch auch einen noch merkwürdigeren Punkt.
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 kürzliches Beispiel für den Versuch, unseren Adressraum abzufangen.
Als die spezifischeren Werte für unsere Präfixe erstellt wurden, wurde ein speziell angefertigter AS_PATH verwendet. Dieser AS_PATH konnte jedoch nicht aus einem unserer vorherigen Routen entnommen werden. Wir haben nicht einmal eine Verbindung zu AS6762. Schauen wir uns die anderen Routen im Vorfall an: Einige von ihnen hatten einen echten AS_PATH, der zuvor verwendet wurde, andere hingegen nicht, selbst wenn sie wie echte aussahen. Eine zusätzliche Änderung des AS_PATH macht praktisch keinen Sinn, da der Datenverkehr in jedem Fall zum Angreifer umgeleitet wird, aber Routen mit einem „schlechten“ AS_PATH können durch ASPA oder einen anderen Überprüfungsmechanismus herausgefiltert werden. Hier haben wir über die Motivation des Angreifers nachgedacht. Momentan fehlen uns die Daten, um zu bestätigen, dass dieser Vorfall ein geplanter Angriff war. Es ist jedoch möglich. Lassen Sie uns versuchen, eine hypothetische, aber potenziell durchaus realistische Situation zu skizzieren.
Idealer Angriff
Was haben wir? Angenommen, Sie sind ein Transitprovider, der Routen für seine Kunden veröffentlicht. Wenn Ihre Kunden mehrere Verbindungen haben (Multihome), erhalten Sie nur einen Teil ihres Datenverkehrs. Aber je mehr Datenverkehr, desto höher Ihr Einkommen. Wenn Sie also die Subnetz-Prefixe dieser Routen mit demselben AS_PATH ankündigen, erhalten Sie den Rest ihres Datenverkehrs. Folglich also auch den Rest des Geldes.
Wird ROA hier helfen? Möglicherweise ja, wenn Sie sich entscheiden, vollständig darauf zu verzichten. . 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 uns andere Mechanismen zur Sicherstellung der Sicherheit in der Routenführung ansehen, hilft in diesem Fall ASPA ebenfalls nicht (da das AS_PATH von der zulässigen Route verwendet wird). BGPSec ist nach wie vor keine optimale Wahl aufgrund der geringen Akzeptanzrate und der Möglichkeit von Downgrade-Angriffen.
Somit haben wir einen klaren Vorteil für den Angreifer und ein mangelndes Sicherheitsniveau. Eine großartige Mischung!
Was ist zu tun?
Der offensichtlichste und radikalste Schritt besteht darin, Ihre aktuelle Routing-Politik zu überdenken. Zerlegen Sie Ihren Adressraum in die kleinsten Stücke (ohne Überlappungen), die Sie nur ankündigen möchten. Signieren Sie für diese nur ROA und verwenden Sie nicht den Parameter maxLength. In diesem Fall kann Ihnen der aktuelle POV vor einem solchen Angriff schützen. Für einige Betreiber ist ein solcher Ansatz jedoch nicht sinnvoll, aufgrund der ausschließlichen Nutzung von more specific Routen. Alle Probleme des aktuellen Zustands von ROA und Route-Objekten werden in einem unserer zukünftigen Materialien beschrieben.
Zusätzlich können Sie versuchen, solche Abfragen zu überwachen. Dazu benötigen wir zuverlässige 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 den Einflussbereich und andere Vorfälle identifizieren. Für diejenigen, die noch nicht an unser Überwachungssystem angeschlossen sind, genügt zunächst eine Liste von Routen mit nur Ihren Präfixen. Wenn Sie jedoch bereits eine Sitzung mit uns eingerichtet haben, überprüfen Sie bitte, ob alle Ihre Routen übermittelt wurden. Leider muss daran erinnert werden, da einige Betreiber einen oder zwei Präfixe vergessen und damit unsere Suchmethoden stören. Wenn alles richtig gemacht wird, haben wir zuverlässige Daten über Ihre Präfixe, die in Zukunft helfen werden, solche (und andere) Arten von Traffic-Abfangungen in Ihrem Adressraum automatisch zu identifizieren und zu detektieren.
Wenn Sie in Echtzeit von einer solchen Abhörung Ihres Traffics erfahren, können Sie versuchen, sich selbst zu wehren. Der erste Ansatz besteht darin, die Routen mit diesen spezifischeren Präfixen selbst anzukündigen. Im Falle eines neuen Angriffs auf diese Präfixe — wiederholen Sie es.
Der zweite Ansatz besteht darin, den Angreifer und diejenigen, für die er ein kritischer Punkt (für gute Routen) ist, zu bestrafen, indem der Zugang Ihrer Routen zum Angreifer unterbrochen wird. Dies kann erreicht werden, indem die ASN des Angreifers in den AS_PATH Ihrer alten Routen hinzugefügt wird und sie damit gezwungen werden, diese AS zu meiden, indem der eingebaute Mechanismus zur Erkennung von Zyklen in BGP verwendet wird. .
Quelle: habr.com
