Fonctionnalités d'HAMACK

Nous avons validé le fait qu'insérer des sondes à proximité d'une référence de la DHT per-mettait d'attirer toutes les requêtes de service à son intention. Nous allons maintenant décrire les diérentes fonctionnalités que permet ce contrôle de la DHT avec pour objectif la supervision des accès aux contenus illégaux. Ces fonctionnalités sont :

 Supervision passive : supervise les requêtes de publication et de recherche pour des mots-clés ou chiers ;

 Éclipse de références : retire les informations concernant des mots-clés ou des chiers du moteur de recherche ;

 Annonce d'appâts : remplace les chiers attachés à un mot-clé par de fausses références achant de nombreuses sources ;

 Insertion de honeypots : remplace les pairs partageant un chier par nos honeypots. 5.2.1 Supervision passive

La fonctionnalité la plus immédiate et discrète permise par notre architecture est la super-vision passive de toutes les requêtes de service émises par les pairs à destination de la référence ciblée. Les Honeypeers enregistrent ainsi les informations des requêtes reçues puis les traitent nor-malement. Ce comportement est le moins intrusif pour le réseau car les services ne sont impactés en aucune manière par l'architecture de supervision dans le traitement des requêtes interceptées.

Plus précisément, lorsqu'une requête de publication de mot-clé (KADEMLIA2_PUBLISH_KEY_REQ) est capturée, un Honeypeer enregistre les informations suivantes contenues dans celle-ci :

 adresse IP de l'émetteur ;  port de l'émetteur ;  identiant du mot-clé ;

 liste des chiers publiés associés, avec pour chacun d'eux :  identiant du chier ;

 liste d'étiquettes décrivant les propriétés du chier (nom complet, taille) ;

Lorsqu'une requête de publication de chier (KADEMLIA2_PUBLISH_SOURCE_REQ) est capturée, un Honeypeer enregistre les informations suivantes :

 adresse IP de l'émetteur ;  port de l'émetteur ;

 identiant du chier publié ;  identiant de la source15

 adresse IP anonymisée de la source ;  port de la source ;

Les sondes capturent également les requêtes de recherche de mot-clé KADEMLIA2_SEARCH_KEY_REQ) et de chier KADEMLIA2_SEARCH_SRC_REQ), celles-ci comportent moins d'informations, typique-ment les paramètres de l'émetteur et l'identiant recherché. Cette fonctionnalité de supervision passive nous permet de connaître précisément l'activité du mot-clé ou du chier étudié. Nous pouvons par exemple découvrir :

 Quels pairs partagent un chier donné ?

 Quels pairs souhaitent télécharger un chier donné ?  Quels sont les nouveaux chiers publiés pour un mot-clé ?  Quels pairs cherchent des contenus relatifs à un mot-clé ? 5.2.2 Éclipse de références

La seconde fonctionnalité permet d'éclipser facilement des contenus du réseau. Pour éclipser un mot-clé ou un chier, les clients exécutant les Honeypeers modient la procédure de traitement des requêtes.

Tout d'abord, il est nécessaire de contourner deux contraintes aectant la capacité d'index-ation d'un client. La première dénit un nombre maximum de références que peut indexer un pair an de ne pas donner trop de poids à un unique pair dans la DHT. La seconde dénit le nombre maximum de références enregistrées pour un identiant particulier an que les contenus populaires (par exemple, le mot-clé the ) ne soient pas sur-référencés sur un même pair. Si ces limites sont atteintes, le client refuse le service d'indexation et le demandeur doit alors con-tacter d'autres pairs pouvant ne pas appartenir à notre architecture. Une fois ces contraintes supprimées, les Honeypeers sont en mesure d'acquitter toute demande de publication, quelque soit la popularité des références ciblées.

Comme les Honeypeers attirent la quasi-totalité des requêtes de publication et arment prendre en charge l'indexation de la référence ciblée, il leur sut ensuite de nier les requêtes de recherche s'y rapportant pour éclipser le contenu du réseau. De ce fait le contenu, bien que partagé et publié par les pairs, restera inaccessible par le moteur de recherche basé sur la DHT. Les échanges de messages sont décrits par le schéma 5.2. Cette fonctionnalité est intéressante car elle permet de faire disparaître les références malveillantes du réseau, et ce faisant, d'une part

15. l'émetteur et la source annoncée peuvent diérer quand l'émetteur ne peut recevoir les requêtes entrantes et doit passer par un intermédiaire

Figure 5.2  HAMACK éclipsant les résultats d'un mot-clé

Figure 5.3  HAMACK falsiant les résultats d'un mot-clé pour promouvoir les honeypots

d'en protéger les utilisateurs en évitant leur accès, et d'autre part d'éviter leur concurrence avec les appâts du honeypot.

5.2.3 Annonce de chiers appâts et honeypots terminaux

Pour qu'un honeypot P2P soit performant, les chiers annoncés doivent éviter toute con-currence et sembler attractifs en présentant un grand nombre de sources. En eet, le nombre de sources pour un contenu donné est une information essentielle permettant à un utilisateur de trier les résultats d'une recherche. Les chiers présentant un nombre de sources élevé sont privilégiés car ceux-ci sont populaires, plus ables, et seront téléchargés plus rapidement.

L'annonce de chiers appâts et la promotion de honeypots sont les fonctionnalités les plus abouties d'HAMACK car elle permet une supervision très précise de l'accès à un contenu, en interceptant l'ensemble des requêtes émises depuis la recherche de mot-clé jusqu'au télécharge-ment du faux chier comme présenté par le schéma 5.3. La supervision des accès des pairs aux faux chiers proposés par notre architecture se fait en deux étapes.

La première étape est similaire à l'éclipse et consiste à prendre le contrôle de la référence à superviser en attirant toutes les requêtes de publication à destination de celle-ci. Ensuite, au lieu de nier les requêtes de recherche, les Honeypeers répondent à ces dernières en incluant de faux chiers dont les paramètres (nom, taille, et surtout, nombre de sources...) sont entièrement maîtrisés par l'architecture. La falsication des réponses peut être partielle ou totale si elle est couplée à l'éclipse des autres chiers, selon la conguration souhaitée. Cette fonctionnalité permet d'acher un grand nombre de sources pour assurer une bonne visibilité au pot de miel sans recourir à une grande quantité de machines annonçant les appâts.

L'étape nale consiste à capturer la demande de téléchargement lorsqu'un faux chier parmi la liste proposée est sélectionné. Pour cela, notre architecture doit être capable d'attirer les

Figure 5.4  Architecture réseau du Honeynet

recherches de sources pour les chiers proposés et d'y répondre avec les références des Honeypeers, formant ainsi un ensemble de honeypots distribués ou Honeynet. Sans que cela soit nécessaire, une optimisation consiste à générer les KADIDs des chiers créés pour rester extrêmement proches (96 bits) du mot-clé supervisé. Ainsi, chaque recherche de sources est attirée de la même manière que la recherche de mot-clé initiale et les mêmes Honeypeers peuvent être utilisés.

Enn, les sources renvoyées dans les réponses sont les Honeypeers eux-mêmes (KADID, IP, port). L'architecture est ainsi assurée de capturer les requêtes de téléchargement. Cette organi-sation spécique permet de s'assurer de l'intention d'un utilisateur malveillant. En capturant l'ensemble des requêtes émises, son comportement peut être vérié depuis le début, par la recherche de mot clé, jusqu'à la demande de téléchargement nale au travers de l'annonce des faux chiers. La partie suivante décrit l'implantation de notre architecture et les résultats obtenus lors de son déploiement sur le réseau KAD.