Résultats

4.2.2.1 Sans protection

La première attaque réalisée considère le client aMule 2.1.3 qui est démuni de protection et nous sert de référence pour les évaluations suivantes des nouveaux mécanismes. Cette version non protégée permet de réaliser une attaque Sybil simple et très ecace. L'identiant des Sybils est construit comme décrit précédemment, les Sybils achent tous la même adresse IP et sont annoncés rapidement (4 Sybils par seconde). De plus, cette version du client réalise une mise à jour des contacts approximative qui s'avère être protable à l'attaque.

En eet, an de maintenir la table de routage à jour, chaque contact de KAD est testé périodiquement en émettant une requête Hello_REQ puis son statut est validé à la réception de la

réponse Hello_RES. Cette version implante une optimisation qui devient une faille de conception lorsque l'on considère l'attaque Sybil. Ainsi, chaque Hello_RES reçue depuis une adresse IP (quelque soit son KADID) acquitte tous les contacts de la table de routage ayant cette adresse IP. De plus, un pair inconnu peut s'annoncer directement en émettant la réponse Hello_RES (au lieu de la requête), et être malgré tout ajouté à la table de routage. Par conséquent, notre attaque envoie des Hello_RES qui permettent à chaque Sybil de s'annoncer tout en acquittant tous les précédents déjà placés. Lorsque l'attaque est terminée, un seul et unique message Hello_RES est ensuite susant pour maintenir les centaines de Sybils en vie.

Figure 4.1  Propagation des Sybils dans la table de routage

La courbe 4.1 montre l'évolution du nombre de Sybils dans la table de routage de deux clients subissant cette attaque : une ancienne version vulnérable et la dernière version incluant tous les mécanismes de protection. La table de routage de la version vulnérable est largement corrompue après l'attaque alors que les Sybils sont absents de la table de routage du client protégé, ce qui est bien le résultat attendu. Après l'émission des Sybils pendant 300s, la table de routage infectée compte ainsi 70% de Sybils (689 Sybils sur 953 contacts). La partie de la table qui n'est pas polluée est constituée des 200 contacts légitimes sauvegardés lors de la précédente exécution et re-chargés pour rejoindre le réseau. La courbe 4.2 montre la vitesse de remplissage de la table de routage selon que le client soit ou non attaqué. Ici le nombre global de contacts est considéré indépendemment de leur qualité de Sybil ou de pair légitime. Malgré une vitesse modérée d'émission des Sybils, la table de routage croît anormalement lors de l'attaque. Nous évaluons ensuite plus en détail ces mécanismes en les confrontant à des attaques plus élaborées. 4.2.2.2 Suivi des messages et protection contre l'inondation

La seconde expérience a pour objectif d'évaluer la protection contre l'inondation de messages. Nous avons ainsi lancé l'attaque sur le client eMule 0.49a en désactivant la limitation des adresses IP. Pour être fonctionnelle, l'attaque a dû être modiée de deux manières. D'une part, le suivi des messages ne traite aucune réponse si le client courant n'a pas envoyé la requête correspondante. La faiblesse autorisant l'annonce et le maintien des Sybils par un unique message Hello_RES

Figure 4.2  Nombre de contacts dans la table de routage en fonction du temps

n'est donc plus possible. Nous avons modié l'attaque en conséquence en répondant aux requêtes Hello_REQ émises par le client victime pour tester les Sybils. Cette tâche n'est cependant pas triviale. En eet, un message Hello_REQ ne spécie pas le KADID du pair destinataire mais celui-ci doit être retourné dans la réponse Hello_RES. Un client normal ne gère que son propre KADID, il n'y a donc jamais d'ambiguïté pour répondre. Cependant, notre outil d'attaque gère de multiples KADIDs pour les Sybils et ne sait pas a priori quel KADID est concerné par la requête Hello_REQ reçue. Pour résoudre ce problème, chaque Sybil doit communiquer grâce à un port UDP diérent qui permet de retrouver quel KADID est concerné par la requête, selon le port sur lequel elle arrive. Cette modication permet d'assurer la pérennité de l'attaque, sans quoi les Sybils insérés sont supprimés après deux heures ou dès qu'un contact plus récent entre dans le k-bucket.

D'autre part, pour ne pas déclencher le mécanisme protégeant un client contre une émission anormale de messages, la fréquence d'émission des messages Hello_REQ doit être baissée à deux par minute pour rester sous le seuil de détection. Nos expériences attestent du bon fonctionnement de ce mécanisme. Le taux d'émission avant le rejet des paquets Hello_REQ est déni à trois par minute, et au delà de 15 paquets par minute, l'adresse IP émettrice est bannie du client, ce que nous avons pu constater. En se conformant à ces contraintes, l'attaque est fortement ralentie comme le montre la courbe 4.3. En eet, l'injection du même nombre de Sybils que précédemment (courbe 4.1) prend plus de huit heures alors qu'elle prenait quelques minutes sans cette protection. L'attaque demeure pour autant possible, la table de routage étant polluée au nal avec 60% de Sybils (540/873). La protection contre l'inondation protège ecacement la majorité des connexions au réseau KAD qui sont de courte durée. Les connexions longues restent cependant vulnérables.

4.2.2.3 Limitation des adresses IP

Notre précédente attaque a été réalisée en utilisant qu'une seule adresse IP pour l'ensemble des Sybils. En activant la limitation des adresses IP, nous avons en eet constaté que seul le premier

Figure 4.3  Propagation des Sybils dans la table de routage protégée contre l'inondation de messages

Sybil est inséré dans la table de routage, tous les autres KADID présentant la même adresse sont ignorés. Pour contourner ce problème, nous avons modié l'outil d'attaque de manière à ce que chaque Sybil soit annoncé avec une adresse IP usurpée aléatoirement choisie. La courbe 4.4 montre que cette modication permet la pollution de la table de routage. De plus, nous avons également constaté que la protection contre l'inondation est complètement inecace avec cette modication. En eet, le suivi des paquets utilisé pour détecter l'envoi abusif de messages mesure le nombre de messages venant d'une même source par rapport à l'adresse IP émettrice. En usurpant leur adresse IP, les messages semblent venir de sources diérentes et l'attaque n'est pas détectée. La vitesse de propagation des Sybils usurpant leur adresse IP est donc similaire à celle observée pour un client sans protection (courbe 4.1), le suivi de paquets protégeant contre l'inondation des messages ne pouvant appréhender une attaque distribuée.

L'usurpation d'adresse IP rend cependant les Sybils beaucoup moins utiles pour l'attaquant. Celui-ci ne peut plus espionner, éclipser ou polluer les entrées de la DHT avec de tels Sybils, étant incapable de recevoir les messages. Il est également beaucoup plus délicat de maintenir en vie les Sybils car leur adresse IP étant usurpée, ils ne peuvent recevoir les Hello_REQ de vérication. Pour les maintenir, l'attaquant doit anticiper le test en émettant pour chaque Sybil des messages Hello_REQ de manière pro-active vers le pair ciblé avant que celui-ci ne sollicite les Sybils par une preuve d'activité.

Néanmoins, l'usurpation d'adresse IP était utilisée dans l'attaque [WTCT+08] pour écraser les contacts dans les tables de routage et réaliser le déni de service nal. A ce niveau, cette attaque demeure donc possible ce qui nous amène à étudier la dernière protection visant à empêcher l'usurpation de KADID et d'adresse IP.

4.2.2.4 Vérication des identités

Nous avons nalement rejoué cette dernière attaque avec l'ensemble des protections activées, incluant la vérication des identités. Les Sybils injectés ne peuvent plus se maintenir dans la

Figure 4.4  Propagation des Sybils usurpant leur adresse IP dans la table de routage protégée contre l'inondation de messages et par la limitation d'adresse IP

table de routage avec une adresse IP usurpée car ils ne peuvent accomplir le test nécessitant une interaction (three-way handshake). La courbe 4.6 montre que les Sybils sont dans un premier temps insérés avec un statut  non vérié, tous comme les autres pairs lors d'une exécution normale 4.5. Ce statut empêche les contacts d'être utilisés pour router des messages ce qui les rend inoensifs. En revanche, comme le test vériant l'identité échoue, les Sybils sont nalement supprimés de la table de routage (courbe 4.6) alors qu'en condition normale les contacts sont progressivement vériés jusqu'à l'obtention d'une table de routage entièrement valide après 1500s (courbe 4.5).

De plus, étant donné le statut non vérié, les Sybils sont supprimés beaucoup plus rapide-ment de la table de routage que le délai limite usuel d'une heure. Ne pouvant être maintenus en vie articiellement, les Sybils usurpant des adresses IP polluent la table pour un temps limité. Par ailleurs, les contacts ne peuvent désormais plus mettre à jour l'information d'un pair sans posséder la clé privée initialement utilisée lors de l'enregistrement dans la table de routage. Ceci empêche l'attaque décrite dans [WTCT+08] qui pouvait alors partitionner le réseau.

Les résultats obtenus sur cette dernière version montrent l'avancée signicative que con-stituent les nouveaux mécanismes contre l'attaque Sybil. Ils empêchent aujourd'hui l'injection massive de Sybils provenant d'une même adresse IP, et de ce fait, augmentent considérablement le coût de l'attaque Sybil telle que pratiquée par [SENB07a]. S'il est devenu très coûteux en adresses IP de réaliser une attaque à large échelle sur le réseau, nous allons montrer que des attaques très ciblées restent en revanche ecaces avec peu de ressources.