Programme d’alerte basé sur des pots de miel

Institut de la Francophonie pour l’Informatique MEMOIRE DE FIN D’ETUDES Projet Leurré.com Programme d’alerte basé sur des pots de miel Stagiaire NGUYEN Huy Quang, IFI Responsables Marc DACIER, EURECOM Fabien POUGET, EURECOM Sophia Antipolis, Septembre 2005 Remerciements J'aimerais consacrer cette section pour remercier des gens spéciaux qui m'ont supporté tout au long de mon stage Premièrement, je remercie infiniment Monsieur le Professeur Marc Dacier, de l'Institut Eurecom, responsable du projet Leurré.com, de m'avoir accueilli au sein de son équipe De plus, sans sa compréhension et son support constant, je n’aurais jamais pu accomplir mes taches Deuxièmement, je voudrais témoigner ma gratitude Monsieur Fabien Pouget, doctorant l'Institut Eurecom, pour le travail qu'il a fait avant moi, pour ses conseils précieux et pour les discussions grâce auxquelles j'ai pu mener bien mon travail Aussi, Monsieur le directeur des études Ho Tuong Vinh, de l'IFI, j'exprime ma profonde reconnaissance pour avoir facilité ce stage Je tiens exprimer également tous mes remerciements aux professeurs de l'IFI de m'avoir fourni des connaissances scientifiques qui seront utiles dans la poursuite de ma carrière Je suis reconnaissant Pham Van Hau, ingénieur de recherche Eurécom pour sa disponibilité et sa patience répondre mes questions Finalement, j'associe ces remerciements mes amis, mes collègues et tous les membres de l'IFI, de l'Institut Eurecom, chercheurs, techniciens, personnels administratifs avec qui j'ai eu le plaisir de travailler Abstract This paper introduces my intern work at Eurecom that aims at building an alert program based on a combination of two current interesting applications in the security domain One is the honey pot technology that focuses on collecting thread information on the Internet to study malicious activities The second one is related to alert correlation tools, which aim at reducing the number of alerts generated by IDSs by organizing them in groups of higherlevel view The work consists of testing OWL, an alert correlation tool developed by France Telecom and building the alert program Some results will be illustrated at the end of the paper Résumé Ce rapport introduit mon travail de stage Eurecom qui vise construire un programme d’alertes basé sur deux applications intéressantes dans le domaine de sécurité L’une est la technologie de pot de miel qui a pour but de collecter des informations d’attaques sur l’Internet pour étudier la communauté des pirates L’autre concerne des outils de corrélation d’alertes dont l’objectif est de réduire le nombre d’alertes générées par des IDSs en les organisant en groupes plus abstraits qui donnent une vue plus générale sur les attaques Le travail consiste tester OWL, un outil de corrélation d’alertes développé par France Télécom et construire le programme d’alertes Quelques résultats sont illustrés la fin du rapport Keywords Honeypot, Alert Correlation, Cluster, IDS TABLE DE MATIERES CHAPITRE INTRODUCTION 1.1 PROBLEMATIQUE 1.2 CONTRIBUTION 1.3 ORGANISATION CHAPITRE TRAVAUX CONCERNES 2.1 PLATEFORMES DES POTS DE MIEL 2.1.1 Architecture générale 2.1.2 Description détaillée .10 2.2 ALGORITHME DE REGROUPEMENT DES ATTAQUES 11 2.2.1 Problématique 11 2.2.2 Algorithme 12 2.3 FORMAT IDMEF (INTRUSION DETECTION MESSAGE EXCHANGE FORMAT) 15 2.3.1 Objectifs 15 2.3.2 Modèle de données de IDMEF .15 2.3.3 Implémentation en XML 15 2.4 TETHEREAL .16 CHAPITRE PROGRAMME D’ALERTE BASE SUR DES POTS DE MIEL DISTRIBUES .17 3.1 TEST DE L’ENVIRONNEMENT OWL 17 3.2 PROGRAMME D’ALERTE BASE SUR DES POTS DE MIEL DISTRIBUES 19 3.2.1 Architecture générale .19 3.2.2 Chargement des clusters .21 3.2.3 Expression de Levenshtein 21 3.2.4 Capture des attaques 23 3.2.5 Détection des attaques 26 3.2.6 Génération des alertes au format IDMEF 26 3.3 CORRELATION DES ALERTES 30 CHAPITRE RESULTATS OBTENUS 32 CHAPITRE CONCLUSION .39 REFERENCES 40 ANNEXE : ALERTE AU FORMAT IDMEF 41 TABLE DE FIGURES Figure Plateformes distribuées des pots de miel Figure Une plateforme détaillée 10 Figure Division d'un cluster en se basant sur sa distance moyenne 14 Figure Architecture de OWL 17 Figure Le module de présentation Web 18 Figure Le processus de test 19 Figure Architecture générale 19 Figure Système décomposé .20 Figure Exemple de calculer l'expression de Levenshtein 22 Figure 10 Distance partielle entre le cluster et l'attaque .23 Figure 11 Structure parallèle du programme 23 Figure 12 Stratégie pour enlever une attaque de la liste 24 Figure 13 Enlèvement d'une attaque 25 Figure 14 La liste d'attaques .26 Figure 15 Calcul de la distance entre une attaque et un cluster 26 Figure 16 Modèle orienté objet d'une alerte au format IDMEF 27 Figure 17 Corrélation entre les alertes Snort et celles du programme d'alerte 31 Figure 18 Données sur deux plateforme chargées par Snort et le programme 32 Figure 19 Outils d’attaque détectés par le programme .33 Figure 20 Outils d'attaque détectés par Snort .33 Figure 21 IPs triées par le nombre d'alertes, capturées par le programme 35 Figure 22 Source triées par le nombre d'alertes, capturées par Snort .35 Figure 23 Correspondances entre des clusters et des signatures Snort .36 Figure 24 Attaques effectuées par la source X.X.X.X, détectées par le programme .37 Figure 25 Attaques effectuées par la source X.X.X.X, détectées par Snort 37 Figure 26 Attaques effectuées par la source Y.Y.Y.Y, détectées par le programme 38 Figure 27 Attaques effectuées par la source Y.Y.Y.Y, détectées par Snort .38 Figure 28 Un exemple d'une alerte au format IDMEF générée par le programme 41 1.1 Problématique Chapitre Introduction 1.1 Problématique Les systèmes de détection d’intrusion (IDS) ont un rôle crucial dans le schéma de sécurité des systèmes informatiques Pourtant il reste des désavantages dans les IDSs courants Les IDSs produisent souvent un gros volume d’alertes dues des processus d’attaques automatisés et fréquents Cela rend l’analyse embarrassante et compliquée Les IDSs peuvent également générer de nombreux faux positifs et faux négatifs En outre, les auteurs de [5] ont montré que les IDSs basés sur des anomalies sont impuissants face des comportements changeant très lentement alors que les IDSs basés sur des signatures ne peuvent pas détecter de novelles intrusions Il est donc intéressant de trouver une nouvelle approche de détection d’intrusion Dans les dernières années, la technologie de pot de miel a suscité l’intérêt de la communauté de sécurité Un pot de miel est défini comme « une ressource dont la valeur est d’être attaquée ou d’être compromise » En effet, les pots de miel sont des machines créées pour gagner des informations sur des attaques sur l’Internet Comme ils n’ont aucune fonction de production, seulement des données malicieuses sont supposées d’être collectées Ces données sont utilisées pour étudier la communauté des attaquants En outre, les administrateurs aujourd’hui sont souvent surchargés par un gros volume d’alertes générées par des IDSs C’est la raison pour laquelle les outils de corrélation d’alertes ont été créés Ils permettent d’organiser des alertes en groupes qui donnent une vue plus abstraite sur les attaques Cela permet aux administrateurs de se focaliser sur un nombre moindre d’alertes plus significatives Une convergence de ces deux tendances nous inspire de proposer une nouvelle approche de détection d’intrusion qui est introduite dans ce rapport Le projet Leurré.com a débuté en 2003 l’Institut Eurecom par l’équipe de Marc Dacier Le but du projet est d’étudier profondément des attaques sur l’Internet Depuis sa naissance, le projet a attiré beaucoup d’intérêts de la communauté de sécurité Il s’agit d’un réseau de plateformes de pots de miel distribués dans une vingtaine de pays Une plateforme se 1.1 Problématique compose de trois pots de miel qui sont en fait trois machines virtuelles Le but de ces pots de miel est de collecter des attaques sur l’Internet Les paquets capturés sont stockés dans une base centrale pour plus tard Dans [2], en utilisant des données capturées par les plateformes des pots de miel, M Dacier et F Pouget ont introduit un algorithme pour regrouper des attaques en « clusters » Chaque cluster porte des caractéristiques communes pour un ensemble d’attaques Un cluster en fait peut se percevoir comme une signature dans les IDSs normaux En appliquant cet algorithme sur des données dans la base centrale, on obtient une liste de signatures qui caractérisent des attaques observées sur l’Internet Cette liste de signatures représente donc les caractéristiques des attaques ayant déjà été observées par les différents pots de miel Nous nous sommes intéressés développer un programme d’alerte Ce programme doit être installé sur chaque plateforme de pot de miel a fin de détecter les activités malicieuses Pour chaque nouvelle activité, le programme compare avec les signatures existantes et envoie le résultat de cette recherche OWL - une console de corrélation d’alertes développée par France Télécom, au format standard IDMEF Nous avons également comparé les résultats avec des alertes Snort pour mieux comprendre des attaques observées 1.2 Contribution • Tester l’outil OWL développé par France Télécom, produire un rapport de test • Développer le programme d’alerte, définir un format IDMEF pour des alertes générées • Ecrire des scripts pour corréler des alertes du programme avec celles Snort 1.3 Organisation Ce rapport se compose de chapitres : Chapitre : Introduction Chapitre : Travaux concernés Ce chapitre présente tous les travaux concernant ce stage : les plateformes des pots de miel, l’algorithme de regroupement, le format IDMEF, Tethereal 1.3 Organisation Chapitre : Programme d’alerte Dans ce chapitre, nous présenterons le travail réalisé pendant le stage : test de l’environnement OWL, architecture générale, capture des attaques, détection des attaques, génération des alertes, corrélation des alertes avec celles Snort Chapitre : Résultats obtenus Nous illustrerons le travail par des résultats obtenus en utilisant l’interface OWL Chapitre : Conclusion Ce stage a eu lieu dans le carde du projet Leurré.com, une coopération entre l’équipe de M Dacier et France Télécom Il a été réalisé au département d’entreprise, l’Institut Eurecom, Sophia Antipolis, France en été 2005 2.1 Plateformes des pots de miel Chapitre Travaux concernés Dans ce chapitre, nous discutons les travaux extérieurs dont le résultat est utilisé dans ce stage Nous commençons par la plateforme répartie des pots de miel déployée par Eurecom et ensuite l’algorithme de regroupement des attaques proposé par M Dacier et F Pouget Grâce au résultat de cet algorithme appliqué sur les données collectées par cette plateforme pendant un an, nous pouvons développer ce programme d’alerte Puis nous abordons le format IDMEF dans lequel le programme génère des alertes Nous introduisons enfin la console OWL et l’outil Tethereal qui font partie de l’architecture générale du programme 2.1 Plateformes des pots de miel 2.1.1 Architecture générale Figure Plateformes distribuées des pots de miel Il s’agit d’un réseau de plateformes déployées dans une vingtaine de pays Sur chaque plateforme sont installés des pots de miel afin de surveiller des attaquants Un pot de miel est une machine qui n’a aucune fonction de production Il ne collecte que des trafics 2.1 Plateformes des pots de miel malicieux, pas de production [11] Vues de l’extérieur, ce sont de vraies machines avec de vrais services Des informations sur les attaques sont capturées silencieusement par un observateur qui est invisible de l’extérieur Les données capturées chaque plateforme sont envoyées quotidiennement une base centrale installée l’Eurecom Cette base est ensuite enrichie par d’autres informations liées la location géographique, au système d’exploitation et au nom de domaine Ces données peuvent être partagées entre les responsables des réseaux qui ont déployé une plateforme chez eux 2.1.2 Description détaillée Figure Une plateforme détaillée Une plateforme se compose de trois machines virtuelles ou trois pots de miel Ces pots de miel sont simulés en utilisant VMWare ou Honeyd Les systèmes d’exploitation installés sur ces machines sont Windows 98, Windows NT et Linux Redhat 7.3 Les machines virtuelles se présentent comme de vraies machines pour les attaquants depuis l’extérieur Outre trois pots de miel, on déploie un observateur - une machine pour capturer tous les trafics qui arrivent sur la plateforme Des données capturées pendant une journée sont stockées dans un fichier tcpdump et envoyées la base centrale L’observateur n’est pas observé par l’extérieur Un pare-feu est utilisé pour refuser des connexions des machines virtuelles vers 10 3.2 Programme d’alerte basé sur des pots de miel distribués format réduit pour le programme est présenté par le modèle orienté objet dans la figure 16 Figure 16 Modèle orienté objet d'une alerte au format IDMEF IDMEF-Message IDMEF-Message est la classe au sommet du diagramme pour présenter une unité de données échangée entre un IDS (analyseur) et une interface de l’administrateur Un message peut emballer une ou plusieurs alertes L’attribut version indique la version IDMEF du document contenant ce message Alert 27 3.2 Programme d’alerte basé sur des pots de miel distribués Alert est la classe fondamentale dans le modèle Chaque fois que l’analyseur détecte un événement (une attaque), il envoie une alerte l’administrateur Alert contient des informations suivantes : • Ident : une identification unique pour l’alerte • Analyser: l’information concernant l’analyseur qui a généré cette alerte • CreateTime: moment où l’alerte est générée • DetectTime : moment où l’événement concernant cette alerte est détecté • Source : machine qui a provoqué l’événement • Target : machine cible de l’événement • Classification : nom de l’alerte qui permet l’administrateur de déterminer la signification de l’alerte • AdditionalData : des informations supplémentaires, par exemple le champ « payload » des paquets Analyser Cette classe présente l’analyseur par lequel l’alerte a été générée Analyser est un concept utilisé par le langage IDMEF pour signifier un IDS Seulement un analyseur est décodé dans une alerte Analyser contient des informations suivantes : • Analyserid : une identification unique pour l’analyseur • Name : un nom de l’analyseur pour distinguer avec d’autres analyseurs dans un même système • Manufacturer : organisation qui a développé cet analyseur • Node : information concernant la machine où réside cet analyseur CreateTime Cette classe indique la date et le temps où l’alerte est générée par l’analyseur L’attribut ntpstamp présente la même date et le même temps que le champ « contenu » au format NTPSTAMP [3] Le champ « contenu » présente la date et le temps au format yyyy-mm-ddThh:mm:ssZ DetectTime 28 3.2 Programme d’alerte basé sur des pots de miel distribués Cette classe indique la date et le temps où l’événement provoquant l’alerte est détecté par l’analyseur Dans le cas où l’événement concerne plusieurs paquets, c’est le moment où le premier paquet est observé par l’analyseur DetectTime n’est pas exactement CreateTime parce que l’analyseur n’est pas obligé de générer l’alerte immédiatement après la détection Pour les informations contenues, voir CreateTime Source Cette classe contient des informations concernant la machine d’origine de l’événement qui a généré l’alerte Ces informations sont : • Node.Address.category : Le type de l’adresse de la machine source (ou le réseau où réside la machine) Ce champ ne peut prendre que des valeurs déterminées, voir [3] Dans ce programme, on utilise la valeur « ipv4-addr » • Node.Address.address : l’adresse IP de la machine source • Service.protocol : Le protocole utilisé pour réaliser l’attaque (tcp, udp, icmp) Target Cette classe contient des informations concernant la machine cible de l’événement qui a généré l’alerte Dans notre cas, ce sont des pots de miels dans une plateforme Pour les informations contenues, voir Source Classification La classe Classification fournit une signification de l’alerte ou des informations permettant de déterminer l’événement qui a généré l’alerte Ces informations sont définies par le fournisseur de l’alerte Dans ce cas, nous fournissons des informations afin de caractériser un outil d’attaque comme la séquence de ports, le protocole, le nombre de pots de miel attaqués, le nombre de paquets, etc Classification contient des informations suivantes : • Name : une chaîne de caractères fournie par le développeur pour identifier l’alerte • Url : l’adresse où l’administrateur peut trouver des explications pour l’alerte Cela peut être des descriptions détaillées sur l’outil utilisé pour faire l’attaque • Orgin : La source où le nom de l’alerte est défini Ce champ ne peut prendre que des 29 3.2 Programme d’alerte basé sur des pots de miel distribués valeurs déterminées, voir [3] Dans notre cas, on utilise la valeur « vendor-specific » AdditionalData Cette classe est utilisée pour fournir des informations qui ne peuvent pas être représentées par le modèle de données Elle peut être aussi utilisée pour étendre le modèle afin de représenter des données complexes Dans notre cas, nous utilisons cette classe pour contenir des données dans le champ « payload » des paquets Nous avons des informations suivantes : • Meaning : une chaîne de caractères décrivant la signification du contenu Cela permet l’administrateur d’interpréter le contenu envoyé par l’analyseur Par exemple, dans ce programme, le champ prend la valeur « packet_payload » • Type : Le type des données dans le contenu Les valeurs permises pour ce champ est listées dans [3] Nous utilisons la librairie XML::IDMEF, un module de Perl développé par Erwan Lemonnier pour créer et analyser des messages IDMEF Une alerte complète est présentée dans l'annexe 3.3 Corrélation des alertes Snort est un des plus populaires IDSs dans la communauté de logiciels libres Snort détecte des intrusions en utilisant des règles Aujourdui, Snort a un ensemble d’environ 1200 règles dans sa base, c'est-à-dire il peut détecter environ 1200 vulnérabilités différentes Nous voulons comparer le résultat de notre programme et celui de Snort avec les mêmes trafics, pour clarifier ses avantages et ses inconvénients par rapport Snort 30 3.3 Corrélation des alertes Figure 17 Corrélation entre les alertes Snort et celles du programme d'alerte Nous observons une adresse source qui attaque la plateforme Nous lançons en même temps Snort et le programme d’alerte pour détecter cette adresse Toutes les alertes générées par Snort et par le programme sont analysées Donc pour chaque adresse source, nous avons une correspondance entre une combinaison de clusters et une combinaison de signatures Snort En lançant le script avec plusieurs attaques visant plusieurs plateformes différentes, nous enrichissons le résultat dans une liste de confrontation dans la base de données Avec cette liste, nous pouvons analyser les points forts et les points faibles du programme par rapport Snort En plus, cette liste est utilisée comme une référence qui nous permet de savoir quelle signature Snort un cluster quelconque correspond 31 Chapitre Résultats obtenus Chapitre Résultats obtenus Pour illustrer les résultats obtenus, nous avons utilisé des données capturées sur une première plate-forme (aaaa) de Janvier Mai 2004 et sur une deuxième plate-forme (bbbb) du mois de Février 2005 Ces données sont chargées par Snort et par le programme d'alerte Les alertes générées sont stockées dans une base de données et affichées par l'outil OWL Figure 18 Données sur deux plateforme chargées par Snort et le programme Les alertes sont groupées dans des sondes: • • • • aaaa.honeypot: Les données sur la plate-forme aaaa, chargées par le programme aaaa.Snort: Les données sur la plate-forme aaaa, chargées par Snort bbbb.honeypot: Les données sur la plate-forme bbbb, chargées par le programme bbbb.Snort: Les données sur la plate-forme bbbb, chargées par Snort On voit que pour toutes les deux plateformes, le nombre de sources capturées par le programme est beaucoup plus supérieur que le nombre de sources capturées par Snort Pour la plate-forme aaaa, seulement 855 machines source sont capturées par Snort lorsque 13731 machines sont capturées par le programme Pour la plate-forme bbbb, seulement 1954 machines sont détectées par Snort par rapport 18131 machines détectées par le programme C'est dire beaucoup d'attaques sont négligées par Snort Avec sa base de connaissances, Snort ne peut détecter qu'un nombre limité de machines attaquant les plateformes par rapport au programme De la même façon, le nombre de signatures détectées par Snort est très limité par rapport celles détectées par le programme Seulement 40 signatures différentes sur la plateforme bbbb et signatures sur la plateforme aaaa sont détectées par Snort tandis que 3019 signatures sur la plateforme bbbb et 2854 signatures sur la plateforme aaaa sont détectées par le programme Cela signifie que le programme fournit plus d'informations sur les attaques que Snort Avec le programme, on obtient une base de connaissances d'attaques beaucoup plus riche qu'avec Snort 32 Chapitre Résultats obtenus Figure 19 Outils d’attaque détectés par le programme Figure 20 Outils d'attaque détectés par Snort 33 Chapitre Résultats obtenus Dans la figure 19 on observe que les deuxième et onzième signatures sont des signatures connues Elles sont déjà dans la base de connaissances du programme avec l'identifiant 1131 et 1107 Les autres sont de nouveaux outils, c'est dire ils ne sont pas présents dans la base de connaissances Le préfixe « (FIRST) New tool » signifie de nouveaux outils observés la première fois sur la plateforme Le préfixe « New tool » signifie de nouveaux outils qui ont déjà été vus au moins une fois avant sur la plateforme mais qui n’ont pas encore reçu d’identifiant Par exemple, les première et quatrième signatures décrivent un même outil qui attaque tous les trois pots de miel en envoyant un seul paquet au port 137 de chaque pot Par conséquent, le programme peut mettre jour sans cesse et immédiatement sa base de connaissances avec de nouveaux outils d'attaque détectées Par contre, Snort est limité par un ensemble de règles fixées Il laisse passer toutes les attaques pour lesquelles il n’a pas de signature En plus, la mise jour de la base de connaissances n'est pas automatique En revenant la Figure 18, on examine maintenant le nombre d'alertes générées par deux programmes Sonde aaaa.Snort Alertes Sources Alertes par source 1149 855 1,34 aaaa.honeypot 15999 13731 1,17 bbbb.Snort 21233 1954 10,87 bbbb.honeypot 20749 18131 1,14 En général, pour une source d'attaque, le programme génère moins d'alertes que Snort Snort examine tous les paquets qu'il voit Si le paquet contient du code malveillant (par rapport aux signatures dans la base), il générera une alerte Si un attaquant envoie par exemple un paquet plusieurs fois, Snort va générer plusieurs alertes identiques Cela dérange l'administrateur et perturbe l'analyse des attaques Par contre, notre programme regroupe tous les paquets provenant d'une même source afin de former une attaque En conséquence, si un attaquant envoie plusieurs paquets identiques pendent un intervalle déterminé de temps, alors une seule alerte sera générée De cette façon, le nombre d'alertes est vraiment réduit Cette affirmation est clarifiée dans la figure 21 et 22 34 Chapitre Résultats obtenus Figure 21 IPs triées par le nombre d'alertes, capturées par le programme Figure 22 Source triées par le nombre d'alertes, capturées par Snort Ces figures illustrent le nombre d'alertes générées par le programme et par Snort pour quelques sources d'attaque sur la plateforme bbbb Les adresses IP sources sont triées par le nombre d'alertes générées Comme nous avons dit, les signatures du programme fournissent plus d'informations précises sur des attaques que celles Snort Pourtant, les signatures Sort ont été acceptées et utilisées largement par la communauté de sécurité En plus, les signatures Snort peuvent expliquer la façon dont les attaques sont réalisées Par exemple, pour chaque signature Snort, nous avons une référence sur l'Internet ou on peut trouver toutes les informations liées cette attaque: l'objectif, la méthode, la sévérité, etc Dans ce sens, les signatures Snort sont plus significatives que celles de notre programme C'est pourquoi nous avons écrit des scripts pour faire une liste de corrélation entre les signatures de notre programme avec celles de Snort 35 Chapitre Résultats obtenus Figure 23 Correspondances entre des clusters et des signatures Snort En lançant ces scripts avec des données sur plateformes, nous avons obtenu une liste de 320 paires de correspondance Nous constatons que, plusieurs clusters correspondent une même combinaison de signatures Snort Dans la figure 23, les clusters 17565 et 17570 correspondent la signature « (http_inspect) BARE BYTE UNICODE ENCODING » Cela affirme encore une fois que les clusters donnent plus d'informations que les signatures Snort Cette liste sera utilisée comme référence pour des outils détectés par le programme Nous illustrons l’utilité de cette liste par deux exemples Dans la figure 23, le cluster 17933 correspond la signature « WEB-IIS nsiislog.dl » A l’aide de l’interface OWL, nous savons que ces attaques ont été effectuées par une source X.X.X.X: 36 Chapitre Résultats obtenus Figure 24 Attaques effectuées par la source X.X.X.X, détectées par le programme Selon le programme, la machine X.X.X.X a attaqué le port 80 des trois pots de miel Il a envoyé paquets au premier, au deuxième et au troisième Figure 25 Attaques effectuées par la source X.X.X.X, détectées par Snort Sur le site snort.org/pub-bin/sigs.cgi nous avons trouvé des explications sur l’attaque « WEB-IIS nsiislog.log access »: c'est un essai afin d'accéder le fichier nsiislon.dll sur une machine exécutant le serveur IIS L'attaquant veut déborder un tampon pour exécuter son code dangereux sur la machine victime L’exemple suivant illustre les attaques effectuées par la source Y.Y.Y.Y Selon le programme, cette machine a effectué attaques correspondant alertes générées Dans chaque attaque, l'attaquant a envoyé paquets chaque pot de miel Dans la première et la troisième (correspondent la signature « SCAN Proxy Port 8080 attempt » de Snort), le port 8080 a été attaqué tandis que dans la deuxième et la quatrième (correspondant la signature « SCAN Squid Proxy attempt » de Snort), le port 3128 a été attaqué 37 Chapitre Résultats obtenus Figure 26 Attaques effectuées par la source Y.Y.Y.Y, détectées par le programme Par contre, pour cette machine attaquante, Snort a généré 64 alertes avec deux signatures « SCAN Proxy Port 8080 attempt » et « SCAN Squid Proxy attempt » Car Snort peut envoyer autant d’alertes que de paquets, ce qui n’est pas le cas chez nous Sur le site web de Snort, ce sont des scans sur une machine C’est peut-être le prélude d’une attaque L’attaquant veut déterminer sur quels ports la machine écoute, si les ports sont filtrés par un pare-feu et si la machine est vulnérable une exploitation particulière Figure 27 Attaques effectuées par la source Y.Y.Y.Y, détectées par Snort 38 Chapitre Conclusion Chapitre Conclusion Nous avons introduit le problème de détection d’intrusions en exploitant les données contextuelles fournies par des pots de miel Nous avons parlé d’abord des plateformes réparties des pots de miel déployées plusieurs endroits sur l’Internet Une plateforme se compose de trois machines virtuelles sur lesquelles nous avons installé les systèmes d’exploitation Windows 98, Windows NT et Linux Redhat 7.3 avec de vrais services Les pots de miel collectent des trafics malveillants et les envoient chaque jour une base centrale Après avoir été enrichies par d’autres informations, les données dans cette base sont analysées pour étudier des attaques sur l’Internet Le groupe du projet a publié des résultats intéressants Nous avons introduit ensuite l’algorithme de regroupement des attaques proposé par F Pouget et M Dacier Une attaque est caractérisée par trois séquences de ports et d’autres attributs comme le protocole, le nombre de machines attaquées, le nombre de paquets envoyés Cet algorithme est appliqué sur des données collectées par les plateformes distribuées pendant un an Chaque cluster obtenu rassemble les traces d’attaques dues une cause commune, c'est-à-dire dans la plupart des cas, un même outil Ces clusters sont utilisés comme les signatures dans le programme d’alerte que nous avons développé après Puis, nous avons présenté les tâches réaliser liées au test de l’outil OWL et au développement du programme d’alerte Nous avons décrit l’architecture générale dont notre programme fait partie Les fonctions sont détaillées pas pas: la capture des attaques, la détection des clusters et la génération des alertes Le format IDMEF est décrit par un modèle orienté objet Des scripts ont été écrits pour faire la corrélation entre ces alertes et celles de Snort Dans la partie suivante, nous avons présenté quelques résultats obtenus l’aide de l’interface OWL Les alertes générées par le programme ont été comparées avec les alertes Snort Nous avons constaté qu’il existe de nombreuses attaques qui ne sont pas détectées par Snort mais elles sont identifiées par notre programme De plus, le nombre d’alertes générées par notre programme est beaucoup plus faible, par attaquant, que celui généré par Snort pour les mêmes trafics Nous avons construit une liste de corrélation entre des clusters et des signatures Snort En général, nous observons que plusieurs clusters correspondent une même signature Snort Cela signifie que les clusters apportent plus d’informations sur les attaques que les signatures Snort Enfin, notre programme est capable de détecter de nouvelles attaques invisibles pour Snort Le programme a été testé et validé par des données de plusieurs plateformes Dans un futur proche, nous espérons de le déployer sur les plateformes des membres qui font partie de Leurré.com 39 Références [1] Fabien Pouget Leurré.com, the Eurecom Honeypot Project introduction Http://www.eurecom.fr/~pouget/leurrecom.htm [2] Fabien Pouget, Marc Dacier « Honeypot-based Forensics » [3] H Debar, D Curry, B Feinstein « The Intrusion Détection Message Exchange Format » January 27, 2005 [4] Ethereal Http://www.ethereal.com [5] Anita K Jones, Robert S Sielken « Computer System Intrusion Detection: A Survey » University of Virginia, September 2000 [6] Stefan Axelsson « Research in Intrusion-Detection Systems: A Survey » Chalmers University of Technology, August 1999 [7] Système de détection d'intrusion Snort Www.snort.org [8] R Agrawal, R Imielinski, A Swami « Mining Association Rules between Sets of Items in Large Databases » Centre de recherche IBM Almaden [9] « Root causes analysis: Literature review » WS Atkins Consultants Ltd [10] R Agrawal, R Imielinski, A Swami « Fast Algorithms for Mining Association Rules» Centre de recherche IBM Almaden [11] Lance Spitzner “The Value of Honeypots, Part One: Definitions and Values of Honeypots” Annexe : Alerte au format IDMEF Figure 28 Un exemple d'une alerte au format IDMEF générée par le programme 41 [...]... compose des pages suivantes: Figure 5 Le module de présentation Web • • • • • Accueil : demande de l’identifiant et le mot de passe Administration : gestion des utilisateurs, des rôles et des bases de données Sondes : gestion des sondes et des groups de sondes Signatures : gestion des classifications et des signatures Alertes : affichage des alertes, des signatures, des classifications, des sondes, des. .. de problèmes et de proposer des modifications qui ont été communiquées à France Télécom R&D dans un rapport interne confidentiel 3.2 Programme d’alerte basé sur des pots de miel distribués 3.2.1 Architecture générale Cette partie décrit l’architecture générale du système dans lequel se situe notre programme Figure 7 Architecture générale 19 3.2 Programme d’alerte basé sur des pots de miel distribués... la figure 8, le programme se compose de quatre fonctions principales Lors que le programme démarre, les clusters sont chargés dans la mémoire Ensuite des attaques sont capturées sur une interface de réseau Puis elles sont passées pour chercher des clusters qui concordent En se basant sur le résultat de la détection, des alertes au format 20 3.2 Programme d’alerte basé sur des pots de miel distribués... sources, des destinations et des utilisateurs • Recherche : recherche par des critères • Rapport : production des rapports statistiques au format HTML • Aide : page d’usage Pour rendre le test intéressant, nous avons besoin des alertes réelles Des données d’attaques sur 9 plateformes stockées dans des fichiers tcpdump sont chargées par Snort En consultant sa base de connaissances, Snort produit des alertes... cluster en se basant sur des attributs décrits ci-dessus (voir la section 3.2.5) La chaîne de caractères est aussi comptée comme un tel attribut Il est donc nécessaire de calculer pour chaque cluster une chaîne commune (nous appelons cette chaîne l’expression de Levenshtein) à partir de la chaîne des attaques dans ce cluster La distance 21 3.2 Programme d’alerte basé sur des pots de miel distribués partielle1... Le fonctionnement du programme est présenté dans la figure 13 24 3.2 Programme d’alerte basé sur des pots de miel distribués Figure 13 Enlèvement d'une attaque Le processus 1 capture des paquets sur le réseau Il extrait ensuite des champs d’information utiles dans les paquets comme le temps d’arrivée, le protocole, l’adresse source, l’adresse destination, le port source, le port destination, etc Ces... d’événement qui accueille des alertes de plusieurs IDSs • Une interface de gestion des alertes qui peut afficher des alertes de plusieurs IDSs • Echange des données entre plusieurs organisations 2.3.2 Modèle de données de IDMEF IDMEF est défini par un modèle orienté objet en raison de ces avantages de flexibilité et d’extensibilité Ce modèle permet également de décrire les relations entre des alertes simples... permettant de traiter des documents en XML 15 2.4 Tethereal Pour plus de détails sur le format IDMEF, voir [3] 2.4 Tethereal Tethereal est un analyseur de protocoles de réseau Il peut capturer des paquets sur le réseau ou lire des paquets dans un fichier Tethereal décode ces paquets et sort des champs d’information dans les paquets sur la sortie standard ou dans un fichier Par défaut, il présente une ligne de. .. leur niveau de sévérité, etc pour faciliter des recherches et des analyses OWL est aussi capable d’enrichir et de corréler des alertes dans la base de données Figure 4 Architecture de OWL OWL maintient une base de données centrale pour stocker toutes les alertes provenant de diverses sources OWL supporte des données en entrée au format IDMEF et au format Nessus Le module de corrélation lit des alertes... fournissons des informations afin de caractériser un outil d’attaque comme la séquence de ports, le protocole, le nombre de pots de miel attaqués, le nombre de paquets, etc Classification contient des informations suivantes : • Name : une chaîne de caractères fournie par le développeur pour identifier l’alerte • Url : l’adresse où l’administrateur peut trouver des explications pour l’alerte Cela peut être des