Modélisation et détection des comportements malveillants dans les réseaux pair à pair publics

Transcription

1 Nom, Prénom : Montassier Guillaume Branche : Master Sécurité des Systèmes d Informations Responsable pédagogique UTT : Année : 2011 M. Alain Corpel Semestre : Printemps Titre du stage Modélisation et détection des comportements malveillants dans les réseaux pair à pair publics Résumé Ce stage s est déroulé dans l équipe ERA - Environnements et Réseaux Autonomes au sein de l Institut Charles Delaunay. Les réseaux P2P constituent aujourd hui des SI majeurs comptant des millions d utilisateurs. L objectif de ce stage est de concevoir un système permettant la détection des comportements malveillants et plus particulièrement de la pollution dans le cadre de ces réseaux. Nous proposons un système détectant la pollution grâce à l analyse des différents noms associés à un même fichier. Cette méthode de détection est ensuite évaluée et validée par des experts qui mettent en évidence son faible taux d erreur. Nous montrons que les fichiers présents dans KAD sont au 2/3 infectés par une nouvelle forme de pollution, la falsification d indexation. Dans un second temps, nous étudions les éléments permettant de diffuser la pollution puis expérimentons celle-ci et comparons nos méthodes avec les comportements réellement aperçus sur le réseau par des mesures. Nous proposons ensuite une autre méthode de détection plus optimisée en terme de ressource et nous concluons nos travaux. Entreprise : ERA / STMR - UMR CNRS 6279 Lieu : Troyes Responsable : M. Thibault CHOLEZ Mots clés : Recherche appliquée 14 Services non marchands (fonction publique) Sécurité des systèmes Logiciels - Recherche

2 2 Remerciements Je voudrai tout d abord remercier M. Thibault Cholez pour m avoir traité comme un égal là ou il était souverain et qui a de surcroit énormément contribué à mon évolution scientifique et technique, merci pour sa patience et le temps qu il m a consacré. Sa rigueur et sa qualité de travail resteront des exemples. Ensuite, pour parler de M. Guillaume Doyen et M. Rida Khatoun je voudrai citer Mr. Robert Louis Stevenson : Avare de louange et prodigue de conseil. Leurs commentaires et leurs avis m ont été très précieux.

3 Table des matières 1 Introduction Cadre Scientifique Contexte Organisation du manuscrit Terminologie I État de l art 11 2 Les architectures pair à pair Le Modèle P2P Le modèle centralisé Le modèle décentralisé Kademlia : un exemple de DHT Adressage Table de routage Localisation Publication KAD : un exemple d implémentation La sécurité dans KAD L attaque Sybil Mise en oeuvre Contre-mesures Solutions Proposées Pollution Pollution des fichiers Pollution de l indexation (index poisoning) Les contre-mesures II Contributions 29 4 Détection et quantification de la pollution Détection de la pollution dans la DHT KAD Introduction La stratégie de détection de la falsification d index Métrique de similarité pour la détection de la pollution Quantification de la pollution dans KAD Collecte des données sur les contenus partagés Validation de la métrique Quantification finale et caractérisation de la pollution dans KAD Conclusion Étude de la diffusion de la pollution Supervision des mots-clefs pollués

4 5.1.1 Architecture de supervision mot-clefs supervisés Stratégie de détection Identification de la méthode de falsification du nombre de sources Détection des nombres de sources falsifiés Validation de la Détection Test de la vulnérabilité à grande échelle Conclusion 53 7 ANNEXE Top 100 des contenus téléchargés en Liste des experts Étude des annonces de publication dans KAD Code des messages Kademlia Diagramme UML de la publication dans le réseau KAD Publication : Content Pollution Quantification in Large P2P networks Table des figures 2.1 Exemple d architectures centralisées. (a) Architecture avec un serveur unique (b) Architecture avec des serveurs distribués (c) Architecture avec des serveurs Différentiés Exemple d architectures décentralisées (a) Architecture pure (b) Architecture hybride Exemple de table de routage Étapes de publication dans le réseau KAD[3] Attaque Sybils dans KAD : Eclipse [8] Mécanisme de publication et de falsification Autres Noms de fichiers associés à un fichier téléchargé en tant qu Ubuntu Noms de fichiers annoncés pour un fichier sain Noms de fichiers annoncés pour un fichier corrompu Nombre moyen de sources réelles trouvées en fonction du temps Interface web pour le vote des experts Distribution cumulative du nombre de fichiers en fonction de l indice de pollution obtenu Distribution du nombre de fichiers en fonction de l indice de pollution obtenu Quantification de la pollution des contenus dans le réseau P2P KAD Architecture du réseau HAMACK [4] Notation des requêtes iron et avatar et twilight avec la métrique de détection par nombre de sources Régression linéaire entre la métrique de détection par nom et la métrique de détection par nombre de sources (échelle log) Résultat d une recherche sur le mot recherché Capture d une requête de publication Champ tag issu d une requéte de publication

5 Liste des tableaux 2.1 Caractéristiques des principaux réseaux Tableau récapitulant la pollution de contenu Tableau récapitulant les moyens de diffusion de la pollution Tableau récapitulant la pollution d index Exemple de différents noms annoncés pour un fichier au premier niveau d indexation Taux d erreurs pour les différentes valeurs de α et β Taux d erreurs pour la borne des fichiers pollués Taux d erreurs pour la borne des fichiers sains Taux d erreurs calculés grâce aux votes de experts Types de contenus liés à la falsification d index Requêtes capturées pour le fichier A013BDE495058B9CE E4189A Format d une requête de publication Format du champ TAG Format réponse à une requête de publication Liste des Équations 4.1 Index de Jaccard Indice de similarité de Tversky Métrique de détection (différence des noms) Coefficient de Dice Métrique de détection (nombre de sources) Coefficient de corrélation de Bravais-Pearson

6 6 LISTE DES ÉQUATIONS

7 Chapitre 1 Introduction 1.1 Cadre Scientifique Ce rapport présente le travail effectué sur une durée de 6 mois dans le cadre d un stage Master. Pour ce stage, j ai intégré l équipe ERA - Environnements et Réseaux Autonomes 1 au sein de l Institut Charles Delaunay (ICD) 2. L Institut Charles Delaunay possède depuis 2006 le statut de Formation de Recherche en Evolution (UMR STMR 6279). L équipe ERA dirigée par le professeur Dominique GAITI 3 est centrée sur le domaine des réseaux autonomes, mais possède un large domaine d activité car elle travaille aussi bien au niveau architecture réseau, qu au niveau des protocoles, ou encore dans la gestion et le contrôle. Mon travail entrait dans le cadre du Groupement d Intérêt scientifique (GIS) 3SGS «Surveillance, Sûreté et Sécurité des Grands Systèmes»et plus particulèrement sur le projet ACDA-P2P. L objectif du projet ACDA-P2P est de proposer une architecture collaborative pour la détection d attaques dans les réseaux pair à pair. 1.2 Contexte Les réseaux pair à pair sont devenus des applications majeures d internet 4. Ils représentent la majorité des systèmes d échange de fichiers et sont aussi utilisés pour des systèmes de streaming multimédia (Spotify) et pour des systèmes de communication (Skype). Un réseau pair à pair est un réseau dans lequel les échanges de services sont effectués directement entre les éléments terminaux du réseau (à l inverse du modèle client-serveur). Actuellement, Les réseaux P2P permettent la connexion et les échanges entre des millions d utilisateurs répartis à travers le monde. A cause de l absence de contrôle propre à aux réseaux P2P ainsi que l engouement qu ils suscitent, les réseaux P2P ont vu l arrivée de comportements malveillants créant des dysfonctionnements (pollution, Sybils) ou les utilisant à des fins malintentionnées (botnet, DDoS). La pollution est un comportement particulièrement dangereux car les conséquences peuvent être multiples (téléchargements inintentionnels, faux positifs pour la surveillance de fichier, diffusion de contenus illégaux...). De plus, la pollution est due à plusieurs facteurs, comme les erreurs de partages ou encore la pollution réalisée par les entreprises pour empêcher le téléchargement des fichiers licenciés et la pollution réalisée par les cybercriminels. Aucune étude récente n à été réalisée sur les comportements malveillants dans les réseaux de partage et les contre-mesures proposées ont un impact limité. Le travail de ce stage a consisté à étudier les problèmes de pollution affectant un réseau réel et plus particulièrement les attaques de pollution dont l objectif est de faire télécharger un fichier malveillant dans le cadre du réseau KAD. Dans ce rapport de stage, nous présentons donc la démarche et le travail accomplis pour lutter contre cette forme de pollution. 1. Environnements et Réseaux Autonomes - http ://era.utt.fr/ 2. Institut Charles Delaunay - http ://icd.utt.fr/fr 3. http ://era.utt.fr/fr/membres.html 4. http :// 7

8 8 CHAPITRE 1. INTRODUCTION 1.3 Organisation du manuscrit Pour présenter le travail réalisé dans le cadre de la modélisation et la détection des comportements polluants dans le réseau KAD, ce rapport est divisé en trois parties principales qui sont : (1) l état de l art des réseaux P2P et plus particulièrement du réseau KAD ;(2) l étude, la détection et la quantification de la pollution ;(3) l étude de la diffusion de la pollution. Enfin, nous conclurons et présenterons les perspectives futures. Nous introduirons dans un premier temps (section 2) les réseaux pair à pair orientés sur le partage de fichiers et décrirons la structure et le fonctionnement du réseau KAD. Nous ferons un tour d horizon des problèmes de sécurité que ce réseau rencontre. Nous nous focaliserons ensuite plus spécifiquement sur les problèmes de pollution et nous présenterons les formes de pollution actuellement découvertes et utilisées sur KAD. Dans la section 4, nous décrirons une nouvelle forme de pollution appelée falsification d index que nous avons découverte et présenterons son fonctionnement. Nous décrirons une stratégie de détection basée sur une métrique de similarité puis nous automatiserons son application aux fichiers de KAD. Pour cela, nous réaliserons une expérience consistant à télécharger une grande quantité de fichiers populaires (2000 fichiers) pour pouvoir quantifier cette pollution. Nous ferons aussi appel à des experts pour pouvoir valider notre métrique de détection. Nos résultats montrerons que la falsification d index est un phénomène majeur et participe à la diffusion de fichiers pornographiques et pédopornographique. Nous continuerons sur une étude de la diffusion de la pollution (section 5). Dans une première partie, nous présenterons les mécanismes et les failles protocolaires utilisés pour diffuser la pollution ainsi que les outils que nous avons mis en place pour reproduire la falsification d index. A l issue de cette partie, nous aurons étudié la diffusion de la pollution, mis en avant des failles du protocoles et réalisé des tests à échelle réelle. Une deuxième partie permettra de découvrir les comportements réels des pollueurs grâce à des sondes placées dans le réseau et surveillant le traffic. Les informations ainsi récoltées permettront de faire le lien entre les fichiers annoncés peu de fois avec un grand nombre de sources annoncées et les fichiers pollués et permettront la mise en place d une nouvelle métrique de détection. Pour finir, nous présenterons dans la section 6 les futurs travaux et nous conclurons. 1.4 Terminologie Pour clarifier ce rapport et éviter tout risque de confusion, nous définissons une terminologie : Le terme pair à pair fait référence à un modèle distribué dont les pairs qui le composent sont à la fois client et serveur. Dans le cadre ce rapport, nous utiliserons indifféremment les termes pair à pair, P2P, et Peer to Peer. Le terme pair ou encore noeud désigne un élément d un réseau pair à pair. Cet élément est généralement un poste utilisateur mais peut aussi être une machine dédiée ou encore une sonde. Le terme ID est un terme générique pour désigner un identifiant. Le KAD ID est un identifiant propre au réseau KAD. Il est composé de 128 bits et permet de distinguer les pairs dans la DHT Kademlia. l acronyme DoS signifie Deny of Service (Déni de Service). Il est associé à l attaque par déni de service qui consiste à rendre un service indisponible en saturant le service ou en exploitant une faille de celui-ci.

9 1.4. TERMINOLOGIE 9 l acronyme DDoS signifie Distributed Deny of Service (Déni de Service Distribué). Une attaque DDoS est similaire à une attaque DoS par saturation mais avec un grand nombre de machines distribuées sur le réseau Internet. le terme Hash est utilisé pour parler du résultat d une fonction hachage. Ainsi, si le terme en entré est schrodinger et la fonction de hachage est MD4, le Hash sera : F69FCA040EE67C3AF4B C7D28 l acronyme DHT ou Distributed Hash Table (Table de Hachage Distribuée) est un système d indexation utilisé par certains réseaux P2P.

10 10 CHAPITRE 1. INTRODUCTION

11 Première partie État de l art 11

12

13 Chapitre 2 Les architectures pair à pair 2.1 Le Modèle P2P Le pair-à-pair est un modèle de service apparu en 1999 avec l avènement du logiciel Napster. Ce modèle est caractérisé par les communications directes entre différents pairs sans utiliser de serveur central. Par définition les réseaux pair-à-pair sont donc distribués, partiellement ou totalement. La suppression d un contrôle centralisé engendre cependant des problèmes de sécurité, chaque pair ayant un comportement autonome. Ainsi, les réseaux pairs à pairs sont soumis à de nombreuses malveillances (pollution, DoS, man-in-the-middle, etc). La décentralisation permet en contrepartie de connecter des millions de pairs (passage à l échelle) qui constituent une architecture à faible coût (pas d infrastructure à payer) et robuste aux défaillances/pannes. Ces avantages ont orienté l utilisation de ce modèle vers le partage de données Le modèle centralisé Ce modèle utilise un ou plusieurs serveurs pour centraliser des informations. Les serveurs servent en général à indexer les ressources du réseau, facilitant la publication et la recherche de données. Ce modèle reste tout de même pair-à-pair car le transfert de fichiers est réalisé directement entre pairs, le serveur servant juste à les mettre en relation. Il existe trois types d organisation P2P faisant intervenir un serveur : serveur unique, serveurs distribués et serveurs différentiés [5]. Serveur Unique L utilisation d un serveur central est l architecture la plus simple. Un serveur indexe toutes les données partagées et les pairs effectuent des recherches sur celui-ci. Grâce aux recherches, il est alors possible de trouver le pair échangeant les données et de se connecter directement sur celui-ci. Les échanges de données sont donc réalisés en pair-à-pair et la recherche et publication en mode client/serveur. La figure 2.1.(a) illustre ce type d architecture. Serveurs Distribués Les serveurs distribués fonctionnent de la même façon qu un serveur central. Cependant, il existe plusieurs serveurs distribués ce qui permet de diminuer les risques d indisponibilité. La publication des données et la recherche se font sur le serveur sur lequel le pair est connecté, mais il est possible de faire une recherche globale sur tous les serveurs. Un exemple de réseau utilisant des serveurs distribués est le réseau edonkey. La figure 2.1.(b) illustre ce type d architecture. Serveurs Différentiés Certains réseaux P2P utilisent plusieurs serveurs ayant chacun des fonctions distinctes. Par exemple le réseau Bittorent utilise des serveurs web pour indexer les fichiers torrent et des trackers qui connaissent la localisation des données. Un torrent contient des informations propres au fichier partagé ainsi que l adresse du tracker. La publication s effectue en deux temps : publication d un fichier torrent sur le serveur web, puis prise en charge du torrent par un tracker. Pour télécharger un fichier un pair doit donc : télécharger le fichier torrent, se connecter au tracker et lancer le téléchargement en pair-à-pair avec le pair source. La figure 2.1.(c) illustre ce type d architecture. 13

14 14 CHAPITRE 2. LES ARCHITECTURES PAIR À PAIR Figure 2.1 Exemple d architectures centralisées. (a) Architecture avec un serveur unique (b) Architecture avec des serveurs distribués (c) Architecture avec des serveurs Différentiés Figure 2.2 Exemple d architectures décentralisées (a) Architecture pure (b) Architecture hybride Le modèle décentralisé La centralisation amène un risque en terme de disponibilité et engendre un coût d exploitation important. Pour pâlier ce risque, certains modèles P2P sont construits avec un système entièrement distribué. La décentralisation engendre des réseaux plus complexes (indexation sur les pairs, topologie) et de nouveaux risques pour la sécurité (attaque Sybil, man-in-the-middle, etc), mais permet d avoir un réseau pérenne et au coût distribué. On distingue deux architectures : pure et hybride et deux topologie : structurée et non structurée [1]. Architecture Architecture Pure Dans ce modèle tous les noeuds ont le même rôle, il n y a plus de point central de coordination. Beaucoup des applications basées sur les DHT utilisent cette architecture, comme par exemple Kademlia, Gnutella, etc. La figure 2.2.(a) illustre le modèle pur. Architecture Hybride Ce modèle utilise une hiérarchie entre pairs, il existe des Superpair dont le rôle peut varier (indexation, routage, etc) et des pairs normaux. Ce système se différencie d un système centralisé distribué par le nombre important de super-pair et par l allocation dynamique de ceux ci. La figure 2.2.(b) représente ce type d architecture.

15 2.2. KADEMLIA : UN EXEMPLE DE DHT 15 Topologie Dans les réseaux pair-à-pair la topologie est virtuelle, la position des noeuds et des ressources dans le réseau dépend donc uniquement de la structure du modèle. Il existe deux classes de topologie distribuée : les topologies non-structurées et structurées. Topologie Non Structurée Dans les réseaux non structurés comme Gnutella, les pairs ainsi que les données sont placés aléatoirement. La position aléatoire des pairs et l absence de serveur pour les localiser obligent ceux-ci à créer de nombreux liens aléatoires entre eux. Dans cette topologie, l ensemble des liens est sollicité á chaque recherche (inondation) ainsi pour avoir une recherche efficace il est nécessaire d augmenter le nombre de lien ou d augmenter la charge de ceux-ci. Les recherches sont effectuées par inondation, chaque pair propage la requête à ses voisins jusqu à trouver le fichier. Cette méthode engendre un grand nombre de messages et ne garantit pas la localisation du fichier. Topologie Structurée Dans les réseaux structurés, chaque ressource et chaque pair possède un identifiant qui permet de le localiser. On réalise donc le lien entre une donnée et sa position dans le réseau, ce qui améliore l efficacité des recherches. Pour construire ce lien les modèles P2P se basent sur les tables de hachage distribuées (DHT). Les DHT sont des systèmes d indexation distribués associant une clef à une ressource. La clef est composée d un couple (identifiant, valeur). L identifiant est l élément qui va permettre de localiser la clef. Il est le résultat d une fonction de hachage sur un élément distinctif de la donnée (le nom, le binaire, etc). La valeur de la clef permet de trouver la ressource, par exemple avec l adresse du pair source. Les couples (identifiant, valeur) sont positionnés et dupliqués sur les noeuds du système de telle manière que la déconnexion d un noeud n entraine pas la perte d indexation d un fichier [2]. Comparaison Nous avons vu qu existent différentes architectures et différentes structures pour les réseaux P2P. L architecture centralisée permet d avoir une indexation et une topologie plus simple mais engendre un risque pour la disponibilité et un coût important. Exemple de réseaux centralisés : Napster, edonkey, Bittorrent. Les architectures non structurées et pures ont de nombreuses limitations : La recherche passe mal à l échelle car elle entraine une multiplication du nombre de requêtes et la saturation de certains pairs. Certains réseaux comme Gnutella sont donc devenus hybrides pour paliers ces faiblesses. L architecture décentralisée et structurée propose un système très performant. L utilisation de DHT permet une localisation rapide et efficace des données. Il est possible de trouver des fichiers rares et les réseaux sont très résistants aux déconnexions des pairs. Un exemple de réseau respectant cette architecture est le réseau KAD. Celui-ci est basé sur le modèle de DHT Kademlia qui permet de connecter des millions d utilisateurs et que nous présenterons dans la section suivante. Le tableau 2.1 présente les réseaux les plus connus et leurs principaux éléments. 2.2 Kademlia : un exemple de DHT Le modèle de DHT Kademlia [26] spécifie la structure d un réseau pair à pair distribué ainsi que les échanges au sein de ce réseau. Le routage et la localisation des noeuds dans ce système sont basés sur une métrique utilisant l opération XOR. Beaucoup d avantages de Kademlia sont dûs à cette opération et notamment au fait qu elle soit symétrique (distance(a, B)= A XOR B = B XOR A). L organisation des contacts connus selon un arbre binaire permet d avoir un routage en

16 16 CHAPITRE 2. LES ARCHITECTURES PAIR À PAIR architecture Localisation Sécurité Disponibilité Recherche Napster Serveur Central faible edonkey Centralisé Serveur Distribué Garantie haute moyen Complexe Bittorent Serveur Différenciés faible Gnutella Non Structuré Pur Non Garantie Complexe FastTrack Décentralisé Non Structuré Hybride Non Garantie faible haute Complexe Kademlia Structuré Pur log n +c Stricte Table 2.1 Caractéristiques des principaux réseaux [log n] + c messages (c est une constante issue du fait que l arbre binaire est déséquilibré et n le nombre de noeuds dans le réseau) Adressage Kademlia distingue deux types d objets : les pairs et les ressources partagées. Chaque objet possède un identifiant au sein du même espace d adressage, celui-ci sert d adresse sur le réseau et est défini sur 160 bits. La position des pairs est virtuelle, deux pairs dont les identifiants sont proches seront voisins dans le réseau, mais, peuvent être géographiquement très éloignés. Une ressource est aussi positionnée en fonction de son identifiant. Cependant, elle ne sera pas placée exactement à son adresse mais sur un ou plusieurs pairs proches (d après la distance XOR) qui en auront la responsabilité. L attribution des identifiants se fait de manière différente pour les pairs et les ressources. Les pairs reçoivent un identifiant aléatoire lors de leur connexion au réseau, alors que l attribution de l identifiant d une ressource dépend d une fonction de hachage (MD4 ou SHA1). Par exemple, le mot-clé toto aura pour identifiant en hexadécimal : MD4(toto)=0B9C2625DC21EF05F6AD4DDF47C5F203837AA32C Table de routage On appelle préfixe [16] le plus grand nombre de bits de poids fort en commun entre deux identifiants. La table de routage contient les adresses des pairs connus, celles-ci sont placées dans un arbre binaire de recherche (ABR). L arbre permet de répartir les adresses en se basant sur leur distance logique par rapport au pair courant. Cette distance est définie par le préfixe entre le pair et le pair distant, pour la calculer on utilise la fonction OU exclusif (XOR). Ainsi, à chaque niveau h de l arbre correspond un intervalle (k-bucket) qui contient k adresses partageant un préfixe de h bits. Le parcours de l arbre binaire se fait donc avec le résultat de la fonction currentid XOR contactid. De cette façon, à chaque niveau h de l arbre on compare le h ème bit et, s il est égal à 1 on arrête le parcours et on entre dans le bucket correspondant. Ensuite, dans le bucket on sélectionne le ou les noeuds ayant les ID les plus proches du contactid. La figure 2.3 représente une table de routage dans le cas ou l identifiant est composé de 4 bits. On remarque que plus on descend dans l arbre, plus la distance au pair courant est faible, et plus la proportion des contacts connus augmente car les k contacts représentent une partie de l espace toujours plus petite (deux fois moins) à chaque niveau. Cette structure permet d avoir un routage en O[log n] +c. Lors de l initialisation d un pair, celui ci possède un seul niveau dans son arbre binaire et donc un seul bucket. Au fur et à mesure qu il découvre de nouveaux pairs il remplit son bucket. Quand son bucket est rempli, il créé un nouveau niveau dans l arbre et par conséquent un nouveau bucket. Il répète ainsi l opération jusqu à ce que l arbre soit de h niveaux (ou h est la profondeur maximum autorisée) ou jusqu à ce qu il be trouve plus de contacts assez proches. Le remplissage de la table de routage se fait automatiquement lorsqu un pair reçoit un message

17 2.2. KADEMLIA : UN EXEMPLE DE DHT 17 Figure 2.3 Exemple de table de routage (dans la limite des places libres dans le bucket correspondant). En effet, si l ID de l émetteur n est pas déjà dans la table de routage, le pair met à jour le bucket concerné. Cependant, si le bucket contient déjà k ID, le pair vérifie que l adresse vue il y a le plus longtemps répond toujours. Si celle-ci répond, la table n est pas mise à jour et si elle ne répond pas, on supprime cet ID du bucket et on le remplace par l ID de l émetteur. On donne la priorité aux pairs les plus anciens toujours connectés car il est plus probable que ceux-ci restent connectés [30] Localisation La recherche de fichier sur Kademlia est itérative, l avantage de ce système est qu il permet de facilement et rapidement mettre à jour les tables de routages des pairs actifs tout en évitant les noeuds défaillants ou malveillants. Cependant, à l inverse du routage récursif [15] il est plus difficile de mettre à jour les pairs passifs. Cette difficulté vient du fait qu à la réception d une requête de recherche les pairs interrogés se contentent de répondre, mais l absence de nouvelles informations les empêchent de mettre à jour leur table de routage. Pour le routage récursif, comme les pairs interrogés demandent à leur tour à d autres pairs, ils en profitent pour mettent à jours leur table de routage. Kadmelia permet aussi de réaliser des recherches en parallèle, améliorant ainsi l efficacité par rapport aux déconnexions de noeuds. Pour localiser une information il est nécessaire de connaitre sa clef ou son identifiant 1. L identifiant de 160 bits correspond au hash de l information, et permet de l identifier (comme un mot-clef). Il est donc nécessaire de connaître un élément identifiant l information pour pouvoir trouver sa clef. Une fois l identifiant connu, on parcourt l arbre de routage pour trouver les pairs dont la distance avec l ID du mot est la plus faible. Ensuite, on envoie une requête de localisation aux pairs trouvés qui nous envoient en réponse des pairs plus proches de l ID recherché. On répète cette opération jusqu à ce que les pairs retournés ne se rapprochent plus de l ID cherché. Alors, on peut envoyer une nouvelle requête destinée à récupérer l information Publication On entend par publier le fait de partager sur le réseau une information. On considère qu une information est publiée quand toutes les clefs liées à celle-ci sont placées dans le réseau. Pour cela on va positionner les clefs sur des pairs en fonction de leur ID. La publication d une clef est réalisée sur plusieurs pairs appelés réplicats. La zone dans laquelle sont situés ces pairs est appelée la zone de tolérance. La publication d une information dans Kademlia suit donc certaines étapes : création de la clef, localisation des pairs les plus proches, utilisation de la requête STORE pour publier la clef sur les 1. une information peut éventuellement avoir plusieurs clefs

18 18 CHAPITRE 2. LES ARCHITECTURES PAIR À PAIR pairs. Pour assurer la persistance des données, chaque noeud republie les clefs de ses informations toutes les heures, de plus le publicateur original d une clef doit la republier toutes les 24 heures. Une clef a donc une durée de vie de 24 heures renouvelable indéfiniment grâce à la republication par le pair original KAD : un exemple d implémentation Le réseau KAD est un réseau pair-à-pair basé sur la DHT Kademlia et orienté vers l échange de fichiers. Ce réseau, grâce aux avantages de Kademlia supporte des millions d utilisateurs simultanés répartis dans le monde entier. KAD utilise une version modifiée des algorithmes de Kademlia. Les principales modifications se trouvent dans les étapes de publication et de localisation qui sont maintenant spécialisées pour le partage de fichier alors que kademlia ne décrit aucun service particulier. De plus, l adressage se fait sur 128 bits au lieu des 160 préconisés dans Kademlia. Publication La publication des fichiers dans Kademlia est réalisée avec un double niveau d indexation, pour cela on utilise un jeu de deux clefs [33] : La Keyword key : qui est le hash d un mot-clef et contient le hash des fichiers liés à ce mot-clef. La Source key : qui est le hash du fichier et contient l adresse des pairs qui le possède. Cette clef permet donc de trouver les sources. Pour assurer la persistance des données la publication de la Source Key doit être refaite toutes les 24 heures et les Keyword Key toutes les 5 heures. De plus, une clef est publiée sur les dix pairs les plus proches de son ID [32]. La figure 2.4 représente une publication d un fichier nommé Kademlia Project. Dans cet exemple, il existe deux mots-clefs : Kademlia (hash : 00010) et Project (hash : 11000), et un fichier (hash : 00111). La première étape consiste donc à construire les références (Keyword key et Source key). Ensuite, on localise les pairs les plus proches des clefs et on publie les Keyword key avec la requête publish Key Req et source key grâce à la requête publish Source Req. Recherche La première étape de la recherche est de trouver une keyword key. Pour cela l argument utilisé est le hash d un mot contenu dans le titre du fichier, ce mot doit être exact à la lettre près. En effet, le hash de 2 mots proches donne des résultats complêtement différents. Par exemple : hash(schrodinger)=f69fca040ee67c3af4b c7d28 hash(schradinger)=2b45ecb549cb395b6d537320b La moindre erreur faussera la recherche et ne permettra pas de trouver le fichier. Une fois le hash du mot réalisé, on parcourt l arbre pour trouver les trois pairs dont la distance avec l ID du mot est la plus faible. Ensuite, on envoie en paralèlle à ces trois pairs une requête (route request) et s ils connaissent des pairs plus proches de l ID recherché ils nous les envoient (route reponse). On répète cette opération jusqu à ce que les pairs retournés ne se rapprochent plus de l ID cherché. Alors, on peut envoyer une nouvelle requête destinée à récupérer la valeur de la keyword key. Ensuite, on extrait le hash des fichiers potentiels des réponses. Une fois un fichier sélectionné, on cherche la source key correspondante suivant le même processus. On extrait finalement l adresse des sources et on initialise le téléchargement du fichier [5].

19 2.2. KADEMLIA : UN EXEMPLE DE DHT 19 Figure 2.4 Étapes de publication dans le réseau KAD[3]

20 20 CHAPITRE 2. LES ARCHITECTURES PAIR À PAIR

21 Chapitre 3 La sécurité dans KAD 3.1 L attaque Sybil L attaque Sybil a été définie en 2002 par J. Douceur comme the forging of multiple identities [14]. Le principe est d introduire dans un réseau P2P des pairs corrompus, nommés Sybils, et de les placer pour qu ils puissent agir sur le réseau. Cette attaque exploite deux vulnérabilités du réseau KAD décrites dans [8] : 1. La possibilité d attribuer manuellement un ID à un pair, ce qui permet de placer ce pair à n importe quel endroit du réseau. 2. La publication d un contenu se fait toujours de manière déterministe sur les noeuds les plus proches de l ID de ce contenu. A cause de ces faiblesses, l introduction de Sybils dans le réseau permet de réaliser plusieurs types d attaques [9]. Par exemple : Si les Sybils sont dispersés dans une zone du réseau, il est alors possible d en surveiller l activité. En localisant les Sybils autour d un contenu, on peut empêcher les recherches sur celui-ci d aboutir ou encore réaliser une attaque par Deni de Service distribué (DDoS) en redirigeant les messages vers une cible. Il est aussi possible de polluer un mot avec de faux fichiers Mise en oeuvre La complexité de la mise en place d une attaque Sybil varie selon l objectif de cette attaque et selon les contre-mesures implémentées. Nous allons présenter la mise en place de trois types d attaques Sybils dans le réseau KAD. Pour simplifier la présentation, nous ne considérerons pas les contre-mesures actuellement implémentées dans les clients (emule 1, amule 2 ) [7]. Éclipse : Pour éclipser un contenu, la première étape est de placer les Sybils au plus près de l ID d une des clefs du contenu. Placés près d une Keyword key les recherches n afficheront plus rien, et placé autour de la Source key le contenu ne sera plus téléchargeable. Ensuite, il faut que les Sybils s annoncent auprès des autres pairs non corrompus. De cette façon, ils corrompent les tables de routage des pairs et attirent ainsi toutes les requêtes de recherche. Si les Sybils ne répondent pas aux requêtes de recherche, le contenu sera alors inaccessible [32][9]. Il est aussi possible de réaliser une éclipse plus large, de façon à bloquer toute une partie de réseau [32] si les ressources de l attaquant le permettent. La figure 3.1 représente une attaque ou un pair va publier son contenu sur des Sybils, qui peuvent rendre inaccessible ce contenu ou le polluer. Le publishing peer utilise donc les requêtes de routage (routing requests) pour trouver le pair le plus proche du target ID. Les pairs ainsi interrogés lui répondent avec les adresses des pairs les plus proches qu ils connaissent. Ensuite, Le publishing

22 22 CHAPITRE 3. LA SÉCURITÉ DANS KAD Figure 3.1 Attaque Sybils dans KAD : Eclipse [8] peer finit par interroger un attaquant (attacker) situé près du target ID. Enfin, grâce à des réponses corrompues les attaquants vont prendre le contrôle du contenu indexé. Il existe une autre stratégie proposée par [17] pour réaliser une éclipse, celle-ci consiste à placer les Sybils au plus proche du contenu à éclipser, mais à des distances différentes de façon à créer une chaine. Le principe est qu un seul Sybil est annoncé et reçoit les requêtes de recherches. Il répond avec des ID générés toujours plus proches du contenu, de cette façon, la nouvelle Sybil va être contactée et on répète le processus jusqu au timeout du processus de routage. Cette stratégie plus complexe permet de passer outre les mécanismes de protections mis en oeuvre dans les clients de KAD car seule le premier Sybil sera enregistré dans la table de routage. Surveillance : L espionnage du réseau consiste à surveiller et analyser les requêtes de service émises par les pairs pour un contenu donné. Pour ne pas fausser les résultats, il est préférable que la surveillance soit passive. La surveillance peut être effectuée à différents niveaux, ainsi les auteurs de [9] réalisent une surveillance localisée en plaçant leurs Sybils autour des contenus à surveiller. Cette surveillance permet donc de collecter les recherches et les publications des pairs pour un contenu en particulier. Les auteurs de [32] proposent une autre méthode permettant de surveiller les contenus recherchés et publiés dans une zone (1/256ème du réseau KAD). Pour cela, il faut découvrir tous les pairs présents dans la zone, insérer un grand nombre de Sybils (2 16 lors des expérimentations) puis annoncer aux pairs les ID des Sybils (index poisoning). Les Sybils stockeront ensuite toutes les requêtes (recherche, publication, etc) qu elles verront transiter, cette méthode est efficace mais très intrusive et coûteuse en ressources. Dans [27], les auteurs proposent une surveillance à très grande échelle en associant à chaque pair un Sybil. Chaque Sybil est donc placé à coté du pair qu il surveille et capture une copie des requêtes de routage destinées à celui-ci. Les Sybils pour ne pas avoir d influence sur le réseau ce contentent de répondent qu au pair qui leur est associé, ils ne capturent donc pas les requêtes de service. DDoS : Les réseaux P2P permettent de réaliser deux types d attaque DDoS : Une attaque basée sur la multiplication des connexions TCP vers une cible. Pour effectuer cette attaque, on place dans le réseau des sources de fichiers corrompues qui pointent vers la cible à attaquer, les pairs recherchant les contenus pollués vont alors établir une connexion TCP avec la cible et ainsi réaliser l attaque DDoS. Il est possible de contrôler le débit de l attaque en fonction du nombre de clefs corrompues et leurs positions (popularité). Cette attaque peut aussi être réalisée sans la publication de clef corrompue, mais en positionnant des Sybils près des contenus populaires (similaire à l attaque éclipse) qui répondront directement aux demandes de clefs par des clefs corrompues [28].

23 3.1. L ATTAQUE SYBIL 23 Une attaque [28] basée sur la génération d un important trafic (UDP) qui permet de bloquer le réseau de la cible. Cette attaque consiste à empoisonner les tables de routage d un grand nombre de pairs pour y insérer l adresse de la cible. Quand les pairs empoisonnés vont envoyer une requête (message de maintenance, recherche, etc) à la cible, ils vont générer du trafic et donc l attaque DDoS. Attaque sur la publication : Les auteurs de [24] proposent d attaquer directement les plus proches pairs de l ID d un mot clef. Cette attaque repose sur la limitation de taille de la table de mots-clefs (50000 tuples pour chaque ID), ainsi, que sur le nombre d entrée qu une réponse peut contenir (les 300 tuples les plus récents). Il est donc possible de remplacer les informations contenues dans la table en la remplissant d entrées corrompues. Une fois sa table de mots-clefs remplie, le pair attaqué n acceptera plus les requêtes de publication et répondra aux requêtes de recherches avec les 300 dernières entrées corrompues qu il aura reçues. Si cette attaque est réalisée sur tous les pairs proches du mot clef, il est alors impossible de publier un nouveau contenu ou de trouver un contenu lié à ce mot clef. Cependant, une entrée dans la table a une durée de vie limitée (24 heures pour une Keyword key et 5 heures pour une Source key), il est donc nécessaire de réaliser l attaque régulièrement pour garder la table remplie. Il est aussi important de surveiller l arrivée de nouveaux pairs qui pourrait être placés près du mot clef et, le cas échéant, remplir leurs tables. Cette attaque donne de bons résultats : une attaque a été réalisée sur le mot clef simpsons pendant cinq jours et la moyenne de réponses corrompues était de 80%. Cette attaque est cependant très lourde à maintenir et donne de moins bons résultats qu une attaque Sybils Contre-mesures Les développeurs des logiciels clients ont implémenté des contre-mesures décrites dans [7] et protégeant l algorithme de maintenance de la table de routage pour se protéger : Une adresse IP ne peut être associée qu à un seul identifiant. Un bucket ne doit pas contenir plus de deux pairs ayant leurs 24 premiers bits de l adresse IP communs. La table de routage (ensemble des buckets) ne doit pas contenir plus de dix pairs ayant leurs 24 premiers bits d adresse IP en commun. Ces mécanismes de protection ont une portée limitée. En effet, la protection permet de protéger la table de routage mais non le processus de localisation. Ainsi, des chercheurs ont développé [17] un nouveau type d attaque basé sur une chaine de Sybils (présenté dans le paragraphe 3.1.1) et qui permet de surmonter les contre-mesures ou encore, distribuent l attaque au niveau IP [9]. Un autre mécanisme de protection appelé Trust Value a été mis en place dans le logiciel client amule 3. Le Trust Value est un indicateur qui permet de noter la crédibilité d une entrée publiée. La note attribuée sera comprise entre 0 et Avec une note 1 une entrée sera considérée comme corrompue et avec une note 1 l entrée sera considérée comme bonne. L objectif de ce mécanisme est de détecter les pairs publiant un grand nombre d entrées pour un mot clef donné. Les entrées avec une Trustvalue 1 seront retournées en dernier lors des recherches (si la limite de 300 réponses n est pas déjà atteinte). Il est aussi prévu d utiliser cette métrique pour signaler le niveau de corruption d un fichier, mais à l heure actuelle ceci n est pas implémenté 4. Le TrustValue est basée sur le nombre de plages d adresses IP (/24) qui ont publié une même entrée, et le nombre d entrées que ces plages d adresses ont déjà publié, ainsi que sur un nombre de points attribués à chaque plages d adresses. Par exemple : ont attribue à chaque plages d adresses 10 points, de cette façon, si une adresse publie 3 entrées différentes et que personne d autre ne publie ces entrées alors, chacune de ces entrées aura une TrustValue égale à 10/3 = 3.3 (donc considérées comme valable). Si le pair publie amule version Classe Entry.cpp 4. amule version Classe Entry.cpp - ligne 645

24 24 CHAPITRE 3. LA SÉCURITÉ DANS KAD entrées identiques, chacune vaudra 10/12 = 0.8 (ce qui considérera chaque entrée comme corrompue).cependant, si une autre plage d adresses publie la même entrée une seule fois la TrustValue vaudra 10/ /1 = Le TrustValue permet donc de lutter contre certaines formes de pollution (multiplication de sources et de versions), mais plusieurs points restent à améliorer, comme les actions à mener après la détection d un pair pollueur (pour l instant la clef polluée est rarement ignorée). De plus, si une clef est détectée comme corrompue et qu un nouveau pair publie cette clef moins de 10 fois, la clef sera reconsidérée comme non corrompue (ce qui limite grandement la détection de la pollution par multiplication de sources) Solutions Proposées Plusieurs solutions ont été proposées pour résoudre les problèmes liés aux attaques Sybils. Ces solutions se divisent en deux catégories, soit empêcher les pairs de choisir leurs identifiants et donc leurs positions, soit de détecter les Sybils et d empêcher leurs agissements. Les solutions pour empêcher les pairs de choisir leurs identifiants telles que [32], proposent de passer par une solution centralisée (distribution des KAD ID, autorité de certification, etc). Ces solutions sont difficiles à mettre en place et peuvent demander d importantes modifications au niveau de l implémentation de la DHT, de plus elles sont contraires au paradigme P2P (défaillance, coût, etc). Pour la détection des Sybils dans KAD, des protocoles comme SybilGuard [35] ont été proposés. Le principe est de détecter les Sybils grâce aux réseaux sociaux, pour cela, chaque pair est lié à un identifiant d un réseau social. Ainsi, les Sybils pourrons être détectées car elles n auront que très peu de relations avec les humains. Une autre solution pour détecter les Sybils [8] consiste à comparer la distribution concrète des pairs dans KAD par rapport à la distribution théorique, en utilisant la divergence Kullback-Leilbler (l entropie relative). Cette méthode permet de détecter efficacement les pairs artificiellement insérés dans le réseau KAD puis de les ignorer, en ne modifiant que très peu le protocole. 3.2 Pollution L une des difficultés majeures que rencontrent les réseaux P2P actuellement, est le phénomène de pollution (50% des fichiers partagés sur KaZaa en 2005 [23]). La pollution consiste à publier des fichiers corrompus ou ne correspondant pas à leur description, de façon à empêcher le téléchargement (les bons fichiers sont noyés dans la masse), ou encore pour diffuser un contenu malveillant au plus de personnes possibles, et même parfois les deux 5. Il existe plusieurs méthodes pour polluer un réseau, celles-ci peuvent être divisées en deux catégories : La pollution des fichiers et la pollution de l indexation [10]. La différence fondamentale entre ces deux méthodes se situe dans la quantité de ressources nécessaires pour la mise en place. En effet, dans le cas d une pollution de fichier les besoins en terme de bande passante sont immenses (nécessaires à l envoi des fichiers), alors que dans le cas d une pollution d indexation, peu de ressources sont utilisées car seules des messages protocolaires sont envoyés. La pollution a un impact fort sur la qualité d un réseau car elle influe sur le stockage, la bande passante, l utilisation des noeuds, et sur l humain (obligation de vérifier le bon contenu et éventuellement de relancer un nouveau téléchargement). En terme de sécurité, la pollution présente un risque informatique évident de par le partage de vers pouvant constituer des botnets [31]. On a aussi un risque pour la sécurité de l utilisateur qui peut être heurtée par les données corrompues (pornographie, pédophile) html

25 3.2. POLLUTION 25 Type Méthode Mise en oeuvre Conséquence Génération de faux Génération de faux fichiers Illisible, virus, etc... fichiers que l on partage Pollution de Dégradation d un On dégrade un contenu Illisible, qualité très Contenu contenu (bruit, supression d un faible, etc... partie, etc) et on le partage Table 3.1 Tableau récapitulant la pollution de contenu Les auteurs de [20] mettent en avant la relation entre la dynamique de pollution et les comportements des utilisateurs. L étude montre que les utilisateurs ont pour la majorité un comportement non-averti voir naïf qui augmente la pollution. Cependant, l étude met en avant que si certaines bonnes pratiques étaient réalisées par les utilisateurs la pollution serait grandement diminuée. Les utilisateurs ne sont pas les seuls responsables de la pollution, l article [23] identifie la source principale de la pollution comme étant intentionnelle et réalisée par des entreprises spécialisées Pollution des fichiers La pollution des fichiers est la manière la plus générique et la plus simple de polluer un réseau. Elle est parfois réalisée involontairement par les utilisateurs eux même. Les 2 méthodes pour réaliser cette pollution sont résumées par le tableau 3.1, Le principe est de partager : Un fichier différent (ex : virus) ce qui entraine une erreur de téléchargment. Le bon fichier mais corrompu, par exemple en dégradant énormément la qualité ou en le rendant illisible. Pour que les utilisateurs téléchargent ces fichiers corrompus, deux méthodes existent : La multiplication des versions d un contenu pollué ou la multiplication des sources de ce fichier. Les auteurs de [9] réalisent une expérimentation en éclipsant les entrées d un contenu populaire (Spiderman) et en les remplaçant par quatre faux fichiers. Deux fichiers possèdent peu de sources (multiplication des versions), et deux fichiers possèdent un grand nombre de sources (une multiplication des sources). L étude montre que 96% des premières requêtes de téléchargement aboutissent sur les fichiers ayant beaucoup de sources. La différence d efficacité entre ces deux méthodes est principalement due à l ordonnancement des fichiers trouvés lors de l étape de recherche. En effet, les fichiers trouvés sont souvent triés en fonction du nombre de sources, car potentiellement plus populaires. L étude [20] montre également que le nombre de pairs possédant le fichier est l un des critères les plus importants pour les utilisateurs. La multiplication des versions d un fichier n a pas d impact fort. En effet, lors d une recherche les logiciels clients limitent le nombre de résultats à 300 ce qui limite cette pollution. De plus, les fichiers ayant le plus de sources sont sélectionnés en priorité et mis en avant (les fichiers ayant peu de sources étant assimilés une pollution involontaire suite à un changement de nom de fichier [11]). La multiplication des sources est une méthode très efficace car le nombre de tentative de téléchargement est directement lié au nombre de sources annoncé lors d une recherche. L étude [23] a montré que cette méthode de pollution a été utilisée par des entreprises spécialisées pour empêcher le téléchargement de fichiers licenciés dans les réseaux Overnet et Kazaa. Cette méthode est cependant très lourde car elle réclame beaucoup de ressources (bande passante) pour diffuser les nombreux fichiers corrompus. Le tableau 3.2 présente les différentes méthodes d insertion de pollution Pollution de l indexation (index poisoning) La pollution de l indexation (aussi appelé index poisoning ou Metadata pollution) consiste à diffuser la pollution via le mécanisme d indexation du réseau [22]. le tableau 3.3 résume les différents types de pollution d indexation, qui sont dans le cas du réseau KAD : la corruption des clefs,

26 26 CHAPITRE 3. LA SÉCURITÉ DANS KAD Méthode d insertion de pollution de contenu Méthode Mise en oeuvre Conséquence Multiplication Partage de même contenu Pollution efficace et des sources d un sur beaucoup de pairs en générale volontaire contenu Multiplication versions des Création de plusieurs versions d un contenu (renommer, compresser,etc) Pollution peu efficace, parfois involontaire Table 3.2 Tableau récapitulant les moyens de diffusion de la pollution collision du hachage MD4, l insertion d un noeud pollueur. Insertion de Sybils : Une méthode de pollution d indexation consiste à insérer dans le réseau un noeud au plus proche d un mot clef à polluer. Ce noeud va donc recevoir les requêtes de recherche du mot-clef, et pourra alors répondre par une réponse corrompue [9][22]. Les auteurs de [24] ont démontré que seulement trois noeuds pollueurs suffisaient pour avoir 95% de réponses corrompues. Pour cela, chacune des réponses des noeuds pollueurs contient 300 tuples corrompus, ce qui à pour effet d arrêter la recherche du client car le maximum de réponses est trouvé. Collision de hachage : Une autre attaque est basée sur la collision de la fonction de hachage MD4 [34], cette attaque n impacte pas directement le système d indexation mais profite d une faiblesse de celui-ci. Cette attaque consiste à créer un exécutable qui aura le même identifiant qu un autre contenu partagé sur le réseau, de cette manière les utilisateurs téléchargeront l exécutable au lieu du fichier. Cette attaque est très efficace et aucune contre-mesure n a actuellement été mise en place, cependant, cette attaque est techniquement difficile à réaliser ce qui limite son utilisation. Envoi de requêtes corrompues : Une attaque plus poussée consiste à créer un grand nombre de Keyword key corrompues et à les faire pointer vers un même fichier. Cette méthode appelée mélange d indexation [5] permet de polluer rapidement et efficacement beaucoup de mots clefs. On peut par exemple faire pointer toutes les clefs vers un fichier pollueur, ainsi, tous les téléchargements réalisés à partir des mots-clés corrompus aboutiront sur ce fichier. Cette attaque peut aussi être utilisée pour réaliser un déni de service, en modifiant l adresse de la source par une adresse à attaquer (voir DDoS 3.1.1). Il est aussi possible de réaliser un mélange d indexation simplifié (mais moins efficace et plus facilement détectable) en renommant un fichier corrompu avec plusieurs mots-clefs ciblés. Index poisoning : La corruption d une clef (source ou keyword) consiste à modifier une clef pour que sa valeur ou ses métadonnées (IP, port) ne soient plus les bonnes. De cette manière, le téléchargement du fichier ne pourra pas s effectuer, et sera avorté suite à un time-out. Cette pollution est simple à mettre en place car elle demande juste la modification des clefs et l envoi des requêtes de publication Les contre-mesures Pour détecter la pollution, une démarche possible est de télécharger les contenus et de les vérifier automatiquement. Cette démarche est complexe à mettre en place car la pollution diffère en fonction du type de contenu, de plus, l importance de la pollution oblige à télécharger une grande quantité de fichiers. Malgré de bons résultats [23], cette démarche n est pas utilisée en dehors

27 3.2. POLLUTION 27 impos- Type Méthode Mise en oeuvre Conséquence Source Key La clef possède une valeur corrompu Téléchargement sible (timeout) Keyword Key Corruption Mélange des clefs d indexation Pollution de l index Modification de la valeur d une keyword-key pour pointer vers une sourcekey Beaucoup de mots clefs peuvent être associés à une seule source-key Attaque ciblée Un noeud est placé pour être responsable d un mot clef. Il répond ensuite avec des réponses corrompues Table 3.3 Tableau récapitulant la pollution d index Titre du fichier On renomme un fichier Fichier non correspondant Collision de hachage Collision de hachage MD4 Deux fichiers peuvent avoir le même ID. Il est alors possible de télécharger un fichier corrompu Téléchargement impossible (mot clef introuvable, timeout, etc...) d études académiques car la détection est trop tardive pour être utile au pair courant. Une autre démarche consiste à supposer qu un fichier est pollué ou non. Pour cela il existe beaucoup de solutions : Par vote : Ce système consiste à faire partager son expérience auprès d autres pairs. Pour cela un système de vote est mis en place, le vote permet de noter des contenus. La faiblesse de ce genre de système est qu il peut très vite être faussé (erreur, vote malveillant), et le mélange d indexation peut rendre un fichier bon pour certain et pollué pour d autre. De plus certaines études [23] ont montré que les utilisateurs n étaient pas sensibilisés à ce mécanisme et ne l utilisaient pas. Par filtrage : Cette méthode est issue de l analyse de la pollution de contenu. Constatant qu un petit nombre d adresses IP annonce la majorité des versions et des sources disponibles. Il est donc possible de découvrir ces IP puis de les mettre sur liste noire. Cette méthode donne de bons résultats, mais nécessite une phase d exploration très lourde et ne détecte pas les mélanges d indexation [23]. Le papier [21] propose une méthode de filtrage intéressante et qui se base sur plusieurs métriques (nom du fichier, type de fichier, adresse du pair, etc) et qui met en liste noire les pairs détectés comme pollueurs. Cette méthode semble plus complète et plus efficace que celle proposée dans l article [23], mais souffre des mêmes limitations : elle nécessite aussi une lourde phase d exploration centralisée et la diffusion d une liste noire par un tiers de confiance qui est peu adaptée au P2P. Par réputation : Cette méthode permet d attribuer une réputation à un pair ou à un contenu, la réputation peut être basée sur plusieurs métriques. L article [12] présente une méthode de détection basée sur la réputation d un pair ou d un contenu. Les auteurs proposent un système de réputation distribué et décentralisé nommé Scrubber qui identifie et punit les pollueurs. Pour construire la réputation Scrubber se base sur l expérience individuelle, cette expérience est propre à chaque pair et contient son expérience avec d autres pairs. L expérience qu un pair A a d un pair B évolue en fonction du nombre de fichiers que A a téléchargé depuis B et si ceux ci sont pollués. Ce système semble efficace car 25% des pairs détectés comme pollueurs suppriment leurs fichiers pollués. Il existe cependant d importantes limites car les

28 28 CHAPITRE 3. LA SÉCURITÉ DANS KAD pairs peuvent fausser leurs expériences. Cette falsification peut se faire volontairement dans le cas de pair pollueur et involontairement dans le cas de mélange d indexation ou tout simplement d erreur. De plus, la probabilité de rencontrer deux fois le même pair dans un grand réseau P2P est très faible : problème des mécanismes de réputation locaux. Par nom : Il est aussi possible de détecter le mélange d indexation en fonction du nom des fichiers. L article [25] propose de détecter les fakes (faux fichiers) en comparant la distance entre chaque mot contenu dans le titre d un fichier. Ainsi, plus un titre contiendra des mots distants, plus son indice de pollution sera élevé et si l indice dépasse une limite, le fichier sera considéré comme pollué. Cette méthode semble efficace mais reste incomplète. En effet, le nombre de sources par nom de fichier distinct ou encore les mots-clés souhaités par utilisateur ne sont pas considérés. Une méthode similaire a été développée dans [19] dans le but d analyser les requêtes de recherches des utilisateurs. Cette méthode ne permet pas de détecter les fichiers pollués mais permet de repérer les utilisateurs intéressés par certains contenus illégaux (pédophiles). Chacune des contre-mesures présentées permet de lutter contre un ou plusieurs types de pollution, mais il n existe pas actuellement de solution générique au problème de pollution. Certaines méthodes comme Winnowing [18] proposent d utiliser en parallèle plusieurs contre-mesures ainsi, chaque contre-mesure contrecarre un type de pollution précis. L inconvénient de multiplier les contre-mesures est le coût en terme de messages, et les problèmes liés à la rétro-compatibilité des clients ainsi modifiés. Conclusion Nous avons présenté dans ce chapitre les différents modèles P2P, mis en avant leurs forces et leurs faiblesses, tout en nous intéressant à la sécurité des contenus sur ces réseaux. Nous nous sommes particulièrement attachés à présenter la DHT Kademlia sur laquelle repose le réseau de partage KAD et sur les faiblesses de celui-ci. Il apparait que peu d études ont été menées dans le domaine de la pollution et qu aucune n a été réalisée sur le réseau KAD. De surcroît, les solutions de détection de la pollution actuellement proposées par la communauté scientifique ne sont pas utilisées par les logiciels clients. Le manque d intérêt pour les solutions scientifiques par les développeurs s explique de surcroit par les limites des solutions, et profondes modifications que celles-ci engendrent ainsi que les problèmes de rétro-compatibilité. Dans la suite de ce rapport, nous étudierons et quantifierons les types de pollutions actuellement présents dans le réseau KAD. Cette étude est nécessaire car l étude la plus récente actuellement réalisée date de 2005 et a été réalisée sur le réseau Kazaa [23]. Nous mettrons en avant un nouveau phénomène majeur de pollution que nous appellerons falsification d index et nous étudierons son impact dans le réseau. Nous travaillerons ensuite sur la caractérisation des pollueurs de façon à mettre en avant leurs manières de diffuser la pollution.

29 Deuxième partie Contributions 29

30

31 Chapitre 4 Détection et quantification de la pollution 4.1 Détection de la pollution dans la DHT KAD Comme nous l avons vu dans le chapitre 3, la pollution dans les réseaux P2P est un domaine très vaste et les formes de pollution sont nombreuses. Devant l impossibilité d étudier et de détecter toutes les formes de pollution nous proposons de concentrer notre étude sur une nouvelle forme de pollution, à savoir : la falsification d index. Tous d abord, nous présentons en détail le fonctionnement de cette pollution ainsi que les moyens possibles de mise en oeuvre. Ensuite, nous proposons une méthode de détection basée sur une métrique de similarité et nous quantifions grâce à celle-ci la pollution dans le réseau KAD Introduction Durant ce stage nous avons découvert et investigué une nouvelle forme de pollution largement répandue dans le réseau KAD, la falsification d index. La falsification d index consiste à publier un même fichier avec différents noms. Ainsi, le fichier est indexé avec des mots-clefs qui n ont rien à voir avec son contenu. De surcroît, le pollueur annonce ce fichier un grand nombre de fois pour chaque nom, ce qui a pour conséquence d augmenter le nombre de sources annoncées pour ce fichier et de le rendre populaire. La figure 4.1 présente le mécanisme normal de publication de KAD (en noir) ainsi que les mécanismes de la falsification d indexation (en rouge). Dans ce schéma, un pair malveillant va indexer un fichier Matrix sous les noms Matrix, Avatar et Toto. Ainsi, les pairs voulant télécharger Toto ou Avatar téléchargeront en réalité le fichier Matrix. Cette forme de pollution est plus dangereuse que l empoisonnement d index qui empêche seulement l initialisation du téléchargement. Ici, la recherche du fichier et le téléchargement aboutissent mais pas sur le bon fichier. On a donc une perte de temps, de ressources réseaux, et un risque pour l utilisateur. Le contenu réel du fichier téléchargé peut être de n importe quel type, mais semble généralement être des virus, ou des fichiers pouvant heurter la sensibilité de l utilisateur : fichiers à caractère pornographique ou pédophile. De plus, cette pollution crée de nombreux faux positifs dans la surveillance des téléchargements illégaux. Par exemple, un utilisateur souhaitant télécharger un contenu libre de droit tel que le système d exploitation Ubuntu (licence GPL) pourra se retrouver avec un fichier soumis à une licence payante. La figure 4.2 est une capture réalisée suite au téléchargement du fichier Ubuntu Server 10.0.iso et dont le fichier téléchargé est aussi indexé avec des contenus licenciés et donc illégaux

32 32 CHAPITRE 4. DÉTECTION ET QUANTIFICATION DE LA POLLUTION Figure 4.1 Mécanisme de publication et de falsification Figure 4.2 Autres Noms de fichiers associés à un fichier téléchargé en tant qu Ubuntu La stratégie de détection de la falsification d index Le principe de la falsification d index est d indexer un fichier avec différents noms. Pour détecter cette pollution, nous nous sommes attachés à récupérer et analyser tous les noms avec lesquels un fichier est partagé. Le fonctionnement en double indexation de KAD (paragraphe 2.2.5) rend cependant la détection de cette pollution plus difficile. Le premier niveau d indexation correspond aux pairs responsables d un mot clef. Ces pairs connaissent donc seulement les noms du fichier correspondant à ce mot clef. Le tableau 4.1 montre les noms que connaît un pair responsable du mot clef Avatar pour le fichier Avatar.DVDrip.AC3.ita.Mp3.eng.parte.2.by.Memphis.avi. Il apparaît clairement qu il n est pas possible de détecter la pollution à ce niveau d indexation car la connaissance des différents noms possédant le même mot clef n est pas assez discriminante pour détecter la pollution. Les pairs responsables du deuxième niveau d indexation possèdent la connaissance du hash du fichier ainsi que de l adresse des pairs le partageant. A ce niveau, le nom du fichier n est pas publié, seules les informations concernant les sources le sont. Il est donc impossible de détecter la falsification d index. Une recherche sur la DHT ne permet donc pas de découvrir la totalité des noms avec lesquels est indexé un fichier. Il est cependant possible de trouver ces différents noms lors de la phase de téléchargement. En effet, le système de partage de KAD étant multi source, lors de l initialisation

33 4.1. DÉTECTION DE LA POLLUTION DANS LA DHT KAD 33 Mot clef dont le pair est responsable : Avatar Nom le plus annoncé : Avatar.DVDrip.AC3.ita.Mp3.eng.parte.2.by.Memphis.avi FileID : G638DEA37E0CEF44585CD3B90B9D3GG5 Différents noms annoncés nb sources Avatar CD2.avi 3 Avatar (Cameron, 2009) cd2.avi 1 Avatar.DVDrip.AC3.ita.Mp3.eng.parte.2.by.Memphis.avi 30 Avatar.DVDRip.iTALiAN.AC3.ENGLiSH.Mp3.XviD-by.Memphis.CD2.avi 1 Avatar parte 2.avi 1 Avatar CD2.avi 1 Avatar.cd2.avi 1 Table 4.1 Exemple de différents noms annoncés pour un fichier au premier niveau d indexation d un téléchargement les pairs possédant et partageant le fichier désiré sont détectés pour pouvoir servir d éventuelles sources KADMELIA2 SEARCH SOURCE REQ. Ensuite, une connexion TCP est initialisée avec chacune des sources potentielles pour demander l initialisation du téléchargement. Une fonction implémentée dans les clients KAD permet alors de récupérer des informations détaillées quant au fichier téléchargé, comme par exemple le nom du fichier sous lequel cette source le partage. Grâce à ces informations, des noms contradictoires peuvent apparaître entre les différentes sources et ainsi permettre de détecter la falsification d index. Il est important de noter que la récupération de ces informations est externe au mécanisme de la DHT KADEMLIA et est donc propre aux clients KAD. La capture d écran 4.3 montre un cas où les noms annoncés par les sources laisse supposer que le fichier est sain, car une majorité de sources s accorde sur le même nom. La capture 4.4 montre un cas significatif de mélange d indexation car aucun des noms annoncés ne correspond au fichier demandé. De plus, les noms annoncés ne s accordent pas non plus entre eux et ne possèdent pas de mot en commun Métrique de similarité pour la détection de la pollution Pour un fichier (identifié par le hash de ses données), nous avons pour objectif de déterminer si celui-ci est soumis à une falsification d indexation. Pour cela, nous avons analysé les différents noms renvoyés par les sources grâce à une métrique de similarité 2 capable de déterminer la distance entre deux ensembles de mots. Le coefficient de similarité le plus commun dans la littérature est l index de Jaccard [29], qui définit la similarité comme l intersection de deux ensembles de mots (X et Y) divisés par leurs unions (équation 1). J(X, Y ) = X Y X Y (4.1) L index de similarité de Tversky est une version étendue de l indice de Jaccard. Sa valeur est comprise entre 0 et 1 ce qui est une propriété intéressante pour permettre une notation. L index de Tversky est défini par la formule : T (X, Y ) = X Y X Y + α X Y + β Y X (4.2) Pour notre détection, nous considérons que X est l ensemble des mots composant le nom du fichier choisi par l utilisateur et Y l ensemble des mots composant un nom donné par une des sources. Ainsi, pour le cas où 2 noms sont complètement différents, le résultat de l index sera 0. De même, si 2 fichiers ont des noms identiques, la valeur de l index sera homepages.cwi.nl/~paulv/papers/similarity.pdf

34 34 CHAPITRE 4. DÉTECTION ET QUANTIFICATION DE LA POLLUTION Pour déterminer l indice de pollution P d un fichier dont le titre est X, nous calculons la moyenne de l ensemble des indices de similarité (un indice par source Y i ayant communiqué son nom de fichier) et inverserons le résultat pour ne plus avoir un indice de similarité mais bien un indice de pollution. n i=1 P (X) = 1 T (X, Y i) n (4.3) Figure 4.3 Noms de fichiers annoncés pour un fichier sain

35 4.1. DÉTECTION DE LA POLLUTION DANS LA DHT KAD 35 Figure 4.4 Noms de fichiers annoncés pour un fichier corrompu

36 36 CHAPITRE 4. DÉTECTION ET QUANTIFICATION DE LA POLLUTION 4.2 Quantification de la pollution dans KAD Collecte des données sur les contenus partagés De par le nombre de contenus partagés ainsi que la forte instabilité des noeuds, il est impossible d investiguer tous les fichiers partagés dans le réseau P2P KAD. De plus, la collecte d informations détaillées, comme par exemple le nom avec lequel une source partage un fichier, est très couteuse car elle nécessite de : Trouver les fichiers que l on veut télécharger KADEMLIA2 SEARCH KEY REQ Trouver les sources potentielles du fichier sélectionné KADEMLIA2 SEARCH SOURCE REQ Établir les connexions aux sources concrètes (ouverture d une connexion TCP par source découverte). Du fait de ces contraintes, nous avons décidé de quantifier la pollution en nous basant sur un échantillon significatif. Pour établir l échantillon, nous avons choisi d utiliser le TOP 100 (annexe 7.1) des fichiers téléchargés en 2010 selon l un des principaux sites d indexation Bittorent 3, qui reçoit plus de cent millions de recherches par an. Pour avoir un échantillon encore plus représentatif, nous avons collecté pour chaque entrée du TOP 100, les 20 fichiers avec le plus de sources annoncées. Nous avions ainsi une base de 2000 fichiers à investiguer. Le choix d étudier les fichiers avec le plus grand nombre de sources repose sur des études ultérieures [9] et [20] qui ont montré que le nombre de sources estimées pour un fichier est directement lié au nombre de requêtes de téléchargement et donc d utilisateurs qui vont y être confrontés. Cette expérience à été réalisée avec un client amule placé dans la DHT et instrumenté pour initier le téléchargement des 20 fichiers les plus populaires de chaque entrée du TOP 100. La collecte d information a été réalisée par groupe de 20 fichiers pour éviter de surcharger la bande passante. Configuration de l expérimentation La première phase lors du téléchargement d un fichier est la phase de recherche des sources réelles (phase de bootstrap). La durée de cette phase varie en fonction du nombre de sources et de la disponibilité de celles-ci. Avant de lancer notre expérience sur nos 2000 fichiers, nous souhaitons estimer la durée moyenne à attendre avant de pouvoir récupérer les noms partagés par les sources. Nous avons donc étudié un échantillon de 150 fichiers populaires (Pour les 15 premières entrées du TOP 100, nous avons téléchargé les 10 fichiers avec le plus de sources) et mesuré l évolution du nombre de sources pendant la première heure. La figure 4.5 montre la moyenne de l évolution du nombre de sources pour les 150 fichiers. Pour la figure 4.5, nous avons limité l échelle du temps à 600 secondes car au delà, l évolution était nulle. Il apparaît qu après 300 secondes d attente, le nombre de sources trouvées est en moyenne de 97%, ce qui permet d optimiser le temps d attente avant la collecte d information. Ce temps est également un indice sur les performances offertes par notre approche dans le cas d une détection en temps réel. Pour réaliser la collecte des noms de fichiers, nous avons instrumenté un client KAD pour qu il : récupère une entrée du TOP 100 ; recherche cette entrée sur le réseau KAD ; initie le téléchargement des 20 fichiers les plus populaires ; attende 5 minutes (300 secondes) puis, récupère les noms avec lesquels le fichier est partagé ; recommence avec la prochaine entrée du TOP 100. Durant cette expérience, il s écoule environ 10 heures entre le premier et le dernier téléchargement. Cette durée n influe cependant pas sur la validité des noms récupérés car les fichiers téléchargés ne sont pas comparés entre eux. 3.

37 4.2. QUANTIFICATION DE LA POLLUTION DANS KAD 37 Figure 4.5 Nombre moyen de sources réelles trouvées en fonction du temps Validation de la métrique Comme nous l avons vu au paragraphe 4.1.3, notre métrique de détection de pollution donne un résultat entre 0 et 1. Pour déterminer le statut d un fichier, il est donc nécessaire de faire apparaître un seuillage. De plus, notre métrique sera forcément sujette aux erreurs : des fichiers non pollués peuvent être considérés comme pollué (faux positifs) et à l inverse des fichiers pollués peuvent être considérés non pollués (faux négatifs). Afin de déterminer le meilleur seuillage et d estimer le taux d erreur, nous avons demandé à des experts d évaluer un échantillon (20%) des fichiers que nous avions collecté. Nous avons eu recours à des experts hautement spécialisés dans la sécurité informatique et possédant une grande culture des réseaux de partage (liste des experts ayant acceptés d être cités en annexe 7.2). Cependant, de par les grandes différences entre les noms des sources, l évaluation des fichiers était naturelle voir triviale pour un grand nombre de personnes. Pour permettre aux experts d évaluer la métrique, nous avons mis en place une interface Web permettant aux experts de noter les fichiers. L interface affiche les fichiers et les noms des sources issues de l échantillon de façon aléatoire, ainsi l ordre des fichiers affichés n influait pas sur le vote. Nous avons aussi fait en sorte qu un expert n ait pas à noter la totalité de l échantillon pour que son vote soit pris en compte. Cela permettait aux experts disposant de peu de temps de pouvoir tout de même participer. Trois réponses était proposées pour l évaluation d un fichier : pollué, non-pollué ou indéfini. La figure 4.6 est une capture d écran de l interface de vote que nous avons mise en place. En nous basant sur leurs réponses, nous avons analysé les taux de faux positifs et négatifs en fonction des différentes valeurs de α et β définit précédemment dans l équation 4.2. Comme le présente le tableau 4.2, Il apparaît que le choix de prendre les valeurs α = β = 0.5, permet d avoir le meilleure compromis entre les taux d erreur et le taux d incertitude (représantant le nombre de fichiers pour lesquels la métrique ne peut pas déterminer le statut). De plus, le choix de prendre α = β se justifie par l observation qu aucun des deux noms ne peut être privilégié. En effet, il y a autant de chance que le titre du fichier téléchargé soit faux que le titre de la source soit faux, il n est donc pas possible de choisir l un ou l autre comme un référence. Ce cas particulier produit le coefficient de similarité de Dice[13] définit par : D(X, Y ) = 2 X Y X + Y (4.4)

38 38 CHAPITRE 4. DÉTECTION ET QUANTIFICATION DE LA POLLUTION Figure 4.6 Interface web pour le vote des experts Nous avons également défini que le meilleur seuillage était de considérer les fichiers avec une note inférieure à 0.3 comme non pollués et les fichiers avec une note supérieure à 0.7 comme pollués. En effet, les tableaux 4.3 et 4.4 montrent que ces valeurs permettent d avoir le meilleur rapport (taux d erreurs / taux de fichiers notés). Pour les fichiers entre ces 2 bornes, nous considérons que la métrique ne peut pas déterminer avec fiabilité leur état et sont donc marqués comme inconnus. La figure 4.7 et la figure 4.8 présentent respectivement la distribution et la distribution cumulative des sources en fonction de la valeur attribuée par notre métrique. Il apparaît que nous avons une distribution bimodale avec un pic à 0.1 et un autre à 0.9. Notre métrique permet donc d avoir naturellement deux grandes classes pour classifier les données analysées. Le tableau 4.5 montre que ce seuillage permet à notre métrique (coefficient de Dice) d avoir des taux d erreur très faibles. Le tableau compare aussi ces taux d erreur avec une autre métrique de similarité connue, l index de Jaccard (α = β = 1) qui présente un taux d erreurs plus grand. Nous avons étudié plus en détail les faux positifs de notre métrique et découvert qu ils étaient principalement dûs à des films possédant un titre original et un titre traduit. Par exemple, nous avons investigué le fichier El signo Nero Sub Ita.avi et la majorité des noms renvoyés par les sources étaient Black.Swan.2010.DVDSCR.XviD-TiMKY.avi. Du point de vue de notre métrique, ces deux noms sont totalement différents et le fichier est considéré comme pollué. Seule une connaissance de la sémantique des mots traduits ou encore une connaissance des noms localisés des films, permettrait d éviter ces erreurs et d avoir un jugement aussi fiable que celui des experts.

39 4.2. QUANTIFICATION DE LA POLLUTION DANS KAD 39 Taux d erreurs α = 0.1 β = 0.9 α = 0.2 β = 0.8 α = 0.3 β = 0.7 α = 0.4 β = 0.6 Faux positif % Faux négatif % Taux d incertitude Taux d erreurs α = 0.5 β = 0.5 α = 0.6 β = 0.4 α = 0.7 β = 0.3 α = 0.8 β = 0.2 Faux positif % Faux négatif % Taux d incertitude Taux d erreurs α = 0.9 β = 0.1 α = 1.0 β = 0.0 Faux positif % Faux négatif % Taux d incertitude Table 4.2 Taux d erreurs pour les différentes valeurs de α et β seuil de métrique taux d erreurs (%) taux fichiers notés (%) Table 4.3 Taux d erreurs pour la borne des fichiers pollués seuil de métrique taux d erreurs (%) taux fichiers notés (%) Table 4.4 Taux d erreurs pour la borne des fichiers sains Quantification finale et caractérisation de la pollution dans KAD Pour quantifier la falsification d index, nous avons appliqué notre métrique sur l ensemble des fichiers que nous avons collectés. Le schéma 4.9 représente la répartition de la pollution selon notre métrique. Il apparaît que le mélange d indexation est une forme de pollution majeure avec 41% des fichiers populaires de KAD corrompus. De surcroit, pour 21% des fichiers étudiés, il n a pas été possible d initialiser une seule connexion TCP et ce, malgré un grand nombre de sources potentielles annoncées. Ce comportement est significatif d une attaque par empoisonnement d index (index poisoning). On a donc seulement 29% de fichiers considérés comme sains, et moins de 10% de fichiers dont la métrique doute. Nous avons aussi analysé le taux de pollution pour chaque entrée du TOP 100 afin de distinguer les contenus. pour cela nous avons attribué une note sur vingt représentant le nombre de fichiers sains parmi les vingt téléchargés. Il apparaît que l entrée la moins polluée est The Big Bang Theory avec 15 fichiers non pollués sur 20, et l entrée la plus polluée est Avatar avec aucun des 20 fichiers non pollués. Il est important de noter que les fichiers soumis à des droits d auteurs ne sont pas les seuls à subir le mélange d indexation. Ainsi, en utilisant le mot-clef Ubuntu 4 (présenté dans 4.1), 15 des des 20 fichiers les plus populaires sont pollués. Pour caractériser plus finement le mélange d indexation, nous analysons les noms de sources et 4.

40 40 CHAPITRE 4. DÉTECTION ET QUANTIFICATION DE LA POLLUTION Figure 4.7 Distribution cumulative du nombre de fichiers en fonction de l indice de pollution obtenu Figure 4.8 Distribution du nombre de fichiers en fonction de l indice de pollution obtenu cherchons les cas où, au moins un nom fait référence à un contenu de type pornographique ou pédopornographique. Pour cela, en nous basant sur les travaux de [19] nous générons une liste contenant des mots clefs clairement identifiés comme pédopornographique, ainsi qu une liste contenant des mots clefs à caractère pornographique en nous basant sur la liste du logiciel de contrôle parental ProCon 5. Les résultats sont présentés sur le tableau 4.6. Il apparaît que plus de la moitié (55%) des fichiers soumis à la falsification d index sont potentiellement pornographiques, mais aussi que 8.8% des fichiers sont probablement pédopornographiques. Ces chiffres sont alarmants car la popularité des fichiers téléchargés et la vaste diffusion de ceux ci fait que le risque pour un utilisateur de télécharger un de ces fichiers illégaux sans en avoir conscience est très élevé. Au vue de ces résutats il semble que ce phénomène de pollution serve en premier lieu à empêcher les téléchargements des fichiers en initialisant le téléchargement d un autre fichier à la place (généralement pornographique) dans le but de décourager l utilisateur. Il est aussi possible que dans certain cas cette forme de pollution serve à diffuser un contenu dangereux (virus, pedopornographie) au plus grand nombre et de façon pernicieuse. 5.

41 4.2. QUANTIFICATION DE LA POLLUTION DANS KAD 41 Métrique de similatitée Faux positif (%) Faux négatif (%) Coefficient de Dice Coefficient de Jaccard Table 4.5 Taux d erreurs calculés grâce aux votes de experts Contenu quantification (%) Pédopornographie 8,8% Pornographie 55,7% Autre 35,3% Table 4.6 Types de contenus liés à la falsification d index Figure 4.9 Quantification de la pollution des contenus dans le réseau P2P KAD Conclusion Dans ce chapitre, nous avons identifié une nouvelle forme de pollution : la falsification d index. L étude de cette pollution sur un échantillon de 2000 fichiers nous a permis de mettre en avant son importance au sein du réseau KAD (41% de fichiers pollués) ainsi, que sa dangerosité (8.8% de fichiers indexés avec des titres pédopornographiques et 55.7% avec des titres pornographiques). En nous basant sur une métrique de similarité (coefficient de Dice) pour analyser les différents noms indexants un fichier, nous proposons un système de détection avec une grande fiabilité et validé par une expertise humaine. Notre solution est cependant réalisée tardivement (lors du début d un téléchargement). Pour pouvoir améliorer notre détection et la réaliser plus tôt, la prochaine étape est d étudier la pollution en amont, c est a dire étudier la diffusion de la pollution dans les réseaux P2P et comprendre les comportements des pollueurs.

42 42 CHAPITRE 4. DÉTECTION ET QUANTIFICATION DE LA POLLUTION

43 Chapitre 5 Étude de la diffusion de la pollution Nous cherchons à définir par quels moyens la pollution est diffusée. Pour cela, il est nécessaire d avoir une vision précise des échanges réalisés et donc de superviser l activité de publication du réseau KAD. Cependant, le réseau KAD présente de nombreuses difficultés en terme de supervision (complètement distribué, forte instabilité des noeuds, etc). Nous avons eu recours à une solution de supervision performante et permettant de récupérer des informations précises sur KAD (les informations liées à la publication). À la suite de cette supervision, nous avons définit une nouvelle méthode de détection et l avons validé grâce à notre précédente étude. Pour finir, nous reproduisons la falsification d index pour montrer la faisabilité de cette attaque ainsi que l importance des faiblesses du protocole de publication de KAD. 5.1 Supervision des mots-clefs pollués Architecture de supervision De part nos besoins, il est nécessaire de mettre en place une supervision qui s oriente autour d un mot-clé et de cette manière, permette d avoir une vue de toutes les publications de fichiers liées à celui-ci. En effet, une supervision limitée à un fichier serait trop ciblée et ne permet pas de mettre en avant des comportements malveillants car la pollution est diffusée au niveau des mots clefs. De plus, une supervision globale et précise du réseau est impossible de part la taille de celui-ci et la quantité d informations à traiter. Une méthode supervision possible est celle proposée dans [27]. Cette solution propose de positionner une sonde auprès de chaque pair à surveiller, la proximité entre eux permettant de recevoir théoriquement les mêmes informations. L avantage de cette méthode de supervision est qu elle peut se faire de manière totalement transparente. Cependant, de par son architecture (une sonde par noeud) et la nécessité de découvrir tous les pairs avant de pouvoir être mise en place, cette méthode ne semble pas adaptée pour surveiller avec précision un contenu du réseau, comme par exemple un mot-clef dont l indexation est distribuée sur des dizaines de pairs dynamiques. Nous avons décidé d utiliser l approche HAMACK (Honeynet Architecture for Monitoring content ACcess in KAD), présentée dans [9] et [4]. HAMACK propose d utiliser des Sybils généralement utilisés dans le cadre d attaques (présenté dans le paragraphe 3.1), comme sondes (appelée Honeypeers) permettant une supervision avancée des contenus associés à un mot clef. Du point de vue de l architecture, les Honeypeers sont simplement placés à proximité du mot clef à surveiller de façon à recevoir les requêtes de services (publication, recherche, etc) liés à celui-ci. La figure 5.1 présente l architecture et les composants du système HAMACK et la figure 3.1 les échanges de message permettant la supervision. 43

44 44 CHAPITRE 5. ÉTUDE DE LA DIFFUSION DE LA POLLUTION Figure 5.1 Architecture du réseau HAMACK [4] La solution HAMACK possède différentes fonctionnalités allant de la supervision passive à l utilisation des Honeypeers pour réaliser des attaques telles que l éclipse de contenus, la falsification d index à la source, ou encore l insertion de honeypots. Dans le cadre de notre travail, nous nous intéresserons seulement à la supervision passive permettant de collecter les messages des pollueurs. La supervision est dite passive car les Honeypeers agissent sur le réseau de la même manière que des pairs standards, toutefois les informations des requêtes de services reçues par les Honeypeers sont sauvegardées dans une base de données relationnelle pour un traitement ultérieur. De cette façon, le système n influence pas le comportement du réseau et l impact est invisible pour les utilisateurs. Les informations suivantes sont capturées lors de la réception d une requête de publication de mot-clef : La date (minute, heure, jour, mois, année) Adresse IP de l émetteur Port de l émetteur Identifiant du mot-clé Liste des fichiers publiés associés, avec pour chacun d eux : Nom complet Taille Hash Nous avons également modifié le système HAMACK pour qu il enregistre le nombre de sources annoncées pour chaque fichier publié mot-clefs supervisés De part l impossibilité de surveiller tous les mots clefs existants, nous avons choisi de découvrir les comportements des pollueurs à travers la supervision autour d une dizaine de mots clefs. Les mots clefs furent choisis en nous basant sur les résultats de notre précédente étude (partie 4.2), qui avait souligné leurs hauts niveaux de pollution. Les mots clefs surveillés et leurs hash sont les suivants : iron : 9A55301A4C668C2CC5FE59B81BB270A3 avatar : C0F70911A9C2E6F6960DDED0D twilight : 4D62D26BB2A686195DA7078D3720F60A axxo : 0C64F68E40DCD6087E44BCA23480E458 robin : B9DF47E5BFAD75F8EE5E3F50EA prince : B3E FD36E80228CC D