Le 13 mars, le groupe de travail anti-abus du RIPE a
reçu une proposition de considérer le détournement comme une violation de la politique du RIPE. Si la proposition était acceptée, le fournisseur d'accès Internet attaqué par interception de trafic serait en mesure d'envoyer une demande spéciale pour amener l'attaquant à l'eau potable. Si le groupe d'experts recueille suffisamment de preuves à l'appui, un tel LIR, qui est la source de l'interception BGP, serait considéré comme un intrus et pourrait être privé du statut de LIR. Il y avait quelques arguments
contre ce changement.
Dans cette publication, nous voulons montrer un exemple d'attaque lorsque non seulement le véritable attaquant était dans le doute, mais la liste complète des préfixes affectés. De plus, une telle attaque soulève à nouveau des questions sur les motifs des futures interceptions de ce type de trafic.
Au cours des deux dernières années, seuls des conflits comme MOAS (Multiple Origin Autonomous System) ont été rapportés dans la presse comme interceptions BGP. MOAS est un cas particulier lorsque deux systèmes autonomes différents annoncent des préfixes en conflit avec les numéros ASN correspondants dans AS_PATH (le premier ASN dans AS_PATH, ci-après dénommé ASN d'origine). Cependant, nous pouvons nommer au moins
3 types supplémentaires d' interception
de trafic qui permettent à un attaquant de manipuler l'attribut AS_PATH à des fins différentes, y compris pour contourner les approches modernes de filtrage et de surveillance. Le type bien connu d'
attaque Pilosov-Capela est le dernier type d'une telle interception, mais pas du tout important. Il est possible que ce soit précisément l'attaque que nous avons observée ces dernières semaines. Un tel événement a un caractère compréhensible et des conséquences assez graves.
Ceux qui recherchent une version TL; DR peuvent faire défiler jusqu'à la sous-rubrique "Perfect Attack".
Contexte du réseau
(pour mieux comprendre les processus impliqués dans cet incident)Si vous souhaitez envoyer un paquet et que vous avez plusieurs préfixes dans la table de routage contenant l'adresse IP de destination, vous utiliserez l'itinéraire pour le préfixe avec la longueur maximale. Si dans la table de routage il y a plusieurs routes différentes pour un préfixe, vous choisirez la meilleure (conformément au mécanisme de choix du meilleur chemin).
Les approches de filtrage et de surveillance existantes tentent d'analyser les itinéraires et de prendre des décisions en analysant l'attribut AS_PATH. Le routeur peut changer cet attribut en n'importe quelle valeur lors de l'annonce. Ajouter simplement le propriétaire ASN au début de AS_PATH (comme l'origine ASN) peut être suffisant pour contourner les mécanismes actuels de vérification de la source. De plus, s'il existe une route de l'ASN attaqué vers vous, il devient possible d'extraire et d'utiliser l'AS_PATH de cette route dans vos autres annonces. Toute validation de seulement AS_PATH pour vos annonces spécialement conçues sera finalement passée.
Il existe plusieurs limitations notables. Premièrement, dans le cas du filtrage des préfixes par un fournisseur supérieur, votre itinéraire peut toujours être filtré (même avec le bon AS_PATH) si le préfixe n'appartient pas à votre cône client configuré en amont. Deuxièmement, un AS_PATH valide peut devenir invalide si l'itinéraire créé est annoncé dans les mauvaises directions et viole ainsi la politique de routage. Et le dernier - tout itinéraire avec un préfixe qui viole la longueur du ROA peut être considéré comme invalide.
Incident
Il y a quelques semaines, nous avons reçu une plainte d'un des utilisateurs. Nous avons vu des itinéraires avec ses préfixes ASN et / 25 d'origine, tandis que l'utilisateur a affirmé qu'il ne les avait pas annoncés.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||Exemples d'annonces début avril 2019NTT en transit pour le préfixe / 25 le rend particulièrement suspect. Lors de l'incident, le LG NTT ne savait rien de cette route. Alors oui, une sorte d'opérateur crée un AS_PATH entier pour ces préfixes! Les tests sur d'autres routeurs vous permettent de mettre en évidence un ASN spécial: AS263444. En regardant d'autres itinéraires avec ce système autonome, nous avons été confrontés à la situation suivante:
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||Essayez de deviner ce qui ne va pas iciIl semble que quelqu'un a pris le préfixe de l'itinéraire, l'a divisé en deux parties et a annoncé l'itinéraire avec le même AS_PATH pour ces deux préfixes.
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||Exemples de routes pour l'une des paires de préfixes fractionnésPlusieurs questions se posent à la fois. Quelqu'un a-t-il vraiment essayé ce type d'interception dans la pratique? Quelqu'un a-t-il emprunté ces routes? Quels préfixes ont été affectés?
C'est là que commence notre série d'échecs et une nouvelle vague de déceptions sur la santé actuelle d'Internet.
Le chemin de l'échec
Tout d'abord. Comment déterminer quels routeurs ont accepté de telles routes interceptées et dont le trafic peut être redirigé aujourd'hui? Nous avons pensé commencer par les préfixes / 25, car ils "ne peuvent tout simplement pas avoir une distribution globale". Comme vous pouvez le deviner, nous nous sommes vraiment trompés. Cette métrique était trop bruyante et les routes avec de tels préfixes peuvent apparaître même auprès des opérateurs de niveau 1. Par exemple, NTT a environ 50 de ces préfixes qu'il distribue à ses propres clients. D'un autre côté, cette métrique est mauvaise car de tels préfixes peuvent être filtrés si l'opérateur applique le
filtrage des petits préfixes dans toutes les directions. Par conséquent, cette méthode ne convient pas pour rechercher tous les opérateurs dont le trafic a été redirigé à la suite d'un tel incident.
Une autre bonne idée que nous pensions était de regarder
POV . Surtout sur les routes qui violent la règle maxLength du ROA correspondant. Ainsi, nous avons pu trouver le nombre d'ASN d'origine différente avec un statut invalide qui étaient visibles pour cet AS. Cependant, il existe un «petit» problème. La valeur moyenne (médiane et mode) de ce nombre (le nombre d'ASN d'origine différente) est d'environ 150 et même si nous filtrons les petits préfixes, il restera supérieur à 70. Cette situation a une explication très simple: il n'y a que quelques opérateurs qui utilisent déjà le ROA- filtres avec la politique de «réinitialisation des itinéraires non valides» aux points d'entrée, donc partout où un itinéraire avec une violation de ROA apparaît dans le monde réel, il peut se propager dans toutes les directions.
Les deux dernières approches nous permettent de retrouver les opérateurs qui ont vu notre incident (car il était assez important), mais en général elles ne sont pas applicables. D'accord, mais pouvons-nous trouver l'attaquant? Quelles sont les caractéristiques communes d'une telle manipulation AS_PATH? Il existe plusieurs hypothèses de base:
- Le préfixe n'a été vu nulle part auparavant;
- L'ASN d'origine (rappel: premier ASN dans AS_PATH) est valide;
- Le dernier ASN dans AS_PATH est l'ASN de l'attaquant (si son voisin vérifie l'ASN du voisin sur toutes les routes entrantes);
- L'attaque provient d'un fournisseur.
Si toutes les hypothèses sont correctes, alors sur toutes les routes incorrectes, l'ASN de l'attaquant sera présenté (à l'exception de l'origine de l'ASN) et, donc, c'est un point «critique». Parmi les vrais pirates de l'air se trouvait AS263444, bien qu'il y en ait eu d'autres. Même lorsque nous avons abandonné les routes de l'incident. Pourquoi? Un point critique peut rester critique même pour des itinéraires corrects. Cela peut être soit le résultat d'une mauvaise connectivité dans n'importe quelle région, soit les limites de notre propre visibilité.
En conséquence: il existe un moyen de détecter un attaquant, mais uniquement si toutes les conditions ci-dessus sont remplies et uniquement lorsque l'interception est suffisamment importante pour franchir les seuils de surveillance. Si l'un de ces facteurs n'est pas respecté, peut-on distinguer les préfixes affectés par une telle interception? Pour certains opérateurs, oui.
Lorsqu'un attaquant crée une route plus spécifique, un tel préfixe n'est pas annoncé par le véritable propriétaire. Si vous disposez d'une liste dynamique de tous ses préfixes, vous pouvez effectuer une comparaison et trouver des itinéraires plus spécifiques déformés. Nous collectons cette liste de préfixes à l'aide de nos sessions BGP, car on nous donne non seulement une liste complète des routes visibles par l'opérateur en ce moment, mais aussi une liste de tous les préfixes qu'il veut annoncer au monde. Malheureusement, il y a maintenant plusieurs dizaines d'utilisateurs de Radar qui ne terminent pas correctement la dernière partie. Dans un proche avenir, nous les informerons et tenterons de résoudre ce problème. Tout le monde peut rejoindre notre système de surveillance dès maintenant.
Si nous revenons à l'incident d'origine, l'attaquant et la zone de distribution ont été découverts par nos soins en recherchant des points critiques. Étonnamment, AS263444 n'a pas envoyé d'itinéraires fabriqués à tous ses clients. Bien qu'il y ait un moment plus étrange.
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||Un exemple récent d'une tentative d'intercepter notre espace d'adressageLorsque plus spécifiques pour nos préfixes ont été créés, l'AS_PATH spécialement créé a été utilisé. Cependant, cet AS_PATH n'a pu être emprunté à aucune de nos routes précédentes. Nous n'avons même pas de connexion avec AS6762. Nous examinons d'autres itinéraires dans l'incident: certains d'entre eux avaient un vrai AS_PATH, qui a été utilisé plus tôt, tandis que d'autres n'en avaient pas, même s'ils avaient l'air réels. Un changement supplémentaire à AS_PATH n'a aucun sens pratique, car dans tous les cas le trafic sera redirigé vers l'attaquant, mais les routes avec un "mauvais" AS_PATH peuvent être filtrées par ASPA ou tout autre mécanisme de vérification. Ici, nous avons réfléchi à la motivation du pirate de l'air. Maintenant, nous n'avons pas suffisamment de données pour affirmer que cet incident était une attaque planifiée. Néanmoins, c'est possible. Essayons d'imaginer une situation hypothétique, mais potentiellement bien réelle.
Attaque parfaite
Qu'avons-nous? Supposons que vous êtes un fournisseur de transport en commun qui diffuse des itinéraires pour vos clients. Si vos clients ont une présence multiple (multihome), vous ne recevrez qu'une partie de leur trafic. Mais plus il y a de trafic, plus vos revenus sont importants. Par conséquent, si vous commencez à annoncer des préfixes de sous-réseau des mêmes routes avec le même AS_PATH, vous recevrez le reste de leur trafic. En conséquence, le reste de l'argent.
Le ROA va-t-il aider ici? Peut-être que oui, si vous décidez d'abandonner complètement l'utilisation de
maxLength . De plus, il est hautement indésirable d'avoir des entrées ROA avec des préfixes qui se croisent. Pour certains opérateurs, de telles restrictions sont inacceptables.
Compte tenu des autres mécanismes de sécurité de routage, ASPA n'aidera pas dans ce cas non plus (car AS_PATH est utilisé à partir d'une route valide). BGPSec n'est toujours pas la meilleure option en raison du faible taux d'acceptation et de la possibilité restante d'attaques de déclassement.
Ainsi, nous avons un bénéfice net pour l'attaquant et un manque de sécurité. Super mélange!
Que dois-je faire?
L'étape la plus évidente et la plus radicale consiste à revoir votre politique de routage actuelle. Divisez votre espace d'adressage en petits morceaux (sans intersections) que vous souhaitez uniquement annoncer. Signez les ROA uniquement pour eux, sans utiliser le paramètre maxLength. Dans ce cas, le PDV actuel peut vous sauver d'une telle attaque. Cependant, encore une fois, pour certains opérateurs, cette approche n'est pas raisonnable en raison de l'utilisation exclusive d'itinéraires plus spécifiques. Tous les problèmes de l'état actuel du ROA et des objets de route seront décrits dans l'un de nos futurs matériaux.
De plus, vous pouvez essayer de surveiller ces interceptions. Pour ce faire, nous avons besoin d'informations fiables sur vos préfixes. Ainsi, si vous établissez une session BGP avec notre collecteur et nous donnez des informations sur votre visibilité sur Internet, nous pouvons également trouver la zone de distribution pour d'autres incidents. Pour ceux qui ne sont pas encore connectés à notre système de surveillance - pour commencer, une liste de routes avec uniquement vos préfixes nous suffira. Si vous avez une session avec nous, veuillez vérifier que tous vos itinéraires ont bien été envoyés. Malheureusement, cela mérite d'être rappelé, car certains opérateurs oublient un ou deux préfixes et interfèrent ainsi avec nos méthodes de recherche. Si tout est fait correctement, nous disposerons de données fiables sur vos préfixes, ce qui à l'avenir permettra de détecter et de détecter automatiquement ces types (et d'autres) d'interception de trafic pour votre espace d'adressage.
Si vous découvrez en temps réel une telle interception de votre trafic, vous pouvez essayer de la contrer vous-même. La première approche consiste à annoncer vous-même des itinéraires avec ces préfixes plus spécifiques. En cas de nouvelle attaque sur ces préfixes - répétez.
La deuxième approche consiste à punir l'attaquant et ceux pour lesquels il est un point critique (pour les bons itinéraires) en coupant l'accès de vos itinéraires à l'attaquant. Cela peut être fait en ajoutant l'ASN de l'attaquant à l'AS_PATH de vos anciennes routes et en les faisant ainsi éviter cet AS en utilisant le mécanisme de détection de boucle intégré dans BGP
pour leur propre avantage .