Turb(l)o(g)

Un récent commentaire m’amène fatalement à vous parler de la sécurité à propos de BGP. (la jolie illustration à droite, c’est un routeur Cisco, les trous noirs rectangulaires partout étant des emplacements prévus pour recevoir les petits modules laser qui servent à émettre et recevoir sur des fibres optiques)

Ce merveilleux protocole qui est à la base de toute communication sur internet souffre principalement de deux défauts dont un a été corrigé à grande échelle il y a quelques années et l’autre est toujours en activité mais n’est heureusement exploitable que par un nombre assez restreint de personnes.

Nous allons rapidement passer sur le premier qui n’est en réalité pas spécifiquement lié à BGP mais au protocole TCP qui le transporte et qui peut, dans certains cas, être victime d’attaques avec de faux paquets qui vont faire redémarrer la connexion TCP. Rien de bien affolant quand la connexion en question est celle d’un navigateur web avec votre blog favori, mais si une session BGP saute, le trafic ne passe plus, tendance, pendant quelques secondes/minute (selon le routeur concerné) il se perd ou tourne en rond.

Les effets de l’attaque ne sont que passagers (la session BGP se rétabli aussitôt), mais cette menace a été suffisante pour qu’en 2004 une bonne partie des sessions BGP importantes du réseau soient passés sous signature MD5 pour éviter ce genre d’injection de paquets désobligeants. C’est à cette occasion que de nombreux outils statistiques à propos de BGP ont cessé de fonctionner, les mouvements d’annonces sur le réseau ayant été, pendant quelques jours, sans commune mesure avec le trafic habituel, puisque pour activer le MD5 checksum TCP sur une session BGP, il faut la redémarrer. Pour plus d’infos techniques sur BGP & MD5, ça se passe par la.

La deuxième faiblesse de BGP réside, comme souvent, entre la chaise et le clavier (it’s not a bug, it’s a feature) … Beaucoup de gens se souviennent encore très bien de l’épisode Pakistan Telecom v.s. Youtube d’il y a deux ans ou, pendant quelques heures, Youtube était, pour toute la planète, une pauvre machine perdue au fin fond du Pakistan. Si c’est le cas le plus médiatique qu’on puisse trouver, le tipiakage d’adresse IP n’est pas si rare. Pas plus tard qu’hier, le préfixe contenant le fameux DNS public de Google, 8.8.8.8, a été détourné entre 22h53 UTC et 23h01 UTC par Evolva Telecom, un fournisseur d’accès Roumain, sans pour autant que cela ne détourne tout le trafic mondial à destination de ce bloc d’adresse ni que ça ne fasse la une de la presse people online.

Mais comment se fait-ce, vous demandez vous ?

Intéressons nous d’abord à la méthode employée. Je vous invite à (re) lire l’article sur comment trouver la bonne route avant de continuer. Pour reprendre l’analogie utilisée dans cet article, le routage sur internet peut être assimilé à une collection de panneaux indicateurs qui tourneraient en permanence partout en fonction des routes utilisables ou pas. Ces panneaux indiqueraient des endroits de taille variable. Par exemple un petit village ou Paris tout entier, mais aussi, pourquoi pas, une seule et unique rue de Paris qui serait fléchée depuis l’autre bout du monde.

C’est cette petit rue de Paris fléchée depuis l’autre bout du monde qui pose problème, puisqu’à Castelmoron, si vous indiquez une direction pour cette petite rue de Paris, la totalité des gens qui ont prévu de s’y rendre suivront aveuglément cette direction, même si elle aboutit dans l’abri de jardin derrière chez vous, et même s’il y a juste au dessus de votre faux panneau indicateur un vrai panneau marqué « Paris ».

Techniquement, imaginez que vous avez une route sur internet qui décrit un bloc de 4096 adresses (une puissance de 2, vous l’aurez remarqué, puisque les blocs d’adresses annoncés sur internet le sont généralement par blocs indivisibles de 256 adresses). Vous allez donc annoncer quelque chose qui ressemble à 192.168.0.0/20. Les règles de base du routage IP veulent que la route la plus précise prime systématiquement, de sorte que si quelqu’un d’autre annonce 192.168.0.0/24, soit les premières 256 adresses de votre bloc d’IP, la totalité du trafic de tout internet à destination de ces 256 adresses ira chez l’opérateur qui annonce la route la plus précise (vous aurez les 3840 autres adresses dont le trafic ira toujours chez vous).

C’est ce qui s’était passé chez Pakistan Telecom qui avait involontairement (ou pas) détourné l’ensemble du trafic de Youtube.

Le cas d’hier en Roumanie est un peu plus diffus dans l’interception du trafic puisque l’opérateur Evolva avait annoncé strictement la même route que Google. Que se passe-t-il dans ce cas précis ? Eh bien les routeurs pour qui il semble plus court d’aller chez Evolva que chez Google choisissent la route qui va chez Evolva, les autres, eux, continuent d’aller chez Google, ce qui nous donne un impact moins important sur le réseau global.

Comment se protéger de ce genre de chose dans l’état actuel de l’usage de BGP sur le réseau ? eh bien on ne peut pas vraiment. Pour éviter de propager de fausses informations, il faut drastiquement filtrer les routes qu’on apprend de l’extérieur et qu’on renvoie ailleurs (typiquement, ses propres clients), ça, c’est pour protéger les autres de ses propres bêtises ou de celles des gens dont on est responsable.

Quand à se protéger de quelqu’un qui annoncerait indument un bloc à soi, c’est impossible, la seule chose faisable est de surveiller l’état global du réseau pour détecter un changement qui affecterait l’un de ses bloc d’IP (par exemple avec RIS qui propose un outil plutôt bien fait)

Et enfin, pour éviter que son trafic ne suive une mauvaise route qui tomberait là par hasard, il n’y a pas vraiment de moyen actuellement utilisable, si ce n’est de compter sur le sérieux des autres membres de la communauté.