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.

2


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

3


TABLE DE MATIERES

CHAPITRE 1 INTRODUCTION............................................................................................................................6
1.1 PROBLEMATIQUE ..............................................................................................................................................6
1.2 CONTRIBUTION .................................................................................................................................................7
1.3 ORGANISATION .................................................................................................................................................7
CHAPITRE 2 TRAVAUX CONCERNES..............................................................................................................9
2.1 PLATEFORMES DES POTS DE MIEL ......................................................................................................................9
2.1.1 Architecture générale ............................................................................................................................... 9
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 3 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 4 RESULTATS OBTENUS ..............................................................................................................32
CHAPITRE 5 CONCLUSION...............................................................................................................................39
REFERENCES........................................................................................................................................................40
ANNEXE 1 : ALERTE AU FORMAT IDMEF ...................................................................................................41

4


TABLE DE FIGURES
Figure 1. Plateformes distribuées des pots de miel........................................................................9
Figure 2. Une plateforme détaillée ..............................................................................................10
Figure 3. Division d'un cluster en se basant sur sa distance moyenne ........................................14
Figure 4. Architecture de OWL ...................................................................................................17
Figure 5. Le module de présentation Web...................................................................................18
Figure 6. Le processus de test......................................................................................................19
Figure 7. Architecture générale ...................................................................................................19
Figure 8. Système décomposé .....................................................................................................20
Figure 9. 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

5


1.1 Problématique

Chapitre 1 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

6


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 5 chapitres :
Chapitre 1 : Introduction
Chapitre 2 : 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.

7

1.3 Organisation
Chapitre 3 : 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 4 : Résultats obtenus
Nous illustrerons le travail par des résultats obtenus en utilisant l’interface OWL.
Chapitre 5 : 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.

8


2.1 Plateformes des pots de miel

Chapitre 2 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 1. 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

9


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 2. 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


2.1 Plateformes des pots de miel
l’extérieur et pour accepter celles en sens contraire. Cela permet d’éviter le cas où les pots
de miel sont utilisés pour attaquer les autres.
Plus d’informations sur le projet sont disponibles sur le site www.leurrecom.org.

2.2 Algorithme de regroupement des attaques
2.2.1 Problématique
Avec une plateforme comme décrite dans 2.1, l’équipe du projet peut surveiller des activités
malveillantes sur l’Internet. Les données sont envoyées chaque jour au serveur central de
données. La base de données est ensuite enrichie par des informations concernant la location
géographique, le système d’exploitation de la machine source, la date d’attaque, la
description de l’environnement de pots de miel, les ports sources, etc. Avec ces données,
l’équipe veut étudier profondément des processus (outils d’attaque) qui ont été utilisés pour
réaliser ces attaques.
On introduit deux définitions :
•

Source d’attaque : Une adresse IP qui envoie des paquets à notre plateforme pendant
une journée. C'est-à-dire si on observe des paquets envoyés d’une même source
pendant deux jours différents, ils sont considérés appartenant à deux adresses sources
différentes. C’est parce que des attaques observées expérimentalement ne dépassent
pas une minute dans la plupart des cas.

•

Séquence de ports : C’est une chaîne en ordre temporel des ports auxquels les

attaquants envoient de paquets pour une machine virtuelle. Par exemple, une source
envoie des paquets au port 80, ensuite 57 et puis 21, alors la séquence de ports est
{80, 57, 21}.

On constate que le nombre de séquence de ports est très limité. Pendant une période de
Février 2003 à Février 2004, on n’observe que 485 séquences différentes. En plus, on
constate qu’un nombre limité de séquences représente la plupart des trafics. L’exemple ci-

11


2.2 Algorithme de regroupement des attaques
dessous illustre les séquences observées et le pourcentage d’attaques correspondant pendant
Mars 2003 :
445 (45,5%)
80 (15,9%)
1433 (8,8%)
139 (5,8%)
21 (3,5%)
135 (2,9%)
80, 57, 21 (2,7%)
443 (2,1%)
Autres (12,8%)
Nous voulons savoir si les séquences de ports nous permettent de déterminer la cause
fondamentale (root cause [9]). Autrement dit, les séquences de ports caractérisent-elles des
outils d’attaque ? Dans la section suivante, nous verrons que les séquences de ports ne
peuvent pas décrire uniquement un outil d’attaque.

2.2.2 Algorithme
Pour caractériser des attaques observées dans les pots de miel, on utilise entre autres les

attributs suivants :
•

T : Le nombre de machines sur la plateforme attaquées par une source

•

ni : Le nombre de paquets envoyés par une source à la machine i, i ∈ {1, 2, 3}

•

N : Le nombre total de paquets envoyés par une source à toutes les trois machines. N
= n1+n2+n3

Avec la séquence de ports et ces attributs, on espère déterminer la cause fondamentale des
processus d’attaque. On applique l’algorithme « Règles d’association » [8] pour regrouper
ces attaques en clusters. Autrement dit, chaque cluster représente la cause fondamentale
d’un ensemble d’attaques.

12


2.2 Algorithme de regroupement des attaques
Les règles d’association sont très utilisées dans le domaine de fouille de données, par
exemple pour étudier le comportement des clients d’un supermarché. Imaginons un
supermarché avec une grande collection d’articles. Le gestionnaire du supermarché veut
prendre des décisions sur quels articles à vendre, comment arranger des articles sur les
rayonnages pour améliorer le profit, etc.
Avec une base de transactions des clients qui ont visité le supermarché, on aimerait trouver
les règles les plus fréquentes. Un exemple de telles règles d’association dit que 90% de

clients qui achètent du pain et du beurre achètent aussi du lait. Avec cette règle, le
gestionnaire peut décider de placer le rayonnage de lait près celui de pain et celui de beurre.
Pour évaluer les règles obtenues, on utilise les définitions « support » et « confiance ». Pour
une règle sous forme A+B ⇒ C, nous avons :

Support =

nombre _ de _ transaction _ contenant ( A, B, C )
nombre _ total _ de _ transactions

Confiance =

nombre _ de _ transaction _ contenant ( A, B, C )
nombre _ de _ transaction _ contenant ( A, B)

Les règles trouvées doivent avoir un support et une confiance supérieure à un seuil
déterminé.
On applique l’algorithme décrit dans [11] pour la base de données décrite ci-dessus.
Quelques clusters obtenus sont illustrés dans l’exemple ci-dessous :

Séquence de ports

Clusters fréquents

Support

{445}

Cluster 1 : T=3 & N=9 (n1=3 & n2=3 & n3=3)
Cluster 2 : T=1 1 N=1

Cluster 3 : T=3 & N=8
Cluster 4 : T=3 & N=13(n1=3 1 n2=8 & n3=2)
Cluster 5 : T=3 & N=26(n1=6 & n2=16 & n3=4)
Cluster 6 : T=1 & N=3
Cluster 7 : T=3 & N=11(n1=3 & n2=5 & n3=3)
Cluster 8 : T=1 & N=1

65,5%
18,4%
6,1%
66,3%
33,6%
55,8%
18,7%
5,6%

{135, 4444}
{80}

13


2.2 Algorithme de regroupement des attaques
Avec ces attributs, nous ne pouvons cependant pas assurer que ces clusters caractérisent bien
les attaques. A fin de valider les clusters, nous utilisons le champ de données dans les
paquets. Les champs de tous les paquets provenant d’une même source sont combinés en
utilisant Tethereal pour obtenir une chaîne de caractères. Par conséquent, pour chaque
attaque dans un cluster, nour avons une chaîne correspondant. Cette chaîne nous permet de
calculer la distance entre deux attaques et donc la distance moyenne d’un cluster comme
suivant :

D (i, j )
;
j∈C n − 1

di = ∑

DC = ∑
i∈C

di
n

C- un cluster (un ensemble d’attaques), |C| = n
D(a,b) – la distance entre l’attaque a et l’attaque b
di – la distance moyenne de l’attaque i à tous les autres attaques dans C
DC – la distance moyenne du cluster C
Un cluster n’est pas satisfait si sa distance moyenne est supérieure à un seuil déterminé. Il
doit être divisé en de plus petits clusters dont la distance moyenne est inférieure à ce seuil,
voir figure 3.

Figure 3. Division d'un cluster en se basant sur sa distance moyenne

Pour calculer la distance D(a,b), nous utilisons la distance de Levenshtein. Cette distance est
définie par le nombre de délétions,

d’insertions ou de substitutions nécessaires pour

transformer la chaîne a à la chaîne b.

Par exemple, pour a = « Eurecom » et b =

« Eurocom », D(a,b) = 1 parce que nous avons besoin d’une substitution ‘e’ → ‘o’ pour
transformer a à b.

14


2.2 Algorithme de regroupement des attaques
Les clusters obtenus sont utilisés comme des signatures dans le programme d’alerte. Pour
plus d’informations, voir [2].

2.3 Format IDMEF (Intrusion Detection Message Exchange
Format)
2.3.1Objectifs
IDMEF est créé comme un format standard auquel des systèmes de détection d’intrusions
peuvent générer des alertes. Cela permet l’interopérabilité entre divers systèmes qui veulent
partager des données. Dans ce travail, il est utilisé pour formaliser les connaissances
acquisses par les clusters sous un format standard accepté par la plupart des IDSs.
IDMEF peut être utilisé dans les cas suivants :

•

Un canal de données entre un IDS et une interface de gestion des alertes.

•

Une base centrale de données pour stocker des alertes provenant de plusieurs IDSs
différents.

•

Un système de corrélation 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
et complexes.

2.3.3 Implémentation en XML
XML a été choisi pour implémenter le modèle du format IDMEF. Avec la flexibilité, XML
permet d’implémenter facilement toutes les entités et toutes les relations entre eux dans un
modèle orienté objet. En outre, comme XML a été largement utilisé, il existe plusieurs outils
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 sommaire pour chaque paquet. Avec le paramètre –V, Tethereal
présente tous les champs de tous les protocoles dans les paquets. Les champs intéressés dans
ce travail sont l’adresse IP source, l’adresse IP destination, le port source, le port destination,
le temps d’arrivée, le protocole, le champ de données (payload).

16


3.1 Test de l’environnement OWL

Chapitre 3 Programme d’alerte basé sur des pots de miel
distribués
Dans ce chapitre, nous présentons les tâches effectuées. La première est de tester l’outil de
corrélation d’alertes OWL. Ensuite nous discuterons le processus de construction du
programme d’alerte. Enfin, nous décrivons les scripts pour faire des corrélations des alertes
générées par le programme.

3.1 Test de l’environnement OWL
OWL – développé par France Télécom – est un environnement permettant de stocker,
d’analyser et d’afficher des alertes générées par plusieurs sources. Les alertes sont
organisées et classifiées selon leur signature, 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 dans la base, les modifie ou insère de
nouvelles alertes. OWL présente des alertes à l’utilisateur par une interface web.

17


3.1 Test de l’environnement OWL
Cette tâche vise à tester tous les modules de OWL avec des données collectées par plusieurs
plateformes. Les modules sont le chargeur des données, le corrélateur et l’interface web. Le
chargeur et le corrélateur sont des scripts en Perl. L’interface web est écrite en PHP, GD2 et
ADOdb. Il se 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 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 au format IDMEF et les enregistre dans
un fichier temporaire. Le chargeur lit ce fichier pour charger les alertes dans la base de
données. Après avoir calculé la variation statistique du flux d’alertes, le corrélateur peut
modifier des alertes ou insérer de nouvelles alertes pour refléter des anomalies dans le flux
d’alertes. Les alertes sont présentées par l’interface web à l’utilisateur.

18


3.1 Test de l’environnement OWL

Figure 6. Le processus de test

Les tests réalisés ont permis d’identifier un certain nombre 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
Comme illustré dans la figure 7, Tethereal capture et analyse le trafic sur le réseau. Il
capture tous les paquets circulant sur le réseau, les décode et extrait des informations dans

les paquets comme les adresses IP, les ports, le protocole, etc. En particulier, il peut
assembler des données dans tous les paquets appartenant à une conversation, les afficher au
format texte qui est lisible à l’être humain.
OWL est un outil qui permet de visualiser des alertes au format IDMEF sur une interface
web.
Le programme maintient une liste de clusters. Le concept « cluster » est considéré comme
celui de signature dans des systèmes de détection d'intrusion généraux. Chaque cluster
caractérise uniquement un outil d'attaque détecté sur l'internet. Le programme utilise la liste
comme une base de connaissance lors de la détection des attaques. Cette liste de clusters est
obtenue en analysant des trafics sur des plateformes de pots de miel [2].
Après avoir obtenu des informations des attaques, Honeypot IDS les compare avec les
clusters dans la liste. Si une attaque et un cluster concordent, une alerte prenant ce cluster
comme sa signature sera générée. Par contre, le programme générera une alerte qui signale
la détection d'un nouvel outil d'attaque. En tous cas, les alertes sont générées au format
IDMEF [3] et envoyées à l'interface OWL pour faire d'autres analyses nécessaires.

Figure 8. Système décomposé

Comme illustré dans 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
IDMEF sont crées et envoyées à l'interface OWL. Ces fonctions sont détaillées dans les
sections suivantes.
Ce programme est implémenté en Perl, un langage de script qui est portable sur la plupart

des plateformes (Unix, VMS, Windows, Mac ...). Perl est particulièrement performant pour
le traitement du texte donc il est convenable pour le programme qui doit analyser beaucoup
de données en texte.

3.2.2 Chargement des clusters
Les clusters sont stockés dans un fichier texte, un cluster par ligne. Le format du fichier de
cluster est comme suivre:
clusterid=8112 ports=3410 T=1 N=4 n1=4 n2=0 n3=0
clusterid=8113 ports=5000 T=1 N=4 n1=4 n2=0 n3=0
clusterid=8114 ports=5000 T=1 N=12 n1=12 n2=0 n3=0
clusterid=8115 ports=5000,445,80 T=3 N=12 n1=9 n2=1 n3=2

•

Clusterid: l'identification unique d’un cluster.

•

Ports: séquence de ports de destination

•

T: le nombre de machines attaquées

•

n1, n2, n3: le nombre de paquets envoyés aux pots de miel 1, 2, 3

•

N: n1 + n2 + n3

Le programme est assez flexible pour ajouter d'autres attributs facilement. Lorsque le
programme s’initialise, les clusters sont chargés dans la mémoire.

3.2.3 Calcul de l’expression de Levenshtein
Nous rappelons que un cluster est un représentant pour un groupe d’attaques et que chaque
attaque a une chaîne de caractères correspondant. Nous avons besoin de calculer la distance
entre une attaque et un 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 entre un cluster et une attaque (correspondant à la chaîne de caractères) est définie
par la distance de Levenshtein entre cette expression et la chaîne de l’attaque.
Nous examinons maintenant l’algorithme pour calculer l’expression de Levenshtein pour un
cluster. Pour simplifier le problème, nous présentons d’abord comment calculer l’expression
pour deux chaînes A et B. Nous remplaçons tous les délétions, insertions ou substitutions
nécessaires a fin de transformer A à B par une caractère spéciale, par exemple ‘*’. Les
autres caractères communes de A et B sont gardées dans l’expression résultante. Par
exemple, avec deux chaînes « INTRUSION » et « INTRUTION », nous obtenons
« INTRU*ION » comme l’expression de Levenshtein. Nous appelons la fonction pour
calculer l’expression de deux chaînes expression_2_chaînes(A,B).
Il est facile maintenant de calculer l’expression de Levenshtein pour un cluster :
Expression_Levenshtein := attaque_0 ;
// attaque_0 – la première attaque dans le cluster

POUR CHAQUE attaque_i DANS le cluster
Expression_Levenshtein :=
expression_2_chaînes( Expression_Levenshtein, chaîne(attaque_i) ;
// chaîne(attaque_i) retourne la chaîne de l’attaque i
FIN_POUR

Nous donnons un exemple pour illustrer l’algorithme. Nous avons par exemple un cluster de
4 chaînes comme illustré dans la figure 9 :

Figure 9. Exemple de calculer l'expression de Levenshtein

L’expression de Levenshtein de ce cluster est donc *RANC*P*ONIE.

1

La distance partielle entre une attaque et un cluster est calculée en utilisant un seul attribut. La distance
globale est un somme de toutes les distances partielle.

22


3.2 Programme d’alerte basé sur des pots de miel distribués
Supposons que nous avons capturé une attaque dont la chaîne est FRANCOPHONI. Donc la
distance partielle (correspondant à la chaîne) entre ce cluster et l’attaque et de 4 (4 caractères
* dans l’expression résultante) :

Figure 10. Distance partielle entre le cluster et l'attaque

3.2.4 Capture des attaques
Cette fonction a pour but de capturer des attaques sur le réseau en temps réel. Les attaques

capturées sont stockées dans une liste d'attaques. Pour assurer la capture sans perte des
paquets, le programme est organisé en deux processus parallèles. Ces deux processus
partagent la liste d'attaques. Un processus reçoit la sortie de Tethereal, extrait des
informations utiles et met à jour la liste. L'autre processus choisit une attaque dans la liste, la
passe aux fonctions de détection et de génération (figure 11).
Ces deux processus fonctionnent indépendamment et partagent une zone mémoire
commune. Pour éviter la concurrence, un mécanisme de verrouillage est utilisé. Si un
processus veut accéder à la liste, il verrouille la zone mémoire donc l'autre doit attendre
jusqu'à ce que la liste soit libérée.

Figure 11. Structure parallèle du programme

23


3.2 Programme d’alerte basé sur des pots de miel distribués
La communication entre le processus 1 et l'outil Tethereal est réalisée via le mécanisme de
tuyau. La sortie de Tethereal pour un paquet est présenté dans l'annexe 4. En analysant cette
sortie, le processus 1 peut extraire toutes les informations utiles pour former la liste
d'attaques.

Figure 12. Stratégie pour enlever une attaque de la liste

Comme des paquets appartenant à une attaque n'arrivent pas en même temps, les attaques
doivent résider dans la liste pendant un certain temps pour assurer que tous les paquets de
l’attaque soient capturés. On utilise ici le concept « temps dormant » pour décider du
moment d’enlèvement de l’attaque. Le temps dormant d'une attaque est comptée à partir du
moment où le dernier paquet de l'attaque est capturé jusqu’au présent, voir la figure 12. Si le
temps dormant d’une attaque dépasse une durée T déterminé, c'est-à-dire depuis T secondes
l’attaquant n’a pas envoyé des paquets, alors elle sera enlevée de la liste pour générer une

alerte. Le choix du T est vraiment important. Dans le cas idéal, une attaque réside dans la
liste jusqu'à ce que le dernier paquet soit capturé. Si T est trop petit, une attaque peut perdre
quelques paquets. Par contre, avec T trop grand, on ne peut pas assurer l'instantanéité des
alertes. Autrement dit, l’administrateur est alerté trop tard.
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 informations sont mises à jour dans la
liste d’attaques en se basant sur l’adresse source correspondante.
Parallèlement, le processus 2 choisit dans la liste une attaque dont le temps dormant a
dépassé T. S’il en trouve une, il l’enlève de la liste et calcule la distance entre cette attaque
et les clusters chargés dans 3.2. Si un cluster dont la distance avec l’attaque est égale à zéro
est trouvé, il va être choisi comme la signature pour générer une alerte. Si aucun cluster
n’est trouvé, une alerte de nouvelle attaque est crée. L’alerte au format IDMEF sera envoyée
à l’interface OWL pour l’administrateur.

25