Ossim Doc

Fonctionnement dOSSIM
Dans le cadre de SIMS - Security Intrusion Management System

(http ://www.fullsecurity.ch/security/sims/)
Auteur : Joel Winteregg (joel.winteregg@heig-vd.ch)

Professeur : Stefano Ventura
Ecole : Swiss University of Applied Sciences (HEIG-VD)
Institut ICT (http ://www.iict.ch)
Date : 12 mai 2006
Version : 3.4
Table des matieres
1 License dutilisation de cette documentation 5
2 Etude dOSSIM (Open Source Security Information Management) 6

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 La detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Methodes de detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Lanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Definition de la priorite des alarmes . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Evaluation des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Le monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Risk monitor (moniteur du risque) . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2 Moniteur dutilisation, session et profile . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Path monitor (moniteur de chemin) . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.4 Forensic console (Console legale) . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.5 Control Panel (panneau de controle) . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Fonctionnement logiciel dOSSIM 17

3.1 Les applications Ossim-server et Ossim-agent . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Fonctionnement de larchitecture avec une sonde Snort . . . . . . . . . . . . . . . . . . 17
3.2.1 Pourquoi deux flux dinformations ? . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Fonctionnement de larchitecture avec une sonde Ntop et le plugin RRD . . . . . . . . . 19
3.3.1 Quest-ce que Ntop ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Fonctionnement de larchitecture avec une sonde P0f . . . . . . . . . . . . . . . . . . . 20
3.4.1 Quest-ce que P0f ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 Fonctionnement de larchitecture avec une sonde TCPTrack . . . . . . . . . . . . . . . 21
3.5.1 Quest-ce que TCPTrack ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1
SIMS - Security Intrusion Management System
3.6 Fonctionnement de larchitecture avec une sonde PADS . . . . . . . . . . . . . . . . . . 22

3.6.1 Quest-ce que PADS ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Fonctionnement de larchitecture avec une sonde Syslog . . . . . . . . . . . . . . . . . 24
3.7.1 Quest-ce quune sonde HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.8 Fonctionnement de larchitecture avec une sonde HIDS IIS (Internet Information Services) 25
3.8.1 Quest-ce quune sonde HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.8.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Fonctionnement du Framework (interface Web et serveur OSSIM) 27

4.1 Avant propos et terminologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Architecture des menu du framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Definition du risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Menu Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4.1 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.2 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.3 Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4.4 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 Reports Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.1 Host Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.2 Security Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.3 PDF Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.4 Anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.5 Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6 Monitor Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6.1 Riskmeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6.2 Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6.3 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7 Policy Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7.1 Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7.2 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7.3 Network groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7.5 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.7.6 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.8 Correlation Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.8.1 Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8.2 Cross Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8.3 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2 Institut ICT, Joel Winteregg (cc)

4.9 Configuration Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.9.1 Main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.9.2 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.9.3 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.9.4 RRD config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.9.5 Host scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.10 Tools Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.10.1 Net Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.10.2 Rule viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.10.3 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Conclusion 45
A Installation et configuration dOssim-server 47

A.1 Prerequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.3.1 Ossim plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.3.2 Serveur Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.3.3 Nessus client-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.3.4 Cross correlation via Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
B Ajout et configuration dune sonde Snort 52

B.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
B.1.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
B.1.2 Ossim-agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
B.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
B.2.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
B.2.2 Ossim-agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
B.3 Configuration dOssim-server pour une nouvelle sonde Snort . . . . . . . . . . . . . . . 55
B.4 Test de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
B.4.1 Erreur de demarrage de lagent Ossim . . . . . . . . . . . . . . . . . . . . . . . 56
C Ajout et configuration de Ntop 58

C.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
C.1.1 Ntop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
C.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C.2.1 Ntop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C.2.2 Lagent Ossim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C.3 Configuration dOssim-server pour une nouvelle sonde Ntop . . . . . . . . . . . . . . . 61
D Ajout et configuration de P0f 62

D.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

D.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
D.2.1 P0f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
D.2.2 Lagent Ossim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
E Ajout et configuration de TCPTrack 63

E.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
E.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
F Ajout et configuration dune sonde HIDS Syslog 64

F.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
F.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
G Ajout et configuration dune sonde HIDS IIS 65

G.1 Installation du plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
G.2 Installation de Snare IIS (rapatriement des logs vers un serveur Syslog) . . . . . . . . . 65
G.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
G.3.1 Configuration de lagent OSSIM . . . . . . . . . . . . . . . . . . . . . . . . . . 66
G.3.2 Configuration du serveur IIS (client Snare IIS) . . . . . . . . . . . . . . . . . . 66
H Ajout et configuration de PADS 68

H.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
H.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
I Creation de regles de correlation 69

I.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
I.2 Ajout dun fichier de regles sur le serveur . . . . . . . . . . . . . . . . . . . . . . . . . 69
I.3 Syntaxe XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
I.3.1 Balise directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
I.3.2 Balise rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
I.3.3 Balise rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
I.3.4 Syntaxe des attributs de caracteristiques . . . . . . . . . . . . . . . . . . . . . . 71
I.4 Structures des directives de correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
I.4.1 Exemple de structure des directives . . . . . . . . . . . . . . . . . . . . . . . . 75
I.4.2 Structure de correlation realisable . . . . . . . . . . . . . . . . . . . . . . . . . 77
J Analyse heuristique - (algorithme Holt-winter) 79

J.1 Recuperation des donnees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
J.1.1 Configuration du plugin RRD de Ntop . . . . . . . . . . . . . . . . . . . . . . . 80
J.2 Analyse des donnees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
J.2.1 Algorithmes de prevision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Chapitre 1
License dutilisation de cette

documentation
THIS WORK IS LICENSED UNDER THE CREATIVE COMMONS ATTRIBUTION-NONCOMMERCIAL-

SHAREALIKE LICENSE.
TO VIEW A COPY OF THIS LICENSE, VISIT : http ://creativecommons.org/licenses/by-nc-sa/2.5/deed.fr
OR SEND A LETTER TO CREATIVE COMMONS, 543 HOWARD STREET, 5TH FLOOR, SAN
FRANCISCO, CALIFORNIA, 94105, USA.
5
Chapitre 2
Etude dOSSIM (Open Source Security

Information Management)
2.1 Introduction
OSSIM est une solution offrant une infrastructure pour le monitoring de la securite reseau. Ses objectifs
sont :
Fournir un cadre centralise
Fournir une console dorganisation
Ameliorer la detection et laffichage des alarmes de securite
Le but commun des trois principaux objectifs decrits ci-dessus est de permettre une reduction des
faux positifs1 et des faux negatifs2 . Ce but est dautant plus difficile a atteindre du fait quun volume
considerable dalarmes est present. Il est donc necessaire de relier ces differentes alarmes entre elles afin
dobtenir des informations pertinantes et deliminer les alarmes innutiles (levees pour rien). Cet objectif
peut etre atteint a laide dun procede danalyse des donnees nomme : Correlation.
Le principe de fonctionnement dOSSIM est forme de trois grandes categories decomposees elles-memes
en sous categories :
1. La detection
IDS (pattern matching3 )
Detection danomalie
Firewalls
2. Lanalyse et le monitoring (detaille en section 2.3.3 et 2.4)
1
Alarmes levees pour rien
2
Alarmes non declenchees alors quune attaque a eu lieu
3
signatures
6
Correlation
Evaluation de la dangerosite des alarmes
Evaluation du risque sur larchitecture a proteger
3. Les management (configuration)
Inventaire des ressources informatiques4
Definition de la topologie
Definition des polices de securite
Definition des regles de correlation
Liens avec differents outils daudits Open Source
Les differents procedes cites ci-dessus seront detailles dans les sections suivantes.
2.2 La detection
Celle-ci est evidemment effectuee a laide de sondes capables de traiter linformation5 en temps reel et
demettre des alarmes lorsquune situation a risque est detectee.
2.2.1 Methodes de detection
Une sonde peut utiliser differentes approches afin de determiner si une evenement est a risque ou non.
En effet, deux grands principes complementaires (et non concurrent) sont presents dans la detection
dintrusions :
1. Base sur des signatures
2. Base sur la detection danomalie
Detection par signatures
La detection par signatures identifie des evenements de securite qui tentent dutiliser un systeme de facon
non standard. Les representations dintrusions sont donc stockees et comparees a lactivite du systeme.
Lorsquune intrusion connue est reperee lors de lutilisation du systeme, une alarme est levee.
La detection par signatures a des limites. Elle ne connat pas lobjectif de lactivite correspondant a
une signature et va donc declencher une alerte meme si le trafic est normal. De plus, la detection par
signature exige de connatre prealablement lattaque afin de generer la signature precise correspondante
(fonctionnement par liste noire, exemple : antivirus). Ceci implique quune attaque encore inconnue ne
pourra pas etre detectee par signature.
4
machines, systemes dexploitation, services
5
Trames transitants par le reseau ou log dune application

Detection danomalie
La detection danomalie identifie une activite suspecte en mesurant une norme6 sur un certain temps.
Une alerte est ensuite generee lorsque le modele seloigne de cette norme.
Le principal avantage de la detection danomalie est quelle nexige aucune connaissance prealable des
attaques. Si le module de detection par anomalie determine quune attaque differe de facon significative
de lactivite normale, il peut la detecter.
Comme la detection par recherche de pattern, la detection danomalie possede ses limites. Toute la dif-
ficulte reside dans la periode de collecte des donnees correspondant a une activite designee comme
normale pour alimenter la base de donnees de reference.
2.3 Lanalyse
La methode de traitement des donnees peut etre decomposee en trois phases distinctes :
1. Preprocessing, generation des alarmes et envoi de celles-ci.
2. Rassemblement, toutes les alarmes precedemment envoyees (preprocessing) sont emmagasinees
dans un serveur central.
3. Post-processing, le traitement des donnees que lon a emagasine.
Les deux premieres etapes (preprocessing et rassemblement) ne presentent rien de nouveau dans le cadre
dOSSIM. Celles-ci font principalement partie des methodes de detection mentionnees ci-dessus (section
2.2). OSSIM offrira uniquement de nouvelles methodes danalyse et daffichage des donnees recoltees.
Il napportera en aucun cas de nouvelles solutions dans la detection et le rassemblement de donnees.
Differentes methodes danalyse sont implementees dans le cadre dOSSIM :

Definition de la priorite des alarmes
Evaluation des risques
Correlation
2.3.1 Definition de la priorite des alarmes
Ce procede permettra de deduire la priorite dune alarme en fonction de son type, de la source de
leventuelle attaque ainsi que de sa cible. Les exemples suivants illustrent facilement lutilite de cette
etape danalyse :
Une machine fonctionnant avec le systeme dexploitation UNIX et hebergeant un serveur Web
Apache est mentionnee comme cible dune attaque. Cette attaque a precedemment ete detectee
comme possible a laide dun scanner de vulnerabilites. La piorite de lalerte sera donc maximale
6
Peut etre assimile a un chablon de bon fonctionnement (activite normale)

puisque le serveur Web est vulnerable a lattaque en question. Un procede de cross-correlation est
donc applique a toutes les alertes.
Si la connexion a un serveur genere une alarme, la configuration de police de securite en fonction
des utilisateurs permettra facilement la definition de la priorite de celle-ci. En effet, differents cas
sont envisageables :
Priorite maximale de lalarme si lutilisateur (source de lattaque) est exterieur au reseau
de lentreprise et que la connexion a pour cible une base de donnees importantes.
Basse priorite si lutilisateur (source de lattaque) est interne au reseau de lentreprise et
que la connexion a pour cible une imprimante.
Alarme discreditee si lutilisateur (source de lattaque) fait partie de lequipe de developpement
et que la cible de la connexion est un serveur de test.
La definition de priorite fait partie dune etape de mise en place de contextes des alarmes. Celle-ci est
uniquement possible si lenvironnement de lentreprise est defini dans une base de donnees des connais-
sances. Cette base de donnees est definie par linventaire des bien informatiques ainsi que sur des polices
dacces a des serveurs et/ou services. La definition des ces differentes polices de securites implique
la mise a disposition dun outil de management permettant une configuration precise des polices de
securites ainsi que des machines du reseau.
Cette etape represente une part importante du filtrage des alarmes et necessitera une constante mise a
jour de la base de donnees des connaissances.
2.3.2 Evaluation des risques
Le risque peut etre defini comme etant la probabilite de menace de levenement. En dautres termes,
cette etape tente de definir si la menace est reelle ou pas.
Limportance a donner a un evenement depend principalement de trois facteurs :
1. La valeur du bien attaque
2. La menace representee par levenement
3. La probabilite que levenement apparaisse
Les trois facteurs vus ci-dessus sont la base du calcul du risque intrinseque.
Risque intrinseque
Ce risque peut etre defini de la facon suivante : La mesure de limpact potentiel de la menace sur le
bien informatique, en fonction de la probabilite que cette menace apparaisse, tout en tenant compte
de la fiabilite du capteur ayant emit lalarme.
Le risque est traditionnellement represente par le risque intrinseque representant le risque quune orga-
nisation court de par les biens quelle possede.

Risque immediat
Etant donne quOSSIM offre un traitement temps reel des alarmes, le calcul du risque immediat peut etre
associe a la situation courante.
Ce risque offre une vision de levaluation des degats quune alarme recue pourrait engendrer. Cette
evaluation prendra aussi en compte la fiabilite du capteur ayant emis cette alarme. Le risque immediat
est donc calcule pour chaque alarmes recues et indique limportance de lalarme en terme de securite.
2.3.3 Correlation
Ce procede permet nottamment de retrouver certaines relations entre differentes alarmes independantes.
Ceci permettra par exemple de decouvrir des attaques noyees dans le flot des alarmes ou encore de
discrediter des alarmes (decouverte de faux positifs).
La correlation peut etre simplement definie comme un procede traitant des donnees (inputs) et retournant
un resultat (outputs). OSSIM utilise deux types dinputs :
1. Informations du moniteur (qui fournit normalement des indications a ladministrateur)
2. Informations des detecteurs (qui fournissent normalement des alarmes)
Le resultat de ce traitement sera lui aussi dun des deux genres cites ci-dessus (du moniteur ou des
detecteurs). Les modeles de correlations utilises par OSSIM ont les objectifs suivants :
Utilisation de methodes par signatures, pour la detection devenements connus et detectables
Utilisation de methodes sans signature, pour la detection devenements non connus
Utilisation dune machine detats configurable par lutilisateur, pour la description de signatures
complexes
Utilisation dalgorithmes evolues, pour laffichage general de la securite
Methodes de correlation
OSSIM met en oeuvre plusieurs methodes de correlation complementaires :

1. Correlation utilisant des sequences devenements, basees sur les signatures connues et detectables
2. Correlation utilisant des algorithmes heuristique7 , utilisee pour la detection dattaques non connues
3. Cross-correlation permettant la recherche de relations entre les scans Nessus effectues et des alertes
detectees
Correlation par heuristique OSSIM implemente un algorithme dheuristique comme un accumula-

teur devenements (CALM), offrant une indication de letat general du reseau. Lobjectif de ce traitement
est dobtenir en premier lieu, le risque immediat (definit dans la section 2.3.2) puis, le risque accumule.
7
Technique consistant a apprendre petit a petit, en tenant compte de ce que lon a fait precedemment pour tendre vers la
solution dun probleme

Le risque immediat offre un haut niveau de monitoring temps reel. Celui-ci peut etre assimile a
un thermometre des situations critiques, sans meme connatre les details des caracteristiques du
probleme.
Le risque accumule offre quant a lui un haut niveau de monitoring sur une certaine fenetre tempo-
relle (risque accumule et non plus temps reel).
Le second algorithme heuristique utilise par OSSIM permet la prevision des statistiques reseaux (paquets
emis et recus) en fonction des valeurs precedentes (Holt-winter). Ceci permettra la detection automatique
danomalies reseaux.
Par consequence, la correlation par heuristique offre :

Une vue globale et rapide de la situation
Une detection possible dattaques, non relevees par les autres methodes de correlation (se basant
sur des signatures)
CALM (Compromise and Attack Level Monitor), est un algorithme8 utilisant les evenements accumules et
fournissant une valeur indicative du niveau de securite global. Laccumulation devenements est effectuee
independamment pour tous les elements du reseau. Celle-ci est simplement calculee par la somme de
deux variables detat representant le risque immediat de chaque evenement :
1. Variable C ou niveau de fiabilite dune machine ou dun reseau, mesure la probabilite quune
machine ou un reseau soit compromis (source dune attaque effectue par un ver ou troyen installe
sur une machine a surveiller).
2. Variable A indique la probabilite que la machine ou reseau a surveiller soit la cible dattaques.
La variable A represente la probabilite quune attaque a ete lancee et quelle est reussie, alors que la
variable C fournit levidence quil y a eu une attaque et quelle a reussi.
Chaque machine du reseau a donc une variable A et C associee, fluctuant de la maniere suivante :
1. Toute attaque possible dune machine 1 (source) vers une machine 2 (cible) incrementera le niveau
A de la machine 2 et le niveau C de la machine 1.
2. Lorsquune reponse a une attaque est detectee (signifiant que lattaque est reussie), le niveau C
des deux machines sera incremente.
3. Lorsque levenement est interne (source interne), seul le niveau C de la machine source est
incremente.
CALM fonctionne dune maniere temps reel (accumulation temps reel des evenements). Il peut aussi etre
interessant dobserver ces statistiques dans une fenetre temporelle (accumulation sur le temps). En ef-
fet, ceux-ci varieront grandement en fonction de la fenetre utilisee puisquun fonctionnement temps reel
(accumulation continue devenements) aura pour effet de noyer certaines alarmes critiques dans la masse
dinformation. Nous pourrions assimiler le fonctionnement daccumulation sur le temps a un zoom sur
les statistiques temps reel.
8
Algorithme implemente dans OSSIM

Holt-Winter Algorithme, algorithme heuristique implemente dans le moteur de correlation temps reel
dOSSIM, permettant la decouverte de comportements anormaux sans lutilisation de seuils. Descrip-
tion tiree de : http ://www.usenix.org/events/lisa2000/full papers/brutlag/brutlag html/index.html
La detection anormale de comportements est decomposee en trois parties, chacune etablie selon son
predecesseur :
1. Un algorithme pour prevoir pas par pas les valeurs dune serie chronologique.
2. Une mesure de deviation entre les valeurs prevues et les valeurs observees.
3. Un mecanisme detectant lorsquune valeur est trop deviante de la valeur prevue.
Lalgorithme de prevision Holt-Winter fait appel aux principes de lissage exponentiel (genre de moyenne
mathematique permettant la prediction de valeurs). En effet, Holt-Winter fournit une methode un peu
plus complexe utilisant un triple lissage exponentiel. Pour plus dinformations au sujet de cet algorithme,
consultez lannexe J.
Correlation par diagramme detats (sequence devenements) Ce genre de correlation fait appel a
la detection par signatures. Ceci permettra a lutilisateur (administrateur reseau en charge de la securite),
de definir des regles de correlation a laide des signatures disponnibles. Exemple : Si lalarme A, B et C
est levee, il faut executer laction D. Ceci sapparente donc au moteur de correlation developpe par M.
Saladino dans le cadre de SIMS 20039 .
Le moteur de correlation dOSSIM a les caracteristiques suivantes :
Capacite de definir des variables dorigines et de destination
Utilisation des alarmes des detecteurs (detection par signature) et/ou des informations des moni-
teurs (monitoring) comme input pour la correlation
Utilisation de variables elastiques (accumulant des informations au cour du temps)
Architecture recursive (possibilite dutiliser des regles precedemment definie dans de nouvelle
regles)
2.4 Le monitoring
Le monitoring consiste en laffichage des informations fournies. Les consoles de monitoring utilisent les
differentes donnees produites par les procedes de correlation (decrit ci-dessus) pour la construction dun
affichage efficace et/ou resume.
9
Realise dans le cadre dun projet de diplome de linstitut Tcom de lEivd
(http ://www.tcom.ch/Tcom/Projets/SIMS/sims.html)

2.4.1 Risk monitor (moniteur du risque)
Ce moniteur appele RiskMeter permet laffichage des donnees produites par lalgorithme CALM
(decrit dans la section 2.3.3). Les informations C (mesure de la fiabilite) et A (mesure du niveau
dattaque) sont illustres graphiquement par ce moniteur.
2.4.2 Moniteur dutilisation, session et profile
Comme decrit plus haut, OSSIM place une grande importance sur le monitoring detaille de chaque
machine et profile. Il existe 3 differents types de monitoring dans OSSIM :
1. Monitoring dutilisation, offrant une vue generale dune machine (comme snmp le ferai)
2. Monitoring de profile, offrant des informations specifiques sur lactivite des utilisateurs, nous per-
mettant detablir un profil (pop, http, etc..) pour chaque utilisateur
3. Monitoring de session, offre un affichage temps reel des sessions en cours dun utilisateur
2.4.3 Path monitor (moniteur de chemin)
Ce moniteur offre un affichage temps reel des chemins de linformation empruntes par des donnees
emises par differentes machines sur le reseau. Il utilise les informations fournies par le moniteur de
session (identifiant chaque lien present sur le reseau) et par le moniteur de risque (fournissant le niveau
de risque de chaque machine) afin de construire un affichage agreable (a laide de differentes couleurs).
Deux methodes daffichage et danalyse sont disponibles.
Hard link analysis (Analyse des liens TCP)
Cette methode affiche uniquement les sessions TCP courantes. Le but de celle-ci est de pouvoir observer
la propagation dune attaque ou dun ver afin de determiner un perimetre de securite.
Soft link analysis
Cette methode danalyse offre laffichage de tous les liens percus sur le reseau (UDP, TCP, ICMP inclus).
2.4.4 Forensic console (Console legale)
Cette console offre lacces a toutes les informations recueillies et stockees par le collecteur. Elle est donc
un outil de recherche sur la base de donnees devenements. Celle-ci permet une analyse a posteriori
detaillee et approfondie des elements reseaux.

2.4.5 Control Panel (panneau de controle)
Cette console offre un apercu de haut niveau de la securite. Cette console permet la definition de seuils
generant des alarmes de haut niveau a destination de ladministrateur reseau en charge de la securite.
Laffichage est simple est le plus concis possible et permet la visualisation des informations suivantes :
Monitoring constant du niveau de risque
Monitoring constant du reseau (statistiques dutilisation)
Monitoring des seuils definis
Monitoring des profiles depassant les seuils
2.5 Architecture
Larchitecture dOSSIM est divisee en 2 principaux etages :

1. Pre-processing, remontee devenements des moniteurs et detecteurs dans une base de donnees
commune
2. Post- processing, analyse centralisee
La figure 2.1 illustre le fonctionnement en 2 etages (comme mentionne ci-dessus). Nous remarquons que
ces deux etages disposent de differentes bases de donnees permettant la sauvegarde des informations
intermediaires (correlees). Defintions des bases de donnees :
F IG . 2.1 Architecture dOSSIM
EDB La base de donnees des evenements (la plus grande), stockant toutes les alarmes individuelles

KDB La base de donnees des connaissances, sauvegardant les configurations etablies par ladministra-
teur en charge de la securite
UDB La base de donnees des profiles, stockant toutes les informations du moniteur de profile
2.5.1 Data flow
Afin daider a la comprehension, nous allons detailler le cheminement dune alarme dans larchitecture
definie par la figure 2.1. Le schema de la figure 2.2, illustre le fonctionnement decrit ci-dessous :
1. Detection dun evenement suspect par un detecteur (par signatures ou par lheuristique)
2. Si necessaire, des alarmes sont regroupees (par le detecteur) afin de diminuer le trafic reseau
3. Le collecteur recoit la/les alarme(s) via differents protocoles de communications ouverts
4. Le parser normalise et sauve les alarmes dans la base de donnees devenements (EDB)
5. Le parser assigne une priorite aux alarmes recues en fonction de la configuration des polices de
securites definies par ladministrateur securite
6. Le parser evalue le risque immediat represente par lalarme et envoie si necessaire une alarme
interne au Control panel
7. Lalerte est maintenant envoyee a tous les processus de correlation qui mettent a jour leurs etats et
envoient eventuellement une alerte interne plus precise (groupe dalerte provenant de la correlation)
au module de centralisation.
8. Le moniteur de risque affiche periodiquement letat de chaque risque calcules par CALM10 .
9. Le paneau de controle affiche les alarmes les plus recentes et met a jour les indices des etats qui
sont compares aux seuils definis par ladministrateur. Si les indices sont superieurs aux seuils
configures, une alarme interne est emise.
10. Depuis le panneau de controle, ladministrateur a la possibilite de visualiser et rechercher des liens
entre les differentes alarmes a laide de la console forensic
10
Algorithme decrit dans la section 2.3.3

F IG . 2.2 Data flow du serveur OSSIM

Chapitre 3
Fonctionnement logiciel dOSSIM
Des informations relatives a linstallation sont disponibles dans les annexes ou sur le site officiel dOssim
(http ://www.ossim.net/docs.php)
3.1 Les applications Ossim-server et Ossim-agent

Ossim-agent recupere simplement les informations des fichiers de logs des plugins (fichier fast.log
pour Snort) et les envoie directement au serveur OSSIM permettant ainsi le traitement temps reel
de celles-ci. De plus, lagent Ossim soccupera de la mise en marche et de larret des differentes
sondes qui lui sont connectees. Il ne sera ainsi pas necessaire de demarrer la sonde Snort a la
main puisque son activation sera effectuee depuis la console de management offerte par Ossim-
server.
Ossim-server constitue le noyau de larchitecture. En effet, celui-ci comporte les modules danalyse
et de correlation des donnees ainsi quun serveur Web permettant linteraction avec lutilisateur
(administrateur reseau).
3.2 Fonctionnement de larchitecture avec une sonde Snort
Le principe de communication dune sonde Snort avec le serveur OSSIM est illustre par la figure 3.1.
Nous remarquons que lIDS1 Snort est independant du programme client dOSSIM (nomme : ossim-
agent) et que deux flux dinformations sont emis en direction du serveur.
3.2.1 Pourquoi deux flux dinformations ?
Le flux nomme Requetes SQL pour depos des alertes est utilise afin de deposer directement les
alertes dans la base de donnees Snort DB du serveur. Ceci permettra larchivage de celles-ci et
1
Intrusion Detection System
17
F IG . 3.1 Principe de communication entre une sonde Snort et le serveur dOSSIM
leur conslutation via ACID2 , permettant ainsi lanalyse precise de chaque alertes.
Le flux nomme Envoi des alertes pour lanayse temps reel (TCP et protocole applicatif propre a
OSSIM est quant a lui necessaire pour le procede danalye et de correlation temps reel opere sur
le serveur dOSSIM.
Ces deux flux dinformations redondants sont indispensables si lon ne veut pas redefinir le protocole
denvoi des informations dans la base de donnees Snort DB. En effet, le plugin de sortie Mysql ne
serait pas suffisant pour un traitement temps reel puisque le stockage des informations dans une base de
donnees casse le procede temps reel. Un tel fonctionnement impliquerait linterrogation continuelle
de la base de donnees afin de decouvrir les nouvelles donnees inserees. Les concepteurs dOSSIM ont
donc prefere utiliser deux flux dinformations plutot que de creer un nouveau plugin de sortie pour Snort
permettant denvoyer les alertes dans un seul flux structure au serveur. Dans ce mode de fonctionnement,
cest le serveur qui se chargerait ensuite du traitement temps reel et de linsertion des informations dans
une base de donnees.
Pour lanalyse et la correlation, le serveur Ossim utilise uniquement les alertes provenant de lagent Os-
sim, alors que les alertes directement stockees dans la base de donnees sont uniquement utilisees pour la
2
Analysis Console for Intrusion Databases, interface Web integree a OSSIM permettant linterrogation dune base de
donnees Snort (developpe dans le cadre du projet Open Source Snort)

consultation.
3.3 Fonctionnement de larchitecture avec une sonde Ntop et le plugin

RRD
Le principe de communication dune sonde Ntop avec le serveur OSSIM est illustre par la figure 3.2.
F IG . 3.2 Principe de communication entre une sonde Ntop et le serveur dOSSIM
3.3.1 Quest-ce que Ntop ?
Ce logiciel analyse de maniere temps reel le trafic reseau et met a disposition une liste de compteurs (par
exemple : IP DNSBytes, IP HTTPBytes), permettant le monitoring ainsi que le calcul de statistiques
reseaux. La sonde Ntop met en place un serveur Web (sur le port 3000) permettant le monitoring ainsi
que la configuration de celle-ci a distance.
Le plugin de sortie RRD3 est necessaire pour lintegration des fonctionnalites heuristiques et de detection
de seuils dans OSSIM. Celui-ci permet lenregistrement des donnees Ntop sous forme de tourniquet (les
3
Round Robin Database

plus vieilles donnees sont ecrasees par les nouvelles). Linterrogation de la base de donnee RRD est en-
suite facilitee a laide de loutil RRDtool4 utilise par le script rrd plugin.pl offrant les fonctions danalyse
heuristiques et de controle de depassement de seuils.
Des seuils RRD ainsi que les parametres de lanalyse heuristique (algorithme Holt-Winter explique dans
lannexe J) peuvent ensuite etre defini par ladministateur securite via le framework (cf. section 4.9.4).
Cette configuration permettra la generation dalertes lorsque des valeurs excessives auront ete detectees
par rrd plugin.pl.
3.3.2 Fonctionnement
Le script Perl rrd plugin.pl effectue la liaison entre Ntop et lagent Ossim pour les fonctionnalites
heuristiques (Holtwinter algorithme) et de detection de seuils. Celui-ci interroge periodiquement la
base de donnees RRD (illustree par Ntop/rrd log file sur la figure 3.2) a laide de loutil RRDtool.
Il recupere (via des requetes SQL sur le serveur) les seuils des compteurs definis par ladministrateur
reseau a laide du framework de configuration5 et les compare aux donnees precedemment recuperees
(a laide de RRDtool). Les eventuels depassements des seuils sont ensuite stockes dans un fichier de log
(/var/log/ossim/rrd plugin.log) qui sera recupere par lagent Ossim afin de permettre lenvoi temps reel
des informations au serveur.
La correlation des ces informations peut ensuite etre effectuee sur le serveur.
3.4 Fonctionnement de larchitecture avec une sonde P0f
Le principe de communication dune sonde P0f avec le serveur OSSIM est illustre par la figure 3.3.
3.4.1 Quest-ce que P0f ?
P0f est un logiciel de detection de systemes dexploitations6 passif. Il analyse les trames transitant sur le
reseau (le segment analyse) et les compare avec une base de donnees des caracteristiques de chaque OS
(prise dempreintes) afin den retrouver lOS correspondant :
1. detection de la presence dun firewall et NAT
2. detection dun load balancer (repartiteur de charge reseau)
3. detection de la distance (TTL) de la machine distante ainsi que depuis combien de temps la ma-
chine est demarree
P0f est totalement passif. Il ne genere aucun traffic reseau supplementaire !
4
http ://people.ee.ethz.ch/ oetiker/webtools/rrdtool/
5
interface Web offerte par le serveur. Menu : Configuration - RRD config
6
Operating System (OS)

F IG . 3.3 Principe de communication entre une sonde P0f et le serveur dOSSIM
Celui-ci est assez simple. P0f ecrit ses logs dans le fichier /var/log/ossim/p0f.log (chemin fournit a P0f
par lagent Ossim lors du lancement de P0f). Ce chemin se trouve donc dans la configuration du plugin
P0f (/etc/ossim/agent/plugins/p0f.xml) de lagent. Le daemon agent (ossim-agent) soccupera ensuite de
les recuperer afin de les envoyer au serveur OSSIM pour une analyse temps reel.
3.5 Fonctionnement de larchitecture avec une sonde TCPTrack
Le principe de communication dune sonde TCPTrack avec le serveur OSSIM est illustre par la figure
3.4.
3.5.1 Quest-ce que TCPTrack ?
TCPTrack est un sniffer affichant des informations sur les connexions TCP quil rencontre sur une inter-
face. Il detecte passivement les connexions TCP sur linterface a analyser et affiche les informations de
la meme maniere que la commande Unix top. Il permet laffichage des adresses source et destination, de
letat de la connexion, du temps de connexion ainsi que de la bande passante utilisee.

F IG . 3.4 Principe de communication entre une sonde TCPTrack et le serveur dOSSIM
TCPTrack fonctionne dune maniere similaire a laffichage Web des informations de Ntop. En effet,
aucune information nest spontanement envoyee vers le serveur OSSIM. TcpTrack ouvre simplement
un port serveur7 sur la loopback de lagent. Cest ensuite le serveur OSSIM qui, lors du procede de
correlation, interrogera si necessaire lagent afin quil interroge a son tour TCPTrack (via la loopback).
Une fois les informations recoltees par lagent, celui-ci se chargera de les remettre au serveur qui les
utilisera pour la correlation. Lagent joue donc un role dintermediaire entre le serveur et le sonde TCP-
Track.
3.6 Fonctionnement de larchitecture avec une sonde PADS
Le principe de communication dune sonde PADS8 avec le serveur OSSIM est illustre par la figure 3.5.
7
port 40003 par defaut
8
Passive Asset Detection System

3.6.1 Quest-ce que PADS ?
PADS va permettre didentifier les machines (adresses IP et MAC) ainsi que leurs services uniquement
en sniffant le reseau. Il permettra laffichage des services dune machine sans avoir a operer un scan actif
comme nmap9 . Il permettra laffichage des services dune machine configuree sur OSSIM sans operer
un scan actif.
Le logiciel PADS reportera simplement toutes les informations recoltees dans le fichier de log /var/log/ossim/pads.csv
(indique dans la configuration du plugin, fichier /etc/ossim/agent/plugins/pad.xml). Lagent Ossim se
chargera ensuite de les recolter et de les envoyer de maniere temps reel au serveur.
F IG . 3.5 Principe de communication entre une sonde PADS et le serveur dOSSIM
9
Outil integre a OSSIM permettant, entre autre, des scans de ports

3.7 Fonctionnement de larchitecture avec une sonde Syslog
Le principe de communication dune sonde HIDS10 Syslog avec le serveur OSSIM est illustre par la
figure 3.6.
F IG . 3.6 Principe de communication entre une sonde HIDS Syslog et le serveur dOSSIM
3.7.1 Quest-ce quune sonde HIDS
Ces sondes ont pour but de rechercher des patterns specifiques dans des fichiers de logs. Des quune suite
de caractere (pattern) appartenant a la liste des patterns recherche est detecte, une alerte est generee. Il
est ainsi possible de remonter des evenements specifiques (critiques) vers la console de monitoring. De
plus, a laide du sid de chaque regle, il est possible de les utiliser dans des regles de correlation sur le
serveur.
10
Host Intrusion Detection System

Le parser analysant le fichier Syslog dune machine Linux est directement present sous forme native sur
les agents OSSIM. Son code et ses regles sont presents dans un seul et unique fichier /usr/share/ossim-
agent/pyossim/ParserSyslog.py. Il analysera le fichier de logs de maniere temps reel et informera le
serveur OSSIM, via la connexion presente entre lagent et le serveur, des quun pattern present dans la
liste de pattern interdits (blacklist) aura ete detecte.
3.8 Fonctionnement de larchitecture avec une sonde HIDS IIS (Internet

Information Services)
Le principe de communication dune sonde HIDS11 IIS avec le serveur OSSIM est illustre par la figure
3.7.
F IG . 3.7 Principe de communication entre une sonde HIDS IIS et le serveur dOSSIM
11
Host Intrusion Detection System

3.8.1 Quest-ce quune sonde HIDS
Ces sondes ont pour but de rechercher des patterns specifiques dans des fichiers de logs. Des quune suite
de caractere (pattern) appartenant a la liste des patterns recherche est detecte, une alerte est generee. Il
est ainsi possible de remonter des evenements specifiques (critiques) vers la console de monitoring. De
plus, a laide du sid de chaque regle, il est possible de les utiliser dans des regles de correlation sur le
serveur.
Le serveur web de Windows (IIS) doit obligatoirement utiliser un programme specifique (SnareIIS) per-
mettant denvoyer les logs du serveur sur une machine distante (lagent OSSIM dans notre cas). En effet,
aucun agent OSSIM nest disponible pour Windows.
Le parser present sous forme native sur les agents OSSIM (/usr/share/ossim-agent/pyossim/ParserIIS.py)
analysera le fichier de logs de maniere temps reel et transmettra par defaut tous les logs du serveur web
au serveur OSSIM via le flux present entre le serveur et lagent (chaque log etant vu comme une alerte
sur le serveur OSSIM).

Chapitre 4
Fonctionnement du Framework (interface

Web et serveur OSSIM)
4.1 Avant propos et terminologies
Un howto expliquant la configuration de base du framework (ajout et configuration dagents et dhotes a

proteger) est disponible a ladresse suivante : http ://www.ossim.net/docs/User-Manual.pdf
Ce chapitre fera le lien entre les differents outils decrits precedemment et les menus disponibles dans le
framework dOSSIM.
Trois termes bien distincts seront employes dans ce chapitre. Il est tres important den saisir la difference :
Alerte Information de detection dintrusion ou danomalie brut genere par une sonde. Typiquement, les
alertes Snort generees par un agent. Celles-ci contiendront donc un grand nombre de faux positifs...
Groupe dalertes Information correspondant au resultat dune correlation (alerte de haut niveau). Il
sagira donc de plusieurs alertes reliees ensemble selon des caracteristiques definies par les direc-
tives de correlation.
Alarme Alerte ou groupe dalertes ayant atteint un niveau de risque superieur ou egal a 2 (valeur cal-
culee selon la forumule 4.1, puis arrondie. Par exemple : 1.6 est arrondi a 2).
4.2 Architecture des menu du framework
Linterface de configuration et monitoring offerte par OSSIM (framework) se compose de divers menu
et sous-menu illustre par la figure 4.1 page 43. Ce chapitre traitera chacun deux afin que le lecteur soit
ensuite capable dutiliser plainement les fonctionnalites dOSSIM.
27
4.3 Definition du risque
Plusieurs parametres permettent de qualifier le niveau de dangerosite (risque) dune alerte/groupe dalertes.
Il est important de bien saisir leur signification afin detre a meme de creer des regles de correlation ou
meme de gerer correctement les alarmes selon leur niveau dimportance.
Asset Il sagt la dune valeur permettant de definir limportance dune machine sur le reseau. En effet,
un serveur Web sera souvent une ressource plus precieuse pour une entreprise quune imprimante
reseau. Comme nous le verrons apres, ces specifications seront prises en compte lors du calcul du
risque de chaque alerte.
Il est ainsi possible de definir pour chaque machine (menu Policy sous-menu Hosts) lAsset de
celles-ci. Cette valeur doit etre comprise entre 0 et 5 (0 = machine peu importante pour lentreprise,
5 = machine tres importante pour lentreprise).
Priority Cette valeur permet de mesurer la gravite dune alerte ou dun groupe dalertes isolee. En
effet, celle-ci ne tient aucunement compte de lenvironement ou de lhote a proteger. Ce niveau
est donc uniquement dependant de lalerte ou du groupe dalertes (resultat dune correlation). Il
est donc possible dajuster le niveau Priority des alertes de chaque plugins via le menu Configura-
tion, sous-menu Plugins. Celui-ci est aussi definit (surcharge des priorites definies par les alertes
independantes) pour chaque regle de correlation, permettant le reglage de la priorite du resultat de
la correlation (groupe dalertes).
La valeur de ce parametre est ajustable entre 0 et 5.
Reliability En terme de risque, ce parametre pourrait sappeler la probabilite. Celui-ci est defini pour
chaque alerte independante (via le menu Configuration, sous-menu Plugins). Il est ainsi possible
de qualifier la probabilite que lalerte se produise.
Ce parametre sera principalement ajuste sur les groupes dalertes par le moteur de correlation
(surcharge de la valeur definie pour le plugin). Celui-ci sera capable daugmenter la reliability
dun groupe dalarme a chaque fois quune sous-regle sera matchee. Ceci prouvera pas a pas que
ce groupe dalertes (alerte de haut niveau) nest pas un faux positif. Le terme reliability peut donc
etre traduit par la fiabilite quune alarme nest pas un faux positif. La valeur de ce parametre est
comprise entre 0 et 10 (equivalent a 0% = cest un faux positif et 100%= ce nest pas un faux
positif).
Le risque permet de lier les trois parametres precedent par la formule suivante (4.1) et detablir si une
alerte ou un groupe dalertes est mute en alarme :
Asset P riority Reliability
Risk = (4.1)
10
Le lien entre letape 6 et 9 de la figure 2.2 du chapitre 2 illustre la mutation dalertes/groupe dalertes
en alarmes.
4.4 Menu Control Panel
Ce menu offre quatre differentes vues :

4.4.1 Metrics
Ce sous-menu affiche les informations relatives a lalgorithme CALM (decrit dans la section 2.3.3) de
maniere globale ainsi que sur les reseaux definis par ladministrateur et les hotes dont les niveaux A1
ou C2 sont eleves. Une visualisation graphique est offerte ainsi quun historique. Il est donc possible
dobserver les parametres A et C de maniere temps reel via cette interface.
CALM recupere toutes les alertes afin de les associer au niveau A et/ou C de lhote voulu sur un interval
de temps. Son fonctionnement est illustre par la figure 4.2 page 44 .
Il offre une vue rapide du nombre dalertes detectees sur les hotes du reseau. Par un clic sur licone
dinformation, il est possible de generer un ticket permettant le depos de commentaires sur le serveur au
sujet des niveaux observes (pour plus dexplications consultez la section 4.5.5). Licone graphique offre
quant a lui (lors dun clic sur celui-ci) un affichage des niveaux A et C de lhote ou reseau specifie.
4.4.2 Alarms
Ce sous-menu offre une vue des alarmes detectees. En effet, les evenements affiches contiendront uni-
quement des alarmes de haut niveau (niveau de risque superieur ou egal a 2, calcules selon la for-
mule 4.1). Il est alors possible de cliquer sur le nom de lalarme (champ Alarm) afin den observer plus
precisement les causes. Deux situations sont alors envisageables :
Lalarme provient dune directive de correlation (groupe dalertes ayant un risque superieur ou egal a 2)
Un menu permettant la visualisation des regles matchees est affiche lors du clic sur le nom de
lalarme. Dans cette nouvelle vue, il sera ensuite possible (via le lien Visualize alarm et une applet
Java3 ) dobserver graphiquement les trames, ayant genere lalarme, transiter sur le reseau. Cette
reconstitution est effectuee a laide de la base de donnee Snort et des adresses IP contenues dans
les differentes alertes.
Lalarme provient dune alerte de risque eleve (plus grand ou egal a 2) Le seul contenu pertinant pou-
vant etre affiche sera le dump4 de celle-ci. Lors du clic sur le nom de lalarme lutilisateur sera
redirige sur linterface dACID (equivalent au sous-menu Alerts de ce menu). Un filtrage sera auto-
matiquement applique afin dafficher uniquement les alertes provenant des memes adresses IP dans
la fenetre temporelle de lalerte. Il sera ainsi possible dobserver lalerte ayant provoque lalarme
(risque plus grand ou egal a 2) ainsi que toutes les autres alertes de la meme fenetre temporelle.
Par defaut, toutes les alarmes ont un status (champ Status) OPEN. Cela signifie quaucun administrateur
en charge de la securite na analyse lalarme ou na reussi a y trouver une solution. Plusieurs possibilites
soffrent alors a lui :
1. Effacer lalarme (il sagit clairement dun faux positif). Lalarme sera effacee a jamais...
1
niveau dattaque auquel un systeme est sujet, mesure le risque potentiel du aux attaques detectees
2
niveau de fiabilite dune machine, mesure le niveau de probabilite quune machine soit compromise (hacker)
3
http ://scanmap3d.sourceforge.net/
4
Contenu brut de lalerte Snort

2. Fermer le status de lalarme (par un clic sur OPEN contenu dans le champ Status). Dans ce cas
lalarme nest pas effacee mais nest plus directment affichee dans le menu Alarms. Afin de visua-
liser a nouveau les alarmes fermees (status CLOSED), il sera necessaire de deselectionner longlet
Hide closed alarms
3. Generer un ticket permettant la saisie dinformations sur les actions entreprises par ladministrateur
en charge de la securite (par un clic sur licone dinformation contenu dans le champ Action). Il
aura de plus la possibilite de modifier le status de lalarme (OPEN ou CLOSED) afin dindiquer
si le probleme a pu etre resolu ou non. Ce fonctionnement est particulierement interessant lorsque
plusieurs administrateur en charge de la securite travaillent sur le meme framework OSSIM. Le
principe de generation de ticket et dajout dinformations au sujet dune alarme est decrit plus en
detail dans la section 4.5.5.
Calcul du risque des alarmes
Le calcul du risque des alarmes (champ Risk de ce sous-menu) est opere a laide de la formule 4.1.
Les valeurs des parametres Priority et Reliability sont directement tirees du resultat de la correlation (si
lalarme est un output dune correlation, groupe dalertes) ou de lalarme unique (si lalarme est une
alerte de niveau de risque superieur a 2). Le calcul du risque est donc opere de maniere differente entre
les alertes (section 4.4.3) et les alarmes. En effet, dans le calcul du risque des alarmes, la valeur du
parametre Asset sera la valeur la plus elevee entre la source de lalarme (de lattaque) et la destination de
celle-ci. Les autres parametres (Priority et Reliability) restent quant a eux les memes que pour lalerte
ou groupe dalertes ayant genere lalarme.
Comme dans le calcul du risque des alertes (section 4.4.3), la valeur de lAsset (source et destination de
lattaque) est en premier lieu recuperee dans les configurations des machines (sous-menu Hosts du menu
Policy) puis (si aucune valeur nest configuree dans ce sous-menu) dans les configurations des reseaux
(etablies dans le sous-menu Network du menu Policy).
4.4.3 Alerts
Ce sous-menu permet la visualisation des alertes generees (alertes brutes) par les differentes sondes
connectees au serveur ainsi que les resultats des correlations qui ont abouties (regles matchees). En effet,
ce sous-menu permet la consultation de toutes les alertes recoltees par le serveur avant lapplication des
differents procedes de correlation sur celles-ci.
La valeur du risque (champ Risk) calcule pour chaque alerte est directement opere a laide de la formule
4.1. Comme explique en section 4.3, les valeurs des parametres Priority et Reliability utilises dans le
calcul du risque sont propres aux alertes (configure dans le sous-menu Plugins du menu Configuration).
La valeur de lAsset utilisee pour le calcul du risque est celle configuree pour la machine de destination
ou, si celle-ci nest pas configuree dans le sous-menu Hosts du menu Policy, celle configuree pour le
reseau auquel est connecte la machine de destination (configure dans le sous-menu Network du menu
Policy).

Ce sous-menu est en fait dune version quelque peu modifiee dACID5 . Il sera donc possible dobtenir
des informations detaillees et precises sur les alertes via ce sous-menu. Pour de plus amples informations
sur lutilisation dACID, je vous laisse consulter la documentation suivante :
http ://acidlab.sourceforge.net/acid instruct.html
4.4.4 Vulnerabilities
Ce sous-menu offre une interface Web au scanner de vulerabilites Nessus6 . Celle-ci permettra lactivation
du script /usr/share/ossim/scripts/do nessus.pl, qui procedera a linterrogation de la base de donnees
dOSSIM afin de determiner quelles sont les machines et/ou reseaux a scanner (Les machines a scanner
sont configurees a laide du sous-menu Hosts du menu Policy). Le script do nessus.pl effectuera ensuite
le scan par lappel du client nessus installe sur le serveur OSSIM. Les rapports de securites generes par
Nessus seront ensuite disponibles dans ce sous-menu.
Ce script soccupe ensuite de remplir la table host plugin sid repertoriant les sid Nessus pour lesquels
chaque machine est vulnerable. Ce fonctionnement (cross-correlation Nessus-Snort) est decrit plus en
detail dans la section 4.8.2.
4.5 Reports Menu
Ce menu offre cinq differents sous-menus en rapport avec la securite du reseau.
4.5.1 Host Report
Ce sous-menu permet dobserver les machines configurees dans le sous-menu Hosts du menu Policy. Il
est ainsi possible dobserver le hostname, lAsset, lIP et lOS des machines configurees.
En cliquant sur le hostname de la machine voulue, il est possible dacceder a differenes caracteristiques
et informations de celle-ci. Il sera ainsi possible dobserver les caracteristiques suivantes :
Section principale
Inventory Inventaire de la machine (Nom, IP, Systeme dexploitation, adresse MAC, Sensor ana-
lysant son trafic, Ports ouverts). Toutes les caracteristiques affichees sont celles configurees
par ladministrateur reseau, mis a part les ports ouverts. En effet, le plugin PADS7 permet la
detection des ports ouverts dune machine uniquement par lanalyse des trames transitant sur
le reseau. Cest donc les informations fournie par PADS qui permettent lidentification des
ports ouverts de la machine en question.
En cliquant sur le mode Passive (mode de detection de PADS), le mode de detection des
ports passe en active. Il est alors possible dobserver la liste des ports ouverts a laide dun
5
Analysis Console for Intrusion Databases, http ://acidlab.sourceforge.net/
6
http ://www.nessus.org/
7
Passive Asset Detection System, plugin decrit dans la section 3.6.

programme de scan actif (nmap). Le lien update permet quant a lui lexecution de nmap
(programme de scan actif) afin de mettre a jour la liste des ports ouverts.
Metrics Niveau A et C de la machine selectionnee (niveaux calcules a laide de lalgorithme
CALM8 .
Usage Offre laffichage graphique des informations fournies par Ntop9 . En effet, ce plugin met en
place un serveur web sur lagent qui permettra laffichage de toutes les donnees statistiques
recoltees par Ntop. Le lien (Usage) fournit donc uniquement une redirection vers le serveur
Web du plugin Ntop de lagent voulu (agent analysant les informations de la machine en
question).
Anomalies permettant de visualiser la detection danomalies operee par Ntop. Il sagt la des
resultats de lanalyse heuristique decrite en section J.
Sous-section Alarms :
Source or Dest Ce lien permet la visualisation des alarmes de haut niveau, ayant comme adresse
source ou destination, ladresse de la machine en question.
Source Ce lien permet la visualistion des alarmes de haut niveau, ayant ladresse de la machine
en question comme source.
Destination Ce lien permet la visalisation des alarmes de haut niveau, ayant ladresse de la ma-
chine en question comme adresse de destination.
Sous-section Alerts :
Main Ce lien permet laffichage dACID10 , offrant un menu de navigation dans les alertes generees
par les differents plugins. Laffichage fourni par le lien Main, permet de connatre le nombre
doccurence dalertes de la machine en question (comme source et/ou destination). Il est en-
suite possible de continuer son investigation en cliquant sur les liens offerts par linterface
dACID.
Src Unique alerts Ce lien affiche directement les alertes (via ACID) ayant ladresse de la machine
en question comme source. Il est ensuite possible de continuer son investigation en cliquant
sur les liens offerts par linterface dACID.
Dst Unique alerts Ce lien affiche directement les alertes (via ACID) ayant ladresse de la ma-
chine en question comme destination. Il est ensuite possible de continuer son investigation
en cliquant sur les liens offerts par linterface dACID.
Sous-section Vulnerabilites :
Vulnmeter Ce lien offre une interface entre le framework et le scanner de vulnerabilites Nessus.
En effet, cette interface affiche le nombre de failles detectees sur toutes les machines scannees
en mettant en evidence (en rouge) le resultat de la machine en question. Il suffira ensuite de
cliquer sur ladresse IP de la machine voulue afin dobserver le rapport de vulnerabilite de
celle-ci. Le lien update scan offre la possibilite deffectuer un nouveau scan afin de mettre a
jour la liste des vulnerabilites de toutes les machines configuree pour un scan Nessus.
8
Principe decrit en section 4.4.1
9
Outil danalyse temps reel du trafic reseau. Logiciel decrit dans la section 3.3.1
10
Analysis Console for Intrusion Databases, http ://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html

Security Problems Ce lien offre la vue directe du rapport de vulnerabilites de la machine en

question (equivalent au clic sur lIP de la machine en rouge du lien Vulnmeter).
4.5.2 Security Report
Ce sous-menu offre une visualisation graphique, sans fenetre temporelle, des niveaux A (Top Atta-
cked) et C (Top Attacker) de lalgorithme CALM (explique en section 2.3.3). Il permet dobserver les
10 machines figurant le plus souvent comme source des alertes (Top Attacker) et les 10 figurant les plus
souvent comme destination des alertes (Top Attacked). En cliquant sur le nom dune machine, il sera
possible dobserver les alertes relatives a celle-ci dans ACID.
Le graphique Top 10 used ports offre une vision des ports de destination des alertes detectees. Il permet
ainsi de determiner quels sont les services les plus attaques. En cliquant sur le numero de port voulu, il
est possibles dobserver toutes les alertes a destination de celui-ci (a laide de linterface dACID).
Les informations fournies par Top 10 alerts offre simplement une vision textuelle et graphique des alertes
les plus rencontrees, alors que Top 10 alerts by Risk offre une vision des alertes les plus rencontrees ayant
un risque eleve.
4.5.3 PDF Report
Ce sous-menu permet la recuperation de rapports PDF. Il est ainsi possible de recuperer 3 differents
rapports PDF, comportant chacun des informations specifiques :
Security Report Permettant la generation dun document PDF identique au sous-menu Security Report
(Section 4.5.2)
Metrics Report Permettant la generation dun document PDF, offrant une vue numerique des niveau
A et C de lalgorithme CALM11 en fonction des fenetres temporelles selectionnees.
Incident Report Permettant la generation dun document PDF, offrant le resume des incidents reportes
par les gestionnaires du reseaux (personnes physiques) utilisant OSSIM (sous-menu Incident,
menu Reports)
4.5.4 Anomalies
Ce sous-menu offre laffichage des resultats de lalgorithme heuristique Holt-Winter (explique en section
2.3.3).
Cette fonctionnalite comporte malheureusement certains bugs qui la rende encore non fiable.
11
algorithme explique en section 2.3.3

4.5.5 Incident
Ce sous-menu offre un archivage des commentaires deposes par les differents administrateurs en charge
de la securite. En effet, ce sous-menu permet de deposer des annotations sur les activites effectuees ainsi
que de fermer les alarmes/problemes ayant ete resolus (principe de fermeture dalarmes explique en
section 4.4.2).
Differents sujets darchivages sont dipsonibles :
OSSIM Permettant de deposer des commentaires sur des alarmes specifiques (ticket ALA) ou sur des
metriques marginaux (ticket MET). Il sagit donc du menu dans lequel lutilisateur est renvoye
lorsquil clic sur licone dinformation dans le sous-menu Metrics ou Alarms du menu Control
Panel.
Hardware Permettant de deposer des commentaires sur le hardware dOSSIM et des problemes ren-
contres sur celui-ci.
Install Permettant de deposer des commentaires sur linstallation de nouveaux agents et/ou plugins.
Un outil de recherche integre dans la page Web dincidents, permettra de retrouver et trier les commen-
taires sur la base de mots cles. Celui-ci propose plus ou moins de champs de recherche (Filter Advenced
ou Filter simple). Apres avoir selectionne son sujet darchivage il sera possible dajouter de nouveaux
commentaire en cliquant sur lien Insert new Incident.
Vous pourrez ensuite completer les champs offerts et ajuster le niveau de priorite de lincident (commen-
taire).
4.6 Monitor Menu
Cette section offre une representation graphique de letat du reseaux et des differents agents places sur
celui-ci.
4.6.1 Riskmeter
Ce sous-menu offre uniquement laffichage de lalgorithme CALM12 . Il sagit donc dune representation
reduite du sous-menu Metrics du menu Control Panel (explications en section 4.4.1).
4.6.2 Session
Ce sous-menu offre une vue des sessions TCP actives (ou qui lont ete recemment). Cette visualisation
fait appel a loutil Ntop (explications technique en section 3.3). En effet, celui-ci repertorie toutes les
connexions TCP quil appercoit depuis le ou les agents sur lesquels il est place. Il offre ensuite, via son
12
Algorithme explique en sections 4.4.1 et 2.3.3

interface web (port 3000 de lagent) une liste de connexions detectees.
Cette sous-section offre ensuite la possibilite de visualiser ces informations en fonction dune sonde
(agent Ntop) ou en fonction dun reseau. Plusieurs comportements sont alors possibles :
En fonction dune sonde Ce sous-menu affiche simplement la page web fournie par le serveur web
Ntop de la sonde en question.
En fonction dun reseau Ce sous-menu affiche toutes les informations disponibles sur les sessions TCP
des hotes situees sur le reseau en question.
Pour ce faire, le framework effectuera un scan Nmap13 de tout le reseau en question. Pour chaque
machine decouverte, il determinera avec quelle sonde celle-ci est associee (association effectuee
dans le sous-menu Hosts du menu Policy, champ Sensors). Une fois les associations resolues, il
interrogera les serveur web Ntop des sondes en question afin de recuperer les informations sur les
sessions TCP des machines voulues. Il generera ensuite une page web a laide des informations
recoltees.
4.6.3 Network
Cette sous-section fait simplement appel a linterface web fournie par les sondes hebergeant un agent
Ntop. Il est ainsi possible de selectionner lagent sur lequel lon desire se connecter puis de choisir le
genre dinformations desirees. Ces informations sont donc relative a la sonde Ntop (reseau sur lequel
celle-ci est placee) et non pas a un hote ou un reseau specifique.
Etant donne que ce sous-menu fait appel a linterface web de Ntop, de plus amples informations sur son
utilisation sont disponibles dans le document suivant : http ://www.ntop.org/ntop-overview.pdf
4.6.4 Sensors
Ce sous-menu permet simplement la visualisation des plugins installes sur les differents agents actifs. A
laide de celle-ci, il sera possible darreter ou de desactiver le plugin a distance (lien stop ou disable). La
desactivation du plugin engendrera son non activation lors dun redemarrage de lagent alors que larret
naura aucune inscidence lors dun redemarrage de lagent. Lorsquun plugin est arrete ou desactive, il
est possible de le redemarrer ou le reactiver a laide de ce sous-menu (lien start ou enable).
4.7 Policy Menu
Ce menu offre une interface de configuration du reseau a surveiller. En effet, il est necessaire dindiquer
les plages dadresses IP des reseaux a analyser ainsi que les hotes a surveiler. Les explications ci-dessous
seront succintes puisque le document suivant : http ://www.ossim.net/docs/User-Manual.pdf offre deja
des explications completes a ce sujet.
13
Outil de scan reseaux

4.7.1 Hosts
Ce sous-menu permet la configuration des machines a surveiller. En effet, il est possible de definir lim-
portance de la machine (champ asset), les seuils dalerte pour lalgorithme CALM associe a la machine
(champ Threshold A et Threshold C), le profile RRD utilise pour lanalyse heuristique sur la machine en
question (detection de depassement de seuils et algorithme Holt-Winter) champ RRD Profile, le ou les
agents etant capable de recuperer (sniffer) les informations reseaux de la machine (champ Sensors), le
type de scan a effectuer (champ Scantype).
4.7.2 Networks
Ce sous-menu permet la definition des reseaux a surveiller. En effet, il est possible de definir la plage
dadresses du reseau (champ IPs), limportance de celui-ci (champ asset), les seuils dalerte pour lal-
gorithme CALM associe au reseau (champ Threshold A et Threshold C), le profile RRD utilise pour
lanalyse heuristique sur le reseau en question (detection de depassement de seuils et algorithme Holt-
Winter) champ RRD Profile, le type de scan a effectuer (champ Scantype).
4.7.3 Network groups
A laide des configurations des reseaux defini precedemment (section 4.7.2), il est possible a laide de ce
sous-menu de definir des groupes de reseaux ayant des caracteristiques communes.
4.7.4 Sensors
Ce sous-menu permet lajout et la configuration dun agent. Il sera ainsi possible de definir limportance
de celui-ci (champ asset).
4.7.5 Signatures
Ce sous-menu permet la creation de groupe de signatures Snort. Ceux-ci seront ensuite utilise par le
sous-menu Policy actuellement non disponible dans OSSIM pour cause de bug.
4.7.6 Ports
Ce sous-menu permet la creation de groupes de ports. Ceux-ci seront ensuite utilise par le sous-menu
Policy actuellement non disponible dans OSSIM pour cause de bug.
4.8 Correlation Menu
Ce menu offre trois differents sous-menus :

4.8.1 Directives
Ce sous-menu permet la visualisation des regles de correlation definies sur le serveur OSSIM. Celles-
ci sont appliquees de maniere temps reel aux alertes arrivant sur le serveur. Ces regles permettent la
creation dun diagramme detats definissant les alertes a matcher afin de lever une alerte de haut ni-
veau (groupe dalertes). Ce principe de fonctionnement est explique dans la section 2.3.3, paragraphe
Correlation par diagramme detats. Ces alertes de haut niveau seront ensuite stockees dans le sous-
menu Alerts du menu Control Panel. Etant donne que la quasi totalite dentre elles fournissent un niveau
de risque superieur a 2 (provenant de la configuration dune priorite souvent elevee dans les directives de
correlation), ces alertes de haut niveau seront mutees en alarmes et affichees dans le sous-menu Alarms
du menu Control Panel.
La configuration et letablissement des directives de correlation sont detailles dans lannexe I.
4.8.2 Cross Correlation
Ce procede permettra daugmenter la priorite dune alerte Snort lorsque lattaque definie par celle-ci aura
ete decouverte comme possible par Nessus. Les associations entre les alertes de Snort et les sid des regles
NASL14 de Nessus sont affichees dans ce sous-menu (affichage correspondant a la table plugin reference
de la base de donnee dOSSIM). Les differentes colonnes affichees on les significations suivantes :
Plugin id Identification du plugin qui va etre associe avec un script NASL Nessus. Il sagt, pour le
moment, uniquement du plugin Snort.
Plugin sid Identification de levenement du plugin (Plugin id) qui va etre associee avec un script NASL
Nessus. Il sagt, pour le moment, uniquement de regles Snort.
Reference id Identification du plugin de reference (Nessus en loccurence).
Reference sid Identification de levenement associe au plugin de reference (script NASL).
Ces informations representees normalement sous forme numerique sont simplement remplacees par leurs
definition textuelle contenue dans la base de donnee OSSIM.
Le script do nessus.pl execute lors dun scan Nessus (section 4.4.4) soccupe ensuite de remplir la table
host plugin sid repertoriant les sid Nessus pour lesquel chaque machine est vulnerable. Une fois ces
informations connues, le moteur de cross-correlation pourra rechercher pour chaque alerte recue, son
existance dans la table plugin reference. Si un tel evenement est repertorie dans cette table, le moteur de
correlation pourra en tirer le plugin sid de Nessus correspondant. Il pourra ensuite, rechercher dans la
table host plugin sid lexistance de ce sid de Nessus pour la machine cible de lalerte. Si un tel sid est
present, la priorite et la fiabilite (reliabiliy) de lalerte Snort seront modifies de la sorte :
Fiabilite Addition de la fiabilite de la regle Nessus matchee et de la regle Snort
Priorite La valeur maximale entre la priorite de la regle Nessus matchee et la regle Snort
14
Nessus Attack Scripting Language, language permettant detablir des regles de test Nessus

Lalerte sera ensuite automatiquement mutee en Alarme afin que celle-ci apparaisse dans le sous-menu
Alarms du menu Control Panel du framework.
4.8.3 Backlog
Ce sous-menu repertorie les paquetages de backlog des alarmes provenant dune directive de correlation.
En effet, lorsquune alarme est levee suite a laboutissement (complet ou partiel) dune directive de
correlation cela signifie que plusieurs alertes ont ete matchees par la directive. Le paquetage de lalarme
contient alors les references a ces alertes. Il sera ainsi possible, lors de la consultation des alarmes (sous-
menu Alarms du menu Control Panel), de cliquer sur le nom de lalarme resultant dune correlation afin
de pouvoir observer les alertes contenues dans les paquetages backlogs (cf. section 4.4.2).
4.9 Configuration Menu
Ce menu permet la configuration de certains parametres dOSSIM.
4.9.1 Main
Ce sous-menu offre une interface de configuration globale dOSSIM. En effet, le framework, les agents
et leurs plugins recupereront ces differentes informations. Ce sous-menu se decompose en plusieurs
sections :
Language Configuration de la langue du framework et des preferences daffichage locale dir.
Fonctionnalite pas encore implementee
Server Configuration des caracteristiques reseau du serveur (adresse IP et port).
Snort Configuration des caracteristiques propres a Snort (base de donnees, login et chemin dacces)
Metrics Configuration du seuil dalerte (threshold) lors dun depassement des metriques (algorithme
CALM), ainsi que du debit de sortie des alertes de laccumulateur CALM (recovery).
phpGACL Configuration de la base de donnee des regles ACL (Access Control List) permettant la
gesion des utilisateurs et dacces dOSSIM.
PHP Configuration des chemins des libraires php.
Le champ use svg graphics initialise a yes permet laffichage graphique du thermometre du sous-
menu Metrics du menu Control Panel. Celui-ci necessite linstallation dun plugin sur le navigateur
client (plugin SVG).
Le champ use resolv initialise a yes offre la resolution de noms pour les adresses IP affichees par
OSSIM.
RRD Configuration des chemis vers les librairies graphiques et scripts permettant la generation des
graphiques dOSSIM (Metrics, etc...)
Links Configuration du chemin web (URI) dOSSIM (ossim link) ainsi que celui de Ntop et Opennms.

Backup Configuration de la base de donnees de backup (fonctionnalite pas encore implementee, puisque
les backups sont sauvgardees dans des fichiers .sgl.gz)
Nessus Configuration du user/login utilise par le client Nessus pour effectuer les scans, ainsi que de
lhote hebergant le serveur Nessus. Mise en place du mot de passe Nessus effectue en section
A.3.3.
ACID Configuration du chemin (URI) vers ACID, ainsi que de la pair user/pass lors de lutilisation
HTTPS dACID. Configuration de la paire user/pass dOSSIM permettant la connexion a linter-
face Web du framework.
External applications Configuration des chemins complets vers les applicatifs utilises par le serveur
OSSIM. Le champ have scanmap3d permet lactivation ou non de laffichage 3D des alertes Snort
(explications en section 4.4.2)
4.9.2 Users
Ce sous-menu permet la creation de comptes utilisateurs pour linterface web dOSSIM. En effet, il est
possible de creer differents comptes ayant differents droits dacces. Il sera ainsi possible de definir pour
chaque utilisateur, les menu et sous-menu quil sera autorise de visualiser.
4.9.3 Plugins
Ce sous-menu offre laffichage de la liste des plugins offerts par OSSIM. Chaque evenement de chaque
plugin est indexe a laide dun sid (identifiant unique pour les evenements du plugin). Il sera ainsi pos-
sible de referencer chaque evenement a laide dune pair id/sid ou id est lidentifiant du plugin et sid
lidentifiant de levenement pour le plugin selectionne. Cette methode de referencement des evenements
permettra lutilisation de ceux-ci dans des directives de correlation. Plus dinformations sur leur utilisa-
tion dans les directives de correlation en section I.
4.9.4 RRD config
Ce sous-menu permet letablissement de profils RRD utilises par le plugin RRD des agents OSSIM. Le
principe de fonctionnement de ce plugin a ete aborde dans la section 3.3.1 lors de la presentation de
loutil danalyse Ntop. Ce plugin effectuera deux types danalyses sur chaque agent OSSIM :
1. Analyse heuristique : Utilisation dun algorithme de lissage exponentiel (Holt-Winter) pour la
prediction de valeurs (valeurs fournies par Ntop). Des explications detaillees sur lanalyse heuris-
tique Holt-winter est fournie en annexe J.
2. Detection de depassement de seuils : Comparaison des seuils configures avec les valeurs courantes
fournies par Ntop.
Les profils cree a laide de ce sous-menu pourront ensuite etre utilises dans les polices de securite des
machines et des reseaux definis a laide du framework. Il sera ainsi possible dappliquer le profile sou-

haite sur ces elements.
Les attributs representent les informations fournies par Ntop (compteurs de bytes, etc...). Sur chacun
deux, il est possible de definir des seuils (threshold) afin detre averti (generation dune alerte rrd threshold
affichee dans le sous-menu Alerts du menu Control Panel) lorsquun compteur depasse le seuil indique.
Les parametres alpha et beta sont quant a eux propres a lalgorithme heuristique Holt-winter. Les alertes
generees par cet algorithme (rrd anomaly) seront ensuite visibles dans le sous-menu Anomalies du menu
Report. Elles napparatront donc jamais dans le meme sous-menu que les alertes de types rrd threshold.
Parametres de configuration a disposition
Attribute Nom du parametre (compteur Ntop) pour lequel la ligne de configuration sapplique.
Threshold Seuil que lattribut devra atteindre pour quune alerte rrd threshold soit generee.
Priority Priorite de lalerte rrd threshold entrant de le calcul du risque effectue par le serveur lors de la
reception de lalerte (priorite non associee aux alertes de type rrd anomaly).
Alpha Parametre alpha de lalgorithme heuristique Holt-winter generant une alerte de type rrd anomaly.
Beta Parametre beta de lalgorithme heuristique Holt-winter generant une alerte de type rrd anomaly.
Persistence Nombre de fois quun depassement de seuil ou quune anomalie doit etre apercue pour
lattribut en question afin quune alerte rrd threshold ou rrd anomaly (suivant le cas) soit generee.
Enable Activation ou non de lattribut dans le profile.
Il est important de noter que le plugin RRD effectue periodiquement (chaque 300 secondes) lanalyse des
donnees fournies par Ntop (stockee dans la base de donnee tourniquet RRD). Le parametre persistence
se base donc sur cette granularite afin de decider de la generation dune alerte. En effet, si celui-ci est
configure a 3, il faudra que trois controles successifs des valeurs (anomalie et/ou seuil) soit superieur aux
valeurs autorisees afin quune alerte soit generee (alerte rrd anomaly et/ou rrd threshold). Cela signifiera
quun depassement aura ete observe durant au moins 15 minutes.
Configuration
Lunite des attributs (pour la configuration des seuils) nest malheureusement pas indiquee sur linterface
de configuration. Certains attributs sont exprimes de maniere relative alors que dautres de maniere ab-
solue (par exemple : bit/s et bit). Afin de connatre lunite utilisee par chaque attribut, il est preferable de
consulter leurs graphiques via Ntop. En effet, lunite est indiquee verticalement sur la gauche des graphs.
Les valeurs configurees pour les seuils sont utilisees pour des periodes de 5 minutes (par defaut). Par
exemple, cela signifie que si IPHTTPrcvdBytes vaut 8000, nous acceptons de recevoir 8ko du protocole

HTTP toutes les 5 minutes, donc en quelque sorte 8ko/5min.
La configuration des parametres propres a lalgorithme Holt-Winter sont expliques dans lannexe J.
Tous ces parametres permettent ladaptation de la detection de seuils et de lalgorithme heuristique Holt-
Winter en fonction du segment reseau a surveiller.
ATTENTION : OSSIM Version : 0.9.8rc2 contient des erreurs dimplementation sur lutilisation de
Holt-Winter par rrd plugin.pl ! !
4.9.5 Host scan
Ce sous-menu permet la visualisation des hotes a scaner a laide de Nessus ou Nmap.
4.10 Tools Menu
Ce menu offre trois differents sous-menus :
4.10.1 Net Scan
Ce sous-menu fait office dinterface avec le programme Open Source de scan reseaux nmap. Il permettra
ainsi de scanner lun des reseau definit dans le sous-menu Network du menu Policy ou dindiquer ma-
nuellement la plage dadresses a scanner.
Une fois le scan opere, il sera possible dinserer ou mettre automatiquement a jour la configuration (du
sous-menu Hosts du menu Policy) des machines detectees en cliquant sur le bouton update database
values.
4.10.2 Rule viewer
Ce sous-menu offre simplement une interface de consultation des regles Snort. En effet, il peut etre
interessant dobserver la syntaxe dune regle plutot que son nom. Pour lutilisation de cette fonctionna-
lite, il sera necessaire dinstaller (copier) la totalite des regles Snort dans le repertoire /etc/snort/rules/
du serveur OSSIM.
4.10.3 Backup
Ce sous-menu permet la gestion des backups des alertes. En effet, le script /etc/cron.daily/acid-backup.pl
place sur le serveur OSSIM archivera journalierement les vieilles alertes contenues dans ACID permat-
tant ainsi de limiter le temps de recherche des alertes dans la base de donnees. Ce sous-menu affichera
14
http ://www.insecure.org/nmap/

donc les fichiers de backup contenu dans le repertoire /var/lib/ossim/bakup/ du serveur et permettra de
reinserer des backups precedentes afin de retrouver des evenements deja archives. Inversement, il sera
aussi possible de retirer les donnees reinserees dans la base de donnees.

F IG . 4.1 Arborescence des menus dOSSIM

F IG . 4.2 Principe de daccumulation des alertes opere par CALM

Chapitre 5
Conclusion
OSSIM se revele etre une solution proposant des concepts danalyses tres innovateurs. En effet, peu de
solutions Open Source proposent actuellement une telle palette de procedes danalyse devenements de
securite :
Recuperation devenements dinfrastructures heterogenes (alertes de NIDS, logs, etc...).
Attribution dune severite a chaque evenement en fonction de lattention que lon porte au bien
potentiellement attaque (priorization des alertes).
Correlation croisee (Nessus - Snort) permettant la modification de la severite des alertes en fonc-
tion des vulnerabilites de la cible de lattaque potentielle.
Analyse comportementale du reseau permettant la generation dalertes en fonction du comporte-
ment des utilisateurs (Ntop et lalgoritme Holt-Winter de RRD).
Correlation des evenements et integration des evenements de lanalyse comportementale dans ce
procede.
Etant toujours en developpement, OSSIM reste malheureusement encore non utilisable dans un envi-
ronnement de production. En effet, son installation et les tests preliminaires semblent encore poser pas-
sablement de problemes. Les developpeurs dOSSIM ont principalement concentre leurs efforts sur les
procedes danalyse (encore inexistant sur des solutions Open Source). Leurs conceptes innovateurs re-
posent des lors sur des bases quelques peu instables et difficiles a faire co-exister.
En terme de concepts et de procedes danalyse, OSSIM na rien a envier aux solutions commerciales
denvergure comme :
ISS et leurs solutions SIM SiteProtector
(http ://www.iss.net/products services/enterprise protection/site protector/sec fusion module.php).
NetIQ et leur solution SIM SecurityManager (http ://www.netiq.com/products/sm/default.asp)
ExaProtect et leur solution EAS de management de la securite (http ://www.exaprotect.com/fr/eas-
1.jsp) jusqua peu, basee sur Prelude-ids une solution Open Source de grande qualite.
La solution Open Source Prelude-ids (http ://prelude-ids.org), etudiee et utilisee dans les deux premieres
phases du projet SIMS, offre quant a elle des fonctionnalites de detection (Snort et recuperation de
45
logs), centralisation et normalisation (IDMEF1 ) tres robustes. En effet, lequipe Prelude-ids a concentre
ses efforts sur le rapatriement devenements de securite avec la triade CIA (Confidentiality, Integrity,
Availability) comme ligne directrice. Ce projet de grande qualite noffre malheureusement encore aucune
solution avancee danalyse des donnees, bien que lintegration dun outil de correlation Open Source
(SEC, aborde dans le chapitre 7 du document http ://www.fullsecurity.ch/liens/sims-webJwinteregg.pdf)
soit en cours.
1
http ://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-16.txt

Annexe A
Installation et configuration
dOssim-server
Ce chapitre decrit toutes les etapes dinstallation dun serveur Ossim1 sur une plateforme GNU Li-
nux/Debian. Celui-ci est tire de http ://www.ossim.net/docs/INSTALL.Debian.quick.html
A.1 Prerequis
Disposer dune machine Linux Debian ayant un noyau 2.6.xx. Avoir configure le manager de paquets
Debian (aptitude) afin quil recupere ceux-ci sur le site Web dOssim (cf. Section B.1.1).
A.2 Installation
Installation de la base de donnee MySql-Ossim :
# apt-get install ossim-mysql
Creation du compte root et mise en place de son mot de passe :
# mysqladmin -u root password your_secret_password
Vous pouvez ensuite editer le fichier /etc/mysql/my.cnf afin de choisir ladresse IP (bind-address) associee
au serveur MySql.
La creation des bases de donnees sopere simplement a laide des commandes suivantes :
# mysql -u root -p
1
Serveur des gestion des sondes ET framework de gestion (= interface Web)
47
mysql> create database ossim;

mysql> create database ossim_acl;
mysql> create database snort;
mysql> exit;
Le chargement des tables peut ensuite seffectuer a laide des scriptes fourni par mysql-ossim :
# zcat /usr/share/doc/ossim-mysql/contrib/create_mysql.sql.gz \
/usr/share/doc/ossim-mysql/contrib/ossim_config.sql.gz \
/usr/share/doc/ossim-mysql/contrib/ossim_data.sql.gz \
/usr/share/doc/ossim-mysql/contrib/realsecure.sql.gz | \
mysql -u root ossim -p
# zcat /usr/share/doc/ossim-mysql/contrib/create_snort_tbls_mysql.sql.gz \
/usr/share/doc/ossim-mysql/contrib/create_acid_tbls_mysql.sql.gz \
| mysql -u root snort -p
Installation du serveur (daemon de correlation et recuperation des donnees des agents) :
# apt-get install ossim-server
Installation du framework (interface Web) ainsi que du paquetage de la gestion des droits dacces au
serveur Web :
# apt-get install phpgacl
# apt-get install ossim-framework
Installation du paquetage utils permettant la gestion des connexions a la base de donnee Ossim :
# apt-get install ossim-utils
Installation de Nessus (pour la detection des vulnerabilites). Installation du serveur Nessus :
# apt-get install nessusd
Il est aussi possible de directment telecharger la derniere archive dinstallation sur http ://www.nessus.org/download/.
En effet cette derniere version de Nessus (v.2.2.5) offre la possibilite de mettre a jour automatiquement les
regles Nessus via un simple enregistrement sur http ://www.nessus.org/. Vous devrez ensuite simplement
suivre les instructions donnees par le script dinstallation. A laide de linstallation par defaut, la racine du
serveur Nessus se trouvera alors dans /usr/local/. Ses fichiers de configuration dans /usr/local/etc/nessus
et les logs dans /usr/local/var/nessus.
Installation du client (utilise par le script /usr/share/ossim/script/do nessus.pl, execute par le framework
lors dune demande de scan) pour lexecution des scan nessus :
# apt-get install nessus

A.3 Configuration
A.3.1 Ossim plate-forme
Tous les paquetages intalles ci-dessus offrent une configuration garphique ncruses a linstallation. Celle-
ci peut etre effectuee a la demande via la commande :
# dpkg-reconfigure <nomDuPaquetage>
Ladresse IP du serveur ainsi que les nom dutilisateurs et mots de passes des bases de donnees seront
necessaire. Il convient donc ensuite de creer ces utilisateurs. Si nous choissons de nous connecter aux
bases de donnees a laide dun utilisateur nomme ossim ayant comme mot de pase ossim pass, il sera
necessaire doperer ainsi afin dajouter cet uilisateur sur les differentes bases de donnees :
# mysql -u root -p
mysql> GRANT ALL PRIVILEGES ON snort.* TO ossim@localhost

-> IDENTIFIED BY ossim_pass WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON ossim.* TO ossim@localhost

mysql> GRANT ALL PRIVILEGES ON ossim_acl.* TO ossim@localhost

mysql> FLUSH PRIVILEGES;
Ici, nous offrons tous les privileges a lutilisateur ossim sur les bases de donnees necessaires (soit ossim,
snort et ossim acl).
Pour une configuration graphique, il suffira dinstaller le paquetage suivant sur le serveur :
# apt-get install phpmyadmin
A.3.2 Serveur Web
Celle-ci se situe dans /etc/apache/httpd.conf. Il est en premier lieu indispensable de charger le module de
linterpreteur PHP afin que le site dOssim puisse fonctionner. Ceci sopere via la commande suivante :
# apache-modconf apache enable mod_php4
La configuration dOssim se situe dans /etc/apache/httpd.conf/conf.d/ qui est importe dans le fichier de
configuration principal dApache. Le fichier de configuration dApache pour Acid2 nest par contre pas
directement fourni dans ce repertoire. Il est donc necessaire de le copier afin quApache soit capable de
servir les pages web dAcid :
2
Viewer pour les alertes Snort et Ossim

# cp /etc/acidlab/apache.conf /etc/apache/conf.d/acid.conf
Il est ensuite necessaire de modifier la configuration par defaut dApache pour Ossim, afin que celui-ci
soit capable de suivre les liens symboliques. En effet, un lien symbolique est utilise pour laffichage
des vulnerabilites decouvertes a laide de Nessus. Il faut donc ajout loption suivante dans le fichier
/etc/apache/conf.d/ossim.conf (a la suite des options deja definies) :
Options FollowSymLinks
A.3.3 Nessus client-serveur
Il est necessaire dajouter un user au serveur Nessus afin le framework (script do nessus.pl) puisse luti-
liser pour executer des scans. Ceci sopere sur le serveur a laide de la commande nessus-adduser. Il
suffira ensuite de completer les informations requises comme illustre ci-dessous :
# nessus-adduser
Using /var/tmp as a temporary file holder
Add a new nessusd user

----------------------
Login : <yourUserLogin>
Authentication (pass/cert) [pass] :
Login password : <yourUserPass>
Login password (again) : <yourUserPass>
Il faudra maintenant configurer correctement les champs nessus user et nessus pass du sous-menu Main
du menu de Configuration du framework afin que les scripts utilisants Nessus soient capables de se
connecter au serveur Nessus. Le champ nessus user devra contenir yourUserLogin entre ci-dessus et
nessus pass devra contenir yourUserPass.
Il est maintenant possible de mettre a jour les regles de tests (contenues dans Nessus) sur le framework.
Le script update nessus ids.pl soccupe de ca (via lutilisation du client Nessus et des informations confi-
gurees ci-dessus) :
# /usr/share/ossim/scripts/update_nessus_ids.pl
A.3.4 Cross correlation via Nessus
Pour que lajustement des priorites des alertes en fonction des vulnerabilite de la machine cible (vulnerabilites
detectees par Nessus) soit possible, il est necessaire de mettre a jour les relations entre les alertes Snort et
les regles NASL3 Nessus (relations enregistrees dans la table plugin reference de Mysql). Ces relations
sont contenues dans larchive snort nessus.sql.gz quil faut fournir au client mysql afin que celui-ci mette
a jour la base de donnee dOssim :
3
Nessus Attack Scripting Language, language permettant detablir des regles de test Nessus

# zcat /usr/share/doc/ossim-mysql/contrib/snort_nessus.sql.gz | mysql -u root ossim -p

Annexe B
Ajout et configuration dune sonde Snort
Les manipulations decrites ci-dessous requierent un serveur Ossim operationnel (installation decrite dans
la section A).
B.1 Installation
B.1.1 Snort
Son installation sur une distribution Debian (via apt-get) implique lajout dune source de download afin
de recuperer lapplication Snort directement patchee. Il est necessaire dajouter la ligne suivant dans
/etc/apt/source.list afin que le gestionnaire de paquets de Debian (aptitude) soit capable de recuperer les
paquetages dOssim :
deb http://www.ossim.net/download/ debian/
Il est ensuite necessaire de creer un fichier de preferences /etc/apt/preferences afin que Debian aille en
premier lieu rechercher les paquetages disponibles sur Ossim plutot que ceux disponibles sur dautres
serveurs. Nous serons ainsi certain dobtenir la version patchee de Snort :
Package: *
Pin: release o=ossim
Pin-Priority: 995
Apres la mise a jour des paquetages disponibles, il est possible de downloader Snort :
# apt-get update
# apt-get install snort-mysql
Pour plus dinformations a ce sujet, consultez : http ://www.ossim.net/docs/INSTALL.Debian.html#d0e783
52
B.1.2 Ossim-agent
Maintenant quaptitude est capable de recuperer des paquets sur les serveurs dOSSIM, il suffit de taper
la commande suivante afin dinstaller Ossim-agent :
# apt-get install ossim-agent
Linstalleur de paquets de Debian va maintenant vous questionner afin de creer une configuration de
base. Reportez-vous a la section suivante (section B.2.2) pour plus de details.
B.2 Configuration
B.2.1 Snort
Comme mentionne plus haut, le logiciel de detection dintrusion Snort utilise son plugin de sortie Mysql
afin de transmettre directement ses alertes en direction dune des bases de donnees dOssim-server (Snort
BD). Celui-ci disposera alors de tous les details de chaque alertes levee par la sonde.
Le second plugin de sortie utilise est logfile=fast.log. Il sagt dun plugin developpe par OSSIM tres
proche de alert full1 directement integre a Snort. Fast.log place simplement les differentes alertes dans
un fichier de logs qui sera ensuite lu par lagent Ossim qui soccupera de transmettre ces informations
vers le serveur Ossim (permettant ainsi lanalyse temps reel).
La configuration des plugins de sorties de Snort ressemble donc a ceci (fichier : /etc/snort/snort.conf ) :
output database: alert, mysql, user=snort password=myPass

dbname=snort host=sgbdServerIP sensor_name=MonSensor logfile=fast.log
Les champs user, password, dbname et host correspondent aux informations relative a la base de donnee
Snort distante. Il est donc necessaire de creer un nouvel utilisateur sur celle-ci afin que la sonde puisse
sy connecter a laide du mot de passe indique. Lajout dun utilisateur sur la base de donnee Snort
sera detaille ci-dessous (section B.3). De plus, il est indispensable de retirer le script de demarrage
automatique de Snort afin que la sonde puisse etre directement activee par le Serveur (via Ossim-agent).
Ceci sopere a laide de la commande suivante :
# update-rc.d -f snort remove
Mise a jour des regles sur le serveur Ossim
La mise a jour des regles Snort permet lutilisation de celles-ci dans les scenarii de correlation. En
effet, le menu de Correlation - Directives du framework permet lutilisation des alertes Snort dans
1
fast.log ajout simplement deux parametres supplementaire a alert full afin daugmenter les performances du serveur. Info
sur : https ://sourceforge.net/forum/message.php ?msg id=2627915

la definition de scenarii de correlation. Lutilisation du SID des alarmes permet de les referencer dans
les regles de correlation. Celui-ci doit donc etre unique pour chaque plugin. Il convient donc lors de
creation de regles Snort de ne pas les dupliquer (un controle est quand meme effectue par le script
/usr/share/ossim/scripts/create sidmap.pl de mise a jour des regles dans la base de donnee du serveur
Ossim). La mise a jour des regles sur le serveur Ossim requiert le client Mysql puisque le script procede
au controle de la duplication des regles et fournit les commandes SQL a entrer dans le client. Ce script
doit evidemment etre execute sur lagent hebergeant la sonde Snort. Installation du client mysql :
# apt-get install mysql-client
Lancement du script de mise a jour a laide dun simple pipe vers le client mysql configure pour un
connexion vers la base de donnee du serveur Ossim (a ecrire sur une ligne) :
# /usr/share/ossim/scripts/create_sidmap.pl /etc/snort/rules | mysql

--host=<serverIP> -u ossim ossim -p
Le user ossim utilise pour la connexion du client mysql doit beneficier des droits suffisants pour la com-
mande Sql INSERT.
Pour que linsertion se passe correctement (avec lenregistremenent du champ msg des regles Snort dans
la base de donnee Ossim), il est necessaire que le champ classtype soit present dans la regle Snort.
Effacer des regles de plugins dans Ossim Pour se faire, il est necessaire de directement taper
dans la base de donnee dOssim. Il sera alors necessaire dutiliser un client Mysql (mysql-client ou
phpMyAdmin). Via mysql-client, il suffira de se connecter a la base de donnee a laide dun user ayant
les droits Delete, et de taper la requete suivante (avec le bon id et sid) :
mysql> DELETE FROM plugin_sid WHERE plugin_id=<id> and sid=<sid>;
B.2.2 Ossim-agent
Sa configuration seffecture directement a laide du menu de configuration des paquets Debian et peut
etre reconfigure a volonte a laide de la commande :
# dpkg-reconfigure ossim-agent
La configuration requiert (dans lordre dapparition) :

1. Ladresse IP de lagent
2. Linterface reseau a utiliser (pour la communication avec le serveur)
3. Ladresse IP du serveur OSSIM
4. Les plugins qui vont etre connecte a cet agent. Dans notre cas, uniquement Snort (illustre a la
figure B.1)
Lexecutable de lagent Ossim est ensuite directement lie dans les runlevels appropries afin quun demarrage
automatique seffectue a chaque boot de la machine.

F IG . B.1 Interface de configuration (dpkg) des plugins a utiliser sur un agent Ossim
B.3 Configuration dOssim-server pour une nouvelle sonde Snort
La procedure dajout dun nouveau sensor doit etre effectue via linterface Web du serveur Ossim. Celle-
ci est decrite dans le manuel disponnible a lURL suivante : http ://www.ossim.net/docs/User-Manual.pdf
Lors de lajout dun sensor local (agent place sur le serveur Ossim), il faudra bien prendre garde de
specifier correctement ladresse du serveur Ossim dans la configuration de lagent (/etc/ossim/agent/config.xml).
En effet, pour une bonne generation des liens HTML du framework, il sera necessaire de ne pas specifier
ladresse de loopback du serveur comme serverip.
<serverip>Adr_ip_non_loopback</serverip>
Lajout dune nouvelle sonde Snort implique lajout de droit dacces dans la base de donnee snort afin
que cette nouvelle sonde (=nouvel utilisateur) soit capable dy deposer directement ses alertes (comme
illustre sur la figure 3.1). Il est donc necessaire de se trouver sur la machine serveur afin dy entrer les
requetes SQL pour lajout dun utilisateur.
Lancement du client Mysql local et utilisation de la base de donnee snort :
# mysql -u root
mysql> use snort;
Requetes SQL a entrer pour lajout dun nouvel utilisateur et pour la mise en place de son mot de passe :
mysql> GRANT ALL ON snort.* TO snort@sensorIP;

mysql> UPDATE user SET Password = PASSWORD(passwordDeSnort@sensorIP)
-> WHERE Host = sensorIP AND User = snort;

Lutilisateur snort provenant de sensorIP a maintenant un acces total a la base de donnee snort du serveur.
Son mot de passe (a indiquer dans la configuration de Snort, section B.2.1) est maintenant passwordDeS-
nort.
B.4 Test de fonctionnement
Maintenant que lagent Ossim est configure et que la base de donnee snort est accessible depuis celui-ci,
nous pouvons tester le fonctionnement de lagent (le serveur doit etre en marche).
Il est maintenant possible de demarrer lagent Ossim (en mode de debug afin de controler son bon fonc-
tionnement) a laide de la commande suivante :
# ossim-agent -v -f
Les logs suivants doivent alors apparatre sur la console :
(->) pyossim.Agent (2005-04-27 11:38:04): Waiting for server...

(->) pyossim.Agent (2005-04-27 11:38:04): Waiting for server...
(<-) pyossim.Agent (2005-04-27 11:38:04): Server connected
(<-) pyossim.Agent (2005-04-27 11:38:04): Server connected
(=>) pyossim.Agent (2005-04-27 11:38:04): Apending plugins...

(--) pyossim.Watchdog (2005-04-27 11:38:04): monitor started
Starting Network Intrusion Detection System: snort(eth0)No /etc/snort/snort.eth0.conf,
(--) pyossim.ParserSnort (2005-04-27 11:38:04): plugin started (fast)...
.
(=>) pyossim.Agent (2005-04-27 11:38:05): plugin-start plugin_id="1001"
Vous pouvez maintenant executer lagent Ossim en tache de fond :
# ossim-agent -d
Votre nouvelle sonde Snort est prete a lemploi !
B.4.1 Erreur de demarrage de lagent Ossim
Il se peut que lerreur suivante apparaisse a la console :
[Errno 2] No such file or directory: /var/log/snort/alert
Celle-ci signifie que le fichier de log de Snort que recupere lagent (pour lenvoi temps reel des infor-
mations au serveur), na pas ete trouve. Il est alors necessaire de modifier la configuration du plugin

Snort afin dy indiquer le bon chemin (le bon fichier de log). Celle-ci est decrite dans le fichier XML
/etc/ossim/agent/plugins/snort.xml. Il est indispensable de modifier la balise location afin dy indiquer
lemplacement reel du fichier de log de Snort (genere par le plugin fast.log de Snort), comme illustre
ci-dessous :
<plugin id="1001" process="snort" type="detector" start="yes" enable="yes">

.......... balises de configuration ...........
<location>/var/log/snort/fast.log</location>
</plugin>

Annexe C
Ajout et configuration de Ntop
Les manipulations decrites ci-dessous requierent un serveur Ossim operationnel, ainsi quun agent Ossim
installe sur la machine qui hebergera Ntop (linstallation de lagent est decrite dans la section B.1.2
puisquil sagt, dans notre cas, du meme agent que pour la sonde Snort).
C.1 Installation
C.1.1 Ntop
Installation de Ntop et des librairies necessaires :
# apt-get install librrd0 ntop
Installation du paquetage ossim-utils fournissant le script danalyse des informations de Ntop

(/usr/share/ossim/scripts/rrd plugin.pl) ainsi que le fichier de configuration necessaire pour linterroga-
tion de la base de donnee Ossim par rrd plugin.pl (permettant la recuperation de la configuration des
seuils defini par ladministrateur reseau sur le framework) :
# apt-get install ossim-utils
Pour les details de la configuration de ce paquetage consultez la section C.2.2.

Installation des outils utilises par le script rrd plugin.pl pour la recuperation des informations dans la
base de donnee RRD :
# apt-get install rrdtool librrd0-dev librrdp-perl librrds-perl python-mysqldb
58
C.2 Configuration
C.2.1 Ntop
Configuration du mot de passe admin pour Ntop :
# ntop -u ntop
>> Please enter the password for the admin user:
#
Comme mentionne dans la section 3.3.1, Ntop dispose dune interface Web pour le monitoring ainsi que
pour sa configuration. Le serveur Web sinstalle par defaut sur le port 3000. Il est maintenant necessaire
de configurer le format des logs de sortie (plugin RRD) afin que le script rrd plugin.pl soit capable de les
recuperer via loutil RRDtool. Pour ce faire il suffit de se rendre a lURL suivante : http ://yourhost :3000/
et dactiver le rrdPlugin dans Admin - plugins. En cliquant sur rrdPlugin le menu de configuration de
celui-ci devient editable. Vous pouvez maintenant cliquer sur Host dans le menu Data to Dump puis
entrer votre masque de sous-reseau dans Hosts Filter. Il est encore necessaire de controler que le RRD
Files Path soit le meme que celui fournit dans le framework de configuration (Configuration - Main -
rrdpath ntop). En effet le script Perl rrd plugin.pl recupere la configuration des seuils sur le framework,
ainsi que les chemins dacces aux fichiers de logs.
Il est ensuite necessaire de modifier le fichier /etc/default/ntop afin dy mettre no-mac comme GE-
TOPT :
GETOPT="--no-mac"
Le script danalye et de comparaison des seuils (rrd plugin) sera maintenant capable de recuperer les
donnees de la base de donnee tourniquet afin de les analyser.
C.2.2 Lagent Ossim
Ossim-utils
Ce paquetage contenant le script rrd plugin.pl met a disposition le module perl /usr/lib/perl5/config.pm
permettant de recuperer la configuration etablie dans le framework (configuration etablie dans Configu-
ration - Main). Il est necessaire de configurer correctement ce paquetage afin que ce module soit capable
de se connecter a la base de donnee distante. Il faudra lui indiquer un utilisateur Mysql, capable de se
connecter depuis lagent Ossim. Dans notre cas, nous indiquerons lutilisateur snort precedemment confi-
gure (cf. section B.3). Editee a la main (/etc/ossim/framework/ossim.conf) cette configuration ressemble
a ceci :
################
# OSSIM db configuration
################

ossim_type=mysql
ossim_base=ossim
ossim_user=snort
ossim_pass=E1ephant
ossim_host=10.192.72.172
ossim_port=3306
Celle-ci peut aussi etre aisement editee a laide de dpkg via la commande suivante :
# dpkg-reconfigure ossim-utils
Ossim-agent
Le script rrd plugin.pl recupere de lui meme (sans appel a config.pm) les informations relatives a la
configuration des seuils dans la base de donnee Ossim distante. Il est donc necessaire de lui indiquer
correctement les memes informations que ci-dessus. Celles-ci sont visibles comme variables globales
dans la configuration de lagent (/etc/ossim/agent/config.xml) et sont ensuite utilisees par certains plugins
(dont le plugin RRD). La definition de lENTITY suivant avec les bon parametres de connexion est
necessaire :
<!ENTITY ossim_db "mysql:10.192.72.172:ossim:snort:E1ephant" >
Il faut ensuite reconfiguer lagent Ossim afin de preciser que Ntop est active sur cet agent. Etant donne
que rrd plugin.pl est utilise pour lanalyse des donnees, il est necessaire dindiquer que le plugin RRD
est aussi en fonction. La figure C.1 illustre cette nouvelle configuration executee a laide de la commande
suivante :
F IG . C.1 Interface de configuration (dpkg) des plugins a activer sur lagent Ossim

C.3 Configuration dOssim-server pour une nouvelle sonde Ntop
Si lajout de cette sonde a ete effectuee sur un sensor existant (comme dans notre cas), il ne sera pas
necessaire denregistrer un nouvel agent sur linterface Web du serveur. Lagent existant transmettra de
lui meme lexistance dune nouvelle sonde au serveur. Dans le cas contraire (mise en place de cette sonde
sur un nouvel agent), il sera necessaire de proceder a lenregistrement du nouvel agent, comme explique
dans le manuel disponnible a lURL suivante : http ://www.ossim.net/docs/User-Manual.pdf
Il est aussi indispensable dajouter les droits suffisants a lutilisateur utilise lors de la connexion a la base
de donnee, afin que celui-ci soit capable de recuperer la configuration sur le serveur :
# mysql -u root
mysql> use ossim;
Requetes SQL a entrer pour lajout dun nouvel utilisateur et pour la mise en place de son mot de passe :
mysql> GRANT ALL ON ossim.* TO snort@sensorIP;

mysql> UPDATE user SET Password = PASSWORD(passwordDeSnort@sensorIP)
-> WHERE Host = sensorIP AND User = snort;
Ceci peut aussi etre effectue via phpMyAdmin.

Annexe D
Ajout et configuration de P0f
la section A), ainsi quun agent Ossim installe sur la machine qui hebergera P0f (linstallation de lagent
est decrite dans la section B.1.2 puisquil sagt, dans notre cas, du meme agent que pour la sonde Snort).
D.1 Installation
Son installation necessite uniquement linstallation du paquetage P0f :
# apt-get install p0f
D.2 Configuration
D.2.1 P0f
P0f ne necessite aucune configuration supplementaire puisque le chemin de son fichier de log lui est
fourni par lagent Ossim lors de son execution.
D.2.2 Lagent Ossim
Il est necessaire de reconfiguer lagent Ossim afin de preciser que P0f est active sur cet agent. Celle-ci
sopere a laide de la commande suivante :
62
Annexe E
Ajout et configuration de TCPTrack
la section A), ainsi quun agent Ossim installe sur la machine qui hebergera TCPTrack (linstallation de
lagent est decrite dans la section B.1.2 puisquil sagt, dans notre cas, du meme agent que pour la sonde
Snort).
E.1 Installation
Celle-ci est vraiment tres simple puisquil suffira de recuperer le paquetage Debian de TCPTrack sur le
serveur Web dOssim1 via la commande suivante :
# apt-get install tcptrack
E.2 Configuration
Aucune configuration specifique nest necessaire pour TCPTrack puisque cest le serveur Ossim qui
soccupera dinteroger TCPTrack. Il sera par contre indispensable dindiquer a lagent quune nouvelle
sonde lui a ete ajoutee. Ceci soperera via le menu de configuration offert par la commande suivante :
1
Il est donc indispensable davoir configure aptitude afin quil recupere directement les paquetages chez Ossim (cf. Section
B.1.1). En effet, la version de TCPTrack utilisee dans larchitecture dOssim est une version modifiee de la version originale.
63
Annexe F
Ajout et configuration dune sonde HIDS

Syslog
la section A), ainsi quun agent Ossim installe sur la machine qui hebergera cette sonde HIDS Syslog
(linstallation de lagent est decrite dans la section B.1.2 puisquil sagt, dans notre cas, du meme agent
que pour la sonde Snort).
F.1 Installation
Aucune installation nest requise puisque le parser de fichiers de log Syslog et directement present sur
tous les agents (fichier /usr/share/ossim-agent/pyossim/ParserSyslog.py).
F.2 Configuration
Il suffira dactiver le plugin voulu afin que celui-ci soit automatiquement execute par lagent. Pour ce
faire, il vous suffira de lactiver a laide du menu de configuration offert par la commande suivante :
La configuration du fichier a controler peut etre directement faite en modifiant la balise location du fi-
chier /etc/ossim/agent/plugins/syslog.xml. Par defaut celui-ci est /var/log/auth.log.
Sous Debian il sera en plus necessaire de modifier (dans le meme fichier de configuration) le nom du
daemon de logging puisque celui-ci se nomme sysklogd et non pas syslog.
Lajout de nouvelles regles necessitera malheureusement la modification du code du parseur /usr/share/ossim-

agent/pyossim/ParserSyslog.py puisque celles-ci sy trouvent directement integrees. Aucun fichier de
configuration des regles nest pour le moment disponnible.
64
Annexe G
Ajout et configuration dune sonde HIDS

IIS
la section A), ainsi quun agent Ossim installe sur la machine qui hebergera cette sonde HIDS IIS1
(linstallation de lagent est decrite dans la section B.1.2 puisquil sagt, dans notre cas, du meme agent
que pour la sonde Snort).
G.1 Installation du plugin
Aucune installation nest requise puisque le parser de fichiers de log est directement present sur tous les
agents (fichier /usr/share/ossim-agent/pyossim/ParserIIS.py).
G.2 Installation de Snare IIS (rapatriement des logs vers un serveur Sys-
log)
Du cote du serveur web, il est necessaire dinstaller un logiciel client capable demettre les logs vers un
serveur de logs Linux. Vous pouvez donc telecharger librement le logiciel Open Source Snare disponible
a ladresse suivante : http ://www.intersectalliance.com/projects/SnareIIS/index.html#Download
Son installation est ensuite extrement simple. Il vous suffira de suivre les quelques instructions a lecran...
1
Internet Information Services, serveur Web de Microsoft
65
G.3 Configuration
G.3.1 Configuration de lagent OSSIM
Il suffira dactiver le plugin voulu afin que celui-ci soit automatiquement execute par lagent. Pour ce
faire, vous devrez lactiver a laide du menu de configuration offert par la commande suivante :
La configuration du fichier de log a controler peut etre directement faite en modifiant la balise location
du fichier /etc/ossim/agent/plugins/iis.xml. Par defaut celui-ci est /var/log/syslog.
Sous Debian il sera en plus necessaire de modifier (dans le meme fichier de configuration) le nom du
daemon de logging puisque celui-ci se nomme sysklogd et non pas syslog.
Lajout de nouvelles regles necessitera malheureusement la modification du code du parseur /usr/share/ossim-

agent/pyossim/ParserIIS.py puisque celles-ci sy trouvent directement integrees. Aucun fichier de confi-
guration des regles nest pour le moment disponible.
Configuration du serveur Syslog Linux (present sur lagent OSSIM)
Syslogd est le daemon soccupant de la recuperation de logs dune machine Linux. Par defaut celui-ci
travaille uniquement en local. Lors de son lancement (commande syslogd), via largument -r, il est
possible de lui indiquer douvrir le port 514 UDP pour la recuperation de logs distants. Nous modifions
donc son script de lancement sysklogd place dans /etc/ini.d/. Il suffira donc dajouter le -r dans la
variable SYSLOGD deja presente dans ce fichier, comme illustre ci-dessous :
# Options for start/restart the daemons

# For remote UDP logging use SYSLOGD="-r"
SYSLOGD="-r"
Nous pouvons ensuite relancer le daemon qui attendra maintenant des messages syslog sur le port 514 :
jo:/etc/init.d# ./sysklogd restart
Il est important de preciser que le protocole de transfert de logs base sur UDP nest pas securise. Les
trames circulent en clair sur le reseau. De plus lutilisation dUDP implique une eventuelle possibilite
de perte des paquets sans quaucun des deux partenaires ne sen rende compte (principe meme dUDP).
G.3.2 Configuration du serveur IIS (client Snare IIS)
La figure G.1 illustre la configuration du client Snare effectuee, afin que la station 192.168.1.2 recoive
les logs contenu dans le fichier C :\WINNT\System32\LogFiles du serveur IIS.
Lutilisation de Snare implique une configuration rigoureuse du format des logs dIIS. En effet, il est
indispensable de configurer une rotation des logs journaliere ainsi quun format etendu (W3C extended

F IG . G.1 Configuration de lutilitaire de recuperation des logs dIIS
Log File Format) afin que Snare soit capable de les lire. Cette configuration est accessible dans le menu
de configuration de IIS, dans longlet Web Site. En cliquant sur le bouton Properties..., il sera possible
de definir la periode de rotation des logs ainsi que leur format.
De plus, le parser IIS dOSSIM (/etc/ossim/agent/plugins/iis.xml) necessite un format de log tres precis
afin detre capable de les interpreter. Il sera donc necessaire de configurer les logs dIIS afin que les
informations suivantes soient presentent :
Heure
Date
Client IP
Server IP
Server port
Method
URI stream
URI query
Protocol Status

Annexe H
Ajout et configuration de PADS
la section A), ainsi quun agent Ossim installe sur la machine qui hebergera PADS (linstallation de
lagent est decrite dans la section B.1.2 puisquil sagt, dans notre cas, du meme agent que pour la sonde
Snort).
H.1 Installation
Celle-ci est vraiment tres simple puisquil suffira de recuperer le paquetage Debian de PADS, via la
commande suivante :
# apt-get install pads
H.2 Configuration
Aucune configuration specifique nest necessaire pour PADS puisque le chemin de ses logs de sortie est
directement fourni par lagent Ossim (parametre lors de son execution). Il sera par contre indispensable
dindiquer a lagent quune nouvelle sonde lui a ete ajoutee. Ceci soperera via le menu de configuration
offert par la commande suivante :
68
Annexe I
Creation de regles de correlation
I.1 Introduction
Cette annexe vous apprendra a creer vos propres directives de correlation. La structure et syntaxe de
celles-ci est decrite dans ce chapitre.
I.2 Ajout dun fichier de regles sur le serveur
Pour ce faire, il suffit de creer un nouveau fichier de regles sur le serveur et de le placer dans le repertoire
/etc/ossim/server/. Si celui-ci se nomme mesRegles.xml, il sera indispensable dindiquer au serveur de
charger ce fichier afin que les regles presentent dans celui-ci soient utilisees. Pour se faire, il vous suffit
dediter le fichier /etc/ossim/server/directives.xml afin dy ajouter la configuration suivante :
SYSTEM /etc/ossim/server/directives.dtd
[
... inclusion des fichieres existants ....
<!ENTITY myRules SYSTEM /etc/ossim/server/mesRegles.xml>
]>
<directives>
... inclusion des regles existantes a laffichage ...

&myRules;
..... suite de la config ....
</directives>
Chaque regle sera ensuite automatiquement triee lors de son affichage dans le framework. Lors de la
creation de regles, iI sera indispensable de respecter la numerotation de lattribut id des balises direc-
69
tives mentionne dans Directive numbering du sous-menu Directives du framework. De cette maniere, les
nouvelles regles seront directement affichees dans la categorie voulue.
I.3 Syntaxe XML
Cette section est partiellement tiree du document de Sebastien Contreras et des exemples fourni aux
URLs suivantes :
http ://www.ossim.net/docs/correlation engine explained rpc dcom example.pdf
http ://www.ossim.net/docs/correlation engine explained worm example.pdf
Nous allons, en premier lieu, reprendre la definition des differentes balises utilisables dans les regles de
correlation :
I.3.1 Balise directive
Cette balise englobe la directive de correlation entiere. Elle permettra de definir les parametres globaux
de celle-ci. Ceux-ci sont :
lid de la directive de correlation, attribut id
le nom de celle-ci affiche dans le framework, attribut name
la priorite de la regle, attribut priority
I.3.2 Balise rule
Cette balise permet la definition dune regle utilisee dans le processus de correlation de la directive. Il
sera possible den definir ses caracteristiques a laide des attributs suivants :
Le type de la regle, attribut type
Le nom de celle-ci, attribut name
La provenance de lalerte que nous attendons, attribut plugin id
Le numero devenement1 de lalerte du plugin que nous attendons, attribut plugin sid
Le parametre de fiabitite (reliability) entrant dans le calcul du risque, attribut reliability
La fenetre temporelle dans laquelle la regle doit etre matchee, attribut time out
Le nombre de fois que doit etre matche la regle afin de passer a la suivante, attribut occurence
Le type de protocole sur lequel sapplique la regle, attribut protocol
Ladresse IP source de la trame matchee par la regle, attribut from
Ladresse IP de destination de la trame matchee par la regle, attribut to
1
Reference chaque plugin offerte par le sous menu Plugins du menu Configuration

Le port source de la trame matchee par la regle, attribut port from

Le port de destination de la trame matchee par la regle, attribut port to
La condition a appliquer si le controle dune quantite vehiculee par lalerte est necessaire, attribut
condition
La valeur a comparer (a laide de la condition definie par lattribut precedent) a la quantite vehiculee
par lalerte, attribut value
Valeur permettant de definir si la valeur a comparer (value) est absolue ou relative, attribut absolute
Linterval dans lequel la regle doit sappliquer (equivalent au time out mais utilise pour les regles
monitor), attribut interval
Parametre permettant de geler les parametres non defini2 dans la directive (utilise lorsque loccu-
rence dune regle est superieur a 1), attribut sticky
Parametre permettant de forcer un attribut a etre different lorsque plusieurs occurence de la regle
sont attendues, attribut sticky different
Lorsquune regle (rule) est matchee, cela a pour effet de declencher le passage a la regle suivante conte-
nue dans la directive. Il sagit donc dun ET entre les regles impriquees dans rule.
I.3.3 Balise rules
Cette balise permet lencapsualtion dune ou plusieurs regles (balise rule). Si plusieur regles rule sont
presentes au meme niveau (sans imbrications) a lintereur de la balise rules, un OU est opere entre
celles-ci (exemple : la 1ere regle ou la deuxieme regle ou la 3 eme regle... ). Cette balise ne contient
aucun attribut.
I.3.4 Syntaxe des attributs de caracteristiques
Nous allons maintenant reprendre la definition des attributs utilisables (parametres) dans les differentes
balises XML.
balise directive
id Cet attribut permet la definition de lidentifiant unique de la directive de correlation. Cette numerotation
doit suivre les directives emises par Ossim afin que le tri daffichage effectue dans le framework (sous-
menu directives du menu correlation) soit effectue correctement. Les directives de numerotation sont
disponible dans ce sous-menu.
name Cet attribut permet la definition du nom de la directive (affiche lorsque la directive est matchee).
2
parametres non utilise dans la directive

priority Cet attribut permet de definir la priorite de la directive de correlation. Pour plus dinformations
sur la signification de la priorite dun evenement, conslutez la section 4.3.
balise rule
Type Cet attribut definit le type de la regle. Il existe uniquement deux type de regles :
Detector regles utilisant les informations de detecteurs (snort, spade, syslog, ...) contenue dans la base
de donnee du serveur.
Monitor regles utilisant les information des moniteurs (TcpTrack, Ntop, etc...). Dans ce cas, cest le
serveur qui aura la tache dinterroger le moniteur (agent) afin dobtenir les informations voulues.
name Cet attribut permet de definir le nom de chaque regle. Celui-ci sera ensuite affiche dans le sous-
menu backlog du menu correlation, permettant la visualisation des regles matchees par alertes de haut
niveau (groupe dalertes).
plugin id Cet attribut definit la provenance de lalerte attendue par la regle. En effet, chaque plugin a
un identifiant associe (identifiant affiche dans le sous-menu plugins du menu configuration) permettant
de le referencer dans les regles de correlation.
plugin sid Cet attribut definit levenement associe au plugin (plugin id). En effet, tous les evenement
recupere par Ossim sont repertorie (en fonction de leur plugin) et configure3 . La configuration des plu-
gin sid est accessible en cliquant sur le plugin id voulu dans le sous-menu plugins du menu configura-
tion. Par exemple, lalerte fournie par le plugin id 1501 et le plugin sid 400 equivaut a : apache : Bad
Request. A laide de ces deux attributs (plugin id et plugin sid), il est possible de definir precisement
levenement attendu par la regle.
reliability Lutilite de cet attribut est explique dans la section 4.3. Plus ce parametre est grand (proche
de 10), plus il indique que lalerte nest pas un faut positif. Ce parametre prend alors une grand im-
portance dans le procede de correlation. En effet, au fur et a mesure que des regles sont matchees, la
probabilite que ce groupe dalerte (alerte de haut niveau) est un faux positif diminue... Il est alors pos-
sible, dans chaque balise rule, de modifier la fiabilite de lalerte de haut niveau. La premiere regle (rule)
indique la reliabilite de depart de lalerte de haut niveau. Les regles suivantes ont ensuite la possibilite
de faire evoluer cette valeur de maniere relative (par exemple : +3, signifiant que la reliabilite globale
augmente de 3 par rapport a la regle precedente) ou absolue (par exemple : 7, signifiant que maintenant
la reliabilite vaut 7).
3
Afin de leur assigner un niveau de priorite et de reliability (termes expliques dans la section 4.3)

time out Cet attribut permet dindiquer le temps dattente de levenement correspondant a la regle. Si
celui-ci narrive pas dans le temps imparti (configure en secondes a laide de cet attribut), la directive
de correlation se termine et retourne le resultat calcule des regles precedentes. Cet attribut permet de
preciser la fenetre temporelle dans laquelle lalerte (evenement) attendue par la regle doit apparatre.
occurence Cet attribut permet de creer une unique regle lorsque plusieurs occurence dun meme
evenement est attendu. Il est ainsi possible de definir le nombre devenements identique a attendre avant
de passer a la regle suivante.
protocol Cet attribut permet de configurer le type devenements reseau attendu par la regle. Il est
possible den definir trois types :
1. TCP
2. UDP
3. ICMP
Cet attribut permet le referencement absolu. Cela signifie quil est possible de reprendre le type de
protocole matche par des regles precedentes. Pour ce faire, il suffira par exemple dindiquer : proto-
col=1 :PROTOCOL afin de preciser que le protocole de cette regle est identique au protocole matche
par la regle de premier niveau (premiere regle). Si lon desire recuperer le protocole matche par la regle
du deuxieme niveau, il suffira de preciser protocol=2 :PROTOCOL.
Cet attribut devra uniquement etre utilise lorsque levenement attendu par la regle fait partie de lun des
trois type de protocole disponible.
from Cet attribut permet de preciser ladresse IP source de lalerte attendue. Il est possible de la men-
tionner de six differentes manieres :
1. ANY, indique que nimporte quelle adresse source sera matchee par cet attribut
2. x.x.x.x, adresse IP standard
3. Par referencement, fonctionnant sur le meme principe que le referencement de lattribut protocole
(exemple : 1 :SRC IP = adresse IP source de lalerte matchee par le premier niveau de la directive
de correlation, 2 :DST IP = adresse IP de destinaion de lalerte matchee par le deuxieme niveau
de la directive de correlation)
4. Par nom du reseau, il est possible dutiliser une plage dadresse IP en utilisant les nom de reseaux
defini a laide du framework (sous-menu network du menu policy). La variable HOME NET definit
quant a elle tous les reseaux defini dans le framework.
5. Plusieurs adresses, cette syntaxe permet de preciser plusieurs adresses IP separees par des virgules
6. Negations, cette syntaxe permet lutilisation de negations sur des adresses IP ou des nom de
reseaux (exemple : !192.168.2.203,HOME NET)

Note sur la premiere syntaxe (ANY) : Il est evident quau niveau de la regle utilisant cette syntaxe cela
revient au meme que de ne pas utiliser cet attribut. Cette syntaxe permettra, par contre, le referencement
(a laide de la troisieme syntaxe) de ladresse IP de cette alerte dans les regles suivantes.
Cet attribut ne devra pas etre utilise lorsque linformation attendue par la regle nest pas une trame IP.
to Cet attribut permet de preciser ladresse IP de destination de levenement attendu par la regle. Sa
syntaxe est totalement identique a celle de lattribut from.
Cet attribut ne devra pas etre utilise lorsque linformation attendue par la regle nest pas une trame IP.
port from Cet attribut permet de preciser le port source du segment TCP ou datagramme UDP attendu
par la regle. Celui-ci peut etre decrit par :
Une liste de ports separe par des virgules
ANY
Un referencement absolu a laide des variables SRC PORT et DST PORT
Cet attribut ne devra pas etre utilise lorsque linformation attendue par la regle nest pas un segment TCP
ou un datagramme UDP.
port to Cet attribut permet de preciser le port de destination du segment TCP ou datagramme UDP
attendu par la regle. La syntaxe de celui-ci est identique a celle de lattribut port from.
Cet attribut ne devra pas etre utilise lorsque linformation attendue par la regle nest pas un segment TCP
ou un datagramme UDP.
condition Cet attribut permet de definir le type de condition applique entre la quantite vehiculee a
laides des regles de type monitor et lattribut value. Le type des quantites vehiculees par les monitor
sont definies par le plugin sid du plugin id. Les valeurs de la condition peuvent etre les suivantes :
1. eq - egal
2. ne - non egal
3. it - plus petit que
4. gt - plus grand que
5. le - plus petit ou egal
6. ge - plus grand ou egal
value Cet attribut est simplement la valeur numerique a comparer avec la quantite vehiculee par lalerte
dun moniteur.

absolute Cet attribut permet dindiquer si la valeur a comparer (value) a la quantite vehiculee par le
monitor est absolue ou relative a la fenetre temporelle dapplication . Cet attribut prend donc les valeurs
true ou false.
Absolute=true Indique que la valeur (value) doit etre atteinte afin que la condition soit matchee
Absolute=false Indique que la valeur vehiculee par le plugin sid du plugin id doit etre incrementee
de value durant la fenetre temporelle dapplication de la regle afin que la condition soit matchee.
interval Cet attribut est similaire a lattribut time out, mais il sapplique uniquement aux temps de
comparaisons entre les quantites vehiculees par le plugin sid du plugin id et lattribut value. Il permet
ainsi de definir la fenetre temporelle utilisee par lattribut absolute.
sticky Cet attribut permettra, lors de lattente de plusieurs occurence dune meme regle (attribut occu-
rence plus grand que 1), de geler les parametres non definis dans celle-ci. Sans cette possibilite, differents
evenements non identiques pourraient etre matches comme occurence dune meme regle. En effet, les pa-
rametres non defini dans une regle sont equivalents a ANY, provoquant ainsi la validation de levenement
(matching), meme si celui-ci nest pas exactement le meme (parametre non defini differents).
Lorsque cet attribut est configure a true (sticky=true), les caracteristiques non defini des evenements
devront etre strictement les meme que ceux de la premiere occurence afin que levenement soit matche
a nouveau.
sticky different Cet attribut permet linverse de lattribut sticky et doit etre utilise conjointement avec
celui-ci. En effet, pour la detection de scan de ports, il serait interessant de detecter des evenements
identique ayant uniquement leur port de destination different. Il est ainsi possible de definir lattribut
devant etre different a chaque occurence de la regle. Sticky different pourra ainsi prendre les valeurs
suivantes :
SRC PORT
DST PORT
SRC IP
DST IP
PROTOCOL
Ces parametres pourront aussi utiliser le referencement absolu aborde dans les explications de lattribut
protocol.
I.4 Structures des directives de correlation
I.4.1 Exemple de structure des directives
Lexemple ci-dessous illustre le fonctionnement des regles de correlation :

<directive MyDirective>
<rule INTRO .. parametres .. >
<rules>
<rule A .. parametres .. >
<rules>
<rule C .. parametres .. />
</rules>
</rule A>
<rule B .. parametres .. />
</rules>
</rule INTRO>
</directive>
La regle rule INTRO est la regle declencheuse de la directive de correlation. Une fois celle-ci matchee,
le moteur de correlation attend lapparition de levenement rule A ou rule B avant de continuer (car les
regles A et B sont encapsulees au meme niveau dans une balise rules). Si rule A apparat, le moteur de
correlation attend lapparition de rule C pour finir son travail sur cette directive. Si par contre rule B
apparat a la place de rule A, la correlation est terminee et une alerte de haut niveau est generee.
Lexemple suivant illustre le fonctionnement de regles successives :
<directive MyDirective>
<rule INTRO .. parametres .. >
<rules>
<rule A .. parametres .. >
<rules>
<rule B .. parametres .. >
<rules>
<rule C .. parametres .. />
</rules>
</rule B>
</rules>
</rule A>
</rules>
</rule INTRO>
</directive>
La regle rule INTRO est la regle declencheuse de la directive de correlation. Une fois celle-ci matchee, le
moteur de correlation attend lapparition de levenement rule A avant de continuer (passer a la regle sui-
vante). Lorsquun tel evenement apparat, le moteur de correlation attendra lapparition de levenement
suivant permettant le passage a ruleB et ainsi de suite.
Nous remarquons que les OU logiques entre les regles (balise rule) sont construit a laide de regles de
meme niveau a linterieur dune balise rules. Les ET logiques entre regles sont quant a eux simplement

construit par imbriquation de regles (balise rule). De plus, nous remarquons que les balises rules encap-
sulent obligatoirement les regles (balise rule), meme si une unique regle est presente.
I.4.2 Structure de correlation realisable
La figure I.1, illustre un schema de correlation non realisable a laide de la syntaxe XML dOSSIM.
En effet, la syntaxe arborescente des regles empeche le passage de differents etats sur un etat commun
(les etats 2 et 3 de la figure I.1 peuvent passer sur un meme etat etat 4). Pour quune telle structure
soit realisable a laide dOSSIM, il sera indispensable de la decomposer en arbre. Pour ce faire, il serait
necessaire de dupliquer certains etats (donc certaines regles) afin quune regle aboutisse toujours sur
un/des etats fils et non sur des etats cousins.
F IG . I.1 Schema de correlation non realisable a laide dOSSIM
La figure I.2, illustre le schema typique dun scenario de correlation dOSSIM. En effet, chaque regle
mene a ses propres sous-regles. Il ny a pas de saut entre des etats adjacents.

F IG . I.2 Schema de correlation realisable a laide dOSSIM

Annexe J
Analyse heuristique - (algorithme

Holt-winter)
Les explications propres a la recuperation des donnees sont tirees du document suivant :
http ://www.mirrors.wiretapped.net/security/network-monitoring/ntop/rrdandntop.pdf
J.1 Recuperation des donnees
Comme mentionne en section 3.3.1 Ntop fournit les statistiques reseaux necessaires a lanalyse heuris-
tique (ainsi qua lanalyse de detection de seuils). Ces donnees sont stockees dans des bases de donnees
tourniquets illustrees par la figure J.1.
F IG . J.1 Illustration dune base de donnee tourniquet
Une fois le tourniquet plein, les anciennes donnees seront petit a petit remplacees par de nouvelles.
79
A chaque periode dechantillonage, le plugin RRD1 de Ntop interrogera les differents compteurs de bytes
fourni par celui-ci. Il enregistrera ensuite ces valeurs dans la base de donnees tourniquet correspondante.
Celles-ci seront ensuite interrogees (a laide de RRDtool) par lagent OSSIM via le plugin RRD2 afin
dy controler les seuils et les depassement de lalgorithme heuristique configure a laide du framework
(section 4.9.4). Laffichage des informations de Ntop3 utilisera les memes bases de donnees afin de pro-
duire ses graphiques et statistiques.
Il est donc important de comprendre limpacte de la configuration du plugin RRD de Ntop (plugin natif a
Ntop) sur la periode dechantillonage et la quantite dinformations (nombre dechantillons) collectee par
les bases de donnees tourniquets. Chaque compteur dinformation reseau fourni par Ntop (IP DNSBytes,
IP HTTPBytes, etc...) impliquera la creation de 3 bases de donnees tourniquet. Ces trois differentes bases
de donnees tourniquet sont necessaires afin de permettre lenregistrement dau moins 1 annee de statis-
tiques sans pour autant disposer dune gigantesque base de donnees.
Si une unique base de donnees tourniquet etait utilisee afin de stocker 1 an dechantillons et que la
periode dechantillonnage est de 5 minutes (300 secondes), il faudrait exactement :
nbJours nbHeures/jour nbM inutes/heure nbSecondes/min 365 24 60 60

= = 30 1530 600Slots
periodeEchantillonage[sec] 300
(J.1)
Afin de reduire la taille des bases de donnees tourniquet, des moyennes sont effectuees sur les echantillons
qui sont ensuite enregistre dans deux bases de donnees tourniquets annexes permettant le stockage de
plus dune annee de statistiques moyennes sans pour autant disposer de plus de 3mios de Slots.
J.1.1 Configuration du plugin RRD de Ntop
Celle-ci sopere a laide de linterface Web offerte par la sonde Ntop (port 3000 de la sonde). Le sous-
menu Plugins du menu Admin permet la configuration du plugin RRD de Ntop.
Les quatre premiers parametres permettent la definition de la taille des 3 bases de donnees tourniquet
(chaque compteur Ntop utilisera trois base de donnees tourniquet) ainsi que la periode dechantillonnage
utilisee par le plugin :
Dump Interval Indique la periode dechantillonage en secondes. Cest a dire quun nouveau slot du
tourniquet sera rempli toutes les N secondes. Valeur par defaut = 300 secondes.
Dump Hours Indique la taille de la 1ere base de donnees tourniquet en heures (nb dheures dinforma-
tions a stocker). On pourra en deduire le nombre de slots necessaire pour stocker N heures din-
formations avant quun nouvel echantillon ecrase un echantillon existant (1 tour du tourniquet).
Valeur par defaut = 72 heures.
1
plugin nativement integre a Ntop (a ne pas confondre avec le plugin RRD dOSSIM)
2
plugin OSSIM cette fois-ci (rrd plugin.pl)
3
affichage sous forme de page Web, via le serveur Web integre a Ntop

Dump Days Indique la taille de la seconde base de donnees tourniquet en jours (nb de jours dinfor-
mations a stocker). On pourra en deduire le nombre de slots necessaire pour stocker N jours din-
formations avant quun nouvel echantillon ecrase un echantillon existant (1 tour du tourniquet).
Valeur par defaut = 90 jours.
Dump Months Indique la taille de la troisieme base de donnees tourniquet en mois (nb de mois din-
formations a stocker). On pourra en deduire le nombre de slots necessaire pour stocker N mois
dinformations avant quun nouvel echantillon ecrase un echantillon existant (1 tour du tourni-
quet). Valeur par defaut = 36 mois.
Creation des bases de donnees tourniquets
Les parametres par defauts ci-dessus generent automatiquement (pour un compteur Ntop, IP HTTPBytes
par exemple) les bases de donnees tourniquets suivantes (calcul des valeurs moyennes) :
RRA:AVERAGE:0.5:1:864
Structure des commandes RRD :

Commande :Fonction :periodeEchantillonage :nbValPourFonction :nbSlots
Commande RRA = creation dune base de donnees tourniquet

Fonction Fonction mathematique appliquee aux valeurs (nbValPourFonction) afin de reduire la taille
des base de donnees tourniquet suivante
periodeEchantillonage Interval de temps entre le releve de deux echantillons
nbValPourFonction Nb dechantillons appliques a la fonction mathematique definie par Fonction
nbSlots Nb de slots de la base de donnees tourniquet
Ainsi, la permiere base de donnees tourniquet ne contiendra aucune moyenne (uniquement les valeurs
instantannees), puisque lAVERAGE est effectue avec une unique valeur (nbValPourFonction = 1). Elle
contiendra 72 heures dinformations recuperees toute les 300 secondes, ce qui implique :
nbHeures nbM inutes/heure nbSecondes/min 72 60 60

= = 864Slots (J.2)
periodeEchantillonage[sec] 300
Pour la seconde base de donnees tourniquet : Un slot de celle-ci correspondra a 12 echantillons (nbVal-
PourFonction) auquels la fonction average (Fonction = AVERAGE) aura ete appliquee. Un slot contiendra
alors la moyenne dune heure dechantillons (12 * 5 = 60 min). Il sera donc necessaire de diposer de 2160
slots afin de pouvoir y stocker 90 jours dinformations :
nbJours nbHeures/jour = 90 24 = 20 160Slots (J.3)

J.2 Analyse des donnees
Cette section vise a expliquer lalgorithme de prevision (heuristique) utilise dans OSSIM. Celui-ci
recupere les informations des bases de donnees RRD afin den tirer ses previsions. Le fonctionnement
des bases de donnees RRD est explique dans la section precedente (section J.1).
Les explications ci-dessous sont tirees des URL suivantes :

http ://iut86-fad.univ-poitiers.fr/StatPC/livre/chapitre8/lissexpo.htm
http ://www.gpa.etsmtl.ca/cours/gpa548/Chapitre2.pdf&ei=NSIDQ6TAO6GEiAKd-IkZ
http ://www.usenix.org/events/lisa2000/full papers/brutlag/brutlag html/index.html
J.2.1 Algorithmes de prevision
Les series temporelles sont basees sur lanalyse des donnes historiques recueillies sur un phenomene
donne, durant une certaine periode de temps (statistiques reseaux par exemples). Les previsions ef-
fectuees a partir de series temporelles ont pour hypothese que le passe est garant de lavenir, que le
phenomene continuera a se comporter comme il la fait dans le passe.
On isole habituellement trois composantes dans les series temporelles :

tendance caracteristique dun phenomene a demontrer, un patron stable de croissance ou de decroissance
dans le temps. Le patron peut etre lineaire ou non-lineaire.
caracteristique dun phenomene qui se repete a intervalles fixes, par exemple tous les hivers, tous les
mois, etc...
aspect cyclique identique a la saisonnalite mais pour des intervalles plus longs, souvent calcules en
annees.
aspect aleatoire se dit dun phenomene qui ne comporte aucun patron decelable.
Divers methodes et modeles de previsions sont actuellement utilisables. Cest le type de la fonction
temporelle a predire qui nous indiquera le meilleur algorithme (modele mathematique) a utiliser. En
effet, il sera inutile dutiliser un modele mathematique complex tel que Holt-Winters si aucun phenomene
cyclique nest present dans la serie temporelle. En effet, dans le cas ou la serie est stationnaire (on ne
distingue pas de tendance a la hausse ni a la baisse), on utilisera le lissage exponentiel simple. Dans le
cas dune serie soumise a des variations saisonnieres, on utilise souvent le modele de Holt et Winters.
Moyennes glissantes
Une moyenne gilssante dordre N est definie comme etant la moyenne arithmetique sur les N dernieres
observations. En methodes previsionnelles, cette moyenne devient la porchaine prevision.
Mathematiquement cela donne :
1
Ft = (Dt1 + Dt2 + ... + DtN ) (J.4)
N

Avec :
Ft La prevision effectuee a la periode t-1 pour la periode t.
Dt-1 La valeur (mesuree) de la serie a la periode t-1.
Lissage exponentiel
Le lissage exponentiel est une classe de methodes de lissage de series chronologiques dont lobjectif
est la prevision a court terme. Ces methodes sont fondees sur une hypothese fondamentale : chaque
observation a linstant t depend des observations precedentes et dune variation accidentelle. En resume,
la prevision courante est une moyenne ponderee de la derniere prevision et de la valeur courante.
Mathematiquement cela secrit sous cette forme :
Ft = Dt1 + (1 )Ft1 (J.5)
Avec :
Ft La prevision effectuee a la periode t-1 pour la periode t.
Dt-1 La valeur (mesuree) de la serie a la periode t-1.
Ft-1 La prevision a la periode t-1 (periode precedente de la nouvelle prevision).
alpha Parametre compris entre 0 et 1.
A laide de la formule J.5, nous remarquons que plus le parametre alpha est grand (proche de 1) plus nous
tenons compte des valeurs precedentes mesurees. Plus alpha est petit (proche de 0), plus nous tenons
compte des valeurs precedentes predites.
Holt-Winters
La methode de Holt et Winters permet en effet deffectuer des previsions sur des series chronologiques
assez irregulieres et soumises ou non a des variations saisonnieres suivant un modele additif ou multipli-
catif. Elle consiste en trois lissages exponentiels simultanes definit par trois parametres. On peut choisir
les coefficients arbitrairement : faibles si lon considere que la valeur a linstant t depend dun grand
nombre dobservations anterieures, eleves dans le cas contraire (meme principe que pour le lissage ex-
ponentiel simple). On peut aussi en calculer les valeurs optimales, en minimisant la somme des carres
des differences entre les valeurs observees et estimees.
Le parametrage de la periodicite (variation saisonniere) est important puisque celui-ci influencera grande-
ment lalgorithme de prevision. La figure J.2 illustre lerreur entre une prediction par lissage exponentiel
et la fonction a observee (en bleu) ainsi que lerreur entre une prediction par Holt-Winters et la fonction
observee (en rouge).
La figure J.3, illustre quant a elle les memes erreurs que la figure precedente (figure J.2) avec, cette
fois-ci, un mauvais reglage du parametre de periodicite de lalgorithme Holt-Winters. Nous remarquons

F IG . J.2 Erreurs de predictions avec un bon reglage du parametre de periodicite de Holt-Winters
donc que la prevision par Holt-Winters devient aussi mauvaise (meme pire) quune simple prediction par
lissage exponentiel. Il est donc tres important de bien regler ce parametre afin dobtenir une prediction
optimale...
Les feuilles de calcul OpenOffice et Excel permettant de tester et comparer le comportement dun algo-
rithme de prediction par lissage exponentiel ainsi que par Holt-Winters sont telechargeables a ladresse
suivante :
http ://www.fullsecurity.ch/security/sims/download.jsp

F IG . J.3 Erreurs de predictions avec un mauvais reglage du parametre de periodicite de Holt-Winters

Ossim Doc

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ossim Doc

Загружено:

Авторское право:

Доступные форматы

Fonctionnement dOSSIM

Dans le cadre de SIMS - Security Intrusion Management System

Auteur : Joel Winteregg (joel.winteregg@heig-vd.ch)

1 License dutilisation de cette documentation 5

2 Etude dOSSIM (Open Source Security Information Management) 6

3 Fonctionnement logiciel dOSSIM 17

3.6 Fonctionnement de larchitecture avec une sonde PADS . . . . . . . . . . . . . . . . . . 22

4 Fonctionnement du Framework (interface Web et serveur OSSIM) 27

2 Institut ICT, Joel Winteregg (cc)

4.9 Configuration Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A Installation et configuration dOssim-server 47

B Ajout et configuration dune sonde Snort 52

C Ajout et configuration de Ntop 58

D Ajout et configuration de P0f 62

3 Institut ICT, Joel Winteregg (cc)

E Ajout et configuration de TCPTrack 63

F Ajout et configuration dune sonde HIDS Syslog 64

G Ajout et configuration dune sonde HIDS IIS 65

H Ajout et configuration de PADS 68

I Creation de regles de correlation 69

J Analyse heuristique - (algorithme Holt-winter) 79

4 Institut ICT, Joel Winteregg (cc)

License dutilisation de cette

THIS WORK IS LICENSED UNDER THE CREATIVE COMMONS ATTRIBUTION-NONCOMMERCIAL-

Etude dOSSIM (Open Source Security

2.2.1 Methodes de detection

Detection par signatures

7 Institut ICT, Joel Winteregg (cc)

Differentes methodes danalyse sont implementees dans le cadre dOSSIM :

2.3.1 Definition de la priorite des alarmes

8 Institut ICT, Joel Winteregg (cc)

2.3.2 Evaluation des risques

9 Institut ICT, Joel Winteregg (cc)

OSSIM met en oeuvre plusieurs methodes de correlation complementaires :

Correlation par heuristique OSSIM implemente un algorithme dheuristique comme un accumula-

10 Institut ICT, Joel Winteregg (cc)

Par consequence, la correlation par heuristique offre :

11 Institut ICT, Joel Winteregg (cc)

12 Institut ICT, Joel Winteregg (cc)

2.4.1 Risk monitor (moniteur du risque)

2.4.2 Moniteur dutilisation, session et profile

2.4.3 Path monitor (moniteur de chemin)

Hard link analysis (Analyse des liens TCP)

Soft link analysis

2.4.4 Forensic console (Console legale)

13 Institut ICT, Joel Winteregg (cc)

2.4.5 Control Panel (panneau de controle)

Larchitecture dOSSIM est divisee en 2 principaux etages :

F IG . 2.1 Architecture dOSSIM

14 Institut ICT, Joel Winteregg (cc)

2.5.1 Data flow

15 Institut ICT, Joel Winteregg (cc)

F IG . 2.2 Data flow du serveur OSSIM

16 Institut ICT, Joel Winteregg (cc)

Fonctionnement logiciel dOSSIM

3.1 Les applications Ossim-server et Ossim-agent

3.2 Fonctionnement de larchitecture avec une sonde Snort

3.2.1 Pourquoi deux flux dinformations ?

F IG . 3.1 Principe de communication entre une sonde Snort et le serveur dOSSIM

18 Institut ICT, Joel Winteregg (cc)

3.3 Fonctionnement de larchitecture avec une sonde Ntop et le plugin

F IG . 3.2 Principe de communication entre une sonde Ntop et le serveur dOSSIM

3.3.1 Quest-ce que Ntop ?