Décryptage d’une fuite de routes BGP (Route leak)
Publié le 14 Juin 2019
Le 6 Juin dernier, plusieurs opérateurs européens voyaient une partie de leur trafic impacté pendant plusieurs heures en raison d’une fuite de leurs routes. Devenus des incidents réseau communs, les route leaks illustrent bien les failles de l’Internet. Comment les opérateurs peuvent-ils réduire la récurrence et l’impact de ces incidents?
Internet repose sur un maillage de réseaux dits autonomes (AS) à l’échelle mondiale. Chaque AS annonce son trafic au travers du protocole de routage BGP vers l’ensemble des autres AS. Ceux-ci acceptent l’annonce et la retransmettent à leur tour.
A l’heure où le nombre de réseaux ainsi que le nombre de routes ne cessent d’augmenter (presque 800 000 routes à ce jour), ce modèle d’interdépendance apporte son lot de vulnérabilités mais aussi d’attaques malveillantes. Par mégarde, un AS peut provoquer une redirection illégitime du trafic d’un autre AS. Cela entraîne une dégradation, voire une interruption des services du réseau propriétaire de ces routes.
Il peut également s’agir d’un acte volontaire comme dans le cas d’une usurpation de routes (BGP hijack). Cette pratique consiste à rediriger les données d’une entreprise dans le but d’en connaître le contenu ou encore d’interrompre temporairement le(s) service(s) de l’entreprise en question.
Ces incidents sont devenus des événements répétitifs pouvant toucher n’importe quelle entité faisant du routage BGP: fournisseurs de services Internet aussi appelé eyeballs dans la terminologie du peering, les fournisseurs de transit (tier-1, tier-2, tier-3), les fournisseurs de contenu (Google, Facebook, Microsoft, AWS, etc…) et également les entreprises.
Nous vous présentons ci-dessous les principes de fonctionnement de ces fuites de routes ainsi que leurs impacts au niveau de la sécurité et de la qualité de service.Notre exemple s’inspire de l’événement survenu la semaine dernière mais reste à but pédagogique et ne vise en aucun cas à définir des responsables.
Tout d’abord, voyons comment est structuré le routage du réseau Internet et les différents types d’acteurs d’un point de vue des relations de voisinage réseau (BGP peering):
Le réseau de routage de l’Internet est structuré, aussi bien d’un point de vue technique que commercial, autour de trois types d’acteurs. Tout d’abord, les acteurs de l’accès au service Internet aussi appelé Eyeball (terminologie venant du monde des TV broadcasters, ce sont les opérateurs qui connectent les utilisateurs du réseau), les acteurs du contenu aussi appelés “content providers” (les célèbres GAFAM faisant partie de cette catégorie) et enfin les transitaires permettant, schématiquement, aux deux acteurs précédemment cités d’échanger du trafic. Il existe une hiérarchie entre les transitaires: TIER 1, 2 et 3. Le TIER 1 est le plus gros de ces trois types de transitaire et il se définit comme étant autosuffisant pour accéder à toutes les routes de l’Internet. Il n’achète de transit à personne.
Ce modèle historique de l’Internet a été sérieusement mis à mal ces dernières années par l’extension des réseaux des acteurs du contenu mais cela est un autre sujet plus commercial et stratégique que nous n’abordons pas ici.
Il ressort de ce découpage des relations de voisinage au sens du routage BGP de l’Internet : relations peer to peer, customer to provider, provider to provider. Ces relations sont définies par des règles techniques et des accords commerciaux. Chaque type de relation impose une ingénierie de routage particulière. Cette ingénierie est directement liée à la configuration des équipements routeurs de l’acteur en question. Ces règles sont dépendantes des équipes qui les configurent et peuvent faire l’objet d’erreurs majoritairement involontaires.
Afin de raccorder son réseau à l’Internet, il est nécessaire de se connecter aux acteurs du transit. Dans ce type de relation, le transitaire annonce toutes les routes de l’Internet et le réseau client du transitaire ne doit annoncer que ses propres routes (soit ses propres blocs d’adresses IP).
Dans une version simplifiée, les échanges de routes entre les protagonistes ressemblent à ce schéma :
Le trafic s’écoule dans l’Internet conformément aux accords de peering et de transit entre les différentes parties prenantes.
Qu’a-t-il pu se passer lors de la fuite de routes du 6 Juin? Il est fort probable qu’une erreur de configuration ou un bug logiciel se soit glissé dans les annonces réseau d’un acteur du contenu. Dans notre schéma l’entreprise nommée ENT1. Celui-ci s’est mis à annoncer au réseau d’un TIER 2 des routes qu’il avait apprises d’autres transitaires. ENT1 a ainsi annoncé un certain nombre de routes appartenant aux réseaux de EBALL1 et de CTNT1 à un transitaire TIER2 devenant ainsi un transitaire pour ces routes.
Annoncer les routes d’un autre réseau que le sien va à l’encontre des règles de routage, à l’exception des fournisseurs de transit IP. Ces derniers ont la capacité d’annoncer la table complète des destinations de l’Internet.
Le Tier 2, à réception de ces routes, les a acceptées dans son réseau puis les a propagées vers les autres réseaux avec lesquels il échange du trafic. Ces routes se sont donc propagées vers d’autres acteurs clés de l’Internet : les Tier 1. Il s’agit d’une autre erreur de routage, cette fois-ci dans le réseau du Tier 2. Par la suite, ces routes ont visiblement fini par être propagées par des fournisseurs de la plus haute hiérarchie des transitaires, les Tier 1.
La propagation d’une fuite de routage est donc l’aboutissement d’un enchaînement d’erreurs de configuration et d’un manque de vérification de la part de plusieurs réseaux.
Illustration de l’impact sur le routage du trafic:
Dans le pire des cas, ce phénomène peut engendrer un perte importante de trafic et dans tous les cas, le trafic ainsi détourné subira un latence supérieure à la normale. Dans le cas du route leak du 6 juin, le pire a été évité grâce à la pertinence de la configuration du routage des opérateurs concernés.
Ce type de phénomène réseau peut aussi faire l’objet d’acte volontaire afin de détourner le trafic vers des équipements d’analyse et produire ainsi une attaque de type MiM (Man In the Middle). Ce fut le cas chez Amazon comme précisé dans ce blog post : http://pragma-security.com/index.php/2018/04/25/arnaques-crimes-bgp/.
Ce type “d’erreurs volontaires” se produisent essentiellement lorsque le trafic représente une valeur marchande. Il peut aussi exister une simple volonté de nuire. Ces phénomènes font donc partie des problématiques de déni de service et il fait sens de mener des actions de prévention pour y remédier.
Pour faire face aux vulnérabilités BGP, la communauté internationale des opérateurs travaille à l’adoption de mesures de sécurité spécifiques. Par exemple, la mise en place de certificats pour valider l’origine des routes (ROA RPKI) ou encore des initiatives pour étendre cette approche RPKI aux AS_PATH (chemin entre opérateurs) via l’utilisation d’une base partagée : Autonomous System Provider Authorization (ASPA) comme décrit dans ce document https://radar.qrator.net/blog/eliminating-traffic-hijacking_36.
Dans l’immédiat, s’appuyer sur des outils de monitoring devient une nécessité pour les opérateurs et entreprises faisant du routage BGP sur Internet. Lors d’un incident, l’entreprise concernée est alertée et peut agir au plus tôt pour résoudre ou limiter l’impact sur ses services. Dans un deuxième temps, le monitoring permet de produire une analyse post mortem de l’incident et de mettre en place les améliorations de processus de résolution.
Utilisé par de nombreuses entreprises françaises, l’outil Radar offre une supervision permanente des communications BGP et détecte tous types d’anomalies (connectivité, Route Leak, Hijack, Bogon prefix, etc…. ) grâce à son analyse des routes empruntées pour chaque AS ainsi que le modèle relationnel entre AS. En souscrivant au service, toute entreprise peut dès lors recevoir des alertes lorsque son réseau est affecté et mettre en action les recommandations prescrites.
Exemple d’alerte en cas de fuite de routes:
