fonctionnement d’ossim - download.velannes.comdownload.velannes.com/ossim_doc.pdf · ossim est...

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

(http ://www.fullsecurity.ch/security/sims/)

Auteur : Joel Winteregg ([email protected])Professeur : Stefano Ventura

Ecole : Swiss University of Applied Sciences (HEIG-VD)Institut ICT (http ://www.iict.ch)

Date : 12 mai 2006Version : 3.4

Table des matieres

1 License d’utilisation de cette documentation 5

2 Etude d’OSSIM (Open Source Security Information Management) 62.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 La detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Methodes de detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 L’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Definition de la priorite des alarmes . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 Evaluation des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.3 Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Le monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.1 Risk monitor (moniteur du risque) . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.2 Moniteur d’utilisation, session et profile . . . . . . . . . . . . . . . . . . . . . . 132.4.3 Path monitor (moniteur de chemin) . . . . . . . . . . . . . . . . . . . . . . . . 132.4.4 Forensic console (Console legale) . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.5 Control Panel (panneau de controle) . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5.1 Data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Fonctionnement logiciel d’OSSIM 173.1 Les applications Ossim-server et Ossim-agent . . . . . . . . . . . . . . . . . . . . . . . 173.2 Fonctionnement de l’architecture avec une sonde Snort . . . . . . . . . . . . . . . . . . 17

3.2.1 Pourquoi deux flux d’informations ? . . . . . . . . . . . . . . . . . . . . . . . . 173.3 Fonctionnement de l’architecture avec une sonde Ntop et le plugin RRD . . . . . . . . . 19

3.3.1 Qu’est-ce que Ntop ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 Fonctionnement de l’architecture avec une sonde P0f . . . . . . . . . . . . . . . . . . . 203.4.1 Qu’est-ce que P0f ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5 Fonctionnement de l’architecture avec une sonde TCPTrack . . . . . . . . . . . . . . . 213.5.1 Qu’est-ce que TCPTrack ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1

SIMS - Security Intrusion Management System

3.6 Fonctionnement de l’architecture avec une sonde PADS . . . . . . . . . . . . . . . . . . 223.6.1 Qu’est-ce que PADS ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.6.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.7 Fonctionnement de l’architecture avec une sonde Syslog . . . . . . . . . . . . . . . . . 243.7.1 Qu’est-ce qu’une sonde HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.7.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.8 Fonctionnement de l’architecture avec une sonde HIDS IIS (Internet Information Services) 253.8.1 Qu’est-ce qu’une sonde HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.8.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Fonctionnement du Framework (interface Web et serveur OSSIM) 274.1 Avant propos et terminologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Architecture des menu du framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Definition du risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Menu Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4.1 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.4.2 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.4.3 Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4.4 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5 Reports Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5.1 Host Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5.2 Security Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.5.3 PDF Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.5.4 Anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.5.5 Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.6 Monitor Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.6.1 Riskmeter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.6.2 Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.6.3 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.7 Policy Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.7.1 Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.7.2 Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.7.3 Network groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.7.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.7.5 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.7.6 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.8 Correlation Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.8.1 Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.8.2 Cross Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.8.3 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2 Institut ICT, Joel Winteregg (cc)


4.9 Configuration Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.9.1 Main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.9.2 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.9.3 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.9.4 RRD config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.9.5 Host scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.10 Tools Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.10.1 Net Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.10.2 Rule viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.10.3 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Conclusion 45

A Installation et configuration d’Ossim-server 47A.1 Prerequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

A.3.1 Ossim plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.3.2 Serveur Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.3.3 Nessus client-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A.3.4 Cross correlation via Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

B Ajout et configuration d’une sonde Snort 52B.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

B.1.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.1.2 Ossim-agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

B.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.2.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.2.2 Ossim-agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

B.3 Configuration d’Ossim-server pour une nouvelle sonde Snort . . . . . . . . . . . . . . . 55B.4 Test de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

B.4.1 Erreur de demarrage de l’agent Ossim . . . . . . . . . . . . . . . . . . . . . . . 56

C Ajout et configuration de Ntop 58C.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

C.1.1 Ntop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58C.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

C.2.1 Ntop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.2.2 L’agent Ossim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

C.3 Configuration d’Ossim-server pour une nouvelle sonde Ntop . . . . . . . . . . . . . . . 61

D Ajout et configuration de P0f 62D.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62



D.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62D.2.1 P0f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62D.2.2 L’agent Ossim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

E Ajout et configuration de TCPTrack 63E.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63E.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

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

G Ajout et configuration d’une sonde HIDS IIS 65G.1 Installation du plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65G.2 Installation de Snare IIS (rapatriement des logs vers un serveur Syslog) . . . . . . . . . 65G.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

G.3.1 Configuration de l’agent OSSIM . . . . . . . . . . . . . . . . . . . . . . . . . . 66G.3.2 Configuration du serveur IIS (client Snare IIS) . . . . . . . . . . . . . . . . . . 66

H Ajout et configuration de PADS 68H.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68H.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

I Creation de regles de correlation 69I.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69I.2 Ajout d’un fichier de regles sur le serveur . . . . . . . . . . . . . . . . . . . . . . . . . 69I.3 Syntaxe XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

I.3.1 Balise directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70I.3.2 Balise rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70I.3.3 Balise rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71I.3.4 Syntaxe des attributs de caracteristiques . . . . . . . . . . . . . . . . . . . . . . 71

I.4 Structures des directives de correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . 75I.4.1 Exemple de structure des directives . . . . . . . . . . . . . . . . . . . . . . . . 75I.4.2 Structure de correlation realisable . . . . . . . . . . . . . . . . . . . . . . . . . 77

J Analyse heuristique - (algorithme Holt-winter) 79J.1 Recuperation des donnees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

J.1.1 Configuration du plugin RRD de Ntop . . . . . . . . . . . . . . . . . . . . . . . 80J.2 Analyse des donnees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

J.2.1 Algorithmes de prevision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82


Chapitre 1

License d’utilisation de cettedocumentation

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.frOR SEND A LETTER TO CREATIVE COMMONS, 543 HOWARD STREET, 5TH FLOOR, SANFRANCISCO, CALIFORNIA, 94105, USA.

5

Chapitre 2

Etude d’OSSIM (Open Source SecurityInformation Management)

2.1 Introduction

OSSIM est une solution offrant une infrastructure pour le monitoring de la securite reseau. Ses objectifssont :

– Fournir un cadre centralise

– Fournir une console d’organisation

– Ameliorer la detection et l’affichage des alarmes de securite

Le but commun des trois principaux objectifs decrits ci-dessus est de permettre une reduction desfaux positifs1 et des faux negatifs2. Ce but est d’autant plus difficile a atteindre du fait qu’un volumeconsiderable d’alarmes est present. Il est donc necessaire de relier ces differentes alarmes entre elles afind’obtenir des informations pertinantes et d’eliminer les alarmes innutiles (levees pour rien). Cet objectifpeut etre atteint a l’aide d’un procede d’analyse des donnees nomme : Correlation.

Le principe de fonctionnement d’OSSIM est forme de trois grandes categories decomposees elles-memesen sous categories :

1. La detection

– IDS (pattern matching3)

– Detection d’anomalie

– Firewalls

2. L’analyse et le monitoring (detaille en section 2.3.3 et 2.4)1Alarmes levees pour rien2Alarmes non declenchees alors qu’une attaque a eu lieu3signatures

6


– Correlation

– Evaluation de la dangerosite des alarmes

– Evaluation du risque sur l’architecture a proteger

3. Les management (configuration)

– Inventaire des ressources informatiques4

– Definition de la topologie

– Definition des polices de securite

– Definition des regles de correlation

– Liens avec differents outils d’audits Open Source

Les differents procedes cites ci-dessus seront detailles dans les sections suivantes.

2.2 La detection

Celle-ci est evidemment effectuee a l’aide de sondes capables de traiter l’information5 en temps reel etd’emettre des alarmes lorsqu’une situation a risque est detectee.

2.2.1 Methodes de detection

Une sonde peut utiliser differentes approches afin de determiner si une evenement est a risque ou non.En effet, deux grands principes complementaires (et non concurrent) sont presents dans la detectiond’intrusions :

1. Base sur des signatures

2. Base sur la detection d’anomalie

Detection par signatures

La detection par signatures identifie des evenements de securite qui tentent d’utiliser un systeme de faconnon standard. Les representations d’intrusions sont donc stockees et comparees a l’activite du systeme.Lorsqu’une intrusion connue est reperee lors de l’utilisation du systeme, une alarme est levee.La detection par signatures a des limites. Elle ne connaıt pas l’objectif de l’activite correspondant aune signature et va donc declencher une alerte meme si le trafic est normal. De plus, la detection parsignature exige de connaıtre prealablement l’attaque afin de generer la signature precise correspondante(fonctionnement par liste noire, exemple : antivirus). Ceci implique qu’une attaque encore inconnue nepourra pas etre detectee par signature.

4machines, systemes d’exploitation, services5Trames transitants par le reseau ou log d’une application



Detection d’anomalie

La detection d’anomalie identifie une activite suspecte en mesurant une norme6 sur un certain temps.Une alerte est ensuite generee lorsque le modele s’eloigne de cette norme.Le principal avantage de la detection d’anomalie est qu’elle n’exige aucune connaissance prealable desattaques. Si le module de detection par anomalie determine qu’une attaque differe de facon significativede l’activite normale, il peut la detecter.Comme la detection par recherche de pattern, la detection d’anomalie possede ses limites. Toute la dif-ficulte reside dans la periode de collecte des donnees correspondant a une activite designee commenormale pour alimenter la base de donnees de reference.

2.3 L’analyse

La methode de traitement des donnees peut etre decomposee en trois phases distinctes :

1. Preprocessing, generation des alarmes et envoi de celles-ci.

2. Rassemblement, toutes les alarmes precedemment envoyees (preprocessing) sont emmagasineesdans un serveur central.

3. Post-processing, le traitement des donnees que l’on a emagasine.

Les deux premieres etapes (preprocessing et rassemblement) ne presentent rien de nouveau dans le cadred’OSSIM. Celles-ci font principalement partie des methodes de detection mentionnees ci-dessus (section2.2). OSSIM offrira uniquement de nouvelles methodes d’analyse et d’affichage des donnees recoltees.Il n’apportera en aucun cas de nouvelles solutions dans la detection et le rassemblement de donnees.

Differentes methodes d’analyse sont implementees dans le cadre d’OSSIM :

– Definition de la priorite des alarmes

– Evaluation des risques

– Correlation

2.3.1 Definition de la priorite des alarmes

Ce procede permettra de deduire la priorite d’une alarme en fonction de son type, de la source del’eventuelle attaque ainsi que de sa cible. Les exemples suivants illustrent facilement l’utilite de cetteetape d’analyse :

– Une machine fonctionnant avec le systeme d’exploitation UNIX et hebergeant un serveur WebApache est mentionnee comme cible d’une attaque. Cette attaque a precedemment ete detecteecomme possible a l’aide d’un scanner de vulnerabilites. La piorite de l’alerte sera donc maximale

6Peut etre assimile a un chablon de bon fonctionnement (activite normale)



puisque le serveur Web est vulnerable a l’attaque en question. Un procede de cross-correlation estdonc applique a toutes les alertes.

– Si la connexion a un serveur genere une alarme, la configuration de police de securite en fonctiondes utilisateurs permettra facilement la definition de la priorite de celle-ci. En effet, differents cassont envisageables :

– Priorite maximale de l’alarme si l’utilisateur (source de ”l’attaque”) est exterieur au reseaude l’entreprise et que la connexion a pour cible une base de donnees importantes.

– Basse priorite si l’utilisateur (source de ”l’attaque”) est interne au reseau de l’entreprise etque la connexion a pour cible une imprimante.

– Alarme discreditee si l’utilisateur (source de ”l’attaque”) fait partie de l’equipe de developpementet que la cible de la connexion est un serveur de test.

La definition de priorite fait partie d’une etape de mise en place de contextes des alarmes. Celle-ci estuniquement possible si l’environnement de l’entreprise est defini dans une base de donnees des connais-sances. Cette base de donnees est definie par l’inventaire des bien informatiques ainsi que sur des policesd’acces a des serveurs et/ou services. La definition des ces differentes polices de securites impliquela mise a disposition d’un outil de management permettant une configuration precise des polices desecurites ainsi que des machines du reseau.Cette etape represente une part importante du filtrage des alarmes et necessitera une constante mise ajour de la base de donnees des connaissances.

2.3.2 Evaluation des risques

Le risque peut etre defini comme etant la probabilite de menace de l’evenement. En d’autres termes,cette etape tente de definir si la menace est reelle ou pas.L’importance a donner a un evenement depend principalement de trois facteurs :

1. La valeur du bien attaque

2. La menace representee par l’evenement

3. La probabilite que l’evenement apparaisse

Les trois facteurs vus ci-dessus sont la base du calcul du risque intrinseque.

Risque intrinseque

Ce risque peut etre defini de la facon suivante : La mesure de l’impact potentiel de la menace sur lebien informatique, en fonction de la probabilite que cette menace apparaisse, tout en tenant comptede la fiabilite du capteur ayant emit l’alarme.Le risque est traditionnellement represente par le risque intrinseque representant le risque qu’une orga-nisation court de par les biens qu’elle possede.



Risque immediat

Etant donne qu’OSSIM offre un traitement temps reel des alarmes, le calcul du risque immediat peut etreassocie a la situation courante.Ce risque offre une vision de l’evaluation des degats qu’une alarme recue pourrait engendrer. Cetteevaluation prendra aussi en compte la fiabilite du capteur ayant emis cette alarme. Le risque immediatest donc calcule pour chaque alarmes recues et indique l’importance de l’alarme en terme de securite.

2.3.3 Correlation

Ce procede permet nottamment de retrouver certaines relations entre differentes alarmes independantes.Ceci permettra par exemple de decouvrir des attaques noyees dans le flot des alarmes ou encore dediscrediter des alarmes (decouverte de faux positifs).La correlation peut etre simplement definie comme un procede traitant des donnees (inputs) et retournantun resultat (outputs). OSSIM utilise deux types d’inputs :

1. Informations du moniteur (qui fournit normalement des indications a l’administrateur)

2. Informations des detecteurs (qui fournissent normalement des alarmes)

Le resultat de ce traitement sera lui aussi d’un des deux genres cites ci-dessus (du moniteur ou desdetecteurs). Les modeles de correlations utilises par OSSIM ont les objectifs suivants :

– Utilisation de methodes par signatures, pour la detection d’evenements connus et detectables

– Utilisation de methodes sans signature, pour la detection d’evenements non connus

– Utilisation d’une machine d’etats configurable par l’utilisateur, pour la description de signaturescomplexes

– Utilisation d’algorithmes evolues, pour l’affichage general de la securite

Methodes de correlation

OSSIM met en oeuvre plusieurs methodes de correlation complementaires :

1. Correlation utilisant des sequences d’evenements, basees sur les signatures connues et detectables

2. Correlation utilisant des algorithmes heuristique7, utilisee pour la detection d’attaques non connues

3. Cross-correlation permettant la recherche de relations entre les scans Nessus effectues et des alertesdetectees

Correlation par heuristique OSSIM implemente un algorithme d’heuristique comme un accumula-teur d’evenements (CALM), offrant une indication de l’etat general du reseau. L’objectif de ce traitementest d’obtenir en premier lieu, le risque immediat (definit dans la section 2.3.2) puis, le risque accumule.

7Technique consistant a apprendre petit a petit, en tenant compte de ce que l’on a fait precedemment pour tendre vers lasolution d’un probleme



– Le risque immediat offre un haut niveau de monitoring temps reel. Celui-ci peut etre assimile aun ”thermometre” des situations critiques, sans meme connaıtre les details des caracteristiques duprobleme.

– Le risque accumule offre quant a lui un haut niveau de monitoring sur une certaine fenetre tempo-relle (risque accumule et non plus temps reel).

Le second algorithme heuristique utilise par OSSIM permet la prevision des statistiques reseaux (paquetsemis et recus) en fonction des valeurs precedentes (Holt-winter). Ceci permettra la detection automatiqued’anomalies reseaux.

Par consequence, la correlation par heuristique offre :

– Une vue globale et rapide de la situation

– Une detection possible d’attaques, non relevees par les autres methodes de correlation (se basantsur des signatures)

CALM (Compromise and Attack Level Monitor), est un algorithme8 utilisant les evenements accumules etfournissant une valeur indicative du niveau de securite global. L’accumulation d’evenements est effectueeindependamment pour tous les elements du reseau. Celle-ci est simplement calculee par la somme dedeux variables d’etat representant le risque immediat de chaque evenement :

1. Variable ”C” ou niveau de fiabilite d’une machine ou d’un reseau, mesure la probabilite qu’unemachine ou un reseau soit compromis (source d’une attaque effectue par un ver ou troyen installesur une machine a surveiller).

2. Variable ”A” indique la probabilite que la machine ou reseau a surveiller soit la cible d’attaques.

La variable ”A” represente la probabilite qu’une attaque a ete lancee et qu’elle est reussie, alors que lavariable ”C” fournit l’evidence qu’il y a eu une attaque et qu’elle a reussi.Chaque machine du reseau a donc une variable ”A” et ”C” associee, fluctuant de la maniere suivante :

1. Toute attaque possible d’une machine 1 (source) vers une machine 2 (cible) incrementera le niveau”A” de la machine 2 et le niveau ”C” de la machine 1.

2. Lorsqu’une reponse a une attaque est detectee (signifiant que l’attaque est reussie), le niveau ”C”des deux machines sera incremente.

3. Lorsque l’evenement est interne (source interne), seul le niveau ”C” de la machine source estincremente.

CALM fonctionne d’une maniere temps reel (accumulation temps reel des evenements). Il peut aussi etreinteressant d’observer ces statistiques dans une fenetre temporelle (accumulation sur le temps). En ef-fet, ceux-ci varieront grandement en fonction de la fenetre utilisee puisqu’un fonctionnement temps reel(accumulation continue d’evenements) aura pour effet de noyer certaines alarmes critiques dans la massed’information. Nous pourrions assimiler le fonctionnement d’accumulation sur le temps a un zoom surles statistiques temps reel.

8Algorithme implemente dans OSSIM



Holt-Winter Algorithme, algorithme heuristique implemente dans le moteur de correlation temps reeld’OSSIM, permettant la decouverte de comportements anormaux sans l’utilisation de seuils. Descrip-tion tiree de : http ://www.usenix.org/events/lisa2000/full papers/brutlag/brutlag html/index.html

La detection anormale de comportements est decomposee en trois parties, chacune etablie selon sonpredecesseur :

1. Un algorithme pour prevoir pas par pas les valeurs d’une serie chronologique.

2. Une mesure de deviation entre les valeurs prevues et les valeurs observees.

3. Un mecanisme detectant lorsqu’une valeur est ”trop deviante” de la valeur prevue.

L’algorithme de prevision Holt-Winter fait appel aux principes de lissage exponentiel (genre de moyennemathematique permettant la prediction de valeurs). En effet, Holt-Winter fournit une methode un peuplus complexe utilisant un triple lissage exponentiel. Pour plus d’informations au sujet de cet algorithme,consultez l’annexe J.

Correlation par diagramme d’etats (sequence d’evenements) Ce genre de correlation fait appel ala detection par signatures. Ceci permettra a l’utilisateur (administrateur reseau en charge de la securite),de definir des regles de correlation a l’aide des signatures disponnibles. Exemple : Si l’alarme A, B et Cest levee, il faut executer l’action D. Ceci s’apparente donc au moteur de correlation developpe par M.Saladino dans le cadre de SIMS 20039.Le moteur de correlation d’OSSIM a les caracteristiques suivantes :

Capacite de definir des variables d’origines et de destination

Utilisation des alarmes des detecteurs (detection par signature) et/ou des informations des moni-teurs (monitoring) comme input pour la correlation

Utilisation de variables elastiques (accumulant des informations au cour du temps)

Architecture recursive (possibilite d’utiliser des regles precedemment definie dans de nouvelleregles)

2.4 Le monitoring

Le monitoring consiste en l’affichage des informations fournies. Les consoles de monitoring utilisent lesdifferentes donnees produites par les procedes de correlation (decrit ci-dessus) pour la construction d’unaffichage efficace et/ou resume.

9Realise dans le cadre d’un projet de diplome 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 donnees produites par l’algorithme CALM(decrit dans la section 2.3.3). Les informations ”C” (mesure de la fiabilite) et ”A” (mesure du niveaud’attaque) sont illustres graphiquement par ce moniteur.

2.4.2 Moniteur d’utilisation, session et profile

Comme decrit plus haut, OSSIM place une grande importance sur le monitoring detaille de chaquemachine et profile. Il existe 3 differents types de monitoring dans OSSIM :

1. Monitoring d’utilisation, offrant une vue generale d’une machine (comme snmp le ferai)

2. Monitoring de profile, offrant des informations specifiques sur l’activite des utilisateurs, nous per-mettant d’etablir un profil (pop, http, etc..) pour chaque utilisateur

3. Monitoring de session, offre un affichage temps reel des sessions en cours d’un utilisateur

2.4.3 Path monitor (moniteur de chemin)

Ce moniteur offre un affichage temps reel des chemins de l’information empruntes par des donneesemises par differentes machines sur le reseau. Il utilise les informations fournies par le moniteur desession (identifiant chaque lien present sur le reseau) et par le moniteur de risque (fournissant le niveaude risque de chaque machine) afin de construire un affichage agreable (a l’aide de differentes couleurs).Deux methodes d’affichage et d’analyse sont disponibles.

Hard link analysis (Analyse des liens TCP)

Cette methode affiche uniquement les sessions TCP courantes. Le but de celle-ci est de pouvoir observerla propagation d’une attaque ou d’un ver afin de determiner un perimetre de securite.

Soft link analysis

Cette methode d’analyse offre l’affichage de tous les liens percus sur le reseau (UDP, TCP, ICMP inclus).

2.4.4 Forensic console (Console legale)

Cette console offre l’acces a toutes les informations recueillies et stockees par le collecteur. Elle est doncun outil de recherche sur la base de donnees d’evenements. Celle-ci permet une analyse a posterioridetaillee et approfondie des elements reseaux.



2.4.5 Control Panel (panneau de controle)

Cette console offre un apercu de haut niveau de la securite. Cette console permet la definition de seuilsgenerant des alarmes de haut niveau a destination de l’administrateur reseau en charge de la securite.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 reseau (statistiques d’utilisation)

– Monitoring des seuils definis

– Monitoring des profiles depassant les seuils

2.5 Architecture

L’architecture d’OSSIM est divisee en 2 principaux etages :

1. Pre-processing, remontee d’evenements des moniteurs et detecteurs dans une base de donneescommune

2. Post- processing, analyse centralisee

La figure 2.1 illustre le fonctionnement en 2 etages (comme mentionne ci-dessus). Nous remarquons queces deux etages disposent de differentes bases de donnees permettant la sauvegarde des informationsintermediaires (correlees). Defintions des bases de donnees :

FIG. 2.1 – Architecture d’OSSIM

EDB La base de donnees des evenements (la plus grande), stockant toutes les alarmes individuelles



KDB La base de donnees des connaissances, sauvegardant les configurations etablies par l’administra-teur en charge de la securite

UDB La base de donnees des profiles, stockant toutes les informations du moniteur de profile

2.5.1 Data flow

Afin d’aider a la comprehension, nous allons detailler le cheminement d’une alarme dans l’architecturedefinie par la figure 2.1. Le schema de la figure 2.2, illustre le fonctionnement decrit ci-dessous :

1. Detection d’un evenement suspect par un detecteur (par signatures ou par l’heuristique)

2. Si necessaire, des alarmes sont regroupees (par le detecteur) afin de diminuer le trafic reseau

3. Le collecteur recoit la/les alarme(s) via differents protocoles de communications ouverts

4. Le parser normalise et sauve les alarmes dans la base de donnees d’evenements (EDB)

5. Le parser assigne une priorite aux alarmes recues en fonction de la configuration des polices desecurites definies par l’administrateur securite

6. Le parser evalue le risque immediat represente par l’alarme et envoie si necessaire une alarmeinterne au Control panel

7. L’alerte est maintenant envoyee a tous les processus de correlation qui mettent a jour leurs etats etenvoient eventuellement une alerte interne plus precise (groupe d’alerte provenant de la correlation)au module de centralisation.

8. Le moniteur de risque affiche periodiquement l’etat de chaque risque calcules par CALM10.

9. Le paneau de controle affiche les alarmes les plus recentes et met a jour les indices des etats quisont compares aux seuils definis par l’administrateur. Si les indices sont superieurs aux seuilsconfigures, une alarme interne est emise.

10. Depuis le panneau de controle, l’administrateur a la possibilite de visualiser et rechercher des liensentre les differentes alarmes a l’aide de la console forensic

10Algorithme decrit dans la section 2.3.3



FIG. 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 recupere simplement les informations des fichiers de logs des plugins (fichier fast.logpour Snort) et les envoie directement au serveur OSSIM permettant ainsi le traitement temps reelde celles-ci. De plus, l’agent Ossim s’occupera de la mise en marche et de l’arret des differentessondes qui lui sont connectees. Il ne sera ainsi pas necessaire de demarrer la sonde Snort ”a lamain” puisque son activation sera effectuee 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’analyseet de correlation des donnees ainsi qu’un serveur Web permettant l’interaction avec l’utilisateur(administrateur reseau).

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 independant du programme client d’OSSIM (nomme : ossim-agent) et que deux flux d’informations sont emis en direction du serveur.

3.2.1 Pourquoi deux flux d’informations ?

Le flux nomme ”Requetes SQL pour depos des alertes” est utilise afin de deposer directement lesalertes dans la base de donnees ”Snort DB” du serveur. Ceci permettra l’archivage de celles-ci et

1Intrusion Detection System

17


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

leur conslutation via ACID2, permettant ainsi l’analyse precise de chaque alertes.

Le flux nomme ”Envoi des alertes pour l’anayse temps reel (TCP et protocole applicatif propre aOSSIM” est quant a lui necessaire pour le procede d’analye et de correlation temps reel opere surle serveur d’OSSIM.

Ces deux flux d’informations redondants sont indispensables si l’on ne veut pas redefinir le protocoled’envoi des informations dans la base de donnees ”Snort DB”. En effet, le plugin de sortie Mysql neserait pas suffisant pour un traitement temps reel puisque le stockage des informations dans une base dedonnees ”casse” le procede temps reel. Un tel fonctionnement impliquerait l’interrogation continuellede la base de donnees afin de decouvrir les nouvelles donnees inserees. Les concepteurs d’OSSIM ontdonc prefere utiliser deux flux d’informations plutot que de creer un nouveau plugin de sortie pour Snortpermettant 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 reel et de l’insertion des informations dansune base de donnees.Pour l’analyse et la correlation, le serveur Ossim utilise uniquement les alertes provenant de l’agent Os-sim, alors que les alertes directement stockees dans la base de donnees sont uniquement utilisees pour la

2Analysis Console for Intrusion Databases, interface Web integree a OSSIM permettant l’interrogation d’une base dedonnees Snort (developpe dans le cadre du projet Open Source Snort)



consultation.

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

Le principe de communication d’une sonde Ntop avec le serveur OSSIM est illustre par la figure 3.2.

FIG. 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 maniere temps reel le trafic reseau et met a disposition une liste de compteurs (parexemple : IP DNSBytes, IP HTTPBytes), permettant le monitoring ainsi que le calcul de statistiquesreseaux. La sonde Ntop met en place un serveur Web (sur le port 3000) permettant le monitoring ainsique la configuration de celle-ci a distance.Le plugin de sortie RRD3 est necessaire pour l’integration des fonctionnalites heuristiques et de detectionde seuils dans OSSIM. Celui-ci permet l’enregistrement des donnees Ntop sous forme de tourniquet (les

3Round Robin Database



plus vieilles donnees sont ecrasees par les nouvelles). L’interrogation de la base de donnee RRD est en-suite facilitee a l’aide de l’outil RRDtool4 utilise par le script rrd plugin.pl offrant les fonctions d’analyseheuristiques et de controle de depassement de seuils.Des seuils RRD ainsi que les parametres de l’analyse heuristique (algorithme Holt-Winter explique dansl’annexe J) peuvent ensuite etre defini par l’administateur securite via le framework (cf. section 4.9.4).Cette configuration permettra la generation d’alertes lorsque des valeurs excessives auront ete detecteespar rrd plugin.pl.

3.3.2 Fonctionnement

Le script Perl rrd plugin.pl effectue la liaison entre Ntop et l’agent Ossim pour les fonctionnalitesheuristiques (Holtwinter algorithme) et de detection de seuils. Celui-ci interroge periodiquement la”base de donnees” RRD (illustree par Ntop/rrd log file sur la figure 3.2) a l’aide de l’outil RRDtool.Il recupere (via des requetes SQL sur le serveur) les seuils des compteurs definis par l’administrateurreseau a l’aide du framework de configuration5 et les compare aux donnees precedemment recuperees(a l’aide de RRDtool). Les eventuels depassements des seuils sont ensuite stockes dans un fichier de log(/var/log/ossim/rrd plugin.log) qui sera recupere par l’agent Ossim afin de permettre l’envoi temps reeldes informations au serveur.La correlation des ces informations peut ensuite etre effectuee 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 detection de systemes d’exploitations6 passif. Il analyse les trames transitant sur lereseau (le segment analyse) et les compare avec une base de donnees des caracteristiques de chaque OS(prise d’empreintes) afin d’en retrouver l’OS correspondant :

1. detection de la presence d’un firewall et NAT

2. detection d’un load balancer (repartiteur de charge reseau)

3. detection de la distance (TTL) de la machine distante ainsi que depuis combien de temps la ma-chine est demarree

P0f est totalement passif. Il ne genere aucun traffic reseau supplementaire !4http ://people.ee.ethz.ch/ oetiker/webtools/rrdtool/5interface Web offerte par le serveur. Menu : Configuration - RRD config6Operating System (OS)



FIG. 3.3 – Principe de communication entre une sonde P0f et le serveur d’OSSIM


Celui-ci est assez simple. P0f ecrit ses logs dans le fichier /var/log/ossim/p0f.log (chemin fournit a P0fpar l’agent Ossim lors du lancement de P0f). Ce chemin se trouve donc dans la configuration du pluginP0f (/etc/ossim/agent/plugins/p0f.xml) de l’agent. Le daemon agent (ossim-agent) s’occupera ensuite deles recuperer afin de les envoyer au serveur OSSIM pour une analyse temps reel.

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 figure3.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 detecte passivement les connexions TCP sur l’interface a analyser et affiche les informations dela meme maniere que la commande Unix top. Il permet l’affichage des adresses source et destination, del’etat de la connexion, du temps de connexion ainsi que de la bande passante utilisee.



FIG. 3.4 – Principe de communication entre une sonde TCPTrack et le serveur d’OSSIM


TCPTrack fonctionne d’une maniere similaire a l’affichage Web des informations de Ntop. En effet,aucune information n’est spontanement envoyee vers le serveur OSSIM. TcpTrack ouvre simplementun port serveur7 sur la loopback de l’agent. C’est ensuite le serveur OSSIM qui, lors du procede decorrelation, interrogera si necessaire l’agent afin qu’il interroge a son tour TCPTrack (via la loopback).Une fois les informations recoltees par l’agent, celui-ci se chargera de les remettre au serveur qui lesutilisera pour la correlation. L’agent joue donc un role d’intermediaire 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.7port 40003 par defaut8Passive 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 uniquementen sniffant le reseau. Il permettra l’affichage des services d’une machine sans avoir a operer un scan actifcomme nmap9. Il permettra l’affichage des services d’une machine configuree sur OSSIM sans opererun scan actif.


Le logiciel PADS reportera simplement toutes les informations recoltees dans le fichier de log /var/log/ossim/pads.csv(indique dans la configuration du plugin, fichier /etc/ossim/agent/plugins/pad.xml). L’agent Ossim sechargera ensuite de les recolter et de les envoyer de maniere temps reel au serveur.

FIG. 3.5 – Principe de communication entre une sonde PADS et le serveur d’OSSIM

9Outil integre 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 lafigure 3.6.

FIG. 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 specifiques dans des fichiers de logs. Des qu’une suitede caractere (pattern) appartenant a la liste des patterns recherche est detecte, une alerte est generee. Ilest ainsi possible de remonter des evenements specifiques (critiques) vers la console de monitoring. Deplus, a l’aide du sid de chaque regle, il est possible de les utiliser dans des regles de correlation sur leserveur.

10Host Intrusion Detection System




Le parser analysant le fichier Syslog d’une machine Linux est directement present sous forme native surles agents OSSIM. Son code et ses regles sont presents dans un seul et unique fichier /usr/share/ossim-agent/pyossim/ParserSyslog.py. Il analysera le fichier de logs de maniere temps reel et informera leserveur OSSIM, via la connexion presente entre l’agent et le serveur, des qu’un pattern present dans laliste de pattern interdits (blacklist) aura ete detecte.

3.8 Fonctionnement de l’architecture avec une sonde HIDS IIS (InternetInformation Services)

Le principe de communication d’une sonde HIDS11 IIS avec le serveur OSSIM est illustre par la figure3.7.

FIG. 3.7 – Principe de communication entre une sonde HIDS IIS et le serveur d’OSSIM

11Host Intrusion Detection System



3.8.1 Qu’est-ce qu’une sonde HIDS

Ces sondes ont pour but de rechercher des patterns specifiques dans des fichiers de logs. Des qu’une suitede caractere (pattern) appartenant a la liste des patterns recherche est detecte, une alerte est generee. Ilest ainsi possible de remonter des evenements specifiques (critiques) vers la console de monitoring. Deplus, a l’aide du sid de chaque regle, il est possible de les utiliser dans des regles de correlation sur leserveur.


Le serveur web de Windows (IIS) doit obligatoirement utiliser un programme specifique (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 present sous forme native sur les agents OSSIM (/usr/share/ossim-agent/pyossim/ParserIIS.py)analysera le fichier de logs de maniere temps reel et transmettra par defaut tous les logs du serveur webau serveur OSSIM via le flux present entre le serveur et l’agent (chaque log etant vu comme une alertesur le serveur OSSIM).


Chapitre 4

Fonctionnement du Framework (interfaceWeb 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’hotes aproteger) est disponible a l’adresse suivante : http ://www.ossim.net/docs/User-Manual.pdfCe chapitre fera le lien entre les differents outils decrits precedemment et les menus disponibles dans leframework d’OSSIM.

Trois termes bien distincts seront employes dans ce chapitre. Il est tres important d’en saisir la difference :

Alerte Information de detection d’intrusion ou d’anomalie brut genere par une sonde. Typiquement, lesalertes Snort generees par un agent. Celles-ci contiendront donc un grand nombre de faux positifs...

Groupe d’alertes Information correspondant au resultat d’une correlation (alerte de haut niveau). Ils’agira donc de plusieurs alertes reliees ensemble selon des caracteristiques definies par les direc-tives de correlation.

Alarme Alerte ou groupe d’alertes ayant atteint un niveau de risque superieur ou egal a 2 (valeur cal-culee selon la forumule 4.1, puis arrondie. Par exemple : 1.6 est arrondi a 2).

4.2 Architecture des menu du framework

L’interface de configuration et monitoring offerte par OSSIM (framework) se compose de divers menuet sous-menu illustre par la figure 4.1 page 43. Ce chapitre traitera chacun d’eux afin que le lecteur soitensuite capable d’utiliser plainement les fonctionnalites d’OSSIM.

27


4.3 Definition du risque

Plusieurs parametres permettent de qualifier le niveau de dangerosite (risque) d’une alerte/groupe d’alertes.Il est important de bien saisir leur signification afin d’etre a meme de creer des regles de correlation oumeme de gerer correctement les alarmes selon leur niveau d’importance.

Asset Il s’agıt la d’une valeur permettant de definir l’importance d’une machine sur le reseau. En effet,un serveur Web sera souvent une ressource plus precieuse pour une entreprise qu’une imprimantereseau. Comme nous le verrons apres, ces specifications seront prises en compte lors du calcul durisque de chaque alerte.Il est ainsi possible de definir pour chaque machine (menu Policy sous-menu Hosts) l’Asset decelles-ci. Cette valeur doit etre comprise entre 0 et 5 (0 = machine peu importante pour l’entreprise,5 = machine tres importante pour l’entreprise).

Priority Cette valeur permet de mesurer la gravite d’une alerte ou d’un groupe d’alertes isolee. Eneffet, celle-ci ne tient aucunement compte de l’environement ou de l’hote a proteger. Ce niveauest donc uniquement dependant de l’alerte ou du groupe d’alertes (resultat d’une correlation). Ilest donc possible d’ajuster le niveau Priority des alertes de chaque plugins via le menu Configura-tion, sous-menu Plugins. Celui-ci est aussi definit (surcharge des priorites definies par les alertesindependantes) pour chaque regle de correlation, permettant le reglage de la priorite du resultat dela correlation (groupe d’alertes).La valeur de ce parametre est ajustable entre 0 et 5.

Reliability En terme de risque, ce parametre pourrait s’appeler la ”probabilite”. Celui-ci est defini pourchaque alerte independante (via le menu Configuration, sous-menu Plugins). Il est ainsi possiblede qualifier la probabilite que l’alerte se produise.Ce parametre sera principalement ajuste sur les groupes d’alertes par le moteur de correlation(surcharge de la valeur definie pour le plugin). Celui-ci sera capable d’augmenter la reliabilityd’un groupe d’alarme a chaque fois qu’une sous-regle sera matchee. Ceci prouvera pas a pas quece groupe d’alertes (alerte de haut niveau) n’est pas un faux positif. Le terme reliability peut doncetre traduit par la fiabilite qu’une alarme n’est pas un faux positif. La valeur de ce parametre estcomprise entre 0 et 10 (equivalent a 0% = c’est un faux positif et 100%= ce n’est pas un fauxpositif).

Le risque permet de lier les trois parametres precedent par la formule suivante (4.1) et d’etablir si unealerte ou un groupe d’alertes est ”mute” en alarme :

Risk =Asset ∗ Priority ∗Reliability

10(4.1)

Le lien entre l’etape 6 et 9 de la figure 2.2 du chapitre 2 illustre la ”mutation” d’alertes/groupe d’alertesen alarmes.

4.4 Menu Control Panel

Ce menu offre quatre differentes vues :



4.4.1 Metrics

Ce sous-menu affiche les informations relatives a l’algorithme CALM (decrit dans la section 2.3.3) demaniere globale ainsi que sur les reseaux definis par l’administrateur et les hotes dont les niveaux A1

ou C2 sont eleves. Une visualisation graphique est offerte ainsi qu’un historique. Il est donc possibled’observer les parametres A et C de maniere temps reel via cette interface.CALM recupere toutes les alertes afin de les associer au niveau A et/ou C de l’hote voulu sur un intervalde temps. Son fonctionnement est illustre par la figure 4.2 page 44 .

Il offre une vue rapide du nombre d’alertes detectees sur les hotes du reseau. Par un clic sur l’iconed’information, il est possible de generer un ticket permettant le depos de commentaires sur le serveur ausujet des niveaux observes (pour plus d’explications consultez la section 4.5.5). L’icone graphique offrequant a lui (lors d’un clic sur celui-ci) un affichage des niveaux A et C de l’hote ou reseau specifie.

4.4.2 Alarms

Ce sous-menu offre une vue des alarmes detectees. En effet, les evenements affiches contiendront uni-quement des alarmes de haut niveau (niveau de risque superieur ou egal a 2, calcules selon la for-mule 4.1). Il est alors possible de cliquer sur le nom de l’alarme (champ Alarm) afin d’en observer plusprecisement les causes. Deux situations sont alors envisageables :

L’alarme provient d’une directive de correlation (groupe d’alertes ayant un risque superieur ou egal a 2)Un menu permettant la visualisation des regles ”matchees” est affiche lors du clic sur le nom del’alarme. Dans cette nouvelle vue, il sera ensuite possible (via le lien Visualize alarm et une appletJava3) d’observer graphiquement les trames, ayant genere l’alarme, transiter sur le reseau. Cettereconstitution est effectuee a l’aide de la base de donnee Snort et des adresses IP contenues dansles differentes alertes.

L’alarme provient d’une alerte de risque eleve (plus grand ou egal a 2) Le seul contenu pertinant pou-vant etre affiche sera le dump4 de celle-ci. Lors du clic sur le nom de l’alarme l’utilisateur seraredirige sur l’interface d’ACID (equivalent au sous-menu Alerts de ce menu). Un filtrage sera auto-matiquement applique afin d’afficher uniquement les alertes provenant des memes adresses IP dansla fenetre temporelle de l’alerte. Il sera ainsi possible d’observer l’alerte ayant provoque l’alarme(risque plus grand ou egal a 2) ainsi que toutes les autres alertes de la meme fenetre temporelle.

Par defaut, toutes les alarmes ont un status (champ Status) OPEN. Cela signifie qu’aucun administrateuren charge de la securite n’a analyse l’alarme ou n’a reussi a y trouver une solution. Plusieurs possibilitess’offrent alors a lui :

1. Effacer l’alarme (il s’agit clairement d’un faux positif). L’alarme sera effacee a jamais...1niveau d’attaque auquel un systeme est sujet, mesure le risque potentiel du aux attaques detectees2niveau de fiabilite d’une machine, mesure le niveau de probabilite qu’une machine soit compromise (hacker)3http ://scanmap3d.sourceforge.net/4Contenu brut de l’alerte Snort



2. Fermer le status de l’alarme (par un clic sur OPEN contenu dans le champ Status). Dans ce casl’alarme n’est pas effacee mais n’est plus directment affichee dans le menu Alarms. Afin de visua-liser a nouveau les alarmes fermees (status CLOSED), il sera necessaire de deselectionner l’ongletHide closed alarms

3. Generer un ticket permettant la saisie d’informations sur les actions entreprises par l’administrateuren charge de la securite (par un clic sur l’icone d’information contenu dans le champ Action). Ilaura de plus la possibilite de modifier le status de l’alarme (OPEN ou CLOSED) afin d’indiquersi le probleme a pu etre resolu ou non. Ce fonctionnement est particulierement interessant lorsqueplusieurs administrateur en charge de la securite travaillent sur le meme framework OSSIM. Leprincipe de generation de ticket et d’ajout d’informations au sujet d’une alarme est decrit plus endetail dans la section 4.5.5.

Calcul du risque des alarmes

Le calcul du risque des alarmes (champ Risk de ce sous-menu) est opere a l’aide de la formule 4.1.Les valeurs des parametres Priority et Reliability sont directement tirees du resultat de la correlation (sil’alarme est un output d’une correlation, groupe d’alertes) ou de l’alarme unique (si l’alarme est unealerte de niveau de risque superieur a 2). Le calcul du risque est donc opere de maniere differente entreles alertes (section 4.4.3) et les alarmes. En effet, dans le calcul du risque des alarmes, la valeur duparametre Asset sera la valeur la plus elevee entre la source de l’alarme (de l’attaque) et la destination decelle-ci. Les autres parametres (Priority et Reliability) restent quant a eux les memes que pour l’alerteou groupe d’alertes ayant genere l’alarme.Comme dans le calcul du risque des alertes (section 4.4.3), la valeur de l’Asset (source et destination del’attaque) est en premier lieu recuperee dans les configurations des machines (sous-menu Hosts du menuPolicy) puis (si aucune valeur n’est configuree dans ce sous-menu) dans les configurations des reseaux(etablies dans le sous-menu Network du menu Policy).

4.4.3 Alerts

Ce sous-menu permet la visualisation des alertes generees (alertes brutes) par les differentes sondesconnectees au serveur ainsi que les resultats des correlations qui ont abouties (regles matchees). En effet,ce sous-menu permet la consultation de toutes les alertes recoltees par le serveur avant l’application desdifferents procedes de correlation sur celles-ci.La valeur du risque (champ Risk) calcule pour chaque alerte est directement opere a l’aide de la formule4.1. Comme explique en section 4.3, les valeurs des parametres Priority et Reliability utilises dans lecalcul du risque sont propres aux alertes (configure dans le sous-menu Plugins du menu Configuration).La valeur de l’Asset utilisee pour le calcul du risque est celle configuree pour la machine de destinationou, si celle-ci n’est pas configuree dans le sous-menu Hosts du menu Policy, celle configuree pour lereseau auquel est connecte la machine de destination (configure dans le sous-menu Network du menuPolicy).



Ce sous-menu est en fait d’une version quelque peu modifiee d’ACID5. Il sera donc possible d’obtenirdes informations detaillees et precises sur les alertes via ce sous-menu. Pour de plus amples informationssur 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 vulerabilites Nessus6. Celle-ci permettra l’activationdu script /usr/share/ossim/scripts/do nessus.pl, qui procedera a l’interrogation de la base de donneesd’OSSIM afin de determiner quelles sont les machines et/ou reseaux a scanner (Les machines a scannersont configurees a l’aide du sous-menu Hosts du menu Policy). Le script do nessus.pl effectuera ensuitele scan par l’appel du client nessus installe sur le serveur OSSIM. Les rapports de securites generes parNessus seront ensuite disponibles dans ce sous-menu.Ce script s’occupe ensuite de remplir la table host plugin sid repertoriant les sid Nessus pour lesquelschaque machine est vulnerable. Ce fonctionnement (cross-correlation Nessus-Snort) est decrit plus endetail dans la section 4.8.2.

4.5 Reports Menu

Ce menu offre cinq differents sous-menus en rapport avec la securite du reseau.

4.5.1 Host Report

Ce sous-menu permet d’observer les machines configurees dans le sous-menu Hosts du menu Policy. Ilest ainsi possible d’observer le hostname, l’Asset, l’IP et l’OS des machines configurees.En cliquant sur le hostname de la machine voulue, il est possible d’acceder a differenes caracteristiqueset informations de celle-ci. Il sera ainsi possible d’observer les caracteristiques suivantes :

– Section principale

Inventory Inventaire de la machine (Nom, IP, Systeme d’exploitation, adresse MAC, Sensor ana-lysant son trafic, Ports ouverts). Toutes les caracteristiques affichees sont celles configureespar l’administrateur reseau, mis a part les ports ouverts. En effet, le plugin PADS7permet ladetection des ports ouverts d’une machine uniquement par l’analyse des trames transitant surle reseau. C’est donc les informations fournie par PADS qui permettent l’identification desports ouverts de la machine en question.En cliquant sur le mode Passive (mode de detection de PADS), le mode de detection desports passe en active. Il est alors possible d’observer la liste des ports ouverts a l’aide d’un

5Analysis Console for Intrusion Databases, http ://acidlab.sourceforge.net/6http ://www.nessus.org/7Passive Asset Detection System, plugin decrit dans la section 3.6.



programme de scan actif (nmap). Le lien update permet quant a lui l’execution de nmap(programme de scan actif) afin de mettre a jour la liste des ports ouverts.

Metrics Niveau ”A” et ”C” de la machine selectionnee (niveaux calcules a l’aide de l’algorithmeCALM8.

Usage Offre l’affichage graphique des informations fournies par Ntop9. En effet, ce plugin met enplace un serveur web sur l’agent qui permettra l’affichage de toutes les donnees statistiquesrecoltees par Ntop. Le lien (Usage) fournit donc uniquement une redirection vers le serveurWeb du plugin Ntop de l’agent voulu (agent analysant les informations de la machine enquestion).

Anomalies permettant de visualiser la detection d’anomalies operee par Ntop. Il s’agıt la desresultats de l’analyse heuristique decrite en section J.

– Sous-section Alarms :

Source or Dest Ce lien permet la visualisation des alarmes de haut niveau, ayant comme adressesource 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 machineen 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 genereespar les differents plugins. L’affichage fourni par le lien Main, permet de connaıtre le nombred’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’interfaced’ACID.

Src Unique alerts Ce lien affiche directement les alertes (via ACID) ayant l’adresse de la machineen question comme source. Il est ensuite possible de continuer son investigation en cliquantsur 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 investigationen 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 vulnerabilites Nessus.En effet, cette interface affiche le nombre de failles detectees sur toutes les machines scanneesen mettant en evidence (en rouge) le resultat de la machine en question. Il suffira ensuite decliquer sur l’adresse IP de la machine voulue afin d’observer le rapport de vulnerabilite decelle-ci. Le lien update scan offre la possibilite d’effectuer un nouveau scan afin de mettre ajour la liste des vulnerabilites de toutes les machines configuree pour un scan Nessus.

8Principe decrit en section 4.4.19Outil d’analyse temps reel du trafic reseau. Logiciel decrit dans la section 3.3.1

10Analysis Console for Intrusion Databases, http ://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html



Security Problems Ce lien offre la vue directe du rapport de vulnerabilites de la machine enquestion (equivalent 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 fenetre 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 les10 machines figurant le plus souvent comme source des alertes (Top Attacker) et les 10 figurant les plussouvent comme destination des alertes (Top Attacked). En cliquant sur le nom d’une machine, il serapossible 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 detectees. Il permetainsi de determiner quels sont les services les plus attaques. En cliquant sur le numero de port voulu, ilest 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 alertesles plus rencontrees, alors que Top 10 alerts by Risk offre une vision des alertes les plus rencontrees ayantun risque eleve.

4.5.3 PDF Report

Ce sous-menu permet la recuperation de rapports PDF. Il est ainsi possible de recuperer 3 differentsrapports PDF, comportant chacun des informations specifiques :

Security Report Permettant la generation d’un document PDF identique au sous-menu Security Report(Section 4.5.2)

Metrics Report Permettant la generation d’un document PDF, offrant une vue numerique des niveau”A” et ”C” de l’algorithme CALM11 en fonction des fenetres temporelles selectionnees.

Incident Report Permettant la generation d’un document PDF, offrant le resume des incidents reportespar les gestionnaires du reseaux (personnes physiques) utilisant OSSIM (sous-menu Incident,menu Reports)

4.5.4 Anomalies

Ce sous-menu offre l’affichage des resultats de l’algorithme heuristique Holt-Winter (explique en section2.3.3).Cette fonctionnalite comporte malheureusement certains bugs qui la rende encore non fiable.

11algorithme explique en section 2.3.3



4.5.5 Incident

Ce sous-menu offre un archivage des commentaires deposes par les differents administrateurs en chargede la securite. En effet, ce sous-menu permet de deposer des annotations sur les activites effectuees ainsique de fermer les alarmes/problemes ayant ete resolus (principe de fermeture d’alarmes explique ensection 4.4.2).

Differents sujets d’archivages sont dipsonibles :

OSSIM Permettant de deposer des commentaires sur des alarmes specifiques (ticket ALA) ou sur desmetriques marginaux (ticket MET). Il s’agit donc du menu dans lequel l’utilisateur est renvoyelorsqu’il clic sur l’icone d’information dans le sous-menu Metrics ou Alarms du menu ControlPanel.

Hardware Permettant de deposer des commentaires sur le hardware d’OSSIM et des problemes ren-contres sur celui-ci.

Install Permettant de deposer des commentaires sur l’installation de nouveaux agents et/ou plugins.

Un outil de recherche integre dans la page Web d’incidents, permettra de retrouver et trier les commen-taires sur la base de mots cles. Celui-ci propose plus ou moins de champs de recherche (Filter Advencedou Filter simple). Apres avoir selectionne son sujet d’archivage il sera possible d’ajouter de nouveauxcommentaire en cliquant sur lien Insert new Incident.

Vous pourrez ensuite completer les champs offerts et ajuster le niveau de priorite de l’incident (commen-taire).

4.6 Monitor Menu

Cette section offre une representation graphique de l’etat du reseaux et des differents agents places surcelui-ci.

4.6.1 Riskmeter

Ce sous-menu offre uniquement l’affichage de l’algorithme CALM12. Il s’agit donc d’une representationreduite 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 ete recemment). Cette visualisationfait appel a l’outil Ntop (explications technique en section 3.3). En effet, celui-ci repertorie toutes lesconnexions TCP qu’il appercoit depuis le ou les agents sur lesquels il est place. Il offre ensuite, via son

12Algorithme explique en sections 4.4.1 et 2.3.3



interface web (port 3000 de l’agent) une liste de connexions detectees.

Cette sous-section offre ensuite la possibilite de visualiser ces informations en fonction d’une sonde(agent Ntop) ou en fonction d’un reseau. Plusieurs comportements sont alors possibles :

En fonction d’une sonde Ce sous-menu affiche simplement la page web fournie par le serveur webNtop de la sonde en question.

En fonction d’un reseau Ce sous-menu affiche toutes les informations disponibles sur les sessions TCPdes hotes situees sur le reseau en question.Pour ce faire, le framework effectuera un scan Nmap13 de tout le reseau en question. Pour chaquemachine decouverte, il determinera avec quelle sonde celle-ci est associee (association effectueedans le sous-menu Hosts du menu Policy, champ Sensors). Une fois les associations resolues, ilinterrogera les serveur web Ntop des sondes en question afin de recuperer les informations sur lessessions TCP des machines voulues. Il generera ensuite une page web a l’aide des informationsrecoltees.

4.6.3 Network

Cette sous-section fait simplement appel a l’interface web fournie par les sondes hebergeant un agentNtop. Il est ainsi possible de selectionner l’agent sur lequel l’on desire se connecter puis de choisir legenre d’informations desirees. Ces informations sont donc relative a la sonde Ntop (reseau sur lequelcelle-ci est placee) et non pas a un hote ou un reseau specifique.Etant donne que ce sous-menu fait appel a l’interface web de Ntop, de plus amples informations sur sonutilisation sont disponibles dans le document suivant : http ://www.ntop.org/ntop-overview.pdf

4.6.4 Sensors

Ce sous-menu permet simplement la visualisation des plugins installes sur les differents agents actifs. Al’aide de celle-ci, il sera possible d’arreter ou de desactiver le plugin a distance (lien stop ou disable). Ladesactivation du plugin engendrera son non activation lors d’un redemarrage de l’agent alors que l’arretn’aura aucune inscidence lors d’un redemarrage de l’agent. Lorsqu’un plugin est arrete ou desactive, ilest possible de le redemarrer ou le reactiver a l’aide de ce sous-menu (lien start ou enable).

4.7 Policy Menu

Ce menu offre une interface de configuration du reseau a surveiller. En effet, il est necessaire d’indiquerles plages d’adresses IP des reseaux a analyser ainsi que les hotes a surveiler. Les explications ci-dessousseront succintes puisque le document suivant : http ://www.ossim.net/docs/User-Manual.pdf offre dejades explications completes a ce sujet.

13Outil de scan reseaux



4.7.1 Hosts

Ce sous-menu permet la configuration des machines a surveiller. En effet, il est possible de definir 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 enquestion (detection de depassement de seuils et algorithme Holt-Winter) champ RRD Profile, le ou lesagents etant capable de recuperer (sniffer) les informations reseaux de la machine (champ Sensors), letype de scan a effectuer (champ Scantype).

4.7.2 Networks

Ce sous-menu permet la definition des reseaux a surveiller. En effet, il est possible de definir la plaged’adresses du reseau (champ IPs), l’importance de celui-ci (champ asset), les seuils d’alerte pour l’al-gorithme CALM associe au reseau (champ Threshold A et Threshold C), le profile RRD utilise pourl’analyse heuristique sur le reseau en question (detection de depassement de seuils et algorithme Holt-Winter) champ RRD Profile, le type de scan a effectuer (champ Scantype).

4.7.3 Network groups

A l’aide des configurations des reseaux defini precedemment (section 4.7.2), il est possible a l’aide de cesous-menu de definir des groupes de reseaux ayant des caracteristiques communes.

4.7.4 Sensors

Ce sous-menu permet l’ajout et la configuration d’un agent. Il sera ainsi possible de definir l’importancede celui-ci (champ asset).

4.7.5 Signatures

Ce sous-menu permet la creation de groupe de signatures Snort. Ceux-ci seront ensuite utilise par lesous-menu Policy actuellement non disponible dans OSSIM pour cause de bug.

4.7.6 Ports

Ce sous-menu permet la creation de groupes de ports. Ceux-ci seront ensuite utilise par le sous-menuPolicy actuellement non disponible dans OSSIM pour cause de bug.

4.8 Correlation Menu

Ce menu offre trois differents sous-menus :



4.8.1 Directives

Ce sous-menu permet la visualisation des regles de correlation definies sur le serveur OSSIM. Celles-ci sont appliquees de maniere temps reel aux alertes arrivant sur le serveur. Ces regles permettent lacreation d’un diagramme d’etats definissant 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, paragrapheCorrelation par diagramme d’etats. Ces alertes de haut niveau seront ensuite stockees dans le sous-menu Alerts du menu Control Panel. Etant donne que la quasi totalite d’entre elles fournissent un niveaude risque superieur a 2 (provenant de la configuration d’une priorite souvent elevee dans les directives decorrelation), ces alertes de haut niveau seront ”mutees” en alarmes et affichees dans le sous-menu Alarmsdu menu Control Panel.

La configuration et l’etablissement des directives de correlation sont detailles dans l’annexe I.

4.8.2 Cross Correlation

Ce procede permettra d’augmenter la priorite d’une alerte Snort lorsque l’attaque definie par celle-ci auraete decouverte comme possible par Nessus. Les associations entre les alertes de Snort et les sid des reglesNASL14 de Nessus sont affichees dans ce sous-menu (affichage correspondant a la table plugin referencede la base de donnee d’OSSIM). Les differentes colonnes affichees on les significations suivantes :

Plugin id Identification du plugin qui va etre associe avec un script NASL Nessus. Il s’agıt, pour lemoment, uniquement du plugin Snort.

Plugin sid Identification de l’evenement du plugin (Plugin id) qui va etre associee avec un script NASLNessus. Il s’agıt, pour le moment, uniquement de regles Snort.

Reference id Identification du plugin de reference (Nessus en l’occurence).

Reference sid Identification de l’evenement associe au plugin de reference (script NASL).

Ces informations representees normalement sous forme numerique sont simplement remplacees par leursdefinition textuelle contenue dans la base de donnee OSSIM.

Le script do nessus.pl execute lors d’un scan Nessus (section 4.4.4) s’occupe ensuite de remplir la tablehost plugin sid repertoriant les sid Nessus pour lesquel chaque machine est vulnerable. Une fois cesinformations connues, le moteur de cross-correlation pourra rechercher pour chaque alerte recue, sonexistance dans la table plugin reference. Si un tel evenement est repertorie dans cette table, le moteur decorrelation pourra en tirer le plugin sid de Nessus correspondant. Il pourra ensuite, rechercher dans latable host plugin sid l’existance de ce sid de Nessus pour la machine cible de l’alerte. Si un tel sid estpresent, la priorite et la fiabilite (reliabiliy) de l’alerte Snort seront modifies de la sorte :

Fiabilite Addition de la fiabilite de la ”regle” Nessus matchee et de la regle Snort

Priorite La valeur maximale entre la priorite de la ”regle” Nessus matchee et la regle Snort14Nessus Attack Scripting Language, language permettant d’etablir des regles de test Nessus



L’alerte sera ensuite automatiquement mutee en Alarme afin que celle-ci apparaisse dans le sous-menuAlarms du menu Control Panel du framework.

4.8.3 Backlog

Ce sous-menu repertorie les ”paquetages” de backlog des alarmes provenant d’une directive de correlation.En effet, lorsqu’une alarme est levee suite a l’aboutissement (complet ou partiel) d’une directive decorrelation cela signifie que plusieurs alertes ont ete matchees par la directive. Le ”paquetage” de l’alarmecontient alors les references a ces alertes. Il sera ainsi possible, lors de la consultation des alarmes (sous-menu Alarms du menu Control Panel), de cliquer sur le nom de l’alarme resultant d’une correlation afinde pouvoir observer les alertes contenues dans les ”paquetages” backlogs (cf. section 4.4.2).

4.9 Configuration Menu

Ce menu permet la configuration de certains parametres d’OSSIM.

4.9.1 Main

Ce sous-menu offre une interface de configuration globale d’OSSIM. En effet, le framework, les agentset leurs plugins recupereront ces differentes informations. Ce sous-menu se decompose en plusieurssections :

Language Configuration de la langue du framework et des preferences d’affichage locale dir.Fonctionnalite pas encore implementee

Server Configuration des caracteristiques reseau du serveur (adresse IP et port).

Snort Configuration des caracteristiques propres a Snort (base de donnees, login et chemin d’acces)

Metrics Configuration du seuil d’alerte (threshold) lors d’un depassement des metriques (algorithmeCALM), ainsi que du debit de sortie des alertes de l’accumulateur CALM (recovery).

phpGACL Configuration de la base de donnee des regles ACL (Access Control List) permettant lagesion des utilisateurs et d’acces d’OSSIM.

PHP Configuration des chemins des libraires php.Le champ use svg graphics initialise a yes permet l’affichage graphique du thermometre du sous-menu Metrics du menu Control Panel. Celui-ci necessite l’installation d’un plugin sur le navigateurclient (plugin SVG).Le champ use resolv initialise a yes offre la resolution de noms pour les adresses IP affichees parOSSIM.

RRD Configuration des chemis vers les librairies graphiques et scripts permettant la generation desgraphiques 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 donnees de backup (fonctionnalite pas encore implementee, puisqueles backups sont sauvgardees dans des fichiers .sgl.gz)

Nessus Configuration du user/login utilise par le client Nessus pour effectuer les scans, ainsi que del’hote hebergant le serveur Nessus. Mise en place du mot de passe Nessus effectue en sectionA.3.3.

ACID Configuration du chemin (URI) vers ACID, ainsi que de la pair user/pass lors de l’utilisationHTTPS 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 utilises par le serveurOSSIM. 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 creation de comptes utilisateurs pour l’interface web d’OSSIM. En effet, il estpossible de creer differents comptes ayant differents droits d’acces. Il sera ainsi possible de definir pourchaque 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 evenement de chaqueplugin est indexe a l’aide d’un sid (identifiant unique pour les evenements du plugin). Il sera ainsi pos-sible de referencer chaque evenement a l’aide d’une pair id/sid ou id est l’identifiant du plugin et sidl’identifiant de l’evenement pour le plugin selectionne. Cette methode de referencement des evenementspermettra l’utilisation de ceux-ci dans des directives de correlation. Plus d’informations sur leur utilisa-tion dans les directives de correlation en section I.

4.9.4 RRD config

Ce sous-menu permet l’etablissement de profils RRD utilises par le plugin RRD des agents OSSIM. Leprincipe de fonctionnement de ce plugin a ete aborde dans la section 3.3.1 lors de la presentation del’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 laprediction de valeurs (valeurs fournies par Ntop). Des explications detaillees sur l’analyse heuris-tique Holt-winter est fournie en annexe J.

2. Detection de depassement de seuils : Comparaison des seuils configures avec les valeurs courantesfournies par Ntop.

Les profils cree a l’aide de ce sous-menu pourront ensuite etre utilises dans les polices de securite desmachines et des reseaux definis a l’aide du framework. Il sera ainsi possible d’appliquer le profile sou-



haite sur ces elements.

Les attributs representent les informations fournies par Ntop (compteurs de bytes, etc...). Sur chacund’eux, il est possible de definir des seuils (threshold) afin d’etre averti (generation d’une alerte rrd thresholdaffichee dans le sous-menu Alerts du menu Control Panel) lorsqu’un compteur depasse le seuil indique.Les parametres alpha et beta sont quant a eux propres a l’algorithme heuristique Holt-winter. Les alertesgenerees par cet algorithme (rrd anomaly) seront ensuite visibles dans le sous-menu Anomalies du menuReport. Elles n’apparaıtront donc jamais dans le meme sous-menu que les alertes de types rrd threshold.

Parametres de configuration a disposition

Attribute Nom du parametre (compteur Ntop) pour lequel la ligne de configuration s’applique.

Threshold Seuil que l’attribut devra atteindre pour qu’une alerte rrd threshold soit generee.

Priority Priorite de l’alerte rrd threshold entrant de le calcul du risque effectue par le serveur lors de lareception de l’alerte (priorite non associee aux alertes de type rrd anomaly).

Alpha Parametre alpha de l’algorithme heuristique Holt-winter generant une alerte de type rrd anomaly.

Beta Parametre beta de l’algorithme heuristique Holt-winter generant une alerte de type rrd anomaly.

Persistence Nombre de fois qu’un depassement de seuil ou qu’une anomalie doit etre apercue pourl’attribut en question afin qu’une alerte rrd threshold ou rrd anomaly (suivant le cas) soit generee.

Enable Activation ou non de l’attribut dans le profile.

Il est important de noter que le plugin RRD effectue periodiquement (chaque 300 secondes) l’analyse desdonnees fournies par Ntop (stockee dans la base de donnee tourniquet RRD). Le parametre persistencese base donc sur cette granularite afin de decider de la generation d’une alerte. En effet, si celui-ci estconfigure a 3, il faudra que trois controles successifs des valeurs (anomalie et/ou seuil) soit superieur auxvaleurs autorisees afin qu’une alerte soit generee (alerte rrd anomaly et/ou rrd threshold). Cela signifieraqu’un depassement aura ete observe durant au moins 15 minutes.

Configuration

L’unite des attributs (pour la configuration des seuils) n’est malheureusement pas indiquee sur l’interfacede configuration. Certains attributs sont exprimes de maniere relative alors que d’autres de maniere ab-solue (par exemple : bit/s et bit). Afin de connaıtre l’unite utilisee par chaque attribut, il est preferable deconsulter leurs graphiques via Ntop. En effet, l’unite est indiquee verticalement sur la gauche des graphs.

Les valeurs configurees pour les seuils sont utilisees pour des periodes de 5 minutes (par defaut). Parexemple, cela signifie que si IPHTTPrcvdBytes vaut 8000, nous acceptons de recevoir 8ko du protocole



HTTP toutes les 5 minutes, donc en quelque sorte 8ko/5min.

La configuration des parametres propres a l’algorithme Holt-Winter sont expliques dans l’annexe J.Tous ces parametres permettent l’adaptation de la detection de seuils et de l’algorithme heuristique Holt-Winter en fonction du segment reseau a surveiller.

ATTENTION : OSSIM Version : 0.9.8rc2 contient des erreurs d’implementation sur l’utilisation deHolt-Winter par rrd plugin.pl ! !

4.9.5 Host scan

Ce sous-menu permet la visualisation des hotes a scaner a l’aide de Nessus ou Nmap.

4.10 Tools Menu

Ce menu offre trois differents sous-menus :

4.10.1 Net Scan

Ce sous-menu fait office d’interface avec le programme Open Source de scan reseaux nmap. Il permettraainsi de scanner l’un des reseau definit dans le sous-menu Network du menu Policy ou d’indiquer ma-nuellement la plage d’adresses a scanner.Une fois le scan opere, il sera possible d’inserer ou mettre automatiquement a jour la configuration (dusous-menu Hosts du menu Policy) des machines detectees en cliquant sur le bouton update databasevalues.

4.10.2 Rule viewer

Ce sous-menu offre simplement une interface de consultation des regles Snort. En effet, il peut etreinteressant d’observer la syntaxe d’une regle plutot que son nom. Pour l’utilisation de cette fonctionna-lite, il sera necessaire d’installer (copier) la totalite des regles Snort dans le repertoire /etc/snort/rules/du serveur OSSIM.

4.10.3 Backup

Ce sous-menu permet la gestion des backups des alertes. En effet, le script /etc/cron.daily/acid-backup.plplace sur le serveur OSSIM archivera journalierement les vieilles alertes contenues dans ACID permat-tant ainsi de limiter le temps de recherche des alertes dans la base de donnees. Ce sous-menu affichera

14http ://www.insecure.org/nmap/



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



FIG. 4.1 – Arborescence des menus d’OSSIM



FIG. 4.2 – Principe de d’accumulation des alertes opere par CALM


Chapitre 5

Conclusion

OSSIM se revele etre une solution proposant des concepts d’analyses tres innovateurs. En effet, peu desolutions Open Source proposent actuellement une telle palette de procedes d’analyse d’evenements desecurite :

– Recuperation d’evenements d’infrastructures heterogenes (alertes de NIDS, logs, etc...).

– Attribution d’une severite a chaque evenement en fonction de l’attention que l’on porte au bienpotentiellement attaque (priorization des alertes).

– Correlation croisee (Nessus - Snort) permettant la modification de la severite des alertes en fonc-tion des vulnerabilites de la cible de l’attaque potentielle.

– Analyse comportementale du reseau permettant la generation d’alertes en fonction du comporte-ment des utilisateurs (Ntop et l’algoritme Holt-Winter de RRD).

– Correlation des evenements et integration des evenements de l’analyse comportementale dans ceprocede.

Etant toujours en developpement, OSSIM reste malheureusement encore non utilisable dans un envi-ronnement de production. En effet, son installation et les tests preliminaires semblent encore poser pas-sablement de problemes. Les developpeurs d’OSSIM ont principalement concentre leurs efforts sur lesprocedes d’analyse (encore inexistant sur des solutions Open Source). Leurs conceptes innovateurs re-posent des lors sur des bases quelques peu instables et difficiles a faire co-exister.En terme de concepts et de procedes d’analyse, OSSIM n’a rien a envier aux solutions commercialesd’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 securite (http ://www.exaprotect.com/fr/eas-1.jsp) jusqu’a peu, basee sur Prelude-ids une solution Open Source de grande qualite.

La solution Open Source Prelude-ids (http ://prelude-ids.org), etudiee et utilisee dans les deux premieresphases du projet SIMS, offre quant a elle des fonctionnalites de detection (Snort et recuperation de

45


logs), centralisation et normalisation (IDMEF1) tres robustes. En effet, l’equipe Prelude-ids a concentreses efforts sur le rapatriement d’evenements de securite avec la triade CIA (Confidentiality, Integrity,Availability) comme ligne directrice. Ce projet de grande qualite n’offre malheureusement encore aucunesolution avancee d’analyse des donnees, bien que l’integration d’un outil de correlation Open Source(SEC, aborde dans le chapitre 7 du document http ://www.fullsecurity.ch/liens/sims-webJwinteregg.pdf)soit en cours.

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


Annexe A

Installation et configurationd’Ossim-server

Ce chapitre decrit toutes les etapes 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 Prerequis

Disposer d’une machine Linux Debian ayant un noyau 2.6.xx. Avoir configure le manager de paquetsDebian (aptitude) afin qu’il recupere ceux-ci sur le site Web d’Ossim (cf. Section B.1.1).

A.2 Installation

Installation de la base de donnee MySql-Ossim :

# apt-get install ossim-mysql

Creation du compte root et mise en place de son mot de passe :

# mysqladmin -u root password your_secret_password

Vous pouvez ensuite editer le fichier /etc/mysql/my.cnf afin de choisir l’adresse IP (bind-address) associeeau serveur MySql.

La creation des bases de donnees s’opere simplement a l’aide des commandes suivantes :

# mysql -u root -p

1Serveur 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 correlation et recuperation des donnees des agents) :

# apt-get install ossim-server

Installation du framework (interface Web) ainsi que du paquetage de la gestion des droits d’acces auserveur Web :

# apt-get install phpgacl

# apt-get install ossim-framework

Installation du paquetage utils permettant la gestion des connexions a la base de donnee Ossim :

# apt-get install ossim-utils

Installation de Nessus (pour la detection des vulnerabilites). Installation du serveur Nessus :

# apt-get install nessusd

Il est aussi possible de directment telecharger la derniere archive d’installation sur http ://www.nessus.org/download/.En effet cette derniere version de Nessus (v.2.2.5) offre la possibilite de mettre a jour automatiquement lesregles Nessus via un simple enregistrement sur http ://www.nessus.org/. Vous devrez ensuite simplementsuivre les instructions donnees par le script d’installation. A l’aide de l’installation par defaut, la racine duserveur Nessus se trouvera alors dans /usr/local/. Ses fichiers de configuration dans /usr/local/etc/nessuset les logs dans /usr/local/var/nessus.Installation du client (utilise par le script /usr/share/ossim/script/do nessus.pl, execute par le frameworklors d’une demande de scan) pour l’execution des scan nessus :

# apt-get install nessus



A.3 Configuration

A.3.1 Ossim plate-forme

Tous les paquetages intalles ci-dessus offrent une configuration garphique ncruses a l’installation. Celle-ci peut etre effectuee 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 donnees serontnecessaire. Il convient donc ensuite de creer ces utilisateurs. Si nous choissons de nous connecter auxbases de donnees a l’aide d’un utilisateur nomme ossim ayant comme mot de pase ossim pass, il seranecessaire d’operer ainsi afin d’ajouter cet uilisateur sur les differentes bases de donnees :

# mysql -u root -p

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

-> IDENTIFIED BY ’ossim_pass’ WITH GRANT OPTION;

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


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


mysql> FLUSH PRIVILEGES;

Ici, nous offrons tous les privileges a l’utilisateur ossim sur les bases de donnees necessaires (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 del’interpreteur PHP afin que le site d’Ossim puisse fonctionner. Ceci s’opere 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 deconfiguration principal d’Apache. Le fichier de configuration d’Apache pour Acid2 n’est par contre pasdirectement fourni dans ce repertoire. Il est donc necessaire de le copier afin qu’Apache soit capable deservir les pages web d’Acid :

2Viewer pour les alertes Snort et Ossim



# cp /etc/acidlab/apache.conf /etc/apache/conf.d/acid.conf

Il est ensuite necessaire de modifier la configuration par defaut d’Apache pour Ossim, afin que celui-cisoit capable de suivre les liens symboliques. En effet, un lien symbolique est utilise pour l’affichagedes vulnerabilites decouvertes 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 deja definies) :

Options FollowSymLinks

A.3.3 Nessus client-serveur

Il est necessaire d’ajouter un user au serveur Nessus afin le framework (script do nessus.pl) puisse l’uti-liser pour executer des scans. Ceci s’opere sur le serveur a l’aide de la commande nessus-adduser. Ilsuffira ensuite de completer les informations requises comme illustre ci-dessous :

# nessus-adduser

Using /var/tmp as a temporary file holder

Add a new nessusd user

----------------------

Login : <yourUserLogin>

Authentication (pass/cert) [pass] :

Login password : <yourUserPass>

Login password (again) : <yourUserPass>

Il faudra maintenant configurer correctement les champs nessus user et nessus pass du sous-menu Maindu menu de Configuration du framework afin que les scripts utilisants Nessus soient capables de seconnecter au serveur Nessus. Le champ nessus user devra contenir yourUserLogin entre ci-dessus etnessus pass devra contenir yourUserPass.

Il est maintenant possible de mettre a jour les regles de tests (contenues dans Nessus) sur le framework.Le script update nessus ids.pl s’occupe de ca (via l’utilisation du client Nessus et des informations confi-gurees ci-dessus) :

# /usr/share/ossim/scripts/update_nessus_ids.pl

A.3.4 Cross correlation via Nessus

Pour que l’ajustement des priorites des alertes en fonction des vulnerabilite de la machine cible (vulnerabilitesdetectees par Nessus) soit possible, il est necessaire de mettre a jour les relations entre les alertes Snort etles regles NASL3 Nessus (relations enregistrees dans la table plugin reference de Mysql). Ces relationssont contenues dans l’archive snort nessus.sql.gz qu’il faut fournir au client mysql afin que celui-ci mettea jour la base de donnee d’Ossim :

3Nessus Attack Scripting Language, language permettant d’etablir des regles de test Nessus



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


Annexe B

Ajout et configuration d’une sonde Snort

Les manipulations decrites ci-dessous requierent un serveur Ossim operationnel (installation decrite dansla 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 afinde recuperer l’application Snort directement patchee. Il est necessaire d’ajouter la ligne suivant dans/etc/apt/source.list afin que le gestionnaire de paquets de Debian (aptitude) soit capable de recuperer lespaquetages d’Ossim :

deb http://www.ossim.net/download/ debian/

Il est ensuite necessaire de creer un fichier de preferences /etc/apt/preferences afin que Debian aille enpremier lieu rechercher les paquetages disponibles sur Ossim plutot que ceux disponibles sur d’autresserveurs. Nous serons ainsi certain d’obtenir la version patchee de Snort :

Package: *Pin: release o=ossim

Pin-Priority: 995

Apres la mise a jour des paquetages disponibles, il est possible de downloader Snort :

# apt-get update

# apt-get install snort-mysql

Pour plus 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 recuperer des paquets sur les serveurs d’OSSIM, il suffit de taperla commande suivante afin d’installer Ossim-agent :

# apt-get install ossim-agent

L’installeur de paquets de Debian va maintenant vous questionner afin de creer une configuration debase. Reportez-vous a la section suivante (section B.2.2) pour plus de details.

B.2 Configuration

B.2.1 Snort

Comme mentionne plus haut, le logiciel de detection d’intrusion Snort utilise son plugin de sortie Mysqlafin de transmettre directement ses alertes en direction d’une des bases de donnees d’Ossim-server (SnortBD). Celui-ci disposera alors de tous les details de chaque alertes levee par la sonde.Le second plugin de sortie utilise est ”logfile=fast.log”. Il s’agıt d’un plugin developpe par OSSIM tresproche de ”alert full”1 directement integre a Snort. Fast.log place simplement les differentes alertes dansun fichier de logs qui sera ensuite lu par l’agent Ossim qui s’occupera de transmettre ces informationsvers le serveur Ossim (permettant ainsi l’analyse temps reel).

La configuration des plugins de sorties de Snort ressemble donc a ceci (fichier : /etc/snort/snort.conf ) :

output database: alert, mysql, user=snort password=myPass

dbname=snort host=sgbdServerIP sensor_name=MonSensor logfile=fast.log

Les champs user, password, dbname et host correspondent aux informations relative a la base de donneeSnort distante. Il est donc necessaire de creer un nouvel utilisateur sur celle-ci afin que la sonde puisses’y connecter a l’aide du mot de passe indique. L’ajout d’un utilisateur sur la base de donnee Snortsera detaille ci-dessous (section B.3). De plus, il est indispensable de retirer le script de demarrageautomatique de Snort afin que la sonde puisse etre directement activee par le Serveur (via Ossim-agent).Ceci s’opere a l’aide de la commande suivante :

# update-rc.d -f snort remove

Mise a jour des regles sur le serveur Ossim

La mise a jour des regles Snort permet l’utilisation de celles-ci dans les scenarii de correlation. Eneffet, le menu de ”Correlation - Directives” du framework permet l’utilisation des alertes Snort dans

1fast.log ajout simplement deux parametres supplementaire a alert full afin d’augmenter les performances du serveur. Infosur : https ://sourceforge.net/forum/message.php ?msg id=2627915



la definition de scenarii de correlation. L’utilisation du SID des alarmes permet de les referencer dansles regles de correlation. Celui-ci doit donc etre unique pour chaque plugin. Il convient donc lors decreation de regles Snort de ne pas les dupliquer (un controle est quand meme effectue par le script/usr/share/ossim/scripts/create sidmap.pl de mise a jour des regles dans la base de donnee du serveurOssim). La mise a jour des regles sur le serveur Ossim requiert le client Mysql puisque le script procedeau controle de la duplication des regles et fournit les commandes SQL a entrer dans le client. Ce scriptdoit evidemment etre execute sur l’agent hebergeant 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 unconnexion vers la base de donnee du serveur Ossim (a ecrire sur une ligne) :

# /usr/share/ossim/scripts/create_sidmap.pl /etc/snort/rules | mysql

--host=<serverIP> -u ossim ossim -p

Le user ossim utilise pour la connexion du client mysql doit beneficier des droits suffisants pour la com-mande Sql INSERT.Pour que l’insertion se passe correctement (avec l’enregistremenent du champ msg des regles Snort dansla base de donnee Ossim), il est necessaire que le champ classtype soit present dans la regle Snort.

Effacer des regles de plugins dans Ossim Pour se faire, il est necessaire de directement ”taper”dans la base de donnee d’Ossim. Il sera alors necessaire d’utiliser un client Mysql (mysql-client ouphpMyAdmin). Via mysql-client, il suffira de se connecter a la base de donnee a l’aide d’un user ayantles droits Delete, et de taper la requete suivante (avec le bon id et sid) :

mysql> DELETE FROM plugin_sid WHERE plugin_id=<id> and sid=<sid>;

B.2.2 Ossim-agent

Sa configuration s’effecture directement a l’aide du menu de configuration des paquets Debian et peutetre 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 reseau a utiliser (pour la communication avec le serveur)

3. L’adresse IP du serveur OSSIM

4. Les plugins qui vont etre connecte a cet agent. Dans notre cas, uniquement Snort (illustre a lafigure B.1)

L’executable de l’agent Ossim est ensuite directement lie dans les runlevels appropries afin qu’un demarrageautomatique s’effectue a chaque boot de la machine.



FIG. 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 procedure d’ajout d’un nouveau sensor doit etre effectue via l’interface Web du serveur Ossim. Celle-ci est decrite dans le manuel disponnible a l’URL suivante : http ://www.ossim.net/docs/User-Manual.pdfLors de l’ajout d’un sensor local (agent place sur le serveur Ossim), il faudra bien prendre garde despecifier correctement l’adresse du serveur Ossim dans la configuration de l’agent (/etc/ossim/agent/config.xml).En effet, pour une bonne generation des liens HTML du framework, il sera necessaire de ne pas specifierl’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’acces dans la base de donnee snort afinque cette nouvelle sonde (=nouvel utilisateur) soit capable d’y deposer directement ses alertes (commeillustre sur la figure 3.1). Il est donc necessaire de se trouver sur la machine serveur afin d’y entrer lesrequetes SQL pour l’ajout d’un utilisateur.Lancement du client Mysql local et utilisation de la base de donnee snort :

# mysql -u root

mysql> use snort;

Requetes SQL a entrer pour 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 acces total a la base de donnee snort du serveur.Son mot de passe (a indiquer dans la configuration de Snort, section B.2.1) est maintenant passwordDeS-nort.

B.4 Test de fonctionnement

Maintenant que l’agent Ossim est configure et que la base de donnee snort est accessible depuis celui-ci,nous pouvons tester le fonctionnement de l’agent (le serveur doit etre en marche).Il est maintenant possible de demarrer l’agent Ossim (en mode de debug afin de controler 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, defaulting to snort.conf

(--) pyossim.ParserSnort (2005-04-27 11:38:04): plugin started (fast)...

.

(=>) pyossim.Agent (2005-04-27 11:38:05): plugin-start plugin_id="1001"

Vous pouvez maintenant executer l’agent Ossim en tache de fond :

# ossim-agent -d

Votre nouvelle sonde Snort est prete a l’emploi !

B.4.1 Erreur de demarrage 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 recupere l’agent (pour l’envoi temps reel des infor-mations au serveur), n’a pas ete trouve. Il est alors necessaire de modifier la configuration du plugin



Snort afin d’y indiquer le bon chemin (le bon fichier de log). Celle-ci est decrite dans le fichier XML/etc/ossim/agent/plugins/snort.xml. Il est indispensable de modifier la balise location afin d’y indiquerl’emplacement reel du fichier de log de Snort (genere par le plugin fast.log de Snort), comme illustreci-dessous :

<plugin id="1001" process="snort" type="detector" start="yes" enable="yes">

.......... balises de configuration ...........

<location>/var/log/snort/fast.log</location>

</plugin>


Annexe C

Ajout et configuration de Ntop

Les manipulations decrites ci-dessous requierent un serveur Ossim operationnel, ainsi qu’un agent Ossiminstalle sur la machine qui hebergera Ntop (l’installation de l’agent est decrite dans la section B.1.2puisqu’il s’agıt, dans notre cas, du meme agent que pour la sonde Snort).

C.1 Installation

C.1.1 Ntop

Installation de Ntop et des librairies necessaires :

# apt-get install librrd0 ntop

Installation du paquetage ossim-utils fournissant le script d’analyse des informations de Ntop(/usr/share/ossim/scripts/rrd plugin.pl) ainsi que le fichier de configuration necessaire pour l’interroga-tion de la base de donnee Ossim par rrd plugin.pl (permettant la recuperation de la configuration desseuils defini par l’administrateur reseau sur le framework) :

# apt-get install ossim-utils

Pour les details de la configuration de ce paquetage consultez la section C.2.2.

Installation des outils utilises par le script rrd plugin.pl pour la recuperation des informations dans labase de donnee RRD :

# apt-get install rrdtool librrd0-dev librrdp-perl librrds-perl python-mysqldb

58


C.2 Configuration

C.2.1 Ntop

Configuration du mot de passe admin pour Ntop :

# ntop -u ntop

>> Please enter the password for the admin user:

#

Comme mentionne dans la section 3.3.1, Ntop dispose d’une interface Web pour le monitoring ainsi quepour sa configuration. Le serveur Web s’installe par defaut sur le port 3000. Il est maintenant necessairede configurer le format des logs de sortie (plugin RRD) afin que le script rrd plugin.pl soit capable de lesrecuperer 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 decelui-ci devient editable. Vous pouvez maintenant cliquer sur Host dans le menu Data to Dump puisentrer votre masque de sous-reseau dans Hosts Filter. Il est encore necessaire de controler que le RRDFiles Path soit le meme que celui fournit dans le framework de configuration (Configuration - Main -rrdpath ntop). En effet le script Perl rrd plugin.pl recupere la configuration des seuils sur le framework,ainsi que les chemins d’acces aux fichiers de logs.

Il est ensuite necessaire 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 recuperer lesdonnees de la base de donnee 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.pmpermettant de recuperer la configuration etablie dans le framework (configuration etablie dans Configu-ration - Main). Il est necessaire de configurer correctement ce paquetage afin que ce module soit capablede se connecter a la base de donnee distante. Il faudra lui indiquer un utilisateur Mysql, capable de seconnecter depuis l’agent Ossim. Dans notre cas, nous indiquerons l’utilisateur snort precedemment confi-gure (cf. section B.3). Editee a la main (/etc/ossim/framework/ossim.conf) cette configuration ressemblea ceci :

################

# OSSIM db configuration

################



ossim_type=mysql

ossim_base=ossim

ossim_user=snort

ossim_pass=E1ephant

ossim_host=10.192.72.172

ossim_port=3306

Celle-ci peut aussi etre aisement editee a l’aide de dpkg via la commande suivante :

# dpkg-reconfigure ossim-utils

Ossim-agent

Le script rrd plugin.pl recupere de lui meme (sans appel a config.pm) les informations relatives a laconfiguration des seuils dans la base de donnee Ossim distante. Il est donc necessaire de lui indiquercorrectement les memes 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 utilisees par certains plugins(dont le plugin RRD). La definition de l’ENTITY suivant avec les bon parametres de connexion estnecessaire :

<!ENTITY ossim_db "mysql:10.192.72.172:ossim:snort:E1ephant" >

Il faut ensuite reconfiguer l’agent Ossim afin de preciser que Ntop est active sur cet agent. Etant donneque rrd plugin.pl est utilise pour l’analyse des donnees, il est necessaire d’indiquer que le plugin RRDest aussi en fonction. La figure C.1 illustre cette nouvelle configuration executee a l’aide de la commandesuivante :


FIG. 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 ete effectuee sur un sensor existant (comme dans notre cas), il ne sera pasnecessaire d’enregistrer un nouvel agent sur l’interface Web du serveur. L’agent existant transmettra delui meme l’existance d’une nouvelle sonde au serveur. Dans le cas contraire (mise en place de cette sondesur un nouvel agent), il sera necessaire de proceder a l’enregistrement du nouvel agent, comme expliquedans 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 basede donnee, afin que celui-ci soit capable de recuperer la configuration sur le serveur :

# mysql -u root

mysql> use ossim;

Requetes SQL a entrer pour 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 etre effectue via phpMyAdmin.


Annexe D

Ajout et configuration de P0f

Les manipulations decrites ci-dessous requierent un serveur Ossim operationnel (installation decrite dansla section A), ainsi qu’un agent Ossim installe sur la machine qui hebergera P0f (l’installation de l’agentest decrite dans la section B.1.2 puisqu’il s’agıt, dans notre cas, du meme agent que pour la sonde Snort).

D.1 Installation

Son installation necessite uniquement l’installation du paquetage P0f :

# apt-get install p0f

D.2 Configuration

D.2.1 P0f

P0f ne necessite aucune configuration supplementaire puisque le chemin de son fichier de log lui estfourni par l’agent Ossim lors de son execution.

D.2.2 L’agent Ossim

Il est necessaire de reconfiguer l’agent Ossim afin de preciser que P0f est active sur cet agent. Celle-cis’opere a l’aide de la commande suivante :


62

Annexe E

Ajout et configuration de TCPTrack

Les manipulations decrites ci-dessous requierent un serveur Ossim operationnel (installation decrite dansla section A), ainsi qu’un agent Ossim installe sur la machine qui hebergera TCPTrack (l’installation del’agent est decrite dans la section B.1.2 puisqu’il s’agıt, dans notre cas, du meme agent que pour la sondeSnort).

E.1 Installation

Celle-ci est vraiment tres simple puisqu’il suffira de recuperer le paquetage Debian de TCPTrack sur leserveur Web d’Ossim1 via la commande suivante :

# apt-get install tcptrack

E.2 Configuration

Aucune configuration specifique n’est necessaire pour TCPTrack puisque c’est le serveur Ossim quis’occupera d’interoger TCPTrack. Il sera par contre indispensable d’indiquer a l’agent qu’une nouvellesonde lui a ete ajoutee. Ceci s’operera via le menu de configuration offert par la commande suivante :


1Il est donc indispensable d’avoir configure aptitude afin qu’il recupere directement les paquetages chez Ossim (cf. SectionB.1.1). En effet, la version de TCPTrack utilisee dans l’architecture d’Ossim est une version modifiee de la version originale.

63

Annexe F

Ajout et configuration d’une sonde HIDSSyslog

Les manipulations decrites ci-dessous requierent un serveur Ossim operationnel (installation decrite dansla section A), ainsi qu’un agent Ossim installe sur la machine qui hebergera cette sonde HIDS Syslog(l’installation de l’agent est decrite dans la section B.1.2 puisqu’il s’agıt, dans notre cas, du meme agentque pour la sonde Snort).

F.1 Installation

Aucune installation n’est requise puisque le parser de fichiers de log Syslog et directement present surtous 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 execute par l’agent. Pour cefaire, il vous suffira de l’activer a l’aide du menu de configuration offert par la commande suivante :


La configuration du fichier a controler peut etre directement faite en modifiant la balise location du fi-chier /etc/ossim/agent/plugins/syslog.xml. Par defaut celui-ci est /var/log/auth.log.Sous Debian il sera en plus necessaire de modifier (dans le meme fichier de configuration) le nom dudaemon de logging puisque celui-ci se nomme sysklogd et non pas syslog.

L’ajout de nouvelles regles necessitera malheureusement la modification du code du parseur /usr/share/ossim-agent/pyossim/ParserSyslog.py puisque celles-ci s’y trouvent directement integrees. Aucun fichier deconfiguration des regles n’est pour le moment disponnible.

64

Annexe G

Ajout et configuration d’une sonde HIDSIIS

Les manipulations decrites ci-dessous requierent un serveur Ossim operationnel (installation decrite dansla section A), ainsi qu’un agent Ossim installe sur la machine qui hebergera cette sonde HIDS IIS1

(l’installation de l’agent est decrite dans la section B.1.2 puisqu’il s’agıt, dans notre cas, du meme agentque pour la sonde Snort).

G.1 Installation du plugin

Aucune installation n’est requise puisque le parser de fichiers de log est directement present sur tous lesagents (fichier /usr/share/ossim-agent/pyossim/ParserIIS.py).

G.2 Installation de Snare IIS (rapatriement des logs vers un serveur Sys-log)

Du cote du serveur web, il est necessaire d’installer un logiciel client capable d’emettre les logs vers unserveur de logs Linux. Vous pouvez donc telecharger librement le logiciel Open Source Snare disponiblea l’adresse suivante : http ://www.intersectalliance.com/projects/SnareIIS/index.html#DownloadSon installation est ensuite extrement simple. Il vous suffira de suivre les quelques instructions a l’ecran...

1Internet 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 execute par l’agent. Pour cefaire, vous devrez l’activer a l’aide du menu de configuration offert par la commande suivante :


La configuration du fichier de log a controler peut etre directement faite en modifiant la balise locationdu fichier /etc/ossim/agent/plugins/iis.xml. Par defaut celui-ci est /var/log/syslog.Sous Debian il sera en plus necessaire de modifier (dans le meme fichier de configuration) le nom dudaemon de logging puisque celui-ci se nomme sysklogd et non pas syslog.

L’ajout de nouvelles regles necessitera malheureusement la modification du code du parseur /usr/share/ossim-agent/pyossim/ParserIIS.py puisque celles-ci s’y trouvent directement integrees. Aucun fichier de confi-guration des regles n’est pour le moment disponible.

Configuration du serveur Syslog Linux (present sur l’agent OSSIM)

Syslogd est le daemon s’occupant de la recuperation de logs d’une machine Linux. Par defaut celui-citravaille uniquement en local. Lors de son lancement (commande syslogd), via l’argument ”-r”, il estpossible de lui indiquer d’ouvrir le port 514 UDP pour la recuperation de logs distants. Nous modifionsdonc son script de lancement ”sysklogd” place dans /etc/ini.d/. Il suffira donc d’ajouter le ”-r” dans lavariable SYSLOGD deja presente dans ce fichier, comme illustre ci-dessous :

# Options for start/restart the daemons

# For remote UDP logging use SYSLOGD="-r"

SYSLOGD="-r"

Nous pouvons ensuite relancer le daemon qui attendra maintenant des messages syslog sur le port 514 :

jo:/etc/init.d# ./sysklogd restart

Il est important de preciser que le protocole de transfert de logs base sur UDP n’est pas securise. Lestrames circulent ”en clair” sur le reseau. De plus l’utilisation d’UDP implique une eventuelle possibilitede perte des paquets sans qu’aucun des deux partenaires ne s’en rende compte (principe meme d’UDP).

G.3.2 Configuration du serveur IIS (client Snare IIS)

La figure G.1 illustre la configuration du client Snare effectuee, afin que la station 192.168.1.2 recoiveles 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 estindispensable de configurer une rotation des logs journaliere ainsi qu’un format etendu (W3C extended



FIG. G.1 – Configuration de l’utilitaire de recuperation des logs d’IIS

Log File Format) afin que Snare soit capable de les lire. Cette configuration est accessible dans le menude configuration de IIS, dans l’onglet Web Site. En cliquant sur le bouton Properties..., il sera possiblede definir la periode de rotation des logs ainsi que leur format.De plus, le parser IIS d’OSSIM (/etc/ossim/agent/plugins/iis.xml) necessite un format de log tres precisafin d’etre capable de les interpreter. Il sera donc necessaire de configurer les logs d’IIS afin que lesinformations suivantes soient presentent :

– Heure

– Date

– Client IP

– Server IP

– Server port

– Method

– URI stream

– URI query

– Protocol Status


Annexe H

Ajout et configuration de PADS

Les manipulations decrites ci-dessous requierent un serveur Ossim operationnel (installation decrite dansla section A), ainsi qu’un agent Ossim installe sur la machine qui hebergera PADS (l’installation del’agent est decrite dans la section B.1.2 puisqu’il s’agıt, dans notre cas, du meme agent que pour la sondeSnort).

H.1 Installation

Celle-ci est vraiment tres simple puisqu’il suffira de recuperer le paquetage Debian de PADS, via lacommande suivante :

# apt-get install pads

H.2 Configuration

Aucune configuration specifique n’est necessaire pour PADS puisque le chemin de ses logs de sortie estdirectement fourni par l’agent Ossim (parametre lors de son execution). Il sera par contre indispensabled’indiquer a l’agent qu’une nouvelle sonde lui a ete ajoutee. Ceci s’operera via le menu de configurationoffert par la commande suivante :


68

Annexe I

Creation de regles de correlation

I.1 Introduction

Cette annexe vous apprendra a creer vos propres directives de correlation. La structure et syntaxe decelles-ci est decrite dans ce chapitre.

I.2 Ajout d’un fichier de regles sur le serveur

Pour ce faire, il suffit de creer un nouveau fichier de regles sur le serveur et de le placer dans le repertoire/etc/ossim/server/. Si celui-ci se nomme mesRegles.xml, il sera indispensable d’indiquer au serveur decharger ce fichier afin que les regles presentent dans celui-ci soient utilisees. Pour se faire, il vous suffitd’editer 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 regles existantes a l’affichage ...

&myRules;

..... suite de la config ....

</directives>

Chaque regle sera ensuite automatiquement triee lors de son affichage dans le framework. Lors de lacreation de regles, iI sera indispensable de respecter la numerotation de l’attribut id des balises direc-

69


tives mentionne dans Directive numbering du sous-menu Directives du framework. De cette maniere, lesnouvelles regles seront directement affichees dans la categorie voulue.

I.3 Syntaxe XML

Cette section est partiellement tiree du document de Sebastien Contreras et des exemples fourni auxURLs suivantes :http ://www.ossim.net/docs/correlation engine explained rpc dcom example.pdfhttp ://www.ossim.net/docs/correlation engine explained worm example.pdf

Nous allons, en premier lieu, reprendre la definition des differentes balises utilisables dans les regles decorrelation :

I.3.1 Balise directive

Cette balise englobe la directive de correlation entiere. Elle permettra de definir les parametres globauxde celle-ci. Ceux-ci sont :

– l’id de la directive de correlation, attribut id

– le nom de celle-ci affiche dans le framework, attribut name

– la priorite de la regle, attribut priority

I.3.2 Balise rule

Cette balise permet la definition d’une regle utilisee dans le processus de correlation de la directive. Ilsera possible d’en definir ses caracteristiques a l’aide des attributs suivants :

– Le type de la regle, attribut type

– Le nom de celle-ci, attribut name

– La provenance de l’alerte que nous attendons, attribut plugin id

– Le numero d’evenement1 de l’alerte du plugin que nous attendons, attribut plugin sid

– Le parametre de fiabitite (reliability) entrant dans le calcul du risque, attribut reliability

– La fenetre temporelle dans laquelle la regle doit etre matchee, attribut time out

– Le nombre de fois que doit etre matche la regle afin de passer a la suivante, attribut occurence

– Le type de protocole sur lequel s’applique la regle, attribut protocol

– L’adresse IP source de la trame matchee par la regle, attribut from

– L’adresse IP de destination de la trame matchee par la regle, attribut to

1Reference chaque plugin offerte par le sous menu Plugins du menu Configuration



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

– Le port de destination de la trame matchee par la regle, attribut port to

– La condition a appliquer si le controle d’une quantite vehiculee par l’alerte est necessaire, attributcondition

– La valeur a comparer (a l’aide de la condition definie par l’attribut precedent) a la quantite vehiculeepar l’alerte, attribut value

– Valeur permettant de definir si la valeur a comparer (value) est absolue ou relative, attribut absolute

– L’interval dans lequel la regle doit s’appliquer (equivalent au time out mais utilise pour les reglesmonitor), attribut interval

– Parametre permettant de geler les parametres non defini2 dans la directive (utilise lorsque l’occu-rence d’une regle est superieur a 1), attribut sticky

– Parametre permettant de forcer un attribut a etre different lorsque plusieurs occurence de la reglesont attendues, attribut sticky different

Lorsqu’une regle (rule) est matchee, cela a pour effet de declencher le passage a la regle suivante conte-nue dans la directive. Il s’agit donc d’un ET entre les regles impriquees dans rule.

I.3.3 Balise rules

Cette balise permet l’encapsualtion d’une ou plusieurs regles (balise rule). Si plusieur regles rule sontpresentes au meme niveau (sans imbrications) a l’intereur de la balise rules, un OU est opere entrecelles-ci (exemple : la 1ere regle ou la deuxieme regle ou la 3 eme regle... ). Cette balise ne contientaucun attribut.

I.3.4 Syntaxe des attributs de caracteristiques

Nous allons maintenant reprendre la definition des attributs utilisables (parametres) dans les differentesbalises XML.

balise directive

id Cet attribut permet la definition de l’identifiant unique de la directive de correlation. Cette numerotationdoit suivre les directives emises par Ossim afin que le tri d’affichage effectue dans le framework (sous-menu directives du menu correlation) soit effectue correctement. Les directives de numerotation sontdisponible dans ce sous-menu.

name Cet attribut permet la definition du nom de la directive (affiche lorsque la directive est matchee).2parametres non utilise dans la directive



priority Cet attribut permet de definir la priorite de la directive de correlation. Pour plus d’informationssur la signification de la priorite d’un evenement, conslutez la section 4.3.

balise rule

Type Cet attribut definit le type de la regle. Il existe uniquement deux type de regles :

Detector regles utilisant les informations de detecteurs (snort, spade, syslog, ...) contenue dans la basede donnee du serveur.

Monitor regles utilisant les information des moniteurs (TcpTrack, Ntop, etc...). Dans ce cas, c’est leserveur qui aura la tache d’interroger le moniteur (agent) afin d’obtenir les informations voulues.

name Cet attribut permet de definir le nom de chaque regle. Celui-ci sera ensuite affiche dans le sous-menu backlog du menu correlation, permettant la visualisation des regles matchees par alertes de hautniveau (groupe d’alertes).

plugin id Cet attribut definit la provenance de l’alerte attendue par la regle. En effet, chaque plugin aun identifiant associe (identifiant affiche dans le sous-menu plugins du menu configuration) permettantde le referencer dans les regles de correlation.

plugin sid Cet attribut definit l’evenement associe au plugin (plugin id). En effet, tous les evenementrecupere par Ossim sont repertorie (en fonction de leur plugin) et configure3. La configuration des plu-gin sid est accessible en cliquant sur le plugin id voulu dans le sous-menu plugins du menu configura-tion. Par exemple, l’alerte fournie par le plugin id 1501 et le plugin sid 400 equivaut a : ”apache : BadRequest”. A l’aide de ces deux attributs (plugin id et plugin sid), il est possible de definir precisementl’evenement attendu par la regle.

reliability L’utilite de cet attribut est explique dans la section 4.3. Plus ce parametre est grand (prochede 10), plus il indique que l’alerte n’est pas un faut positif. Ce parametre prend alors une grand im-portance dans le procede de correlation. En effet, au fur et a mesure que des regles sont matchees, laprobabilite 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 premiere regle (rule)indique la reliabilite de depart de l’alerte de haut niveau. Les regles suivantes ont ensuite la possibilitede faire evoluer cette valeur de maniere relative (par exemple : +3, signifiant que la reliabilite globaleaugmente de 3 par rapport a la regle precedente) ou absolue (par exemple : 7, signifiant que maintenantla reliabilite vaut 7).

3Afin de leur assigner un niveau de priorite et de reliability (termes expliques dans la section 4.3)



time out Cet attribut permet d’indiquer le temps d’attente de l’evenement correspondant a la regle. Sicelui-ci n’arrive pas dans le temps imparti (configure en secondes a l’aide de cet attribut), la directivede correlation se termine et retourne le resultat ”calcule” des regles precedentes. Cet attribut permet depreciser la fenetre temporelle dans laquelle l’alerte (evenement) attendue par la regle doit apparaıtre.

occurence Cet attribut permet de creer une unique regle lorsque plusieurs occurence d’un memeevenement est attendu. Il est ainsi possible de definir le nombre d’evenements identique a attendre avantde passer a la regle suivante.

protocol Cet attribut permet de configurer le type d’evenements reseau attendu par la regle. Il estpossible d’en definir trois types :

1. TCP

2. UDP

3. ICMP

Cet attribut permet le referencement absolu. Cela signifie qu’il est possible de reprendre le type deprotocole matche par des regles precedentes. Pour ce faire, il suffira par exemple d’indiquer : proto-col=”1 :PROTOCOL” afin de preciser que le protocole de cette regle est identique au protocole matchepar la regle de premier niveau (premiere regle). Si l’on desire recuperer le protocole matche par la regledu deuxieme niveau, il suffira de preciser protocol=”2 :PROTOCOL”.

Cet attribut devra uniquement etre utilise lorsque l’evenement attendu par la regle fait partie de l’un destrois type de protocole disponible.

from Cet attribut permet de preciser l’adresse IP source de l’alerte attendue. Il est possible de la men-tionner de six differentes manieres :

1. ANY, indique que n’importe quelle adresse source sera matchee par cet attribut

2. x.x.x.x, adresse IP standard

3. Par referencement, fonctionnant sur le meme principe que le referencement de l’attribut protocole(exemple : 1 :SRC IP = adresse IP source de l’alerte matchee par le premier niveau de la directivede correlation, 2 :DST IP = adresse IP de destinaion de l’alerte matchee par le deuxieme niveaude la directive de correlation)

4. Par nom du reseau, il est possible d’utiliser une plage d’adresse IP en utilisant les nom de reseauxdefini a l’aide du framework (sous-menu network du menu policy). La variable HOME NET definitquant a elle tous les reseaux defini dans le framework.

5. Plusieurs adresses, cette syntaxe permet de preciser plusieurs adresses IP separees par des virgules

6. Negations, cette syntaxe permet l’utilisation de negations sur des adresses IP ou des nom dereseaux (exemple : !192.168.2.203,HOME NET)



Note sur la premiere syntaxe (ANY) : Il est evident qu’au niveau de la regle utilisant cette syntaxe celarevient au meme que de ne pas utiliser cet attribut. Cette syntaxe permettra, par contre, le referencement(a l’aide de la troisieme syntaxe) de l’adresse IP de cette alerte dans les regles suivantes.

Cet attribut ne devra pas etre utilise lorsque l’information attendue par la regle n’est pas une trame IP.

to Cet attribut permet de preciser l’adresse IP de destination de l’evenement attendu par la regle. Sasyntaxe est totalement identique a celle de l’attribut from.

Cet attribut ne devra pas etre utilise lorsque l’information attendue par la regle n’est pas une trame IP.

port from Cet attribut permet de preciser le port source du segment TCP ou datagramme UDP attendupar la regle. Celui-ci peut etre decrit par :

– Une liste de ports separe par des virgules

– ANY

– Un referencement absolu a l’aide des variables SRC PORT et DST PORT

Cet attribut ne devra pas etre utilise lorsque l’information attendue par la regle n’est pas un segment TCPou un datagramme UDP.

port to Cet attribut permet de preciser le port de destination du segment TCP ou datagramme UDPattendu par la regle. La syntaxe de celui-ci est identique a celle de l’attribut port from.Cet attribut ne devra pas etre utilise lorsque l’information attendue par la regle n’est pas un segment TCPou un datagramme UDP.

condition Cet attribut permet de definir le type de condition applique entre la quantite vehiculee al’aides des regles de type monitor et l’attribut value. Le type des quantites vehiculees par les monitorsont definies par le plugin sid du plugin id. Les valeurs de la condition peuvent etre les suivantes :

1. eq - egal

2. ne - non egal

3. it - plus petit que

4. gt - plus grand que

5. le - plus petit ou egal

6. ge - plus grand ou egal

value Cet attribut est simplement la valeur numerique a comparer avec la quantite vehiculee par l’alerted’un moniteur.



absolute Cet attribut permet d’indiquer si la valeur a comparer (value) a la quantite vehiculee par lemonitor est absolue ou relative a la fenetre temporelle d’application . Cet attribut prend donc les valeurstrue ou false.

Absolute=”true” Indique que la valeur (value) doit etre atteinte afin que la condition soit matchee

Absolute=”false” Indique que la valeur vehiculee par le plugin sid du plugin id doit etre incrementeede value durant la fenetre temporelle d’application de la regle afin que la condition soit matchee.

interval Cet attribut est similaire a l’attribut time out, mais il s’applique uniquement aux temps decomparaisons entre les quantites vehiculees par le plugin sid du plugin id et l’attribut value. Il permetainsi de definir la fenetre temporelle utilisee par l’attribut absolute.

sticky Cet attribut permettra, lors de l’attente de plusieurs occurence d’une meme regle (attribut occu-rence plus grand que 1), de geler les parametres non definis dans celle-ci. Sans cette possibilite, differentsevenements non identiques pourraient etre matches comme occurence d’une meme regle. En effet, les pa-rametres non defini dans une regle sont equivalents a ANY, provoquant ainsi la validation de l’evenement(matching), meme si celui-ci n’est pas exactement le meme (parametre non defini differents).Lorsque cet attribut est configure a true (sticky=”true”), les caracteristiques non defini des evenementsdevront etre strictement les meme que ceux de la premiere occurence afin que l’evenement soit matchea nouveau.

sticky different Cet attribut permet l’inverse de l’attribut sticky et doit etre utilise conjointement aveccelui-ci. En effet, pour la detection de scan de ports, il serait interessant de detecter des evenementsidentique ayant uniquement leur port de destination different. Il est ainsi possible de definir l’attributdevant etre different a chaque occurence de la regle. Sticky different pourra ainsi prendre les valeurssuivantes :

– SRC PORT

– DST PORT

– SRC IP

– DST IP

– PROTOCOL

Ces parametres pourront aussi utiliser le referencement absolu aborde dans les explications de l’attributprotocol.

I.4 Structures des directives de correlation

I.4.1 Exemple de structure des directives

L’exemple ci-dessous illustre le fonctionnement des regles de correlation :



<directive MyDirective>

<rule INTRO .. parametres .. >

<rules>

<rule A .. parametres .. >

<rules>

<rule C .. parametres .. />

</rules>

</rule A>

<rule B .. parametres .. />

</rules>

</rule INTRO>

</directive>

La regle rule INTRO est la regle declencheuse de la directive de correlation. Une fois celle-ci matchee,le moteur de correlation attend l’apparition de l’evenement rule A ou rule B avant de continuer (car lesregles A et B sont encapsulees au meme niveau dans une balise rules). Si rule A apparaıt, le moteur decorrelation attend l’apparition de rule C pour finir son travail sur cette directive. Si par contre rule Bapparaıt a la place de rule A, la correlation est terminee et une alerte de haut niveau est generee.

L’exemple suivant illustre le fonctionnement de regles successives :

<directive MyDirective>

<rule INTRO .. parametres .. >

<rules>

<rule A .. parametres .. >

<rules>

<rule B .. parametres .. >

<rules>

<rule C .. parametres .. />

</rules>

</rule B>

</rules>

</rule A>

</rules>

</rule INTRO>

</directive>

La regle rule INTRO est la regle declencheuse de la directive de correlation. Une fois celle-ci matchee, lemoteur de correlation attend l’apparition de l’evenement rule A avant de continuer (passer a la regle sui-vante). Lorsqu’un tel evenement apparaıt, le moteur de correlation attendra l’apparition de l’evenementsuivant permettant le passage a ruleB et ainsi de suite.

Nous remarquons que les OU logiques entre les regles (balise rule) sont construit a l’aide de regles dememe niveau a l’interieur d’une balise rules. Les ET logiques entre regles sont quant a eux simplement



construit par imbriquation de regles (balise rule). De plus, nous remarquons que les balises rules encap-sulent obligatoirement les regles (balise rule), meme si une unique regle est presente.

I.4.2 Structure de correlation realisable

La figure I.1, illustre un schema de correlation non realisable a l’aide de la syntaxe XML d’OSSIM.En effet, la syntaxe arborescente des regles empeche le passage de differents etats sur un etat commun(les etats 2 et 3 de la figure I.1 peuvent passer sur un meme etat ”etat 4”). Pour qu’une telle structuresoit realisable a l’aide d’OSSIM, il sera indispensable de la decomposer en arbre. Pour ce faire, il seraitnecessaire de dupliquer certains etats (donc certaines regles) afin qu’une regle aboutisse toujours surun/des etats fils et non sur des etats cousins.

FIG. I.1 – Schema de correlation non realisable a l’aide d’OSSIM

La figure I.2, illustre le schema typique d’un scenario de correlation d’OSSIM. En effet, chaque reglemene a ses propres sous-regles. Il n’y a pas de saut entre des etats adjacents.



FIG. I.2 – Schema de correlation realisable a l’aide d’OSSIM


Annexe J

Analyse heuristique - (algorithmeHolt-winter)

Les explications propres a la recuperation des donnees sont tirees du document suivant :http ://www.mirrors.wiretapped.net/security/network-monitoring/ntop/rrdandntop.pdf

J.1 Recuperation des donnees

Comme mentionne en section 3.3.1 Ntop fournit les statistiques reseaux necessaires a l’analyse heuris-tique (ainsi qu’a l’analyse de detection de seuils). Ces donnees sont stockees dans des bases de donneestourniquets illustrees par la figure J.1.

FIG. J.1 – Illustration d’une base de donnee tourniquet

Une fois le tourniquet plein, les anciennes donnees seront petit a petit remplacees par de nouvelles.

79


A chaque periode d’echantillonage, le plugin RRD1 de Ntop interrogera les differents compteurs de bytesfourni par celui-ci. Il enregistrera ensuite ces valeurs dans la base de donnees tourniquet correspondante.Celles-ci seront ensuite interrogees (a l’aide de RRDtool) par l’agent OSSIM via le plugin RRD2 afind’y controler les seuils et les depassement de l’algorithme heuristique configure a l’aide du framework(section 4.9.4). L’affichage des informations de Ntop3 utilisera les memes bases de donnees 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 aNtop) sur la periode d’echantillonage et la quantite d’informations (nombre d’echantillons) collectee parles bases de donnees tourniquets. Chaque compteur d’information reseau fourni par Ntop (IP DNSBytes,IP HTTPBytes, etc...) impliquera la creation de 3 bases de donnees tourniquet. Ces trois differentes basesde donnees tourniquet sont necessaires afin de permettre l’enregistrement d’au moins 1 annee de statis-tiques sans pour autant disposer d’une gigantesque base de donnees.

Si une unique base de donnees tourniquet etait utilisee afin de stocker 1 an d’echantillons et que laperiode d’echantillonnage est de 5 minutes (300 secondes), il faudrait exactement :

nbJours ∗ nbHeures/jour ∗ nbMinutes/heure ∗ nbSecondes/min

periodeEchantillonage[sec]=

365 ∗ 24 ∗ 60 ∗ 60300

= 3′153′600Slots

(J.1)Afin de reduire la taille des bases de donnees tourniquet, des moyennes sont effectuees sur les echantillonsqui sont ensuite enregistre dans deux bases de donnees tourniquets annexes permettant le stockage deplus d’une annee de statistiques ”moyennes” sans pour autant disposer de plus de 3mios de Slots.

J.1.1 Configuration du plugin RRD de Ntop

Celle-ci s’opere 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 parametres permettent la definition de la taille des 3 bases de donnees tourniquet(chaque compteur Ntop utilisera trois base de donnees tourniquet) ainsi que la periode d’echantillonnageutilisee par le plugin :

Dump Interval Indique la periode d’echantillonage en secondes. C’est a dire qu’un nouveau slot dutourniquet sera rempli toutes les N secondes. Valeur par defaut = 300 secondes.

Dump Hours Indique la taille de la 1ere base de donnees tourniquet en heures (nb d’heures d’informa-tions a stocker). On pourra en deduire le nombre de slots necessaire pour stocker N heures d’in-formations avant qu’un nouvel echantillon ecrase un echantillon existant (1 tour du tourniquet).Valeur par defaut = 72 heures.

1plugin nativement integre a Ntop (a ne pas confondre avec le plugin RRD d’OSSIM)2plugin OSSIM cette fois-ci (rrd plugin.pl)3affichage sous forme de page Web, via le serveur Web integre a Ntop



Dump Days Indique la taille de la seconde base de donnees tourniquet en jours (nb de jours d’infor-mations a stocker). On pourra en deduire le nombre de slots necessaire pour stocker N jours d’in-formations avant qu’un nouvel echantillon ecrase un echantillon existant (1 tour du tourniquet).Valeur par defaut = 90 jours.

Dump Months Indique la taille de la troisieme base de donnees tourniquet en mois (nb de mois d’in-formations a stocker). On pourra en deduire le nombre de slots necessaire pour stocker N moisd’informations avant qu’un nouvel echantillon ecrase un echantillon existant (1 tour du tourni-quet). Valeur par defaut = 36 mois.

Creation des bases de donnees tourniquets

Les parametres par defauts ci-dessus generent automatiquement (pour un compteur Ntop, IP HTTPBytespar exemple) les bases de donnees tourniquets suivantes (calcul des valeurs moyennes) :

RRA:AVERAGE:0.5:1:864



Structure des commandes RRD :Commande :Fonction :periodeEchantillonage :nbValPourFonction :nbSlots

Commande RRA = creation d’une base de donnees tourniquet

Fonction Fonction mathematique appliquee aux valeurs (nbValPourFonction) afin de reduire la tailledes base de donnees tourniquet suivante

periodeEchantillonage Interval de temps entre le releve de deux echantillons

nbValPourFonction Nb d’echantillons appliques a la fonction mathematique definie par Fonction

nbSlots Nb de slots de la base de donnees tourniquet

Ainsi, la permiere base de donnees tourniquet ne contiendra aucune moyenne (uniquement les valeursinstantannees), puisque l’AVERAGE est effectue avec une unique valeur (nbValPourFonction = 1). Ellecontiendra 72 heures d’informations recuperees toute les 300 secondes, ce qui implique :

nbHeures ∗ nbMinutes/heure ∗ nbSecondes/min

periodeEchantillonage[sec]=

72 ∗ 60 ∗ 60300

= 864Slots (J.2)

Pour la seconde base de donnees tourniquet : Un slot de celle-ci correspondra a 12 echantillons (nbVal-PourFonction) auquels la fonction average (Fonction = AVERAGE) aura ete appliquee. Un slot contiendraalors la moyenne d’une heure d’echantillons (12 * 5 = 60 min). Il sera donc necessaire de diposer de 2160slots afin de pouvoir y stocker 90 jours d’informations :

nbJours ∗ nbHeures/jour = 90 ∗ 24 = 2′160Slots (J.3)



J.2 Analyse des donnees

Cette section vise a expliquer l’algorithme de prevision (heuristique) utilise dans OSSIM. Celui-cirecupere les informations des bases de donnees RRD afin d’en tirer ses previsions. Le fonctionnementdes bases de donnees RRD est explique dans la section precedente (section J.1).

Les explications ci-dessous sont tirees des URL suivantes :http ://iut86-fad.univ-poitiers.fr/StatPC/livre/chapitre8/lissexpo.htmhttp ://www.gpa.etsmtl.ca/cours/gpa548/Chapitre2.pdf&ei=NSIDQ6TAO6GEiAKd-IkZhttp ://www.usenix.org/events/lisa2000/full papers/brutlag/brutlag html/index.html

J.2.1 Algorithmes de prevision

Les series temporelles sont basees sur l’analyse des donnes historiques recueillies sur un phenomenedonne, durant une certaine periode de temps (statistiques reseaux par exemples). Les previsions ef-fectuees a partir de series temporelles ont pour hypothese que le passe est garant de l’avenir, que lephenomene continuera a se comporter comme il l’a fait dans le passe.

On isole habituellement trois composantes dans les series temporelles :

tendance caracteristique d’un phenomene a demontrer, un patron stable de croissance ou de decroissancedans le temps. Le patron peut etre lineaire ou non-lineaire.

caracteristique d’un phenomene qui se repete a intervalles fixes, par exemple tous les hivers, tous lesmois, etc...

aspect cyclique identique a la saisonnalite mais pour des intervalles plus longs, souvent calcules enannees.

aspect aleatoire se dit d’un phenomene qui ne comporte aucun patron decelable.

Divers methodes et modeles de previsions sont actuellement utilisables. C’est le type de la fonctiontemporelle a predire qui nous indiquera le meilleur algorithme (modele mathematique) a utiliser. Eneffet, il sera inutile d’utiliser un modele mathematique complex tel que Holt-Winters si aucun phenomenecyclique n’est present dans la serie temporelle. En effet, dans le cas ou la serie est stationnaire (on nedistingue pas de tendance a la hausse ni a la baisse), on utilisera le lissage exponentiel simple. Dans lecas d’une serie soumise a des variations saisonnieres, on utilise souvent le modele de Holt et Winters.

Moyennes glissantes

Une moyenne gilssante d’ordre N est definie comme etant la moyenne arithmetique sur les N dernieresobservations. En methodes previsionnelles, cette moyenne devient la porchaine prevision.Mathematiquement cela donne :

Ft =1N

• (Dt−1 + Dt−2 + ... + Dt−N ) (J.4)



Avec :

Ft La prevision effectuee a la periode t-1 pour la periode t.

Dt-1 La valeur (mesuree) de la serie a la periode t-1.

Lissage exponentiel

Le lissage exponentiel est une classe de methodes de lissage de series chronologiques dont l’objectifest la prevision a court terme. Ces methodes sont fondees sur une hypothese fondamentale : chaqueobservation a l’instant t depend des observations precedentes et d’une variation accidentelle. En resume,la prevision courante est une moyenne ponderee de la derniere prevision et de la valeur courante.Mathematiquement cela s’ecrit sous cette forme :

Ft = αDt−1 + (1− α)Ft−1 (J.5)

Avec :

Ft La prevision effectuee a la periode t-1 pour la periode t.

Dt-1 La valeur (mesuree) de la serie a la periode t-1.

Ft-1 La prevision a la periode t-1 (periode precedente de la nouvelle prevision).

alpha Parametre compris entre 0 et 1.

A l’aide de la formule J.5, nous remarquons que plus le parametre alpha est grand (proche de 1) plus noustenons compte des valeurs precedentes mesurees. Plus alpha est petit (proche de 0), plus nous tenonscompte des valeurs precedentes predites.

Holt-Winters

La methode de Holt et Winters permet en effet d’effectuer des previsions sur des series chronologiquesassez irregulieres et soumises ou non a des variations saisonnieres suivant un modele additif ou multipli-catif. Elle consiste en trois lissages exponentiels simultanes definit par trois parametres. On peut choisirles coefficients arbitrairement : faibles si l’on considere que la valeur a l’instant t depend d’un grandnombre d’observations anterieures, eleves dans le cas contraire (meme principe que pour le lissage ex-ponentiel simple). On peut aussi en calculer les valeurs optimales, en minimisant la somme des carresdes differences entre les valeurs observees et estimees.

Le parametrage de la periodicite (variation saisonniere) est important puisque celui-ci influencera grande-ment l’algorithme de prevision. La figure J.2 illustre l’erreur entre une prediction par lissage exponentielet la fonction a observee (en bleu) ainsi que l’erreur entre une prediction par Holt-Winters et la fonctionobservee (en rouge).

La figure J.3, illustre quant a elle les memes erreurs que la figure precedente (figure J.2) avec, cettefois-ci, un mauvais reglage du parametre de periodicite de l’algorithme Holt-Winters. Nous remarquons



FIG. J.2 – Erreurs de predictions avec un bon reglage du parametre de periodicite de Holt-Winters

donc que la prevision par Holt-Winters devient aussi mauvaise (meme pire) qu’une simple prediction parlissage exponentiel. Il est donc tres important de bien regler ce parametre afin d’obtenir une predictionoptimale...

Les feuilles de calcul OpenOffice et Excel permettant de tester et comparer le comportement d’un algo-rithme de prediction par lissage exponentiel ainsi que par Holt-Winters sont telechargeables a l’adressesuivante :http ://www.fullsecurity.ch/security/sims/download.jsp



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


fonctionnement d’ossim - download.velannes.comdownload.velannes.com/ossim_doc.pdf · ossim est...

Documents