Éliminer les opportunités de détournement de trafic

^{Beau schéma pour la connexion BGP au réseau de filtrage Qrator}

Un petit aperçu historique

• Détournements BGP - lorsqu'un FAI crée une annonce d'espace d'adressage qui ne lui appartient pas;
• Fuites de route BGP - lorsqu'un FAI annonce des préfixes reçus d'un fournisseur ou d'un homologue à un autre fournisseur ou homologue.

Cette semaine, 11 ans se sont écoulés depuis l' incident mémorable de BGP sur YouTube , provoqué par la propagation mondiale d'une annonce de préfixe plus spécifique, déclenchée par Pakistan Telecom, conduisant à une interruption de trafic de près de 2 heures sous la forme de rediriger le trafic de légitime chemin vers le faux. Nous pouvions deviner si cet événement était intentionnel, et même une réponse correcte ne nous aiderait pas à empêcher complètement de tels incidents de se produire aujourd'hui. Pendant que vous lisez ceci, une fuite d'itinéraire ou un détournement se propage sur les réseaux. Pourquoi? Parce que BGP n'est pas facile, et configurer une configuration correcte et sécurisée est encore plus difficile (encore).

Au cours de ces onze années, le détournement de BGP est devenu un vecteur d'attaque très dommageable en raison de la mise en place du BGP dans l'architecture d'Internet moderne. Grâce au BGP, les routeurs acquièrent non seulement des informations sur les pairs, et donc toutes les routes Internet - ils sont capables de calculer le meilleur chemin pour le trafic vers sa destination via de nombreux réseaux intermédiaires (transit), chacun représentant un AS individuel. Un seul AS est juste un groupe de réseaux IPv4 et / ou IPv6 fonctionnant sous une seule politique de routage externe.

Et grâce à BGP dans son état actuel, les attaquants sont capables de conduire des volées massives de trafic, détournant efficacement les préfixes du réseau cible, se plaçant au milieu. Et ce n'est que le début - à l'ère des cyber-acteurs parrainés par l'État, il est évident que la clé de voûte du Border Gateway Protocol, qui est la confiance, n'est plus suffisante pour empêcher des épidémies malveillantes d'incidents de routage, délibérés ou non, de se produire . Étant donné que BGP joue un rôle essentiel dans l'existence d'Internet telle que nous la connaissons (c'est le seul protocole de passerelle extérieure pour contrôler le flux de trafic entre différents fournisseurs de services Internet dans le monde entier), depuis une décennie, nous avons vu des tentatives de correction les choses.

Définition du problème

La complexité globale de la gestion d'un AS fonctionnant avec le protocole BGP ne diminue pas avec le temps et les efforts. Les opérateurs des marchés en développement, où les marchés des FAI et des opérateurs se développent chaque année de manière spectaculaire, n'évaluent pas correctement les conséquences possibles d'un SA mal réglé. Aucune mesure de sécurité ne pouvait se défendre contre une telle erreur interne. L'absence d'automatisation au sein du BGP rend impossible pour les nouveaux joueurs, avec moins d'expérience, de gérer correctement l'AS en situation de stress élevé, comme après la création de fuite de route ou sous le détournement.

Malheureusement, en raison de la place dans la vie humaine qu'Internet occupait, il est difficile pour de nombreux opérateurs AS de suivre le nombre croissant. Exemple simple: en 1997, le nombre de systèmes autonomes était de 3000, en 2005 - 17000, au début de 2019 - 63678. Les tables de routage (qui sont stockées dans les routeurs BGP) sont passées de 50 000 entrées en 1997 et 180 000 en 2005 à étonnantes 850 000. début 2019.

Les fuites de route et les détournements ont des effets similaires sur les opérations du FAI - ils redirigent le trafic, entraînant une latence accrue, une perte de paquets ou des attaques MITM possibles. Cependant, le niveau de risque dépend de manière significative de la propagation de ces anomalies BGP. Par exemple, un détournement qui est propagé uniquement aux clients peut concentrer le trafic du cône client d'un FAI particulier. Si l'anomalie se propage par des pairs, en amont ou atteint des réseaux de niveau 1, se répartissant ainsi à l'échelle mondiale, le trafic peut être redirigé au niveau de pays entiers et / ou de fournisseurs mondiaux. La capacité de limiter la propagation des anomalies BGP aux amonts et aux homologues, sans nécessiter la prise en charge de la source de l'anomalie (ce qui est essentiel si une source a une intention malveillante), devrait améliorer considérablement la sécurité du routage inter-domaines et résoudre la majorité des problèmes. .

En jetant simplement un coup d'œil rapide sur les événements cités par Wikipédia liés au «détournement de BGP», nous constatons une augmentation de leur fréquence au cours des deux dernières années. Pourquoi? Parce qu'il existe de nombreuses façons d'organiser une attaque contre le BGP et trop peu de chances de se déconnecter. Pourtant, ces entreprises bien connues comme mauvais acteurs perdent finalement leurs connexions en amont, car cela nuit à leur réputation. Et pourtant, de tels incidents se produisent car il n'y a (encore) aucun moyen d'empêcher une fuite de route ou un détournement de préfixe avec une précision de 100%.

Des centaines d'incidents de routage se produisent quotidiennement, la majorité étant le résultat d'une simple mauvaise configuration. Ces détournements vraiment dangereux et malveillants sont généralement trompeurs et ciblés avec précision, ce qui les rend plus difficiles à trouver et à corriger. Et seul un petit pourcentage d'entre eux a bénéficié d'une couverture médiatique car, en raison de la nature du BGP, chaque incident doit se propager à un niveau plus important (au niveau national) pour être remarqué - et les entreprises qui surveillent leurs réseaux pourraient arrêter une telle propagation.

Étant donné que le concept de détournement BGP tourne autour de la localisation d'un FAI qui ne filtre pas les annonces BGP (et il existe de nombreux fournisseurs de ce type), il y a toujours un suspect. Pour chaque incident BGP au cours des deux dernières années, il y avait un ou plusieurs AS spécifiques responsables.

Vous devriez penser qu'en raison d'un énorme potentiel de dommages collatéraux à une partie si vitale de la vie moderne, les entreprises devraient être effrayées à mort et prendre toutes les mesures possibles pour empêcher de tels événements en premier lieu. Eh bien, cela semble trop beau pour être vrai IRL.

Fin 2018, 7% des FAI de transit en IPv4 et 1% des FAI de transit dans le monde du routage IPv6 ont accepté des fuites en dehors de leur cône client. Vous pouvez dire que les chiffres ne sont pas si élevés, mais regardons de plus près les résultats triés par la «taille» du FAI:



Sans surprise, tous les Tier-1 sont concernés, avec plus de 50% des 400 meilleurs FAI IPv4. IPv6 semble un peu plus sain, n'oublions pas qu'il a moins de préfixes et prend en charge les FAI. Le problème existe donc et n'est pas réglé de manière suffisamment efficace - nous allons essayer d'expliquer pourquoi.

Tente d'appliquer un patch

En fait, il y a eu un effort important pour améliorer la sécurité BGP. Actuellement, la technique la plus courante consiste à utiliser des filtres d'entrée (entrants), basés sur les données des registres de routage Internet . L'idée est simple: utiliser des objets de route et des AS-SET «approuvés» pour créer des filtres sur les liens clients. Un problème sous-jacent est que les AS-SET et les objets route varient d'un IRR à l'autre, et parfois des objets différents peuvent exister avec le même identifiant dans des IRR séparés. Et, bien sûr, les politiques IRR ne sont pas obligatoires - elles sont volontaires à mettre en œuvre, ce qui nous conduit à une situation où beaucoup d'IPv4 et IPv6 n'ont pas d'objets enregistrés ou les ont incorrects. Outre ces mauvais. Ainsi, de nombreux objets IRR sont mal entretenus, et même certains énormes réseaux de niveau 2 ne parviennent pas à configurer correctement leurs filtres.


^{Hiérarchie des certificats de ressources RPKI}

Il existe une autre option intéressante pour filtrer les annonces incorrectes: la validation de l'origine basée sur le ROA peut être utilisée pour détecter et filtrer les erreurs d'origine accidentelles. Bien que ces mises à niveau BGP soient très utiles, elles reposent toujours sur des attributs BGP transitifs - AS_Path, que l'attaquant peut et va manipuler.

RPKI (ROA Foundation) est basé sur une hiérarchie de certificats de ressources, alignée sur la structure d'allocation de ressources de numéros Internet. Le certificat de ressource est lié, par exemple, à l'enregistrement RIPE NCC . Cela est dû au fait que tant que quelqu'un est membre du RIPE NCC et a une relation contractuelle avec le RIPE NCC, il peut être déclaré avec autorité qui est le titulaire d'une ressource de numéro Internet individuel. Le certificat a une validité de 18 mois, mais il est automatiquement renouvelé tous les 12 mois. RPKI est structuré de manière à ce que chaque certificat de ressource actuel corresponde à une allocation ou une affectation de ressource actuelle - un moment crucial pour ASPA également.

Il convient de noter que 2018 a été une année essentielle pour la sécurité BGP avec de nombreux événements remarquables. BGPSec est enfin une norme, bien que personne ne s'attende à ce qu'il soit entièrement mis en œuvre en raison de ses exigences de support complexes. À un taux d'adoption de 100%, BGPSec résout les détournements malveillants avec une très haute précision, mais les coûts de calcul d'une validation cryptographique AS_Path stricte sont insupportables pour la plupart des joueurs, à l'exception peut-être des opérateurs AS les plus riches du monde. Et, encore une fois - pour fonctionner correctement, BGPSec doit être implémenté sur chaque réseau qui gère sa propre route.

Tous les événements récents montrent clairement que le génie de la manipulation BGP est sorti de la bouteille, réalisant les souhaits de quelqu'un. Nous ne pouvons pas attendre une autre décennie pour arriver à une conclusion que nous avions il y a 10 ans - cela devrait être arrêté maintenant, en fournissant des mesures techniques efficaces pour la validation des préfixes, à la fois en entrée et en sortie.

Approche ASPA

Auparavant, notre société ciblait les améliorations de protocole sur la diminution des erreurs et des erreurs, et en 2018, nous nous sommes concentrés sur la lutte contre les activités malveillantes - en particulier les détournements de BGP. Ce vecteur est puissant comme nous l'avons déjà vu à plusieurs reprises, et les attaquants n'hésitent pas à l'utiliser pour tenter de perturber le service ou de voler des données utilisateur. Le principal problème est qu'à l'exception de la surveillance, rien n'empêche actuellement les détournements de chemin dans le protocole lui-même. Comme nous l'avons déjà indiqué, BGPSec ne changera rien tant qu'il ne sera pas implémenté sur les fournisseurs de réseaux les plus importants (ou, reformulé, sur la majorité des réseaux), ce qui aurait déjà pu se produire si le protocole était approprié.

Notre réponse est l'approche pirate - ASPA, où les outils actuels sont utilisés pour lutter contre les problèmes les plus graves dans le monde du routage BGP. La mise en œuvre est facile, bien que la solution résultante réponde à presque toutes les menaces associées. Le fait qu'il n'est pas nécessaire d'attendre l'adoption intégrale de la ZSPA est la principale raison à l'appui de notre approche. En 2018, nous avons vu des fuites de routes importantes, des détournements graves et de nombreux autres événements impliquant BGP, ce qui est la principale raison pour laquelle nous devons trouver quelque chose qui fonctionne dans les mois les plus proches, sans attendre 10 ans pour la mise en œuvre de BGPSec.

L'amélioration Autonomous System Path Authorization du protocole BGP sur lequel nos ingénieurs travaillent, en collaboration avec d'autres, pourrait efficacement et, plus important encore, résoudre rapidement le problème mondial des détournements d'avion. ASPA se concentre sur l'automatisation de la détection et de la prévention des détournements malveillants (en association avec le ROA) et des fuites de route.

Pour atteindre cet objectif spécifique, une nouvelle procédure de vérification AS_PATH est définie, qui permet de détecter automatiquement les AS_PATH malformés dans les annonces reçues des clients et des pairs. La procédure elle-même utilise une base de données partagée et signée des relations client-fournisseur (C2P), en cours de création avec un nouvel objet RPKI - Autonomous System Provider Authorization (ASPA). Il est léger et rapide à déployer, détectant les AS_PATH non valides juste après l'implémentation.

Les ASPA sont des objets signés numériquement qui attestent qu'un titulaire AS client (CAS) a autorisé un fournisseur AS particulier (PAS) à propager les annonces de routage BGv IPv4 ou IPv6 du client en avant - vers les amonts ou les pairs du fournisseur. Pour approfondir les détails, vous devriez jeter un œil au profil d'enregistrement ASPA.

Donc, si une route valide est reçue d'un client ou d'un homologue, elle NE DOIT avoir que des paires C2P dans son AS_PATH. Après, si nous avons une base de données validée de paires client-fournisseur, nous sommes en mesure de vérifier les itinéraires reçus des clients et des pairs! Bien sûr, ce n'est pas une solution miracle - c'est seulement un outil utile pour arrêter la propagation d'une anomalie plus près de son origine.



Ce schéma simple montre comment fonctionne une telle vérification basée sur ASPA. Les AS verts représentent les paires signées et le rouge représente l'attaquant. Dans cet exemple, AS1 a un objet RPKI ROA en place.

AS_PATH: AS4
Le coin 1 montre que si l'AS le plus proche dans l'AS_PATH n'est pas l'ASN voisin du récepteur, la procédure s'arrête avec le résultat «invalide». De plus, si dans l'un des segments AS_SEQ il y a une paire «invalide», la procédure s'arrête également avec le résultat «invalide»;

AS_PATH: AS4 AS1
Le coin 2 montre que la même chose se produit si l'attaquant tentait de créer une nouvelle paire non validée, le résultat serait également «invalide»;

AS_PATH: AS4 AS2 AS1
Le coin 3 illustre que toute tentative d'annoncer une paire non validée résulterait en un itinéraire «invalide» et donc abandonné.

AS_PATH: AS2 AS1
Dans le dernier Corner 4 , nous revenons à la condition initiale dans laquelle si l'AS le plus proche dans l'AS_PATH n'est pas l'ASN voisin du récepteur, alors cette procédure est conservée comme «invalide».

Des détails détaillés sur la procédure de vérification AS_PATH peuvent être trouvés dans le projet IETF correspondant. Cela peut sembler un peu compliqué, mais il est léger, fonctionne sur l'infrastructure RPKI existante et donne effet à l'état d'une adoption partielle, rentable. En d'autres termes, cela pourrait fonctionner maintenant, nous aidant à mettre les fuites de route BGP et les détournements au bord de l'extinction!

Pourquoi vous devriez nous soutenir dans l'amélioration de la sécurité BGP

Comment savons-nous d'abord que le RPKI ROA convient à ce rôle? Examinons de plus près les statistiques actuelles sur son adoption.

Dans l'IPv4 pour les préfixes 938526, 95272 ont des entrées RPKI ROA valides ou ~ 10%. Dans le monde IPv6 pour les préfixes 80480, 10593 ont des entrées RPKI ROA valides ou ~ 12%

Ces chiffres ne sont pas aussi élevés que nous le souhaiterions, mais ils grandissent chaque jour! Le nombre de ROA validés n'étant pas très important, il est évident que seuls les plus responsables les entretiennent quotidiennement. Et bien que nous ne fassions pas entièrement confiance aux données IRR, la signature de l'annonce BGP avec ROA est déjà utile et en place. Il y a des progrès parmi les opérateurs Internet Exchange, ainsi que les plus grands fournisseurs de services Internet dans le monde entier. Et en ce qui concerne les «utilisateurs Internet ordinaires» - votre propre FAI pourrait être le prochain s'il est suffisamment motivé pour assurer la sécurité de vos données.

Si vous êtes aussi intéressé par l'élimination des opportunités de détournement de trafic que nous le sommes, signez des accords de retour sur investissement et soutenez l'adoption des ASPA sur la liste de diffusion de l'IETF, comme nous l'espérons dans sa transition vers l'étape RFC dans un avenir observable!