Ossim Doc PDF

Fonctionnement d’OSSIM
Dans le cadre de SIMS - Security Intrusion Management System

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

Professeur : Stefano Ventura
École : Swiss University of Applied Sciences (HEIG-VD)
Institut ICT (http ://www.iict.ch)
Date : 12 mai 2006
Version : 3.4
Table des matières
1 License d’utilisation de cette documentation 5
2 Étude d’OSSIM (Open Source Security Information Management) 6

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 La détection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Méthodes de détection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 L’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Définition de la priorité des alarmes . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Évaluation des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Corrélation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Le monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Risk monitor (moniteur du risque) . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2 Moniteur d’utilisation, session et profile . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Path monitor (moniteur de chemin) . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.4 Forensic console (Console légale) . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.5 Control Panel (panneau de contrôle) . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Fonctionnement logiciel d’OSSIM 17

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

3.6.1 Qu’est-ce que PADS ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Fonctionnement de l’architecture avec une sonde Syslog . . . . . . . . . . . . . . . . . 24
3.7.1 Qu’est-ce qu’une sonde HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.8 Fonctionnement de l’architecture avec une sonde HIDS IIS (Internet Information Services) 25
3.8.1 Qu’est-ce qu’une 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 Définition 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, Joël 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 d’Ossim-server 47

A.1 Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 corrélation via Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
B Ajout et configuration d’une 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 d’Ossim-server pour une nouvelle sonde Snort . . . . . . . . . . . . . . . 55
B.4 Test de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
B.4.1 Erreur de démarrage de l’agent 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 L’agent Ossim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C.3 Configuration d’Ossim-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 L’agent Ossim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
E Ajout et configuration de TCPTrack 63

E.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
E.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
F Ajout et configuration d’une sonde HIDS Syslog 64

F.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
F.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
G Ajout et configuration d’une 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 l’agent 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 Création de règles de corrélation 69

I.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
I.2 Ajout d’un fichier de règles 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 caractéristiques . . . . . . . . . . . . . . . . . . . . . . 71
I.4 Structures des directives de corrélation . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
I.4.1 Exemple de structure des directives . . . . . . . . . . . . . . . . . . . . . . . . 75
I.4.2 Structure de corrélation réalisable . . . . . . . . . . . . . . . . . . . . . . . . . 77
J Analyse heuristique - (algorithme Holt-winter) 79

J.1 Récupération des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
J.1.1 Configuration du plugin RRD de Ntop . . . . . . . . . . . . . . . . . . . . . . . 80
J.2 Analyse des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
J.2.1 Algorithmes de prévision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Chapitre 1
License d’utilisation 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
Étude d’OSSIM (Open Source Security

Information Management)
2.1 Introduction
OSSIM est une solution offrant une infrastructure pour le monitoring de la sécurité réseau. Ses objectifs
sont :
– Fournir un cadre centralisé
– Fournir une console d’organisation
– Améliorer la détection et l’affichage des alarmes de sécurité
Le but commun des trois principaux objectifs décrits ci-dessus est de permettre une réduction des
faux positifs1 et des faux négatifs2 . Ce but est d’autant plus difficile à atteindre du fait qu’un volume
considérable d’alarmes est présent. Il est donc nécessaire de relier ces différentes alarmes entre elles afin
d’obtenir des informations pertinantes et d’éliminer les alarmes innutiles (levées pour rien). Cet objectif
peut être atteint à l’aide d’un procédé d’analyse des données nommé : Corrélation.
Le principe de fonctionnement d’OSSIM est formé de trois grandes catégories décomposées elles-mêmes
en sous catégories :
1. La détection
– IDS (pattern matching3 )
– Détection d’anomalie
– Firewalls
2. L’analyse et le monitoring (détaillé en section 2.3.3 et 2.4)
1
Alarmes levées pour rien
2
Alarmes non déclenchées alors qu’une attaque a eu lieu
3
signatures
6
– Corrélation
– Évaluation de la dangerosité des alarmes
– Évaluation du risque sur l’architecture à protéger
3. Les management (configuration)
– Inventaire des ressources informatiques4
– Définition de la topologie
– Définition des polices de sécurité
– Définition des règles de corrélation
– Liens avec différents outils d’audits Open Source
Les différents procédés cités ci-dessus seront détaillés dans les sections suivantes.
2.2 La détection
Celle-ci est évidemment effectuée à l’aide de sondes capables de traiter l’information5 en temps réel et
d’émettre des alarmes lorsqu’une situation à risque est détectée.
2.2.1 Méthodes de détection
Une sonde peut utiliser différentes approches afin de déterminer si une événement est à risque ou non.
En effet, deux grands principes complémentaires (et non concurrent) sont présents dans la détection
d’intrusions :
1. Basé sur des signatures
2. Basé sur la détection d’anomalie
Détection par signatures
La détection par signatures identifie des événements de sécurité qui tentent d’utiliser un système de façon
non standard. Les représentations d’intrusions sont donc stockées et comparées à l’activité du système.
Lorsqu’une intrusion connue est repérée lors de l’utilisation du système, une alarme est levée.
La détection par signatures a des limites. Elle ne connaı̂t pas l’objectif de l’activité correspondant à
une signature et va donc déclencher une alerte même si le trafic est normal. De plus, la détection par
signature exige de connaı̂tre préalablement l’attaque afin de générer la signature précise correspondante
(fonctionnement par liste noire, exemple : antivirus). Ceci implique qu’une attaque encore inconnue ne
pourra pas être détectée par signature.
4
machines, systèmes d’exploitation, services
5
Trames transitants par le réseau ou log d’une application

Détection d’anomalie
La détection d’anomalie identifie une activité suspecte en mesurant une norme6 sur un certain temps.
Une alerte est ensuite générée lorsque le modèle s’éloigne de cette norme.
Le principal avantage de la détection d’anomalie est qu’elle n’exige aucune connaissance préalable des
attaques. Si le module de détection par anomalie détermine qu’une attaque diffère de façon significative
de l’activité normale, il peut la détecter.
Comme la détection par recherche de pattern, la détection d’anomalie possède ses limites. Toute la dif-
ficulté réside dans la période de collecte des données correspondant à une activité désignée comme
normale pour alimenter la base de données de référence.
2.3 L’analyse
La méthode de traitement des données peut être décomposée en trois phases distinctes :
1. Preprocessing, génération des alarmes et envoi de celles-ci.
2. Rassemblement, toutes les alarmes précédemment envoyées (preprocessing) sont emmagasinées
dans un serveur central.
3. Post-processing, le traitement des données que l’on a emagasiné.
Les deux premières étapes (preprocessing et rassemblement) ne présentent rien de nouveau dans le cadre
d’OSSIM. Celles-ci font principalement partie des méthodes de détection mentionnées ci-dessus (section
2.2). OSSIM offrira uniquement de nouvelles méthodes d’analyse et d’affichage des données récoltées.
Il n’apportera en aucun cas de nouvelles solutions dans la détection et le rassemblement de données.
Différentes méthodes d’analyse sont implémentées dans le cadre d’OSSIM :

– Définition de la priorité des alarmes
– Évaluation des risques
– Corrélation
2.3.1 Définition de la priorité des alarmes
Ce procédé permettra de déduire la priorité d’une alarme en fonction de son type, de la source de
l’éventuelle attaque ainsi que de sa cible. Les exemples suivants illustrent facilement l’utilité de cette
étape d’analyse :
– Une machine fonctionnant avec le système d’exploitation UNIX et hébergeant un serveur Web
Apache est mentionnée comme cible d’une attaque. Cette attaque a précédemment été détectée
comme possible à l’aide d’un scanner de vulnérabilités. La piorité de l’alerte sera donc maximale
6
Peut être assimilé à un chablon de bon fonctionnement (activité normale)

puisque le serveur Web est vulnérable à l’attaque en question. Un procédé de cross-corrélation est
donc appliqué à toutes les alertes.
– Si la connexion à un serveur génère une alarme, la configuration de police de sécurité en fonction
des utilisateurs permettra facilement la définition de la priorité de celle-ci. En effet, différents cas
sont envisageables :
– Priorité maximale de l’alarme si l’utilisateur (source de ”l’attaque”) est extérieur au réseau
de l’entreprise et que la connexion a pour cible une base de données importantes.
– Basse priorité si l’utilisateur (source de ”l’attaque”) est interne au réseau de l’entreprise et
que la connexion a pour cible une imprimante.
– Alarme discréditée si l’utilisateur (source de ”l’attaque”) fait partie de l’équipe de développement
et que la cible de la connexion est un serveur de test.
La définition de priorité fait partie d’une étape de mise en place de contextes des alarmes. Celle-ci est
uniquement possible si l’environnement de l’entreprise est défini dans une base de données des connais-
sances. Cette base de données est définie par l’inventaire des bien informatiques ainsi que sur des polices
d’accès à des serveurs et/ou services. La définition des ces différentes polices de sécurités implique
la mise à disposition d’un outil de management permettant une configuration précise des polices de
sécurités ainsi que des machines du réseau.
Cette étape représente une part importante du filtrage des alarmes et nécessitera une constante mise à
jour de la base de données des connaissances.
2.3.2 Évaluation des risques
Le risque peut être défini comme étant la probabilité de menace de l’événement. En d’autres termes,
cette étape tente de définir si la menace est réelle ou pas.
L’importance à donner à un événement dépend principalement de trois facteurs :
1. La valeur du bien attaqué
2. La menace représentée par l’événement
3. La probabilité que l’événement apparaisse
Les trois facteurs vus ci-dessus sont la base du calcul du risque intrinsèque.
Risque intrinsèque
Ce risque peut être défini de la façon suivante : La mesure de l’impact 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 émit l’alarme.
Le risque est traditionnellement représenté par le risque intrinsèque représentant le risque qu’une orga-
nisation court de par les biens qu’elle possède.

Risque immédiat
Étant donné qu’OSSIM offre un traitement temps réel des alarmes, le calcul du risque immédiat peut être
associé à la situation courante.
Ce risque offre une vision de l’évaluation des dégats qu’une alarme reçue pourrait engendrer. Cette
évaluation prendra aussi en compte la fiabilité du capteur ayant émis cette alarme. Le risque immédiat
est donc calculé pour chaque alarmes reçues et indique l’importance de l’alarme en terme de sécurité.
2.3.3 Corrélation
Ce procédé permet nottamment de retrouver certaines relations entre différentes alarmes indépendantes.
Ceci permettra par exemple de découvrir des attaques noyées dans le flot des alarmes ou encore de
discréditer des alarmes (découverte de faux positifs).
La corrélation peut être simplement définie comme un procédé traitant des données (inputs) et retournant
un résultat (outputs). OSSIM utilise deux types d’inputs :
1. Informations du moniteur (qui fournit normalement des indications à l’administrateur)
2. Informations des détecteurs (qui fournissent normalement des alarmes)
Le résultat de ce traitement sera lui aussi d’un des deux genres cités ci-dessus (du moniteur ou des
détecteurs). Les modèles de corrélations utilisés par OSSIM ont les objectifs suivants :
– Utilisation de méthodes par signatures, pour la détection d’événements connus et détectables
– Utilisation de méthodes sans signature, pour la détection d’événements non connus
– Utilisation d’une machine d’états configurable par l’utilisateur, pour la description de signatures
complexes
– Utilisation d’algorithmes évolués, pour l’affichage général de la sécurité
Méthodes de corrélation
OSSIM met en oeuvre plusieurs méthodes de corrélation complémentaires :

1. Corrélation utilisant des séquences d’événements, basées sur les signatures connues et détectables
2. Corrélation utilisant des algorithmes heuristique7 , utilisée pour la détection d’attaques non connues
3. Cross-corrélation permettant la recherche de relations entre les scans Nessus effectués et des alertes
détectées
Corrélation par heuristique OSSIM implémente un algorithme d’heuristique comme un accumula-

teur d’événements (CALM), offrant une indication de l’état général du réseau. L’objectif de ce traitement
est d’obtenir en premier lieu, le risque immédiat (définit dans la section 2.3.2) puis, le risque accumulé.
7
Technique consistant à apprendre petit à petit, en tenant compte de ce que l’on a fait précédemment pour tendre vers la
solution d’un problème

– Le risque immédiat offre un haut niveau de monitoring temps réel. Celui-ci peut être assimilé à
un ”thermomètre” des situations critiques, sans même connaı̂tre les détails des caractéristiques du
problème.
– Le risque accumulé offre quant à lui un haut niveau de monitoring sur une certaine fenêtre tempo-
relle (risque accumulé et non plus temps réel).
Le second algorithme heuristique utilisé par OSSIM permet la prévision des statistiques réseaux (paquets
émis et reçus) en fonction des valeurs précédentes (Holt-winter). Ceci permettra la détection automatique
d’anomalies réseaux.
Par conséquence, la corrélation par heuristique offre :

– Une vue globale et rapide de la situation
– Une détection possible d’attaques, non relevées par les autres méthodes de corrélation (se basant
sur des signatures)
CALM (Compromise and Attack Level Monitor), est un algorithme8 utilisant les événements accumulés et
fournissant une valeur indicative du niveau de sécurité global. L’accumulation d’événements est effectuée
indépendamment pour tous les éléments du réseau. Celle-ci est simplement calculée par la somme de
deux variables d’état représentant le risque immédiat de chaque événement :
1. Variable ”C” ou niveau de fiabilité d’une machine ou d’un réseau, mesure la probabilité qu’une
machine ou un réseau soit compromis (source d’une attaque effectué par un ver ou troyen installé
sur une machine à surveiller).
2. Variable ”A” indique la probabilité que la machine ou réseau à surveiller soit la cible d’attaques.
La variable ”A” représente la probabilité qu’une attaque a été lancée et qu’elle est réussie, alors que la
variable ”C” fournit l’évidence qu’il y a eu une attaque et qu’elle a réussi.
Chaque machine du réseau a donc une variable ”A” et ”C” associée, fluctuant de la manière suivante :
1. Toute attaque possible d’une machine 1 (source) vers une machine 2 (cible) incrémentera le niveau
”A” de la machine 2 et le niveau ”C” de la machine 1.
2. Lorsqu’une réponse à une attaque est détectée (signifiant que l’attaque est réussie), le niveau ”C”
des deux machines sera incrémenté.
3. Lorsque l’événement est interne (source interne), seul le niveau ”C” de la machine source est
incrémenté.
CALM fonctionne d’une manière temps réel (accumulation temps réel des événements). Il peut aussi être
intéressant d’observer ces statistiques dans une fenêtre temporelle (accumulation sur le temps). En ef-
fet, ceux-ci varieront grandement en fonction de la fenêtre utilisée puisqu’un fonctionnement temps réel
(accumulation continue d’événements) aura pour effet de noyer certaines alarmes critiques dans la masse
d’information. Nous pourrions assimiler le fonctionnement d’accumulation sur le temps à un zoom sur
les statistiques temps réel.
8
Algorithme implémenté dans OSSIM

Holt-Winter Algorithme, algorithme heuristique implémenté dans le moteur de corrélation temps réel
d’OSSIM, permettant la découverte de comportements anormaux sans l’utilisation de seuils. Descrip-
tion tirée de : http ://www.usenix.org/events/lisa2000/full papers/brutlag/brutlag html/index.html
La détection anormale de comportements est décomposée en trois parties, chacune établie selon son
prédécesseur :
1. Un algorithme pour prévoir pas par pas les valeurs d’une série chronologique.
2. Une mesure de déviation entre les valeurs prévues et les valeurs observées.
3. Un mécanisme détectant lorsqu’une valeur est ”trop déviante” de la valeur prévue.
L’algorithme de prévision Holt-Winter fait appel aux principes de lissage exponentiel (genre de moyenne
mathématique permettant la prédiction de valeurs). En effet, Holt-Winter fournit une méthode un peu
plus complexe utilisant un triple lissage exponentiel. Pour plus d’informations au sujet de cet algorithme,
consultez l’annexe J.
Corrélation par diagramme d’états (séquence d’événements) Ce genre de corrélation fait appel à
la détection par signatures. Ceci permettra à l’utilisateur (administrateur réseau en charge de la sécurité),
de définir des règles de corrélation à l’aide des signatures disponnibles. Exemple : Si l’alarme A, B et C
est levée, il faut exécuter l’action D. Ceci s’apparente donc au moteur de corrélation développé par M.
Saladino dans le cadre de SIMS 20039 .
Le moteur de corrélation d’OSSIM a les caractéristiques suivantes :
Capacité de définir des variables d’origines et de destination
Utilisation des alarmes des détecteurs (détection par signature) et/ou des informations des moni-
teurs (monitoring) comme input pour la corrélation
Utilisation de variables élastiques (accumulant des informations au cour du temps)
Architecture récursive (possibilité d’utiliser des règles précédemment définie dans de nouvelle
règles)
2.4 Le monitoring
Le monitoring consiste en l’affichage des informations fournies. Les consoles de monitoring utilisent les
différentes données produites par les procédés de corrélation (décrit ci-dessus) pour la construction d’un
affichage efficace et/ou résumé.
9
Réalisé dans le cadre d’un projet de diplôme de l’institut Tcom de l’Eivd
(http ://www.tcom.ch/Tcom/Projets/SIMS/sims.html)

2.4.1 Risk monitor (moniteur du risque)
Ce moniteur appelé ”RiskMeter” permet l’affichage des données produites par l’algorithme CALM
(décrit dans la section 2.3.3). Les informations ”C” (mesure de la fiabilité) et ”A” (mesure du niveau
d’attaque) sont illustrés graphiquement par ce moniteur.
2.4.2 Moniteur d’utilisation, session et profile
Comme décrit plus haut, OSSIM place une grande importance sur le monitoring détaillé de chaque
machine et profile. Il existe 3 différents types de monitoring dans OSSIM :
1. Monitoring d’utilisation, offrant une vue générale d’une machine (comme snmp le ferai)
2. Monitoring de profile, offrant des informations spécifiques sur l’activité des utilisateurs, nous per-
mettant d’établir un profil (pop, http, etc..) pour chaque utilisateur
3. Monitoring de session, offre un affichage temps réel des sessions en cours d’un utilisateur
2.4.3 Path monitor (moniteur de chemin)
Ce moniteur offre un affichage temps réel des chemins de l’information empruntés par des données
émises par différentes machines sur le réseau. Il utilise les informations fournies par le moniteur de
session (identifiant chaque lien présent sur le réseau) et par le moniteur de risque (fournissant le niveau
de risque de chaque machine) afin de construire un affichage agréable (à l’aide de différentes couleurs).
Deux méthodes d’affichage et d’analyse sont disponibles.
Hard link analysis (Analyse des liens TCP)
Cette méthode affiche uniquement les sessions TCP courantes. Le but de celle-ci est de pouvoir observer
la propagation d’une attaque ou d’un ver afin de déterminer un périmètre de sécurité.
Soft link analysis
Cette méthode d’analyse offre l’affichage de tous les liens perçus sur le réseau (UDP, TCP, ICMP inclus).
2.4.4 Forensic console (Console légale)
Cette console offre l’accès à toutes les informations recueillies et stockées par le collecteur. Elle est donc
un outil de recherche sur la base de données d’événements. Celle-ci permet une analyse à postériori
détaillée et approfondie des éléments réseaux.

2.4.5 Control Panel (panneau de contrôle)
Cette console offre un aperçu de haut niveau de la sécurité. Cette console permet la définition de seuils
générant des alarmes de haut niveau à destination de l’administrateur réseau en charge de la sécurité.
L’affichage est simple est le plus concis possible et permet la visualisation des informations suivantes :
– Monitoring constant du niveau de risque
– Monitoring constant du réseau (statistiques d’utilisation)
– Monitoring des seuils définis
– Monitoring des profiles dépassant les seuils
2.5 Architecture
L’architecture d’OSSIM est divisée en 2 principaux étages :

1. Pré-processing, remontée d’évenements des moniteurs et détecteurs dans une base de données
commune
2. Post- processing, analyse centralisée
La figure 2.1 illustre le fonctionnement en 2 étages (comme mentionné ci-dessus). Nous remarquons que
ces deux étages disposent de différentes bases de données permettant la sauvegarde des informations
intermédiaires (corrélées). Défintions des bases de données :
F IG . 2.1 – Architecture d’OSSIM
EDB La base de données des événements (la plus grande), stockant toutes les alarmes individuelles

KDB La base de données des connaissances, sauvegardant les configurations établies par l’administra-
teur en charge de la sécurité
UDB La base de données des profiles, stockant toutes les informations du moniteur de profile
2.5.1 Data flow
Afin d’aider à la compréhension, nous allons détailler le cheminement d’une alarme dans l’architecture
définie par la figure 2.1. Le schéma de la figure 2.2, illustre le fonctionnement décrit ci-dessous :
1. Détection d’un événement suspect par un détecteur (par signatures ou par l’heuristique)
2. Si nécessaire, des alarmes sont regroupées (par le détecteur) afin de diminuer le trafic réseau
3. Le collecteur reçoit la/les alarme(s) via différents protocoles de communications ouverts
4. Le parser normalise et sauve les alarmes dans la base de données d’événements (EDB)
5. Le parser assigne une priorité aux alarmes reçues en fonction de la configuration des polices de
sécurités définies par l’administrateur sécurité
6. Le parser évalue le risque immédiat représenté par l’alarme et envoie si nécessaire une alarme
interne au Control panel
7. L’alerte est maintenant envoyée à tous les processus de corrélation qui mettent à jour leurs états et
envoient éventuellement une alerte interne plus précise (groupe d’alerte provenant de la corrélation)
au module de centralisation.
8. Le moniteur de risque affiche périodiquement l’état de chaque risque calculés par CALM10 .
9. Le paneau de contrôle affiche les alarmes les plus récentes et met à jour les indices des états qui
sont comparés aux seuils définis par l’administrateur. Si les indices sont supérieurs aux seuils
configurés, une alarme interne est émise.
10. Depuis le panneau de contrôle, l’administrateur a la possibilité de visualiser et rechercher des liens
entre les différentes alarmes à l’aide de la console forensic
10
Algorithme décrit dans la section 2.3.3

F IG . 2.2 – Data flow du serveur OSSIM

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

Ossim-agent récupère 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 réel
de celles-ci. De plus, l’agent Ossim s’occupera de la mise en marche et de l’arrêt des différentes
sondes qui lui sont connectées. Il ne sera ainsi pas nécessaire de démarrer la sonde Snort ”à la
main” puisque son activation sera effectuée depuis la console de management offerte par Ossim-
server.
Ossim-server constitue le noyau de l’architecture. En effet, celui-ci comporte les modules d’analyse
et de corrélation des données ainsi qu’un serveur Web permettant l’interaction avec l’utilisateur
(administrateur réseau).
3.2 Fonctionnement de l’architecture avec une sonde Snort
Le principe de communication d’une sonde Snort avec le serveur OSSIM est illustré par la figure 3.1.
Nous remarquons que l’IDS1 Snort est indépendant du programme client d’OSSIM (nommé : ossim-
agent) et que deux flux d’informations sont émis en direction du serveur.
3.2.1 Pourquoi deux flux d’informations ?
Le flux nommé ”Requêtes SQL pour dépos des alertes” est utilisé afin de déposer directement les
alertes dans la base de données ”Snort DB” du serveur. Ceci permettra l’archivage de celles-ci et
1
Intrusion Detection System
17
F IG . 3.1 – Principe de communication entre une sonde Snort et le serveur d’OSSIM
leur conslutation via ACID2 , permettant ainsi l’analyse précise de chaque alertes.
Le flux nommé ”Envoi des alertes pour l’anayse temps réel (TCP et protocole applicatif propre à
OSSIM” est quant à lui nécessaire pour le procédé d’analye et de corrélation temps réel opéré sur
le serveur d’OSSIM.
Ces deux flux d’informations redondants sont indispensables si l’on ne veut pas redéfinir le protocole
d’envoi des informations dans la base de données ”Snort DB”. En effet, le plugin de sortie Mysql ne
serait pas suffisant pour un traitement temps réel puisque le stockage des informations dans une base de
données ”casse” le procédé temps réel. Un tel fonctionnement impliquerait l’interrogation continuelle
de la base de données afin de découvrir les nouvelles données insérées. Les concepteurs d’OSSIM ont
donc préféré utiliser deux flux d’informations plutôt que de créer un nouveau plugin de sortie pour Snort
permettant d’envoyer les alertes dans un seul flux structuré au serveur. Dans ce mode de fonctionnement,
c’est le serveur qui se chargerait ensuite du traitement temps réel et de l’insertion des informations dans
une base de données.
Pour l’analyse et la corrélation, le serveur Ossim utilise uniquement les alertes provenant de l’agent Os-
sim, alors que les alertes directement stockées dans la base de données sont uniquement utilisées pour la
2
Analysis Console for Intrusion Databases, interface Web intégrée à OSSIM permettant l’interrogation d’une base de
données Snort (développé dans le cadre du projet Open Source Snort)

consultation.
3.3 Fonctionnement de l’architecture avec une sonde Ntop et le plugin

RRD
Le principe de communication d’une 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 d’OSSIM
3.3.1 Qu’est-ce que Ntop ?
Ce logiciel analyse de manière temps réel le trafic réseau et met à disposition une liste de compteurs (par
exemple : IP DNSBytes, IP HTTPBytes), permettant le monitoring ainsi que le calcul de statistiques
réseaux. 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 nécessaire pour l’intégration des fonctionnalités heuristiques et de détection
de seuils dans OSSIM. Celui-ci permet l’enregistrement des données Ntop sous forme de tourniquet (les
3
Round Robin Database

plus vieilles données sont écrasées par les nouvelles). L’interrogation de la base de donnée RRD est en-
suite facilitée à l’aide de l’outil RRDtool4 utilisé par le script rrd plugin.pl offrant les fonctions d’analyse
heuristiques et de contrôle de dépassement de seuils.
Des seuils RRD ainsi que les paramètres de l’analyse heuristique (algorithme Holt-Winter expliqué dans
l’annexe J) peuvent ensuite être défini par l’administateur sécurité via le framework (cf. section 4.9.4).
Cette configuration permettra la génération d’alertes lorsque des valeurs excessives auront été détectées
par rrd plugin.pl.
3.3.2 Fonctionnement
Le script Perl rrd plugin.pl effectue la liaison entre Ntop et l’agent Ossim pour les fonctionnalités
heuristiques (Holtwinter algorithme) et de détection de seuils. Celui-ci interroge périodiquement la
”base de données” RRD (illustrée par Ntop/rrd log file sur la figure 3.2) à l’aide de l’outil RRDtool.
Il récupère (via des requêtes SQL sur le serveur) les seuils des compteurs définis par l’administrateur
réseau à l’aide du framework de configuration5 et les compare aux données précédemment récupérées
(à l’aide de RRDtool). Les éventuels dépassements des seuils sont ensuite stockés dans un fichier de log
(/var/log/ossim/rrd plugin.log) qui sera récupéré par l’agent Ossim afin de permettre l’envoi temps réel
des informations au serveur.
La corrélation des ces informations peut ensuite être effectuée sur le serveur.
3.4 Fonctionnement de l’architecture avec une sonde P0f
Le principe de communication d’une sonde P0f avec le serveur OSSIM est illustré par la figure 3.3.
3.4.1 Qu’est-ce que P0f ?
P0f est un logiciel de détection de systèmes d’exploitations6 passif. Il analyse les trames transitant sur le
réseau (le segment analysé) et les compare avec une base de données des caractéristiques de chaque OS
(prise d’empreintes) afin d’en retrouver l’OS correspondant :
1. détection de la présence d’un firewall et NAT
2. détection d’un load balancer (répartiteur de charge réseau)
3. détection de la distance (TTL) de la machine distante ainsi que depuis combien de temps la ma-
chine est démarrée
P0f est totalement passif. Il ne génère aucun traffic réseau supplémentaire !
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 d’OSSIM
Celui-ci est assez simple. P0f écrit ses logs dans le fichier /var/log/ossim/p0f.log (chemin fournit à P0f
par l’agent Ossim lors du lancement de P0f). Ce chemin se trouve donc dans la configuration du plugin
P0f (/etc/ossim/agent/plugins/p0f.xml) de l’agent. Le daemon agent (ossim-agent) s’occupera ensuite de
les récupérer afin de les envoyer au serveur OSSIM pour une analyse temps réel.
3.5 Fonctionnement de l’architecture avec une sonde TCPTrack
Le principe de communication d’une sonde TCPTrack avec le serveur OSSIM est illustré par la figure
3.4.
3.5.1 Qu’est-ce que TCPTrack ?
TCPTrack est un sniffer affichant des informations sur les connexions TCP qu’il rencontre sur une inter-
face. Il détecte passivement les connexions TCP sur l’interface à analyser et affiche les informations de
la même manière que la commande Unix top. Il permet l’affichage des adresses source et destination, de
l’état de la connexion, du temps de connexion ainsi que de la bande passante utilisée.

F IG . 3.4 – Principe de communication entre une sonde TCPTrack et le serveur d’OSSIM
TCPTrack fonctionne d’une manière similaire à l’affichage Web des informations de Ntop. En effet,
aucune information n’est spontanément envoyée vers le serveur OSSIM. TcpTrack ouvre simplement
un port serveur7 sur la loopback de l’agent. C’est ensuite le serveur OSSIM qui, lors du procédé de
corrélation, interrogera si nécessaire l’agent afin qu’il interroge à son tour TCPTrack (via la loopback).
Une fois les informations récoltées par l’agent, celui-ci se chargera de les remettre au serveur qui les
utilisera pour la corrélation. L’agent joue donc un rôle d’intermédiaire entre le serveur et le sonde TCP-
Track.
3.6 Fonctionnement de l’architecture avec une sonde PADS
Le principe de communication d’une sonde PADS8 avec le serveur OSSIM est illustré par la figure 3.5.
7
port 40003 par défaut
8
Passive Asset Detection System

3.6.1 Qu’est-ce que PADS ?
PADS va permettre d’identifier les machines (adresses IP et MAC) ainsi que leurs services uniquement
en sniffant le réseau. Il permettra l’affichage des services d’une machine sans avoir à opérer un scan actif
comme nmap9 . Il permettra l’affichage des services d’une machine configurée sur OSSIM sans opérer
un scan actif.
Le logiciel PADS reportera simplement toutes les informations récoltées dans le fichier de log /var/log/ossim/pads.csv
(indiqué dans la configuration du plugin, fichier /etc/ossim/agent/plugins/pad.xml). L’agent Ossim se
chargera ensuite de les récolter et de les envoyer de manière temps réel au serveur.
F IG . 3.5 – Principe de communication entre une sonde PADS et le serveur d’OSSIM
9
Outil intégré à OSSIM permettant, entre autre, des scans de ports

3.7 Fonctionnement de l’architecture avec une sonde Syslog
Le principe de communication d’une 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 d’OSSIM
3.7.1 Qu’est-ce qu’une sonde HIDS
Ces sondes ont pour but de rechercher des patterns spécifiques dans des fichiers de logs. Dès qu’une suite
de caractère (pattern) appartenant à la liste des patterns recherché est détecté, une alerte est générée. Il
est ainsi possible de remonter des événements spécifiques (critiques) vers la console de monitoring. De
plus, à l’aide du sid de chaque règle, il est possible de les utiliser dans des règles de corrélation sur le
serveur.
10
Host Intrusion Detection System

Le parser analysant le fichier Syslog d’une machine Linux est directement présent sous forme native sur
les agents OSSIM. Son code et ses règles sont présents dans un seul et unique fichier /usr/share/ossim-
agent/pyossim/ParserSyslog.py. Il analysera le fichier de logs de manière temps réel et informera le
serveur OSSIM, via la connexion présente entre l’agent et le serveur, dès qu’un pattern présent dans la
liste de pattern interdits (blacklist) aura été détecté.
3.8 Fonctionnement de l’architecture avec une sonde HIDS IIS (Internet

Information Services)
Le principe de communication d’une 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 d’OSSIM
11
Host Intrusion Detection System

3.8.1 Qu’est-ce qu’une sonde HIDS
Ces sondes ont pour but de rechercher des patterns spécifiques dans des fichiers de logs. Dès qu’une suite
de caractère (pattern) appartenant à la liste des patterns recherché est détecté, une alerte est générée. Il
est ainsi possible de remonter des événements spécifiques (critiques) vers la console de monitoring. De
plus, à l’aide du sid de chaque règle, il est possible de les utiliser dans des règles de corrélation sur le
serveur.
Le serveur web de Windows (IIS) doit obligatoirement utiliser un programme spécifique (SnareIIS) per-
mettant d’envoyer les logs du serveur sur une machine distante (l’agent OSSIM dans notre cas). En effet,
aucun agent OSSIM n’est disponible pour Windows.
Le parser présent sous forme native sur les agents OSSIM (/usr/share/ossim-agent/pyossim/ParserIIS.py)
analysera le fichier de logs de manière temps réel et transmettra par défaut tous les logs du serveur web
au serveur OSSIM via le flux présent entre le serveur et l’agent (chaque log étant 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 d’agents et d’hôtes à

protéger) est disponible à l’adresse suivante : http ://www.ossim.net/docs/User-Manual.pdf
Ce chapitre fera le lien entre les différents outils décrits précédemment et les menus disponibles dans le
framework d’OSSIM.
Trois termes bien distincts seront employés dans ce chapitre. Il est très important d’en saisir la différence :
Alerte Information de détection d’intrusion ou d’anomalie brut généré par une sonde. Typiquement, les
alertes Snort générées par un agent. Celles-ci contiendront donc un grand nombre de faux positifs...
Groupe d’alertes Information correspondant au résultat d’une corrélation (alerte de haut niveau). Il
s’agira donc de plusieurs alertes reliées ensemble selon des caractéristiques définies par les direc-
tives de corrélation.
Alarme Alerte ou groupe d’alertes ayant atteint un niveau de risque supérieur ou égal à 2 (valeur cal-
culée selon la forumule 4.1, puis arrondie. Par exemple : 1.6 est arrondi à 2).
4.2 Architecture des menu du framework
L’interface 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 d’eux afin que le lecteur soit
ensuite capable d’utiliser plainement les fonctionnalités d’OSSIM.
27
4.3 Définition du risque
Plusieurs paramètres permettent de qualifier le niveau de dangerosité (risque) d’une alerte/groupe d’alertes.
Il est important de bien saisir leur signification afin d’être à même de créer des règles de corrélation ou
même de gérer correctement les alarmes selon leur niveau d’importance.
Asset Il s’agı̂t là d’une valeur permettant de définir l’importance d’une machine sur le réseau. En effet,
un serveur Web sera souvent une ressource plus précieuse pour une entreprise qu’une imprimante
réseau. Comme nous le verrons après, ces spécifications seront prises en compte lors du calcul du
risque de chaque alerte.
Il est ainsi possible de définir pour chaque machine (menu Policy sous-menu Hosts) l’Asset de
celles-ci. Cette valeur doit être comprise entre 0 et 5 (0 = machine peu importante pour l’entreprise,
5 = machine très importante pour l’entreprise).
Priority Cette valeur permet de mesurer la gravité d’une alerte ou d’un groupe d’alertes isolée. En
effet, celle-ci ne tient aucunement compte de l’environement ou de l’hôte à protéger. Ce niveau
est donc uniquement dépendant de l’alerte ou du groupe d’alertes (résultat d’une corrélation). Il
est donc possible d’ajuster le niveau Priority des alertes de chaque plugins via le menu Configura-
tion, sous-menu Plugins. Celui-ci est aussi définit (surcharge des priorités définies par les alertes
indépendantes) pour chaque règle de corrélation, permettant le réglage de la priorité du résultat de
la corrélation (groupe d’alertes).
La valeur de ce paramètre est ajustable entre 0 et 5.
Reliability En terme de risque, ce paramètre pourrait s’appeler la ”probabilité”. Celui-ci est défini pour
chaque alerte indépendante (via le menu Configuration, sous-menu Plugins). Il est ainsi possible
de qualifier la probabilité que l’alerte se produise.
Ce paramètre sera principalement ajusté sur les groupes d’alertes par le moteur de corrélation
(surcharge de la valeur définie pour le plugin). Celui-ci sera capable d’augmenter la reliability
d’un groupe d’alarme à chaque fois qu’une sous-règle sera matchée. Ceci prouvera pas à pas que
ce groupe d’alertes (alerte de haut niveau) n’est pas un faux positif. Le terme reliability peut donc
être traduit par la fiabilité qu’une alarme n’est pas un faux positif. La valeur de ce paramètre est
comprise entre 0 et 10 (équivalent à 0% = c’est un faux positif et 100%= ce n’est pas un faux
positif).
Le risque permet de lier les trois paramètres précédent par la formule suivante (4.1) et d’établir si une
alerte ou un groupe d’alertes est ”muté” en alarme :
Asset ∗ P riority ∗ Reliability
Risk = (4.1)
10
Le lien entre l’étape 6 et 9 de la figure 2.2 du chapitre 2 illustre la ”mutation” d’alertes/groupe d’alertes
en alarmes.
4.4 Menu Control Panel
Ce menu offre quatre différentes vues :

4.4.1 Metrics
Ce sous-menu affiche les informations relatives à l’algorithme CALM (décrit dans la section 2.3.3) de
manière globale ainsi que sur les réseaux définis par l’administrateur et les hôtes dont les niveaux A1
ou C2 sont élevés. Une visualisation graphique est offerte ainsi qu’un historique. Il est donc possible
d’observer les paramètres A et C de manière temps réel via cette interface.
CALM récupère toutes les alertes afin de les associer au niveau A et/ou C de l’hôte voulu sur un interval
de temps. Son fonctionnement est illustré par la figure 4.2 page 44 .
Il offre une vue rapide du nombre d’alertes détectées sur les hôtes du réseau. Par un clic sur l’icone
d’information, il est possible de générer un ticket permettant le dépos de commentaires sur le serveur au
sujet des niveaux observés (pour plus d’explications consultez la section 4.5.5). L’icone graphique offre
quant à lui (lors d’un clic sur celui-ci) un affichage des niveaux A et C de l’hôte ou réseau spécifié.
4.4.2 Alarms
Ce sous-menu offre une vue des alarmes détectées. En effet, les événements affichés contiendront uni-
quement des alarmes de haut niveau (niveau de risque supérieur ou égal à 2, calculés selon la for-
mule 4.1). Il est alors possible de cliquer sur le nom de l’alarme (champ Alarm) afin d’en observer plus
précisément les causes. Deux situations sont alors envisageables :
L’alarme provient d’une directive de corrélation (groupe d’alertes ayant un risque supérieur ou égal à 2)
Un menu permettant la visualisation des règles ”matchées” est affiché lors du clic sur le nom de
l’alarme. Dans cette nouvelle vue, il sera ensuite possible (via le lien Visualize alarm et une applet
Java3 ) d’observer graphiquement les trames, ayant généré l’alarme, transiter sur le réseau. Cette
reconstitution est effectuée à l’aide de la base de donnée Snort et des adresses IP contenues dans
les différentes alertes.
L’alarme provient d’une alerte de risque élevé (plus grand ou égal à 2) Le seul contenu pertinant pou-
vant être affiché sera le dump4 de celle-ci. Lors du clic sur le nom de l’alarme l’utilisateur sera
redirigé sur l’interface d’ACID (équivalent au sous-menu Alerts de ce menu). Un filtrage sera auto-
matiquement appliqué afin d’afficher uniquement les alertes provenant des mêmes adresses IP dans
la fenêtre temporelle de l’alerte. Il sera ainsi possible d’observer l’alerte ayant provoqué l’alarme
(risque plus grand ou égal à 2) ainsi que toutes les autres alertes de la même fenêtre temporelle.
Par défaut, toutes les alarmes ont un status (champ Status) OPEN. Cela signifie qu’aucun administrateur
en charge de la sécurité n’a analysé l’alarme ou n’a réussi à y trouver une solution. Plusieurs possibilités
s’offrent alors à lui :
1. Effacer l’alarme (il s’agit clairement d’un faux positif). L’alarme sera effacée à jamais...
1
niveau d’attaque auquel un système est sujet, mesure le risque potentiel dû aux attaques détectées
2
niveau de fiabilité d’une machine, mesure le niveau de probabilité qu’une machine soit compromise (hacker)
3
http ://scanmap3d.sourceforge.net/
4
Contenu brut de l’alerte Snort

2. Fermer le status de l’alarme (par un clic sur OPEN contenu dans le champ Status). Dans ce cas
l’alarme n’est pas effacée mais n’est plus directment affichée dans le menu Alarms. Afin de visua-
liser à nouveau les alarmes fermées (status CLOSED), il sera nécessaire de désélectionner l’onglet
Hide closed alarms
3. Générer un ticket permettant la saisie d’informations sur les actions entreprises par l’administrateur
en charge de la sécurité (par un clic sur l’icone d’information contenu dans le champ Action). Il
aura de plus la possibilité de modifier le status de l’alarme (OPEN ou CLOSED) afin d’indiquer
si le problème a pu être résolu ou non. Ce fonctionnement est particulièrement intéressant lorsque
plusieurs administrateur en charge de la sécurité travaillent sur le même framework OSSIM. Le
principe de génération de ticket et d’ajout d’informations au sujet d’une alarme est décrit plus en
détail dans la section 4.5.5.
Calcul du risque des alarmes
Le calcul du risque des alarmes (champ Risk de ce sous-menu) est opéré à l’aide de la formule 4.1.
Les valeurs des paramètres Priority et Reliability sont directement tirées du résultat de la corrélation (si
l’alarme est un output d’une corrélation, groupe d’alertes) ou de l’alarme unique (si l’alarme est une
alerte de niveau de risque supérieur à 2). Le calcul du risque est donc opéré de manière différente entre
les alertes (section 4.4.3) et les alarmes. En effet, dans le calcul du risque des alarmes, la valeur du
paramètre Asset sera la valeur la plus élevée entre la source de l’alarme (de l’attaque) et la destination de
celle-ci. Les autres paramètres (Priority et Reliability) restent quant à eux les mêmes que pour l’alerte
ou groupe d’alertes ayant généré l’alarme.
Comme dans le calcul du risque des alertes (section 4.4.3), la valeur de l’Asset (source et destination de
l’attaque) est en premier lieu récupérée dans les configurations des machines (sous-menu Hosts du menu
Policy) puis (si aucune valeur n’est configurée dans ce sous-menu) dans les configurations des réseaux
(établies dans le sous-menu Network du menu Policy).
4.4.3 Alerts
Ce sous-menu permet la visualisation des alertes générées (alertes brutes) par les différentes sondes
connectées au serveur ainsi que les résultats des corrélations qui ont abouties (règles matchées). En effet,
ce sous-menu permet la consultation de toutes les alertes récoltées par le serveur avant l’application des
différents procédés de corrélation sur celles-ci.
La valeur du risque (champ Risk) calculé pour chaque alerte est directement opéré à l’aide de la formule
4.1. Comme expliqué en section 4.3, les valeurs des paramètres Priority et Reliability utilisés dans le
calcul du risque sont propres aux alertes (configuré dans le sous-menu Plugins du menu Configuration).
La valeur de l’Asset utilisée pour le calcul du risque est celle configurée pour la machine de destination
ou, si celle-ci n’est pas configurée dans le sous-menu Hosts du menu Policy, celle configurée pour le
réseau auquel est connecté la machine de destination (configuré dans le sous-menu Network du menu
Policy).

Ce sous-menu est en fait d’une version quelque peu modifiée d’ACID5 . Il sera donc possible d’obtenir
des informations détaillées et précises sur les alertes via ce sous-menu. Pour de plus amples informations
sur l’utilisation d’ACID, 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 vulérabilités Nessus6 . Celle-ci permettra l’activation
du script /usr/share/ossim/scripts/do nessus.pl, qui procédera à l’interrogation de la base de données
d’OSSIM afin de déterminer quelles sont les machines et/ou réseaux à scanner (Les machines à scanner
sont configurées à l’aide du sous-menu Hosts du menu Policy). Le script do nessus.pl effectuera ensuite
le scan par l’appel du client nessus installé sur le serveur OSSIM. Les rapports de sécurités générés par
Nessus seront ensuite disponibles dans ce sous-menu.
Ce script s’occupe ensuite de remplir la table host plugin sid répertoriant les sid Nessus pour lesquels
chaque machine est vulnérable. Ce fonctionnement (cross-corrélation Nessus-Snort) est décrit plus en
détail dans la section 4.8.2.
4.5 Reports Menu
Ce menu offre cinq différents sous-menus en rapport avec la sécurité du réseau.
4.5.1 Host Report
Ce sous-menu permet d’observer les machines configurées dans le sous-menu Hosts du menu Policy. Il
est ainsi possible d’observer le hostname, l’Asset, l’IP et l’OS des machines configurées.
En cliquant sur le hostname de la machine voulue, il est possible d’accéder à différenes caractéristiques
et informations de celle-ci. Il sera ainsi possible d’observer les caractéristiques suivantes :
– Section principale
Inventory Inventaire de la machine (Nom, IP, Système d’exploitation, adresse MAC, Sensor ana-
lysant son trafic, Ports ouverts). Toutes les caractéristiques affichées sont celles configurées
par l’administrateur réseau, mis à part les ports ouverts. En effet, le plugin PADS7 permet la
détection des ports ouverts d’une machine uniquement par l’analyse des trames transitant sur
le réseau. C’est donc les informations fournie par PADS qui permettent l’identification des
ports ouverts de la machine en question.
En cliquant sur le mode Passive (mode de détection de PADS), le mode de détection des
ports passe en active. Il est alors possible d’observer la liste des ports ouverts à l’aide d’un
5
Analysis Console for Intrusion Databases, http ://acidlab.sourceforge.net/
6
http ://www.nessus.org/
7
Passive Asset Detection System, plugin décrit dans la section 3.6.

programme de scan actif (nmap). Le lien update permet quant à lui l’éxécution de nmap
(programme de scan actif) afin de mettre à jour la liste des ports ouverts.
Metrics Niveau ”A” et ”C” de la machine sélectionnée (niveaux calculés à l’aide de l’algorithme
CALM8 .
Usage Offre l’affichage graphique des informations fournies par Ntop9 . En effet, ce plugin met en
place un serveur web sur l’agent qui permettra l’affichage de toutes les données statistiques
récoltées par Ntop. Le lien (Usage) fournit donc uniquement une redirection vers le serveur
Web du plugin Ntop de l’agent voulu (agent analysant les informations de la machine en
question).
Anomalies permettant de visualiser la détection d’anomalies opérée par Ntop. Il s’agı̂t là des
résultats de l’analyse heuristique décrite 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, l’adresse de la machine en question.
Source Ce lien permet la visualistion des alarmes de haut niveau, ayant l’adresse de la machine
en question comme source.
Destination Ce lien permet la visalisation des alarmes de haut niveau, ayant l’adresse de la ma-
chine en question comme adresse de destination.
– Sous-section Alerts :
Main Ce lien permet l’affichage d’ACID10 , offrant un menu de navigation dans les alertes générées
par les différents plugins. L’affichage fourni par le lien Main, permet de connaı̂tre le nombre
d’occurence d’alertes 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 l’interface
d’ACID.
Src Unique alerts Ce lien affiche directement les alertes (via ACID) ayant l’adresse de la machine
en question comme source. Il est ensuite possible de continuer son investigation en cliquant
sur les liens offerts par l’interface d’ACID.
Dst Unique alerts Ce lien affiche directement les alertes (via ACID) ayant l’adresse de la ma-
chine en question comme destination. Il est ensuite possible de continuer son investigation
en cliquant sur les liens offerts par l’interface d’ACID.
– Sous-section Vulnerabilites :
Vulnmeter Ce lien offre une interface entre le framework et le scanner de vulnérabilités Nessus.
En effet, cette interface affiche le nombre de failles détectées sur toutes les machines scannées
en mettant en évidence (en rouge) le résultat de la machine en question. Il suffira ensuite de
cliquer sur l’adresse IP de la machine voulue afin d’observer le rapport de vulnérabilité de
celle-ci. Le lien update scan offre la possibilité d’effectuer un nouveau scan afin de mettre à
jour la liste des vulnérabilités de toutes les machines configurée pour un scan Nessus.
8
Principe décrit en section 4.4.1
9
Outil d’analyse temps réel du trafic réseau. Logiciel décrit 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 vulnérabilités de la machine en

question (équivalent au clic sur l’IP de la machine en rouge du lien Vulnmeter).
4.5.2 Security Report
Ce sous-menu offre une visualisation graphique, sans fenêtre temporelle, des niveaux ”A” (Top Atta-
cked) et ”C” (Top Attacker) de l’algorithme CALM (expliqué en section 2.3.3). Il permet d’observer 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 d’une machine, il sera
possible d’observer les alertes relatives à celle-ci dans ACID.
Le graphique Top 10 used ports offre une vision des ports de destination des alertes détectées. Il permet
ainsi de déterminer quels sont les services les plus attaqués. En cliquant sur le numéro de port voulu, il
est possibles d’observer toutes les alertes à destination de celui-ci (à l’aide de l’interface d’ACID).
Les informations fournies par Top 10 alerts offre simplement une vision textuelle et graphique des alertes
les plus rencontrées, alors que Top 10 alerts by Risk offre une vision des alertes les plus rencontrées ayant
un risque élevé.
4.5.3 PDF Report
Ce sous-menu permet la récupération de rapports PDF. Il est ainsi possible de récupérer 3 différents
rapports PDF, comportant chacun des informations spécifiques :
Security Report Permettant la génération d’un document PDF identique au sous-menu Security Report
(Section 4.5.2)
Metrics Report Permettant la génération d’un document PDF, offrant une vue numérique des niveau
”A” et ”C” de l’algorithme CALM11 en fonction des fenêtres temporelles sélectionnées.
Incident Report Permettant la génération d’un document PDF, offrant le résumé des incidents reportés
par les gestionnaires du réseaux (personnes physiques) utilisant OSSIM (sous-menu Incident,
menu Reports)
4.5.4 Anomalies
Ce sous-menu offre l’affichage des résultats de l’algorithme 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 déposés par les différents administrateurs en charge
de la sécurité. En effet, ce sous-menu permet de déposer des annotations sur les activités effectuées ainsi
que de fermer les alarmes/problèmes ayant été résolus (principe de fermeture d’alarmes expliqué en
section 4.4.2).
Différents sujets d’archivages sont dipsonibles :
OSSIM Permettant de déposer des commentaires sur des alarmes spécifiques (ticket ALA) ou sur des
métriques marginaux (ticket MET). Il s’agit donc du menu dans lequel l’utilisateur est renvoyé
lorsqu’il clic sur l’icone d’information dans le sous-menu Metrics ou Alarms du menu Control
Panel.
Hardware Permettant de déposer des commentaires sur le hardware d’OSSIM et des problèmes ren-
contrés sur celui-ci.
Install Permettant de déposer des commentaires sur l’installation de nouveaux agents et/ou plugins.
Un outil de recherche intégré dans la page Web d’incidents, permettra de retrouver et trier les commen-
taires sur la base de mots clés. Celui-ci propose plus ou moins de champs de recherche (Filter Advenced
ou Filter simple). Après avoir sélectionné son sujet d’archivage il sera possible d’ajouter de nouveaux
commentaire en cliquant sur lien Insert new Incident.
Vous pourrez ensuite compléter les champs offerts et ajuster le niveau de priorité de l’incident (commen-
taire).
4.6 Monitor Menu
Cette section offre une représentation graphique de l’état du réseaux et des différents agents placés sur
celui-ci.
4.6.1 Riskmeter
Ce sous-menu offre uniquement l’affichage de l’algorithme CALM12 . Il s’agit donc d’une représentation
réduite 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 l’ont été récemment). Cette visualisation
fait appel à l’outil Ntop (explications technique en section 3.3). En effet, celui-ci répertorie toutes les
connexions TCP qu’il apperçoit 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 l’agent) une liste de connexions détectées.
Cette sous-section offre ensuite la possibilité de visualiser ces informations en fonction d’une sonde
(agent Ntop) ou en fonction d’un réseau. Plusieurs comportements sont alors possibles :
En fonction d’une sonde Ce sous-menu affiche simplement la page web fournie par le serveur web
Ntop de la sonde en question.
En fonction d’un réseau Ce sous-menu affiche toutes les informations disponibles sur les sessions TCP
des hôtes situées sur le réseau en question.
Pour ce faire, le framework effectuera un scan Nmap13 de tout le réseau en question. Pour chaque
machine découverte, il déterminera avec quelle sonde celle-ci est associée (association effectuée
dans le sous-menu Hosts du menu Policy, champ Sensors). Une fois les associations résolues, il
interrogera les serveur web Ntop des sondes en question afin de récupérer les informations sur les
sessions TCP des machines voulues. Il générera ensuite une page web à l’aide des informations
récoltées.
4.6.3 Network
Cette sous-section fait simplement appel à l’interface web fournie par les sondes hébergeant un agent
Ntop. Il est ainsi possible de sélectionner l’agent sur lequel l’on désire se connecter puis de choisir le
genre d’informations désirées. Ces informations sont donc relative à la sonde Ntop (réseau sur lequel
celle-ci est placée) et non pas à un hôte ou un réseau spécifique.
Étant donné que ce sous-menu fait appel à l’interface 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 installés sur les différents agents actifs. A
l’aide de celle-ci, il sera possible d’arrêter ou de désactiver le plugin à distance (lien stop ou disable). La
désactivation du plugin engendrera son non activation lors d’un redémarrage de l’agent alors que l’arrêt
n’aura aucune inscidence lors d’un redémarrage de l’agent. Lorsqu’un plugin est arrêté ou désactivé, il
est possible de le redémarrer ou le réactiver à l’aide de ce sous-menu (lien start ou enable).
4.7 Policy Menu
Ce menu offre une interface de configuration du réseau à surveiller. En effet, il est nécessaire d’indiquer
les plages d’adresses IP des réseaux à analyser ainsi que les hôtes à surveiler. Les explications ci-dessous
seront succintes puisque le document suivant : http ://www.ossim.net/docs/User-Manual.pdf offre déjà
des explications complètes à ce sujet.
13
Outil de scan réseaux

4.7.1 Hosts
Ce sous-menu permet la configuration des machines à surveiller. En effet, il est possible de définir l’im-
portance de la machine (champ asset), les seuils d’alerte pour l’algorithme CALM associé à la machine
(champ Threshold A et Threshold C), le profile RRD utilisé pour l’analyse heuristique sur la machine en
question (détection de dépassement de seuils et algorithme Holt-Winter) champ RRD Profile, le ou les
agents étant capable de récupérer (sniffer) les informations réseaux de la machine (champ Sensors), le
type de scan à effectuer (champ Scantype).
4.7.2 Networks
Ce sous-menu permet la définition des réseaux à surveiller. En effet, il est possible de définir la plage
d’adresses du réseau (champ IPs), l’importance de celui-ci (champ asset), les seuils d’alerte pour l’al-
gorithme CALM associé au réseau (champ Threshold A et Threshold C), le profile RRD utilisé pour
l’analyse heuristique sur le réseau en question (détection de dépassement de seuils et algorithme Holt-
Winter) champ RRD Profile, le type de scan à effectuer (champ Scantype).
4.7.3 Network groups
A l’aide des configurations des réseaux défini précédemment (section 4.7.2), il est possible à l’aide de ce
sous-menu de définir des groupes de réseaux ayant des caractéristiques communes.
4.7.4 Sensors
Ce sous-menu permet l’ajout et la configuration d’un agent. Il sera ainsi possible de définir l’importance
de celui-ci (champ asset).
4.7.5 Signatures
Ce sous-menu permet la création 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 création 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 différents sous-menus :

4.8.1 Directives
Ce sous-menu permet la visualisation des règles de corrélation définies sur le serveur OSSIM. Celles-
ci sont appliquées de manière temps réel aux alertes arrivant sur le serveur. Ces règles permettent la
création d’un diagramme d’états définissant les alertes à matcher afin de lever une alerte de haut ni-
veau (groupe d’alertes). Ce principe de fonctionnement est expliqué dans la section 2.3.3, paragraphe
Corrélation par diagramme d’états. Ces alertes de haut niveau seront ensuite stockées dans le sous-
menu Alerts du menu Control Panel. Étant donné que la quasi totalité d’entre elles fournissent un niveau
de risque supérieur à 2 (provenant de la configuration d’une priorité souvent élevée dans les directives de
corrélation), ces alertes de haut niveau seront ”mutées” en alarmes et affichées dans le sous-menu Alarms
du menu Control Panel.
La configuration et l’établissement des directives de corrélation sont détaillés dans l’annexe I.
4.8.2 Cross Correlation
Ce procédé permettra d’augmenter la priorité d’une alerte Snort lorsque l’attaque définie par celle-ci aura
été découverte comme possible par Nessus. Les associations entre les alertes de Snort et les sid des règles
NASL14 de Nessus sont affichées dans ce sous-menu (affichage correspondant à la table plugin reference
de la base de donnée d’OSSIM). Les différentes colonnes affichées on les significations suivantes :
Plugin id Identification du plugin qui va être associé avec un script NASL Nessus. Il s’agı̂t, pour le
moment, uniquement du plugin Snort.
Plugin sid Identification de l’événement du plugin (Plugin id) qui va être associée avec un script NASL
Nessus. Il s’agı̂t, pour le moment, uniquement de règles Snort.
Reference id Identification du plugin de référence (Nessus en l’occurence).
Reference sid Identification de l’événement associé au plugin de référence (script NASL).
Ces informations représentées normalement sous forme numérique sont simplement remplacées par leurs
définition textuelle contenue dans la base de donnée OSSIM.
Le script do nessus.pl exécuté lors d’un scan Nessus (section 4.4.4) s’occupe ensuite de remplir la table
host plugin sid répertoriant les sid Nessus pour lesquel chaque machine est vulnérable. Une fois ces
informations connues, le moteur de cross-corrélation pourra rechercher pour chaque alerte reçue, son
existance dans la table plugin reference. Si un tel événement est répertorié dans cette table, le moteur de
corrélation pourra en tirer le plugin sid de Nessus correspondant. Il pourra ensuite, rechercher dans la
table host plugin sid l’existance de ce sid de Nessus pour la machine cible de l’alerte. Si un tel sid est
présent, la priorité et la fiabilité (reliabiliy) de l’alerte Snort seront modifiés de la sorte :
Fiabilité Addition de la fiabilité de la ”règle” Nessus matchée et de la règle Snort
Priorité La valeur maximale entre la priorité de la ”règle” Nessus matchée et la règle Snort
14
Nessus Attack Scripting Language, language permettant d’établir des règles de test Nessus

L’alerte sera ensuite automatiquement mutée 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 répertorie les ”paquetages” de backlog des alarmes provenant d’une directive de corrélation.
En effet, lorsqu’une alarme est levée suite à l’aboutissement (complet ou partiel) d’une directive de
corrélation cela signifie que plusieurs alertes ont été matchées par la directive. Le ”paquetage” de l’alarme
contient alors les références 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 l’alarme résultant d’une corrélation 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 paramètres d’OSSIM.
4.9.1 Main
Ce sous-menu offre une interface de configuration globale d’OSSIM. En effet, le framework, les agents
et leurs plugins récupèreront ces différentes informations. Ce sous-menu se décompose en plusieurs
sections :
Language Configuration de la langue du framework et des préférences d’affichage locale dir.
Fonctionnalité pas encore implémentée
Server Configuration des caractéristiques réseau du serveur (adresse IP et port).
Snort Configuration des caractéristiques propres à Snort (base de données, login et chemin d’accès)
Metrics Configuration du seuil d’alerte (threshold) lors d’un dépassement des métriques (algorithme
CALM), ainsi que du débit de sortie des alertes de l’accumulateur CALM (recovery).
phpGACL Configuration de la base de donnée des règles ACL (Access Control List) permettant la
gesion des utilisateurs et d’accès d’OSSIM.
PHP Configuration des chemins des libraires php.
Le champ use svg graphics initialisé à yes permet l’affichage graphique du thermomètre du sous-
menu Metrics du menu Control Panel. Celui-ci nécessite l’installation d’un plugin sur le navigateur
client (plugin SVG).
Le champ use resolv initialisé à yes offre la résolution de noms pour les adresses IP affichées par
OSSIM.
RRD Configuration des chemis vers les librairies graphiques et scripts permettant la génération des
graphiques d’OSSIM (Metrics, etc...)
Links Configuration du chemin web (URI) d’OSSIM (ossim link) ainsi que celui de Ntop et Opennms.

Backup Configuration de la base de données de backup (fonctionnalité pas encore implémentée, puisque
les backups sont sauvgardées dans des fichiers .sgl.gz)
Nessus Configuration du user/login utilisé par le client Nessus pour effectuer les scans, ainsi que de
l’hôte hébergant 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 l’utilisation
HTTPS d’ACID. Configuration de la paire user/pass d’OSSIM permettant la connexion à l’inter-
face Web du framework.
External applications Configuration des chemins complets vers les applicatifs utilisés par le serveur
OSSIM. Le champ have scanmap3d permet l’activation ou non de l’affichage 3D des alertes Snort
(explications en section 4.4.2)
4.9.2 Users
Ce sous-menu permet la création de comptes utilisateurs pour l’interface web d’OSSIM. En effet, il est
possible de créer différents comptes ayant différents droits d’accès. Il sera ainsi possible de définir pour
chaque utilisateur, les menu et sous-menu qu’il sera autorisé de visualiser.
4.9.3 Plugins
Ce sous-menu offre l’affichage de la liste des plugins offerts par OSSIM. Chaque événement de chaque
plugin est indexé à l’aide d’un sid (identifiant unique pour les événements du plugin). Il sera ainsi pos-
sible de référencer chaque événement à l’aide d’une pair id/sid où id est l’identifiant du plugin et sid
l’identifiant de l’événement pour le plugin sélectionné. Cette méthode de référencement des événements
permettra l’utilisation de ceux-ci dans des directives de corrélation. Plus d’informations sur leur utilisa-
tion dans les directives de corrélation en section I.
4.9.4 RRD config
Ce sous-menu permet l’établissement de profils RRD utilisés par le plugin RRD des agents OSSIM. Le
principe de fonctionnement de ce plugin a été abordé dans la section 3.3.1 lors de la présentation de
l’outil d’analyse Ntop. Ce plugin effectuera deux types d’analyses sur chaque agent OSSIM :
1. Analyse heuristique : Utilisation d’un algorithme de lissage exponentiel (Holt-Winter) pour la
prédiction de valeurs (valeurs fournies par Ntop). Des explications détaillées sur l’analyse heuris-
tique Holt-winter est fournie en annexe J.
2. Détection de dépassement de seuils : Comparaison des seuils configurés avec les valeurs courantes
fournies par Ntop.
Les profils créé à l’aide de ce sous-menu pourront ensuite être utilisés dans les polices de sécurité des
machines et des réseaux définis à l’aide du framework. Il sera ainsi possible d’appliquer le profile sou-

haité sur ces éléments.
Les attributs représentent les informations fournies par Ntop (compteurs de bytes, etc...). Sur chacun
d’eux, il est possible de définir des seuils (threshold) afin d’être averti (génération d’une alerte rrd threshold
affichée dans le sous-menu Alerts du menu Control Panel) lorsqu’un compteur dépasse le seuil indiqué.
Les paramètres alpha et beta sont quant à eux propres à l’algorithme heuristique Holt-winter. Les alertes
générées par cet algorithme (rrd anomaly) seront ensuite visibles dans le sous-menu Anomalies du menu
Report. Elles n’apparaı̂tront donc jamais dans le même sous-menu que les alertes de types rrd threshold.
Paramètres de configuration à disposition
Attribute Nom du paramètre (compteur Ntop) pour lequel la ligne de configuration s’applique.
Threshold Seuil que l’attribut devra atteindre pour qu’une alerte rrd threshold soit générée.
Priority Priorité de l’alerte rrd threshold entrant de le calcul du risque effectué par le serveur lors de la
réception de l’alerte (priorité non associée aux alertes de type rrd anomaly).
Alpha Paramètre alpha de l’algorithme heuristique Holt-winter générant une alerte de type rrd anomaly.
Beta Paramètre beta de l’algorithme heuristique Holt-winter générant une alerte de type rrd anomaly.
Persistence Nombre de fois qu’un dépassement de seuil ou qu’une anomalie doit être aperçue pour
l’attribut en question afin qu’une alerte rrd threshold ou rrd anomaly (suivant le cas) soit générée.
Enable Activation ou non de l’attribut dans le profile.
Il est important de noter que le plugin RRD effectue périodiquement (chaque 300 secondes) l’analyse des
données fournies par Ntop (stockée dans la base de donnée tourniquet RRD). Le paramètre persistence
se base donc sur cette granularité afin de décider de la génération d’une alerte. En effet, si celui-ci est
configuré à 3, il faudra que trois contrôles successifs des valeurs (anomalie et/ou seuil) soit supérieur aux
valeurs autorisées afin qu’une alerte soit générée (alerte rrd anomaly et/ou rrd threshold). Cela signifiera
qu’un dépassement aura été observé durant au moins 15 minutes.
Configuration
L’unité des attributs (pour la configuration des seuils) n’est malheureusement pas indiquée sur l’interface
de configuration. Certains attributs sont exprimés de manière relative alors que d’autres de manière ab-
solue (par exemple : bit/s et bit). Afin de connaı̂tre l’unité utilisée par chaque attribut, il est préférable de
consulter leurs graphiques via Ntop. En effet, l’unité est indiquée verticalement sur la gauche des graphs.
Les valeurs configurées pour les seuils sont utilisées pour des périodes de 5 minutes (par défaut). 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 paramètres propres à l’algorithme Holt-Winter sont expliqués dans l’annexe J.
Tous ces paramètres permettent l’adaptation de la détection de seuils et de l’algorithme heuristique Holt-
Winter en fonction du segment réseau à surveiller.
ATTENTION : OSSIM Version : 0.9.8rc2 contient des erreurs d’implémentation sur l’utilisation de
Holt-Winter par rrd plugin.pl ! !
4.9.5 Host scan
Ce sous-menu permet la visualisation des hôtes à scaner à l’aide de Nessus ou Nmap.
4.10 Tools Menu
Ce menu offre trois différents sous-menus :
4.10.1 Net Scan
Ce sous-menu fait office d’interface avec le programme Open Source de scan réseaux nmap. Il permettra
ainsi de scanner l’un des réseau définit dans le sous-menu Network du menu Policy ou d’indiquer ma-
nuellement la plage d’adresses à scanner.
Une fois le scan opéré, il sera possible d’insérer ou mettre automatiquement à jour la configuration (du
sous-menu Hosts du menu Policy) des machines détectées en cliquant sur le bouton update database
values.
4.10.2 Rule viewer
Ce sous-menu offre simplement une interface de consultation des règles Snort. En effet, il peut être
intéressant d’observer la syntaxe d’une règle plutôt que son nom. Pour l’utilisation de cette fonctionna-
lité, il sera nécessaire d’installer (copier) la totalité des règles Snort dans le répertoire /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 journalièrement les vieilles alertes contenues dans ACID permat-
tant ainsi de limiter le temps de recherche des alertes dans la base de données. Ce sous-menu affichera
14
http ://www.insecure.org/nmap/

donc les fichiers de backup contenu dans le répertoire /var/lib/ossim/bakup/ du serveur et permettra de
réinsérer des backups précédentes afin de retrouver des événements déjà archivés. Inversement, il sera
aussi possible de retirer les données réinsérées dans la base de données.

F IG . 4.1 – Arborescence des menus d’OSSIM

F IG . 4.2 – Principe de d’accumulation des alertes opéré par CALM

Chapitre 5
Conclusion
OSSIM se révèle être une solution proposant des concepts d’analyses très innovateurs. En effet, peu de
solutions Open Source proposent actuellement une telle palette de procédés d’analyse d’événements de
sécurité :
– Récupération d’événements d’infrastructures hétérogènes (alertes de NIDS, logs, etc...).
– Attribution d’une sévérité à chaque événement en fonction de l’attention que l’on porte au bien
potentiellement attaqué (priorization des alertes).
– Corrélation croisée (Nessus - Snort) permettant la modification de la sévérité des alertes en fonc-
tion des vulnérabilités de la cible de l’attaque potentielle.
– Analyse comportementale du réseau permettant la génération d’alertes en fonction du comporte-
ment des utilisateurs (Ntop et l’algoritme Holt-Winter de RRD).
– Corrélation des événements et intégration des événements de l’analyse comportementale dans ce
procédé.
Étant toujours en développement, OSSIM reste malheureusement encore non utilisable dans un envi-
ronnement de production. En effet, son installation et les tests préliminaires semblent encore poser pas-
sablement de problèmes. Les développeurs d’OSSIM ont principalement concentré leurs efforts sur les
procédés d’analyse (encore inexistant sur des solutions Open Source). Leurs conceptes innovateurs re-
posent dès lors sur des bases quelques peu instables et difficiles à faire co-exister.
En terme de concepts et de procédés d’analyse, OSSIM n’a rien à envier aux solutions commerciales
d’envergure 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 sécurité (http ://www.exaprotect.com/fr/eas-
1.jsp) jusqu’à peu, basée sur Prelude-ids une solution Open Source de grande qualité.
La solution Open Source Prelude-ids (http ://prelude-ids.org), étudiée et utilisée dans les deux premières
phases du projet SIMS, offre quant à elle des fonctionnalités de détection (Snort et récupération de
45
logs), centralisation et normalisation (IDMEF1 ) très robustes. En effet, l’équipe Prelude-ids a concentré
ses efforts sur le rapatriement d’événements de sécurité avec la triade CIA (Confidentiality, Integrity,
Availability) comme ligne directrice. Ce projet de grande qualité n’offre malheureusement encore aucune
solution avancée d’analyse des données, bien que l’intégration d’un outil de corrélation 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
d’Ossim-server
Ce chapitre décrit toutes les étapes d’installation d’un 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 Prérequis
Disposer d’une machine Linux Debian ayant un noyau 2.6.xx. Avoir configuré le manager de paquets
Debian (aptitude) afin qu’il récupère ceux-ci sur le site Web d’Ossim (cf. Section B.1.1).
A.2 Installation
Installation de la base de donnée MySql-Ossim :
# apt-get install ossim-mysql
Création du compte root et mise en place de son mot de passe :
# mysqladmin -u root password your_secret_password
Vous pouvez ensuite éditer le fichier /etc/mysql/my.cnf afin de choisir l’adresse IP (bind-address) associée
au serveur MySql.
La création des bases de données s’opère simplement à l’aide 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 s’effectuer à l’aide 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 corrélation et récupération des données des agents) :
# apt-get install ossim-server
Installation du framework (interface Web) ainsi que du paquetage de la gestion des droits d’accès 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 donnée Ossim :
# apt-get install ossim-utils
Installation de Nessus (pour la détection des vulnérabilités). Installation du serveur Nessus :
# apt-get install nessusd
Il est aussi possible de directment télécharger la dernière archive d’installation sur http ://www.nessus.org/download/.
En effet cette dernière version de Nessus (v.2.2.5) offre la possibilité de mettre à jour automatiquement les
règles Nessus via un simple enregistrement sur http ://www.nessus.org/. Vous devrez ensuite simplement
suivre les instructions données par le script d’installation. A l’aide de l’installation par défaut, 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, exécuté par le framework
lors d’une demande de scan) pour l’exécution des scan nessus :
# apt-get install nessus

A.3 Configuration
A.3.1 Ossim plate-forme
Tous les paquetages intallés ci-dessus offrent une configuration garphique ncruses à l’installation. Celle-
ci peut être effectuée à la demande via la commande :
# dpkg-reconfigure <nomDuPaquetage>
L’adresse IP du serveur ainsi que les nom d’utilisateurs et mots de passes des bases de données seront
nécessaire. Il convient donc ensuite de créer ces utilisateurs. Si nous choissons de nous connecter aux
bases de données à l’aide d’un utilisateur nommé ossim ayant comme mot de pase ossim pass, il sera
nécessaire d’opérer ainsi afin d’ajouter cet uilisateur sur les différentes bases de données :
# 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 privilèges à l’utilisateur ossim sur les bases de données nécessaires (soit ossim,
snort et ossim acl).
Pour une configuration graphique, il suffira d’installer 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
l’interpréteur PHP afin que le site d’Ossim puisse fonctionner. Ceci s’opère via la commande suivante :
# apache-modconf apache enable mod_php4
La configuration d’Ossim se situe dans /etc/apache/httpd.conf/conf.d/ qui est importé dans le fichier de
configuration principal d’Apache. Le fichier de configuration d’Apache pour Acid2 n’est par contre pas
directement fourni dans ce répertoire. Il est donc nécessaire de le copier afin qu’Apache soit capable de
servir les pages web d’Acid :
2
Viewer pour les alertes Snort et Ossim

# cp /etc/acidlab/apache.conf /etc/apache/conf.d/acid.conf
Il est ensuite nécessaire de modifier la configuration par défaut d’Apache pour Ossim, afin que celui-ci
soit capable de suivre les liens symboliques. En effet, un lien symbolique est utilisé pour l’affichage
des vulnérabilités découvertes à l’aide de Nessus. Il faut donc ajout l’option suivante dans le fichier
/etc/apache/conf.d/ossim.conf (à la suite des options déjà définies) :
Options FollowSymLinks
A.3.3 Nessus client-serveur
Il est nécessaire d’ajouter un user au serveur Nessus afin le framework (script do nessus.pl) puisse l’uti-
liser pour exécuter des scans. Ceci s’opère sur le serveur à l’aide de la commande nessus-adduser. Il
suffira ensuite de compléter 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 règles de tests (contenues dans Nessus) sur le framework.
Le script update nessus ids.pl s’occupe de ça (via l’utilisation du client Nessus et des informations confi-
gurées ci-dessus) :
# /usr/share/ossim/scripts/update_nessus_ids.pl
A.3.4 Cross corrélation via Nessus
Pour que l’ajustement des priorités des alertes en fonction des vulnérabilité de la machine cible (vulnérabilités
détectées par Nessus) soit possible, il est nécessaire de mettre à jour les relations entre les alertes Snort et
les règles NASL3 Nessus (relations enregistrées dans la table plugin reference de Mysql). Ces relations
sont contenues dans l’archive snort nessus.sql.gz qu’il faut fournir au client mysql afin que celui-ci mette
à jour la base de donnée d’Ossim :
3
Nessus Attack Scripting Language, language permettant d’établir des règles de test Nessus

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

Annexe B
Ajout et configuration d’une sonde Snort
Les manipulations décrites ci-dessous requièrent un serveur Ossim opérationnel (installation décrite dans
la section A).
B.1 Installation
B.1.1 Snort
Son installation sur une distribution Debian (via apt-get) implique l’ajout d’une source de download afin
de récupérer l’application Snort directement patchée. Il est nécessaire d’ajouter la ligne suivant dans
/etc/apt/source.list afin que le gestionnaire de paquets de Debian (aptitude) soit capable de récupérer les
paquetages d’Ossim :
deb http://www.ossim.net/download/ debian/
Il est ensuite nécessaire de créer un fichier de préférences /etc/apt/preferences afin que Debian aille en
premier lieu rechercher les paquetages disponibles sur Ossim plutôt que ceux disponibles sur d’autres
serveurs. Nous serons ainsi certain d’obtenir la version patchée de Snort :
Package: *
Pin: release o=ossim
Pin-Priority: 995
Après la mise à jour des paquetages disponibles, il est possible de downloader Snort :
# apt-get update
# apt-get install snort-mysql
Pour plus d’informations à ce sujet, consultez : http ://www.ossim.net/docs/INSTALL.Debian.html#d0e783
52
B.1.2 Ossim-agent
Maintenant qu’aptitude est capable de récupérer des paquets sur les serveurs d’OSSIM, il suffit de taper
la commande suivante afin d’installer Ossim-agent :
# apt-get install ossim-agent
L’installeur de paquets de Debian va maintenant vous questionner afin de créer une configuration de
base. Reportez-vous à la section suivante (section B.2.2) pour plus de détails.
B.2 Configuration
B.2.1 Snort
Comme mentionné plus haut, le logiciel de détection d’intrusion Snort utilise son plugin de sortie Mysql
afin de transmettre directement ses alertes en direction d’une des bases de données d’Ossim-server (Snort
BD). Celui-ci disposera alors de tous les détails de chaque alertes levée par la sonde.
Le second plugin de sortie utilisé est ”logfile=fast.log”. Il s’agı̂t d’un plugin développé par OSSIM très
proche de ”alert full”1 directement intégré à Snort. Fast.log place simplement les différentes alertes dans
un fichier de logs qui sera ensuite lu par l’agent Ossim qui s’occupera de transmettre ces informations
vers le serveur Ossim (permettant ainsi l’analyse temps réel).
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 donnée
Snort distante. Il est donc nécessaire de créer un nouvel utilisateur sur celle-ci afin que la sonde puisse
s’y connecter à l’aide du mot de passe indiqué. L’ajout d’un utilisateur sur la base de donnée Snort
sera détaillé ci-dessous (section B.3). De plus, il est indispensable de retirer le script de démarrage
automatique de Snort afin que la sonde puisse être directement activée par le Serveur (via Ossim-agent).
Ceci s’opère à l’aide de la commande suivante :
# update-rc.d -f snort remove
Mise à jour des règles sur le serveur Ossim
La mise à jour des règles Snort permet l’utilisation de celles-ci dans les scénarii de corrélation. En
effet, le menu de ”Correlation - Directives” du framework permet l’utilisation des alertes Snort dans
1
fast.log ajout simplement deux paramètres supplémentaire à alert full afin d’augmenter les performances du serveur. Info
sur : https ://sourceforge.net/forum/message.php ?msg id=2627915

la définition de scénarii de corrélation. L’utilisation du SID des alarmes permet de les référencer dans
les règles de corrélation. Celui-ci doit donc être unique pour chaque plugin. Il convient donc lors de
création de règles Snort de ne pas les dupliquer (un contrôle est quand même effectué par le script
/usr/share/ossim/scripts/create sidmap.pl de mise à jour des règles dans la base de donnée du serveur
Ossim). La mise à jour des règles sur le serveur Ossim requiert le client Mysql puisque le script procède
au contrôle de la duplication des règles et fournit les commandes SQL à entrer dans le client. Ce script
doit évidemment être exécuté sur l’agent hébergeant la sonde Snort. Installation du client mysql :
# apt-get install mysql-client
Lancement du script de mise à jour à l’aide d’un simple pipe vers le client mysql configuré pour un
connexion vers la base de donnée du serveur Ossim (à écrire 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 bénéficier des droits suffisants pour la com-
mande Sql INSERT.
Pour que l’insertion se passe correctement (avec l’enregistremenent du champ msg des règles Snort dans
la base de donnée Ossim), il est nécessaire que le champ classtype soit présent dans la règle Snort.
Effacer des règles de plugins dans Ossim Pour se faire, il est nécessaire de directement ”taper”
dans la base de donnée d’Ossim. Il sera alors nécessaire d’utiliser un client Mysql (mysql-client ou
phpMyAdmin). Via mysql-client, il suffira de se connecter à la base de donnée à l’aide d’un user ayant
les droits Delete, et de taper la requête 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 s’effecture directement à l’aide du menu de configuration des paquets Debian et peut
être reconfiguré à volonté à l’aide de la commande :
# dpkg-reconfigure ossim-agent
La configuration requiert (dans l’ordre d’apparition) :

1. L’adresse IP de l’agent
2. L’interface réseau à utiliser (pour la communication avec le serveur)
3. L’adresse IP du serveur OSSIM
4. Les plugins qui vont être connecté à cet agent. Dans notre cas, uniquement Snort (illustré à la
figure B.1)
L’exécutable de l’agent Ossim est ensuite directement lié dans les runlevels appropriés afin qu’un démarrage
automatique s’effectue 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 d’Ossim-server pour une nouvelle sonde Snort
La procédure d’ajout d’un nouveau sensor doit être effectué via l’interface Web du serveur Ossim. Celle-
ci est décrite dans le manuel disponnible à l’URL suivante : http ://www.ossim.net/docs/User-Manual.pdf
Lors de l’ajout d’un sensor local (agent placé sur le serveur Ossim), il faudra bien prendre garde de
spécifier correctement l’adresse du serveur Ossim dans la configuration de l’agent (/etc/ossim/agent/config.xml).
En effet, pour une bonne génération des liens HTML du framework, il sera nécessaire de ne pas spécifier
l’adresse de loopback du serveur comme serverip.
<serverip>Adr_ip_non_loopback</serverip>
L’ajout d’une nouvelle sonde Snort implique l’ajout de droit d’accès dans la base de donnée snort afin
que cette nouvelle sonde (=nouvel utilisateur) soit capable d’y déposer directement ses alertes (comme
illustré sur la figure 3.1). Il est donc nécessaire de se trouver sur la machine serveur afin d’y entrer les
requêtes SQL pour l’ajout d’un utilisateur.
Lancement du client Mysql local et utilisation de la base de donnée snort :
# mysql -u root
mysql> use snort;
Requêtes SQL à entrer pour l’ajout d’un 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’;

L’utilisateur snort provenant de sensorIP a maintenant un accès total à la base de donnée 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 l’agent Ossim est configuré et que la base de donnée snort est accessible depuis celui-ci,
nous pouvons tester le fonctionnement de l’agent (le serveur doit être en marche).
Il est maintenant possible de démarrer l’agent Ossim (en mode de debug afin de contrôler son bon fonc-
tionnement) à l’aide de la commande suivante :
# ossim-agent -v -f
Les logs suivants doivent alors apparaı̂tre 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 exécuter l’agent Ossim en tâche de fond :
# ossim-agent -d
Votre nouvelle sonde Snort est prête à l’emploi !
B.4.1 Erreur de démarrage de l’agent Ossim
Il se peut que l’erreur 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 récupère l’agent (pour l’envoi temps réel des infor-
mations au serveur), n’a pas été trouvé. Il est alors nécessaire de modifier la configuration du plugin

Snort afin d’y indiquer le bon chemin (le bon fichier de log). Celle-ci est décrite dans le fichier XML
/etc/ossim/agent/plugins/snort.xml. Il est indispensable de modifier la balise location afin d’y indiquer
l’emplacement réel du fichier de log de Snort (généré 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 décrites ci-dessous requièrent un serveur Ossim opérationnel, ainsi qu’un agent Ossim
installé sur la machine qui hébergera Ntop (l’installation de l’agent est décrite dans la section B.1.2
puisqu’il s’agı̂t, dans notre cas, du même agent que pour la sonde Snort).
C.1 Installation
C.1.1 Ntop
Installation de Ntop et des librairies nécessaires :
# apt-get install librrd0 ntop
Installation du paquetage ossim-utils fournissant le script d’analyse des informations de Ntop

(/usr/share/ossim/scripts/rrd plugin.pl) ainsi que le fichier de configuration nécessaire pour l’interroga-
tion de la base de donnée Ossim par rrd plugin.pl (permettant la récupération de la configuration des
seuils défini par l’administrateur réseau sur le framework) :
# apt-get install ossim-utils
Pour les détails de la configuration de ce paquetage consultez la section C.2.2.

Installation des outils utilisés par le script rrd plugin.pl pour la récupération des informations dans la
base de donnée 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 d’une interface Web pour le monitoring ainsi que
pour sa configuration. Le serveur Web s’installe par défaut sur le port 3000. Il est maintenant nécessaire
de configurer le format des logs de sortie (plugin RRD) afin que le script rrd plugin.pl soit capable de les
récupérer via l’outil RRDtool. Pour ce faire il suffit de se rendre à l’URL suivante : http ://yourhost :3000/
et d’activer le rrdPlugin dans Admin - plugins. En cliquant sur rrdPlugin le menu de configuration de
celui-ci devient éditable. Vous pouvez maintenant cliquer sur Host dans le menu Data to Dump puis
entrer votre masque de sous-réseau dans Hosts Filter. Il est encore nécessaire de contrôler que le RRD
Files Path soit le même que celui fournit dans le framework de configuration (Configuration - Main -
rrdpath ntop). En effet le script Perl rrd plugin.pl récupère la configuration des seuils sur le framework,
ainsi que les chemins d’accès aux fichiers de logs.
Il est ensuite nécessaire de modifier le fichier /etc/default/ntop afin d’y mettre –no-mac comme GE-
TOPT :
GETOPT="--no-mac"
Le script d’analye et de comparaison des seuils (rrd plugin) sera maintenant capable de récupérer les
données de la base de donnée tourniquet afin de les analyser.
C.2.2 L’agent Ossim
Ossim-utils
Ce paquetage contenant le script rrd plugin.pl met à disposition le module perl /usr/lib/perl5/config.pm
permettant de récupérer la configuration établie dans le framework (configuration établie dans Configu-
ration - Main). Il est nécessaire de configurer correctement ce paquetage afin que ce module soit capable
de se connecter à la base de donnée distante. Il faudra lui indiquer un utilisateur Mysql, capable de se
connecter depuis l’agent Ossim. Dans notre cas, nous indiquerons l’utilisateur snort précédemment confi-
guré (cf. section B.3). Éditée 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 être aisément éditée à l’aide de dpkg via la commande suivante :
# dpkg-reconfigure ossim-utils
Ossim-agent
Le script rrd plugin.pl récupère de lui même (sans appel à config.pm) les informations relatives à la
configuration des seuils dans la base de donnée Ossim distante. Il est donc nécessaire de lui indiquer
correctement les mêmes informations que ci-dessus. Celles-ci sont visibles comme ”variables globales”
dans la configuration de l’agent (/etc/ossim/agent/config.xml) et sont ensuite utilisées par certains plugins
(dont le plugin RRD). La définition de l’ENTITY suivant avec les bon paramètres de connexion est
nécessaire :
<!ENTITY ossim_db "mysql:10.192.72.172:ossim:snort:E1ephant" >
Il faut ensuite reconfiguer l’agent Ossim afin de préciser que Ntop est activé sur cet agent. Étant donné
que rrd plugin.pl est utilisé pour l’analyse des données, il est nécessaire d’indiquer que le plugin RRD
est aussi en fonction. La figure C.1 illustre cette nouvelle configuration exécutée à l’aide de la commande
suivante :
F IG . C.1 – Interface de configuration (dpkg) des plugins à activer sur l’agent Ossim

C.3 Configuration d’Ossim-server pour une nouvelle sonde Ntop
Si l’ajout de cette sonde a été effectuée sur un sensor existant (comme dans notre cas), il ne sera pas
nécessaire d’enregistrer un nouvel agent sur l’interface Web du serveur. L’agent existant transmettra de
lui même l’existance d’une nouvelle sonde au serveur. Dans le cas contraire (mise en place de cette sonde
sur un nouvel agent), il sera nécessaire de procéder à l’enregistrement du nouvel agent, comme expliqué
dans le manuel disponnible à l’URL suivante : http ://www.ossim.net/docs/User-Manual.pdf
Il est aussi indispensable d’ajouter les droits suffisants à l’utilisateur utilisé lors de la connexion à la base
de donnée, afin que celui-ci soit capable de récupérer la configuration sur le serveur :
# mysql -u root
mysql> use ossim;
Requêtes SQL à entrer pour l’ajout d’un 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 être effectué via phpMyAdmin.

Annexe D
Ajout et configuration de P0f
la section A), ainsi qu’un agent Ossim installé sur la machine qui hébergera P0f (l’installation de l’agent
est décrite dans la section B.1.2 puisqu’il s’agı̂t, dans notre cas, du même agent que pour la sonde Snort).
D.1 Installation
Son installation nécessite uniquement l’installation du paquetage P0f :
# apt-get install p0f
D.2 Configuration
D.2.1 P0f
P0f ne nécessite aucune configuration supplémentaire puisque le chemin de son fichier de log lui est
fourni par l’agent Ossim lors de son exécution.
D.2.2 L’agent Ossim
Il est nécessaire de reconfiguer l’agent Ossim afin de préciser que P0f est activé sur cet agent. Celle-ci
s’opère à l’aide de la commande suivante :
62
Annexe E
Ajout et configuration de TCPTrack
la section A), ainsi qu’un agent Ossim installé sur la machine qui hébergera TCPTrack (l’installation de
l’agent est décrite dans la section B.1.2 puisqu’il s’agı̂t, dans notre cas, du même agent que pour la sonde
Snort).
E.1 Installation
Celle-ci est vraiment très simple puisqu’il suffira de récupérer le paquetage Debian de TCPTrack sur le
serveur Web d’Ossim1 via la commande suivante :
# apt-get install tcptrack
E.2 Configuration
Aucune configuration spécifique n’est nécessaire pour TCPTrack puisque c’est le serveur Ossim qui
s’occupera d’interoger TCPTrack. Il sera par contre indispensable d’indiquer à l’agent qu’une nouvelle
sonde lui a été ajoutée. Ceci s’opèrera via le menu de configuration offert par la commande suivante :
1
Il est donc indispensable d’avoir configuré aptitude afin qu’il récupère directement les paquetages chez Ossim (cf. Section
B.1.1). En effet, la version de TCPTrack utilisée dans l’architecture d’Ossim est une version modifiée de la version originale.
63
Annexe F
Ajout et configuration d’une sonde HIDS

Syslog
la section A), ainsi qu’un agent Ossim installé sur la machine qui hébergera cette sonde HIDS Syslog
(l’installation de l’agent est décrite dans la section B.1.2 puisqu’il s’agı̂t, dans notre cas, du même agent
que pour la sonde Snort).
F.1 Installation
Aucune installation n’est requise puisque le parser de fichiers de log Syslog et directement présent sur
tous les agents (fichier /usr/share/ossim-agent/pyossim/ParserSyslog.py).
F.2 Configuration
Il suffira d’activer le plugin voulu afin que celui-ci soit automatiquement exécuté par l’agent. Pour ce
faire, il vous suffira de l’activer à l’aide du menu de configuration offert par la commande suivante :
La configuration du fichier à contrôler peut être directement faite en modifiant la balise location du fi-
chier /etc/ossim/agent/plugins/syslog.xml. Par défaut celui-ci est /var/log/auth.log.
Sous Debian il sera en plus nécessaire de modifier (dans le même fichier de configuration) le nom du
daemon de logging puisque celui-ci se nomme sysklogd et non pas syslog.
L’ajout de nouvelles règles nécessitera malheureusement la modification du code du parseur /usr/share/ossim-

agent/pyossim/ParserSyslog.py puisque celles-ci s’y trouvent directement intégrées. Aucun fichier de
configuration des règles n’est pour le moment disponnible.
64
Annexe G
Ajout et configuration d’une sonde HIDS

IIS
la section A), ainsi qu’un agent Ossim installé sur la machine qui hébergera cette sonde HIDS IIS1
(l’installation de l’agent est décrite dans la section B.1.2 puisqu’il s’agı̂t, dans notre cas, du même agent
que pour la sonde Snort).
G.1 Installation du plugin
Aucune installation n’est requise puisque le parser de fichiers de log est directement présent 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 côté du serveur web, il est nécessaire d’installer un logiciel client capable d’émettre les logs vers un
serveur de logs Linux. Vous pouvez donc télécharger librement le logiciel Open Source Snare disponible
à l’adresse suivante : http ://www.intersectalliance.com/projects/SnareIIS/index.html#Download
Son installation est ensuite extrêment simple. Il vous suffira de suivre les quelques instructions à l’écran...
1
Internet Information Services, serveur Web de Microsoft
65
G.3 Configuration
G.3.1 Configuration de l’agent OSSIM
Il suffira d’activer le plugin voulu afin que celui-ci soit automatiquement exécuté par l’agent. Pour ce
faire, vous devrez l’activer à l’aide du menu de configuration offert par la commande suivante :
La configuration du fichier de log à contrôler peut être directement faite en modifiant la balise location
du fichier /etc/ossim/agent/plugins/iis.xml. Par défaut celui-ci est /var/log/syslog.
Sous Debian il sera en plus nécessaire de modifier (dans le même fichier de configuration) le nom du
daemon de logging puisque celui-ci se nomme sysklogd et non pas syslog.
L’ajout de nouvelles règles nécessitera malheureusement la modification du code du parseur /usr/share/ossim-

agent/pyossim/ParserIIS.py puisque celles-ci s’y trouvent directement intégrées. Aucun fichier de confi-
guration des règles n’est pour le moment disponible.
Configuration du serveur Syslog Linux (présent sur l’agent OSSIM)
Syslogd est le daemon s’occupant de la récupération de logs d’une machine Linux. Par défaut celui-ci
travaille uniquement en local. Lors de son lancement (commande syslogd), via l’argument ”-r”, il est
possible de lui indiquer d’ouvrir le port 514 UDP pour la récupération de logs distants. Nous modifions
donc son script de lancement ”sysklogd” placé dans /etc/ini.d/. Il suffira donc d’ajouter le ”-r” dans la
variable SYSLOGD déjà présente 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 préciser que le protocole de transfert de logs basé sur UDP n’est pas sécurisé. Les
trames circulent ”en clair” sur le réseau. De plus l’utilisation d’UDP implique une éventuelle possibilité
de perte des paquets sans qu’aucun des deux partenaires ne s’en rende compte (principe même d’UDP).
G.3.2 Configuration du serveur IIS (client Snare IIS)
La figure G.1 illustre la configuration du client Snare effectuée, afin que la station 192.168.1.2 reçoive
les logs contenu dans le fichier C :\WINNT\System32\LogFiles du serveur IIS.
L’utilisation de Snare implique une configuration rigoureuse du format des logs d’IIS. En effet, il est
indispensable de configurer une rotation des logs journalière ainsi qu’un format étendu (W3C extended

F IG . G.1 – Configuration de l’utilitaire de récupération des logs d’IIS
Log File Format) afin que Snare soit capable de les lire. Cette configuration est accessible dans le menu
de configuration de IIS, dans l’onglet Web Site. En cliquant sur le bouton Properties..., il sera possible
de définir la période de rotation des logs ainsi que leur format.
De plus, le parser IIS d’OSSIM (/etc/ossim/agent/plugins/iis.xml) nécessite un format de log très précis
afin d’être capable de les interpréter. Il sera donc nécessaire de configurer les logs d’IIS afin que les
informations suivantes soient présentent :
– 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 qu’un agent Ossim installé sur la machine qui hébergera PADS (l’installation de
l’agent est décrite dans la section B.1.2 puisqu’il s’agı̂t, dans notre cas, du même agent que pour la sonde
Snort).
H.1 Installation
Celle-ci est vraiment très simple puisqu’il suffira de récupérer le paquetage Debian de PADS, via la
commande suivante :
# apt-get install pads
H.2 Configuration
Aucune configuration spécifique n’est nécessaire pour PADS puisque le chemin de ses logs de sortie est
directement fourni par l’agent Ossim (paramètre lors de son exécution). Il sera par contre indispensable
d’indiquer à l’agent qu’une nouvelle sonde lui a été ajoutée. Ceci s’opèrera via le menu de configuration
offert par la commande suivante :
68
Annexe I
Création de règles de corrélation
I.1 Introduction
Cette annexe vous apprendra à créer vos propres directives de corrélation. La structure et syntaxe de
celles-ci est décrite dans ce chapitre.
I.2 Ajout d’un fichier de règles sur le serveur
Pour ce faire, il suffit de créer un nouveau fichier de règles sur le serveur et de le placer dans le répertoire
/etc/ossim/server/. Si celui-ci se nomme mesRegles.xml, il sera indispensable d’indiquer au serveur de
charger ce fichier afin que les règles présentent dans celui-ci soient utilisées. Pour se faire, il vous suffit
d’éditer le fichier /etc/ossim/server/directives.xml afin d’y 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 règles existantes à l’affichage ...

&myRules;
..... suite de la config ....
</directives>
Chaque règle sera ensuite automatiquement triée lors de son affichage dans le framework. Lors de la
création de règles, iI sera indispensable de respecter la numérotation de l’attribut id des balises direc-
69
tives mentionné dans Directive numbering du sous-menu Directives du framework. De cette manière, les
nouvelles règles seront directement affichées dans la catégorie voulue.
I.3 Syntaxe XML
Cette section est partiellement tirée du document de Sébastien 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 définition des différentes balises utilisables dans les règles de
corrélation :
I.3.1 Balise directive
Cette balise englobe la directive de corrélation entière. Elle permettra de définir les paramètres globaux
de celle-ci. Ceux-ci sont :
– l’id de la directive de corrélation, attribut id
– le nom de celle-ci affiché dans le framework, attribut name
– la priorité de la règle, attribut priority
I.3.2 Balise rule
Cette balise permet la définition d’une règle utilisée dans le processus de corrélation de la directive. Il
sera possible d’en définir ses caractéristiques à l’aide des attributs suivants :
– Le type de la règle, attribut type
– Le nom de celle-ci, attribut name
– La provenance de l’alerte que nous attendons, attribut plugin id
– Le numéro d’événement1 de l’alerte du plugin que nous attendons, attribut plugin sid
– Le paramètre de fiabitité (reliability) entrant dans le calcul du risque, attribut reliability
– La fenêtre temporelle dans laquelle la règle doit être matchée, attribut time out
– Le nombre de fois que doit être matché la règle afin de passer à la suivante, attribut occurence
– Le type de protocole sur lequel s’applique la règle, attribut protocol
– L’adresse IP source de la trame matchée par la règle, attribut from
– L’adresse IP de destination de la trame matchée par la règle, attribut to
1
Référence chaque plugin offerte par le sous menu Plugins du menu Configuration

– Le port source de la trame matchée par la règle, attribut port from

– Le port de destination de la trame matchée par la règle, attribut port to
– La condition a appliquer si le contrôle d’une quantité véhiculée par l’alerte est nécessaire, attribut
condition
– La valeur à comparer (à l’aide de la condition définie par l’attribut précédent) à la quantité véhiculée
par l’alerte, attribut value
– Valeur permettant de définir si la valeur à comparer (value) est absolue ou relative, attribut absolute
– L’interval dans lequel la règle doit s’appliquer (équivalent au time out mais utilisé pour les règles
monitor), attribut interval
– Paramètre permettant de geler les paramètres non défini2 dans la directive (utilisé lorsque l’occu-
rence d’une règle est supérieur à 1), attribut sticky
– Paramètre permettant de forcer un attribut à être différent lorsque plusieurs occurence de la règle
sont attendues, attribut sticky different
Lorsqu’une règle (rule) est matchée, cela a pour effet de déclencher le passage à la règle suivante conte-
nue dans la directive. Il s’agit donc d’un ET entre les règles impriquées dans rule.
I.3.3 Balise rules
Cette balise permet l’encapsualtion d’une ou plusieurs règles (balise rule). Si plusieur règles rule sont
présentes au même niveau (sans imbrications) à l’intéreur de la balise rules, un OU est opéré entre
celles-ci (exemple : la 1ère règle ou la deuxième règle ou la 3 ème règle... ). Cette balise ne contient
aucun attribut.
I.3.4 Syntaxe des attributs de caractéristiques
Nous allons maintenant reprendre la définition des attributs utilisables (paramètres) dans les différentes
balises XML.
balise directive
id Cet attribut permet la définition de l’identifiant unique de la directive de corrélation. Cette numérotation
doit suivre les directives émises par Ossim afin que le tri d’affichage effectué dans le framework (sous-
menu directives du menu correlation) soit effectué correctement. Les directives de numérotation sont
disponible dans ce sous-menu.
name Cet attribut permet la définition du nom de la directive (affiché lorsque la directive est matchée).
2
paramètres non utilisé dans la directive

priority Cet attribut permet de définir la priorité de la directive de corrélation. Pour plus d’informations
sur la signification de la priorité d’un événement, conslutez la section 4.3.
balise rule
Type Cet attribut définit le type de la règle. Il existe uniquement deux type de règles :
Detector règles utilisant les informations de détecteurs (snort, spade, syslog, ...) contenue dans la base
de donnée du serveur.
Monitor règles utilisant les information des moniteurs (TcpTrack, Ntop, etc...). Dans ce cas, c’est le
serveur qui aura la tâche d’interroger le moniteur (agent) afin d’obtenir les informations voulues.
name Cet attribut permet de définir le nom de chaque règle. Celui-ci sera ensuite affiché dans le sous-
menu backlog du menu correlation, permettant la visualisation des règles matchées par alertes de haut
niveau (groupe d’alertes).
plugin id Cet attribut définit la provenance de l’alerte attendue par la règle. En effet, chaque plugin a
un identifiant associé (identifiant affiché dans le sous-menu plugins du menu configuration) permettant
de le référencer dans les règles de corrélation.
plugin sid Cet attribut définit l’événement associé au plugin (plugin id). En effet, tous les événement
récupéré par Ossim sont répertorié (en fonction de leur plugin) et configuré3 . 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, l’alerte fournie par le plugin id 1501 et le plugin sid 400 équivaut à : ”apache : Bad
Request”. A l’aide de ces deux attributs (plugin id et plugin sid), il est possible de définir précisément
l’événement attendu par la règle.
reliability L’utilité de cet attribut est expliqué dans la section 4.3. Plus ce paramètre est grand (proche
de 10), plus il indique que l’alerte n’est pas un faut positif. Ce paramètre prend alors une grand im-
portance dans le procédé de corrélation. En effet, au fur et à mesure que des règles sont matchées, la
probabilité que ce groupe d’alerte (alerte de haut niveau) est un faux positif diminue... Il est alors pos-
sible, dans chaque balise rule, de modifier la fiabilité de l’alerte de haut niveau. La première règle (rule)
indique la reliabilité de départ de l’alerte de haut niveau. Les règles suivantes ont ensuite la possibilité
de faire évoluer cette valeur de manière relative (par exemple : +3, signifiant que la reliabilité globale
augmente de 3 par rapport à la règle précédente) 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 expliqués dans la section 4.3)

time out Cet attribut permet d’indiquer le temps d’attente de l’événement correspondant à la règle. Si
celui-ci n’arrive pas dans le temps imparti (configuré en secondes à l’aide de cet attribut), la directive
de corrélation se termine et retourne le résultat ”calculé” des règles précédentes. Cet attribut permet de
préciser la fenêtre temporelle dans laquelle l’alerte (événement) attendue par la règle doit apparaı̂tre.
occurence Cet attribut permet de créer une unique règle lorsque plusieurs occurence d’un même
événement est attendu. Il est ainsi possible de définir le nombre d’événements identique à attendre avant
de passer à la règle suivante.
protocol Cet attribut permet de configurer le type d’événements réseau attendu par la règle. Il est
possible d’en définir trois types :
1. TCP
2. UDP
3. ICMP
Cet attribut permet le référencement absolu. Cela signifie qu’il est possible de reprendre le type de
protocole matché par des règles précédentes. Pour ce faire, il suffira par exemple d’indiquer : proto-
col=”1 :PROTOCOL” afin de préciser que le protocole de cette règle est identique au protocole matché
par la règle de premier niveau (première règle). Si l’on désire récupérer le protocole matché par la règle
du deuxième niveau, il suffira de préciser protocol=”2 :PROTOCOL”.
Cet attribut devra uniquement être utilisé lorsque l’événement attendu par la règle fait partie de l’un des
trois type de protocole disponible.
from Cet attribut permet de préciser l’adresse IP source de l’alerte attendue. Il est possible de la men-
tionner de six différentes manières :
1. ANY, indique que n’importe quelle adresse source sera matchée par cet attribut
2. x.x.x.x, adresse IP standard
3. Par référencement, fonctionnant sur le même principe que le référencement de l’attribut protocole
(exemple : 1 :SRC IP = adresse IP source de l’alerte matchée par le premier niveau de la directive
de corrélation, 2 :DST IP = adresse IP de destinaion de l’alerte matchée par le deuxième niveau
de la directive de corrélation)
4. Par nom du réseau, il est possible d’utiliser une plage d’adresse IP en utilisant les nom de réseaux
défini à l’aide du framework (sous-menu network du menu policy). La variable HOME NET définit
quant à elle tous les réseaux défini dans le framework.
5. Plusieurs adresses, cette syntaxe permet de préciser plusieurs adresses IP séparées par des virgules
6. Négations, cette syntaxe permet l’utilisation de négations sur des adresses IP ou des nom de
réseaux (exemple : !192.168.2.203,HOME NET)

Note sur la première syntaxe (ANY) : Il est évident qu’au niveau de la règle utilisant cette syntaxe cela
revient au même que de ne pas utiliser cet attribut. Cette syntaxe permettra, par contre, le référencement
(à l’aide de la troisième syntaxe) de l’adresse IP de cette alerte dans les règles suivantes.
Cet attribut ne devra pas être utilisé lorsque l’information attendue par la règle n’est pas une trame IP.
to Cet attribut permet de préciser l’adresse IP de destination de l’événement attendu par la règle. Sa
syntaxe est totalement identique à celle de l’attribut from.
Cet attribut ne devra pas être utilisé lorsque l’information attendue par la règle n’est pas une trame IP.
port from Cet attribut permet de préciser le port source du segment TCP ou datagramme UDP attendu
par la règle. Celui-ci peut être décrit par :
– Une liste de ports séparé par des virgules
– ANY
– Un référencement absolu à l’aide des variables SRC PORT et DST PORT
Cet attribut ne devra pas être utilisé lorsque l’information attendue par la règle n’est pas un segment TCP
ou un datagramme UDP.
port to Cet attribut permet de préciser le port de destination du segment TCP ou datagramme UDP
attendu par la règle. La syntaxe de celui-ci est identique à celle de l’attribut port from.
Cet attribut ne devra pas être utilisé lorsque l’information attendue par la règle n’est pas un segment TCP
ou un datagramme UDP.
condition Cet attribut permet de définir le type de condition appliqué entre la quantité véhiculée à
l’aides des règles de type monitor et l’attribut value. Le type des quantités véhiculées par les monitor
sont définies par le plugin sid du plugin id. Les valeurs de la condition peuvent être les suivantes :
1. eq - égal
2. ne - non égal
3. it - plus petit que
4. gt - plus grand que
5. le - plus petit ou égal
6. ge - plus grand ou égal
value Cet attribut est simplement la valeur numérique à comparer avec la quantité véhiculée par l’alerte
d’un moniteur.

absolute Cet attribut permet d’indiquer si la valeur à comparer (value) à la quantité véhiculée par le
monitor est absolue ou relative à la fenêtre temporelle d’application . Cet attribut prend donc les valeurs
true ou false.
Absolute=”true” Indique que la valeur (value) doit être atteinte afin que la condition soit matchée
Absolute=”false” Indique que la valeur véhiculée par le plugin sid du plugin id doit être incrémentée
de value durant la fenêtre temporelle d’application de la règle afin que la condition soit matchée.
interval Cet attribut est similaire à l’attribut time out, mais il s’applique uniquement aux temps de
comparaisons entre les quantités véhiculées par le plugin sid du plugin id et l’attribut value. Il permet
ainsi de définir la fenêtre temporelle utilisée par l’attribut absolute.
sticky Cet attribut permettra, lors de l’attente de plusieurs occurence d’une même règle (attribut occu-
rence plus grand que 1), de geler les paramètres non définis dans celle-ci. Sans cette possibilité, différents
événements non identiques pourraient être matchés comme occurence d’une même règle. En effet, les pa-
ramètres non défini dans une règle sont équivalents à ANY, provoquant ainsi la validation de l’événement
(matching), même si celui-ci n’est pas exactement le même (paramètre non défini différents).
Lorsque cet attribut est configuré à true (sticky=”true”), les caractéristiques non défini des événements
devront être strictement les même que ceux de la première occurence afin que l’événement soit matché
à nouveau.
sticky different Cet attribut permet l’inverse de l’attribut sticky et doit être utilisé conjointement avec
celui-ci. En effet, pour la détection de scan de ports, il serait intéressant de détecter des événements
identique ayant uniquement leur port de destination différent. Il est ainsi possible de définir l’attribut
devant être différent à chaque occurence de la règle. Sticky différent pourra ainsi prendre les valeurs
suivantes :
– SRC PORT
– DST PORT
– SRC IP
– DST IP
– PROTOCOL
Ces paramètres pourront aussi utiliser le référencement absolu abordé dans les explications de l’attribut
protocol.
I.4 Structures des directives de corrélation
I.4.1 Exemple de structure des directives
L’exemple ci-dessous illustre le fonctionnement des règles de corrélation :

<directive MyDirective>
<rule INTRO .. paramètres .. >
<rules>
<rule A .. paramètres .. >
<rules>
<rule C .. paramètres .. />
</rules>
</rule A>
<rule B .. paramètres .. />
</rules>
</rule INTRO>
</directive>
La règle rule INTRO est la règle déclencheuse de la directive de corrélation. Une fois celle-ci matchée,
le moteur de corrélation attend l’apparition de l’événement rule A ou rule B avant de continuer (car les
règles A et B sont encapsulées au même niveau dans une balise rules). Si rule A apparaı̂t, le moteur de
corrélation attend l’apparition de rule C pour finir son travail sur cette directive. Si par contre rule B
apparaı̂t à la place de rule A, la corrélation est terminée et une alerte de haut niveau est générée.
L’exemple suivant illustre le fonctionnement de règles successives :
<directive MyDirective>
<rule INTRO .. paramètres .. >
<rules>
<rule A .. paramètres .. >
<rules>
<rule B .. paramètres .. >
<rules>
<rule C .. paramètres .. />
</rules>
</rule B>
</rules>
</rule A>
</rules>
</rule INTRO>
</directive>
La règle rule INTRO est la règle déclencheuse de la directive de corrélation. Une fois celle-ci matchée, le
moteur de corrélation attend l’apparition de l’événement rule A avant de continuer (passer à la règle sui-
vante). Lorsqu’un tel événement apparaı̂t, le moteur de corrélation attendra l’apparition de l’événement
suivant permettant le passage à ruleB et ainsi de suite.
Nous remarquons que les OU logiques entre les règles (balise rule) sont construit à l’aide de règles de
même niveau à l’intérieur d’une balise rules. Les ET logiques entre règles sont quant à eux simplement

construit par imbriquation de règles (balise rule). De plus, nous remarquons que les balises rules encap-
sulent obligatoirement les règles (balise rule), même si une unique règle est présente.
I.4.2 Structure de corrélation réalisable
La figure I.1, illustre un schéma de corrélation non réalisable à l’aide de la syntaxe XML d’OSSIM.
En effet, la syntaxe arborescente des règles empêche le passage de différents états sur un état commun
(les états 2 et 3 de la figure I.1 peuvent passer sur un même état ”état 4”). Pour qu’une telle structure
soit réalisable à l’aide d’OSSIM, il sera indispensable de la décomposer en arbre. Pour ce faire, il serait
nécessaire de dupliquer certains états (donc certaines règles) afin qu’une règle aboutisse toujours sur
un/des états fils et non sur des états cousins.
F IG . I.1 – Schéma de corrélation non réalisable à l’aide d’OSSIM
La figure I.2, illustre le schéma typique d’un scénario de corrélation d’OSSIM. En effet, chaque règle
mène à ses propres sous-règles. Il n’y a pas de saut entre des états adjacents.

F IG . I.2 – Schéma de corrélation réalisable à l’aide d’OSSIM

Annexe J
Analyse heuristique - (algorithme

Holt-winter)
Les explications propres à la récupération des données sont tirées du document suivant :
http ://www.mirrors.wiretapped.net/security/network-monitoring/ntop/rrdandntop.pdf
J.1 Récupération des données
Comme mentionné en section 3.3.1 Ntop fournit les statistiques réseaux nécessaires à l’analyse heuris-
tique (ainsi qu’à l’analyse de détection de seuils). Ces données sont stockées dans des bases de données
tourniquets illustrées par la figure J.1.
F IG . J.1 – Illustration d’une base de donnée tourniquet
Une fois le tourniquet plein, les anciennes données seront petit à petit remplacées par de nouvelles.
79
A chaque période d’échantillonage, le plugin RRD1 de Ntop interrogera les différents compteurs de bytes
fourni par celui-ci. Il enregistrera ensuite ces valeurs dans la base de données tourniquet correspondante.
Celles-ci seront ensuite interrogées (à l’aide de RRDtool) par l’agent OSSIM via le plugin RRD2 afin
d’y contrôler les seuils et les dépassement de l’algorithme heuristique configuré à l’aide du framework
(section 4.9.4). L’affichage des informations de Ntop3 utilisera les mêmes bases de données afin de pro-
duire ses graphiques et statistiques.
Il est donc important de comprendre l’impacte de la configuration du plugin RRD de Ntop (plugin natif à
Ntop) sur la période d’échantillonage et la quantité d’informations (nombre d’échantillons) collectée par
les bases de données tourniquets. Chaque compteur d’information réseau fourni par Ntop (IP DNSBytes,
IP HTTPBytes, etc...) impliquera la création de 3 bases de données tourniquet. Ces trois différentes bases
de données tourniquet sont nécessaires afin de permettre l’enregistrement d’au moins 1 année de statis-
tiques sans pour autant disposer d’une gigantesque base de données.
Si une unique base de données tourniquet était utilisée afin de stocker 1 an d’échantillons et que la
période d’échantillonnage 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 réduire la taille des bases de données tourniquet, des moyennes sont effectuées sur les échantillons
qui sont ensuite enregistré dans deux bases de données tourniquets annexes permettant le stockage de
plus d’une année de statistiques ”moyennés” sans pour autant disposer de plus de 3mios de Slots.
J.1.1 Configuration du plugin RRD de Ntop
Celle-ci s’opère à l’aide de l’interface 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 paramètres permettent la définition de la taille des 3 bases de données tourniquet
(chaque compteur Ntop utilisera trois base de données tourniquet) ainsi que la période d’échantillonnage
utilisée par le plugin :
Dump Interval Indique la période d’échantillonage en secondes. C’est à dire qu’un nouveau slot du
tourniquet sera rempli toutes les N secondes. Valeur par défaut = 300 secondes.
Dump Hours Indique la taille de la 1ère base de données tourniquet en heures (nb d’heures d’informa-
tions à stocker). On pourra en déduire le nombre de slots nécessaire pour stocker N heures d’in-
formations avant qu’un nouvel échantillon écrase un échantillon existant (1 tour du tourniquet).
Valeur par défaut = 72 heures.
1
plugin nativement intégré à Ntop (à ne pas confondre avec le plugin RRD d’OSSIM)
2
plugin OSSIM cette fois-ci (rrd plugin.pl)
3
affichage sous forme de page Web, via le serveur Web intégré à Ntop

Dump Days Indique la taille de la seconde base de données tourniquet en jours (nb de jours d’infor-
mations à stocker). On pourra en déduire le nombre de slots nécessaire pour stocker N jours d’in-
formations avant qu’un nouvel échantillon écrase un échantillon existant (1 tour du tourniquet).
Valeur par défaut = 90 jours.
Dump Months Indique la taille de la troisième base de données tourniquet en mois (nb de mois d’in-
formations à stocker). On pourra en déduire le nombre de slots nécessaire pour stocker N mois
d’informations avant qu’un nouvel échantillon écrase un échantillon existant (1 tour du tourni-
quet). Valeur par défaut = 36 mois.
Création des bases de données tourniquets
Les paramètres par défauts ci-dessus génèrent automatiquement (pour un compteur Ntop, IP HTTPBytes
par exemple) les bases de données tourniquets suivantes (calcul des valeurs moyennes) :
RRA:AVERAGE:0.5:1:864
Structure des commandes RRD :

Commande :Fonction :périodeEchantillonage :nbValPourFonction :nbSlots
Commande RRA = création d’une base de données tourniquet

Fonction Fonction mathématique appliquée aux valeurs (nbValPourFonction) afin de réduire la taille
des base de données tourniquet suivante
périodeEchantillonage Interval de temps entre le relevé de deux échantillons
nbValPourFonction Nb d’échantillons appliqués à la fonction mathématique définie par Fonction
nbSlots Nb de slots de la base de données tourniquet
Ainsi, la permière base de données tourniquet ne contiendra aucune moyenne (uniquement les valeurs
instantannées), puisque l’AVERAGE est effectué avec une unique valeur (nbValPourFonction = 1). Elle
contiendra 72 heures d’informations récupérées 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 données tourniquet : Un slot de celle-ci correspondra à 12 échantillons (nbVal-
PourFonction) auquels la fonction average (Fonction = AVERAGE) aura été appliquée. Un slot contiendra
alors la moyenne d’une heure d’échantillons (12 * 5 = 60 min). Il sera donc nécessaire de diposer de 2160
slots afin de pouvoir y stocker 90 jours d’informations :
nbJours ∗ nbHeures/jour = 90 ∗ 24 = 20 160Slots (J.3)

J.2 Analyse des données
Cette section vise à expliquer l’algorithme de prévision (heuristique) utilisé dans OSSIM. Celui-ci
récupère les informations des bases de données RRD afin d’en tirer ses prévisions. Le fonctionnement
des bases de données RRD est expliqué dans la section précédente (section J.1).
Les explications ci-dessous sont tirées 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 prévision
Les séries temporelles sont basées sur l’analyse des donnés historiques recueillies sur un phénomène
donné, durant une certaine période de temps (statistiques réseaux par exemples). Les prévisions ef-
fectuées à partir de séries temporelles ont pour hypothèse que le passé est garant de l’avenir, que le
phénomène continuera à se comporter comme il l’a fait dans le passé.
On isole habituellement trois composantes dans les séries temporelles :

tendance caractéristique d’un phénomène à démontrer, un patron stable de croissance ou de décroissance
dans le temps. Le patron peut être linéaire ou non-linéaire.
caractéristique d’un phénomène qui se répète 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 calculés en
années.
aspect aléatoire se dit d’un phénomène qui ne comporte aucun patron décelable.
Divers méthodes et modèles de prévisions sont actuellement utilisables. C’est le type de la fonction
temporelle à prédire qui nous indiquera le meilleur algorithme (modèle mathématique) à utiliser. En
effet, il sera inutile d’utiliser un modèle mathématique complex tel que Holt-Winters si aucun phénomène
cyclique n’est présent dans la série temporelle. En effet, dans le cas où la série est stationnaire (on ne
distingue pas de tendance à la hausse ni à la baisse), on utilisera le lissage exponentiel simple. Dans le
cas d’une série soumise à des variations saisonnières, on utilise souvent le modèle de Holt et Winters.
Moyennes glissantes
Une moyenne gilssante d’ordre N est définie comme étant la moyenne arithmétique sur les N dernières
observations. En méthodes prévisionnelles, cette moyenne devient la porchaine prévision.
Mathématiquement cela donne :
1
Ft = • (Dt−1 + Dt−2 + ... + Dt−N ) (J.4)
N

Avec :
Ft La prévision effectuée à la période t-1 pour la période t.
Dt-1 La valeur (mesurée) de la série à la période t-1.
Lissage exponentiel
Le lissage exponentiel est une classe de méthodes de lissage de séries chronologiques dont l’objectif
est la prévision à court terme. Ces méthodes sont fondées sur une hypothèse fondamentale : chaque
observation à l’instant t dépend des observations précédentes et d’une variation accidentelle. En résumé,
la prévision courante est une moyenne pondérée de la dernière prévision et de la valeur courante.
Mathématiquement cela s’écrit sous cette forme :
Ft = αDt−1 + (1 − α)Ft−1 (J.5)
Avec :
Ft La prévision effectuée à la période t-1 pour la période t.
Dt-1 La valeur (mesurée) de la série à la période t-1.
Ft-1 La prévision à la période t-1 (période précédente de la nouvelle prévision).
alpha Paramètre compris entre 0 et 1.
A l’aide de la formule J.5, nous remarquons que plus le paramètre alpha est grand (proche de 1) plus nous
tenons compte des valeurs précédentes mesurées. Plus alpha est petit (proche de 0), plus nous tenons
compte des valeurs précédentes prédites.
Holt-Winters
La méthode de Holt et Winters permet en effet d’effectuer des prévisions sur des séries chronologiques
assez irrégulières et soumises ou non à des variations saisonnières suivant un modèle additif ou multipli-
catif. Elle consiste en trois lissages exponentiels simultanés définit par trois paramètres. On peut choisir
les coefficients arbitrairement : faibles si l’on considère que la valeur à l’instant t dépend d’un grand
nombre d’observations antérieures, élevés dans le cas contraire (même principe que pour le lissage ex-
ponentiel simple). On peut aussi en calculer les valeurs optimales, en minimisant la somme des carrés
des différences entre les valeurs observées et estimées.
Le paramètrage de la périodicité (variation saisonnière) est important puisque celui-ci influencera grande-
ment l’algorithme de prévision. La figure J.2 illustre l’erreur entre une prédiction par lissage exponentiel
et la fonction à observée (en bleu) ainsi que l’erreur entre une prédiction par Holt-Winters et la fonction
observée (en rouge).
La figure J.3, illustre quant à elle les mêmes erreurs que la figure précédente (figure J.2) avec, cette
fois-ci, un mauvais règlage du paramètre de périodicité de l’algorithme Holt-Winters. Nous remarquons

F IG . J.2 – Erreurs de prédictions avec un bon réglage du paramètre de périodicité de Holt-Winters
donc que la prévision par Holt-Winters devient aussi mauvaise (même pire) qu’une simple prédiction par
lissage exponentiel. Il est donc très important de bien régler ce paramètre afin d’obtenir une prédiction
optimale...
Les feuilles de calcul OpenOffice et Excel permettant de tester et comparer le comportement d’un algo-
rithme de prédiction par lissage exponentiel ainsi que par Holt-Winters sont téléchargeables à l’adresse
suivante :
http ://www.fullsecurity.ch/security/sims/download.jsp

F IG . J.3 – Erreurs de prédictions avec un mauvais réglage du paramètre de périodicité de Holt-Winters

Ossim Doc PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ossim Doc PDF

Caricato da

Copyright:

Formati disponibili

Fonctionnement d’OSSIM

Dans le cadre de SIMS - Security Intrusion Management System

Auteur : Joël Winteregg (joel.winteregg@heig-vd.ch)

1 License d’utilisation de cette documentation 5

2 Étude d’OSSIM (Open Source Security Information Management) 6

3 Fonctionnement logiciel d’OSSIM 17

3.6 Fonctionnement de l’architecture avec une sonde PADS . . . . . . . . . . . . . . . . . . 22

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

2 Institut ICT, Joël Winteregg (cc)

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

A Installation et configuration d’Ossim-server 47

B Ajout et configuration d’une sonde Snort 52

C Ajout et configuration de Ntop 58

D Ajout et configuration de P0f 62

3 Institut ICT, Joël Winteregg (cc)

E Ajout et configuration de TCPTrack 63

F Ajout et configuration d’une sonde HIDS Syslog 64

G Ajout et configuration d’une sonde HIDS IIS 65

H Ajout et configuration de PADS 68

I Création de règles de corrélation 69

J Analyse heuristique - (algorithme Holt-winter) 79

4 Institut ICT, Joël Winteregg (cc)

License d’utilisation de cette

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

Étude d’OSSIM (Open Source Security

2.2.1 Méthodes de détection

Détection par signatures

7 Institut ICT, Joël Winteregg (cc)

Différentes méthodes d’analyse sont implémentées dans le cadre d’OSSIM :

2.3.1 Définition de la priorité des alarmes

8 Institut ICT, Joël Winteregg (cc)

2.3.2 Évaluation des risques

9 Institut ICT, Joël Winteregg (cc)

OSSIM met en oeuvre plusieurs méthodes de corrélation complémentaires :

Corrélation par heuristique OSSIM implémente un algorithme d’heuristique comme un accumula-

10 Institut ICT, Joël Winteregg (cc)

Par conséquence, la corrélation par heuristique offre :

11 Institut ICT, Joël Winteregg (cc)

12 Institut ICT, Joël Winteregg (cc)

2.4.1 Risk monitor (moniteur du risque)

2.4.2 Moniteur d’utilisation, 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 légale)

13 Institut ICT, Joël Winteregg (cc)

2.4.5 Control Panel (panneau de contrôle)

L’architecture d’OSSIM est divisée en 2 principaux étages :

F IG . 2.1 – Architecture d’OSSIM

14 Institut ICT, Joël Winteregg (cc)

2.5.1 Data flow

15 Institut ICT, Joël Winteregg (cc)

F IG . 2.2 – Data flow du serveur OSSIM

16 Institut ICT, Joël Winteregg (cc)

Fonctionnement logiciel d’OSSIM

3.1 Les applications Ossim-server et Ossim-agent

3.2 Fonctionnement de l’architecture avec une sonde Snort

3.2.1 Pourquoi deux flux d’informations ?

F IG . 3.1 – Principe de communication entre une sonde Snort et le serveur d’OSSIM

18 Institut ICT, Joël Winteregg (cc)

3.3 Fonctionnement de l’architecture avec une sonde Ntop et le plugin

F IG . 3.2 – Principe de communication entre une sonde Ntop et le serveur d’OSSIM

3.3.1 Qu’est-ce que Ntop ?