{"id":31415,"date":"2019-10-31T21:41:08","date_gmt":"2019-10-31T18:41:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika\/"},"modified":"2019-10-31T21:41:08","modified_gmt":"2019-10-31T18:41:08","slug":"vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","title":{"rendered":"Es l\u00e4uft nicht gut oder eine neue Form der Verkehrs\u00fcberwachung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Am 13. M\u00e4rz erhielt die RIPE-Arbeitsgruppe zur Bek\u00e4mpfung von Missbrauchsvorschl\u00e4gen einen Vorschlag<\/a><\/noindex> BGP-Hijacking (hjjack) als Versto\u00df gegen die RIPE-Politik zu betrachten. Im Falle der Annahme des Vorschlags h\u00e4tte der Internetanbieter, der durch den Verkehrshijack angegriffen wurde, die M\u00f6glichkeit, eine spezielle Anfrage zu stellen, um den Angreifer zur Rechenschaft zu ziehen. Wenn die Expertengruppe gen\u00fcgend best\u00e4tigende Beweise sammelt, w\u00fcrde ein solcher LIR, der die Quelle des BGP-Hijackings ist, als T\u00e4ter angesehen und k\u00f6nnte seinen LIR-Status verlieren. Es gab auch einige Argumente gegen dieses Vorgehen.<\/a><\/noindex> \u00c4nderungen.<\/p>\n

In dieser Ver\u00f6ffentlichung m\u00f6chten wir ein Beispiel f\u00fcr einen Angriff pr\u00e4sentieren, bei dem nicht nur der tats\u00e4chliche Angreifer in Frage stand, sondern auch die gesamte Liste der betroffenen Pr\u00e4fixe. Dar\u00fcber hinaus wirft ein solcher Angriff erneut Fragen zu den Motiven zuk\u00fcnftiger Verkehrshijacks dieser Art auf.
\n<\/a><\/noindex>
\nIn 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\u00e4fixe mit entsprechenden ASN-Nummern im AS_PATH ank\u00fcndigen (das erste ASN im AS_PATH, nachfolgend origin ASN genannt). Wir k\u00f6nnen jedoch mindestens drei zus\u00e4tzliche Typen<\/a><\/noindex> von Verkehrshijacks benennen, die es dem Angreifer erm\u00f6glichen, das Attribut AS_PATH mit unterschiedlichen Zielen zu manipulieren, einschlie\u00dflich der Umgehung moderner Filter- und \u00dcberwachungsans\u00e4tze. Ein bekannter Angriffstyp, Pilosova-Kapela,<\/a><\/noindex> ist der letzte Typ eines solchen Hijacks, aber keineswegs der unwichtigste. Es ist durchaus m\u00f6glich, dass wir genau einen solchen Angriff in den letzten Wochen beobachtet haben. Dieses Ereignis hat eine nachvollziehbare Natur und ernsthafte Konsequenzen.<\/p>\n

Wer die TL;DR-Version sucht, kann zum Untertitel \"Perfekter Angriff\" scrollen.<\/p>\n

Netzwerkhintergrund<\/h3>\n

(damit Sie die Prozesse, die an diesem Vorfall beteiligt sind, besser verstehen k\u00f6nnen)<\/i><\/p>\n

Wenn Sie ein Paket senden m\u00f6chten und mehrere Pr\u00e4fixe in der Routingtabelle vorhanden sind, die die Ziel-IP-Adresse enthalten, verwenden Sie die Route f\u00fcr das Pr\u00e4fix mit der maximalen L\u00e4nge. Wenn es in der Routingtabelle jedoch mehrere verschiedene Routen f\u00fcr ein Pr\u00e4fix gibt, w\u00e4hlen Sie die beste (gem\u00e4\u00df dem Mechanismus zur Auswahl des besten Pfades).<\/p>\n

Die bestehenden Ans\u00e4tze zur Filterung und \u00dcberwachung versuchen, Routen zu analysieren und Entscheidungen zu treffen, indem sie das Attribut AS_PATH bewerten. Der Router kann dieses Attribut w\u00e4hrend der Ank\u00fcndigung auf einen beliebigen Wert \u00e4ndern. Das einfache Hinzuf\u00fcgen der ASN des Eigent\u00fcmers zu Beginn des AS_PATH (als origin ASN) kann ausreichen, um die aktuellen Quellverifizierungsmechanismen zu umgehen. Dar\u00fcber hinaus, wenn es eine Route vom angegriffenen ASN zu Ihnen gibt, besteht die M\u00f6glichkeit, das AS_PATH dieser Route in anderen Ihrer Ank\u00fcndigungen zu extrahieren und zu verwenden. Jede \u00dcberpr\u00fcfung der Authentizit\u00e4t nur des AS_PATH f\u00fcr Ihre gef\u00e4lschten Ank\u00fcndigungen wird letztendlich bestanden.<\/p>\n

Es gibt auch einige erw\u00e4hnenswerte Einschr\u00e4nkungen. Erstens kann Ihr Weg durch den \u00fcbergeordneten Anbieter immer noch gefiltert werden (selbst mit einem korrekten AS_PATH), wenn der Pr\u00e4fix nicht zu Ihrem Client-Kegel geh\u00f6rt, der bei Upstream eingerichtet ist. Zweitens - ein g\u00fcltiger AS_PATH kann ung\u00fcltig werden, wenn die erstellte Route in falsche Richtungen angek\u00fcndigt wird und somit die Richtlinien zur Routensteuerung verletzt. Und schlie\u00dflich - jede Route mit einem Pr\u00e4fix, das die ROA-L\u00e4nge verletzt, kann als ung\u00fcltig betrachtet werden.<\/p>\n

Vorf\u00e4lle<\/h3>\n

\nVor einigen Wochen erhielten wir eine Beschwerde von einem der Benutzer. Wir sahen Routen mit seiner origin ASN und Pr\u00e4fixen \/25, w\u00e4hrend der Benutzer behauptete, dass er sie nicht angek\u00fcndigt hatte.<\/p>\n

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0\/25|265466 262761 263444 22356 3491 2914 9121|UNVOLLST\u00c4NDIG|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128\/25|265466 262761 263444 22356 3491 2914 9121|UNVOLLST\u00c4NDIG|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0\/25|265466 262761 263444 6762 2914 9121|UNVOLLST\u00c4NDIG|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128\/25|265466 262761 263444 6762 2914 9121|UNVOLLST\u00c4NDIG|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0\/25|265466 262761 263444 22356 3491 2914 9121|UNVOLLST\u00c4NDIG|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128\/25|265466 262761 263444 22356 3491 2914 9121|UNVOLLST\u00c4NDIG|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0\/25|265466 262761 263444 6762 2914 9121|UNVOLLST\u00c4NDIG|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128\/25|265466 262761 263444 6762 2914 9121|UNVOLLST\u00c4NDIG|xxx|0|0||NAG||<\/code>
\nBeispiele f\u00fcr Ank\u00fcndigungen zu Beginn des April 2019<\/i><\/p>\n

NTT auf dem Weg f\u00fcr Pr\u00e4fix \/25 macht es besonders verd\u00e4chtig. W\u00e4hrend des Vorfalls wusste LG NTT nichts \u00fcber diese Route. Also ja, irgendein Betreiber erstellt einen vollst\u00e4ndigen AS_PATH f\u00fcr diese Pr\u00e4fixe! \u00dcberpr\u00fcfungen auf anderen Routern heben einen besonderen ASN hervor: AS263444. Bei der Betrachtung anderer Routen mit diesem autonomen System stie\u00dfen wir auf die folgende Situation:<\/p>\n

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0\/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128\/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0\/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0\/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||<\/code>
\nVersuchen Sie zu erraten, was hier nicht stimmt<\/i><\/p>\n

Es scheint, dass jemand den Pr\u00e4fix aus der Route genommen, ihn in zwei Teile geteilt hat und eine Route mit demselben AS_PATH f\u00fcr diese beiden Pr\u00e4fixe angek\u00fcndigt hat.<\/p>\n

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||
\nTABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0\/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_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||
\nTABLE_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||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0\/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0\/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||<\/code>
\nBeispiele f\u00fcr Routen einer der Paare geteilter Pr\u00e4fixe<\/i><\/p>\n

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\u00e4fixe waren betroffen?<\/p>\n

Hier beginnt unsere Reihe von Misserfolgen und eine weitere Runde der Entt\u00e4uschung \u00fcber den aktuellen Gesundheitszustand des Internets.<\/p>\n

Der Weg der Misserfolge<\/h3>\n

\nAlles der Reihe nach. Wie k\u00f6nnen wir feststellen, welche Router solche abgefangenen Routen akzeptiert haben und welcher Verkehr bereits heute umgeleitet werden kann? Wir dachten, wir fangen mit den Pr\u00e4fixen \/25 an, denn sie \u201ek\u00f6nnen einfach nicht global verbreitet sein\u201c. Wie Sie erraten k\u00f6nnen \u2014 wir lagen total falsch. Diese Metrik stellte sich als zu verrauscht heraus und Routen mit solchen Pr\u00e4fixen k\u00f6nnen sogar von Tier-1-Anbietern stammen. Zum Beispiel hat NTT etwa 50 solcher Pr\u00e4fixe, die es unter seinen eigenen Kunden verbreitet. Andererseits ist diese Metrik schlecht, weil solche Pr\u00e4fixe gefiltert werden k\u00f6nnen, wenn der Anbieter kleine Pr\u00e4fixfilterung<\/a><\/noindex>, in alle Richtungen anwendet. Daher eignet sich diese Methode nicht zur Auffindung aller Anbieter, deren Verkehr infolge eines solchen Vorfalls umgeleitet wurde.<\/p>\n

Eine weitere gute Idee schien uns, die POV<\/a><\/noindex>zu betrachten. Insbesondere bei Routen, die gegen die maxLength-Regel des entsprechenden ROA versto\u00dfen. Auf diese Weise k\u00f6nnten wir die Anzahl der verschiedenen Origin-ASNs mit dem Status Ung\u00fcltig finden, die diesem AS sichtbar waren. Dennoch gibt es ein \u201ekleines\u201c Problem. Der Mittelwert (Median und Modus) dieser Zahl (Anzahl der verschiedenen Origin-ASNs) liegt bei etwa 150 und selbst wenn wir kleine Pr\u00e4fixe herausfiltern, bleibt er \u00fcber 70. Diese Situation hat eine ganz einfache Erkl\u00e4rung: Es gibt nur wenige Anbieter, die bereits ROA-Filter mit der Politik \u201eUng\u00fcltige Routen zur\u00fccksetzen\u201c an den Eingabepunkten anwenden, weshalb, wo immer in der realen Welt eine Route gegen ROA verst\u00f6\u00dft, sie in alle Richtungen verbreitet werden kann.<\/p>\n

Die letzten beiden Ans\u00e4tze erm\u00f6glichen es, die Anbieter zu finden, die unseren Vorfall bemerkt haben (da er gro\u00df genug war), aber insgesamt sind sie nicht anwendbar. Gut, aber k\u00f6nnen wir den Angreifer finden? Was sind die allgemeinen Merkmale einer solchen Manipulation des AS_PATH? Es gibt einige grundlegende Annahmen:<\/p>\n