Gestion Et Centralisation Des Logs Avec Leurs Corrélationsl

7/23/2019 Gestion Et Centralisation Des Logs Avec Leurs Corrlationsl

1/83

1

Projet de Fin dEtudesPour lObtention du Diplme Master en

Ingnierie Informatique et Internet

Intitul :

Gestion et centralisation des logsavec leurs corrlations

Prsent par :BENZIDANE KARIM

Le, 06/07/2010

Encadrants :Moussaid Khaild , Facult des Sciences, Casablanca

Zoubir Sami , Crdit du Maroc, CasablancaOuali Youness, Crdit du Maroc, Casablanca

Membres du Jury :

Mr Abghour, Facult des Sciences, CasablancaMr Bouzidi, Facult des Sciences, CasablancaMme Fetjah, Facult des Sciences, Casablanca

Anne Universitaire 2009 / 2010


2/83

2

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.


3/83

3

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


4/83

4

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 .......................................................................................... 16Figure 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
http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559651http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559651http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559652http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559652http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559653http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559653http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559654http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559654http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559655http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559655http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559656http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559656http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559657http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559657http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559658http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559658http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559659http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559659http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559660http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559660http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559661http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559661http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559662http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559662http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559663http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559663http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559664http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559664http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559665http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559665http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559666http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559666http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559667http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559667http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559668http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559668http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559669http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559669http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559670http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559670http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559671http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559671http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559672http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559672http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559673http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559673http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559674http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559674http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559675http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559675http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559675http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559674http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559673http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559672http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559671http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559670http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559669http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559668http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559667http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559666http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559665http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559664http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559663http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559662http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559661http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559660http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559659http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559658http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559657http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559656http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559655http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559654http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559653http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559652http://c/Users/benzidane/Desktop/Rapport-%20-%20Copie%20(2).docx%23_Toc273559651


5/83

5

Introduction

De nos jours, les rseaux dentreprise sont exposs toutes sortesdattaques informa-tiques qui vont du simple challenge entre hackers, aux attaques cibles dautres organi-

sations 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 in-

tranet 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 don-

nes administratives.

Pour ladministrateur rseau et scurit, le nouveau challenge consistedonc :

Dfinir et promouvoir une politique scurit,

Dployer les dispositifs de dfense,

Assurer par des outils dobservations performants la dtection defailles ven-

tuelles 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 n-fastes 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 raffec-

tation 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 etcorrlation

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


6/83

6

redevable du flux dinformationprovenant des diffrents organes surveiller respecti-

vement 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 htrogneset dune certaine varit de systmes dexploitation, chacun fournissant ses logs1 dansun format bien propritaire. Selon le type de solution utilis, il est souvent ncessaire deparcourir tous ces logs sparment et manuellement. Certains de ces logs sont envoys en clair sur le rseau (syslog et SNMPv.1 en sont debons exemples) vers un serveur central, offrant ainsi des personnes malveillantes unemagnifique opportunit de masquer leurs agissements en inondant ledit serveur de fauxmessages ou alertes. Dans ltat actuel des choses, aucune solution commerciale ou Open Source ne peutprtendre garantir seule la scurit du rseau . . . il faut avoir recours plusieurs pro-duits de conception et de source diffrentes. Chacun de ces produits possde bien sr unformat de message et une interface qui lui sont propres. Bien que la qualit des sondes rseaux et htes se soit grandement amliore, cesder-nires sont toujours sujettes un pourcentage non ngligeable de faux positifs 2et fauxngatifs3.

Il existe toutefois une petite proportion dentreprises o la surveillance du rseau nesouffre peu ou pas des points mentionns ci-dessus. Malheureusement, le travail du res-ponsable de la scurit nen est pas facilit pour autant, car il doit jongleravec un flotincessant dalertes provoques par des comportements qui nont,dans 90% des cas, au-cun impact sur lintgrit du rseau(En effet, quelle est lutilitde 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 lacote 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, leport monitoring du switch devient compltement satur,rendant soit impossiblelanalyse complte des donnes (perte de paquets) ou ralentissant lensemble de sonfonctionnement (throttling).A la vue du triste palmars des solutions actuelles de scurit, nous pouvons aismentconstater quil devient impratif de trouver rapidement une solution. Force est de cons-tater qu lheure actuelle, seuls des produits commerciaux trs onreux prtendent of-frir une alternative viable et se destinent naturellement au march des grandes entre-prises. Larrive dun produit tout aussi efficace prix plus modr serait extrmementbien accueillie offrant ainsi un bon SIMS4.

1Fichier journal

2

Une alerte est leve sans raison3Aucune alerte na t leve alors que lattaque a bien eu lieu

4Security information management System


7/83

7

Chapitre 1: Contexte du projet


8/83

8

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 activi-

ts 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 r-gissant la conduite des projets et dfinissant les rles des diffrents acteurs,

Organiser et assurer le rle de la matrise d'uvre fonctionnelle traversles mtiers traditionnels de l'informatique savoir la gestion cohrente del'architecture fonctionnelle, les tudes et dveloppements, la gestion desprojets et la maintenance,

Organiser et assurer la gestion de l'infrastructure du systme d'informationet le droulement des traitements priodiques dans les meilleures condi-tions de qualit de service. Cette mission comprend la gestion de l'architec-ture technique (informatique centrale et distribue, tlcommunications)avec comme objectifs la scurisation des donnes et des traitements infor-matiques, la cohrence et le dimensionnement optimal de l'infrastructure

technique et la prennit des investissements.


9/83

9

Le schma ci-dessous donne une vision globale de lorganisation 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 re-

quiert toujours un systme dinformation robuste et surtout bien scuris.

De nos jours, le systme dinformation (S.I.) est devenu vital pour la majorit des entre-

prises. 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 poli-

tique de scurit. Cependant le cot de ces investissements est loin dtre ngligeable etles entreprises sont souvent confrontes aux problmes suivants :

Figure 1 : Schma de l'organisme DSIG


10/83

10

La multiplicit et la complexit croissante des technologies.

Lmergence de nouvelles attaques (phishing, virus, etc ) sans cesses plus perti-

nentes qui imposent aux entreprises une veille permanente

La spcificit. Chaque entreprise est diffrente, donc chaque entreprise ses con-

traintes 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 tou-

tefois les radiquer totalement.

Ainsi, ladministrateur de scurit aura une vue globale sur les attaques qui ont relle-ment abouties, sans devoir visualiser les unes aprs les autres les milliers dalertes g-nres.

Figure 2 : Topologie analogique d'une SIEM


11/83

11

1.4.3 Cahier des charges

En partant de ce qui a t nonc au paragraphe prcdent, ltude sera faite sur

ltablissement dune solutionSIMS. Cette solution semblant rpondre aux problma-

tiques prcdemment cites, permettant ainsi de grer de manire centralise les re-montes dinformation de diffrents outils, de les stocker et les traiter afin de faciliter

ladministrationet 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 SIMSappels galement SEM (Security Event Management) ou SEIM (Security EventInformation Management) ou encore SIEM (Security Information and Event Manage-ment) est un systme servant automatiser la collecte et lanalyse des informations detous les nuds de scurits dans un rseau. Mis part les informations obtenues deslogs 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 adiffrent 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 amlio-rer 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


12/83

12

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, for-

mats 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 en-

voys 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 gnrerpar les faux positives ou ngatives afin de dcouvrir les nouvelles attaques bien cons-

truites.

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 infosque 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 denouvelles alertes, elle va chercher les informations correspondant des alertesmises. 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=Ao Modification : A->B


13/83

13

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 deu-

xime 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 inter-

valle 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 recons-

truire 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 g-nralement 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 acti-

vit rgulire est considrer comme suspicieuse.

Temps de travail : Une connexion hors lintervalle de travail permise d-

clenche 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 ma-

licieuse.

Le reporting

Les SIMS permettent galement de crer et gnrer des tableaux de bord et des rap-

ports. 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 rglemen-

taires. Un archivage valeur probante permet de garantir l'intgrit des traces. Les solu-


14/83

14

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 diffrentes5solutions 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

5Listes non exhaustives


15/83

15

Chapitre 2: Etat de lart


16/83

16

2.1 Choix de la solution SIMS :

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 , tou-

jours 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 d une

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.

Figure 4 : Tableau comparatif des solutions SIEM


17/83

17

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 do-

cumentation 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 peutcontenir 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 solu-

tion 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 Van-

doorselaere (Ingnieur en dveloppement, Expert scurit et Responsable R&D) et Mlle

Audrey Girard (Ingnieur en systmes industriels et Grante) avec lobjectif de repous-

ser 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 com-

ptitif 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


18/83

18

toff et prestigieux, incluant certains leaders des tlcoms, banques, groupes indus-

triels ainsi que des organisations gouvernementales.

2.1.2 Dfinition

Prelude est un SIM Universel. Prelude collecte, normalise, catgorise, agrge, corrle etprsente 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'ini-

tiative 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 denombreuses fonctionnalits, Prewikka facilite le travail des utilisateurs et analystes.Cette interface permet de visualiser les alertes, que un ou plusieurs concentrateurs Pre-lude (prelude-manager) ont stock en base de donnes, de faon conviviale. Prewikkafournit 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 qui-

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


19/83

19

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 conti-

nuit 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 devien-

nent 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 IDMEF 7. 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 quutiliseSnort pour analyser des paquets via

des rgles. Dans le cas de Prelude-LML ses rgles essayent de correspondre des don-

nes 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

6Application Programming Interface7Intrusion Detection exchange format8Perl Compatible Regular Expression


20/83

20

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 (CheckpointFirewall-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 pro-

grammation 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 poin-

ter de faon performante les vnements de scurit importants ayant lieu sur nos in-frastructures.

Sa fonctionnalit est la suivante :

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

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

Analyse en temps rel des vnements reus par le Manager Prelude


21/83

21

Prelude-Correlator permet de corrler, en temps rel, les multiples vnements reuspar Prelude. Plusieurs alertes isoles, issues de sondes multiples, peuvent ainsi dclen-cher une seule alerte de corrlation si les vnements sont lis. L'alerte de corrlationapparait 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 pro-grammation Python. Le moteur de corrlation intgr de Prelude est distribu avec desrgles de corrlation pr-enregistres mais il nous est possible de configurer n'importequelle 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 entierou seulement certaines parties.

Ce plugin permet aussi l'interrogation de la base de donnes afin de joindre aux vne-

ments 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 pos-

sible de gnrer des emails uniquement pour des vnements correspondants des cri-

tres 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 decomposants 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 opra-

tions 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 peu-

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


22/83

22

Cela se traduit en pratique par la possibilit d'installer autant de sondes et de contr-

leurs 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 trecompile 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 certifi-cats 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 lajournalisation des alertes ;

- Ne pas avoir installer un LAN ddi la dtection d'intrusions sur les rseauxconcerns par l'IDS.Donc, pour tre prise en compte par un manager, une sonde doit au pralable avoir tdclare - enregistre - auprs de celui-ci. Dans le cas de sondes et managers supportantSSL, cela se traduit par la gnration d'une clef prive sur la sonde et d'un certificat surle manager qui la prendra en compte.

Fiable

Si pour une raison ou une autre une sonde n'arrive plus envoyer ses alertes un ma-nager auprs duquel elle est enregistre, ces dernires sont conserves localement jus-qu' rtablissement de la connexion avec un manager. Cette fonctionnalit est fourniepar 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 Pre-

lude 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 intgrantd'autres produits (exemple : des sondes plus performantes, des programmes plus spci-fiques, etc) toujours grce la librairie libprelude.


23/83

23

Exemple darchitecture possible:

Architecture simple :

Prelude est divis en plusieurs composantes. Les capteurs sont responsables de la dtec-

tion d'intrusion, et faire des rapports sur les vnements d'une manire centralise en

utilisant une connexion TLS un serveur Prelude-manager '. Le serveur Prelude-

Manager 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 interagis-

sent:

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 v-

nements gnrs par le capteur A, B et C . Toutefois, le Security Center peut voir lesvnements gnrs tant par ses propres capteurs (D, E et F), ainsi que les vnementsgnrs par les autres branches de l'organisation (comme A, B, C, etc.)

Figure 5 : Architecture simple


24/83

24

Architecture Relai-Invers :

Sur certains rseaux, il peut parfois tre difficile ou gnant dorganiserdes autorisationsrseau 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 DMZ9de 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 v-nements mis par elle.

9Zone dmilitarise (Demilitarized Zone)

Figure 6 : Architecture relai

Figure 7 : Architecture relai invers


25/83

25

2.2 Format standard

Les deux principales propositions de standards allant dans le sens dune uniformisationdes changes de messages lis la scurit sont le CIDF 10et lIDMEF11.

2.2.1CIDF

Le CIDF, pour Common Intrusion Detection Framework a t une tentative du US go-vernementsDefense Advanced Research Project (DARPA) pour dvelopper un langage(Protocole & format de messages) dchange entre IDS et manager pour leur utilisationinterne en premier lieu. Cette proposition de standard a t juge trs lourde et peu uti-lisable par les dveloppeurs de solutions IDS et na t que trs rarement utilise dansdes applications concrtes. Toutefois, une partie du concept et des bons points de celangage ont t rutiliss dans IDMEF.

2.2.2 IDMEF

Prsentation

LInternet Engineering Task Force (IETF) est lorganisme responsable du dveloppementde nouveaux standards Internet. Cet organisme a form un groupe de travail, lIntrusionDetection exchange format Working Group (IDWG12), qui incombe maintenant la cra-

tion dun format dchange commun pour les alertes provenant dIDS.

Ce groupe de travail a propos IDMEF, un format de description des alertes bas surXML, 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 appli-cations qui analysent les alertes des IDS, afin quelles se voient fournir toutes les infor-mations ncessaires leur bon fonctionnement. Notons encore quIDMEF est totalementindpendant du protocole de communication et que sa construction base sur XML lerend compatible avec les futursfirewalls applicatifs intelligents XML.

Structure dun message IDMEF

La structure des messages IDMEF est hirarchique et peut sapparenter un modle declasse en programmation oriente objet. La classe parente est IDMEF-Message et tous lesmessages 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 re-lations entre les principaux composants dans la figure 8. Cette reprsentation est uneversion simplifie du modle complet, mais est suffisamment dtaille pour en com-prendre le concept.

10

http://www.isi.edu/gost/cidf/11http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-10.txt

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


26/83

26

Il est encore important de noter que ce modle de donnes ne prcise pas comment unealerte doit tre classifie ou identifie. Par exemple, un port-scan peut tre identifi parun analyseur comme attaque unique contre de multiples cibles, alors quun autre y verraune attaque multiple depuis une source unique. Toutefois, ds quun analyseur a dter-min 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 signa-tures ou heuristique). LIDWGa fait grand travail afin quIDMEFpuisse sadapter cettediversit, en focalisant les informations sur ce que lIDS a dtect plutt que Com-ment il la dtect.La figure 8 nous montre la construction hirarchique en classe du message IDMEF.

Figure 8 : Structure d'un message IDMEF


27/83

27

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 DTD13associe. Il y a actuellement

deux types de messages IDMEF : lalerte (Alert) et le Heartbeat. La classeAlert : Gnralement, chaque fois quun analyseur dtecte un vnement,il

envoie une alerte son (ses) manager(s). Suivant le type danalyseur, cemessage peutcorrespondre un vnement unique ou de multiples vnements.Cette classe Alertecomporte 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(bug-traq5, cve6, etc. . .) ou un identifiant spcifique limplmentation, si laditealerte nestpas encore rpertorie. Cette proprit est intressante, car elle permet deux IDSnutilisant pas le mme algorithme de dtection de rapporter lamme erreur leurmanager. La classeAnalyzer : Cette classe dfinit sil sagit dun message dalerte ou dunheart-beat. Notons quil est impratif quune seule de ces classes ne soit instanciedans unmessage dalerte. La classeAdditionalData : Cette classe peut tre vide ou contenir des informations quinont pas leur place ailleurs dans le message. On peut aussi imaginer utiliser cette classepour fournir un dump complet du trafic qui a provoqu lalerte.

La classe Heartbeat : Les analyseurs envoient priodiquement des messages heartbeatpour indiquer leur manager quils sont en fonction (up and running). Labsencede r-ception de ces messages indique que la connexion rseau est dfectueuseou quelanalyseur a un problme.

La classe CreateTime : Une estampille temporelle y est place, indiquant la date decration de lalerte ou du heartbeat.

De par sa construction intelligente et sa gratuit dutilisation, ladoption dIDMEFcomme 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 mar-

ch. Quelle que soit notre configuration, inutile de remplacer nos quipements scurit :Prelude sadapte linfrastructureet non linverse.

13

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


28/83

28

Lorsquoninstalle 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


29/83

29

Chapitre 3: Sondes et sources

dinformations


30/83

30

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 vuln-rable aux attaques et aux dnis de service. De plus, il est impratif de garantirlauthenticit etlintgrit des messages reus des diffrentes sondes. Les trois notionscls 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 scurisa-tion des transactions effectues via Internet mis au point par Netscape, en collaborationavec MasterCard, Bank of America, MCI et Silicon Graphics. Il repose sur un procd decryptographie par clef publique afin de garantir la scurit de la transmission de don-nes sur Internet ou sur un LAN. Le systme SSL est indpendant du protocole utilis, cequi signifie quil peut aussi bien scuriser des transactions faites sur le Web par le pro-tocole HTTP que des connexions via le protocole FTP, POP ou autres. En effet, SSL agittelle une couche supplmentaire, permettant dassurer la scurit des donnes, situeentre la couche application et la couche transport.(fig10).

Format des messages

Vu que le choix sest port sur une plateforme de base Prelude et aussi un choixdadopter un format de message standard, compatible avec de futures applications, il est

clair que lutilisation dIDMEF est incontournable. On fera appel aux fonctionsdauthentification et de cryptage fournies par LibPrelude pour garantir la scurit des

changes.

Les IDSLes IDS14est 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.

14Intrusion Detection System/systme de dtection d'intrusion

Figure 10 : Modle avec la couche SSH


31/83

31

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 s-

curit au niveau des htes.

Les HbIDS ( IDS hybrides), qui utilisent les NIDS et HIDS pour avoir des alertes

plus pertinentes.

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 arri-

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

Figure 11 : Fonctionnement des NIDS


32/83

32

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 signa-

ture 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 d-

couvrir 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'occu-

per 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 com-

prhensible.

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 frag-

ments. La fragmentation de l'en-tte de la couche transport tant aussi possible, cela

15La recherche de motif


33/83

33

rendait les NIDS vulnrables aux attaques de Stick et de Snot16car les paquets fragmen-

ts n'taient pas analyss.

Les NIDS ont le devoir de refragmenter les paquets avant analyse, afin de ne pas man-

quer 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'ex-

ploitation sur lequel l'attaque est vise. Il s'agit encore d'une technique d'vasion utili-

sable aujourd'hui car les NIDS ne sont pas forcment configurs correctement pour g-

rer 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 pou-

voir 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'ex-ploitation. 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 g-

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

16Techniques utilises pour tromper le moteur de lIDS en fragmentant lattaque dansplusieurs paquets, ainsi

la reconstruction se fait aprs quils aient traverss lIDS


34/83

34

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

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 dela 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 commu-

niquer 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,

Figure 12 : Fonctionnement d'un HybIDS


35/83

35

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, mes-sages IRC par exemple).

Il existe diffrentes catgories de honeypot selon le niveau dinteraction que lon sou-

haite offrir aux attaquants :

Les honeypots de trs faible interaction se contentent de simuler certains ser-vices 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 estpar exemple didentifier les adresses sources de pirates et aussi et surtout les premirescommandes 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 la-

bors 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 estsouvent ddi la recherche comportementale et psychologique pour le profilage despirates.

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 lo-

cale) 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 communi-

cation 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


36/83

36

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.

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 in-

cluent Internet (une zone dont la confiance est nulle), et au moins un rseau in-

terne (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, interfacerseau, 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 sui-

vant le niveau de confiance qu'on leur porte.

Figure 13 : Fonctionnement d'un pare-feu


37/83

37

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 autori-ses

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 blo-

quer tout le trafic arrivant sur certains ports afin dempcher des postes extrieurs

daccder des services non indispensables de lextrieur. Un firewall possdant plu-

sieurs 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


38/83

38

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 don-

nes 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 :

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 )

17Traduction d'adresse rseau/ Network Address Translation


39/83

39

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 certainsvnements afin de diminuer le nombre de fausses alertes.

SEC est un logiciel multiplateforme de corrlations d'vnements Open Source ,il ac-cepte les entres d'un fichier, d'un tube nomm (pipe) ou de l'entre standard et peutdonc tre employer comme couche de corrlation par tous programmes crivant leurssorties d'vnements dans un flux de fichier.

La configuration de SEC est stocke comme rgles dans des fichiers texte, chaque rgledcrivant l'vnement sur lequel ragir, l'action mener. Les expressions rgulirespeuvent tre utilises pour dfinir les conditions de l'vnement. SEC peut lui-mmeproduire des vnements en sortie en excutant des scripts shell ou des programmesexternes (snmptrap, courrier lectronique, filtrage ip) et/ou en crivant des messagesvers des tubes ou des fichiers.

SEC est utilis dans des domaines aussi varis que la gestion des rseaux, le monitoringsystme, la scurit des donnes, la dtection d'intrusions, la surveillance et l'analyse defichiers journaux, etc. SEC est utilis ou intgr dans des produits aussi diffrents que HPOpenView 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 supportespar SEC.

SingleWithScript : Dtection dun motif et excution daction parmi cellesupporte par SEC en fonction du code de sortie d'un script ou programme externe.

SingleWithSuppress : Dtection dun motif et excution daction parmicelles supportes par SEC, mais ignore les motifs dtects suivants pendant t se-condes suivantes.

Pair : Dtection dun motif et excution daction parmi celles supportespar 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 secondesdun motif diffrent. Si ce deuxime motif n'est pas dtect au bout de ce temps, excu-tion 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 nouveauxmotifs 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.


40/83

40

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 plate-formes POSIX18alors quon peut retrouver Snort sur Windows. A cela sajoutelimportance 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 desprofessionnels de la scurit.

Une diffrence importante cependant, au dsavantage de Snort est sa nature , il est NIDSpur 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 pralablementdfinis. Le mode de fonctionnement est alors similaire. Autant pour Prelude-IDS quepour Snort, les solutions sont stables. Notons que mme en intgrant les alertes deSnort, Prelude-IDS relve une quantit plus importante dalertes. Prelude-NIDS archiveaussi les payloads.

Prelude-IDS a lavantage dtre trs modulaire de par son architecture client-serveur. Unmanager peut grer plusieurs sondes, et une sonde peut envoyer ses alertes plusieursmanagers.

La remonte dalertes

En utilisant ces outils, on se rend compte du fait que Prelude-IDS remonte un nombreplus 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 dedtection dun plus grand nombre dattaque. Cela est d lutilisation des mmes signa-tures 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, en-voyer 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 ajouteaux rgles de Prelude-IDS. Ainsi, le nombre important de signatures reconnues par Snort(et qui participe sa popularit) bnficie Prelude-IDS.

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


41/83

41

3.2 Intgration de sources dinformation externes

Firewall

*BSD Packet Filter

Packet Filter (que nous appellerons dsormais PF) est le systme utilis par OpenBSDpour 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 four-nir des services de contrle de bande passante et gestion des priorits des paquets. PFfait partie du noyau GENERIC d'OpenBSD depuis la version 3.0. Les prcdentes versionsd'OpenBSD utilisaient un ensemble logiciel pare- feu/NAT diffrent qui n'est plus sup-port.

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 laTraduction d'Adresse de Rseau NAT. Quand PFlogger est install le plugin Prelude-PFlogger coute les paquets journaliss et envoie les alertes Prelude-Manager.

Firewall Personnel

L encore, lincorporation de diffrentsfirewalls personnels est trs facilite grce lastructure fournie par Prelude. Ainsi, nimporte quel applicatif ou matriel de filtrage uti-

lisant la journalisation NT, Syslog ou des fichiers locaux pour inscrire ses alertes estcompatible avec Prelude. La seule limitation est lexistence dune expression rgulirePerl dans le fichier de configuration de Prelude-LML qui permet ce dernier de parsercorrectement les entres. Dans la ngative, il est toujours possible dy ajouter sespropres 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 utili-

ss, possdant aussi une communaut importante contribuant son succs. Actuelle-

ment SNORT appartient SourceFire.

SNORT est capable deffectuer en temps rel une analyse de trafic et de logger les pa-

quets sur un rseau IP, aussi quune analyse protocolaire et le pattern matching de con-

tenu. 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 SNIF-

FING de rseau, effectuant une journalisation ainsi donc pour dtecter dventuels in-

trusion. Son moteur de dtection utilise une architecture modulaire de plug-in, il a aussiune grande capacit modulaire dalertes en temps rel, incorporant des mcanismes


42/83

42

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 NIPS19via SNORT-Inline , interdi-

sant 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 dispositionsur le site de Pre-

lude-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 prci-

sment 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 pro-pose 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 gale

Gestion Et Centralisation Des Logs Avec Leurs Corrélationsl

Documents

Transcript of Gestion Et Centralisation Des Logs Avec Leurs Corrélationsl

Analyse des fichiers logs Web ~ Projet LP STID ~

Projet d centralisation quipe du Cameroun

L’informatisation : un support pour la centralisation du transport des patients

Administration et supervision depuis le Cloud avec Azure Logs Analytics

Les uniformes Securitas · Centralisation des achats En adoptant la centralisation des achats au niveau européen, Securitas ... Lavage Sèche-linge interdit Repassage à l’envers

Le merchandising - coheris.com€¦ · Avantages et fonctions métier Centralisation des données Centralisation de tous les éléments d’une stratégie merchandising opérationnelle

La d centralisation fiscale en R publique D mocratique du ...

CENTRALISATION DES VOLETS ROULANTS … · 2016-06-10 · spÉcialiste mondial des infrastructures Électriques et numÉriques du bÂtiment centralisation des volets roulants myhome

Niro Granite...NIRO GRANITE NIRO GRANITE Wat« Rupture 027 Stan MS MS 2 MS 2 logs. 2 MS ISO logs • 2 MS 3 MS '0545-6 Unit to Sute S oss S to State Cuss. to State On Cut …

Centralisation d’Informations de Suivi et d’Alerte d’un …bernardin.benoit.free.fr/espacepro/resources/RapportBts2.pdfBERNARDIN Benoît Projet de Centralisation des Informations

De startup à scale-up : créer une solution de logging …...gestion puis l'analyse de leurs logs et métriques, grâce à des tableaux de bord en ligne flexibles et conviviaux. Depuis

Installation de capteurs et centralisation par microcontrôleur pour le ...

Montage Boîtier HF Ebay sur Xantia Phs2 avec Centralisation HFcinok2006.free.fr/Xantia/Montage%20Bo%EEtier%20HF.pdf · Montage Boîtier HF Ebay sur Xantia Phs2 avec Centralisation

Gestion des fichiers LOgs

Centralisation de la trésorerie

CENTRALISATION DES CANDIDATS LOCATAIRES. Besoins Centralisation des données dans le but de la simplification administrative Disposer d’informations complètes.

Logs serveurs : du terme barbare à la simplicité de la réalité

La centralisation des Logs · PDF fileSection : BTS SIO 2ème année Pré-requis : Linux Commands Sujet : La centralisation des Logs 1/30 I. Présentation

Centralisation des logs serveurs · PDF fileLe groupe OCP, qui se charge de l ... Abdoun à Khouribga, Gantour à Youssoufia, ... Projet de stage « Centralisation des logs serveur

Caractérisation des transitions temporisées dans les logs ...