Projet de Fin dEtudes

Pour lObtention du Diplme Master en

Ingnierie Informatique et Internet

Intitul :

Gestion et centralisation des logs

avec leurs corrlations
Prsent par :
BENZIDANE KARIM
Le, 06/07/2010
Encadrants :
Moussaid Khaild , Facult des Sciences, Casablanca
Zoubir Sami , Crdit du Maroc, Casablanca
Ouali Youness, Crdit du Maroc, Casablanca

Membres du Jury :
Mr Abghour, Facult des Sciences, Casablanca
Mr Bouzidi, Facult des Sciences, Casablanca
Mme Fetjah, Facult des Sciences, Casablanca

Anne Universitaire 2009 / 2010

Remerciements

Jadresse mon remercment Mr. Zoubir sami pour sa disponibilit et coute ainsi de
mavoir accept dans son dpartement et mavoir permis le choix du sujet.
Je remercie galement Mr. Youness OUALI pour ses valeureux conseils ainsi que son
encadrement au cours de ce stage allant de la dmarche du travail jusquau technique
de dploiement.
Je remercie galement Mr Abderahim SEKKAKI pour nous avoir donne lopportunit
dacqurir ces connaissances, ainsi que tous les enseignants que jai eu au long de ces 2
annes du Master.
Un grand merci mon encadrant Mr Moussaid pour son aide et conseil pour que ce stage
soit ralis et finalis.
Je tiens aussi remercier toute lquipe du plateau ou jtais CDM, pour leur aide afin
de me fournir les informations ncessaires pour le bon droulement du projet .
Mes remerciements aux membres des jurys qui mont honor en acceptant de juger ce
travail.

Table des matieres

Liste des figures ................................................................................................................ 4
Introduction ..................................................................................................................... 5
Chapitre 1 : Contexte du projet ......................................................................................... 7
1.1 Crdit du Maroc .................................................................................................................................. 8
1.4 Dfinition du besoin ........................................................................................................................... 9
1.2 Dfinition dun SIMS ......................................................................................................................... 11
1.3 Fonctionnalit : ................................................................................................................................. 11

Chapitre 2 : Etat de lart .................................................................................................. 15

2.1 Choix de la solution SIMS : ............................................................................................................... 16
2.1 Prelude-SIEM........................................................................................................................................ 17
2.2 Format standard ............................................................................................................................... 25
2.3 Compatibilit ..................................................................................................................................... 27

Chapitre 3 : Sondes et sources

dinformations ........................................................... 29

3.1 Qualit indispensable ...................................................................................................................... 30

3.2 Intgration de sources dinformation externes ............................................................................ 41

Chapitre 4 : Etude et ralisation de la maquette de test .................................................. 44

4.1 Architecture ...................................................................................................................................... 45
4.2 Fonctionnalits ................................................................................................................................. 46
4.3 Outils et sondes utilises ................................................................................................................. 46
4.4 Stockage des informations dans une BD ............................................................................................... 48
4.5 Schma de la structure de base adopte .............................................................................................. 48
4.5 Enregistrement des sondes .................................................................................................................. 49
4.6 Haute disponibilit ........................................................................................................................... 51

Elaboration de Prelude en haute disponibilit ........................................................................... 52

4.7 Performance ...................................................................................................................................... 53

Chapitre 5 : Fonctionnement et test ................................................................................ 55

5.1 Scan de Port ....................................................................................................................................... 56
5.2 Brute force attaque........................................................................................................................... 58
5.3 Analyse via Prelude-LML ................................................................................................................. 60
5.4

Linterface Prewikka: ................................................................................................................. 63

Conclusion ...................................................................................................................... 68
Annexe ........................................................................................................................... 69
Reference ....................................................................................................................... 83
3

Liste des figures

Figure 1 : Schma de l'organisme DSIG ............................................................................................................. 9

Figure 2 : Topologie analogique d'une SIEM ................................................................................................... 10
Figure 3 : Illustration des tapes du SIMS ....................................................................................................... 11
Figure 4 : Tableau comparatif des solutions SIEM .......................................................................................... 16
Figure 5 : Architecture simple ......................................................................................................................... 23
Figure 6 : Architecture relai ......................................................................................................................... 24
Figure 7 : Architecture relai invers ............................................................................................................. 24
Figure 8 : Structure d'un message IDMEF ....................................................................................................... 26
Figure 9 : Tableau de compatibilit de Prelude............................................................................................... 28
Figure 10 : Modle avec la couche SSH ........................................................................................................... 30
Figure 11 : Fonctionnement des NIDS ............................................................................................................. 31
Figure 12 : Fonctionnement d'un HybIDS ....................................................................................................... 34
Figure 13 : Fonctionnement d'un pare-feu ..................................................................................................... 36
Figure 14 : Maquette de teste propose......................................................................................................... 49
Figure 15 : Remont d'une alerte corrle (EvantScan) .................................................................................. 58
Figure 16 : Remont d'une alerte corrle (Brute Force) ................................................................................ 60
Figure 17 : Fichier syslog , journalisant HoneyD .............................................................................................. 61
Figure 18 : Remont d'alerte de la sonde HoneyD via Prelude-LML ................................................................ 62
Figure 19 : Formulaire d'authentification ....................................................................................................... 63
Figure 20 : Page principale Prewikka .............................................................................................................. 64
Figure 21 : Liste des alertes ............................................................................................................................ 65
Figure 22: Dtail d'une alerte ......................................................................................................................... 65
Figure 23 : Pages des alertes corrles ........................................................................................................... 66
Figure 24 : Liste et pages des agents ............................................................................................................... 67
Figure 25 : Graphes de la page statistiques .................................................................................................... 67

Introduction
De nos jours, les rseaux dentreprise sont exposs toutes sortes dattaques informatiques qui vont du simple challenge entre hackers, aux attaques cibles dautres organisations ou entreprises concurrentes en passant par le sabotage de serveurs (dnis de
service) dans le but de discrditer lentreprise en tant que fournisseur de services ou
simplement en tant quentreprise. Les attaques indoor semblent aussi prendre de
lampleur.
Ainsi, les problmes de protection et prventions contre les attaques informatiques sont
de plus en plus complexes et varis puisque :
Les entreprises sont de plus en plus dlocalises et donc disposent de rseaux intranet et extranet nationaux ou/et mondiaux,
Les attaques peuvent tre externes (outdoor) et internes (indoor),
Les collaborateurs sont de plus en plus mobiles et donc les rseaux daccs de
plus en plus nombreux et varis.
Donc, le responsable des services informatiques et le responsable de la scurit doivent
travailler de plus en plus en troite collaboration pour garantir la consistance des donnes administratives.
Pour ladministrateur rseau et scurit, le nouveau challenge consiste donc :
Dfinir et promouvoir une politique scurit,
Dployer les dispositifs de dfense,
Assurer par des outils dobservations performants la dtection de failles ventuelles et le cas chant,
Redfinir et redployer rapidement de nouvelles dfenses, voire mme redfinir
une nouvelle politique de scurit.
Malheureusement la gestion de la scurit consiste actuellement superposer aux outils
et donnes existantes celles relatives la scurit. Cela cr des redondances trs nfastes au niveau des investissements et surtout au niveau des donnes avec par exemple
des consquences trs fcheuses lors de rvocation de droits daccs suite une raffectation ou au dpart dun collaborateur.
Cependant, les solutions sont trop complexes et coteuses pour rpondre aux besoins
des entreprises. Dans notre valuation du march, nous avons constat surtout
lmergence de nouvelles plateformes de gestion de scurit, trs spcialises et plus
adaptes. Cette nouvelle gnration de produits dispose doutils danalyse et corrlation
pouvant dans une certaine mesure dterminer, parfois mme en temps rel, la gravit de
la menace ou la profondeur de lintrusion en cours. Cette intelligence est cependant trs

redevable du flux dinformation provenant des diffrents organes surveiller respectivement protger.
Dans lurgence, les entreprises investissent des sommes colossales dans des logiciels et
des matriels senss garantir la scurit et lintgrit du rseau.
Un rseau dentreprise digne de ce nom est form dquipements rseau htrognes
et dune certaine varit de systmes dexploitation, chacun fournissant ses logs1 dans
un format bien propritaire. Selon le type de solution utilis, il est souvent ncessaire de
parcourir tous ces logs sparment et manuellement.
Certains de ces logs sont envoys en clair sur le rseau (syslog et SNMPv.1 en sont de
bons exemples) vers un serveur central, offrant ainsi des personnes malveillantes une
magnifique opportunit de masquer leurs agissements en inondant ledit serveur de faux
messages ou alertes.
Dans ltat actuel des choses, aucune solution commerciale ou Open Source ne peut
prtendre garantir seule la scurit du rseau . . . il faut avoir recours plusieurs produits de conception et de source diffrentes. Chacun de ces produits possde bien sr un
format de message et une interface qui lui sont propres.
Bien que la qualit des sondes rseaux et htes se soit grandement amliore, ces dernires sont toujours sujettes un pourcentage non ngligeable de faux positifs2 et faux
ngatifs3.
Il existe toutefois une petite proportion dentreprises o la surveillance du rseau ne
souffre peu ou pas des points mentionns ci-dessus. Malheureusement, le travail du responsable de la scurit nen est pas facilit pour autant, car il doit jongler avec un flot
incessant dalertes provoques par des comportements qui nont, dans 90% des cas, aucun impact sur lintgrit du rseau(En effet, quelle est lutilit de signaler des attaques
propres Microsoft IIS diriges contre un serveur Apache ?).
Un dernier point noir est le fait que les rseaux 100% switchs ont de plus en plus la
cote auprs des entreprises . . . ce qui est une bonne chose du point de vue de la (pseudo)
confidentialit des donnes. Malheureusement, ces derniers sont plus problmatiques
surveiller. En effet, suivant le nombre de postes connects et le dbit des donnes, le
port monitoring du switch devient compltement satur, rendant soit impossible
lanalyse complte des donnes (perte de paquets) ou ralentissant lensemble de son
fonctionnement (throttling).
A la vue du triste palmars des solutions actuelles de scurit, nous pouvons aisment
constater quil devient impratif de trouver rapidement une solution. Force est de constater qu lheure actuelle, seuls des produits commerciaux trs onreux prtendent offrir une alternative viable et se destinent naturellement au march des grandes entreprises. Larrive dun produit tout aussi efficace prix plus modr serait extrmement
bien accueillie offrant ainsi un bon SIMS4.

Fichier journal
Une alerte est leve sans raison
3
Aucune alerte na t leve alors que lattaque a bien eu lieu
4
Security information management System
2

Chapitre 1 : Contexte du projet

1.1 Crdit du Maroc

Etablissement financier marocain de premier ordre, le Crdit du Maroc, filiale du Groupe
Crdit Agricole SA (France)
1.1.1 Prsentation CDM
La banque Crdit du Maroc est un groupe financier marocain multi-mtiers ayant une
prsence nationale.
CDM exerce ses activits en direct et travers plusieurs filiales spcialises. Ses activits directes sont organises en 2 ples Mtiers et 1 ple transverse organis. Ainsi, les
ples Mtiers comprennent :
Le ple Banque Rseau et de Dtail;
Le ple Banque de Financement et dInvestissement;
Le ple Industrialisation;
Le ple Industrialisation comprend :
La Direction des Systmes dInformation Groupe DSIG
La Direction de lOrganisation Groupe DOG
La Direction des Services la Clientle et des Flux DSCF
La Direction des Immeubles et de Logistique DIL
1.1.2 Organisation et prsentation DSIG
La Direction des Systmes dInformation Groupe a pour objectif de rpondre aux besoins
informatiques de l'ensemble des utilisateurs ou matrises d'ouvrage du Groupe CDM en
accord avec la stratgie globale de la banque visant amliorer la rentabilit, la qualit
de service, la productivit et la scurit. Elle assure cet objectif en veillant la cohrence
globale du systme d'information.
Les dpartements qui constituent la DSIG veillent :
Dfinir et contrler l'application des normes et standards informatiques rgissant la conduite des projets et dfinissant les rles des diffrents acteurs,
Organiser et assurer le rle de la matrise d'uvre fonctionnelle travers
les mtiers traditionnels de l'informatique savoir la gestion cohrente de
l'architecture fonctionnelle, les tudes et dveloppements, la gestion des
projets et la maintenance,
Organiser et assurer la gestion de l'infrastructure du systme d'information
et le droulement des traitements priodiques dans les meilleures conditions de qualit de service. Cette mission comprend la gestion de l'architecture technique (informatique centrale et distribue, tlcommunications)
avec comme objectifs la scurisation des donnes et des traitements informatiques, la cohrence et le dimensionnement optimal de l'infrastructure
technique et la prennit des investissements.

Le schma ci-dessous donne une vision globale de lorganisation DSIG :

Figure 1 : Schma de l'organisme DSIG

1.4 Dfinition du besoin

1.4.1 Problmatique :
Comme cit dans la partie ci-dessus , le stage est effectu Crdit du Maroc (Sige ) l
o rside le systme dinformation central. Tous facilement constat une banque requiert toujours un systme dinformation robuste et surtout bien scuris.
De nos jours, le systme dinformation (S.I.) est devenu vital pour la majorit des entreprises. Garant de lactivit de lentreprise pour certaines ou simple garant des donnes
confidentielles pour dautres, une interruption de service du S.I. induirait des risques
majeurs pour lentreprise
Risque de perte financire
Risque de perte dimage
Risque dimpact juridique
Face ces risques, les entreprises nont pas dautre choix que dinvestir dans une politique de scurit. Cependant le cot de ces investissements est loin dtre ngligeable et
les entreprises sont souvent confrontes aux problmes suivants :
9

 La multiplicit et la complexit croissante des technologies.

Lmergence de nouvelles attaques (phishing, virus, etc ) sans cesses plus pertinentes qui imposent aux entreprises une veille permanente
La spcificit. Chaque entreprise est diffrente, donc chaque entreprise ses contraintes propres (au niveau stratgique comme au niveau technique).
1.4.2 Le besoin :
Le besoin de base consiste mettre en place un manager de scurit centralis (Figure
1) capable de faire face au flot dalertes et autres problmes rapports par les HIDS et
NIDS du rseau, ainsi que diffrent autre composant de scurit .
Le premier but est de rcolter toutes ces alertes et de les prsenter dans un format
unique et homogne, rendant ainsi possible lanalyse de ces informations par
ladministrateur.
Une fois toutes les alertes brutes rcupres, il faudrait mettre en place un mcanisme
de corrlation. Ce dernier permettra de diminuer une partie des faux-positifs, sans toutefois les radiquer totalement.
Ainsi, ladministrateur de scurit aura une vue globale sur les attaques qui ont rellement abouties, sans devoir visualiser les unes aprs les autres les milliers dalertes gnres.

Figure 2 : Topologie analogique d'une SIEM

10

1.4.3 Cahier des charges

En partant de ce qui a t nonc au paragraphe prcdent, ltude sera faite sur
ltablissement dune solution SIMS. Cette solution semblant rpondre aux problmatiques prcdemment cites, permettant ainsi de grer de manire centralise les remontes dinformation de diffrents outils, de les stocker et les traiter afin de faciliter
ladministration et la gestion de la scurit pour l administrateur.
Aprs concertations avec lencadrant et aux vues des besoins, la liste des taches sera la
suivantes :
Etude de la problmatique.
Choix dune solution SIMS :
NetForensics
OSSIM
Prelude
Etude de la solution SIMS choisie
Mise en uvre dune maquette de test
Rapport de test
1.2 Dfinition dun SIMS
Un SIMS appels galement SEM (Security Event Management) ou SEIM (Security Event
Information Management) ou encore SIEM (Security Information and Event Management) est un systme servant automatiser la collecte et lanalyse des informations de
tous les nuds de scurits dans un rseau. Mis part les informations obtenues des
logs et des alertes des firewall, IDS , Anti-virus, VPN et autre systme de scurit , un
Security Manager peu obtenir tous ces informations dans une seul consol SIM . Il y a
diffrent types de SIM , quelques un servent faire une agrgation de tous les rapports
venant des diffrentes composantes, et dautre font la corrlation des logs pour amliorer la qualit densemble de la scurit de linformation .
Il y a deux avantages cls dans lagrgation des donns : premirement , la rduction du
cout et lamlioration de lefficacit de ladministration. Deuximement, la simplification
et lamlioration du reporting pour laudit.
1.3 Fonctionnalit :

Figure 3 : Illustration des tapes du SIMS

11

La collecte
Les logiciels de SIEM prennent en entre les vnements collects du SI : les logs des
quipements (firewalls, routeurs, serveurs, bases de donnes, etc.). Ils permettent de
prendre en compte diffrents formats (syslog, Traps SNMP, fichiers plats, OPSEC, formats propritaires, etc.).
La collecte peut tre de faon passive en mode coute ou active en mettant en place des
agents directement sur les quipements ou distance.
La normalisation
Les logs bruts sont stocks sans modification pour garder leur valeur juridique. On parle
de valeur probante. Les logs sont gnralement copis puis normaliss sous un format
plus lisible. En effet, la normalisation permet de faire des recherches multicritres, sur
un champ ou sur une date. Ce sont ces vnements qui seront enrichis avec d'autres
donnes puis envoys vers le moteur de corrlation.
Lagrgation
Fait rfrence au processus dacquisition de plus en plus de donnes .Plusieurs rgles de
filtrage peuvent tre appliques, ils sont ensuite agrgs selon les solutions, puis envoys vers le moteur de corrlation.
La corrlation
La corrlation est une mthode combinat diffrent vnement reli afin davoir une
image prcise de ce qui se passe, ainsi donc limiter les lacunes des IDS. Son but majeur
est dy mettre une bonne concentration de logs et aussi une rduction du bruit gnrer
par les faux positives ou ngatives afin de dcouvrir les nouvelles attaques bien construites.
Latout majeur de la corrlation est de dtecter des squences dalertes prsent par une
ou plusieurs sondes. Lanalyse de ces squences rsulte une nouvelle alerte reprsentant
ainsi la signification globale de toutes les squences.
Il y a deux types de corrlations :
Une corrlation passive : Dduit une alerte uniquement depuis les infos
que lon a par liminations de doublons, factorisations, ou par fusion simple ou complexe
.
Une corrlation active : Driv de la corrlation passive pour faire gnrer
lIDS de nouvelles alertes, elle va chercher les informations correspondant des alertes
mises. Par exemple, lorsqu'une personne se connecte en dehors des heures de travail,
ceci a un impact lev qui n'aurait pas t en temps normal d'activit.
Exemples :
o Compression : A+B = A
o Seuillage : A+A+A+A+A+A=A
o Modification : A->B
12

o Enrichissement : A=A+CVE
Aprs avoir fait la collecte dun maximum dinformation , on peut passer par deux tapes
assurant ainsi un bon niveau de corrlation .la premire tape reposant sur llimination
des duplicata , se basant sur la suppression des alertes identiques ou similaires , la deuxime tape consiste factoriser les alertes ; rduisant ainsi le nombre dalerte en une
seul alerte corrle , cet alerte rsume donc toutes les informations contenues dans les
alertes et ajustes leurs proprits .
On trouve deux niveaux danalyse distinct ; une corrlation simple et corrlation global.
La corrlation simple :
Une squence dalerte ciblant le mme service ou hte peut tre regroup afin de
produire une alerte corrle. Lanalyse de cette squence dattaque na pas besoins
dinformations additionnelles.
La corrlation globale :
La corrlation simple nest pas efficace contre une attaque bien construite ;
lattaque ne va pas attaquer le mme service ou hte ainsi que pas dans la mme intervalle de temps. La corrlation global considre le contexte de tous les vnements qui
nous amne lattaque courante et essaye de trouver des similitudes afin de reconstruire les squences de lattaque.
Il y a plusieurs lments utiles pour un bon niveau danalyse :
@ IP : Le lien entre le trafic entrant et le trafic sortant est important et gnralement pas considrer par les NIDS, l@ IP est une source utile pour comprendre la
relation entre diffrente alerte et les lier la mme squence.
Comportement : Un changement soudain de comportement dans une activit rgulire est considrer comme suspicieuse.
Temps de travail : Une connexion hors lintervalle de travail permise dclenche une alerte corrle.
Rglement : La Policy de la scurit interdit la connexion certain serveur
ou service mise part ladministrateur, donc toute connexion est interprt comme malicieuse.
Le reporting
Les SIMS permettent galement de crer et gnrer des tableaux de bord et des rapports. Ainsi, les diffrents acteurs du SI, RSSI, administrateurs, utilisateurs peuvent avoir
une visibilit sur le SI (Nombre d'attaques, nombre d'alertes/jour...).
Archivage
Les solutions SIEM sont utilises galement pour des raisons juridiques et rglementaires. Un archivage valeur probante permet de garantir l'intgrit des traces. Les solu-

13

tions peuvent utiliser des disques en RAID, calculer l'empreinte, utiliser du chiffrement
ou autre pour garantir l'intgrit des traces.
Rejeu des vnements
La majorit des solutions permettent galement de rejouer les anciens vnements pour
mener des investigations post-incidentes. Il est galement possible de modifier une rgle
et de rejouer les vnements pour voir son comportement.
Les diffrentes5 solutions SIM:
ArcSight
Solutions: ArcSight ESM; ArcSight Interactive Discovery; ArcSight Pattern Discovery
Cisco
Solution: CiscoWorks Security Information Management Solution (SIMS)
Computer Associates
Solution: CA Security Command Center
eIQnetworks
Solution: SecureVue
Enterasys
Solution: Dragon Security Command Console
High Tower
Solution: SEM 3200
netForensics
Solution: nFX SIM One
NitroSecurity
Solution: NitroView ESM
Novell
Solution: ZENworks Endpoint Security Manager
RSA
Solution: enVision Platform
Symantec
Solution: Symantec Security Information Manager
TriGeo
Solution: TriGeo Security Information Manager
PreludeIDS Technologies
Solution: Prelude-SIEM
AlienVault
Slolution : OSSIM

Listes non exhaustives

14

Chapitre 2 : Etat de lart

15

2.1 Choix de la solution SIMS :

Figure 4 : Tableau comparatif des solutions SIEM

Nos choix se sont focaliss sur les solutions les plus utilises sur le march (Open Source
et commercial) ; nFX SIM one de NetForensic , OSSIM de AlienVault et Prelude-SIEM de
Prelude.
nFX SIM one est considr parmi les solutions commercial les plus imposes et qui sest
rpandue dans le march dune faon large, mais elle ne reste pas sans inconvnient car
comme toute solution commercial le cot payant reste toujours un obstacle majeur , toujours dans le cot payant de la solution ou rside sa limitation pour la gestion des
sondes ; cest quil faut avoir une licence pour chaque sonde ajout au-del des dix
sondes offerte au achat de la solution , nombre qui est faible pour un dploiement dune
solution SIM dans un rseau dune grande entreprise ou une banque . Mise part cet
inconvnient, une solution commerciale est toujours une boite noire qui est loin dtre
modelable ou personnalisable (personnalisation des rgles de corrlations par exemple)
en vis--vis ce quon peut faire dans une solution Open Source.

16

La deuxime solution tudi est OSSIM , lune des premire solutions SIM Open Source,
mais elle reste moyennement utilis suite sa difficult de dploiement due une documentation peu abondante et rare aussi , sauf quelle offre une interface graphique
riche et une grande modularit par rapport aux autres solutions SIM Open Source. Mais
linconvnient majeur de OSSIM est lis au format des alertes ; une alerte OSSIM peut
contenir plusieurs champs ( type, date, sensor, interface, plugin_id, plugin_sid, priority,
protocol, src_ip, src_port, dst_ip, dst_port, log, snort_cid, snort_sid, data, condition, value
), le champ log charg de contenir le log original nest pas trait par le serveur pour une
partie des plugins (NTsyslog, ), ce qui signifie que le log original est perdu et ne pourra
pas tre utilis. Si on ajoute cela le fait quOSSIM ne permet la transmission que dune
seule valeur du log (champ value) au moteur de corrlation, nous nous retrouvons avec
une granularit insuffisante compare la richesse dinformations que peuvent contenir
les logs originaux, et cest l o vient la robustesse de Prelude-SIEM en sa centralisation
et normalisation des donnes collectes, ainsi quune interface graphique amlior
(Prewikka) bien plus que ses prcdents (piwi, perl-front end ou php-front end ) , ainsi
quune flexibilit modulaire pour combler les diffrents manques par rapport au solution du march. Prelude-SIEM est une solution de grande qualit qui peut tre dployer
dans un environnement de production non pas comme OSSIM qui pose passablement
des problmes au niveau des phases dinstallation et test prliminaire.
Aprs longue rflexion, nous avons dcid dexploiter la suite Prelude-SIEM comme
structure dchange et de rcolte des messages de scurit, car elle rpond tous les
critres de base qui ont t dfini comme besoin.
2.1 Prelude-SIEM
2.1.1 Cration
Le Systme de Dtection dIntrusions (IDS) open source Prelude a t cr en 1998 par
Yoann Vandoorselaere. Depuis sa cration, des ingnieurs et spcialistes en scurit ont,
dans lesprit open source, contribu activement Prelude. Ce travail mnera, quelques
annes plus tard, au dveloppement dun systme de management de la scurit (SIM)
performant et universel devenu lun des plus largement dploy au monde.
La socit PreludeIDS Technologies a t co-fonde en mars 2005 par M. Yoann Vandoorselaere (Ingnieur en dveloppement, Expert scurit et Responsable R&D) et Mlle
Audrey Girard (Ingnieur en systmes industriels et Grante) avec lobjectif de repousser les frontires de Prelude open source au travers d'un nouveau type de solutions
commerciales.
PreludeIDS Technologies a connu une croissance rapide sur le march hautement comptitif de la scurit informatique et plus particulirement sur le march des systmes
de management de la scurit. Ils ont dvelopp, avec succs, un portefeuille clients

17

toff et prestigieux, incluant certains leaders des tlcoms, banques, groupes industriels ainsi que des organisations gouvernementales.
2.1.2 Dfinition
Prelude est un SIM Universel. Prelude collecte, normalise, catgorise, agrge, corrle et
prsente tous les vnements scurit indpendamment de la marque ou de la licence
du produit dont ces vnements sont issus : il est "Agentless".
En plus d'tre capable de collecter tout type de logs (journaux systmes, syslog, fichiers
plats, etc.), Prelude bnficie d'une compatibilit native avec certains systmes de faon
enrichir encore l'information (snort, samhain, ossec, auditd, etc.)
Les vnements scurit sont normaliss grce un format unique : l'IDMEF (Intrusion
Detection Message Exchange Format). IDMEF est une norme internationale cre l'initiative de l'IETF avec la participation des quipes Prelude pour permettre l'interaction
entre les diffrents outils scurit du march.
2.1.3 Composant :
Interface Prewikka
Prewikka est la console d'analyse graphique du SIM Universel Prelude. En fournissant de
nombreuses fonctionnalits, Prewikka facilite le travail des utilisateurs et analystes.
Cette interface permet de visualiser les alertes, que un ou plusieurs concentrateurs Prelude (prelude-manager) ont stock en base de donnes, de faon conviviale. Prewikka
fournit aussi des outils externes tels que "whois" ou "traceroute".
Manager Prelude
Le Manager Prelude est un concentrateur capable de prendre en charge un grand
nombre de connexions et de traiter de grandes quantits d'vnements. Il utilise des
files d'ordonnancement par sonde afin de traiter les vnements reus de faon quitable entre les diffrentes sondes.
Il est responsable de la centralisation, de la journalisation travers deux fonctions :
Celle de relais : un contrleur relais va assurer le routage vers un contrleur
matre (ou un autre relais dans le cas d'architecture en cascade) d'alertes provenant des
sondes qui lui sont rattaches
Celle de matre : un tel contrleur va assurer la rception des messages et alertes
provenant des sondes et/ou des contrleurs relais qui lui sont rattachs ainsi que leur
journalisation dans un format unique et lisible par lanalyste.
Il enregistre les vnements reus sur des mdias spcifis par lutilisateur (base de
donnes, journaux systme, Email, etc.) et tablit les priorits de traitement en fonction
de la criticit et de la source des alertes.

18

Un manager Prelude assure galement la remonte des tests de connexion (" heartbeats
") changs avec les sondes rseaux et locales. Ces tests permettent de vrifier la continuit de la communication entre sondes et contrleurs.
Libprelude
La bibliothque Libprelude permet la communication scurise entre les diffrentes
sondes et un Manager Prelude. Elle fournit une interface de programmation (API6) pour
la communication avec les sous-systmes Prelude et la gnration dalertes au format
standard IDMEF. Elle automatise lenregistrement et la retransmission des donnes en
cas dinterruption dun des composants du systme.
Libprelude facilite galement la mise en compatibilit de systmes externes qui deviennent ainsi capables de communiquer avec les composants Prelude. Cette bibliothque
fournit aussi des fonctionnalits communes et utiles toutes les sondes.
LibpreludeDB
La bibliothque PreludeDB fournit une couche d'abstraction par rapport au type et au
format de la base de donnes utilise pour stocker les alertes IDMEF7. Elle permet aux
dveloppeurs d'utiliser la base de donnes Prelude IDMEF facilement et efficacement
sans se soucier de SQL et d'accder la base de donnes indpendamment du
type/format de cette dernire.
Prelude-LML
Cette sonde prend en charge la remonte dalertes dtectes localement sur lhte. Cette
dtection est base sur lapplication des objets (fichiers de journalisation et/ou
dapplication) de rgles construites autour dexpressions rgulires compatibles Perl
(PCRE8).
Prelude-LML est comparable la faon quutilise Snort pour analyser des paquets via
des rgles. Dans le cas de Prelude-LML ses rgles essayent de correspondre des donnes dans les fichiers de logs au lieu des paquets rseau.
Prelude-LML a deux modes de fonctionnement principaux :
Monitoring des fichiers de logs
Rception upd des messages Sys log

Application Programming Interface

Intrusion Detection exchange format

Perl Compatible Regular Expression

19

Cette fonctionnalit fait de Prelude un outil extrmement flexible et facile mettre en

uvre dans n'importe quel rseau de production. Si un dispositif (machines distantes,
routeurs, firewalls) n'a pas la compatibilit natale avec Prelude, il peut tre configur
pour enregistrer ses Logs vers un serveur Syslog que Prelude-LML pourra contrler.
Voici une liste presque exhaustive des formats reconnus par cette sonde :
Firewalls Checkpoint6
Famille Cisco
Serveur SMTP exim7
Firewall grSecurity8
IPChains (Linux principalement)
IPFW (Familles *nix & Linux)
Firewalls utilisant IPSO (Checkpoint Firewall-1 & Nokia)
Netfilter / IPTables9
Windows NT (via lutilitaire NTSyslog)
Psionic PortSentry (Cisco)10
ProFTPd
Serveur POP3 QPopper (Eudora)11
Proxy HTTP Squid12
SSHd
vPOPMail
Firewall Zyxel Zywall
Equipements Zyxel (modems, routeurs, etc. . .)
Prelude-Correlator
Prelude-Correlator rend possible la corrlation multiflux grce un langage de programmation puissant permettant l'criture de rgles de corrlation. Tout type d'alertes
pouvant tre corrle, l'analyse des vnements devient plus simple, plus rapide et plus
pointue.
La mise en vidence des scnarii d'attaque par Prelude-Correlator nous permet de pointer de faon performante les vnements de scurit importants ayant lieu sur nos infrastructures.
Sa fonctionnalit est la suivante :

Identification rapide des vnements de scurit importants permettant de donner une priorit d'intervention et de hirarchiser les actions qui en dcoulent

Corrlation d'alertes en provenance de sondes htrognes dployes sur l'ensemble de l'infrastructure

Analyse en temps rel des vnements reus par le Manager Prelude

20

Prelude-Correlator permet de corrler, en temps rel, les multiples vnements reus

par Prelude. Plusieurs alertes isoles, issues de sondes multiples, peuvent ainsi dclencher une seule alerte de corrlation si les vnements sont lis. L'alerte de corrlation
apparait alors dans l'interface Prewikka et met en vidence les informations que nous
aurions choisi de pointer grce aux rgles de corrlation.
La cration de signature Prelude-Correlator est base sur le puissant langage de programmation Python. Le moteur de corrlation intgr de Prelude est distribu avec des
rgles de corrlation pr-enregistres mais il nous est possible de configurer n'importe
quelle rgle de corrlation rpondant nos besoins.
Le Mail Reporting Plugin
Le Mail Reporting Plugin envoie automatiquement des rapports dvnements par email
une liste de destinataires enregistrs. Le corps et le sujet de l'email gnr peuvent
tre totalement configurs pour y faire apparaitre, par exemple, l'vnement en entier
ou seulement certaines parties.
Ce plugin permet aussi l'interrogation de la base de donnes afin de joindre aux vnements entrants des vnements anciens qui leur sont lis. En utilisant le Mail Reporting
plugin en combinaison avec la fonctionnalit de filtrage du Manager Prelude, il est possible de gnrer des emails uniquement pour des vnements correspondants des critres spcifiques ou atteignant certains seuils.
Prelude-PFLogger
Prelude-PFlogger rcupre les paquets journaliss par le firewall OpenBSD et envoie les
alertes au Manager Prelude.
2.1.4 Architecture :
Distribue
Le caractre distribu d'un IDS construit au-dessus de Prelude est un fait qu'il ne faut
jamais perdre de vue lorsque l'on dploie des composants Prelude.
A l'inverse d'un autre produit issu du libre plus clbre, Prelude est bien une suite de
composants et non un logiciel monolithique.
Les composants Prelude - sondes et managers - ont t penss et dvelopps pour tre
autonomes (donc lgers car ddis une tche) et interactifs (les uns ne fonctionnent
pas sans les autres). Ainsi les sondes - rseau comme local - n'effectuent que les oprations de surveillance et de gnration des alertes. Les managers quant eux prennent en
charge la gestion des sondes et la journalisation des alertes. Dans certains cas, ils peuvent galement ne prendre en charge que le routage des alertes vers d'autres managers
(relay). Enfin, ils peuvent tre utiliss pour dclencher des actions de contre-mesure au
niveau d'un sous-rseau particulier tout en assurant la remonte des alertes vers les
contrleurs de niveau suprieur.
21

Cela se traduit en pratique par la possibilit d'installer autant de sondes et de contrleurs que souhait ou ncessaire, afin d'assurer la redondance des composants et/ou de
s'adapter la charge et la complexit d'un rseau, tout en ayant l'assurance d'obtenir
une journalisation centralise dans un format homogne.
Scurise
Le "modle de scurit" de Prelude est un des points forts du produit.
Tous les composants sont construits au-dessus de la librairie libprelude qui peut tre
compile avec le support SSL (utilisant les fonctions fournies par la suite openSSL).
Ce support permet deux choses :
- Une authentification "forte" des composants entre eux ;
- Le chiffrement des communications entre composants.
L'authentification des sondes par les managers est donc effectue sur la base de certificats et le transfert des messages entre ces composants bnficient du chiffrement.
Cela signifie qu'il est possible de :
- Dployer un IDS Prelude sur des sous-rseaux distants relis entre eux par des
canaux non srs (comme Internet) tout en conservant la possibilit de centraliser la
journalisation des alertes ;
- Ne pas avoir installer un LAN ddi la dtection d'intrusions sur les rseaux
concerns par l'IDS.
Donc, pour tre prise en compte par un manager, une sonde doit au pralable avoir t
dclare - enregistre - auprs de celui-ci. Dans le cas de sondes et managers supportant
SSL, cela se traduit par la gnration d'une clef prive sur la sonde et d'un certificat sur
le manager qui la prendra en compte.
Fiable
Si pour une raison ou une autre une sonde n'arrive plus envoyer ses alertes un manager auprs duquel elle est enregistre, ces dernires sont conserves localement jusqu' rtablissement de la connexion avec un manager. Cette fonctionnalit est fournie
par la librairie libprelude, brique de base de tout composant Prelude.
Extensible.
A tous les niveaux ou presque il est possible d'tendre les capacits des composants Prelude l'aide de module additionnel (plugin).
Ces modules peuvent ainsi au :
- Niveau des sondes : assurer le support de nouveaux protocoles ou d'applications ;
- Niveau des managers : permettre un mode alternatif de journalisation.
Il est galement possible d'tendre les capacits et fonctionnalits de l'IDS en intgrant
d'autres produits (exemple : des sondes plus performantes, des programmes plus spcifiques, etc) toujours grce la librairie libprelude.

22

Exemple darchitecture possible :

Architecture simple :
Prelude est divis en plusieurs composantes. Les capteurs sont responsables de la dtection d'intrusion, et faire des rapports sur les vnements d'une manire centralise en
utilisant une connexion TLS un serveur Prelude-manager '. Le serveur PreludeManager peut alors traiter les rapports des vnements et les dlivrer un utilisateur
dun serveur donnes (base de donnes MySQL, base de donnes PostgreSQL, XML, tout
format condition qu'il y est un plugin).
La console Prelude peut alors tre utilise pour afficher les rapports dvnements.
Voici un exemple simple de la faon dont les diffrents composants Prelude interagissent:

Figure 5 : Architecture simple

Architecture relai:
Le relais est une fonction qui permet au programme de Prelude-Manager de faire un
Frowarding des vnements reus un autre programme de Prelude-Manager.
Dans l'exemple de la figure 6, Branch A de l'organisation a seulement laccs aux vnements gnrs par le capteur A, B et C . Toutefois, le Security Center peut voir les
vnements gnrs tant par ses propres capteurs (D, E et F), ainsi que les vnements
gnrs par les autres branches de l'organisation (comme A, B, C, etc.)

23

Figure 6 : Architecture relai

Architecture Relai-Invers :
Sur certains rseaux, il peut parfois tre difficile ou gnant dorganiser des autorisations
rseau afin qu'un programme peut se connecter un serveur hors d'une zone donne
(par exemple, un pare-feu pourrait ne pas permettre aux machines de la DMZ9 de se
connecter en dehors de leur propre rseau).
Dans ce cas prcis, on peut configurer un Prelude-Manager externe pour se connecter
un autre Prelude-Manager interne situ l'intrieur du rseau DMZ, et lire les vnements mis par elle.

Figure 7 : Architecture relai invers

Zone dmilitarise (Demilitarized Zone)

24

2.2 Format standard

Les deux principales propositions de standards allant dans le sens dune uniformisation
des changes de messages lis la scurit sont le CIDF10 et lIDMEF11.
2.2.1CIDF
Le CIDF, pour Common Intrusion Detection Framework a t une tentative du US governements Defense Advanced Research Project (DARPA) pour dvelopper un langage
(Protocole & format de messages) dchange entre IDS et manager pour leur utilisation
interne en premier lieu. Cette proposition de standard a t juge trs lourde et peu utilisable par les dveloppeurs de solutions IDS et na t que trs rarement utilise dans
des applications concrtes. Toutefois, une partie du concept et des bons points de ce
langage ont t rutiliss dans IDMEF.
2.2.2 IDMEF
Prsentation
LInternet Engineering Task Force (IETF) est lorganisme responsable du dveloppement
de nouveaux standards Internet. Cet organisme a form un groupe de travail, lIntrusion
Detection exchange format Working Group (IDWG12), qui incombe maintenant la cration dun format dchange commun pour les alertes provenant dIDS.
Ce groupe de travail a propos IDMEF, un format de description des alertes bas sur
XML, comme base dchange entre les IDS et les managers ou tout autre quipement qui
doit interagir avec ces derniers. Une grande attention a t porte aux besoins des applications qui analysent les alertes des IDS, afin quelles se voient fournir toutes les informations ncessaires leur bon fonctionnement. Notons encore quIDMEF est totalement
indpendant du protocole de communication et que sa construction base sur XML le
rend compatible avec les futurs firewalls applicatifs intelligents XML.
Structure dun message IDMEF
La structure des messages IDMEF est hirarchique et peut sapparenter un modle de
classe en programmation oriente objet. La classe parente est IDMEF-Message et tous les
messages IDMEF sont drivs de cette dernire. Actuellement, il y a deux types (classes
drives) de messages IDMEF : lalerte (Alert) et le Heartbeat. Nous pouvons voir les relations entre les principaux composants dans la figure 8. Cette reprsentation est une
version simplifie du modle complet, mais est suffisamment dtaille pour en comprendre le concept.

10

http://www.isi.edu/gost/cidf/

11

http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-10.txt

12

http://www.ietf.org/html.charters/idwg-charter.html

25

Il est encore important de noter que ce modle de donnes ne prcise pas comment une
alerte doit tre classifie ou identifie. Par exemple, un port-scan peut tre identifi par
un analyseur comme attaque unique contre de multiples cibles, alors quun autre y verra
une attaque multiple depuis une source unique. Toutefois, ds quun analyseur a dtermin le type dalerte quil souhaite envoyer, le modle de donnes lui indique comment
la formater.
Contenu dun message IDMEF
Comme il existe un grand panorama dIDS (HIDS, NIDS, dtection base sur les signatures ou heuristique). LIDWG a fait grand travail afin quIDMEF puisse sadapter cette
diversit, en focalisant les informations sur ce que lIDS a dtect plutt que Comment il la dtect.
La figure 8 nous montre la construction hirarchique en classe du message IDMEF.

Figure 8 : Structure d'un message IDMEF

26

La signification et lutilit de ces principales proprits :

La classe IDMEF-Message : Tous les messages IDMEF sont drivs de cette classe.
Cest le niveau suprieur du modle IDMEF et de sa DTD13 associe. Il y a actuellement
deux types de messages IDMEF : lalerte (Alert) et le Heartbeat.
La classe Alert : Gnralement, chaque fois quun analyseur dtecte un vnement, il
envoie une alerte son (ses) manager(s). Suivant le type danalyseur, ce message peut
correspondre un vnement unique ou de multiples vnements.Cette classe Alerte
comporte aussi une proprit optionnelle ident, qui permet dattribuer un identificateur
lalerte.
La classe Classification : Elle peut tre instancie de manire unique ou multiple.
Elle contient, si possible, un nom identifiant lalerte daprs une liste standardise (bugtraq5, cve6, etc. . .) ou un identifiant spcifique limplmentation, si ladite alerte nest
pas encore rpertorie. Cette proprit est intressante, car elle permet deux IDS
nutilisant pas le mme algorithme de dtection de rapporter la mme erreur leur
manager.
La classe Analyzer : Cette classe dfinit sil sagit dun message dalerte ou dun heartbeat. Notons quil est impratif quune seule de ces classes ne soit instancie dans un
message dalerte.
La classe AdditionalData : Cette classe peut tre vide ou contenir des informations qui
nont pas leur place ailleurs dans le message. On peut aussi imaginer utiliser cette classe
pour fournir un dump complet du trafic qui a provoqu lalerte.
La classe Heartbeat : Les analyseurs envoient priodiquement des messages heartbeat
pour indiquer leur manager quils sont en fonction (up and running). Labsence de rception de ces messages indique que la connexion rseau est dfectueuse ou que
lanalyseur a un problme.
La classe CreateTime : Une estampille temporelle y est place, indiquant la date de
cration de lalerte ou du heartbeat.
De par sa construction intelligente et sa gratuit dutilisation, ladoption dIDMEF
comme standard dchange de messages semble incontournable. De plus, il permettrait
notre futur produit dtre compatible avec dautres solutions.
2.3 Compatibilit
Prelude est un SIM interoprable avec tous les systmes disponibles sur le march. Quelle que soit notre configuration, inutile de remplacer nos quipements scurit :
Prelude sadapte linfrastructure et non linverse.

13

Document Type Definition. Cest un fichier annexe ou une dfinition intgre tout document XML, afin de
dfinir sa structure et de valider son contenu.

27

Lorsquon installe Prelude, deux solutions s'offrent nous :

Renvoyer les logs des solutions vers Prelude
Connecter directement les solutions compatibles nativement avec Prelude .

Figure 9 : Tableau de compatibilit de Prelude

28

Chapitre 3 : Sondes et sources

dinformations

29

3.1 Qualit indispensable

Garantir la scurit et lintgrit des transactions
Un systme de scurit ne peut tre considr comme efficace sil est lui-mme vulnrable aux attaques et aux dnis de service. De plus, il est impratif de garantir
lauthenticit et lintgrit des messages reus des diffrentes sondes. Les trois notions
cls ici sont confidentialit, intgrit et authentification (CIA).
Le protocole de choix pour ce travail est SSL en version 2.0, pour Secure Sockets Layers,
que lon pourrait traduire par couche de sockets scurise. Cest un procd de scurisation des transactions effectues via Internet mis au point par Netscape, en collaboration
avec MasterCard, Bank of America, MCI et Silicon Graphics. Il repose sur un procd de
cryptographie par clef publique afin de garantir la scurit de la transmission de donnes sur Internet ou sur un LAN. Le systme SSL est indpendant du protocole utilis, ce
qui signifie quil peut aussi bien scuriser des transactions faites sur le Web par le protocole HTTP que des connexions via le protocole FTP, POP ou autres. En effet, SSL agit
telle une couche supplmentaire, permettant dassurer la scurit des donnes, situe
entre la couche application et la couche transport.(fig10).

Figure 10 : Modle avec la couche SSH

Format des messages

Vu que le choix sest port sur une plateforme de base Prelude et aussi un choix
dadopter un format de message standard, compatible avec de futures applications, il est
clair que lutilisation dIDMEF est incontournable. On fera appel aux fonctions
dauthentification et de cryptage fournies par LibPrelude pour garantir la scurit des
changes.
Les IDS
Les IDS14 est un mcanisme destin reprer des activits anormales ou suspectes sur la
cible analyse (un rseau ou un hte). Il permet ainsi d'avoir une connaissance sur les
tentatives russies comme choues des intrusions.

14

Intrusion Detection System/systme de dtection d'intrusion

30

Il existe trois grandes familles distinctes dIDS :

Les NIDS (Network Based Intrusion Detection System), qui surveillent l'tat de la
scurit au niveau du rseau.
Les HIDS (HostBased Intrusion Detection System), qui surveillent l'tat de la scurit au niveau des htes.
Les HbIDS ( IDS hybrides), qui utilisent les NIDS et HIDS pour avoir des alertes
plus pertinentes.
NIDS

Figure 11 : Fonctionnement des NIDS

Un NIDS se dcoupe en trois grandes parties : La capture, les signatures et les alertes.

Capture :

La capture sert la rcupration de trafic rseau. En gnral cela se fait en temps rel,
bien que certains NIDS permettent l'analyse de trafic captur prcdemment.
La plupart des NIDS utilisent la bibliothque standard de capture de paquet libpcap. La
bibliothque de capture de paquets Packet Capture Library est porte sur quasiment
toutes les plateformes, ce qui permet en gnral aux IDS rseau de suivre.
Le fonctionnement de la capture d'un NIDS est donc en gnral fortement li
cette libpcap. Son mode de fonctionnement est de copier (sous Linux) tout paquet arrivant au niveau de la couche liaison de donnes du systme d'exploitation. Une fois ce
paquet copi, il lui est appliqu un filtre BPF (Berkley Packet Filter), correspondant
l'affinage de ce que l'IDS cherche rcuprer comme information.

31

Signatures

Les bibliothques de signatures (approche par scnario) rendent la dmarche d'analyse

similaire celle des antivirus quand ceux-ci s'appuient sur des signatures d'attaques.
Ainsi, le NIDS est efficace s'il connat l'attaque, mais inefficace dans le cas contraire. Les
outils commerciaux ou libres ont volu pour proposer une personnalisation de la signature afin de faire face des attaques dont on ne connat qu'une partie des lments. Les
outils base de signatures requirent des mises jour trs rgulires.
Les NIDS ont pour avantage d'tre des systmes temps rel et ont la possibilit de dcouvrir des attaques ciblant plusieurs machines la fois. Leurs inconvnients sont le
taux lev de faux positifs qu'ils gnrent, le fait que les signatures aient toujours du
retard sur les attaques de type 0day et qu'ils peuvent tre la cible d'une attaque.

Alertes

Les alertes sont gnralement stockes dans le syslog. Cependant il existe une norme qui
permet d'en formaliser le contenu, afin de permettre diffrents lments de scurit
d'interoprer. Ce format s'appelle IDMEF dans la RFC4765. IDMEF est popularis par le
projet Prelude, qui offre une infrastructure permettant aux IDS de ne pas avoir s'occuper de l'envoi des alertes. Cela permet aux IDS de n'avoir qu' dcrire les informations
qu'il connat et Prelude se charge de les stocker pour permettre une visualisation comprhensible.

Pattern matching15

Le pattern matching est ce qui permet un NIDS de trouver le plus rapidement possible
les informations dans un paquet rseau.
Dans le cas d'un NIDS, le pattern matching est souvent le nud d'tranglement. Pouvant
consommer plus de quatre-vingt pourcent de temps de calcul.

Analyse

Le moteur d'analyse met ces lments de relation en employant plusieurs techniques :

la refragmentation, la dissection protocolaire ou encore l'analyse comportementale.

La refragmentation

Les paquets dpassant une certaine taille (qui en gnral est de 1 500 octets) sont fragments. La fragmentation de l'en-tte de la couche transport tant aussi possible, cela

15

La recherche de motif

32

rendait les NIDS vulnrables aux attaques de Stick et de Snot16 car les paquets fragments n'taient pas analyss.
Les NIDS ont le devoir de refragmenter les paquets avant analyse, afin de ne pas manquer une attaque. Il s'agit d'une opration relativement complexe, tant donn que
chaque hte de destination ne refragmente pas de la mme faon, selon le systme d'exploitation sur lequel l'attaque est vise. Il s'agit encore d'une technique d'vasion utilisable aujourd'hui car les NIDS ne sont pas forcment configurs correctement pour grer un cas prcis.

La dissection protocolaire

La dissection permet de comprendre un protocole donn, de le dcoder pour l'analyser.

Il s'agit de la partie la plus sensible des NIDS car c'est elle qui est le plus grand vecteur
d'attaques.
Cependant, la dissection est essentielle sur certains protocoles, comme RPC, afin de pouvoir dtecter des attaques qui seraient invisibles sans cette indispensable dissection.
Cette tape permet aussi de rcuprer un champ prcis d'un protocole applicatif ce qui
peut simplifier l'criture de signatures.
HIDS
Les HIDS, pour Host based IDS, signifiant "Systme de dtection d'intrusion machine"
sont des IDS ddis un matriel ou systme d'exploitation. Contrairement a un NIDS, le
HIDS rcupre les informations qui lui sont donnes par le matriel ou le systme d'exploitation. Il y a pour cela plusieurs approches : signatures, comportement (statistiques)
ou dlimitation du primtre avec un systme d'ACL. Un HIDS se comporte comme
un daemon ou un service standard sur un systme hte qui dtecte une activit suspecte
en sappuyant sur une norme. Si les activits sloignent de la norme, une alerte est gnre. La machine peut tre surveille sur plusieurs points :

Activit de la machine : nombre et listes de processus ainsi que d'utilisateurs,

ressources consommes, ...

Activit de l'utilisateur : horaires et dure des connexions, commandes utilises,

messages envoys, programmes activs, dpassement du primtre dfini...

Activit malicieuse d'un ver, virus ou cheval de Troie

16

Techniques utilises pour tromper le moteur de lIDS en fragmentant lattaque dans plusieurs paquets, ainsi
la reconstruction se fait aprs quils aient traverss lIDS

33

Le HIDS a pour avantage de n'avoir que peu de faux positifs, permettant d'avoir des
alertes pertinentes. Quant ses inconvnients il faut configurer un HIDS par poste et
cela demande une configuration de chaque systme.

IDS hybride

Figure 12 : Fonctionnement d'un HybIDS

Les IDS hybrides sont bass sur une architecture distribue, o chaque composant unifie
son format d'envoi d'alerte (typiquement IDMEF) permettant des composants divers
de communiquer et d'extraire des alertes plus pertinentes.
Les avantages des IDS hybrides sont multiples :

Moins de faux positifs

Meilleure corrlation
Possibilit de raction sur les analyseurs
Les Honey Pot

Un Honeypot (littralement pot de miel) c est une mthode utilise dans le domaine de
la dtection d'intrusion se basant un serveur ou programme volontairement vulnrable,
destin attirer et piger les pirates. Situ devant ou derrire un pare-feu, cet appt
laisse croire aux intrus qu'ils se trouvent sur une machine de production normale
alors qu'ils voluent sur un leurre. On aura alors tout loisir d'observer leur manire de
faire et d'enregistrer leurs mthodes d'attaques.
Les honeypots sont des systmes de scurit qui nont aucune valeur de production. Ds
lors, aucun utilisateur ni aucune autre ressource ne devrait en principe avoir communiquer avec lui. Lactivit ou le trafic attendu sur le honeypot tant nul la base, on en
dduit alors que toute activit enregistre par cette ressource est suspecte par nature.
Ainsi, tout trafic, tout flux de donnes envoy un honeypot est probablement un test,
34

un scan ou une attaque. Tout trafic initi par un honeypot doit tre interprt comme
une probable compromission du systme et signifie que lattaquant est en train
deffectuer des connexions par rebond.
Gnralement, un honeypot se comporte telle une bote noire, enregistrant passivement
toute lactivit et tout le trafic qui passe par lui.
Il faut savoir que le trafic capt par les honeypots est la fois rduit (effet microscope)
et suspect par nature. Les fichiers des enregistrements dvnements (fichiers de logs)
sont donc peu volumineux et il est plus ais didentifier une activit malveillante. En
fonction de la nature des donnes collectes, on pourra ainsi retracer prcisment les
flux changs:

provenance,
activit,
date,
dure,
volume ... et parfois mme, le contenu des donnes changes (keystrokes, messages IRC par exemple).

Il existe diffrentes catgories de honeypot selon le niveau dinteraction que lon souhaite offrir aux attaquants :
Les honeypots de trs faible interaction se contentent de simuler certains services notoirement connus tels que lactivit apparente dun serveur web, dun serveur de
messagerie, dun serveur de transfert de fichier, etc. Lobjectif de ce type de honeypot est
par exemple didentifier les adresses sources de pirates et aussi et surtout les premires
commandes de base. Ce type de honeypot napporte gure dinformation prcise sur les
procds et les mthodes dattaque.
Les honeypots de moyenne interactivit fournissent un ensemble de services labors lattaquant. Ce type de honeypot est souvent dploy sur un poste hte.
Les honeypots de trs grande interactivit fournissent des systmes
dexploitation ou un rseau tout entier lattaquant. Ce dernier type de honeypot est
souvent ddi la recherche comportementale et psychologique pour le profilage des
pirates.
Les Firewall
Un pare-feu/firewall, est un systme logiciel, reposant parfois sur un matriel rseau
ddi (appliance) , constituant un intermdiaire entre le rseau local (ou la machine locale) et un ou plusieurs rseaux externes, qui a pour fonction de faire respecter
la politique de scurit du rseau, celle-ci dfinissant quels sont les types de communication autoriss ou interdits . Pour cela, le pare-feu analyse les informations contenues
dans les couches 3, 4 et 7 du modle OSI et contrle ainsi les informations en transit.
Cest est un systme permettant de protger un ordinateur ou un rseau d'ordinateurs
des intrusions provenant d'un rseau tiers (notamment internet), il s'agit ainsi

35

d'une passerelle filtrante comportant au minimum les interfaces rseau ; une interface
pour le rseau protger (rseau interne) et une interface pour le rseau externe.

Figure 13 : Fonctionnement d'un pare-feu

Il a pour principale tche de contrler le trafic entre diffrentes zones de confiance, en

filtrant les flux de donnes qui y transitent. Gnralement, les zones de confiance incluent Internet (une zone dont la confiance est nulle), et au moins un rseau interne (une zone dont la confiance est plus importante.)
Le but ultime est de fournir une connectivit contrle et matrise entre des zones de
diffrents niveaux de confiance, grce l'application de la politique de scurit et d'un
modle de connexion bas sur le principe du moindre privilge.
Le filtrage se fait selon divers critres. Les plus courants sont :
l'origine ou la destination des paquets (adresse IP, ports TCP ou UDP, interface
rseau, etc.) ;
les options contenues dans les donnes (fragmentation, validit, etc.) ;
les donnes elles-mmes (taille, correspondance un motif, etc.) ;
les utilisateurs pour les plus rcents.
Un pare-feu fait souvent office de routeur et permet ainsi d'isoler le rseau en plusieurs
zones de scurit appeles zones dmilitarises ou DMZ. Ces zones sont spares suivant le niveau de confiance qu'on leur porte.

36

Un systme pare-feu contient un ensemble de rgles prdfinies permettant :

D'autoriser la connexion (allow) ;
De bloquer la connexion (deny) ;
De rejeter la demande de connexion sans avertir l'metteur (drop).
L'ensemble de ces rgles permet de mettre en uvre une mthode de filtrage dpendant
de la politique de scurit adopte par l'entit. On distingue habituellement deux types
de politiques de scurit permettant :
soit d'autoriser uniquement les communications ayant t explicitement autorises
soit d'empcher les changes qui ont t explicitement interdits.
Principales techniques de dtection

Le filtrage de paquets

Les premiers pare-feux taient les routeurs eux-mmes. Ceux-ci sappuyaient donc sur
du filtrage de paquets IP, laide dune analyse des enttes des datagrammes en transit.
Les pare-feux peuvent effectuer du filtrage, sur la couche 3 du modle OSI, bas sur les
adresses IP (source ou destination), on parle de filtrage par adresse (address filtering),
ou peuvent effectuer du filtrage sur les protocoles de transmission, on parle alors de
filtrage par protocole (protocol filtering). Enfin le pare-feu peut tre configur pour bloquer tout le trafic arrivant sur certains ports afin dempcher des postes extrieurs
daccder des services non indispensables de lextrieur. Un firewall possdant plusieurs interfaces, dont une DMZ, peut affiner ces rgles de blocage pour les rorienter
vers linterface rseau adquate (ex. : le port 80 vers le serveur WEB de la DMZ).

Le filtrage dynamique

Il existe des services comme le FTP qui utilisent un port statique pour la connexion, puis
des ports dynamiques (au-dessus des ports rservs pour les services standards <1024)
pendant les transferts.
Il existe donc un systme de filtrage dynamique de paquets (stateful inspection) bas
sur l'inspection des couches 3 et 4 du modle OSI. Il permet d'effectuer un suivi des
transactions entre le client et le serveur et donc d'assurer la bonne circulation des donnes de la session en cours. Un paquet qui nappartiendrait pas une session encore active sera soumis au filtrage prdfini.
Le filtrage dynamique est plus performant que le filtrage de paquets standard mais ne
protge pas contre les failles applicatives (failles lies aux logiciels).

37

Le filtrage applicatif

Le dernier type de filtrage utilis est au niveau applicatif (couche 7 du modle OSI). Il
permet de contrler les communications au niveau des applications (analyse application
par application). Ce filtrage ncessite une connaissance parfaite de la structure des donnes changes par les applications.
Un firewall effectuant un filtrage applicatif est appel passerelle applicative car il permet
de relayer des informations entre deux rseaux en effectuant un filtrage fin au niveau du
contenu des paquets changs. Ce type de filtrage est trs performant et assure une
bonne protection du rseau mais ncessite une grande puissance de calcul au niveau du
firewall. Sur des rseaux de taille importante, lutilisation dun tel firewall est difficile
mettre en place et ralentit les communications.
Certaines applications propritaires ou non standards ne permettent pas la mise en
place de ce type de firewalls.
Les pare-feu rcents embarquent de plus en plus de fonctionnalits, parmi lesquelles on
peut citer :

17

Filtrage sur adresses IP/Protocole,

Inspection stateful et applicative,
Intelligence artificielle pour dtecter le trafic anormal,
Filtrage applicatif
HTTP (restriction des URL accessibles),
Courriel (Anti-pourriel)
Logiciel antivirus, anti-logiciel malveillant
NAT17,
Tunnels IPsec, PPTP, L2TP,
Identification des connexions,
Serveurs de protocoles de connexion (Telnet, SSH), de protocoles de transfert de
fichier,
Clients de protocoles de transfert de fichier (TFTP),
Serveur Web pour offrir une interface de configuration agrable,
Serveur mandataire ( proxy ),
Systme de dtection d'intrusion ( IDS )
Systme de prvention d'intrusion ( IPS )

Traduction d'adresse rseau/ Network Address Translation

38

La corrlation
SEC
SEC (Simple Event Correlator) est un programme crit en PERL qui permet de surveiller
des fichiers de logs pour y dtecter des motifs. Il est aussi utilis pour corrler certains
vnements afin de diminuer le nombre de fausses alertes.
SEC est un logiciel multiplateforme de corrlations d'vnements Open Source ,il accepte les entres d'un fichier, d'un tube nomm (pipe) ou de l'entre standard et peut
donc tre employer comme couche de corrlation par tous programmes crivant leurs
sorties d'vnements dans un flux de fichier.
La configuration de SEC est stocke comme rgles dans des fichiers texte, chaque rgle
dcrivant l'vnement sur lequel ragir, l'action mener. Les expressions rgulires
peuvent tre utilises pour dfinir les conditions de l'vnement. SEC peut lui-mme
produire des vnements en sortie en excutant des scripts shell ou des programmes
externes (snmptrap, courrier lectronique, filtrage ip) et/ou en crivant des messages
vers des tubes ou des fichiers.
SEC est utilis dans des domaines aussi varis que la gestion des rseaux, le monitoring
systme, la scurit des donnes, la dtection d'intrusions, la surveillance et l'analyse de
fichiers journaux, etc. SEC est utilis ou intgr dans des produits aussi diffrents que HP
OpenView NNM, CiscoWorks, BMC Patrol, Nagios, SNMPTT, Snort IDS, Prelude IDS, etc.
Les types de rgles de corrlation suivants sont implmentes dans SEC :
Single : Dtection dun motif et excution daction parmi celles supportes
par SEC.
SingleWithScript : Dtection dun motif et excution daction parmi celle
supporte par SEC en fonction du code de sortie d'un script ou programme externe.
SingleWithSuppress : Dtection dun motif et excution daction parmi
celles supportes par SEC, mais ignore les motifs dtects suivants pendant t secondes suivantes.
Pair : Dtection dun motif et excution daction parmi celles supportes
par SEC, ignore les motifs dtects suivants jusqu' la dtection d'un motif diffrent.
Excute une action l'arrive du deuxime motif.
PairWithWindow : Dtection dun motif et attente pendant t secondes
dun motif diffrent. Si ce deuxime motif n'est pas dtect au bout de ce temps, excution daction. Si ce deuxime motif est dtect dans le laps de temps, excute une autre
action.
SingleWithThreshold : Calcul du nombre de motifs semblables pendant t
secondes et si un certain seuil est dpass, excution daction et ignore les nouveaux
motifs pendant le reste du temps. La fentre de temps prcise avec t est coulissante.
SingleWith2Thresholds : La mme rgle que prcdemment combin
deux fentres de temps.
Suppress : Suppression de motif dtect.
Calendar : Excution daction une certaine date et heure.

39

Prelude-IDS et Snort
Projet
Ce sont tous les deux des outils libres. Parmi les avantages de Snort sont sa popularit et
sa disponibilit sur de nombreuses plateformes. Prelude-IDS se restreint sur les plateformes POSIX18 alors quon peut retrouver Snort sur Windows. A cela sajoute
limportance de la base de donnes des signatures dattaque de Snort, pour expliquer sa
plus grande popularit. Mais Prelude-IDS est de plus en plus connu dans le monde des
professionnels de la scurit.
Une diffrence importante cependant, au dsavantage de Snort est sa nature , il est NIDS
pur alors que Prelude-IDS intgre des fonctionnalits NIDS et HIDS.
Moteur danalyse et banque de signatures
Les deux font une analyse par recherche de similitudes avec un scnario pralablement
dnis. Le mode de fonctionnement est alors similaire. Autant pour Prelude-IDS que
pour Snort, les solutions sont stables. Notons que mme en intgrant les alertes de
Snort, Prelude-IDS relve une quantit plus importante dalertes. Prelude-NIDS archive
aussi les payloads.
Prelude-IDS a lavantage dtre trs modulaire de par son architecture client-serveur. Un
manager peut grer plusieurs sondes, et une sonde peut envoyer ses alertes plusieurs
managers.
La remonte dalertes
En utilisant ces outils, on se rend compte du fait que Prelude-IDS remonte un nombre
plus important dalertes que Snort. L o Snort remonte 30 alertes de 2 types diffrents,
Prelude-IDS remonte parfois 2000 alertes de 3 types diffrents. Prelude la capacit de
dtection dun plus grand nombre dattaque. Cela est d lutilisation des mmes signatures que Snort en plus des siennes.
Intgration doutils externes
La grande force de Prelude-IDS est de pouvoir intgrer les fonctionnalits dautres outils
de scurit de rfrence. On peut, par exemple, utiliser Honeyd comme une sonde, envoyer les rsultats vers le manager qui les intgrera ensuite dans la base de dones.
La banque de scnario de Snort peut aussi tre rcupre par Prelude-NIDS et ajoute
aux rgles de Prelude-IDS. Ainsi, le nombre important de signatures reconnues par Snort
(et qui participe sa popularit) bncie Prelude-IDS.

18

Portable Operating System for Computer Environment. C'est une srie de standards IEEE pour Unix

40

3.2 Intgration de sources dinformation externes

Firewall
*BSD Packet Filter
Packet Filter (que nous appellerons dsormais PF) est le systme utilis par OpenBSD
pour filtrer le trafic TCP/IP et effectuer des oprations de Traduction d'Adresses IP
("NAT"). PF est aussi capable de normaliser, de conditionner le trafic TCP/IP, et de fournir des services de contrle de bande passante et gestion des priorits des paquets. PF
fait partie du noyau GENERIC d'OpenBSD depuis la version 3.0. Les prcdentes versions
d'OpenBSD utilisaient un ensemble logiciel pare- feu/NAT diffrent qui n'est plus support.

PFLogger est un composant utilis pour rassembler les Logs du firewall PF d'OpenBSD.
Paquet Filter (PF) est un systme de filtrage pour le trafic TCP/IP d'OpenBSD et aussi la
Traduction d'Adresse de Rseau NAT. Quand PFlogger est install le plugin PreludePFlogger coute les paquets journaliss et envoie les alertes Prelude-Manager.
Firewall Personnel
L encore, lincorporation de diffrents firewalls personnels est trs facilite grce la
structure fournie par Prelude. Ainsi, nimporte quel applicatif ou matriel de filtrage utilisant la journalisation NT, Syslog ou des fichiers locaux pour inscrire ses alertes est
compatible avec Prelude. La seule limitation est lexistence dune expression rgulire
Perl dans le fichier de configuration de Prelude-LML qui permet ce dernier de parser
correctement les entres. Dans la ngative, il est toujours possible dy ajouter ses
propres expressions.
IDS :
Snort
SNORT est un NIDS (Network Intrusion Detection System), une cration de Martin
Roesh, cette solution sest impose dans le march pour tre parmi les IDS les plus utiliss, possdant aussi une communaut importante contribuant son succs. Actuellement SNORT appartient SourceFire.
SNORT est capable deffectuer en temps rel une analyse de trafic et de logger les paquets sur un rseau IP, aussi quune analyse protocolaire et le pattern matching de contenu. Son fonctionnement en ligne de commande le laisse riche en son utilisation avec de
nombreuse option en main. Les fonctionnalits de SNORT permettent de faire un SNIFFING de rseau, effectuant une journalisation ainsi donc pour dtecter dventuels intrusion. Son moteur de dtection utilise une architecture modulaire de plug-in, il a aussi
une grande capacit modulaire dalertes en temps rel, incorporant des mcanismes
41

dalertes pour SYSLog, des fichiers spcifi pour lutilisateur , une socket UNIX, ou des
messages WINPOPUP des clients WINDOWS en utilisant smbClient de SAMBA. Sans
oublier quil peut faire de la journalisation sous diffrentes format, un format binaire
tcpdump ou aussi le format ASCII dcod de SNORT vers un ensemble hirarchique de
rponse qui sont nomms daprs ladresse IP du systme tranger .
SNORT utilise un langage de rgle flexible lui permettant de soit collecter ou de laisser
passer le trafic rseau. Il peut tre considrer comme NIPS19 via SNORT-Inline , interdisant ainsi tout trafic provenant de l adresse IP de lattaquant ou bien toute une classe
dadresse IP.

Bien que lutilisation de Snort en parallle avec Prelude-NIDS soit redondante (ils sont
issus de sources trs communes et emploient une base de signatures identique), il suffit
de patcher les sources de Snort laide des correctifs mis disposition sur le site de Prelude-IDS pour que ce dernier fasse partie intgrante de la plateforme.
OSSEC
Ossec (http://www.ossec.net) est une application de dtection dintrusion, et plus prcisment un HIDS (Host Intrusion Detection System). Il permet de surveiller lintgrit des
fichiers systmes, aussi bien sur des postes Linux que Windows.
De plus, Ossec dtecte galement des attaques de pirates comme les rootkits, les scans
de ports, et analyse les logs du systme, des applications et des services. Le logiciel propose galement un systme de rponses actives, cest--dire dactions raliser en cas
dattaque, comme par exemple changer les paramtres dun parefeu. Tout comme Snort,
il dispose de nombreuses rgles lui offrant un large panel de dtection dattaques, de
problmes sur le poste sur lequel il est install.
Ossec peut galement fonctionner selon le modle client/serveur, avec un serveur ddi
Ossec, et sur tous les postes clients (serveurs) surveiller une installation du logiciel
client, qui est alors charg denvoyer les vnements, les alertes au serveur.
Ossec fonctionne essentiellement sur Linux, mais il peut surveiller galement des postes
Windows grce une application cliente spcialement dveloppe pour, mais pour la
version serveur, seul un systme dexploitation Linux est support.

19

Network Intrusion Prevention System

42

Honey Pot :
HoneyD
HoneyD est un projet pot de miel Open Source sous licence GNU GPL dvelopper par
Niles Provos ingnieur Google. Cest un Deamon permettant de dployer des machines virtuelles sur un rseau utilisant des adresses IP non attribues sur le rseau,
ainsi donc pour dtecter toute activit frauduleuse tant donn que personne nest sens
sy connect voulant dire ainsi que toute tentative de connexion une adresse IP dfinit
virtuellement peut tre interprter comme non autorise et suspecte. Son but est
aussi de dtecter des attaques que de dcouvrir de nouvelles attaques. Toutes donnes
entrantes et sortantes de ce Honey Pot20 est en vue dtre analyser.
HoneyD regroupe deux modes de fonctionnement distincts :
- Capable de simuler, sur un rseau, la prsence de machines de tous types (jusqu
65536 machines la fois ; PC et quipements de routages). Ces htes peuvent tre configurs pour qu'ils paraissent fonctionner sous certains systmes d'exploitations, et ce
grce des Template ; afin d'accroitre l'effet de ralit, ces machines peuvent galement
virtuellement faire tourner certains services. Ceux-ci ne sont en fait que des scripts (dvelopps en perl, python, ou encore en shell-script) qui simulent leur fonctionnement.
- Capable de simuler un rseau entier. Crant alors un "honeynet", il est possible de
configurer ce que l'on appellera des "routing topologies", vritables interconnexions
virtuelles de routeurs, permettant d'obtenir de faux rseaux d'une complexit des plus
leves.
HoneyD peut tre intgr dans larchitecture Prelude-IDS en tant que sonde rseau et
ainsi on peut disposer dun Pot de miel afin dobtenir de nouvelles informations sur
ceux qui attaquent le rseau. Les alertes sont visibles partir du frontend de PreludeIDS.
Pour cela, il suffit dappliquer le plugin Prelude-lml sur la sonde HoneyD pourra tre
manipule comme nimporte quelle autre sonde Prelude-IDS. Tout cela est expliqu en
dtail dans le chapitre venir.

20

Pot de miel

43

Chapitre 4 : Etude et realisation de la

maquette de test

44

Pour des raisons de clart, on a spar la partie technique (fonctionnement interne de la

chose) de la partie utilisation (celle visible pour lutilisateur en nal).
Partie technique
Dans cette section, nous allons numrer tous les points techniques que devra respecter
notre application. Cette liste nous permettra de faire un choix clair sur larchitecture
adopter :
Architecture client-serveur.

La partie serveur tournera sur une plateforme Linux. Ce choix est obligatoire tant donn que nous avons utilis une maquette de communication bas sur la
solution Prelude et que, pour des raisons de scurit, de disponibilit et de rapidit, le
manager Prelude se trouve sur la mme machine physique que le SGBD.

Support de lauthentication et du cryptage des communications entre

client(s) et serveur ; chose qui indispensable et disponible au niveau de notre solution
choisie .
Partie utilisation
Cette partie recense les concepts obligatoires dont doit faire preuve Prelude, ceci en faisant abstraction :

Le frontend doit offrir une prise en main simplie et tre conviviale pour
les utilisateurs.

Le fonctionnement analytique interne ne doit prsenter que les vnements scuritaires ou les comportements qui mritent un rel suivi (filtrage).
Un real time surveillance via un serveur NTP .
4.1 Architecture
An de respecter les contraintes de sparation du traitement des donnes de la prsentation, on a opt pour le modle 3 tiers. Ce choix apporte son lot davantages :

Indpendance entre la partie traitant les informations (serveur) de celle

les prsentant (client). Etant donn que tous les traitements seffectuent ds lors sur le
serveur, la rapidit globale de la solution ne dpend plus de la puissance de calcul ou du
traitement du client.

Stabilit et scurit assures. En effet, en installant la partie serveur en un

endroit unique (DMZ priv), et aussi de prfrence sur la mme machine physique que
la source des informations (la base de donnes) ; ainsi donc il ny aura pas une surcharge
de bande passante et il devient facile de grer les accs et deffectuer dventuelles
mises jour sur le logiciel.

45

4.2 Fonctionnalits
On va maintenant reprendre les points citer prcdemment afin dtailler la liste des
fonctionnalits qui peuvent ou vont tre implantes dans notre maquette de test an de
pouvoir identier les relles menaces scuritaires de la masse dalertes stockes dans la
base de donnes.
Le but principal du projet repose sur le dploiement dune solution SIEM qui fera la centralisation et la corrlation en premier degr, mais afin de pouvoir voir les rsultats et
lefficacit de la solution, passer par une maquette de test est indispensable.
La maquette de teste sest faite via une virtualisation sur VMware Workstation 7 reposant sur la team afin de simuler toute une architecture de production pour cette solution.
Le rsultat attendu repose en premier lieu sur la compatibilit et ladaptabilit, do
vient mon choix des diffrentes solutions ainsi que la diversification au niveau des OS.
4.3 Outils et sondes utilises
Packet Filter
Le choix de ce firewall tait plutt simple reposant sur la simplicit des rgles par rapport aux autres firewalls open source, et aussi sur la scurit disponible au niveau de
FreeBSD et ses performances fortement prouve.
HoneyD
Latout majeur dun honeyPot est la leurre quil fait pour les attaquants, le choix de HoneyD , un honeyPot faible interaction ,cest pour quil ny aura pas un contrle de la
machine et den faire un rebond sur le rseau tant donne quun honeyPot cest une
machine vulnrable intentionnellement . Son placement dans le LAN est juste pour avoir
une sonde dinformation de plus simulant tout un rseau factice compos de poste Windows et dimprimantes au cas dune intrusion ou une brche au niveau du Firewall.
Ossec
Pour sassurer le bon fonctionnement des postes informatiques surveiller,
linstallation dun logiciel comme Ossec, un HIDS, est trs utile. En effet, Ossec va nous
permettre davoir le contrle sur notre DMZ publique , afin dassurer tout dabord
lintgrit des fichiers critique au niveau du serveur ainsi que tout action frauduleuse au
niveau ce serveur ,pour enfin nous en gnrer des alertes.

46

Snort
On a opter pour linstallation de SNORT, un NIDS permettant le contrle sur le LAN afin
de dtecter le trafic suspicieux, comme par exemple le scan de ports, les rootkits, les attaques brute force, mais bien sr selon des rgles bien dfinies pour la situation .Ainsi
donc tout trafic suspect capt est envoy au manager pour en rsulter une alerte. On
sest bas sur des rgles personnelle cre spcifiquement pour la maquette de teste et
les intrusions subites.
Prelude-Manager
Dans loptique de pouvoir superviser lensemble des vnements gnrs par ces applicatifs, il faut pouvoir les centraliser, rendant de cette manire ladministration et la visualisation des alertes plus rapides. Cest ce que permet la solution Prelude, un IDS, qui
utilise des applications tels quOssec et Snort et autre multitude de nud comme des
sondes.
Ainsi, aprs avoir intgr ces applications Prelude-Manager, leurs alertes sont transmises et donc centraliss au sein dun seul logiciel. De plus, cette solution permet de
normaliser toutes les alertes au format IDMEF et les stocke dans la base de donnes.
Prelude-LML
Cette sonde et aussi un plugin de la solution Prelude , est un atout cl pour les sondes
qui ne sont pas nativement compatible avec Prelude. Ainsi donc une configuration au
niveau de ce module pour aider la remont des alertes au niveau de notre manager.
La corrlation
Prelude-Correlator
Afin de corrler des alertes, Prelude peut intgrer galement un corrlateur, savoir
Prelude-Correlator, un module ou plugin de lapplication, donc parfaitement et nativement compatible.
Ce dernier permet ainsi de relier certaines alertes entre elles, spcifiques une attaque
par exemple, selon des rgles de corrlation dfinies. Il intercepte alors les alertes et les
corrle (ou pas), avant de les retransmettre au Prelude.
SEC
Cette solution de corrlation sera integr avec SNORT afin davoir une corrlation local
au niveau de notre NIDS et assurer une meilleur corrlation dans Prelude .
Ce logiciel de corrlation permet de dnir un scnario de corrlation dvnements
extraits de chiers syslog de sortie de SNORT. Dans un premier temps, lide de base est
davoir un IPS au niveau de notre NIDS, mais d des problmes dinstallation et de
compatibilit.
Mais grce ltude de lassociation de SEC avec notre NIDS, il nous a t possible
dentrevoir les capacits danalyse quoffre cet outil. Son utilisation pourrait jouer le rle
47

dun IPS intelligent, reposant sur la partie de corrlation qui en rsulte une action offrant ainsi un systme dalerte rapide en cas de gros problmes.
NTP
Le protocole NTP 21 permet la synchronisation des horloges systmes des machines. Son
fonctionnement sappuie sur une hirarchie dhorloges synchronises. Il est donc indispensable de lui indiquer un serveur sur lequel il pourra sappuyer ou bien juste dune
horloge en local qui nous servira de rfrence. Ensuite, chaque station synchronise
laide de NTP pourrait jouer le rle de serveur pour dautres stations en demande de
synchronisation.
NTP nous permettra dobtenir un timestamp synchronise de toutes les alertes prsentes dans la base de donnes de Prelude Manager. Il est alors indispensable dinstaller
un applicatif soccupant de la gestion de la synchronisation de lheure sur toutes les machines gnrant des alertes.
Lutilit majeur de ce serveur ou bien juste de la synchronisation des horloges est en
premier degr le real time des alertes, afin davoir le temps dintervenir ou de changer
notre politique de scurit.
Prewikka
ET enfin pour la visualisation des vnements stocks dans la base de donnes, nous
allons intgrer dans Prelude-Manager son interface officiel, qui affichera en dtail les
alertes reues par le corrlateur et les diverses sondes et nuds rseaux. Cette interface
sera dans la mme machine comme cit prcdemment que la base de donnes.

4.4 Stockage des informations dans une BD

Le manager Prelude dispose dun plugin de sortie LibPreludeDB permettant de stocker
les alertes dans une base de donnes MySQL.

4.5 Schma de la structure de base adopte

Le schma suivant (fig.14) reprsente bien la configuration propos pour maquette de
test de la plateforme SIEM . Il est important de noter que le serveur MySQL se trouve
sur la mme machine physique que le manager principal pour des raisons videntes de
scurit.

21

Network Time Protocol

48

Figure 14 : Maquette de teste propose

4.5 Enregistrement des sondes

4.5.1 La dclaration
Pour quun agent puisse se connecter et communiquer avec Prelude-Manager, il doit tre
enregistr. L'enregistrement implique des tapes suivre :
Allocation d'une identit unique pour la sonde
La Cration de rpertoire tre utilis par la sonde (cas de Failover)

49

 Dclaration Prelude-Manager dobtenir un certificat X509 sign qui permettra

la communication entre la sonde et le Manager en utilisant les permissions accordes.
Toutes ces informations sont stockes dans une sonde 'profil'.
4.5.2 Profile
Le profil dune sonde est identifi par son nom. Quand une sonde est dmarre, il essayera de charger un profil du mme nom que le programme lui-mme, c'est--dire si
notre sonde est nomme "Prelude-LML", le capteur essayera de charger un profil nomm ""Prelude-LML".
Le cas dune sur lecture (override) dun nom de profile peut tre utiliser avec la commande _--prelude --profile name_of_my_profile_. Elle fournit le capacit de dfinir un
nom de profile afin de pouvoir avoir de multiple instance de la mme sonde avec diffrentes permissions, qui exigent de diffrents profils.
4.5.3 Enregistrement dagent/Cration de Profile
La dclaration des agents est assure par un seul outil nomm prelude-admin.
$ prelude-admin register <nom_profile> <permission> <IP_manager> --uid <uid> --gid
<gid>
La premire fois qu'un agent est enregistr, prelude-admin devra crer une cl prive
pour l'agent. Sous Linux, l'opration peut prendre une trs longue priode de temps en
raison du systme .
o Exemple :
Pour enregistrer la sonde snort on va procder par suite :
# prelude-admin register snort "idmef:w admin:r" 192.168.20.111 uid 501 gid 502
Generating 1024 bits RSA private key... This might take a very long time.
[Increasing system activity will speed-up the process].
Generation in progress... X
Prelude-admin demandera aprs de demmarer linstance prelude-admin sur la machine ou le
serveur prelude-manager est en coute.
You now need to start "prelude-admin" registration-server on 192.168.20.111:
example: "prelude-admin registration-server prelude-manager"
Enter the one-shot password provided on 192.168.20.111:

50

Au niveau du manager (192.168.20.111) , on excute la commande prelude-admin registrationserver en utilisant le nom de profile utilis par notre manager .
$ prelude-admin registration-server prelude-manager
The "d0a9b7xf" password will be requested by "prelude-admin register"
in order to connect. Please remove the quotes before using it.
Generating 1024 bits Diffie-Hellman key for anonymous authentication...++++++++++.+++++..++++++++++
Waiting for peers install request on 0.0.0.0:5553...

Ensuite, la saisie du mot de pass gnr par le manager au niveau de notre sonde Snort
enregistrer.
Enter the one-shot password provided on localhost:
Confirm the one-shot password provided on localhost:
Connecting to registration server (192.168.20.111:5553)... Authentication succeeded.
Successful registration to 192.168.20.111:5553.

Le message affich du cot serveur est le suivant :

Connection from 10.0.0.136:52507...
Registration request for analyzerID="229348179011709" permission="idmef:w admin:r".
Approve registration? [y/n]: y
10.0.0.136:52507 successfully registered.

4.6 Haute disponibilit

La haute disponibilit dsigne le fait quune architecture ou service a un taux de disponibilit convenable.
La disponibilit est un enjeu important des infrastructures informatiques. On estime
aujourd'hui que la non-disponibilit d'un service informatique peut avoir des cots se
chiffrant en millions.
Deux moyens complmentaires sont utiliss pour amliorer la haute disponibilit :
La mise en place d'une infrastructure matrielle ddie, gnralement en se basant sur
de la redondance matrielle. Est alors cr un cluster de haute-disponibilit (par opposi-

51

tion un cluster de calcul) : une grappe d'ordinateurs dont le but est d'assurer un service en vitant au maximum les indisponibilits.
La mise en place de processus adapts permettant de rduire les erreurs, et d'acclrer
la reprise en cas d'erreur. ITIL contient de nombreux processus de ce type.
Pour mesurer la disponibilit, on utilise souvent un pourcentage essentiellement compos de '9' :

99% dsigne le fait que le service est indisponible moins de 3,65 jours par an
99,9%, moins de 8,75 heures par an
99,99%, moins de 52 minutes par an
99,999%, moins de 5,2 minutes par an
99,9999%, moins de 54,8 secondes par an
99,99999%, moins de 3,1 secondes par an
etc.

L'amalgame est souvent fait, tort, entre la haute disponibilit et le plan de reprise d'activit. Il s'agit de deux tches diffrentes, complmentaires pour atteindre
une disponibilit continue.
Afin dassurer une bonne disponibilit du serveur Prelude , notre configuration consiste
consiste fournir une haute disponibilit pour les services Prelude.
Heartbeat 22 prend le contrle des Fail Over de la machine au cours des dfaillances matrielles, au cas o une machine est DOWN ou une perte totale de connectivit. Les deux
serveurs doivent tre toujours jour avec bases de donnes, et soit peut prendre en
charge au pied lev le premier. La valeur ajoute pour assurer une disponibilit assur
est lajout dune solution de supervision, tels que Nagios afin de traiter une dfaillance
au niveau du service, ainsi donc une intervention manuelle pour le redmarrage du service. (Exemple si un service particulier est down, mais le matriel reste oprationnel et
accessible ; UP).
Elaboration de Prelude en haute disponibilit
1. Linstallation de libprelude, LibpreludeDB, Prelude-Manager, PreludeCorrelator,Prelude-LML et Prewikka sur les deux machines.
2. La duplication des fichiers de configuration sur les deux serveurs pour tous les
services centraux de Prelude.

22

Systme de gestion de la haute disponibilit sous Linux.

52

3. La communication et limportation des schmas de Prewikka seront faites quau

niveau dune seule machine, et a sera dupliqu dans l'autre automatiquement.
4. La copie des profils et leur enregistrements se fera sur une seul machine, et on
copie le rpertoire des profils qui se trouve dans notre installation dans
/usr/local/etc/prelude/profile/ de l'autre machine centrale.
5. La mise automatique des services Web et MySQL en dmarrage. Prelude-Manager
et Prelude-Correlator ne doivent pas tre configur pour dmarrer automatiquement au dmarrage, tant donn que Heartbeat se chargera de ces deux services.
4.7 Performance
Dans notre cas o le serveur ne fait office que dun manager principal et de serveur de
base de donnes MySQL. Afin dassurer une bonne performance au niveau du serveur
nous allons voir dsactiver les services inutiles et potentiellement dangereux ainsi
quoprer un paramtrage plus n du systme.
Suppression des services inetd inutiles
La plupart des distributions linux installent par dfaut avec des services anciens et dangereux comme:
lpr : Serveur dimpression UNIX
nfs-common & nfs-kernel-server : Gestion, hbergement et utilisation du systme de
chiers rseau NFS (Network File System).
portmap : Mapping de ports pour les services RPC, compltement obsolte et potentiellement trs dangereux.
pidentd : Daemon didentication, principalement utilis aujourdhui lors de
lutilisation de clients IRC.
ppp, pppoe&pppcong : Utilis lors de connexions dial-up (modem analogique, ADSL &
connexions VPN PPTP).
telnetd : Serveur Telnet, rendu obsolte depuis larrive de SSH.
ngerd : Service nger, source dinformation inutile.
ftpd : Serveur FTP, remplac par le SFTP.
Donc il a fallu supprimer ces services via la commande :
apt-get remove nom_du_paqutage,
Et ensuite dsactiver encore les trois services lancs par inetd ou xinetd laide des trois
instructions suivantes :

53

update-inetd --disable time

update-inetd --disable daytime
update-inetd --disable discard
Au niveau de Mysql
En faisant la commande netstat -a, on a constat que le serveur MySQL rpond aussi bien
aux requtes provenant de lextrieur (eth0) que de lintrieur (lo). Bien que lutilisateur
root ne puisse se connecter que sur linterface lo, on a eu modier la conguration de
MySQL an que son socket ne soit plus visible de lextrieur. (Voir annexe).

54

Chapitre 5 : Fonctionnement et test

55

La phase de ralisation sest focalise sur des scnario de test, afin de voir la comportement de la maquette avec diverse attaque. Les deux attaques sur lesquelles cette phase
repose, sont parmi les attaques les plus frquents :
L'attaque par force brute : une mthode utilise en cryptanalyse pour trouver un
mot de passe ou une cl. Il s'agit de tester, une une, toutes les combinaisons possibles.
Cette mthode de recherche exhaustive ne russit gnralement que dans les cas o le
mot de passe cherch est constitu de peu de caractres. Les programmes utiliss tentent toutes les possibilits de mot de passe dans un ordre alatoire afin de berner les
logiciels de scurit qui empchent de tenter tous les mots de passe dans l'ordre. Dans
notre maquette nous allons faire une attaque sur des sessions ssh afin dobtenir le mot
de passe et aussi voire le comportement de Prelude (remont dalerte et corrlation).
Scan de port (portscan) est une technique servant rechercher les ports ouverts
sur un serveur de rseau. Cette technique est utilise par les administrateurs des systmes informatiques pour contrler la scurit des serveurs de leurs rseaux. La mme
technique est aussi utilise par les pirates informatiques pour tenter de trouver des
failles dans des systmes informatiques. Un scan de port effectu sur un systme tiers
est gnralement considr comme une tentative d'intrusion, servant souvent prparer une intrusion. Les balayages de ports se font habituellement sur le protocole TCP ;
nanmoins, certains logiciels permettent aussi d'effectuer des balayages UDP. Cette dernire fonctionnalit est beaucoup moins fiable, UDP tant orient sans connexion, le service ne rpondra que si la requte correspond un modle prcis variant selon le logiciel serveur utilis. Cette attaque sera perform par loutil Nmap qui est un scanner de
ports open source cr par Fyodor et distribu par Insecure.org. Il est conu pour dtecter les ports ouverts, identifier les services hbergs et obtenir des informations sur
le systme d'exploitation d'un ordinateur cible.
La corrlation se base aussi sur laspect comportemental ainsi, on essayera de configurer
notre moteur de corrlation afin de dtect toute activit hors horaire de travail ou bien
les jours fris.
5.1 Scan de Port
Lors de notre phase de test on a opt pour lintrusion la plus facile et la plus frquente,
qui est le scan de port .Ainsi donc on a fait un scan avec loutil NMAP.
Le rle du corrlateur est de dtecter et de faire plus au moins une conclusion des diffrentes attaques. Nous avons travaill sur la rgle de corrlation suivante, crite en Perl
est se basant sur les expressions rgulire.

56

5.1.1 Rgle de corrlation

1. from PreludeCorrelator.context import Context
2. from PreludeCorrelator.pluginmanager import Plugin
3. class EventScanPlugin(Plugin):
4. def run(self, idmef):
5. source = idmef.Get("alert.source(*).node.address(*).address")
6. target = idmef.Get("alert.target(*).node.address(*).address")
7. if not source or not target:
8. return
9. for saddr in source:
10. for daddr in target:
11. ctx = Context(("SCAN EVENTSCAN", saddr, daddr), { "expire": 60,
"threshold": 30, "alert_on_expire": True }, update = True, idmef=idmef)
12. if ctx.getUpdateCount() == 0:
13. ctx.Set("alert.correlation_alert.name", "A single host has played
many events against a single target. This may be a vulnerability
scan")
14. ctx.Set("alert.classification.text", "Eventscan")
15. ctx.Set("alert.assessment.impact.severity", "high")

La partie la plus importante dans ce code de corrlation est partir de la ligne 11.
La mthode context, cest avec elle que repose le moteur de corrlation pour faire ses
remont dalerte corrle.
ctx = Context(("SCAN EVENTSCAN", saddr, daddr), { "expire": 60,
"threshold": 30, "alert_on_expire": True }, update = True, idmef=idmef)

SCAN EVENTSCAN : est lidentifiant avec le quelle en identifie un context qui sera
par la suite crit de la faon suivante: SCAN EVENTSCA_saddr et SCAN
EVENT_daddr.
Expire, threshold et alert_on_expire sont des options additionnelles :
Expire : comme son nom lindique cest lexpiration dun contexte aprs x seconde
Alert_on_expire : Si notre context est expir, et cette option est True le
message IDMEF sera envoyer.
Treshold : Cest le seuil interne pour un context .
5.1.2 Scenario de corrlation de Scan de port
Aprs avoir fait une comparaison entre ladresse source et destination, on entre dans
une boucle imbrique entre ladresse source et ladresse cible. Dans cette boucle on cre
un contexte ; si le seuil interne de ce context a t atteint en moins de 60 seconde qui
implique aussi un non update de ce context (ctx.getUpdateCount() = 0), alors
une alerte corrle sera remont avec les valeur quon lui aura assign via la mthode
Set (voir les lignes 13,14 et 15) .
57

Figure 15 : Remont d'une alerte corrle (EvantScan)

5.2 Brute force attaque

Cette attaque consiste faire des connexions intensives et avec des mots de passes errons sur une session ssh, afin de simuler quun attaquant essaye de cracker le mot de
passe de cette session.

58

5.2.1 Rgle de corrlation :

1. function brute_force(INPUT)
2. local is_failed_auth = INPUT:match("alert.classification.text",
alert.assessment.impact.completion",
"failed")
3. local result = INPUT:match
("alert.source(*).node.address(*).address",
"(.+)","alert.target(*) .node.address(*).address",
"(.+)");
4. if is_failed_auth and result then
5. for i, source in ipairs(result[1]) do
6. for i, target in ipairs(result[2]) do
7. ctx = Context("BRUTE_ST_" ,source ,target,{ expire = 20,
threshold = 5 "alert_on_expire": True}, update = True,
idmef= local )
8. ctx:set("alert.source(>>)", INPUT:getraw("alert.source"))
9. ctx:set("alert.target(>>)", INPUT:getraw("alert.target"))
10.
ctx:set("alert.correlation_alert.alertident(>>).alertident",
INPUT:getraw( "alert.messageid"))
11.
if ctx:CheckAndDecThreshold() then
12.
ctx:set("alert.classification.text", "Brute force attack")
13.
ctx:set("alert.correlation_alert.name", "Multiple failed login")
14.
ctx:set("alert.assessment.impact.severity", "high")
15.
ctx:set("alert.assessment.impact.description","Multiple failed
attempts have been made to login to a user account")

5.2.2 Scenario corrlation du brute force

Ici le context (ligne 7) de notre rgle consiste contrler le seuil de tentative (threshold
= 5) sur les sessions SSH au bout dune dure de temps spcifiques (expire = 20) .Cette
rgle de corrlation dtecte aussi une attaque brute force distribu (ligne 8 et 9), plusieurs plusieurs. Aprs une dcrmentation du seuil jusqu 0, on assignera les informations de lalerte corrle au context cr (ligne 11 15).

59

Figure 16 : Remont d'une alerte corrle (Brute Force)

5.3 Analyse via Prelude-LML

Pour toute non compatibilit native des sondes avec Prelude, le plugin Prelude-LML est
disponible pour faciliter lanalyse des logs gnrer via une criture de rgles personnelles reposant sur des expressions rgulires.
Dans notre maquettes on a essay de traiter ce point avec un honeyPot , HoneyD gnre
des logs et les journalise dans /var/log/syslog . Cest l o vient le rle du analyseur de
log Prelude-LML .
Lors de la configuration de notre HoneyD , on a essay de faire la journalisation via
SysLog , pour faire par la suite une analyse avec Prelude-LML .
Dans notre analyseur il faut spcifier le format du fichier log afin de dtcter chaque partie et la normaliser aprs pour avoir une remont dalert dans linterface Prelude .

60

1. [format=syslog]
2. time-format = "%b %d %H:%M:%S"
3. prefix-regex = "^(?P<timestamp>.{15})
(?P<hostname>\S+)(?:(?P<process>\S+?)(?:\[(?P<pid>[0-9]+)\])?: )?"
4. file = /var/log/messages
5. file = /var/log/auth.log

La partie la plus importante dans cette section est prefix-regex .Cette option dicte Prelude-LML comment manipuler le fichier log via diffrents champs :
Tableau 1 : Correspondance des valeurs de l'expression rgulire.

Variable

Utilisation

Timestamp

Liaison au temps de dtection de lalerte IDMEF

Hostname

Liaison au nud cible de lalerte IDMEF

Process

Liaison au processus cible de lalerte IDMEF

Pid

Liaison au pid cible de lalerte IDMEF

Figure 17 : Fichier syslog , journalisant HoneyD

Lors du dmarrage de HoneyD ,on dmarre Prelude-LML afin de procd notre analyse
des sortie SysLog du HoneyPot. Comme montrer dans la figure17 et avec la configuration faite au niveau de Prelude-LML on dduit le tableau suivant :
Tableau 2 : Valeur correspondant la capture fig 17

Variable

Value

timestamp

Jun 19 09:07:12

hostname

machine

process

honeyd

pid

5211

61

Figure 18 : Remont d'alerte de la sonde HoneyD via Prelude-LML

Ainsi donc on aura une remont d aletre comme quoi un utilisateur a tenter de pinger
ou douvrire une session SSH dans notre HoneyPot .
62

5.4 Linterface Prewikka:

Prewikka est l'interface Web de Prelude. Elle permet d'afficher les alertes reues par
Prelude-Manager. Lorsque Prelude, plus prcisment Prelude-Manager, reoit une alerte
IDS, il lajoute dans la base de donnes de Prelude. Ainsi, Prewikka, lorsquil va ractualiser sa page daffichage dalertes, relancera un SELECT sur les tables de la base de donnes et affichera alors cette nouvelle alerte.
5.4.1 Description et utilisation de l'interface
Lancement de l'interface
Etant une interface graphique web, Prewikka se lance donc dans un navigateur internet.
Pour cela, il suffit dentrer dans la barre dadresse url du navigateur (Firefox, IE, Opera,
), cette adresse :http://adresse_ip_prewikka:8000
Laccs avec succs dans le navigateur nous mnera vers un formulaire
dauthentification. Il faut entrer le login et le password en fonction de la configuration de
Prewikka (dfinition de ladministrateur par dfaut dans le fichier de configuration
/etc/prewikka/prewikka.conf, avec les champs initial_admin_user et initial_admin_pass).

Figure 19 : Formulaire d'authentification

63

Une fois authentifi, la page principale de Prewikka s'affiche alors, savoir la visualisation des alertes.

Figure 20 : Page principale Prewikka

Description de l'interface
Linterface de Prewikka est compose dune fentre principale, centrale o sont affiches les alertes transmises par les sondes de Prelude. Sur la gauche, on peut trouver le
menu avec les diffrentes parties : Evnements, Agents, Paramtres statistiques et A
propos.
La partie Evnements correspond donc la visualisation des alertes IDS. Cest la page
principale (par dfaut) de Prewikka. Sur cette page, il y a 3 onglets disponibles pour spcifier, voir plutt filtrer laffichage des alertes. On a donc le choix entre Alertes, Alertes
de Corrlation et Alertes doutils. Le premier onglet Alertes (par dfaut), affiche la totalit des alertes (corrles, ), le second, comme lindique son nom, sert visualiser que
les alertes corrles par Prelude-Correlator. Quant au troisime, il affiche les alertes
concernant les outils (sondes).

64

Des couleurs sont utilises pour pouvoir en faciliter la recherche sur les niveaux de gravits, de danger de chacune dentre elles. Ainsi, le code des couleurs est :
1
2
3
4

Bleu niveau dinformation info

Vert niveau le plus faible low
Orange niveau intermdiaire medium
Rouge niveau dalerte maximum high

Les alertes sont affiches sous la forme dun tableau, avec comme colonnes, la classification (nom de lalerte, ), la source ayant provoque lalerte, puis la destination de
lvnement, ensuite le nom de la sonde ayant fait remonte cette alerte Prelude, et
enfin le temps (heure) sur lequel lalerte a t reue par le Prelude-Manager. Pour chacun de ses onglets (Evnements), un bouton se trouvant en bas de page (Effacer), permet aprs slection des alertes (globale, ou cible), de les supprimer.
Quel que soit longlet choisi, il est possible (en gnral) de voir en dtail les alertes en
cliquant dessus, sur le titre de lalerte ou bien, en cliquant sur le nombre ct du titre
dans le cas o il y en aurait plusieurs.

Figure 21 : Liste des alertes

Aprs avoir cliqu sur une alerte (see alert), Prewikka affiche alors le contenu de lalerte,
savoir le format IDMEF avec une mise en forme HTML, plus sympathique lire que
dans un fichier de logs.

Figure 22: Dtail d'une alerte

65

Aprs la rception et lajout dune nouvelle alerte par Prelude-Manager, le corrlateur,

savoir Prelude-Correlator va en fonction de ses rgles, intercepter certaines alertes pour
en gnrer une nouvelle, corrle. Cette dernire sera renvoye au Prelude-Manager, qui
la verra comme une nouvelle alerte, mais corrle. En aucun cas, le corrlateur ne supprime les alertes partir desquelles il a gnr sa corrlation. Ainsi, dans Prewikka, il
sera possible de voir les nouvelles alertes reues directement par le Prelude-Manager,
avec aussi la nouvelle alerte corrle, en gnral un niveau de gravit plus lev.

Figure 23 : Pages des alertes corrles

Le bouton Agents permet de visualiser lensemble des agents constituant larchitecture

rseau de notre maquette, savoir les diffrentes sondes connectes au serveur Prelude,
ainsi que ses composants, comme le Prelude-Manager, le Prelude-Correlator... Il est possible donc de voir ltat des sondes et des composants de Prelude en temps rel, cest-dire si ils sont connectes ou pas (Manquant ou Connect).

66

Figure 24 : Liste et pages des agents

Et enfin , la page Statistique qui permet de voir les attaques au cours d'un intervalle de
temps. Elle nous montre ainsi et de faon explicite des statistiques avec diffrents
graphes et selon dfirent critres.

67
Figure 25 : Graphes de la page statistiques

Conclusion
Durant ces quatre mois de stage de fin dtude, il nous a t offert deffectuer diffrentes
tches aussi varies quintressantes. En effet, nous avons eu le plaisir deffectuer les
travaux suivants :
L tude et comparaison des diffrents solution SIEM.
Le dploiement dune architecture rseau complte (Firewall, NIDS , HIDS, serveurs Web,HoneyPot)
Ladaptabilit dune solution SIEM dans une architecture rseau.
Cration rgles personnalises de SNORT et Prelude nous amenons a bien comprendre le trafic rseau .
Nous estimons avoir atteint notre but, puisque la quasi-totalit du cahier des charge a
t remplie. Mais je ne pourrai prtendre avoir fait le tour du sujet. En effet, la corrlation dvnements reste un domaine en pleine volution et en recherche de solutions
efficaces. Il serait intressant dapprofondir lanalyse et de mettre en place dautres scenario dinvestigation permettant dobserver le comportement de larchitecture mise en
place. De plus, il serait trs utile de dployer un serveur de monitoring (Nagios par
exemple ) afin daider assurer une haute disponibilit .
La corrlation pourra aussi nous mener considrer le data mining ,en effet pour valeur
ajout ce travail il est envisageable dajouter LogHound , qui est un outil conu pour
trouver des motifs frquents partir des donnes log des vnements fixe l'aide de
lalgorithme breadth-first du data minig , chose qui na pas t implmenter par faute de
temps.
Dun point de vue plus personnel, ce travail ma permis dlargir mes connaissances en
scurit rseau, conguration dlments rseaux et gestion de la dtection dintrusions .
Ces diffrents domaines mont donn une forte envie dapprofondir mes connaissances
en la matire. Cest pour cela que jenvisage fortement une formation plus pousse dans
le domaine...

68

Annexe
Installation de Prelude
Pr-requis
Pour la prparation d'un environnement Prelude, il faut installer certains paquets :

$ sudo apt-get update

$ sudo apt-get upgrade

$ sudo apt-get install man wget ssh build-essential checkinstall libpcap-dev flex byacc gtk-doc-tools libssl-dev
libxml-dev libpcre3-dev libfam-dev gnutls-bin libgcrypt11-dev libgnutls-dev libgpg-error-dev libopencdk10-dev
libxmlsec1 libxmlsec1-gnutls

Libprelude
Tlchargement
Rcupration de la librairie de Prelude :

$ sudo wget http://www.prelude-ids.com/download/releases/libprelude/libprelude-1.0.0.tar.gz

Compilation et installation
Installation de la librairie :

$ sudo tar zxf libprelude-1.0.0.tar.gz

$ cd libprelude-0.9.24.1

$ sudo ./configure --enable-easy-bindings --enable-gtk-doc

*** Dumping configuration ***

- Generate documentation

: yes

- Libtool dynamic loader

: System

- LUA binding

: no

- Perl binding

: yes

- Python binding

: yes

- Ruby binding

: no

- Easy bindings

: yes

$ sudo make

$ sudo make install

$ sudo ln /sbin/ldconfig /usr/local/lib

$ sudo export LD_LIBRARY_PATH=/usr/local/lib

69

$ sudo vim /etc/ld.so.conf

include /usr/local/lib

$ sudo ldconfig

LibpreludeDB
Pr-requis
L'ajout d'une base de donnes sur un serveur Prelude requiert des paquets supplmentaires :

$ sudo apt-get install mysql-server libmysqlclient15-dev

Tlchargement
Tlchargement de la librairie de base de donnes de Prelude:

$ sudo wget http://www.prelude-ids.com/download/releases/libpreludedb/libpreludedb-10.0.0.tar.gz

Compilation et installation
Installation de la librairie:

$ sudo tar zxf libpreludedb-1.0.0.tar.gz

$ cd libprelude-0.9.15.3

$ sudo ./configure --with-postgresql=no --enable-gtk-doc

*** Dumping configuration ***

- Generate documentation

: yes

- Enable MySQL plugin

: yes

- Enable PostgreSQL plugin

: no

- Enable SQLite3 plugin

: no

- Perl binding

: yes

- Python binding

: yes

$ sudo make

$ sudo make install

$ sudo vim /etc/ld.so.conf

include /usr/local/lib/libpreludedb/plugins/formats

include /usr/local/lib/libpreludedb/plugins/sql

$ sudo ldconfig

Cration de la base de donnes

70

Pour stocker les alertes, cration de la base de donnes Prelude :

$ sudo mysql -u root p

> create database prelude;

> grant all privileges on prelude.* to prelude@localhost identified by 'prelude';

> grant all privileges on prelude.* to prelude@nagios identified by 'prelude';

> exit

$ sudo mysql -u prelude -p prelude < /usr/local/share/libpreludedb/classic/mysql.sql

Prelude-Manager
Tlchargement
Ensuite, il faut tlcharger le paquet Prelude-Manager:

$ sudo wget http://www.prelude-ids.com/download/releases/prelude-manager/prelude-manager-1.0.0.0.tar.gz

Compilation et installation
Et enfin linstaller:

$ sudo tar zxf prelude-manager-1.0.0.tar.gz

$ cd prelude-manager-0.9.15

$ sudo ./configure

*** Dumping configuration ***

- TCP wrapper support

: no

- XML plugin support

: yes

- Database plugin support: yes

$ sudo make

$ sudo make install

$ sudo vim /etc/ld.so.conf

include /usr/local/lib/prelude-manager/decodes

include /usr/local/lib/prelude-manager/filters

include /usr/local/lib/prelude-manager/reports$ sudo ldconfig

$ sudo ldconfig

Prelude-Correlator
Pr-requis
L'ajout de Prelude-Correlator ncessite l'installation d'un environnement python :

71

$ sudo apt-get install python

Tlchargement
Tlchargement du plugin de corrlation de Prelude :

$ sudo wget http://www.prelude-ids.com/download/releases/prelude-correlator/prelude-correlator-1.0.0.tar.gz

Compilation et installation
Installation du module de corrlation:

$ sudo tar zxf prelude-correlator-1.0.0.tar.gz

$ cd prelude-correlator-0.9.0-beta6

$ sudo python setup.py build

$ sudo python setup.py install

$ sudo vim /etc/ld.so.conf

include /usr/local/lib/prelude-correlator

$ sudo ldconfig

Prelude-LML
Tlchargement
Pour installer le module Prelude-LML, il faut rcuprer le paquet:

$ sudo wget http://www.prelude-ids.com/download/releases/prelude-lml/prelude-lml-1.0.0.tar.gz

Compilation et installation
Puis le compiler et linstaller:

$ sudo tar zxf prelude-lml-0.9.15.tar.gz

$ cd prelude-lml-0.9.15

$ sudo ./configure

*** Dumping configuration ***

- Enable unsupported rulesets

: yes

$ sudo make

$ sudo make install

$ sudo vim /etc/ld.so.conf

include /usr/local/lib/prelude-lml

$ sudo ldconfig

72

Prewikka
Pr-requis
La mise en place de l'interface web ncessite d'installer quelques paquets supplmentaires :

$ sudo apt-get install apache2 libapache2-mod-python mysql-server python python-dev python-setuptools

Tlchargement
Pour mettre en place une interface graphique de Prelude, il faut tlcharger le module Prewikka:

$ sudo wget http://www.prelude-ids.com/download/releases/prewikka/prewikka-1.0.0.tar.gz

Compilation et installation
Installation de linterface Prewikka:

$ sudo tar zxf prewikka-0.9.17

$ cd prewikka-0.9.17

$ sudo apt-get install cheetah

$ sudo python setup.py build

$ sudo python setup.py install

Cration de la base de donnes

Pour linterface Prewikka, il faut crer une base de donnes :

$ sudo mysql -u root p

> create database prewikka;

> grant all privileges on prewikka.* to prewikka@localhost identified by 'prewikka';

> exit

$ sudo mysql -u prewikka -p prewikka < /usr/share/prewikka/database/mysql.sql

Configuration de Prelude
Libprelude
Cette partie correspond la configuration de Prelude en gnral, c'est--dire Libprelude install sur un poste client
ou serveur. En effet, quel que soit l'usage, et l'installation tant la mme sur les deux types de postes, la configuration
de base de Prelude se trouve par dfaut dans le rpertoire /usr/local/etc/prelude/default.
Ce dossier contient plusieurs fichiers de configuration tels que:

client.conf

global.conf

idmef-client.conf

tls.conf

73

client.conf
Ce fichier est diter que dans le cadre d'une configuration d'un agent ou d'une sonde (exemple: Prelude-Correlator,
Ossec, etc). client.conf permet notamment d'indiquer l'adresse du serveur Prelude (Prelude-Manager), et de paramtrer les diffrents changes (au niveau tcp, et tls) entre le client et le serveur.

global.conf
Le fichier global.conf contient la configuration pouvant servir aussi bien pour le serveur, que pour le client (agent, ou
sonde). Dans ce fichier, il est possible de paramtrer certaines options pour grer des champs remplir lors de l'envoi
d'alerte, ou encore pour prciser les informations sur le poste serveur ou client (multiples adresses ip, nom du vlan,
etc).

idmef-client.conf
Quant ce fichier, idmef-client.conf, il contient les liens vers les deux fichiers prcdents, savoir client.conf et global.conf.

tls.conf
Afin de paramtrer la gnration des certificats, comme la dure de vie ou la valeur de la cl de cryptage (par dfaut
1024), il faut diter le fichier tls.conf.

Prelude-Manager

Pour configurer Prelude-Manager, il faut diter le fichier prelude-manager.conf, par dfaut ce dernier se trouve sous
le rpertoire /usr/local/etc/prelude-manager.
$ sudo vim /usr/local/etc/prelude-manager/prelude-manager.conf

Configuration de base
Dans prelude-manager.conf, le rseau sur lequel Prelude-Manager coute doit tre prcis, afin que ce dernier accepte les connexions des clients (sondes). Pour simplifier, ici l'adresse choisie est globale.
listen = 0.0.0.0

Ensuite, il reste indiquer les paramtres de la base de donnes de Prelude (LibpreludeDB) :

[db]

type = mysql

host = localhost

port = 3306

name = prelude

user = prelude

pass = manager

Avec ces paramtres, Prelude-Manager est prt dmarrer et fonctionner.

Optimisation
Une fois la configuration de base termine, il est possible d'optimiser Prelude-Manager dans prelude-manager.conf.

Logs
L'activation du debug en mode texte se fait en ajoutant ces lignes :

74

...

[debug]

logfile = stderr

logfile = /var/log/prelude.log

...

Prelude-LML
Pour configurer Prelude-LML, il faut diter le fichier prelude-lml.conf.
$ sudo vim /usr/local/etc/prelude-lml/prelude-lml.conf

Optimisation
Pour prendre en compte les syslogs par exemple, y ajouter :

[format=syslog]

time-format = "%b %d %H:%M:%S"

prefix-regex = "^(?P<timestamp>.{15}) (?P<hostname>\S+) (?:(?P<process>\S+?)(?:\[(?P<pid>[0-9]+)\])?: )?"

file = /var/log/messages

file = /var/log/auth

file = /var/log/syslog

Prewikka
Pour activer linterface Web de Prelude, il faut commencer par configurer Prewikka. Ce dernier dispose d'un fichier de
configuration, prewikka.conf.
$ sudo vim /etc/prewikka/prewikka.conf

Configuration de base
Dans prewikka.conf, il faut prcis les paramtres des bases de donnes utiliser. Voici les champs complter:
[idmef_database]

# if your database is a sqlite file, please use:

# type: sqlite3

# file: /path/to/your/sqlite_database

type: mysql

host: localhost

user: prelude

pass: prelude

name: prelude

75

[database]

type: mysql

host: localhost

user: prewikka

pass: prewikka

name: prewikka

La premire partie correspond la base de donnes de Prelude-Manager, contenant les alertes IDMEF. Quant la
seconde base de donnes, c'est celle de Prewikka, cre lors de l'installation de ce dernier pour ajouter une interface
graphique.

Optimisation
A travers le fichier prewikka.conf, il est possible d'optimiser la configuration de Prewikka.

Authentification

L'authentification de Prewikka peut tre modifie, soit en la dsactivant, soit en indiquant les paramtres de l'administrateur de base, initial (par dfaut admin/admin).

[auth loginpassword]

expiration: 60

initial_admin_user: admin

initial_admin_pass: admin

Pour dsactiver l'authentification, il suffit de commenter les lignes prcdentes :

#[auth loginpassword]

#expiration: 60

#initial_admin_user: admin

#initial_admin_pass: admin

Logs
Pour activer les logs de Prewikka, il faut indiquer un fichier en sortie :

[log file]

level: debug

file: /var/log/prewikka.log

[log syslog]

level: warning

Installation d'Ossec
Pr-requis
76

Avant de passer linstallation dOssec, il faut au pralable installer certains paquets, adapter selon vos besoins.

$ sudo apt-get update

$ sudo apt-get upgrade

$ sudo apt-get install wget man ssh build-essential libgnutls-dev checkinstall

Ossec-HIDS
Tlchargement
Pour installer Ossec, il faut tout dabord tlcharger la dernire version (http://www.ossec.net/main/downloads).
$ sudo wget http://www.ossec.net/files/ossec-hids-latest.tar.gz

Dcompresser larchive.

$ sudo tar zxf ossec-hids-2.6.tar.gz

Un seul paquet est ncessaire pour linstallation sur un poste Linux. En effet ce dernier sert aussi bien pour linstallation
dun serveur que dun agent.

Ossec Serveur
Libprelude
Linstallation de Libprelude est obligatoire pour pouvoir enregistrer le serveur Ossec auprs du serveur Prelude. Ainsi,
Ossec est considr comme une sonde de Prelude et peut alors changer avec ce dernier de manire scuris.

Ossec
$ cd ossec-hids-2.1

Afin quOssec prenne en charge Prelude (optionnel), cest--dire, lenvoi des alertes au format IDMEF vers PreludeManager, il faut activer le service avant de lancer l'installation, sous peine, en cas d'oubli, de devoir rinstaller
compltement Ossec afin de russir l'intgrer correctement Prelude.
$ cd src

$ sudo make setprelude

$ cd ..
$ sudo ./install.sh

Ensuite, il ne reste plus qu suivre les instructions comme le choix de langue, le type dinstallation (serveur/agent),
le rpertoire dinstallation, etc.

Ossec Agent
Linux

Pour le client Linux, la procdure est similaire au serveur, la seule diffrence quil faut choisir le type Agent lors de
linstallation.

Ossec-WUI
77

Ossec-WUI est l'interface web d'Ossec-HIDS. Elle permet de visualiser les alertes reues par le serveur. Cette installation n'est pas obligatoire.

Pr-requis
Pour installer Ossec-WUI, il faut au pralable installer certains paquets.

$ sudo apt-get install apache2 php5

Tlchargement
Le paquet Ossec-WUI est tlcharger sur le site d'Ossec (http://www.ossec.net/main/downloads).
$ sudo wget http://www.ossec.net/files/ui/ossec-wui-0.3.tar.gz

Dcompresser larchive.

$ sudo tar zxf ossec-wui-0.3.tar.gz

Installation
Une fois le paquet tlcharg et dcompress, il faut le dplacer dans le dossier utilis par notre serveur web (Apache).

$ sudo mv ossec-wui-0.3 /var/www/htdocs/ossec-wui

Ensuite, on peut lancer l'installation.

$ sudo cd /var/www/htdocs/ossec-wui

$ sudo ./setup.sh

www-data tmp

Configuration d'Ossec
Ossec-HIDS
Pour configurer Ossec, il faut diter le fichier ossec.conf.
$ sudo vim /etc/ossec/etc/ossec.conf

Configuration de base
Dans ossec.conf, il faut ajouter les adresses ip autorises interagir avec Ossec, c'est--dire les postes informatiques
ne pouvant tre bloqus par le systme de rponses-actives d'Ossec-HIDS, ces derniers tant considrs comme srs.
Pour cela, ces adresses ip doivent tre entres dans la liste blanche.
<ossec_config>

...

<global>

<white_list>127.0.0.1</white_list>

<white_list>^localhost.localdomain$</white_list>

<white_list>192.168.20.111</white_list>

<white_list>192.168.40.130</white_list>

78

<white_list>192.168.40.1</white_list>

</global>

...

Libprelude
Afin que notre serveur Ossec et Prelude communiquent correctement entre eux, il faut prciser ladresse du serveur
Prelude dans le fichier client.conf dans le repertoire /usr/local/etc/prelude/default.
$ sudo vim /usr/local/etc/prelude/default/client.conf

server-addr = 192.168.20.111

Ensuite dans le fichier de configuration ossec.conf, il faut ajouter des paramtres Prelude.
<ossec_config>

<global>

...

<prelude_output>yes</prelude_output>

<prelude_profile>ossec</prelude_profile>

<prelude_log_level>0</prelude_log_level>

</global>

...

Le paramtre prelude_output permet d'activer l'envoi d'alerte vers Prelude, quant au paramtre prelude_profile, il
sert indiquer le profile (certificat d'inscription utilis pour Prelude) utiliser au dmarrage d'Ossec-HIDS.
Pour prelude_log_level, c'est en quelque sorte un filtre des alertes envoyer Prelude avec un niveau de log minimum.

Ossec Agent
Linux

Sur les agents, il faut comme pour la version serveur, diter le fichier ossec.conf afin de configurer les rpertoires et
les fichiers vers lesquels Ossec doit pointer et surveiller.
Mais le point le plus important, est d'indiquer l'adresse du serveur Ossec :

<ossec_config>

<client>

<server-ip>192.168.40.129</server-ip>

</client>

Installation d'un serveur Snort

Pr-requis
$ sudo apt-get update

$ sudo apt-get upgrade

79

$ sudo apt-get install build-essential checkinstall mysql-server libnet1-dev libpcap0.8-dev libpcre3-dev

libmysqlclient15-dev

Snort
Libprelude
Linstallation de Libprelude est obligatoire pour pouvoir enregistrer le serveur Snort auprs du serveur Prelude. Ainsi,
Snort est considr comme une sonde de Prelude et peut alors changer avec ce dernier de manire scuris.

Snort
Maintenant, linstallation de Snort peut commencer :

$ sudo cd /tmp

$ sudo wget http://dl.snort.org/snort-current/snort-2.8.6.tar.gz

$ sudo tar --zxf snort-2.8.6.tar.gz

$ sudo cd snort-2.8.6

$ sudo ./configure --with-mysql --enable-dynamicplugin --prefix=/usr/local/snort --enable-prelude

$ sudo make

$ sudo make install

$ sudo mkdir /etc/snort

$ sudo mkdir /var/log/snort

$ sudo mkdir /etc/snort/rules_backup

$ sudo mkdir /etc/snort/packages

$ sudo cp /tmp/snort-2.8.6/etc/*.conf* /etc/snort

$ sudo cp /tmp/snort-2.8.6/etc/*.map /etc/snort

Utilisateur et groupe
Pour ladministration de lapplication Snort, il faut crer un utilisateur dadministration et un groupe (cette tape peut
tre optionnelle) :

$ sudo groupadd snort

$ sudo useradd g snort d /usr/local/snort m snort

$ sudo chown R snort /var/log/snort

$ sudo chgrp R snort /var/log/snort

Rgles Snort
Ajout des rgles Snort:

$ sudo cd /tmp

$ sudo wget http://dl.snort.org/sub-rules/snortrules-snapshot-2.8.6_s.tar.gz

80

$ sudo tar zxf snortrules-snapshot-2.8.6_s.tar.gz

$ sudo mv snortrules-snapshot-2.8.6/rules/* /etc/snort/rules

MySQL
Cration de la base de donnes
Pour le stockage des alertes de Snort, et pour une visualisation plus claire que dans un fichier de logs, il est possible de
crer une base de donnes:

$ sudo mysql u root p

> create database snort;

Cration dun utilisateur

Ajout dun utilisateur pour administrer la base de donnes:

> grant all on snort.* to snort@localhost;

> set password for snort@localhost=password(snort);

> flush privileges;

> exit

Construction de la base de donnes

Cration des tables et diffrentes proprits de la base de donnes, grce un script fourni dans le paquet
dinstallation de Snort :

$ sudo cd /tmp/snort-2.8.6/schemas

$ sudo mysql u snort p < create_mysql snort

Configuration d'un serveur Snort

Snort
Pour configurer Snort, il faut diter le fichier snort.conf.
$ sudo vim /etc/snort/snort.conf

Configuration de base
Dans le fichier snort.conf, voici les paramtres de base indiquer pour le bon fonctionnement de Snort :
Dclaration des interfaces dcoute :

var HOME_NET 10.0.0.0/8

var EXTERNAL_NET any

Ensuite, il est important d'indiquer le rpertoire contenant les rgles :

var RULE_PATH /etc/snort/rules

Dfinition de la base de donnes Snort :

81

output database: log, mysql, user=snort password=snort dbname=snort host=localhost

Libprelude
Activation de lenvoi dalertes vers Prelude:

$ sudo vim /etc/snort/snort.conf

Pour relayer les alertes de snort vers le serveur Prelude, il faut galement ajouter cette ligne :

output alert_prelude: profile=snort

Puis, il est important pour la communication entre Snort et Prelude de configurer la librairie de Prelude. Pour cela, il
faut prciser ladresse du serveur Prelude dans le fichier client.conf dans le
rpertoire /usr/local/etc/prelude/default.
$ sudo vim /usr/local/etc/prelude/default/client.conf

server-addr = 192.168.20.111

82

Reference

1)

FreeBSD handbook:

2) http://www.freebsd.org/doc/fr_FR.ISO88591/books/handbook/index.html
3)

Site officielle de Prelude:

4) http://www.prelude-technologies.com
5)

Ralisation dune maquette modulaire avec les Open sources afin de

scuriser le rseau Informatique de la FBPMC pour laccs Internet,
Mr. Sad KHOUDALI

6)

CHE, Ethical Hacker.

7)

www.wikipedia.org

8)

www.google.com

83