Forums d'entraide informatique - Astuces - Conseils

Le projet « Leurré.com », lancé en janvier 2003 par l'Institut Eurécom, a pour but de collecter du trafic anormal sur Internet et d'en étudier les propriétés et les causes. À cette fin, Eurécom et les organismes associés au projet déploient des « honeypots » dans divers endroits du monde.
Présentation de Leurré.com
Alors que la sécurité sur Internet est devenue un enjeu économique et politique primordial, le développement de méthodes et d'outils dans ce domaine se heurte à une difficulté majeure : le manque de données fiables, récentes et représentatives du trafic sur le réseau. Encore aujourd'hui, la plupart des travaux sont fondés sur le trafic consigné dans les célèbres fichiers de la DARPA, dont le moindre inconvénient n'est pas le fait qu'ils datent de 1999. Autant dire que des résultats obtenus par des techniques ou des outils sur un tel jeu de données ne présument en rien de leurs performances sur le terrain, et force est de constater que celles- ci sont généralement décevantes. Le projet Leurré.com [i] a été fondé précisément dans ce but : construire une infrastructure afin de collecter et d'analyser des données réelles et les rendre disponibles à des fins de recherche et de développement.
Les honeypots
Un honeypot, appelé aussi « pot de miel » en français, désigne une ressource informatique dont le rôle est de servir de cible à des usages anormaux ou malveillants. Un honeypot ne fournit aucun service destiné à être utilisé : théoriquement, aucun trafic sur le réseau ne devrait par conséquent être destiné à un honeypot. La présence d'un tel trafic est généralement considérée comme le symptôme d'une anomalie ou d'une tentative d'intrusion (usage illégitime des ressources du réseau).
Il existe deux types de honeypots. Les honeypots dits à « haute interaction » implémentent des services correspondant à une utilisation réelle dans le but d'en enregistrer l'usage, par hypothèse, considéré comme anormal. Cette technique permet donc en principe d'enregistrer des attaques effectives contre les services exposés et les actions délictueuses ainsi perpétrées, fournissant des données utiles aux enquêteurs dans le cadre d'une analyse légiste. Un tel honeypot consiste donc essentiellement en une implémentation opérationnelle des services et en tant que tel, il est lui-même exposé à des attaques. Pour cette raison, les honeypots à haute interaction sont généralement installés sur des machines virtuelles du type VMware [2] , dont le fonctionnement est facile à contrôler et à rétablir dans le cas où le système serait compromis par une attaque. Un honeypot du second type, dit à « faible interaction », est un système factice qui n'offre pas de services réellement exploitables. L'implémentation de ces derniers reste embryonnaire et n'est conçue que pour fournir la réponse attendue aux tentatives d'identification du système
(scanning et fingerprinting). Ces honeypots sont typiquement réalisés à l'aide du Logiciel libre Honeyd [3]. L'avantage principal de cette approche est sa plus grande sécurité : un honeypot à basse interaction offre a priori des possibilités d'attaque ou de détournement très limitées et les attaques dirigées contre le système émule n'aboutissent pas. En revanche, pour cette même raison, un honeypot à basse interaction ne permet pas d'enregistrer des intrusions effectives mais seulement les tentatives d'intrusion. D'autre part, il demeure aisé de détecter à distance un honeypot à basse interaction. Un attaquant peut prendre cette information en compte et modifier son comportement en conséquence. Les honeypots à basse interaction induisent donc intrinsèquement un biais, notamment dans le cas où l'attaquant est un opérateur humain et non un programme autonome simple tel qu'un ver. Ce biais et, plus généralement, ces limitations par rapport à des honeypots à haute interaction, font partie des problèmes étudiés dans le cadre du projet Leurré.com.
Infrastructure
À l'heure actuelle, le projet Leurré.com déploie des honeypots à basse interaction construits sur Honeyd. Chaque site participant au projet expose une ou plusieurs plateformes composées de trois hôtes virtuels sous Honeyd, qui émulent des systèmes Linux, Windows 2000 et Windows NT. Un kit d'installation comprenant une distribution de Linux, Honeyd et sa configuration est proposé aux sites désirant se joindre au projet. Fin 2005, plus de 40 sites de ce type ont été déployés sur tous les continents à l'exception de l'Antarctique. Pour des raisons évidentes, la localisation précise des sites est tenue confidentielle : en effet, s'il était connu qu'une adresse IP particulière correspond à un honeypot, le trafic enregistré par ce site pourrait être fortement biaisé.
L'ensemble du trafic enregistré par TCPdump sur chaque site est transmis et stocké dans la base de données centrale de Leurré. com. Il s'agit d'informations telles que l'adresse d'émission et


e contenu (poyload) de chaque paquet IP reçu par l'un des honeypots déployés, sa date de réception, le numéro de port visé sur le honeypot, etc. Cette masse de données (voir Figure I) est accessible à tous les participants au projet et est utilisée actuellement par plusieurs travaux de recherche, portant sur la reconnaissance et la classification des outils d'attaque ou le développement de techniques de détection. Au-delà de ces travaux concrets menés dans le cadre du projet, Leurré.com a la vocation de fédérer diverses recherches relatives à l'analyse du trafic sur Internet et à encourager la coopération et le partage des informations. Cette fédération se déroule sur le plan technique, par exemple en mettant les bases de données à la disposition de tous les participants et partenaires du projet, mais également sur le plan de la recherche, en développant un cadre théorique général pour intégrer diverses méthodes d'analyse et synthétiser les résultats. Nous présentons certains de ces travaux dans la suite de cet article.
Caractérisation des outils d'attaque
Les premières analyses effectuées sur les données collectées, menées par l'équipe d'Eurécom, portaient sur la détection et la classification des outils d'attaque à l'origine du trafic enregistré par les honeypots [4].
Modélisation du trafic
Pour les besoins de cette analyse, le trafic est structuré en « sessions » de 24 heures. Plus précisément, chaque « session » comprend l'ensemble des paquets transmis entre une source et une destination en l'espace de 24h. Elle peut donc correspondre à une ou plusieurs sessions TCP, mais aussi des séries de paquets utilisant d'autres protocoles comme UDP ou ICMP. Cette durée de 24 heures a été choisie arbitrairement, sachant que 24 heures correspondent, entre autres, au délai de validité par défaut des adresses IP allouées dynamiquement par DHCP. On considère donc qu'il est impossible de garantir qu'une adresse IP donnée corresponde effectivement à la même source de trafic pendant plus de 24 heures. Chaque session de 24 heures associée à un hôte virtuel donné est désignée par le terme de « tiny session ». La modélisation tient compte également de l'ensemble des paquets reçus par une plate-forme donnée en l'espace de 24 heures on désigne cet ensemble par le terme de « large session ». Une large session correspond donc à l'union d'une à trois tiny sessions, en fonction de l'activité des trois hôtes virtuels durant 24h.
Classification des empreintes d'activités
Chaque occurrence de trafic anormal ou malveillant pendant 24h peut ainsi être caractérisée par son empreinte sur la plate- forme cible. En groupant les « sessions » observées en fonction de la similarité de leurs empreintes, on obtient une classification des comportements anormaux et, par conséquent, des outils à
l'origine de ces comportements. Cette classification est obtenue par l'algorithme à base de règles d'association « Apriori » [5], appliqué dans le but de grouper les occurrences de trafic selon des caractéristiques telles que
11111. Le nombre d'hôtes virtuels sur la plate-forme qui reçoivent un trafic en provenance d'une même source ;
▪    Le nombre de paquets dans chacune des tiny sessions enregistrées correspondantes ;
MI Le nombre de paquets dans la large session correspondante (c'est-à-dire la somme des nombres de paquets par tiny- session)
La suite des ports TCP ou UDP visés par ces paquets ;
MI L'adresse IP de la source du trafic et sa localisation géographique
▪    etc.
L'algorithme « Apriori » consiste à construire un ensemble de règles d'association de la forme « si A et B, alors C » où A, B et C correspondent à des caractéristiques telles que celles énumérées ci-dessus. L'algorithme consiste à itérer sur la longueur de telles règles, où chaque itération utilise l'ensemble de règles de longueur k (c'est-à-dire des régies de la forme « si E( I) et E(2) ... et E(k-I) alors E(k) ») pour construire des règles de longueur k+l (de la forme « si [(I) et E(2) ... et E(k) alors E(k+ I ) »).
Les règles sont construites selon le principe suivant :
el I Pour chaque règle de longueur k connue, considérer les règles candidates de longueur k+ I telles que Nku soit supérieur à un pourcentage prédéfini du nombre total d'éléments à classifier, où Nk*, désigne le nombre d'éléments qui possèdent les caractéristiques E(l)... E(k+I): ce paramètre s'appelle le « support » de la règle candidate
1/1111 Retenir les règles candidates dont le rapport Nk/Nk,i (appelé la « confiance » de la règle) est supérieur à une valeur prédéfinie.
L'algorithme débute en sélectionnant les caractéristiques qui présentent chacune un « support » supérieur au minimum prédéfini ; celles-ci constituent alors un ensemble de départ de règles unitaires. Le processus s'arrête lorsque l'ensemble de règles k+ I retenues est vide, c'est-à-dire lorsqu'il n'est plus possible de construire de nouvelles associations. L'ensemble de règles d'association ainsi construites est utilisé pour grouper les occurrences de trafic enregistré en clusters correspondant à des occurrences similaires selon ces critères. Chaque cluster est par la suite divisé en sous-clusters en fonction du contenu des paquets (payload). La règle utilisée pour évaluer la similarité des contenus est la Distance de Levenshtein [6]. À ce stade, on considère que chaque sous-cluster correspond à une

d'attaque, car il regroupe des empreintes dont les caractéristiques sont similaires.
Applications et directions actuelles
Chaque sous-cluster obtenu par cette technique constitue une signature d'une anomalie particulière. Dans les cas où cette anomalie peut être identifiée (par exemple parce que ses caractéristiques sont connues ou en comparant ses caractéristiques à celles observées lors d'une exécution d'un outil donné dans un environnement de test), il est ainsi possible de surveiller sa propagation sur Internet, en particulier lorsqu'il s'agit de vers. Des résultats publiés identifient ainsi certains pays ou régions comme des sources ou des cibles majeures de certains types d'attaques [4]. De même, l'apparition de nouveaux clusters aux caractéristiques nouvelles est le symptôme probable de l'activité d'un nouvel outil d'attaque ou ver, qu'il est nécessaire d'identifier et dont la propagation doit être surveillée.
Analyse des délais entre réceptions de paquets
L'équipe australienne de l'information Security Institute (151) de la Queensland University of Technology travaille en collaboration avec Eurécom et étudie la possibilité de détecter des anomalies du réseau en analysant les délais entre les réceptions par un honeypot de deux paquets consécutifs provenant de la même source. Dans les publications en anglais, ces délais sont désignés par les termes de « Inter-Arrival Times » ou simplement 1AT [7], sigle que nous utilisons également dans cet article. L'objectif consiste ici à développer une technique de détection extrêmement légère. En effet, les méthodes de détection d'anomalies non rudimentaires disponibles actuellement restent lourdes à mettre en œuvre et reposent en grande partie sur l'analyse du contenu des paquets.
La puissance de calcul et la capacité de stockage requises pour appliquer ces traitements à l'ensemble du trafic reçu rendent leur implémentation impossible sur des serveurs de production soumis à une forte charge. En revanche, l'observation des 1AT est très économique : la séquence d'IAT correspondant à un trafic donné consiste en un flux de valeurs numériques, auxquelles il est possible d'appliquer divers algorithmes directement à la volée.
Il est possible d'identifier ainsi rapidement des phénomènes suspects qu'il convient d'examiner en détail par la suite.
Étude de cas
Certaines anomalies du réseau se manifestent par une proportion anormalement élevée d'IAT d'une durée particulière. La Figure 2 montre la distribution statistique globale desIAT dans l'ensemble du trafic enregistré depuis janvier 2003. Elle indique que des IAT de certaines durées apparaissent avec une fréquence inattendue. Un exemple concret est le pic correspondant aux1AT d'une durée de 28800 secondes, qui comptait 5077 occurrences en mai 2005 quand cette étude a été menée (valeur à comparer avec le nombre d'occurrences d'IAT de durée similaire, comme l'illustre la Figure 3). On peut remarquer que cette durée très longue (exactement 8 heures) et le fait qu'elle se reproduit essentiellement avec une précision de +/- 1 seconde excluent l'hypothèse qu'une telle anomalie puisse résulter de latences ou de dysfonctionnements du réseau tels que des pertes de paquets.
Une analyse plus poussée des informations contenues dans la base de données de Leurré.com révèle d'autres traits réguliers liés à cette durée particulière. Ainsi, 99,6% des sessions dans lesquelles apparaît un IAT de 28800 secondes comportent des paquets adressés au port UDP 38293. Plus de 83% de ces sessions sont par ailleurs composées de 18 ou 36 paquets précisément dans ce dernier cas, il s'agit pour la plupart d'une série de 18 paquets répétée deux fois. Enfin, il ressort que deux contenus (payloads) distincts seulement sont observés pour l'ensemble de ces sessions. De plus, ces deux payloads présentent le même nombre d'occurrences dans l'ensemble des sessions examinées (en réalité, leur différence est de I, probablement à cause d'une perte de paquet). Une brève recherche sur Google indique que le port UDP 38293 est utilisé par certaines versions du serveur de mises à jour de Norton Antivirus. En tenant compte de l'ensemble des caractéristiques observées de ce trafic, il est manifeste qu'il correspond à des installations de Norton Antivirus mal configurées qui disposent d'une adresse erronée du serveur de mises à jour. Cet exemple illustre les possibilités offertes par une infrastructure telle que Leurré.com. En l'occurrence il s'agit ici non pas d'attaques mais de dysfonctionnements, qui peuvent être aisément détectés et corrigés. Des observations rapides

d'anomalies, faciles à automatiser, indiquent un problème dont quelques recherches simples dans la base de données permettent d'établir un diagnostic complet, incluant la liste des sites à l'origine de ce trafic, leurs emplacements géographiques et leurs adresses IP.
Généralisation de la détection des pics
Des travaux actuellement en cours à l'ISI visent à systématiser l'analyse d'IAT et obtenir ainsi une technique économique pour déceler effectivement des problèmes potentiels, qui justifieraient alors des analyses plus complexes en utilisant des techniques lourdes. Ces recherches ne sont pas terminées à l'heure actuelle, il est cependant prévu de soumettre les résultats de ces travaux à la publication au cours du ler trimestre 2006. Nous résumons ici les observations et analyses effectuées à l'heure où cet article est écrit. Les premières analyses utilisaient le modèle des « sessions » de 24 heures utilisé par les travaux de l'équipe Eurécom. 11 apparaît cependant qu'en écartant cette limite de 24 heures et en considérant comme « session » l'ensemble de tous les paquets envoyés par une même source à une même destination au cours de l'existence du projet, de nouvelles anomalies apparaissent.
Des pics ont ainsi été observés pour des IAT d'une durée aussi longue que 300000 secondes, soit plus de 3 jours et 12 heures. D'autre part, il existe un phénomène de « pics harmoniques ». Le premier exemple concernait les IAT de 28800 secondes ; il existe cependant un pic similaire pour une durée d'IAT exactement double, soit 57600 secondes (16 heures). Des « harmoniques » de ce type ont pu être observées pour un grand nombre de pics, un exemple marquant en est l'ensemble des pics correspondant aux durées d'IAT respectives de 300, 600, 900, 1800, 2400 et 3600 secondes exactement. (L'analyse plus poussée des IAT d'une durée inférieure à I heure, c'est-à-dire 3600 secondes, a toutefois été provisoirement écartée, car les IAT de cet ordre de grandeur peuvent être fortement biaisés par des latences ou dysfonctionnements du réseau). Ce phénomène n'est pas totalement expliqué à l'heure actuelle. Il est certain toutefois qu'il ne s'agit pas d'un simple artefact dû à la perte de paquets. Si des paquets sont émis régulièrement vers une destination donnée avec une durée d'IAT fixe, la perte d'un paquet donne naturellement lieu à un IAT de durée double. Les observations indiquent cependant que le taux de perte est de l'ordre de 10%. Or, les harmoniques observés comptent des nombres d'occurrences d'IAT très supérieurs à 10% du trafic concerné par le pic original, la perte de paquets n'est donc pas seule à leur origine. De plus, par exemple dans le cas de la mauvaise configuration de Norton Antivirus, le trafic correspondant à l'harmonique de 57600 secondes présente certaines caractéristiques différentes de celui correspondant au pic de 28800 secondes, notamment en termes de nombre de paquets par session de 24h et de contenus. L'une des directions des études actuelles concerne donc les corrélations entre pics. Les observations reposent pour l'heure essentiellement sur une interprétation qualitative des résultats numériques. La Table I montre le nombre de sessions de 24h qui donnent lieu à au moins deux valeurs distinctes d'IAT parmi celles correspondantes aux 10 pics les plus importants. Il apparaît ainsi que de tels cas sont relativement rares, en comparaison avec le nombre de sessions où n'apparaît qu'une seule valeur de « long » IAT, éventuellement se produisant plus d'une fois (ces nombres sont indiqués sur la diagonale de la Table I).
La corrélation entre un pic et un port TCP ou UDP (ou un ensemble de ports) est également intéressante : il apparaît statistiquement qu'en dehors des ports utilisés par le trafic usuel (essentiellement les ports 80, 443 et 135), les paquets correspondant à deux pics distincts non harmoniques visent des ports différents. Pour des IAT longs, un pic et ses harmoniques fournissent par conséquent une signature statistique d'un type particulier de trafic.
Recherche de motifs
Le trafic enregistré par chaque honeypot consiste en des rafales de paquets reçus, c'est-à-dire des séries de paquets avec des IAT de courte durée (de l'ordre de quelques secondes au plus), séparées par des IAT plus ou moins longs. Les observations indiquent que ces périodes de rafales tendent à former des motifs répétitifs qu'il convient d'analyser. Le modèle utilisé actuellement pour cette analyse distingue donc entre des IAT « courts » et des IAT « longs », ces derniers ayant des durées différentes. La limite entre les IAT « courts » et « longs » reste relativement arbitraire. Elle peut être fixée manuellement afin d'étudier certains cas particuliers ; par défaut elle est définie comme étant l'IAT correspondant au premier pic supérieur à I minute. On peut donc représenter le trafic entre une source et une destination données par une suite de couples <longueur ra f al e ;1 cing_IAT>. Par exemple, supposons que le trafic enregistré se traduise par la suite des IAT suivante :
1, 7982, 3, 2, 0 7960, 0, 2. 0, 8004, 1, 3, 8023, 0, 1, 0, 7989, 1, 0, 2, 7978, 0, 0, 0
Notons que la date de réception des paquets (timestamp) est stockée avec une résolution de I seconde ; aussi, un IAT de 0 seconde correspond à deux paquets reçus avec moins de I seconde d'intervalle. Si, dans l'exemple présent, la limite entre « court » et « long » est fixée à 7960 secondes (ce qui sera le cas par défaut en l'absence d'autres données), la séquence ci-dessous pourra être représentée par :
<3,7982> - <3,7960,> - <3,8004> - <2,8023> - <3,7989)- <3,7978> - <3,2
L'ensemble des séquences représentées de cette façon est soumis à un algorithme simple de recherche de motifs afin de déterminer des enchaînements de rafales qui correspondent à des modèles de comportement répétés. Cette recherche concerne uniquement les rafales et ignore la durée des IAT longs qui les sépare.

Elle repose sur deux règles simples :
/I Deux rafales sont considérées identiques si leurs longueurs sont égales avec une tolérance de +/- 10% (ceci afin de prendre en compte le taux de perte de paquets).
El Pour une séquence donnée, chaque motif est retenu comme représentatif si l'ensemble de ses occurrences dans la séquence « couvre » au minimum 90% des paquets de cette séquence par défaut.
Dans cet exemple, la séquence contient ainsi trois motifs obéissant à ces critères :
Iffl Le motif « 3» (une rafale de quatre paquets, c'est-à-dire 3 IAT courts), apparaissant 6 fois dans la séquence au total
Le motif « 3-3-3 » (trois rafales consécutives de quatre paquets chacune), apparaissant 2 fois dans cette et séquence
MM Le motif « 3-3-3-2-3-3-3 », qui apparaît une fois et correspond à la séquence entière.
Les séquences sont alors groupées en fonction des motifs qu'elles contiennent. Les résultats font apparaître un ensemble restreint de motifs apparaissant très fréquemment dans le trafic
enregistré. Il s'agit principalement des motifs « 2 », « 17 » et « 4-2 ». Ce dernier est remarquable : en effet, il désigne une alternance régulière de rafales comprenant 5 paquets (4 IAT) et 3 paquets (2 IAT). Deux autres observations méritent d'être relevées. D'une part, l'occurrence de tels motifs semble être indépendante du type de trafic, elle serait davantage liée à son origine (i. e. la source). D'autre part, il existe un phénomène de « convergence » : dans certains cas, le trafic débute de manière erratique (en termes de séquences d'IAT), les occurrences répétées d'un motif ne commençant qu'après un certain nombre de paquets émis. L'observation de ces motifs répétés et leur détection sont actuellement utilisées afin d'élaborer une nouvelle définition de « sessions d'attaque », basée sur l'identification d'activités élémentaires au sein du trafic enregistré. Une autre application possible des IAT a toutefois été suggérée par des travaux menées indépendamment aux États-Unis. Zhou et Lang ont appliqué la transformée de Fourier discrète aux IAT dans les enregistrements DARPA [8], utilisés traditionnellement pour évaluer des méthodes d'analyse de trafic. Leurs résultats indiquent que des motifs d'IAT courts, identifiés par des pics dans le spectre des fréquences, peuvent être considérés en tant que signatures de certaines attaques ou anomalies.
-
o
•
Conclusion
Nous avons présenté le projet Leurré.com et certains travaux menés dans le cadre de ce projet par les équipes d'Eurécom (Nice) et de QUT-ISI (Brisbane). Ce projet représente aujourd'hui un effort mondial dans le domaine de l'analyse de trafic sur Internet et a la vocation d'offrir une base solide de coopération internationale. Aussi, tout institut ou organisme désirant participer à la recherche dans ce domaine est cordialement invité à rejoindre le projet. Chaque nouveau site participant s'engage par écrit à respecter les règles de confidentialité propres au projet (en particulier, à ne pas divulguer d'informations concernant l'emplacement des honeypots) et, bien sûr, à déployer et à maintenir au moins une plate-forme Honeyd et transmettre le trafic enregistré vers la base de données centrale. En contrepartie, le site se voit offrir un identifiant et un mot de passe permettant d'accéder à cette base, et dispose ainsi d'un accès complet aux données brutes en provenance des honeypots, aussi bien qu'aux résultats des analyses telles que celles présentées dans cet article. Ceux qui le désirent peuvent par ailleurs enrichir la base de données de leurs propres résultats, les mettant ainsi à la disposition de l'ensemble de la communauté du projet. Le projet Leurré.com et les travaux de recherche mentionnés dans cet article ont été financés en partie dans le cadre de l'accord de coopération franco-australien DEST-FAST et du projet HoFa, et également par les programmes ACI-S1 du ministère de la Recherche français et ARC-Linkage International de son homologue australien. Nous souhaitons par ailleurs remercier Marc Dacier, George Mohay et Andrew Clark, responsables des projets menés par Eurécom et QUT-ISI, ainsi que Fabien Pouget et Saleh Al-Motairi pour leur aide lors de la rédaction de cet article. Pour plus d'informations, nous vous invitons à visiter le site du projet : www.leurrecom.org.