{"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":"Alles ist sehr schlecht oder eine neue Art der Verkehrs\u00fcberwachung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Am 13. M\u00e4rz wurde in die Arbeitsgruppe RIPE zur Bek\u00e4mpfung von Missbrauch ein Vorschlag eingebracht der vorsieht<\/a><\/noindex> BGP-Hijacking (hjjack) als Versto\u00df gegen die RIPE-Richtlinien zu betrachten. Im Falle einer Annahme des Vorschlags h\u00e4tte der Internetprovider, der durch den Hijacking-Angriff betroffen ist, die M\u00f6glichkeit, eine spezielle Anfrage zur Identifizierung des Angreifers zu stellen. Sollte die Expertengruppe gen\u00fcgend Beweise sammeln, w\u00fcrde ein solcher LIR, der f\u00fcr BGP-Hijacking verantwortlich ist, als Regelbrecher gelten und k\u00f6nnte seinen LIR-Status verlieren. Es gab jedoch auch einige Argumente gegen eine solche<\/a><\/noindex> \u00c4nderung.<\/p>\n

In diesem Artikel m\u00f6chten wir ein Beispiel f\u00fcr einen Angriff zeigen, bei dem nicht nur der tats\u00e4chliche Angreifer infrage gestellt wurde, sondern auch die gesamte Liste der betroffenen Pr\u00e4fixe. Dar\u00fcber hinaus wirft ein solcher Angriff erneut Fragen zu den Motiven zuk\u00fcnftiger Verkehrshijacking-Angriffe auf.
\n<\/a><\/noindex>
\nIn den letzten Jahren wurden in den Medien als BGP-Angriffe haupts\u00e4chlich Konflikte vom Typ MOAS (Multiple Origin Autonomous System) behandelt. MOAS ist ein spezieller Fall, in dem zwei verschiedene autonome Systeme widerspr\u00fcchliche Pr\u00e4fixe mit den entsprechenden ASN-Nummern im AS_PATH ank\u00fcndigen (der erste ASN im AS_PATH wird als origin ASN bezeichnet). Allerdings k\u00f6nnen wir mindestens drei zus\u00e4tzliche Typen<\/a><\/noindex> von Traffic-Intercepts nennen, die es Angreifern erm\u00f6glichen, das AS_PATH-Attribut zu manipulieren, zu verschiedenen Zwecken, einschlie\u00dflich der Umgehung moderner Filter- und \u00dcberwachungsmethoden. Ein bekannter Angriffstyp Pilosova-Kapela<\/a><\/noindex> ist der neueste Typ eines solchen Angriffs, jedoch keineswegs unwichtig. Es ist durchaus m\u00f6glich, dass wir genau diesen Angriff in den letzten Wochen beobachtet haben. Ein solches Ereignis hat eine nachvollziehbare und ernsthafte Konsequenz.<\/p>\n

F\u00fcr diejenigen, die eine TL;DR-Version suchen, k\u00f6nnen Sie zum Untertitel \u00abDie perfekte Attacke\u00bb scrollen.<\/p>\n

Netzwerk-Hintergrund<\/h3>\n

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

Wenn Sie ein Paket senden m\u00f6chten und mehrere Pr\u00e4fixe in der Routing-Tabelle vorhanden sind, die die Ziel-IP-Adresse enthalten, werden Sie die Route mit dem l\u00e4ngsten Pr\u00e4fix verwenden. Sollten in der Routing-Tabelle mehrere unterschiedliche Routen f\u00fcr dasselbe Pr\u00e4fix existieren, w\u00e4hlen Sie die beste Route (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 AS_PATH-Attribut untersuchen. Der Router kann dieses Attribut w\u00e4hrend der Ank\u00fcndigung auf beliebige Werte \u00e4ndern. Ein einfaches Hinzuf\u00fcgen der ASN des Eigent\u00fcmers zu Beginn des AS_PATH (als Ursprung ASN) kann ausreichen, um die aktuellen Validierungsmechanismen zu umgehen. Dar\u00fcber hinaus, wenn eine Route von der angegriffenen ASN zu Ihnen besteht, besteht die M\u00f6glichkeit, das AS_PATH dieser Route in anderen Ank\u00fcndigungen von Ihnen abzuziehen und zu verwenden. Jede \u00dcberpr\u00fcfung der Validit\u00e4t nur des AS_PATH f\u00fcr Ihre modifizierten Ank\u00fcndigungen wird letztendlich bestanden.<\/p>\n

Es gibt noch einige erw\u00e4hnenswerte Einschr\u00e4nkungen. Erstens kann Ihre Route im Falle einer Pr\u00e4fixfilterung durch den \u00fcbergeordneten Anbieter trotzdem herausgefiltert werden (selbst mit einem korrekten AS_PATH), wenn das Pr\u00e4fix nicht zu Ihrem bei Upstream konfigurierten Kundenkegel geh\u00f6rt. Zweitens kann ein g\u00fcltiger AS_PATH ung\u00fcltig werden, wenn die erstellte Route in falsche Richtungen angek\u00fcndigt wird und somit die Routing-Richtlinie verletzt. Und schlie\u00dflich kann jede Route mit einem Pr\u00e4fix, das die ROA-L\u00e4ngenregel verletzt, f\u00fcr ung\u00fcltig erkl\u00e4rt werden.<\/p>\n

Incident<\/h3>\n

\nVor einigen Wochen erhielten wir eine Beschwerde von einem Benutzer. Wir haben Routen mit seiner Origin-ASN und Pr\u00e4fixen von \/25 gesehen, w\u00e4hrend der Benutzer behauptete, dass er diese 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 April 2019<\/i><\/p>\n

NTT auf dem Weg f\u00fcr das Pr\u00e4fix \/25 macht es besonders verd\u00e4chtig. W\u00e4hrend des Vorfalls wusste LG NTT nichts \u00fcber diese Route. Es scheint also, dass ein Betreiber einen kompletten AS_PATH f\u00fcr diese Pr\u00e4fixe erstellt! Eine \u00dcberpr\u00fcfung an anderen Routern zeigt ein besonderes ASN: AS263444. Betrachtet man weitere Routen mit diesem autonomen System, sind wir auf folgende Situation gesto\u00dfen:<\/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 das Pr\u00e4fix aus der Route genommen, es in zwei Teile aufgeteilt und die 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 eines der Paare getrennter Pr\u00e4fixe<\/i><\/p>\n

Es tauchen sofort mehrere Fragen auf. Hat wirklich jemand diesen Typ von Abfangversuch in der Praxis ausprobiert? 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

\nLassen Sie uns die Dinge der Reihe nach betrachten. Wie k\u00f6nnen wir herausfinden, welche Router solche abgefangenen Routen angenommen haben und dessen Verkehr m\u00f6glicherweise bereits heute umgeleitet werden kann? Wir dachten daran, mit den \/25-Pr\u00e4fixen zu beginnen, da diese \"einfach keine globale Verbreitung haben k\u00f6nnen\". Wie Sie sich vorstellen k\u00f6nnen, lagen wir damit v\u00f6llig daneben. 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 er unter seinen eigenen Kunden verbreitet. Auf der anderen Seite ist diese Metrik problematisch, da solche Pr\u00e4fixe gefiltert werden k\u00f6nnen, wenn der Anbieter kleine Pr\u00e4fixfilterung<\/a><\/noindex>, in alle Richtungen anwendet. Daher ist diese Methode nicht geeignet, um alle Anbieter zu finden, deren Verkehr infolge eines solchen Vorfalls umgeleitet wurde.<\/p>\n

Eine weitere gute Idee schien uns, einen Blick auf POV<\/a><\/noindex>. Besonders bei Routen, die die maxLength-Regel des entsprechenden ROA verletzen. Dadurch k\u00f6nnten wir die Anzahl der verschiedenen origin ASN mit dem Status Invalid ermitteln, die von diesem AS gesehen wurden. Es gibt jedoch ein \u201ekleines\u201c Problem. Der Durchschnitt (Median und Modus) dieser Zahl (Anzahl verschiedener origin ASN) liegt bei etwa 150, und selbst wenn wir kleine Pr\u00e4fixe herausfiltern, bleibt sie \u00fcber 70. Diese Situation l\u00e4sst sich recht einfach erkl\u00e4ren: Nur wenige Betreiber setzen bereits ROA-Filter mit der Politik \u201eInvalid-Routen zur\u00fccksetzen\u201c an den Eingangs-Punkten ein, weshalb Routen, die im realen Umfeld gegen ROA versto\u00dfen, sich in alle Richtungen ausbreiten k\u00f6nnen.<\/p>\n

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