13 mars au groupe de travail anti-abus RIPE considérez le détournement BGP (hjjack) comme une violation de la politique RIPE. Si la proposition était acceptée, le fournisseur Internet attaqué par l'interception du trafic aurait la possibilité d'envoyer une demande spéciale pour dénoncer l'attaquant. Si l’équipe d’examen collectait suffisamment de preuves à l’appui, le LIR qui était à l’origine de l’interception BGP serait considéré comme un intrus et pourrait être déchu de son statut LIR. Il y avait aussi quelques arguments changements.
Dans cette publication, nous souhaitons montrer un exemple d'attaque dans laquelle non seulement le véritable attaquant était en cause, mais également la liste complète des préfixes concernés. De plus, une telle attaque soulève à nouveau des questions sur les motivations des futures interceptions de ce type de trafic.
Au cours des deux dernières années, seuls les conflits tels que MOAS (Multiple Origin Autonomous System) ont été couverts par la presse en tant qu'interceptions BGP. MOAS est un cas particulier dans lequel deux systèmes autonomes différents annoncent des préfixes en conflit avec les ASN correspondants dans AS_PATH (le premier ASN dans AS_PATH, ci-après appelé ASN d'origine). Cependant, on peut citer au moins l'interception du trafic, permettant à un attaquant de manipuler l'attribut AS_PATH à diverses fins, notamment en contournant les approches modernes de filtrage et de surveillance. Type d'attaque connu - le dernier type d'interception de ce type, mais sans aucune importance. Il est fort possible que ce soit exactement le genre d’attaques auxquelles nous avons assisté ces dernières semaines. Un tel événement est compréhensible et a des conséquences assez graves.
Ceux qui recherchent la version TL;DR peuvent faire défiler jusqu'au sous-titre « Perfect Attack ».
Contexte du réseau
(pour vous aider à 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 alors la route pour le préfixe ayant la plus longue longueur. S'il existe plusieurs routes différentes pour un même préfixe dans la table de routage, vous choisirez la meilleure (selon le mécanisme de sélection 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 remplacer cet attribut par n'importe quelle valeur pendant la publication. Le simple fait d'ajouter l'ASN du propriétaire au début de AS_PATH (en tant qu'ASN d'origine) peut suffire à contourner les mécanismes actuels de vérification de l'origine. De plus, s'il existe une route depuis l'ASN attaqué vers vous, il devient possible d'extraire et d'utiliser l'AS_PATH de cette route dans vos autres publicités. Tout contrôle de validation AS_PATH uniquement pour vos annonces contrefaites finira par réussir.
Il y a encore quelques limitations qui méritent d'être mentionnées. Premièrement, en cas de filtrage de préfixe par le fournisseur en amont, votre route peut toujours être filtrée (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 la route créée est annoncée dans des directions incorrectes et viole ainsi la politique de routage. Enfin, tout itinéraire dont le préfixe ne respecte pas la longueur du ROA peut être considéré comme invalide.
Incident
Il y a quelques semaines, nous avons reçu une plainte d'un de nos utilisateurs. Nous avons vu des itinéraires avec ses préfixes ASN d'origine et /25, tandis que l'utilisateur a affirmé qu'il n'en avait pas fait la publicité.
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 pour début avril 2019
NTT dans le chemin du préfixe /25 le rend particulièrement suspect. LG NTT ne connaissait pas cet itinéraire au moment de l'incident. Alors oui, certains opérateurs créent un AS_PATH entier pour ces préfixes ! La vérification sur d'autres routeurs révèle un ASN particulier : AS263444. Après avoir regardé d'autres itinéraires avec ce système autonome, nous avons rencontré 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 ici
Il semble que quelqu'un ait pris le préfixe de la route, l'ait divisé en deux parties et ait annoncé la route 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 d'itinéraires pour l'une des paires de préfixes divisées
Plusieurs questions se posent à la fois. Quelqu'un a-t-il réellement essayé ce type d'interception en pratique ? Quelqu'un a-t-il emprunté ces itinéraires ? Quels préfixes ont été concernés ?
C'est là que commence notre série d'échecs et une nouvelle vague de déception face à l'état actuel de la santé d'Internet.
Le chemin de l'échec
Tout d'abord. Comment pouvons-nous déterminer quels routeurs ont accepté de telles routes interceptées et quel trafic pourrait être redirigé aujourd’hui ? Nous avons pensé commencer par les préfixes /25 car ils « ne peuvent tout simplement pas avoir une distribution mondiale ». Comme vous pouvez le deviner, nous avions vraiment tort. Cette métrique s'est avérée trop bruyante et des itinéraires avec de tels préfixes peuvent apparaître même chez les opérateurs de niveau 1. Par exemple, NTT possède environ 50 préfixes de ce type, qu'elle distribue à ses propres clients. D'un autre côté, cette métrique est mauvaise car ces préfixes peuvent être filtrés si l'opérateur utilise , dans tous les sens. Cette méthode n’est donc pas adaptée pour retrouver tous les opérateurs dont le trafic a été redirigé à la suite d’un tel incident.
Une autre bonne idée nous a semblé être de regarder . Surtout pour les routes qui violent la règle maxLength du ROA correspondant. De cette façon, nous pourrions trouver le nombre d’ASN d’origine différente avec le statut Invalide qui étaient visibles par un AS donné. Il y a cependant un « petit » problème. La moyenne (médiane et mode) de ce nombre (le nombre d'ASN d'origine différente) est d'environ 150 et, même si l'on filtre les petits préfixes, il reste supérieur à 70. Cet état de fait a une explication très simple : il n'y a qu'un quelques opérateurs qui utilisent déjà des filtres ROA avec une politique de « réinitialisation des routes invalides » aux points d'entrée, de sorte que partout où une route avec une violation du ROA apparaît dans le monde réel, elle 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'intrus ? Quelles sont les caractéristiques générales de cette manipulation AS_PATH ? Il existe quelques hypothèses de base :
- Le préfixe n’avait é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 (au cas où son voisin vérifierait l'ASN du voisin sur toutes les routes entrantes) ;
- L'attaque provient d'un seul fournisseur.
Si toutes les hypothèses sont correctes, alors toutes les routes incorrectes présenteront l'ASN de l'attaquant (à l'exception de l'ASN d'origine) et il s'agit donc d'un point « critique ». Parmi les véritables pirates de l’air se trouvait AS263444, bien qu’il y en ait d’autres. Même lorsque nous avons écarté les itinéraires des incidents. Pourquoi? Un point critique peut rester critique même pour des itinéraires corrects. Cela peut être le résultat d’une mauvaise connectivité dans une région ou d’une limitation de notre propre visibilité.
Par conséquent, il existe un moyen de détecter un attaquant, mais seulement si toutes les conditions ci-dessus sont remplies et seulement lorsque l’interception est suffisamment importante pour dépasser les seuils de surveillance. Si certains de ces facteurs ne sont pas remplis, pouvons-nous alors identifier les préfixes qui ont souffert d’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, il devient alors possible de faire une comparaison et de trouver des itinéraires déformés plus spécifiques. Nous collectons cette liste de préfixes à l'aide de nos sessions BGP, car nous recevons non seulement la liste complète des routes visibles par l'opérateur à l'heure actuelle, mais également une liste de tous les préfixes qu'il souhaite annoncer au monde. Malheureusement, il y a désormais plusieurs dizaines d'utilisateurs de Radar qui ne complètent pas correctement la dernière partie. Nous les informerons sous peu 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 initial, nous avons détecté l'attaquant ainsi que la zone de distribution en recherchant les points critiques. Étonnamment, AS263444 n’a pas envoyé de routes fabriquées à tous ses clients. Bien qu'il y ait un moment é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 de tentative d'interception de notre espace d'adressage
Lorsque des préfixes plus spécifiques ont été créés pour nos préfixes, un AS_PATH spécialement créé a été utilisé. Cependant, cet AS_PATH n'aurait pu être extrait d'aucune de nos routes précédentes. Nous n'avons même pas de communication avec AS6762. En regardant les autres routes impliquées dans l'incident, certaines d'entre elles avaient un véritable AS_PATH qui était auparavant utilisé, tandis que d'autres ne l'avaient pas, même s'il ressemble au vrai. Changer AS_PATH n'a en outre aucun sens pratique, puisque le trafic sera de toute façon redirigé vers l'attaquant, mais les routes avec un « mauvais » AS_PATH peuvent être filtrées par ASPA ou tout autre mécanisme d'inspection. Nous pensons ici à la motivation du pirate de l’air. Nous ne disposons actuellement pas de suffisamment d’informations pour confirmer que cet incident était une attaque planifiée. Néanmoins, c'est possible. Essayons d'imaginer une situation, bien qu'encore hypothétique, mais potentiellement bien réelle.
Attaque parfaite
Ce que nous avons? Disons que vous êtes un fournisseur de transport en commun diffusant des itinéraires pour vos clients. Si vos clients ont une présence multiple (multihome), alors vous ne recevrez qu'une partie de leur trafic. Mais plus il y a de trafic, plus vos revenus sont élevés. Ainsi, si vous commencez à annoncer les préfixes de sous-réseau de ces mêmes routes avec le même AS_PATH, vous recevrez le reste de leur trafic. Au final le reste de l'argent.
ROA sera-t-il utile ici ? Peut-être oui, si vous décidez d’arrêter complètement de l’utiliser . De plus, il n'est absolument pas souhaitable d'avoir des enregistrements 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 non plus dans ce cas (car il utilise AS_PATH à partir d'une route valide). BGPSec n'est toujours pas une option optimale en raison des faibles taux d'adoption et de la possibilité restante d'attaques par rétrogradation.
Nous avons donc un gain évident pour l’attaquant et un manque de sécurité. Super mélange !
Que devrais-je faire?
L’étape la plus évidente et la plus radicale consiste à revoir votre politique de routage actuelle. Divisez votre espace d'adressage en plus petits morceaux (sans chevauchement) que vous souhaitez annoncer. Signez ROA pour eux uniquement, sans utiliser le paramètre maxLength. Dans ce cas, votre POV actuel peut vous sauver d’une telle attaque. Cependant, là encore, pour certains opérateurs, cette approche n'est pas raisonnable en raison de l'utilisation exclusive de routes plus spécifiques. Tous les problèmes liés à l'état actuel des objets ROA et route seront décrits dans l'un de nos futurs documents.
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 fournissez des informations sur votre visibilité Internet, nous pouvons trouver l'ampleur d'autres incidents. Pour ceux qui ne sont pas encore connectés à notre système de surveillance, pour commencer, une liste d'itinéraires uniquement avec vos préfixes suffira. Si vous avez une session avec nous, veuillez vérifier que tous vos itinéraires ont é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 cela est fait correctement, nous disposerons de données fiables sur vos préfixes, ce qui nous aidera à l'avenir à identifier et à détecter automatiquement ce type (et d'autres) d'interception de trafic pour votre espace d'adressage.
Si vous constatez en temps réel une telle interception de votre trafic, vous pouvez essayer de la contrecarrer vous-même. La première approche consiste à annoncer vous-même les itinéraires comportant 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 qui il constitue 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 forçant ainsi à éviter cet AS en utilisant le mécanisme de détection de boucle intégré dans BGP. .
Source: habr.com