Programme d’alerte basé sur des pots de miel

16 CHAPITRE 3 PROGRAMME D’ALERTE BASE SUR DES POTS DE MIEL DISTRIBUES .... En effet, les pots de miel sont des machines créées pour gagner des informations sur des attaques sur l’Interne

Institut de la Francophonie pour

Marc DACIER, EURECOM Fabien POUGET, EURECOM

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 higher-level 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 1 INTRODUCTION 6

1.1 P ROBLEMATIQUE 6

1.2 C ONTRIBUTION 7

1.3 O RGANISATION 7

CHAPITRE 2 TRAVAUX CONCERNES 9

2.1 P LATEFORMES DES POTS DE MIEL 9

2.1.1 Architecture générale 9

2.1.2 Description détaillée 10

2.2 A LGORITHME DE REGROUPEMENT DES ATTAQUES 11

2.2.1 Problématique 11

2.2.2 Algorithme 12

2.3 F ORMAT IDMEF (I NTRUSION D ETECTION M ESSAGE E XCHANGE F ORMAT ) 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 T ETHEREAL 16

CHAPITRE 3 PROGRAMME D’ALERTE BASE SUR DES POTS DE MIEL DISTRIBUES 17

3.1 T EST DE L ’ ENVIRONNEMENT OWL 17

3.2 P ROGRAMME 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 C ORRELATION DES ALERTES 30

CHAPITRE 4 RESULTATS OBTENUS 32

CHAPITRE 5 CONCLUSION 39

REFERENCES 40

ANNEXE 1 : ALERTE AU FORMAT IDMEF 41

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

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

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

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

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

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

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

2.1 Plateformes des pots de miel

l’extérieur et pour accepter celles en sens contraire Cela permet d’éviter le cas ó 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-

2.2 Algorithme de regroupement des attaques

dessous illustre les séquences observées et le pourcentage d’attaques correspondant pendant Mars 2003 :

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

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 =

nstransactiode

totalnombre

CBAcontenantn

transactiode

nombre

_

),,(_

Confiance =

),(_

),,(_

BAcontenantn

transactiode

nombre

CBAcontenantn

transactiode

{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

65,5% 18,4% 6,1%

{135, 4444} 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)

66,3% 33,6% {80} Cluster 6 : T=1 & N=3

Cluster 7 : T=3 & N=11(n1=3 & n2=5 & n3=3) Cluster 8 : T=1 & N=1

55,8% 18,7% 5,6%

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 :

∑

∈ −

=

C j i

n

jiDd

1

),( ; ∑

∈

=

C i

i C

n

dD

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

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

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)

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

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

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

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