Angriffe auf BGP.
Diese Verstöße können durch die folgenden Angriffe auf das BGP-Protokoll verursacht werden.
BGP basiert auf dem TCP-Protokoll und lauscht auf Port 179. Daher ist das BGP-Protokoll anfällig für Angriffe auf TCP, über die wir bereits gesprochen haben.
Angriff von Vertraulichkeitsverletzungen. Wie bereits erwähnt, werden die BGP-Routendaten im Klartext übertragen, wodurch Informationen leicht abgefangen werden können (dies liegt daran, dass die Vertraulichkeit der Routendaten keine allgemeine Voraussetzung ist).
Replay-Angriff. BGP enthält keine Maßnahmen, um zu verhindern, dass abgefangene Nachrichten wieder verwendet werden.
Message insertion-Angriff. BGP enthält keinen Schutz vor dem Einfügen von Nachrichten. Da BGP jedoch das TCP-Transportprotokoll verwendet, erfordert das Einfügen von Nachrichten an einen externen Knoten bei abgeschlossener Verbindungsorganisation eine genaue Vorhersage von Sequenznummern (eine solche Vorhersage ist möglich, ist aber für gute TCP-Implementierungen sehr schwierig) oder das Abfangen von Sitzungen, wenn die Verbindung abgeschlossen ist.
Message deletion-Angriff. BGP enthält keinen Schutz vor dem Löschen von Nachrichten. Auch hier sind solche Angriffe für hochwertige TCP-Implementierungen sehr schwierig, aber sie können sie nicht vollständig ausschließen.
Message modification-Angriff. BGP enthält keinen Schutz vor Nachrichtenänderungen. Eine syntaktisch korrekte Änderung ohne Änderung der TCP-Datengröße wird im Allgemeinen nicht wahrnehmbar sein.
Man-in-the-Middle-Angriff (menschliche Angriffe). BGP enthält keine Schutzmaßnahmen gegen MITM-Angriffe. BGP verwendet keine Partnerauthentifizierung, und solche Angriffe werden zu einem «Kinderspielzeug».
Angriff auf denial of service (Angriffe auf Dienste). Obwohl falsche Wegdaten selbst als DoS-Angriff auf das Zielsystem dienen können, das versucht, Daten über das Netzwerk und das Netzwerk als Ganzes zu übertragen, können einige Arten falscher Informationen DoS-Angriffe auf das BGP-Protokoll selbst verursachen. Wenn Sie beispielsweise eine große Anzahl spezifischerer Routen (längere Präfixe) ankündigen, kann dies zu einem Anstieg des BGP-Datenverkehrs und der Größe der Routingtabellen führen, was für das System nicht akzeptabel ist.
Um das in diesem Abschnitt Beschriebene zusammenzufassen, ist anzumerken, dass die Risiken auf drei Hauptanfälligkeiten zurückzuführen sind:
es fehlt ein integrierter Mechanismus zum Schutz der Datenintegrität und -aktualität, zur Authentifizierung von Partnern für die Übertragung von Nachrichten;
kein AS-Berechtigungs-Überprüfungsmechanismus für angekündigte NLRI-Informationen (Network Layer Reachability Information);
es gibt keinen Mechanismus, um sicherzustellen, dass die von AS angekündigten Routenattribute zuverlässig sind.
Einfaches BGP-Hijacking.
Normalerweise sieht BGP Hijacking so aus: AS, das kein Präfix besitzt, beginnt es (das Präfix eines anderen) anzukündigen, die Applinks / Piers akzeptieren es und es beginnt sich im Internet zu verbreiten. Sie nehmen es, weil es keine Präfixfilterung an der Verbindung gibt (entweder ist es ein Konfigurationsfehler oder es ist so konzipiert (weil es aufgrund verschiedener Gründe sehr schwierig ist, einen Präfixfilter an der Verbindung mit sehr großen Operatoren zu erstellen, dies ist für diesen Artikel nicht wichtig)). Eines der bekanntesten Beispiele in letzter Zeit ist, als Rostelecom (AS12389) begann, die Präfixe von Mastercard (AS26380), Visa und einigen anderen Finanzorganisationen (nach der offiziellen Version als Folge eines Softwarefehlers) bekannt zu geben. Wie diese Ankündigungen aussahen, können Sie in der Geschichte von bgplay sehen (über das Web angesehen, json (Archiv)), hier ist einer von ihnen auf einem der RIPE-Collectors (das Präfix 216.119.216.0/24 gehört zu Mastercard (AS26380))):
"source_id": "05-193.203.0.185",
"path": [
6939,
12389
],
"community": [],
"target_prefix": 216.119.216.0/24
Aber so sah die echte Ankündigung aus:
"source_id": "05-193.203.0.63",
"path": [
6720,
8447,
32787,
26380,
26380,
26380
],
"community": [
"1120:1"
],
"target_prefix": 216.119.216.0/24
Das heißt, in diesem Fall hat Rostelecom das Präfix direkt von seinem AS angekündigt (das letzte AS in AS-PATH ist 12389). Das Problem könnte vermieden werden, wenn die Aplinks und Rostelecom-Pyren die Präfixe vom Rostelecom filtern, indem sie AS-SET-Präfixe erstellen und/ oder RPKI-Präfixe nach ROA validieren. Das Erstellen von Präfixlisten zwischen großen Betreibern wird oft nicht durchgeführt, und RPKI hat auch nicht alles implementiert (aber es gibt Fortschritte). Ein solches Hijacking kann theoretisch jeder machen, aber nur, wenn das angekündigte Präfix mindestens einen Aplink / Pir durchläuft. Normalerweise richten große russische Betreiber Präfixfilter für ihre Kunden ein, und daher können kleine AS (kleine / mittlere Betreiber, einige Hostings und einige Unternehmen) fast immer keinen solchen Angriff durchführen (aber wiederum hängt alles von der Region / dem Land / dem jeweiligen Betreiber ab).
Die Angreifer finden jedoch immer noch Orte (Aplinks), an denen die Filterung nicht konfiguriert ist (Brasilien war 2017 der Anführer von Hijacking) und greifen IP-Adressen an / erfassen (oft fallen solche Ereignisse in Nachrichten
bänder), für eine höhere Effektivität können Angriffe spezifischere Präfixe ankündigen (mit einer längeren Maske) als der echte Original. Gehen wir nun zu einer Angriffsoption über, bei der weder die Validierung nach RPKI-ROA noch die Präfixlisten, die nach AS-SET erstellt wurden, gespeichert werden.
BGP hijacking mit dem Hinzufügen des AS des Opfers zu Seinem AS-SET.
Betrachten Sie das folgende Szenario.
Der Angreifer erhält AS und IP-Adressen (in der Tat benötigt er technisch keine IP-Adressen, sondern nur, um keine Fragen zu stellen).
Der Angreifer verbindet sich mit verschiedenen großen und IX-Operatoren (mindestens mit einem Operator oder IX) und gibt als Datenquelle zu den angekündigten Präfixen nicht nur sein AS an, sondern sein AS-SET (dies ist normal für die interoperative Interaktion (einschließlich Client-Aplink-Beziehungen) oder für die Aufnahme auf IX'ah)). Im normalen Fall wird AS-SET angegeben, nicht nur AS, wenn impliziert wird, dass der Client nicht Deadlock ist, sondern er selbst Clients mit bgp und seinen eigenen Netzwerken hat (oder haben wird).
Der Angreifer fügt dem AS-SET nach einiger Zeit das AS des Opfers hinzu und beginnt sein Präfix über sich selbst anzukündigen, dh der angekündigte AS-PATH sieht folgendermaßen aus: «as_des as_des Opfers». In Bezug auf automatisch erstellte Präfixblätter und aus RPKI-Sicht ist dies eine völlig gültige Ankündigung, daher funktionieren beide Schutzmechanismen hier nicht.
Das angekündigte Präfix beginnt mit der tatsächlichen Ankündigung zu konkurrieren (die Ankündigung des Opfers), irgendwo gewinnt es und landet in der Routing-Tabelle, irgendwo verliert es und wird nicht getroffen (es bleibt die Ankündigung des Opfers). Es hängt davon ab, wie viel Applinks und wie viel ein Angreifer verwendet. Wenn ein Angreifer eine Verbindung zu einem AS als Client herstellt, wird er (meistens) durch mehr local-pref vom Opfer profitieren (es sei denn, das Opfer ist derselbe Client, dann wird das Opfer über AS-PATH gewinnen, wenn es keine Prepends macht), dh ein Angreifer muss sich mit seinem AS-SET mit so vielen Aplinks verbinden, um die Effektivität seines Angriffs zu maximieren.
Der Angreifer muss sich auch mit der maximalen Anzahl von IX's verbinden, da normalerweise Deadlock-AS den größten local-pref auf IX's setzen und wenn das Präfix des Opfers nicht an IX teilnimmt, verliert er die Ankündigung des Angreifers in den Routing-Tabellen der Deadlock-AS.
In der Theorie ist dies ein ziemlich starker Angriff, aber glücklicherweise werden die folgenden Einschränkungen in der Praxis auftreten.
Sie müssen mindestens eine juristische Person ausstellen, aber tatsächlich werden sie wahrscheinlich in verschiedenen Ländern benötigt.
Es ist notwendig, Verträge mit den Betreibern zu schließen, die fast immer die Zahlung für die Verbindung mit LIR / RIR leisten.
Einige Operatoren erstellen keine AS-SET-Präfixblätter automatisch, sie müssen dafür Briefe schreiben. Ein erfahrener Administrator wird etwas vermuten, wenn plötzlich ein bekanntes AS-SET in einem unbekannten Unternehmen auftaucht.
Nach dem Angriff wird die verwendete Ausrüstung (wenn sie in einem Rechenzentrum platziert wird) wahrscheinlich beschlagnahmt, wenn ein Strafverfahren eröffnet wird.
Die Präfixlisten verschiedener/IX-Operatoren werden zu unterschiedlichen Zeiten aktualisiert, daher müssen Sie analysieren, wer wann aktualisiert wird, dies ist auch nicht die einfachste Aufgabe.
Mögliche Schutzmaßnahmen.
Theoretisch müssen Sie, um sich vor einem solchen Angriff zu schützen, so viele Verbindungen wie möglich mit den Betreibern (besser als Client, weil sie oben local-pref haben) und IX'ami haben. Das heißt, dasselbe zu tun, was ein Angreifer tun würde. Natürlich ist dies in der Praxis äußerst schwierig zu implementieren und erfordert erhebliche Ressourcen. Diese Methode ist nur für Dienste relevant, die sich mit der Bereitstellung von Informationssicherheitsdiensten auf professioneller Basis befassen.
Wenn Sie eine Website haben, verwenden Sie einen CAA-Eintrag mit dem account–Auftrag (wenn Ihr SSL-Zertifikatanbieter dies unterstützt; letsencrypt unterstützt dies) (siehe RFC6844). In diesem Fall kann ein Angreifer das Zertifikat nicht ausstellen (es sei denn, er kann den CAA-Datensatz ändern).
Theoretisch sollte die weit verbreitete Implementierung von BGPsec einen solchen Angriff eliminieren, aber sein Schicksal ist noch nicht klar (es wird in der Praxis noch nicht angewendet oder sehr selten verwendet).
Implementierung der alternativen AS_PATH-Verifizierung (ohne BGPsec) (bisher ist dies ein Draft, der das beschriebene Problem löst, wenn es überall implementiert wird).
Das Verbot, ein AS-SET ohne Erlaubnis des AS-Besitzers unkontrolliert zu seinem AS-SET hinzuzufügen, könnte die Möglichkeit solcher Angriffe in Regionen verringern, in denen AS-SET's zum Filtern an Fugen verwendet werden. Jetzt gibt es kein solches Verbot.
Tatsächlich ist für die meisten Leser der einzige für sie anwendbare Ratschlag Nummer 2 (bezüglich der Verwendung von account in einem CAA–Eintrag) und teilweise Nummer 1 im Zusammenhang mit der Auswahl eines Hosters mit guter Konnektivität. Beachten Sie dabei die möglichen Angriffe auf den DNS-Dienst, in dem Sie Ihre Datensätze hosten (dies ist jedoch eine separate Frage, und es gibt viele Materialien dafür).
Ist es schwer zu greifen torproject.org .
Ein Angreifer muss zwei Aufgaben lösen:
traffic auf die Zielgruppe umleiten (CA - wer wird eine gefälschte Website erhalten);
zertifikat generieren.
Einleitend:
$ dig torproject.org CAA +short
128 issuewild "\;"
0 iodef "mailto:torproject-admin@torproject.org"
128 issue "globalsign.com"
128 issue "letsencrypt.org"
$ dig torproject.org +short
95.216.163.36
138.201.14.197
Wie Sie sehen können, ist ein CAA-Eintrag vorhanden, Sie können ein Zertifikat von letsencrypt erhalten, es gibt keine Bindung zum Konto im CAA-Eintrag, daher ist das Problem theoretisch vom Angreifer gelöst. Domain-IP-Adressen torproject.org gehören dem ziemlich bekannten Hezner-Hosting an.
Angenommen, der Angreifer ist der Kunde eines russischen Betreibers. Hezner ist kein Kunde von russischen Betreibern (hat aber Peering mit großen – direkt oder über IX's). Damit ein Angreifer den CA-Datenverkehr zu sich selbst umleiten kann, ist es am einfachsten, ein Kunde dieses Betreibers zu werden und einfach durch einen höheren local-pref zu gewinnen. Hier ist besonders alles relativ einfach und verständlich.
Um ein Zertifikat in letsencrypt zu erhalten, muss der Anbieter, der letsencrypt hostet, den Datenverkehr an den Angreifer leiten und nicht an Hezner (AS24940). letsencrypt wird verschiedene Adressen für amerikanische und europäische IP-Adressen finden, aber lassen Sie uns herausfinden, wie schwierig es sein wird, den Datenverkehr zu beeinflussen acme-v02.api.letsencrypt.org/2.19.125.202 ging zum Host des Eindringlings. Hier stoßen wir auf die Tatsache, dass letsencrypt in einem Akamai-CDN gehostet wird, das eine sehr gute Konnektivität auf der ganzen Welt hat (es ist auf den meisten großen IXS vorhanden, hat direkte Verbindungen zu vielen großen Spielern). Akamai hat kein öffentliches LG, im Prinzip gibt es eine API für Kunden, mit der traceroute/Ping durchgeführt werden kann, aber auch ohne öffentliches LG kann man in die peering db schauen, um das Ausmaß ihrer Präsenz zu beurteilen. Ähnlich sieht es bei Hezner aus. Es ist nicht schwer zu sehen, dass beide AS auf demselben IX präsent sind, daher kann man daraus schließen, dass die Präfixe AS Hezner (AS24940) in der Akamai-Tabelle (AS20940) mit AS_PATH 24940 mit einer Wahrscheinlichkeit nahe eins sichtbar sind. Dies bedeutet, dass, wenn ein Angreifer versucht, durch ein IX-Präfix von Hezner anzurufen, er diese Ankündigungen von Hezner nach AS_PATH verliert (da AS_PATH der Angreifer in AS_PATH ist). Eine mögliche Lösung könnte sein, ein «direktes» Peering zwischen dem Angreifer und Akamai zu organisieren (wenn Akamai dem zustimmt und der local-pref höher ist als an den Verbindungen zu IX'ami).
Zusammenfassend lässt sich sagen, dass das Hinzufügen eines anderen AS zu Ihrem AS-SET zu einer erheblichen Verschlechterung der Website führen kann torproject.org (für eine große Anzahl von Kunden, aber nicht für alle im Allgemeinen), aber ein SSL-Zertifikat erwerben torproject.org in letsencrypt wird es wahrscheinlich aufgrund der guten Konnektivität zwischen dem echten Originator (Hezner) und dem CDN, das von letsencrypt (Akamai) verwendet wird, nicht funktionieren. In anderen Fällen, in denen zwischen dem Hosting der Opferseite und der Zertifizierungsstelle Transit-AS vorhanden sind und diese im AS_PATH vorhanden sind, erhöht sich jedoch das Risiko, mit der beschriebenen Methode ein Zertifikat zu erhalten.
Oleg Petukhov, Rechtsanwalt im Bereich des Völkerrechts und des Schutzes personenbezogener Daten, Spezialist für Informationstechnik sicherheit, Schutz von Informationen und persönlichen Daten.
Telegramm-Kanal: https://t.me/datenschutzmit
Die Gruppe im Telegramm: https://t.me/datenschutzmit1
Website: https://legascom.ru
E-Mail: online@legascom.ru
#informationssicherheit #informationssicherheit
