{"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\/fr\/blog\/administrirovanie\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","title":{"rendered":"Tout va tr\u00e8s mal ou un nouveau type d'interception de trafic","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Le 13 mars, un projet de groupe de travail RIPE sur la lutte contre les abus a re\u00e7u une proposition<\/a><\/noindex> d\u2019envisager l'attaque par BGP hijacking (hjjack) comme une violation de la politique RIPE. Si la proposition est adopt\u00e9e, le fournisseur d'acc\u00e8s Internet victime d'un d\u00e9tournement de trafic aurait la possibilit\u00e9 d'envoyer une demande sp\u00e9ciale pour exposer l'attaquant. Si le groupe d'experts rassemble suffisamment de preuves, un LIR \u00e0 l'origine du BGP hijack serait consid\u00e9r\u00e9 comme un contrevenant et pourrait perdre son statut de LIR. Il y a \u00e9galement eu des arguments contre cela.<\/a><\/noindex> modifications.<\/p>\n

Dans cette publication, nous souhaitons montrer un exemple d'attaque, o\u00f9 non seulement le v\u00e9ritable agresseur \u00e9tait en question, mais aussi toute la liste des pr\u00e9fixes touch\u00e9s. De plus, cette attaque soul\u00e8ve de nouveau des questions sur les motifs de futurs d\u00e9tournements de trafic de ce type.
\n<\/a><\/noindex>
\nAu cours des deux derni\u00e8res ann\u00e9es, la presse a couvert les BGP hijacks principalement sous forme de conflits MOAS (Multiple Origin Autonomous System). Le MOAS est un cas particulier o\u00f9 deux syst\u00e8mes autonomes distincts annoncent des pr\u00e9fixes conflictuels avec les num\u00e9ros ASN appropri\u00e9s dans l'AS_PATH (le premier ASN dans l'AS_PATH, ci-apr\u00e8s \u2014 origin ASN). Cependant, nous pouvons citer au moins 3 types suppl\u00e9mentaires<\/a><\/noindex> de d\u00e9tournement de trafic, permettant \u00e0 l'attaquant de manipuler l'attribut AS_PATH \u00e0 diff\u00e9rentes fins, y compris pour contourner les m\u00e9thodes modernes de filtrage et de surveillance. Un type d'attaque connu Pilosova-Kapela<\/a><\/noindex> est le dernier type de ce d\u00e9tournement, mais pas le moins significatif. Il est tout \u00e0 fait possible que nous ayons observ\u00e9 ce type d'attaque au cours des derni\u00e8res semaines. Cet \u00e9v\u00e9nement a une port\u00e9e explicative et des cons\u00e9quences assez graves.<\/p>\n

Ceux qui recherchent une version TL;DR peuvent faire d\u00e9filer jusqu'\u00e0 la sous-titre \u00ab L'attaque parfaite \u00bb.<\/p>\n

Contexte r\u00e9seau<\/h3>\n

(pour que vous compreniez mieux les processus impliqu\u00e9s dans cet incident)<\/i><\/p>\n

Si vous souhaitez envoyer un paquet et que vous avez plusieurs pr\u00e9fixes dans le tableau de routage contenant l'adresse IP de destination, vous utiliserez le trajet pour le pr\u00e9fixe de la longueur maximale. S'il existe plusieurs itin\u00e9raires diff\u00e9rents pour un m\u00eame pr\u00e9fixe dans le tableau de routage, vous choisirez le meilleur (selon le m\u00e9canisme de s\u00e9lection du meilleur chemin).<\/p>\n

Les approches existantes en mati\u00e8re de filtrage et de surveillance tentent d'analyser les routes et de prendre des d\u00e9cisions en examinant l'attribut AS_PATH. Le routeur peut modifier cet attribut \u00e0 n'importe quelle valeur lors de l'annonce. Il peut suffire d'ajouter l'ASN du propri\u00e9taire au d\u00e9but de l'AS_PATH (comme ASN d'origine) pour contourner les m\u00e9canismes de v\u00e9rification de source actuels. De plus, s'il existe une route depuis l'ASN cibl\u00e9 jusqu'\u00e0 vous, il est possible d'extraire et d'utiliser l'AS_PATH de cette route dans d'autres annonces. Toute v\u00e9rification de validit\u00e9 de l'AS_PATH uniquement pour vos annonces fabriqu\u00e9es sera finalement r\u00e9ussie.<\/p>\n

Il existe \u00e9galement plusieurs autres limitations dignes de mention. Tout d'abord, en cas de filtrage de pr\u00e9fixes par un fournisseur sup\u00e9rieur, votre route peut toujours \u00eatre filtr\u00e9e (m\u00eame avec un AS_PATH correct) si le pr\u00e9fixe n'appartient pas \u00e0 votre c\u00f4ne client, r\u00e9gl\u00e9 chez l'upstream. Deuxi\u00e8mement, un AS_PATH valide peut devenir invalide si la route cr\u00e9\u00e9e est annonc\u00e9e dans des directions incorrectes et enfreint ainsi la politique de routage. Enfin, toute route avec un pr\u00e9fixe enfreignant la longueur ROA peut \u00eatre consid\u00e9r\u00e9e comme invalide.<\/p>\n

Incident<\/h3>\n

\nIl y a quelques semaines, nous avons re\u00e7u une plainte d'un utilisateur. Nous avons vu des routes avec son ASN d'origine et des pr\u00e9fixes \/25, alors que l'utilisateur affirmait qu'il ne les avait pas annonc\u00e9s.<\/p>\n

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0\/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128\/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0\/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128\/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||<\/code>
\nExemples d'annonces au d\u00e9but d'avril 2019<\/i><\/p>\n

NTT sur la route pour le pr\u00e9fixe \/25 la rend particuli\u00e8rement suspecte. Pendant l'incident, NTT ne savait rien de cette route. Donc oui, un certain op\u00e9rateur cr\u00e9e un AS_PATH entier pour ces pr\u00e9fixes ! La v\u00e9rification sur d'autres routeurs permet de mettre en \u00e9vidence un ASN particulier : AS263444. En examinant d'autres routes avec ce syst\u00e8me autonome, nous avons rencontr\u00e9 la situation suivante :<\/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>
\nEssayez de deviner ce qui ne va pas ici<\/i><\/p>\n

Il semble que quelqu'un ait pris le pr\u00e9fixe d'une route, l'ait divis\u00e9 en deux parties et annonc\u00e9 une route avec le m\u00eame AS_PATH pour ces deux pr\u00e9fixes.<\/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>
\nExemples de routes pour l'une des paires de pr\u00e9fixes divis\u00e9s<\/i><\/p>\n

Plusieurs questions se posent. Quelqu'un a-t-il d\u00e9j\u00e0 essay\u00e9 un tel type d'interception en pratique ? Quelqu'un a-t-il accept\u00e9 ces routes ? Quels pr\u00e9fixes ont \u00e9t\u00e9 touch\u00e9s ?<\/p>\n

C'est ici que commence notre s\u00e9rie d'\u00e9checs et un autre tour de d\u00e9ceptions concernant l'\u00e9tat actuel de la sant\u00e9 d'Internet.<\/p>\n

Le chemin des \u00e9checs<\/h3>\n

\nTout d'abord, comment pouvons-nous d\u00e9terminer quels routeurs ont accept\u00e9 de telles routes intercept\u00e9es et quel trafic peut d\u00e9j\u00e0 \u00eatre redirig\u00e9 aujourd'hui ? Nous avons pens\u00e9 commencer par les pr\u00e9fixes \/25, car ils \u00ab ne peuvent tout simplement pas avoir de distribution mondiale \u00bb. Comme vous pouvez le deviner, nous avions clairement tort. Cette m\u00e9trique s'est r\u00e9v\u00e9l\u00e9e trop bruit\u00e9e et les routes avec de tels pr\u00e9fixes peuvent appara\u00eetre m\u00eame chez des op\u00e9rateurs de niveau 1. Par exemple, NTT a environ 50 de ces pr\u00e9fixes qu'il distribue \u00e0 ses propres clients. D'autre part, cette m\u00e9trique est mauvaise car ces pr\u00e9fixes peuvent \u00eatre filtr\u00e9s si l'op\u00e9rateur applique le filtrage des petits pr\u00e9fixes<\/a><\/noindex>, dans toutes les directions. Par cons\u00e9quent, cette m\u00e9thode ne convient pas pour trouver tous les op\u00e9rateurs dont le trafic a \u00e9t\u00e9 redirig\u00e9 \u00e0 la suite d'un tel incident.<\/p>\n

Une autre bonne id\u00e9e nous a sembl\u00e9 d'examiner POV<\/a><\/noindex>. En particulier, les routes enfreignant la r\u00e8gle maxLength du ROA correspondant. Ainsi, nous pourrions trouver le nombre de diff\u00e9rents ASN d'origine avec un statut Invalid, qui \u00e9taient visibles par ce AS. Cependant, il y a un \u00ab petit \u00bb probl\u00e8me. La valeur moyenne (m\u00e9diane et mode) de ce nombre (nombre de diff\u00e9rents ASN d'origine) est d'environ 150 et, m\u00eame si nous filtrons les petits pr\u00e9fixes, cela restera au-dessus de 70. Cette situation s'explique assez simplement : il n'y a que quelques op\u00e9rateurs qui appliquent d\u00e9j\u00e0 des filtres ROA avec la politique \u00ab rejeter les routes Invalid \u00bb aux points d'entr\u00e9e, donc, o\u00f9 que dans le monde r\u00e9el une route enfreignante le ROA apparaisse, elle peut se propager dans toutes les directions.<\/p>\n

Les deux derni\u00e8res approches permettent de trouver les op\u00e9rateurs ayant vu notre incident (car il \u00e9tait suffisamment important), mais dans l'ensemble, elles ne sont pas applicables. Tr\u00e8s bien, mais pouvons-nous trouver l'attaquant ? Quelles sont les caract\u00e9ristiques g\u00e9n\u00e9rales de cette manipulation AS_PATH ? Il y a quelques hypoth\u00e8ses de base :<\/p>\n