Efficacité des contres-mesures

Différentes technologies et systèmes ont été mis au point pour détecter et prévenir les attaques par détournement BGP. Nous allons à présent évaluer l’efficacité de deux de ces contre-mesures : un système avancé de détection de détournement BGP nommé Argus [157] et le système de sécurisation de BGP appelé RPKI [101,119,120].

Détection des détournements BGP

Au fil du temps de nombreux systèmes et services, comme par exemple BGPmon.net [7], Renesys [25], PHAS [116] ou encore Argus [157], ont été développé afin de détecter des attaques par détournement BGP. Un de ceux-ci, Argus [157], a pour objectif la détection en temps réel de ce type d’attaques. Pour ce faire ce système utilise une combinaison de données BGP et de mesures ping afin d’identifier des changements dans l’accessibilité d’un réseau consécutifs à un changement dans le routage de celui-ci, et pouvant indiquer que le réseau a été détourné. Afin d’évaluer l’impact sur la sécurité de l’Internet que représentent les attaques que nous identifiées, nous avons décidé de vérifier l’efficacité du système Argus contre ces attaques. Nous avons choisi Argus pour deux raisons : (i) le système est actuellement déployé et permet l’accès publiquement à l’historique de ses alertes, et (ii) il est supposé être capable de dé-tecter n’importe quel type d’attaque par détournement BGP, c’est-à-dire aussi bien celles où l’attaquant utilise un AS d’origine invalide (détournement de préfixe IP via un FAI valide) que celles où l’attaquant utilise un FAI invalide (détournement d’AS via une FAI invalide).

Il s’avère qu’aucun des 2.713 attaques par détournement BGP que nous avons identifiées n’ont été détectées par Argus. La raison à cela est que la plupart des systèmes de détection [96, 116, 157], notamment Argus, fonctionne en construisant

6.4. Résultats 141

URL hosting server IP address

IP prefix URL domain name whois registrant email addres

whois registrar

Keys date Figure6.7–Unexempledecampagneàgrandeéchelleimpliquantplusieursblocsd’adressesIP.Lesnoeudsdisposésdanslesens desaiguillesd’unemontrereflètentlachronologiedelacampagne.

un modèle de la topologie au niveau AS de l’Internet, qu’il utilise ensuite pour valider des changements de routage. Cependant, dans le cas d’un bloc d’adresses IP non annoncé avant d’être détourné, le système ne possède aucun état dans son modèle pour ce réseau. Il ne peut donc évaluer la légitimité d’un changement de routage pour ce réseau. Bien que les systèmes de détection sont très utiles pour les opérateurs réseau afin qu’il puisse surveiller l’état du routage pour leurs réseaux, leur incapacité à détecter le type d’attaques que nous avons observées suggère qu’il devraient, dans le futur, intégrer quelques unes des caractéristiques de ces attaques dans leurs signatures.

Peu de temps après qu’un opérateur réseau se soit plain sur le forum NANOG qu’un de ses blocs d’adresses IP ait été détourné [51], deux rapports différents décri-vant des « opérations de squat d’adresses IP pour envoyer du spam » ont été publiés sur les blogs de BGPmon.net [171] et de Renesys [125]. Ces rapports ont corroboré nos résultats à propos decinq (des 10) ASes invalides que nous avons identifiés.

Prévention des détournements BGP

Outre les techniques de détection de détournements BGP, les opérateurs réseau ont commencé à adopter et à déployer un système de sécurisation de BGP, communé-ment appelé RPKI. Bien que de nombreuses approches différentes ont été proposées pour sécuriser BGP [102], ce système a particulièrement retenu l’attention de la com-munauté réseau ces dernières années. De plus, nous n’avons connaissance d’aucun autre système qui soit aussi prêt et mature que celui-ci.

Le système repose sur une infrastructure à clé publique de ressources (ou « Re-source Public Key Infrastructure, RPKI ») standardisée dans le RFC 6480 [120]

pour prévenir l’injection de routes BGP fallacieuses. La RPKI utilisée consiste en une base de données de certificats de quatre types : (i) un type A appelé « Route Origin Authorisation (ROA) » qui lie un bloc d’adresses IP aux ASs d’origine auto-risés à l’annoncer dans BGP, (ii) un type B qui lie un routeur BGP à l’AS auquel il appartient, et (iii-iv) des certificats C et D qui lient, respectivement, des adresses IP et et des numéros d’AS à leur propriétaire. La chaîne de certification suit la chaîne de délégation des numéros d’AS et des adresses IP, avec l’IANA agissant comme l’au-torité de certification pour les certificats des RIRs, chaque RIR agissant à leur tour comme l’autorité de certification pour les certificats des FAIs auxquels ils délèguent des adresses IP ou des numéros d’AS, etc. Chaque certificat est signé avec clé privée de son propriétaire et embarque également la clé publique de ce dernier. Le système propose ainsi deux techniques différentes pour sécuriser BGP : (i) la sécurisation de l’origine des routes et (ii) la sécurisation de lapropagation des routes (ou BGP-sec). (i) La sécurisation de l’origine des routes, standardisée dans le RFC 6483 [101], utilise des ROAs (certificats de type A) pour vérifier qu’un bloc d’adresses IP est annoncé par les ASs autorisés. Un routeur est alors capable de vérifier la validité d’un message BGP pour un bloc d’adresses IP et un AS d’origine donnés (i-a) en interrogeant la RPKI afin de récupérer un ROA associé au bloc et en vérifiant sa validité du point de vue cryptographique, et, (i-b) si le ROA est valide, en vérifiant que l’AS d’origine et la longueur du préfixe IP dans le message BGP correspondent

6.4. Résultats 143 aux données renseignées dans le ROA. Cela permet d’empêcher un attaquant d’an-noncer un bloc d’adresses IP dont il n’est pas le propriétaire. (ii) La sécurisation de la propagation des routes [119] a quant à elle pour but de prévenir la manipulation du chemin d’ASs par un attaquant en garantissant que l’identité d’aucun AS sur le chemin n’a été usurpée. Pour cela, chaque routeur recevant un message BGP se doit de le signer, au moyen d’un certificat de type B, avant de l’envoyer à ces routeurs voi-sins afin que ceux-ci puissent s’assurer que tous les routeurs par lesquels le message a transité appartiennent bien aux différents ASs renseignés dans le chemin d’ASs.

La sécurisation de l’origine des routes est actuellement en cours de déploiement par les FAIs et autres gestionnaires de réseaux à travers le monde. Selon le RIPE NCC [152], il y a actuellement 4,1% de l’espace IPv4 qui est sécurisé au moyen de ROAs. Curieusement, aucun des blocs que nous avons identifiés comme ayant été détournés n’était couvert par un ROA au moment de l’attaque. Dans 90% des attaques identifiées, l’attaquant a annoncé des blocs d’adresses IP en utilisant un AS d’origine invalide (détournement de préfixe IP via un FAI valide). En supposant qu’un ROA ait existé pour ces blocs avec leur AS d’origine valide, le système RPKI aurait été capable d’invalider les annonces BGP erronées.

Toutefois, en supposant que des ROAs lient l’entièreté des blocs d’adresses IP avec leurs ASs d’origine valides, il est toujours possible pour un attaquant de détourner ces blocs. Pour ce faire, il lui suffit de manipuler le chemin d’ASs en ajoutant à la fin de celui-ci l’AS d’origine valide. De cette façon, les annonces BGP fallacieuses passeraient les vérifications de l’origine des routes (via les ROAs) avec succès. C’est exactement la situation que nous avons observée dans 10% des détournements identi-fiés (détournement d’AS via un FAI invalide). Seule la sécurisation de la propagation des routes (BGPsec) peut empêcher ce type d’attaques. Cependant, BGPsec est tou-jours au début de son processus de développement et son déploiement n’a pas encore débuté.

Globalement, la seule solution définitive au problème des détournements BGP est le déploiement de la sécurisation de la propagation des routes,i.e.,BGPsec. Mal-heureusement, cette solution est beaucoup invasive (que par exemple la sécurisation de l’origine des routes via les ROAs) et ne peut être déployée sans changer de façon substantielle le logiciel et le matériel équipant actuellement les routeurs. De plus, la standardisation de BGPsec est n’est pas encore terminée et il n’existe actuelle-ment pas encore d’impléactuelle-mentation disponible pour les routeurs. Certains fabricants de routeurs y travaillent, mais pour certains autres l’implémentation de BGPsec ne figure même pas sur leur feuille de route.