Ossim Doc [PDF]

Zitiervorschau

Fonctionnement d’OSSIM Dans le cadre de SIMS - Security Intrusion Management System (http ://www.fullsecurity.ch/security/sims/)

Auteur : Jo¨el Winteregg ([email protected]) Professeur : Stefano Ventura ´Ecole : Swiss University of Applied Sciences (HEIG-VD) Institut ICT (http ://www.iict.ch) Date : 12 mai 2006 Version : 3.4

Table des mati`eres 1

License d’utilisation de cette documentation

2

´ Etude d’OSSIM (Open Source Security Information Management) 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 La d´etection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 M´ethodes de d´etection . . . . . . . . . . . . . . . . . . . 2.3 L’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 D´efinition de la priorit´e des alarmes . . . . . . . . . . . . ´ 2.3.2 Evaluation des risques . . . . . . . . . . . . . . . . . . . 2.3.3 Corr´elation . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Le monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Risk monitor (moniteur du risque) . . . . . . . . . . . . . 2.4.2 Moniteur d’utilisation, session et profile . . . . . . . . . . 2.4.3 Path monitor (moniteur de chemin) . . . . . . . . . . . . 2.4.4 Forensic console (Console l´egale) . . . . . . . . . . . . . 2.4.5 Control Panel (panneau de contrˆole) . . . . . . . . . . . . 2.5 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Data flow . . . . . . . . . . . . . . . . . . . . . . . . . .

3

5

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

Fonctionnement logiciel d’OSSIM 3.1 Les applications Ossim-server et Ossim-agent . . . . . . . . . . . . . . 3.2 Fonctionnement de l’architecture avec une sonde Snort . . . . . . . . . 3.2.1 Pourquoi deux flux d’informations ? . . . . . . . . . . . . . . . 3.3 Fonctionnement de l’architecture avec une sonde Ntop et le plugin RRD 3.3.1 Qu’est-ce que Ntop ? . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Fonctionnement de l’architecture avec une sonde P0f . . . . . . . . . . 3.4.1 Qu’est-ce que P0f ? . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Fonctionnement de l’architecture avec une sonde TCPTrack . . . . . . 3.5.1 Qu’est-ce que TCPTrack ? . . . . . . . . . . . . . . . . . . . . 3.5.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . .

1

. . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . .

6 6 7 7 8 8 9 10 12 13 13 13 13 14 14 15

. . . . . . . . . . . .

17 17 17 17 19 19 20 20 20 21 21 21 22

SIMS - Security Intrusion Management System

3.6

3.7

3.8

4

Fonctionnement de l’architecture avec une sonde PADS . . . . . . . . . . . . . . . . . . 3.6.1 Qu’est-ce que PADS ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctionnement de l’architecture avec une sonde Syslog . . . . . . . . . . . . . . . . . 3.7.1 Qu’est-ce qu’une sonde HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctionnement de l’architecture avec une sonde HIDS IIS (Internet Information Services) 3.8.1 Qu’est-ce qu’une sonde HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fonctionnement du Framework (interface Web et serveur OSSIM) 4.1 Avant propos et terminologies . . . . . . . . . . . . . . . . . . 4.2 Architecture des menu du framework . . . . . . . . . . . . . . . 4.3 D´efinition du risque . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Menu Control Panel . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.4 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . 4.5 Reports Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Host Report . . . . . . . . . . . . . . . . . . . . . . . . 4.5.2 Security Report . . . . . . . . . . . . . . . . . . . . . . 4.5.3 PDF Report . . . . . . . . . . . . . . . . . . . . . . . . 4.5.4 Anomalies . . . . . . . . . . . . . . . . . . . . . . . . 4.5.5 Incident . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Monitor Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 Riskmeter . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.2 Session . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.3 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Policy Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.1 Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.2 Networks . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.3 Network groups . . . . . . . . . . . . . . . . . . . . . . 4.7.4 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.5 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 4.7.6 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Correlation Menu . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.1 Directives . . . . . . . . . . . . . . . . . . . . . . . . . 4.8.2 Cross Correlation . . . . . . . . . . . . . . . . . . . . . 4.8.3 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . .

2

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22 23 23 24 24 25 25 26 26 27 27 27 28 28 29 29 30 31 31 31 33 33 33 34 34 34 34 35 35 35 36 36 36 36 36 36 36 37 37 38

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

4.9

Configuration Menu 4.9.1 Main . . . 4.9.2 Users . . . 4.9.3 Plugins . . 4.9.4 RRD config 4.9.5 Host scan . 4.10 Tools Menu . . . . 4.10.1 Net Scan . 4.10.2 Rule viewer 4.10.3 Backup . .

5

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

Conclusion

A Installation et configuration d’Ossim-server A.1 Pr´erequis . . . . . . . . . . . . . . . . A.2 Installation . . . . . . . . . . . . . . . A.3 Configuration . . . . . . . . . . . . . . A.3.1 Ossim plate-forme . . . . . . . A.3.2 Serveur Web . . . . . . . . . . A.3.3 Nessus client-serveur . . . . . . A.3.4 Cross corr´elation via Nessus . .

38 38 39 39 39 41 41 41 41 41 45

. . . . . . .

47 47 47 49 49 49 50 50

. . . . . . . . .

52 52 52 53 53 53 54 55 56 56

. . . . . .

58 58 58 59 59 59 61

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

62 62

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

B Ajout et configuration d’une sonde Snort B.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . B.1.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . B.1.2 Ossim-agent . . . . . . . . . . . . . . . . . . . . . B.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . B.2.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . B.2.2 Ossim-agent . . . . . . . . . . . . . . . . . . . . . B.3 Configuration d’Ossim-server pour une nouvelle sonde Snort B.4 Test de fonctionnement . . . . . . . . . . . . . . . . . . . . B.4.1 Erreur de d´emarrage de l’agent Ossim . . . . . . . . C Ajout et configuration de Ntop C.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . C.1.1 Ntop . . . . . . . . . . . . . . . . . . . . . . . . . C.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . C.2.1 Ntop . . . . . . . . . . . . . . . . . . . . . . . . . C.2.2 L’agent Ossim . . . . . . . . . . . . . . . . . . . . C.3 Configuration d’Ossim-server pour une nouvelle sonde Ntop

3

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . .

. . . . . . . . .

. . . . . .

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

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

62 62 62

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

63 63 63

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

64 64 64

G Ajout et configuration d’une sonde HIDS IIS G.1 Installation du plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . G.2 Installation de Snare IIS (rapatriement des logs vers un serveur Syslog) G.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G.3.1 Configuration de l’agent OSSIM . . . . . . . . . . . . . . . . . G.3.2 Configuration du serveur IIS (client Snare IIS) . . . . . . . . .

. . . . .

65 65 65 66 66 66

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

68 68 68

I

J

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

Cr´eation de r`egles de corr´elation I.1 Introduction . . . . . . . . . . . . . . . . . . . I.2 Ajout d’un fichier de r`egles sur le serveur . . . I.3 Syntaxe XML . . . . . . . . . . . . . . . . . . I.3.1 Balise directive . . . . . . . . . . . . . I.3.2 Balise rule . . . . . . . . . . . . . . . I.3.3 Balise rules . . . . . . . . . . . . . . . I.3.4 Syntaxe des attributs de caract´eristiques I.4 Structures des directives de corr´elation . . . . . I.4.1 Exemple de structure des directives . . I.4.2 Structure de corr´elation r´ealisable . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

69 69 69 70 70 70 71 71 75 75 77

Analyse heuristique - (algorithme Holt-winter) J.1 R´ecup´eration des donn´ees . . . . . . . . . . . J.1.1 Configuration du plugin RRD de Ntop J.2 Analyse des donn´ees . . . . . . . . . . . . . J.2.1 Algorithmes de pr´evision . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

79 79 80 82 82

4

. . . .

Institut ICT, Jo¨el Winteregg (cc)

Chapitre 1

License d’utilisation de cette documentation THIS WORK IS LICENSED UNDER THE CREATIVE COMMONS ATTRIBUTION-NONCOMMERCIALSHAREALIKE LICENSE. TO VIEW A COPY OF THIS LICENSE, VISIT : http ://creativecommons.org/licenses/by-nc-sa/2.5/deed.fr OR SEND A LETTER TO CREATIVE COMMONS, 543 HOWARD STREET, 5TH FLOOR, SAN FRANCISCO, CALIFORNIA, 94105, USA.

5

Chapitre 2

´ Etude d’OSSIM (Open Source Security Information Management) 2.1

Introduction

OSSIM est une solution offrant une infrastructure pour le monitoring de la s´ecurit´e r´eseau. Ses objectifs sont : – Fournir un cadre centralis´e – Fournir une console d’organisation – Am´eliorer la d´etection et l’affichage des alarmes de s´ecurit´e Le but commun des trois principaux objectifs d´ecrits ci-dessus est de permettre une r´eduction des faux positifs1 et des faux n´egatifs2 . Ce but est d’autant plus difficile a` atteindre du fait qu’un volume consid´erable d’alarmes est pr´esent. Il est donc n´ecessaire de relier ces diff´erentes alarmes entre elles afin d’obtenir des informations pertinantes et d’´eliminer les alarmes innutiles (lev´ees pour rien). Cet objectif peut eˆ tre atteint a` l’aide d’un proc´ed´e d’analyse des donn´ees nomm´e : Corr´elation. Le principe de fonctionnement d’OSSIM est form´e de trois grandes cat´egories d´ecompos´ees elles-mˆemes en sous cat´egories : 1. La d´etection – IDS (pattern matching3 ) – D´etection d’anomalie – Firewalls 2. L’analyse et le monitoring (d´etaill´e en section 2.3.3 et 2.4) 1

Alarmes lev´ees pour rien Alarmes non d´eclench´ees alors qu’une attaque a eu lieu 3 signatures 2

6

SIMS - Security Intrusion Management System

– Corr´elation ´ – Evaluation de la dangerosit´e des alarmes ´ du risque sur l’architecture a` prot´eger – Evaluation 3. Les management (configuration) – Inventaire des ressources informatiques4 – D´efinition de la topologie – D´efinition des polices de s´ecurit´e – D´efinition des r`egles de corr´elation – Liens avec diff´erents outils d’audits Open Source Les diff´erents proc´ed´es cit´es ci-dessus seront d´etaill´es dans les sections suivantes.

2.2

La d´etection

Celle-ci est e´ videmment effectu´ee a` l’aide de sondes capables de traiter l’information5 en temps r´eel et d’´emettre des alarmes lorsqu’une situation a` risque est d´etect´ee.

2.2.1

M´ethodes de d´etection

Une sonde peut utiliser diff´erentes approches afin de d´eterminer si une e´ v´enement est a` risque ou non. En effet, deux grands principes compl´ementaires (et non concurrent) sont pr´esents dans la d´etection d’intrusions : 1. Bas´e sur des signatures 2. Bas´e sur la d´etection d’anomalie D´etection par signatures La d´etection par signatures identifie des e´ v´enements de s´ecurit´e qui tentent d’utiliser un syst`eme de fac¸on non standard. Les repr´esentations d’intrusions sont donc stock´ees et compar´ees a` l’activit´e du syst`eme. Lorsqu’une intrusion connue est rep´er´ee lors de l’utilisation du syst`eme, une alarme est lev´ee. La d´etection par signatures a des limites. Elle ne connaˆıt pas l’objectif de l’activit´e correspondant a` une signature et va donc d´eclencher une alerte mˆeme si le trafic est normal. De plus, la d´etection par signature exige de connaˆıtre pr´ealablement l’attaque afin de g´en´erer la signature pr´ecise correspondante (fonctionnement par liste noire, exemple : antivirus). Ceci implique qu’une attaque encore inconnue ne pourra pas eˆ tre d´etect´ee par signature. 4 5

machines, syst`emes d’exploitation, services Trames transitants par le r´eseau ou log d’une application

7

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

D´etection d’anomalie La d´etection d’anomalie identifie une activit´e suspecte en mesurant une norme6 sur un certain temps. Une alerte est ensuite g´en´er´ee lorsque le mod`ele s’´eloigne de cette norme. Le principal avantage de la d´etection d’anomalie est qu’elle n’exige aucune connaissance pr´ealable des attaques. Si le module de d´etection par anomalie d´etermine qu’une attaque diff`ere de fac¸on significative de l’activit´e normale, il peut la d´etecter. Comme la d´etection par recherche de pattern, la d´etection d’anomalie poss`ede ses limites. Toute la difficult´e r´eside dans la p´eriode de collecte des donn´ees correspondant a` une activit´e d´esign´ee comme normale pour alimenter la base de donn´ees de r´ef´erence.

2.3

L’analyse

La m´ethode de traitement des donn´ees peut eˆ tre d´ecompos´ee en trois phases distinctes : 1. Preprocessing, g´en´eration des alarmes et envoi de celles-ci. 2. Rassemblement, toutes les alarmes pr´ec´edemment envoy´ees (preprocessing) sont emmagasin´ees dans un serveur central. 3. Post-processing, le traitement des donn´ees que l’on a emagasin´e. Les deux premi`eres e´ tapes (preprocessing et rassemblement) ne pr´esentent rien de nouveau dans le cadre d’OSSIM. Celles-ci font principalement partie des m´ethodes de d´etection mentionn´ees ci-dessus (section 2.2). OSSIM offrira uniquement de nouvelles m´ethodes d’analyse et d’affichage des donn´ees r´ecolt´ees. Il n’apportera en aucun cas de nouvelles solutions dans la d´etection et le rassemblement de donn´ees. Diff´erentes m´ethodes d’analyse sont impl´ement´ees dans le cadre d’OSSIM : – D´efinition de la priorit´e des alarmes ´ des risques – Evaluation – Corr´elation

2.3.1

D´efinition de la priorit´e des alarmes

Ce proc´ed´e permettra de d´eduire la priorit´e d’une alarme en fonction de son type, de la source de l’´eventuelle attaque ainsi que de sa cible. Les exemples suivants illustrent facilement l’utilit´e de cette e´ tape d’analyse : – Une machine fonctionnant avec le syst`eme d’exploitation UNIX et h´ebergeant un serveur Web Apache est mentionn´ee comme cible d’une attaque. Cette attaque a pr´ec´edemment e´ t´e d´etect´ee comme possible a` l’aide d’un scanner de vuln´erabilit´es. La piorit´e de l’alerte sera donc maximale 6

Peut eˆ tre assimil´e a` un chablon de bon fonctionnement (activit´e normale)

8

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

puisque le serveur Web est vuln´erable a` l’attaque en question. Un proc´ed´e de cross-corr´elation est donc appliqu´e a` toutes les alertes. – Si la connexion a` un serveur g´en`ere une alarme, la configuration de police de s´ecurit´e en fonction des utilisateurs permettra facilement la d´efinition de la priorit´e de celle-ci. En effet, diff´erents cas sont envisageables : – Priorit´e maximale de l’alarme si l’utilisateur (source de ”l’attaque”) est ext´erieur au r´eseau de l’entreprise et que la connexion a pour cible une base de donn´ees importantes. – Basse priorit´e si l’utilisateur (source de ”l’attaque”) est interne au r´eseau de l’entreprise et que la connexion a pour cible une imprimante. – Alarme discr´edit´ee si l’utilisateur (source de ”l’attaque”) fait partie de l’´equipe de d´eveloppement et que la cible de la connexion est un serveur de test. La d´efinition de priorit´e fait partie d’une e´ tape de mise en place de contextes des alarmes. Celle-ci est uniquement possible si l’environnement de l’entreprise est d´efini dans une base de donn´ees des connaissances. Cette base de donn´ees est d´efinie par l’inventaire des bien informatiques ainsi que sur des polices d’acc`es a` des serveurs et/ou services. La d´efinition des ces diff´erentes polices de s´ecurit´es implique la mise a` disposition d’un outil de management permettant une configuration pr´ecise des polices de s´ecurit´es ainsi que des machines du r´eseau. Cette e´ tape repr´esente une part importante du filtrage des alarmes et n´ecessitera une constante mise a` jour de la base de donn´ees des connaissances.

´ 2.3.2 Evaluation des risques Le risque peut eˆ tre d´efini comme e´ tant la probabilit´e de menace de l’´ev´enement. En d’autres termes, cette e´ tape tente de d´efinir si la menace est r´eelle ou pas. L’importance a` donner a` un e´ v´enement d´epend principalement de trois facteurs : 1. La valeur du bien attaqu´e 2. La menace repr´esent´ee par l’´ev´enement 3. La probabilit´e que l’´ev´enement apparaisse Les trois facteurs vus ci-dessus sont la base du calcul du risque intrins`eque. Risque intrins`eque Ce risque peut eˆ tre d´efini de la fac¸on suivante : La mesure de l’impact potentiel de la menace sur le bien informatique, en fonction de la probabilit´e que cette menace apparaisse, tout en tenant compte de la fiabilit´e du capteur ayant e´ mit l’alarme. Le risque est traditionnellement repr´esent´e par le risque intrins`eque repr´esentant le risque qu’une organisation court de par les biens qu’elle poss`ede.

9

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

Risque imm´ediat ´ Etant donn´e qu’OSSIM offre un traitement temps r´eel des alarmes, le calcul du risque imm´ediat peut eˆ tre associ´e a` la situation courante. Ce risque offre une vision de l’´evaluation des d´egats qu’une alarme rec¸ue pourrait engendrer. Cette e´ valuation prendra aussi en compte la fiabilit´e du capteur ayant e´ mis cette alarme. Le risque imm´ediat est donc calcul´e pour chaque alarmes rec¸ues et indique l’importance de l’alarme en terme de s´ecurit´e.

2.3.3

Corr´elation

Ce proc´ed´e permet nottamment de retrouver certaines relations entre diff´erentes alarmes ind´ependantes. Ceci permettra par exemple de d´ecouvrir des attaques noy´ees dans le flot des alarmes ou encore de discr´editer des alarmes (d´ecouverte de faux positifs). La corr´elation peut eˆ tre simplement d´efinie comme un proc´ed´e traitant des donn´ees (inputs) et retournant un r´esultat (outputs). OSSIM utilise deux types d’inputs : 1. Informations du moniteur (qui fournit normalement des indications a` l’administrateur) 2. Informations des d´etecteurs (qui fournissent normalement des alarmes) Le r´esultat de ce traitement sera lui aussi d’un des deux genres cit´es ci-dessus (du moniteur ou des d´etecteurs). Les mod`eles de corr´elations utilis´es par OSSIM ont les objectifs suivants : – Utilisation de m´ethodes par signatures, pour la d´etection d’´ev´enements connus et d´etectables – Utilisation de m´ethodes sans signature, pour la d´etection d’´ev´enements non connus – Utilisation d’une machine d’´etats configurable par l’utilisateur, pour la description de signatures complexes – Utilisation d’algorithmes e´ volu´es, pour l’affichage g´en´eral de la s´ecurit´e M´ethodes de corr´elation OSSIM met en oeuvre plusieurs m´ethodes de corr´elation compl´ementaires : 1. Corr´elation utilisant des s´equences d’´ev´enements, bas´ees sur les signatures connues et d´etectables 2. Corr´elation utilisant des algorithmes heuristique7 , utilis´ee pour la d´etection d’attaques non connues 3. Cross-corr´elation permettant la recherche de relations entre les scans Nessus effectu´es et des alertes d´etect´ees Corr´elation par heuristique OSSIM impl´emente un algorithme d’heuristique comme un accumulateur d’´ev´enements (CALM), offrant une indication de l’´etat g´en´eral du r´eseau. L’objectif de ce traitement est d’obtenir en premier lieu, le risque imm´ediat (d´efinit dans la section 2.3.2) puis, le risque accumul´e. 7

Technique consistant a` apprendre petit a` petit, en tenant compte de ce que l’on a fait pr´ec´edemment pour tendre vers la solution d’un probl`eme

10

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

– Le risque imm´ediat offre un haut niveau de monitoring temps r´eel. Celui-ci peut eˆ tre assimil´e a` un ”thermom`etre” des situations critiques, sans mˆeme connaˆıtre les d´etails des caract´eristiques du probl`eme. – Le risque accumul´e offre quant a` lui un haut niveau de monitoring sur une certaine fenˆetre temporelle (risque accumul´e et non plus temps r´eel). Le second algorithme heuristique utilis´e par OSSIM permet la pr´evision des statistiques r´eseaux (paquets e´ mis et rec¸us) en fonction des valeurs pr´ec´edentes (Holt-winter). Ceci permettra la d´etection automatique d’anomalies r´eseaux. Par cons´equence, la corr´elation par heuristique offre : – Une vue globale et rapide de la situation – Une d´etection possible d’attaques, non relev´ees par les autres m´ethodes de corr´elation (se basant sur des signatures) CALM (Compromise and Attack Level Monitor), est un algorithme8 utilisant les e´ v´enements accumul´es et fournissant une valeur indicative du niveau de s´ecurit´e global. L’accumulation d’´ev´enements est effectu´ee ind´ependamment pour tous les e´ l´ements du r´eseau. Celle-ci est simplement calcul´ee par la somme de deux variables d’´etat repr´esentant le risque imm´ediat de chaque e´ v´enement : 1. Variable ”C” ou niveau de fiabilit´e d’une machine ou d’un r´eseau, mesure la probabilit´e qu’une machine ou un r´eseau soit compromis (source d’une attaque effectu´e par un ver ou troyen install´e sur une machine a` surveiller). 2. Variable ”A” indique la probabilit´e que la machine ou r´eseau a` surveiller soit la cible d’attaques. La variable ”A” repr´esente la probabilit´e qu’une attaque a e´ t´e lanc´ee et qu’elle est r´eussie, alors que la variable ”C” fournit l’´evidence qu’il y a eu une attaque et qu’elle a r´eussi. Chaque machine du r´eseau a donc une variable ”A” et ”C” associ´ee, fluctuant de la mani`ere suivante : 1. Toute attaque possible d’une machine 1 (source) vers une machine 2 (cible) incr´ementera le niveau ”A” de la machine 2 et le niveau ”C” de la machine 1. 2. Lorsqu’une r´eponse a` une attaque est d´etect´ee (signifiant que l’attaque est r´eussie), le niveau ”C” des deux machines sera incr´ement´e. 3. Lorsque l’´ev´enement est interne (source interne), seul le niveau ”C” de la machine source est incr´ement´e. CALM fonctionne d’une mani`ere temps r´eel (accumulation temps r´eel des e´ v´enements). Il peut aussi eˆ tre int´eressant d’observer ces statistiques dans une fenˆetre temporelle (accumulation sur le temps). En effet, ceux-ci varieront grandement en fonction de la fenˆetre utilis´ee puisqu’un fonctionnement temps r´eel (accumulation continue d’´ev´enements) aura pour effet de noyer certaines alarmes critiques dans la masse d’information. Nous pourrions assimiler le fonctionnement d’accumulation sur le temps a` un zoom sur les statistiques temps r´eel. 8

Algorithme impl´ement´e dans OSSIM

11

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

Holt-Winter Algorithme, algorithme heuristique impl´ement´e dans le moteur de corr´elation temps r´eel d’OSSIM, permettant la d´ecouverte de comportements anormaux sans l’utilisation de seuils. Description tir´ee de : http ://www.usenix.org/events/lisa2000/full papers/brutlag/brutlag html/index.html La d´etection anormale de comportements est d´ecompos´ee en trois parties, chacune e´ tablie selon son pr´ed´ecesseur : 1. Un algorithme pour pr´evoir pas par pas les valeurs d’une s´erie chronologique. 2. Une mesure de d´eviation entre les valeurs pr´evues et les valeurs observ´ees. 3. Un m´ecanisme d´etectant lorsqu’une valeur est ”trop d´eviante” de la valeur pr´evue. L’algorithme de pr´evision Holt-Winter fait appel aux principes de lissage exponentiel (genre de moyenne math´ematique permettant la pr´ediction de valeurs). En effet, Holt-Winter fournit une m´ethode un peu plus complexe utilisant un triple lissage exponentiel. Pour plus d’informations au sujet de cet algorithme, consultez l’annexe J. Corr´elation par diagramme d’´etats (s´equence d’´ev´enements) Ce genre de corr´elation fait appel a` la d´etection par signatures. Ceci permettra a` l’utilisateur (administrateur r´eseau en charge de la s´ecurit´e), de d´efinir des r`egles de corr´elation a` l’aide des signatures disponnibles. Exemple : Si l’alarme A, B et C est lev´ee, il faut ex´ecuter l’action D. Ceci s’apparente donc au moteur de corr´elation d´evelopp´e par M. Saladino dans le cadre de SIMS 20039 . Le moteur de corr´elation d’OSSIM a les caract´eristiques suivantes : Capacit´e de d´efinir des variables d’origines et de destination Utilisation des alarmes des d´etecteurs (d´etection par signature) et/ou des informations des moniteurs (monitoring) comme input pour la corr´elation Utilisation de variables e´ lastiques (accumulant des informations au cour du temps) Architecture r´ecursive (possibilit´e d’utiliser des r`egles pr´ec´edemment d´efinie dans de nouvelle r`egles)

2.4

Le monitoring

Le monitoring consiste en l’affichage des informations fournies. Les consoles de monitoring utilisent les diff´erentes donn´ees produites par les proc´ed´es de corr´elation (d´ecrit ci-dessus) pour la construction d’un affichage efficace et/ou r´esum´e. 9

R´ealis´e dans le cadre d’un projet (http ://www.tcom.ch/Tcom/Projets/SIMS/sims.html)

de

12

diplˆome

de

l’institut

Tcom

de

l’Eivd

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

2.4.1

Risk monitor (moniteur du risque)

Ce moniteur appel´e ”RiskMeter” permet l’affichage des donn´ees produites par l’algorithme CALM (d´ecrit dans la section 2.3.3). Les informations ”C” (mesure de la fiabilit´e) et ”A” (mesure du niveau d’attaque) sont illustr´es graphiquement par ce moniteur.

2.4.2

Moniteur d’utilisation, session et profile

Comme d´ecrit plus haut, OSSIM place une grande importance sur le monitoring d´etaill´e de chaque machine et profile. Il existe 3 diff´erents types de monitoring dans OSSIM : 1. Monitoring d’utilisation, offrant une vue g´en´erale d’une machine (comme snmp le ferai) 2. Monitoring de profile, offrant des informations sp´ecifiques sur l’activit´e des utilisateurs, nous permettant d’´etablir un profil (pop, http, etc..) pour chaque utilisateur 3. Monitoring de session, offre un affichage temps r´eel des sessions en cours d’un utilisateur

2.4.3

Path monitor (moniteur de chemin)

Ce moniteur offre un affichage temps r´eel des chemins de l’information emprunt´es par des donn´ees e´ mises par diff´erentes machines sur le r´eseau. Il utilise les informations fournies par le moniteur de session (identifiant chaque lien pr´esent sur le r´eseau) et par le moniteur de risque (fournissant le niveau de risque de chaque machine) afin de construire un affichage agr´eable (`a l’aide de diff´erentes couleurs). Deux m´ethodes d’affichage et d’analyse sont disponibles. Hard link analysis (Analyse des liens TCP) Cette m´ethode affiche uniquement les sessions TCP courantes. Le but de celle-ci est de pouvoir observer la propagation d’une attaque ou d’un ver afin de d´eterminer un p´erim`etre de s´ecurit´e. Soft link analysis Cette m´ethode d’analyse offre l’affichage de tous les liens perc¸us sur le r´eseau (UDP, TCP, ICMP inclus).

2.4.4

Forensic console (Console l´egale)

Cette console offre l’acc`es a` toutes les informations recueillies et stock´ees par le collecteur. Elle est donc un outil de recherche sur la base de donn´ees d’´ev´enements. Celle-ci permet une analyse a` post´eriori d´etaill´ee et approfondie des e´ l´ements r´eseaux.

13

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

2.4.5

Control Panel (panneau de contrˆole)

Cette console offre un aperc¸u de haut niveau de la s´ecurit´e. Cette console permet la d´efinition de seuils g´en´erant des alarmes de haut niveau a` destination de l’administrateur r´eseau en charge de la s´ecurit´e. 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 r´eseau (statistiques d’utilisation) – Monitoring des seuils d´efinis – Monitoring des profiles d´epassant les seuils

2.5

Architecture

L’architecture d’OSSIM est divis´ee en 2 principaux e´ tages : 1. Pr´e-processing, remont´ee d’´evenements des moniteurs et d´etecteurs dans une base de donn´ees commune 2. Post- processing, analyse centralis´ee La figure 2.1 illustre le fonctionnement en 2 e´ tages (comme mentionn´e ci-dessus). Nous remarquons que ces deux e´ tages disposent de diff´erentes bases de donn´ees permettant la sauvegarde des informations interm´ediaires (corr´el´ees). D´efintions des bases de donn´ees :

F IG . 2.1 – Architecture d’OSSIM EDB La base de donn´ees des e´ v´enements (la plus grande), stockant toutes les alarmes individuelles

14

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

KDB La base de donn´ees des connaissances, sauvegardant les configurations e´ tablies par l’administrateur en charge de la s´ecurit´e UDB La base de donn´ees des profiles, stockant toutes les informations du moniteur de profile

2.5.1

Data flow

Afin d’aider a` la compr´ehension, nous allons d´etailler le cheminement d’une alarme dans l’architecture d´efinie par la figure 2.1. Le sch´ema de la figure 2.2, illustre le fonctionnement d´ecrit ci-dessous : 1. D´etection d’un e´ v´enement suspect par un d´etecteur (par signatures ou par l’heuristique) 2. Si n´ecessaire, des alarmes sont regroup´ees (par le d´etecteur) afin de diminuer le trafic r´eseau 3. Le collecteur rec¸oit la/les alarme(s) via diff´erents protocoles de communications ouverts 4. Le parser normalise et sauve les alarmes dans la base de donn´ees d’´ev´enements (EDB) 5. Le parser assigne une priorit´e aux alarmes rec¸ues en fonction de la configuration des polices de s´ecurit´es d´efinies par l’administrateur s´ecurit´e 6. Le parser e´ value le risque imm´ediat repr´esent´e par l’alarme et envoie si n´ecessaire une alarme interne au Control panel 7. L’alerte est maintenant envoy´ee a` tous les processus de corr´elation qui mettent a` jour leurs e´ tats et envoient e´ ventuellement une alerte interne plus pr´ecise (groupe d’alerte provenant de la corr´elation) au module de centralisation. 8. Le moniteur de risque affiche p´eriodiquement l’´etat de chaque risque calcul´es par CALM10 . 9. Le paneau de contrˆole affiche les alarmes les plus r´ecentes et met a` jour les indices des e´ tats qui sont compar´es aux seuils d´efinis par l’administrateur. Si les indices sont sup´erieurs aux seuils configur´es, une alarme interne est e´ mise. 10. Depuis le panneau de contrˆole, l’administrateur a la possibilit´e de visualiser et rechercher des liens entre les diff´erentes alarmes a` l’aide de la console forensic

10

Algorithme d´ecrit dans la section 2.3.3

15

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

F IG . 2.2 – Data flow du serveur OSSIM

16

Institut ICT, Jo¨el Winteregg (cc)

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 r´ecup`ere simplement les informations des fichiers de logs des plugins (fichier fast.log pour Snort) et les envoie directement au serveur OSSIM permettant ainsi le traitement temps r´eel de celles-ci. De plus, l’agent Ossim s’occupera de la mise en marche et de l’arrˆet des diff´erentes sondes qui lui sont connect´ees. Il ne sera ainsi pas n´ecessaire de d´emarrer la sonde Snort ”`a la main” puisque son activation sera effectu´ee depuis la console de management offerte par Ossimserver. Ossim-server constitue le noyau de l’architecture. En effet, celui-ci comporte les modules d’analyse et de corr´elation des donn´ees ainsi qu’un serveur Web permettant l’interaction avec l’utilisateur (administrateur r´eseau).

3.2

Fonctionnement de l’architecture avec une sonde Snort

Le principe de communication d’une sonde Snort avec le serveur OSSIM est illustr´e par la figure 3.1. Nous remarquons que l’IDS1 Snort est ind´ependant du programme client d’OSSIM (nomm´e : ossimagent) et que deux flux d’informations sont e´ mis en direction du serveur.

3.2.1

Pourquoi deux flux d’informations ? Le flux nomm´e ”Requˆetes SQL pour d´epos des alertes” est utilis´e afin de d´eposer directement les alertes dans la base de donn´ees ”Snort DB” du serveur. Ceci permettra l’archivage de celles-ci et

1

Intrusion Detection System

17

SIMS - Security Intrusion Management System

F IG . 3.1 – Principe de communication entre une sonde Snort et le serveur d’OSSIM leur conslutation via ACID2 , permettant ainsi l’analyse pr´ecise de chaque alertes. Le flux nomm´e ”Envoi des alertes pour l’anayse temps r´eel (TCP et protocole applicatif propre a` OSSIM” est quant a` lui n´ecessaire pour le proc´ed´e d’analye et de corr´elation temps r´eel op´er´e sur le serveur d’OSSIM. Ces deux flux d’informations redondants sont indispensables si l’on ne veut pas red´efinir le protocole d’envoi des informations dans la base de donn´ees ”Snort DB”. En effet, le plugin de sortie Mysql ne serait pas suffisant pour un traitement temps r´eel puisque le stockage des informations dans une base de donn´ees ”casse” le proc´ed´e temps r´eel. Un tel fonctionnement impliquerait l’interrogation continuelle de la base de donn´ees afin de d´ecouvrir les nouvelles donn´ees ins´er´ees. Les concepteurs d’OSSIM ont donc pr´ef´er´e utiliser deux flux d’informations plutˆot que de cr´eer un nouveau plugin de sortie pour Snort permettant d’envoyer les alertes dans un seul flux structur´e au serveur. Dans ce mode de fonctionnement, c’est le serveur qui se chargerait ensuite du traitement temps r´eel et de l’insertion des informations dans une base de donn´ees. Pour l’analyse et la corr´elation, le serveur Ossim utilise uniquement les alertes provenant de l’agent Ossim, alors que les alertes directement stock´ees dans la base de donn´ees sont uniquement utilis´ees pour la 2

Analysis Console for Intrusion Databases, interface Web int´egr´ee a` OSSIM permettant l’interrogation d’une base de donn´ees Snort (d´evelopp´e dans le cadre du projet Open Source Snort)

18

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

consultation.

3.3

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

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

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

3.3.1

Qu’est-ce que Ntop ?

Ce logiciel analyse de mani`ere temps r´eel le trafic r´eseau et met a` disposition une liste de compteurs (par exemple : IP DNSBytes, IP HTTPBytes), permettant le monitoring ainsi que le calcul de statistiques r´eseaux. La sonde Ntop met en place un serveur Web (sur le port 3000) permettant le monitoring ainsi que la configuration de celle-ci a` distance. Le plugin de sortie RRD3 est n´ecessaire pour l’int´egration des fonctionnalit´es heuristiques et de d´etection de seuils dans OSSIM. Celui-ci permet l’enregistrement des donn´ees Ntop sous forme de tourniquet (les 3

Round Robin Database

19

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

plus vieilles donn´ees sont e´ cras´ees par les nouvelles). L’interrogation de la base de donn´ee RRD est ensuite facilit´ee a` l’aide de l’outil RRDtool4 utilis´e par le script rrd plugin.pl offrant les fonctions d’analyse heuristiques et de contrˆole de d´epassement de seuils. Des seuils RRD ainsi que les param`etres de l’analyse heuristique (algorithme Holt-Winter expliqu´e dans l’annexe J) peuvent ensuite eˆ tre d´efini par l’administateur s´ecurit´e via le framework (cf. section 4.9.4). Cette configuration permettra la g´en´eration d’alertes lorsque des valeurs excessives auront e´ t´e d´etect´ees par rrd plugin.pl.

3.3.2

Fonctionnement

Le script Perl rrd plugin.pl effectue la liaison entre Ntop et l’agent Ossim pour les fonctionnalit´es heuristiques (Holtwinter algorithme) et de d´etection de seuils. Celui-ci interroge p´eriodiquement la ”base de donn´ees” RRD (illustr´ee par Ntop/rrd log file sur la figure 3.2) a` l’aide de l’outil RRDtool. Il r´ecup`ere (via des requˆetes SQL sur le serveur) les seuils des compteurs d´efinis par l’administrateur r´eseau a` l’aide du framework de configuration5 et les compare aux donn´ees pr´ec´edemment r´ecup´er´ees (`a l’aide de RRDtool). Les e´ ventuels d´epassements des seuils sont ensuite stock´es dans un fichier de log (/var/log/ossim/rrd plugin.log) qui sera r´ecup´er´e par l’agent Ossim afin de permettre l’envoi temps r´eel des informations au serveur. La corr´elation des ces informations peut ensuite eˆ tre effectu´ee 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 illustr´e par la figure 3.3.

3.4.1

Qu’est-ce que P0f ?

P0f est un logiciel de d´etection de syst`emes d’exploitations6 passif. Il analyse les trames transitant sur le r´eseau (le segment analys´e) et les compare avec une base de donn´ees des caract´eristiques de chaque OS (prise d’empreintes) afin d’en retrouver l’OS correspondant : 1. d´etection de la pr´esence d’un firewall et NAT 2. d´etection d’un load balancer (r´epartiteur de charge r´eseau) 3. d´etection de la distance (TTL) de la machine distante ainsi que depuis combien de temps la machine est d´emarr´ee P0f est totalement passif. Il ne g´en`ere aucun traffic r´eseau suppl´ementaire ! 4

http ://people.ee.ethz.ch/ oetiker/webtools/rrdtool/ interface Web offerte par le serveur. Menu : Configuration - RRD config 6 Operating System (OS) 5

20

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

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

3.4.2

Fonctionnement

Celui-ci est assez simple. P0f e´ crit ses logs dans le fichier /var/log/ossim/p0f.log (chemin fournit a` P0f par l’agent Ossim lors du lancement de P0f). Ce chemin se trouve donc dans la configuration du plugin P0f (/etc/ossim/agent/plugins/p0f.xml) de l’agent. Le daemon agent (ossim-agent) s’occupera ensuite de les r´ecup´erer afin de les envoyer au serveur OSSIM pour une analyse temps r´eel.

3.5

Fonctionnement de l’architecture avec une sonde TCPTrack

Le principe de communication d’une sonde TCPTrack avec le serveur OSSIM est illustr´e par la figure 3.4.

3.5.1

Qu’est-ce que TCPTrack ?

TCPTrack est un sniffer affichant des informations sur les connexions TCP qu’il rencontre sur une interface. Il d´etecte passivement les connexions TCP sur l’interface a` analyser et affiche les informations de la mˆeme mani`ere que la commande Unix top. Il permet l’affichage des adresses source et destination, de l’´etat de la connexion, du temps de connexion ainsi que de la bande passante utilis´ee.

21

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

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

3.5.2

Fonctionnement

TCPTrack fonctionne d’une mani`ere similaire a` l’affichage Web des informations de Ntop. En effet, aucune information n’est spontan´ement envoy´ee vers le serveur OSSIM. TcpTrack ouvre simplement un port serveur7 sur la loopback de l’agent. C’est ensuite le serveur OSSIM qui, lors du proc´ed´e de corr´elation, interrogera si n´ecessaire l’agent afin qu’il interroge a` son tour TCPTrack (via la loopback). Une fois les informations r´ecolt´ees par l’agent, celui-ci se chargera de les remettre au serveur qui les utilisera pour la corr´elation. L’agent joue donc un rˆole d’interm´ediaire entre le serveur et le sonde TCPTrack.

3.6

Fonctionnement de l’architecture avec une sonde PADS

Le principe de communication d’une sonde PADS8 avec le serveur OSSIM est illustr´e par la figure 3.5. 7 8

port 40003 par d´efaut Passive Asset Detection System

22

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

3.6.1

Qu’est-ce que PADS ?

PADS va permettre d’identifier les machines (adresses IP et MAC) ainsi que leurs services uniquement en sniffant le r´eseau. Il permettra l’affichage des services d’une machine sans avoir a` op´erer un scan actif comme nmap9 . Il permettra l’affichage des services d’une machine configur´ee sur OSSIM sans op´erer un scan actif.

3.6.2

Fonctionnement

Le logiciel PADS reportera simplement toutes les informations r´ecolt´ees dans le fichier de log /var/log/ossim/pads.csv (indiqu´e dans la configuration du plugin, fichier /etc/ossim/agent/plugins/pad.xml). L’agent Ossim se chargera ensuite de les r´ecolter et de les envoyer de mani`ere temps r´eel au serveur.

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

Outil int´egr´e a` OSSIM permettant, entre autre, des scans de ports

23

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

3.7

Fonctionnement de l’architecture avec une sonde Syslog

Le principe de communication d’une sonde HIDS10 Syslog avec le serveur OSSIM est illustr´e par la figure 3.6.

F IG . 3.6 – Principe de communication entre une sonde HIDS Syslog et le serveur d’OSSIM

3.7.1

Qu’est-ce qu’une sonde HIDS

Ces sondes ont pour but de rechercher des patterns sp´ecifiques dans des fichiers de logs. D`es qu’une suite de caract`ere (pattern) appartenant a` la liste des patterns recherch´e est d´etect´e, une alerte est g´en´er´ee. Il est ainsi possible de remonter des e´ v´enements sp´ecifiques (critiques) vers la console de monitoring. De plus, a` l’aide du sid de chaque r`egle, il est possible de les utiliser dans des r`egles de corr´elation sur le serveur. 10

Host Intrusion Detection System

24

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

3.7.2

Fonctionnement

Le parser analysant le fichier Syslog d’une machine Linux est directement pr´esent sous forme native sur les agents OSSIM. Son code et ses r`egles sont pr´esents dans un seul et unique fichier /usr/share/ossimagent/pyossim/ParserSyslog.py. Il analysera le fichier de logs de mani`ere temps r´eel et informera le serveur OSSIM, via la connexion pr´esente entre l’agent et le serveur, d`es qu’un pattern pr´esent dans la liste de pattern interdits (blacklist) aura e´ t´e d´etect´e.

3.8

Fonctionnement de l’architecture avec une sonde HIDS IIS (Internet Information Services)

Le principe de communication d’une sonde HIDS11 IIS avec le serveur OSSIM est illustr´e par la figure 3.7.

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

Host Intrusion Detection System

25

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

3.8.1

Qu’est-ce qu’une sonde HIDS

Ces sondes ont pour but de rechercher des patterns sp´ecifiques dans des fichiers de logs. D`es qu’une suite de caract`ere (pattern) appartenant a` la liste des patterns recherch´e est d´etect´e, une alerte est g´en´er´ee. Il est ainsi possible de remonter des e´ v´enements sp´ecifiques (critiques) vers la console de monitoring. De plus, a` l’aide du sid de chaque r`egle, il est possible de les utiliser dans des r`egles de corr´elation sur le serveur.

3.8.2

Fonctionnement

Le serveur web de Windows (IIS) doit obligatoirement utiliser un programme sp´ecifique (SnareIIS) permettant 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 pr´esent sous forme native sur les agents OSSIM (/usr/share/ossim-agent/pyossim/ParserIIS.py) analysera le fichier de logs de mani`ere temps r´eel et transmettra par d´efaut tous les logs du serveur web au serveur OSSIM via le flux pr´esent entre le serveur et l’agent (chaque log e´ tant vu comme une alerte sur le serveur OSSIM).

26

Institut ICT, Jo¨el Winteregg (cc)

Chapitre 4

Fonctionnement du Framework (interface Web et serveur OSSIM) 4.1

Avant propos et terminologies

Un howto expliquant la configuration de base du framework (ajout et configuration d’agents et d’hˆotes a` prot´eger) est disponible a` l’adresse suivante : http ://www.ossim.net/docs/User-Manual.pdf Ce chapitre fera le lien entre les diff´erents outils d´ecrits pr´ec´edemment et les menus disponibles dans le framework d’OSSIM. Trois termes bien distincts seront employ´es dans ce chapitre. Il est tr`es important d’en saisir la diff´erence : Alerte Information de d´etection d’intrusion ou d’anomalie brut g´en´er´e par une sonde. Typiquement, les alertes Snort g´en´er´ees par un agent. Celles-ci contiendront donc un grand nombre de faux positifs... Groupe d’alertes Information correspondant au r´esultat d’une corr´elation (alerte de haut niveau). Il s’agira donc de plusieurs alertes reli´ees ensemble selon des caract´eristiques d´efinies par les directives de corr´elation. Alarme Alerte ou groupe d’alertes ayant atteint un niveau de risque sup´erieur ou e´ gal a` 2 (valeur calcul´ee selon la forumule 4.1, puis arrondie. Par exemple : 1.6 est arrondi a` 2).

4.2

Architecture des menu du framework

L’interface de configuration et monitoring offerte par OSSIM (framework) se compose de divers menu et sous-menu illustr´e par la figure 4.1 page 43. Ce chapitre traitera chacun d’eux afin que le lecteur soit ensuite capable d’utiliser plainement les fonctionnalit´es d’OSSIM.

27

SIMS - Security Intrusion Management System

4.3

D´efinition du risque

Plusieurs param`etres permettent de qualifier le niveau de dangerosit´e (risque) d’une alerte/groupe d’alertes. Il est important de bien saisir leur signification afin d’ˆetre a` mˆeme de cr´eer des r`egles de corr´elation ou mˆeme de g´erer correctement les alarmes selon leur niveau d’importance. Asset Il s’agˆıt l`a d’une valeur permettant de d´efinir l’importance d’une machine sur le r´eseau. En effet, un serveur Web sera souvent une ressource plus pr´ecieuse pour une entreprise qu’une imprimante r´eseau. Comme nous le verrons apr`es, ces sp´ecifications seront prises en compte lors du calcul du risque de chaque alerte. Il est ainsi possible de d´efinir pour chaque machine (menu Policy sous-menu Hosts) l’Asset de celles-ci. Cette valeur doit eˆ tre comprise entre 0 et 5 (0 = machine peu importante pour l’entreprise, 5 = machine tr`es importante pour l’entreprise). Priority Cette valeur permet de mesurer la gravit´e d’une alerte ou d’un groupe d’alertes isol´ee. En effet, celle-ci ne tient aucunement compte de l’environement ou de l’hˆote a` prot´eger. Ce niveau est donc uniquement d´ependant de l’alerte ou du groupe d’alertes (r´esultat d’une corr´elation). Il est donc possible d’ajuster le niveau Priority des alertes de chaque plugins via le menu Configuration, sous-menu Plugins. Celui-ci est aussi d´efinit (surcharge des priorit´es d´efinies par les alertes ind´ependantes) pour chaque r`egle de corr´elation, permettant le r´eglage de la priorit´e du r´esultat de la corr´elation (groupe d’alertes). La valeur de ce param`etre est ajustable entre 0 et 5. Reliability En terme de risque, ce param`etre pourrait s’appeler la ”probabilit´e”. Celui-ci est d´efini pour chaque alerte ind´ependante (via le menu Configuration, sous-menu Plugins). Il est ainsi possible de qualifier la probabilit´e que l’alerte se produise. Ce param`etre sera principalement ajust´e sur les groupes d’alertes par le moteur de corr´elation (surcharge de la valeur d´efinie pour le plugin). Celui-ci sera capable d’augmenter la reliability d’un groupe d’alarme a` chaque fois qu’une sous-r`egle sera match´ee. Ceci prouvera pas a` pas que ce groupe d’alertes (alerte de haut niveau) n’est pas un faux positif. Le terme reliability peut donc eˆ tre traduit par la fiabilit´e qu’une alarme n’est pas un faux positif. La valeur de ce param`etre est comprise entre 0 et 10 (´equivalent a` 0% = c’est un faux positif et 100%= ce n’est pas un faux positif). Le risque permet de lier les trois param`etres pr´ec´edent par la formule suivante (4.1) et d’´etablir si une alerte ou un groupe d’alertes est ”mut´e” en alarme : Asset ∗ P riority ∗ Reliability (4.1) 10 Le lien entre l’´etape 6 et 9 de la figure 2.2 du chapitre 2 illustre la ”mutation” d’alertes/groupe d’alertes en alarmes. Risk =

4.4

Menu Control Panel

Ce menu offre quatre diff´erentes vues :

28

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

4.4.1

Metrics

Ce sous-menu affiche les informations relatives a` l’algorithme CALM (d´ecrit dans la section 2.3.3) de mani`ere globale ainsi que sur les r´eseaux d´efinis par l’administrateur et les hˆotes dont les niveaux A1 ou C2 sont e´ lev´es. Une visualisation graphique est offerte ainsi qu’un historique. Il est donc possible d’observer les param`etres A et C de mani`ere temps r´eel via cette interface. CALM r´ecup`ere toutes les alertes afin de les associer au niveau A et/ou C de l’hˆote voulu sur un interval de temps. Son fonctionnement est illustr´e par la figure 4.2 page 44 . Il offre une vue rapide du nombre d’alertes d´etect´ees sur les hˆotes du r´eseau. Par un clic sur l’icone d’information, il est possible de g´en´erer un ticket permettant le d´epos de commentaires sur le serveur au sujet des niveaux observ´es (pour plus d’explications consultez la section 4.5.5). L’icone graphique offre quant a` lui (lors d’un clic sur celui-ci) un affichage des niveaux A et C de l’hˆote ou r´eseau sp´ecifi´e.

4.4.2

Alarms

Ce sous-menu offre une vue des alarmes d´etect´ees. En effet, les e´ v´enements affich´es contiendront uniquement des alarmes de haut niveau (niveau de risque sup´erieur ou e´ gal a` 2, calcul´es selon la formule 4.1). Il est alors possible de cliquer sur le nom de l’alarme (champ Alarm) afin d’en observer plus pr´ecis´ement les causes. Deux situations sont alors envisageables : L’alarme provient d’une directive de corr´elation (groupe d’alertes ayant un risque sup´erieur ou e´ gal a` 2) Un menu permettant la visualisation des r`egles ”match´ees” est affich´e lors du clic sur le nom de l’alarme. Dans cette nouvelle vue, il sera ensuite possible (via le lien Visualize alarm et une applet Java3 ) d’observer graphiquement les trames, ayant g´en´er´e l’alarme, transiter sur le r´eseau. Cette reconstitution est effectu´ee a` l’aide de la base de donn´ee Snort et des adresses IP contenues dans les diff´erentes alertes. L’alarme provient d’une alerte de risque e´ lev´e (plus grand ou e´ gal a` 2) Le seul contenu pertinant pouvant eˆ tre affich´e sera le dump4 de celle-ci. Lors du clic sur le nom de l’alarme l’utilisateur sera redirig´e sur l’interface d’ACID (´equivalent au sous-menu Alerts de ce menu). Un filtrage sera automatiquement appliqu´e afin d’afficher uniquement les alertes provenant des mˆemes adresses IP dans la fenˆetre temporelle de l’alerte. Il sera ainsi possible d’observer l’alerte ayant provoqu´e l’alarme (risque plus grand ou e´ gal a` 2) ainsi que toutes les autres alertes de la mˆeme fenˆetre temporelle. Par d´efaut, toutes les alarmes ont un status (champ Status) OPEN. Cela signifie qu’aucun administrateur en charge de la s´ecurit´e n’a analys´e l’alarme ou n’a r´eussi a` y trouver une solution. Plusieurs possibilit´es s’offrent alors a` lui : 1. Effacer l’alarme (il s’agit clairement d’un faux positif). L’alarme sera effac´ee a` jamais... 1

niveau d’attaque auquel un syst`eme est sujet, mesure le risque potentiel dˆu aux attaques d´etect´ees niveau de fiabilit´e d’une machine, mesure le niveau de probabilit´e qu’une machine soit compromise (hacker) 3 http ://scanmap3d.sourceforge.net/ 4 Contenu brut de l’alerte Snort 2

29

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

2. Fermer le status de l’alarme (par un clic sur OPEN contenu dans le champ Status). Dans ce cas l’alarme n’est pas effac´ee mais n’est plus directment affich´ee dans le menu Alarms. Afin de visualiser a` nouveau les alarmes ferm´ees (status CLOSED), il sera n´ecessaire de d´es´electionner l’onglet Hide closed alarms 3. G´en´erer un ticket permettant la saisie d’informations sur les actions entreprises par l’administrateur en charge de la s´ecurit´e (par un clic sur l’icone d’information contenu dans le champ Action). Il aura de plus la possibilit´e de modifier le status de l’alarme (OPEN ou CLOSED) afin d’indiquer si le probl`eme a pu eˆ tre r´esolu ou non. Ce fonctionnement est particuli`erement int´eressant lorsque plusieurs administrateur en charge de la s´ecurit´e travaillent sur le mˆeme framework OSSIM. Le principe de g´en´eration de ticket et d’ajout d’informations au sujet d’une alarme est d´ecrit plus en d´etail dans la section 4.5.5. Calcul du risque des alarmes Le calcul du risque des alarmes (champ Risk de ce sous-menu) est op´er´e a` l’aide de la formule 4.1. Les valeurs des param`etres Priority et Reliability sont directement tir´ees du r´esultat de la corr´elation (si l’alarme est un output d’une corr´elation, groupe d’alertes) ou de l’alarme unique (si l’alarme est une alerte de niveau de risque sup´erieur a` 2). Le calcul du risque est donc op´er´e de mani`ere diff´erente entre les alertes (section 4.4.3) et les alarmes. En effet, dans le calcul du risque des alarmes, la valeur du param`etre Asset sera la valeur la plus e´ lev´ee entre la source de l’alarme (de l’attaque) et la destination de celle-ci. Les autres param`etres (Priority et Reliability) restent quant a` eux les mˆemes que pour l’alerte ou groupe d’alertes ayant g´en´er´e l’alarme. Comme dans le calcul du risque des alertes (section 4.4.3), la valeur de l’Asset (source et destination de l’attaque) est en premier lieu r´ecup´er´ee dans les configurations des machines (sous-menu Hosts du menu Policy) puis (si aucune valeur n’est configur´ee dans ce sous-menu) dans les configurations des r´eseaux (´etablies dans le sous-menu Network du menu Policy).

4.4.3

Alerts

Ce sous-menu permet la visualisation des alertes g´en´er´ees (alertes brutes) par les diff´erentes sondes connect´ees au serveur ainsi que les r´esultats des corr´elations qui ont abouties (r`egles match´ees). En effet, ce sous-menu permet la consultation de toutes les alertes r´ecolt´ees par le serveur avant l’application des diff´erents proc´ed´es de corr´elation sur celles-ci. La valeur du risque (champ Risk) calcul´e pour chaque alerte est directement op´er´e a` l’aide de la formule 4.1. Comme expliqu´e en section 4.3, les valeurs des param`etres Priority et Reliability utilis´es dans le calcul du risque sont propres aux alertes (configur´e dans le sous-menu Plugins du menu Configuration). La valeur de l’Asset utilis´ee pour le calcul du risque est celle configur´ee pour la machine de destination ou, si celle-ci n’est pas configur´ee dans le sous-menu Hosts du menu Policy, celle configur´ee pour le r´eseau auquel est connect´e la machine de destination (configur´e dans le sous-menu Network du menu Policy).

30

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

Ce sous-menu est en fait d’une version quelque peu modifi´ee d’ACID5 . Il sera donc possible d’obtenir des informations d´etaill´ees et pr´ecises sur les alertes via ce sous-menu. Pour de plus amples informations sur l’utilisation d’ACID, je vous laisse consulter la documentation suivante : http ://acidlab.sourceforge.net/acid instruct.html

4.4.4

Vulnerabilities

Ce sous-menu offre une interface Web au scanner de vul´erabilit´es Nessus6 . Celle-ci permettra l’activation du script /usr/share/ossim/scripts/do nessus.pl, qui proc´edera a` l’interrogation de la base de donn´ees d’OSSIM afin de d´eterminer quelles sont les machines et/ou r´eseaux a` scanner (Les machines a` scanner sont configur´ees a` l’aide du sous-menu Hosts du menu Policy). Le script do nessus.pl effectuera ensuite le scan par l’appel du client nessus install´e sur le serveur OSSIM. Les rapports de s´ecurit´es g´en´er´es par Nessus seront ensuite disponibles dans ce sous-menu. Ce script s’occupe ensuite de remplir la table host plugin sid r´epertoriant les sid Nessus pour lesquels chaque machine est vuln´erable. Ce fonctionnement (cross-corr´elation Nessus-Snort) est d´ecrit plus en d´etail dans la section 4.8.2.

4.5

Reports Menu

Ce menu offre cinq diff´erents sous-menus en rapport avec la s´ecurit´e du r´eseau.

4.5.1

Host Report

Ce sous-menu permet d’observer les machines configur´ees dans le sous-menu Hosts du menu Policy. Il est ainsi possible d’observer le hostname, l’Asset, l’IP et l’OS des machines configur´ees. En cliquant sur le hostname de la machine voulue, il est possible d’acc´eder a` diff´erenes caract´eristiques et informations de celle-ci. Il sera ainsi possible d’observer les caract´eristiques suivantes : – Section principale Inventory Inventaire de la machine (Nom, IP, Syst`eme d’exploitation, adresse MAC, Sensor analysant son trafic, Ports ouverts). Toutes les caract´eristiques affich´ees sont celles configur´ees par l’administrateur r´eseau, mis a` part les ports ouverts. En effet, le plugin PADS7 permet la d´etection des ports ouverts d’une machine uniquement par l’analyse des trames transitant sur le r´eseau. C’est donc les informations fournie par PADS qui permettent l’identification des ports ouverts de la machine en question. En cliquant sur le mode Passive (mode de d´etection de PADS), le mode de d´etection des ports passe en active. Il est alors possible d’observer la liste des ports ouverts a` l’aide d’un 5

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

31

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

programme de scan actif (nmap). Le lien update permet quant a` lui l’´ex´ecution de nmap (programme de scan actif) afin de mettre a` jour la liste des ports ouverts. Metrics Niveau ”A” et ”C” de la machine s´electionn´ee (niveaux calcul´es a` l’aide de l’algorithme CALM8 . Usage Offre l’affichage graphique des informations fournies par Ntop9 . En effet, ce plugin met en place un serveur web sur l’agent qui permettra l’affichage de toutes les donn´ees statistiques r´ecolt´ees par Ntop. Le lien (Usage) fournit donc uniquement une redirection vers le serveur Web du plugin Ntop de l’agent voulu (agent analysant les informations de la machine en question). Anomalies permettant de visualiser la d´etection d’anomalies op´er´ee par Ntop. Il s’agˆıt l`a des r´esultats de l’analyse heuristique d´ecrite en section J. – Sous-section Alarms : Source or Dest Ce lien permet la visualisation des alarmes de haut niveau, ayant comme adresse source ou destination, l’adresse de la machine en question. Source Ce lien permet la visualistion des alarmes de haut niveau, ayant l’adresse de la machine en question comme source. Destination Ce lien permet la visalisation des alarmes de haut niveau, ayant l’adresse de la machine 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 g´en´er´ees par les diff´erents plugins. L’affichage fourni par le lien Main, permet de connaˆıtre le nombre d’occurence d’alertes de la machine en question (comme source et/ou destination). Il est ensuite possible de continuer son investigation en cliquant sur les liens offerts par l’interface d’ACID. Src Unique alerts Ce lien affiche directement les alertes (via ACID) ayant l’adresse de la machine en question comme source. Il est ensuite possible de continuer son investigation en cliquant sur les liens offerts par l’interface d’ACID. Dst Unique alerts Ce lien affiche directement les alertes (via ACID) ayant l’adresse de la machine en question comme destination. Il est ensuite possible de continuer son investigation en cliquant sur les liens offerts par l’interface d’ACID. – Sous-section Vulnerabilites : Vulnmeter Ce lien offre une interface entre le framework et le scanner de vuln´erabilit´es Nessus. En effet, cette interface affiche le nombre de failles d´etect´ees sur toutes les machines scann´ees en mettant en e´ vidence (en rouge) le r´esultat de la machine en question. Il suffira ensuite de cliquer sur l’adresse IP de la machine voulue afin d’observer le rapport de vuln´erabilit´e de celle-ci. Le lien update scan offre la possibilit´e d’effectuer un nouveau scan afin de mettre a` jour la liste des vuln´erabilit´es de toutes les machines configur´ee pour un scan Nessus. 8

Principe d´ecrit en section 4.4.1 Outil d’analyse temps r´eel du trafic r´eseau. Logiciel d´ecrit dans la section 3.3.1 10 Analysis Console for Intrusion Databases, http ://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html 9

32

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

Security Problems Ce lien offre la vue directe du rapport de vuln´erabilit´es de la machine en question (´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 fenˆetre temporelle, des niveaux ”A” (Top Attacked) et ”C” (Top Attacker) de l’algorithme CALM (expliqu´e en section 2.3.3). Il permet d’observer les 10 machines figurant le plus souvent comme source des alertes (Top Attacker) et les 10 figurant les plus souvent comme destination des alertes (Top Attacked). En cliquant sur le nom d’une machine, il sera possible d’observer les alertes relatives a` celle-ci dans ACID. Le graphique Top 10 used ports offre une vision des ports de destination des alertes d´etect´ees. Il permet ainsi de d´eterminer quels sont les services les plus attaqu´es. En cliquant sur le num´ero de port voulu, il est possibles d’observer toutes les alertes a` destination de celui-ci (`a l’aide de l’interface d’ACID). Les informations fournies par Top 10 alerts offre simplement une vision textuelle et graphique des alertes les plus rencontr´ees, alors que Top 10 alerts by Risk offre une vision des alertes les plus rencontr´ees ayant un risque e´ lev´e.

4.5.3

PDF Report

Ce sous-menu permet la r´ecup´eration de rapports PDF. Il est ainsi possible de r´ecup´erer 3 diff´erents rapports PDF, comportant chacun des informations sp´ecifiques : Security Report Permettant la g´en´eration d’un document PDF identique au sous-menu Security Report (Section 4.5.2) Metrics Report Permettant la g´en´eration d’un document PDF, offrant une vue num´erique des niveau ”A” et ”C” de l’algorithme CALM11 en fonction des fenˆetres temporelles s´electionn´ees. Incident Report Permettant la g´en´eration d’un document PDF, offrant le r´esum´e des incidents report´es par les gestionnaires du r´eseaux (personnes physiques) utilisant OSSIM (sous-menu Incident, menu Reports)

4.5.4

Anomalies

Ce sous-menu offre l’affichage des r´esultats de l’algorithme heuristique Holt-Winter (expliqu´e en section 2.3.3). Cette fonctionnalit´e comporte malheureusement certains bugs qui la rende encore non fiable. 11

algorithme expliqu´e en section 2.3.3

33

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

4.5.5

Incident

Ce sous-menu offre un archivage des commentaires d´epos´es par les diff´erents administrateurs en charge de la s´ecurit´e. En effet, ce sous-menu permet de d´eposer des annotations sur les activit´es effectu´ees ainsi que de fermer les alarmes/probl`emes ayant e´ t´e r´esolus (principe de fermeture d’alarmes expliqu´e en section 4.4.2). Diff´erents sujets d’archivages sont dipsonibles : OSSIM Permettant de d´eposer des commentaires sur des alarmes sp´ecifiques (ticket ALA) ou sur des m´etriques marginaux (ticket MET). Il s’agit donc du menu dans lequel l’utilisateur est renvoy´e lorsqu’il clic sur l’icone d’information dans le sous-menu Metrics ou Alarms du menu Control Panel. Hardware Permettant de d´eposer des commentaires sur le hardware d’OSSIM et des probl`emes rencontr´es sur celui-ci. Install Permettant de d´eposer des commentaires sur l’installation de nouveaux agents et/ou plugins. Un outil de recherche int´egr´e dans la page Web d’incidents, permettra de retrouver et trier les commentaires sur la base de mots cl´es. Celui-ci propose plus ou moins de champs de recherche (Filter Advenced ou Filter simple). Apr`es avoir s´electionn´e son sujet d’archivage il sera possible d’ajouter de nouveaux commentaire en cliquant sur lien Insert new Incident. Vous pourrez ensuite compl´eter les champs offerts et ajuster le niveau de priorit´e de l’incident (commentaire).

4.6

Monitor Menu

Cette section offre une repr´esentation graphique de l’´etat du r´eseaux et des diff´erents agents plac´es sur celui-ci.

4.6.1

Riskmeter

Ce sous-menu offre uniquement l’affichage de l’algorithme CALM12 . Il s’agit donc d’une repr´esentation r´eduite du sous-menu Metrics du menu Control Panel (explications en section 4.4.1).

4.6.2

Session

Ce sous-menu offre une vue des sessions TCP actives (ou qui l’ont e´ t´e r´ecemment). Cette visualisation fait appel a` l’outil Ntop (explications technique en section 3.3). En effet, celui-ci r´epertorie toutes les connexions TCP qu’il apperc¸oit depuis le ou les agents sur lesquels il est plac´e. Il offre ensuite, via son 12

Algorithme expliqu´e en sections 4.4.1 et 2.3.3

34

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

interface web (port 3000 de l’agent) une liste de connexions d´etect´ees. Cette sous-section offre ensuite la possibilit´e de visualiser ces informations en fonction d’une sonde (agent Ntop) ou en fonction d’un r´eseau. Plusieurs comportements sont alors possibles : En fonction d’une sonde Ce sous-menu affiche simplement la page web fournie par le serveur web Ntop de la sonde en question. En fonction d’un r´eseau Ce sous-menu affiche toutes les informations disponibles sur les sessions TCP des hˆotes situ´ees sur le r´eseau en question. Pour ce faire, le framework effectuera un scan Nmap13 de tout le r´eseau en question. Pour chaque machine d´ecouverte, il d´eterminera avec quelle sonde celle-ci est associ´ee (association effectu´ee dans le sous-menu Hosts du menu Policy, champ Sensors). Une fois les associations r´esolues, il interrogera les serveur web Ntop des sondes en question afin de r´ecup´erer les informations sur les sessions TCP des machines voulues. Il g´en´erera ensuite une page web a` l’aide des informations r´ecolt´ees.

4.6.3

Network

Cette sous-section fait simplement appel a` l’interface web fournie par les sondes h´ebergeant un agent Ntop. Il est ainsi possible de s´electionner l’agent sur lequel l’on d´esire se connecter puis de choisir le genre d’informations d´esir´ees. Ces informations sont donc relative a` la sonde Ntop (r´eseau sur lequel celle-ci est plac´ee) et non pas a` un hˆote ou un r´eseau sp´ecifique. ´ Etant donn´e que ce sous-menu fait appel a` l’interface web de Ntop, de plus amples informations sur son utilisation sont disponibles dans le document suivant : http ://www.ntop.org/ntop-overview.pdf

4.6.4

Sensors

Ce sous-menu permet simplement la visualisation des plugins install´es sur les diff´erents agents actifs. A l’aide de celle-ci, il sera possible d’arrˆeter ou de d´esactiver le plugin a` distance (lien stop ou disable). La d´esactivation du plugin engendrera son non activation lors d’un red´emarrage de l’agent alors que l’arrˆet n’aura aucune inscidence lors d’un red´emarrage de l’agent. Lorsqu’un plugin est arrˆet´e ou d´esactiv´e, il est possible de le red´emarrer ou le r´eactiver a` l’aide de ce sous-menu (lien start ou enable).

4.7

Policy Menu

Ce menu offre une interface de configuration du r´eseau a` surveiller. En effet, il est n´ecessaire d’indiquer les plages d’adresses IP des r´eseaux a` analyser ainsi que les hˆotes a` surveiler. Les explications ci-dessous seront succintes puisque le document suivant : http ://www.ossim.net/docs/User-Manual.pdf offre d´ej`a des explications compl`etes a` ce sujet. 13

Outil de scan r´eseaux

35

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

4.7.1

Hosts

Ce sous-menu permet la configuration des machines a` surveiller. En effet, il est possible de d´efinir l’importance de la machine (champ asset), les seuils d’alerte pour l’algorithme CALM associ´e a` la machine (champ Threshold A et Threshold C), le profile RRD utilis´e pour l’analyse heuristique sur la machine en question (d´etection de d´epassement de seuils et algorithme Holt-Winter) champ RRD Profile, le ou les agents e´ tant capable de r´ecup´erer (sniffer) les informations r´eseaux de la machine (champ Sensors), le type de scan a` effectuer (champ Scantype).

4.7.2

Networks

Ce sous-menu permet la d´efinition des r´eseaux a` surveiller. En effet, il est possible de d´efinir la plage d’adresses du r´eseau (champ IPs), l’importance de celui-ci (champ asset), les seuils d’alerte pour l’algorithme CALM associ´e au r´eseau (champ Threshold A et Threshold C), le profile RRD utilis´e pour l’analyse heuristique sur le r´eseau en question (d´etection de d´epassement de seuils et algorithme HoltWinter) champ RRD Profile, le type de scan a` effectuer (champ Scantype).

4.7.3

Network groups

A l’aide des configurations des r´eseaux d´efini pr´ec´edemment (section 4.7.2), il est possible a` l’aide de ce sous-menu de d´efinir des groupes de r´eseaux ayant des caract´eristiques communes.

4.7.4

Sensors

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

4.7.5

Signatures

Ce sous-menu permet la cr´eation de groupe de signatures Snort. Ceux-ci seront ensuite utilis´e par le sous-menu Policy actuellement non disponible dans OSSIM pour cause de bug.

4.7.6

Ports

Ce sous-menu permet la cr´eation de groupes de ports. Ceux-ci seront ensuite utilis´e par le sous-menu Policy actuellement non disponible dans OSSIM pour cause de bug.

4.8

Correlation Menu

Ce menu offre trois diff´erents sous-menus :

36

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

4.8.1

Directives

Ce sous-menu permet la visualisation des r`egles de corr´elation d´efinies sur le serveur OSSIM. Cellesci sont appliqu´ees de mani`ere temps r´eel aux alertes arrivant sur le serveur. Ces r`egles permettent la cr´eation d’un diagramme d’´etats d´efinissant les alertes a` matcher afin de lever une alerte de haut niveau (groupe d’alertes). Ce principe de fonctionnement est expliqu´e dans la section 2.3.3, paragraphe Corr´elation par diagramme d’´etats. Ces alertes de haut niveau seront ensuite stock´ees dans le sous´ menu Alerts du menu Control Panel. Etant donn´e que la quasi totalit´e d’entre elles fournissent un niveau de risque sup´erieur a` 2 (provenant de la configuration d’une priorit´e souvent e´ lev´ee dans les directives de corr´elation), ces alertes de haut niveau seront ”mut´ees” en alarmes et affich´ees dans le sous-menu Alarms du menu Control Panel. La configuration et l’´etablissement des directives de corr´elation sont d´etaill´es dans l’annexe I.

4.8.2

Cross Correlation

Ce proc´ed´e permettra d’augmenter la priorit´e d’une alerte Snort lorsque l’attaque d´efinie par celle-ci aura e´ t´e d´ecouverte comme possible par Nessus. Les associations entre les alertes de Snort et les sid des r`egles NASL14 de Nessus sont affich´ees dans ce sous-menu (affichage correspondant a` la table plugin reference de la base de donn´ee d’OSSIM). Les diff´erentes colonnes affich´ees on les significations suivantes : Plugin id Identification du plugin qui va eˆ tre associ´e avec un script NASL Nessus. Il s’agˆıt, pour le moment, uniquement du plugin Snort. Plugin sid Identification de l’´ev´enement du plugin (Plugin id) qui va eˆ tre associ´ee avec un script NASL Nessus. Il s’agˆıt, pour le moment, uniquement de r`egles Snort. Reference id Identification du plugin de r´ef´erence (Nessus en l’occurence). Reference sid Identification de l’´ev´enement associ´e au plugin de r´ef´erence (script NASL). Ces informations repr´esent´ees normalement sous forme num´erique sont simplement remplac´ees par leurs d´efinition textuelle contenue dans la base de donn´ee OSSIM. Le script do nessus.pl ex´ecut´e lors d’un scan Nessus (section 4.4.4) s’occupe ensuite de remplir la table host plugin sid r´epertoriant les sid Nessus pour lesquel chaque machine est vuln´erable. Une fois ces informations connues, le moteur de cross-corr´elation pourra rechercher pour chaque alerte rec¸ue, son existance dans la table plugin reference. Si un tel e´ v´enement est r´epertori´e dans cette table, le moteur de corr´elation pourra en tirer le plugin sid de Nessus correspondant. Il pourra ensuite, rechercher dans la table host plugin sid l’existance de ce sid de Nessus pour la machine cible de l’alerte. Si un tel sid est pr´esent, la priorit´e et la fiabilit´e (reliabiliy) de l’alerte Snort seront modifi´es de la sorte : Fiabilit´e Addition de la fiabilit´e de la ”r`egle” Nessus match´ee et de la r`egle Snort Priorit´e La valeur maximale entre la priorit´e de la ”r`egle” Nessus match´ee et la r`egle Snort 14

Nessus Attack Scripting Language, language permettant d’´etablir des r`egles de test Nessus

37

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

L’alerte sera ensuite automatiquement mut´ee en Alarme afin que celle-ci apparaisse dans le sous-menu Alarms du menu Control Panel du framework.

4.8.3

Backlog

Ce sous-menu r´epertorie les ”paquetages” de backlog des alarmes provenant d’une directive de corr´elation. En effet, lorsqu’une alarme est lev´ee suite a` l’aboutissement (complet ou partiel) d’une directive de corr´elation cela signifie que plusieurs alertes ont e´ t´e match´ees par la directive. Le ”paquetage” de l’alarme contient alors les r´ef´erences a` ces alertes. Il sera ainsi possible, lors de la consultation des alarmes (sousmenu Alarms du menu Control Panel), de cliquer sur le nom de l’alarme r´esultant d’une corr´elation afin de pouvoir observer les alertes contenues dans les ”paquetages” backlogs (cf. section 4.4.2).

4.9

Configuration Menu

Ce menu permet la configuration de certains param`etres d’OSSIM.

4.9.1

Main

Ce sous-menu offre une interface de configuration globale d’OSSIM. En effet, le framework, les agents et leurs plugins r´ecup`ereront ces diff´erentes informations. Ce sous-menu se d´ecompose en plusieurs sections : Language Configuration de la langue du framework et des pr´ef´erences d’affichage locale dir. Fonctionnalit´e pas encore impl´ement´ee Server Configuration des caract´eristiques r´eseau du serveur (adresse IP et port). Snort Configuration des caract´eristiques propres a` Snort (base de donn´ees, login et chemin d’acc`es) Metrics Configuration du seuil d’alerte (threshold) lors d’un d´epassement des m´etriques (algorithme CALM), ainsi que du d´ebit de sortie des alertes de l’accumulateur CALM (recovery). phpGACL Configuration de la base de donn´ee des r`egles ACL (Access Control List) permettant la gesion des utilisateurs et d’acc`es d’OSSIM. PHP Configuration des chemins des libraires php. Le champ use svg graphics initialis´e a` yes permet l’affichage graphique du thermom`etre du sousmenu Metrics du menu Control Panel. Celui-ci n´ecessite l’installation d’un plugin sur le navigateur client (plugin SVG). Le champ use resolv initialis´e a` yes offre la r´esolution de noms pour les adresses IP affich´ees par OSSIM. RRD Configuration des chemis vers les librairies graphiques et scripts permettant la g´en´eration des graphiques d’OSSIM (Metrics, etc...) Links Configuration du chemin web (URI) d’OSSIM (ossim link) ainsi que celui de Ntop et Opennms.

38

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

Backup Configuration de la base de donn´ees de backup (fonctionnalit´e pas encore impl´ement´ee, puisque les backups sont sauvgard´ees dans des fichiers .sgl.gz) Nessus Configuration du user/login utilis´e par le client Nessus pour effectuer les scans, ainsi que de l’hˆote h´ebergant le serveur Nessus. Mise en place du mot de passe Nessus effectu´e en section A.3.3. ACID Configuration du chemin (URI) vers ACID, ainsi que de la pair user/pass lors de l’utilisation HTTPS d’ACID. Configuration de la paire user/pass d’OSSIM permettant la connexion a` l’interface Web du framework. External applications Configuration des chemins complets vers les applicatifs utilis´es par le serveur OSSIM. Le champ have scanmap3d permet l’activation ou non de l’affichage 3D des alertes Snort (explications en section 4.4.2)

4.9.2

Users

Ce sous-menu permet la cr´eation de comptes utilisateurs pour l’interface web d’OSSIM. En effet, il est possible de cr´eer diff´erents comptes ayant diff´erents droits d’acc`es. Il sera ainsi possible de d´efinir pour chaque utilisateur, les menu et sous-menu qu’il sera autoris´e de visualiser.

4.9.3

Plugins

Ce sous-menu offre l’affichage de la liste des plugins offerts par OSSIM. Chaque e´ v´enement de chaque plugin est index´e a` l’aide d’un sid (identifiant unique pour les e´ v´enements du plugin). Il sera ainsi possible de r´ef´erencer chaque e´ v´enement a` l’aide d’une pair id/sid o`u id est l’identifiant du plugin et sid l’identifiant de l’´ev´enement pour le plugin s´electionn´e. Cette m´ethode de r´ef´erencement des e´ v´enements permettra l’utilisation de ceux-ci dans des directives de corr´elation. Plus d’informations sur leur utilisation dans les directives de corr´elation en section I.

4.9.4

RRD config

Ce sous-menu permet l’´etablissement de profils RRD utilis´es par le plugin RRD des agents OSSIM. Le principe de fonctionnement de ce plugin a e´ t´e abord´e dans la section 3.3.1 lors de la pr´esentation de l’outil d’analyse Ntop. Ce plugin effectuera deux types d’analyses sur chaque agent OSSIM : 1. Analyse heuristique : Utilisation d’un algorithme de lissage exponentiel (Holt-Winter) pour la pr´ediction de valeurs (valeurs fournies par Ntop). Des explications d´etaill´ees sur l’analyse heuristique Holt-winter est fournie en annexe J. 2. D´etection de d´epassement de seuils : Comparaison des seuils configur´es avec les valeurs courantes fournies par Ntop. Les profils cr´ee´ a` l’aide de ce sous-menu pourront ensuite eˆ tre utilis´es dans les polices de s´ecurit´e des machines et des r´eseaux d´efinis a` l’aide du framework. Il sera ainsi possible d’appliquer le profile sou-

39

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

hait´e sur ces e´ l´ements. Les attributs repr´esentent les informations fournies par Ntop (compteurs de bytes, etc...). Sur chacun d’eux, il est possible de d´efinir des seuils (threshold) afin d’ˆetre averti (g´en´eration d’une alerte rrd threshold affich´ee dans le sous-menu Alerts du menu Control Panel) lorsqu’un compteur d´epasse le seuil indiqu´e. Les param`etres alpha et beta sont quant a` eux propres a` l’algorithme heuristique Holt-winter. Les alertes g´en´er´ees par cet algorithme (rrd anomaly) seront ensuite visibles dans le sous-menu Anomalies du menu Report. Elles n’apparaˆıtront donc jamais dans le mˆeme sous-menu que les alertes de types rrd threshold.

Param`etres de configuration a` disposition Attribute Nom du param`etre (compteur Ntop) pour lequel la ligne de configuration s’applique. Threshold Seuil que l’attribut devra atteindre pour qu’une alerte rrd threshold soit g´en´er´ee. Priority Priorit´e de l’alerte rrd threshold entrant de le calcul du risque effectu´e par le serveur lors de la r´eception de l’alerte (priorit´e non associ´ee aux alertes de type rrd anomaly). Alpha Param`etre alpha de l’algorithme heuristique Holt-winter g´en´erant une alerte de type rrd anomaly. Beta Param`etre beta de l’algorithme heuristique Holt-winter g´en´erant une alerte de type rrd anomaly. Persistence Nombre de fois qu’un d´epassement de seuil ou qu’une anomalie doit eˆ tre aperc¸ue pour l’attribut en question afin qu’une alerte rrd threshold ou rrd anomaly (suivant le cas) soit g´en´er´ee. Enable Activation ou non de l’attribut dans le profile. Il est important de noter que le plugin RRD effectue p´eriodiquement (chaque 300 secondes) l’analyse des donn´ees fournies par Ntop (stock´ee dans la base de donn´ee tourniquet RRD). Le param`etre persistence se base donc sur cette granularit´e afin de d´ecider de la g´en´eration d’une alerte. En effet, si celui-ci est configur´e a` 3, il faudra que trois contrˆoles successifs des valeurs (anomalie et/ou seuil) soit sup´erieur aux valeurs autoris´ees afin qu’une alerte soit g´en´er´ee (alerte rrd anomaly et/ou rrd threshold). Cela signifiera qu’un d´epassement aura e´ t´e observ´e durant au moins 15 minutes.

Configuration L’unit´e des attributs (pour la configuration des seuils) n’est malheureusement pas indiqu´ee sur l’interface de configuration. Certains attributs sont exprim´es de mani`ere relative alors que d’autres de mani`ere absolue (par exemple : bit/s et bit). Afin de connaˆıtre l’unit´e utilis´ee par chaque attribut, il est pr´ef´erable de consulter leurs graphiques via Ntop. En effet, l’unit´e est indiqu´ee verticalement sur la gauche des graphs. Les valeurs configur´ees pour les seuils sont utilis´ees pour des p´eriodes de 5 minutes (par d´efaut). Par exemple, cela signifie que si IPHTTPrcvdBytes vaut 8000, nous acceptons de recevoir 8ko du protocole

40

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

HTTP toutes les 5 minutes, donc en quelque sorte 8ko/5min. La configuration des param`etres propres a` l’algorithme Holt-Winter sont expliqu´es dans l’annexe J. Tous ces param`etres permettent l’adaptation de la d´etection de seuils et de l’algorithme heuristique HoltWinter en fonction du segment r´eseau a` surveiller. ATTENTION : OSSIM Version : 0.9.8rc2 contient des erreurs d’impl´ementation sur l’utilisation de Holt-Winter par rrd plugin.pl ! !

4.9.5

Host scan

Ce sous-menu permet la visualisation des hˆotes a` scaner a` l’aide de Nessus ou Nmap.

4.10

Tools Menu

Ce menu offre trois diff´erents sous-menus :

4.10.1

Net Scan

Ce sous-menu fait office d’interface avec le programme Open Source de scan r´eseaux nmap. Il permettra ainsi de scanner l’un des r´eseau d´efinit dans le sous-menu Network du menu Policy ou d’indiquer manuellement la plage d’adresses a` scanner. Une fois le scan op´er´e, il sera possible d’ins´erer ou mettre automatiquement a` jour la configuration (du sous-menu Hosts du menu Policy) des machines d´etect´ees en cliquant sur le bouton update database values.

4.10.2

Rule viewer

Ce sous-menu offre simplement une interface de consultation des r`egles Snort. En effet, il peut eˆ tre int´eressant d’observer la syntaxe d’une r`egle plutˆot que son nom. Pour l’utilisation de cette fonctionnalit´e, il sera n´ecessaire d’installer (copier) la totalit´e des r`egles Snort dans le r´epertoire /etc/snort/rules/ du serveur OSSIM.

4.10.3

Backup

Ce sous-menu permet la gestion des backups des alertes. En effet, le script /etc/cron.daily/acid-backup.pl plac´e sur le serveur OSSIM archivera journali`erement les vieilles alertes contenues dans ACID permattant ainsi de limiter le temps de recherche des alertes dans la base de donn´ees. Ce sous-menu affichera 14

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

41

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

donc les fichiers de backup contenu dans le r´epertoire /var/lib/ossim/bakup/ du serveur et permettra de r´eins´erer des backups pr´ec´edentes afin de retrouver des e´ v´enements d´ej`a archiv´es. Inversement, il sera aussi possible de retirer les donn´ees r´eins´er´ees dans la base de donn´ees.

42

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

F IG . 4.1 – Arborescence des menus d’OSSIM

43

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

F IG . 4.2 – Principe de d’accumulation des alertes op´er´e par CALM

44

Institut ICT, Jo¨el Winteregg (cc)

Chapitre 5

Conclusion OSSIM se r´ev`ele eˆ tre une solution proposant des concepts d’analyses tr`es innovateurs. En effet, peu de solutions Open Source proposent actuellement une telle palette de proc´ed´es d’analyse d’´ev´enements de s´ecurit´e : – R´ecup´eration d’´ev´enements d’infrastructures h´et´erog`enes (alertes de NIDS, logs, etc...). – Attribution d’une s´ev´erit´e a` chaque e´ v´enement en fonction de l’attention que l’on porte au bien potentiellement attaqu´e (priorization des alertes). – Corr´elation crois´ee (Nessus - Snort) permettant la modification de la s´ev´erit´e des alertes en fonction des vuln´erabilit´es de la cible de l’attaque potentielle. – Analyse comportementale du r´eseau permettant la g´en´eration d’alertes en fonction du comportement des utilisateurs (Ntop et l’algoritme Holt-Winter de RRD). – Corr´elation des e´ v´enements et int´egration des e´ v´enements de l’analyse comportementale dans ce proc´ed´e. ´ Etant toujours en d´eveloppement, OSSIM reste malheureusement encore non utilisable dans un environnement de production. En effet, son installation et les tests pr´eliminaires semblent encore poser passablement de probl`emes. Les d´eveloppeurs d’OSSIM ont principalement concentr´e leurs efforts sur les proc´ed´es d’analyse (encore inexistant sur des solutions Open Source). Leurs conceptes innovateurs reposent d`es lors sur des bases quelques peu instables et difficiles a` faire co-exister. En terme de concepts et de proc´ed´es d’analyse, OSSIM n’a rien a` envier aux solutions commerciales d’envergure comme : – ISS et leurs solutions SIM SiteProtector (http ://www.iss.net/products services/enterprise protection/site protector/sec fusion module.php). – NetIQ et leur solution SIM SecurityManager (http ://www.netiq.com/products/sm/default.asp) – ExaProtect et leur solution EAS de management de la s´ecurit´e (http ://www.exaprotect.com/fr/eas1.jsp) jusqu’`a peu, bas´ee sur Prelude-ids une solution Open Source de grande qualit´e. La solution Open Source Prelude-ids (http ://prelude-ids.org), e´ tudi´ee et utilis´ee dans les deux premi`eres phases du projet SIMS, offre quant a` elle des fonctionnalit´es de d´etection (Snort et r´ecup´eration de

45

SIMS - Security Intrusion Management System

logs), centralisation et normalisation (IDMEF1 ) tr`es robustes. En effet, l’´equipe Prelude-ids a concentr´e ses efforts sur le rapatriement d’´ev´enements de s´ecurit´e avec la triade CIA (Confidentiality, Integrity, Availability) comme ligne directrice. Ce projet de grande qualit´e n’offre malheureusement encore aucune solution avanc´ee d’analyse des donn´ees, bien que l’int´egration d’un outil de corr´elation Open Source (SEC, abord´e dans le chapitre 7 du document http ://www.fullsecurity.ch/liens/sims-webJwinteregg.pdf) soit en cours.

1

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

46

Institut ICT, Jo¨el Winteregg (cc)

Annexe A

Installation et configuration d’Ossim-server Ce chapitre d´ecrit toutes les e´ tapes d’installation d’un serveur Ossim1 sur une plateforme GNU Linux/Debian. Celui-ci est tir´e de http ://www.ossim.net/docs/INSTALL.Debian.quick.html

A.1

Pr´erequis

Disposer d’une machine Linux Debian ayant un noyau 2.6.xx. Avoir configur´e le manager de paquets Debian (aptitude) afin qu’il r´ecup`ere ceux-ci sur le site Web d’Ossim (cf. Section B.1.1).

A.2

Installation

Installation de la base de donn´ee MySql-Ossim : # apt-get install ossim-mysql

Cr´eation du compte root et mise en place de son mot de passe : # mysqladmin -u root password your_secret_password

Vous pouvez ensuite e´ diter le fichier /etc/mysql/my.cnf afin de choisir l’adresse IP (bind-address) associ´ee au serveur MySql. La cr´eation des bases de donn´ees s’op`ere simplement a` l’aide des commandes suivantes : # mysql -u root -p 1

Serveur des gestion des sondes ET framework de gestion (= interface Web)

47

SIMS - Security Intrusion Management System

mysql> mysql> mysql> mysql>

create database ossim; create database ossim_acl; create database snort; 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 corr´elation et r´ecup´eration des donn´ees des agents) : # apt-get install ossim-server

Installation du framework (interface Web) ainsi que du paquetage de la gestion des droits d’acc`es au serveur Web : # apt-get install phpgacl # apt-get install ossim-framework

Installation du paquetage utils permettant la gestion des connexions a` la base de donn´ee Ossim : # apt-get install ossim-utils

Installation de Nessus (pour la d´etection des vuln´erabilit´es). Installation du serveur Nessus : # apt-get install nessusd

Il est aussi possible de directment t´el´echarger la derni`ere archive d’installation sur http ://www.nessus.org/download/. En effet cette derni`ere version de Nessus (v.2.2.5) offre la possibilit´e de mettre a` jour automatiquement les r`egles Nessus via un simple enregistrement sur http ://www.nessus.org/. Vous devrez ensuite simplement suivre les instructions donn´ees par le script d’installation. A l’aide de l’installation par d´efaut, la racine du serveur Nessus se trouvera alors dans /usr/local/. Ses fichiers de configuration dans /usr/local/etc/nessus et les logs dans /usr/local/var/nessus. Installation du client (utilis´e par le script /usr/share/ossim/script/do nessus.pl, ex´ecut´e par le framework lors d’une demande de scan) pour l’ex´ecution des scan nessus : # apt-get install nessus

48

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

A.3

Configuration

A.3.1

Ossim plate-forme

Tous les paquetages intall´es ci-dessus offrent une configuration garphique ncruses a` l’installation. Celleci peut eˆ tre effectu´ee a` la demande via la commande : # dpkg-reconfigure

L’adresse IP du serveur ainsi que les nom d’utilisateurs et mots de passes des bases de donn´ees seront n´ecessaire. Il convient donc ensuite de cr´eer ces utilisateurs. Si nous choissons de nous connecter aux bases de donn´ees a` l’aide d’un utilisateur nomm´e ossim ayant comme mot de pase ossim pass, il sera n´ecessaire d’op´erer ainsi afin d’ajouter cet uilisateur sur les diff´erentes bases de donn´ees : # 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’ -> IDENTIFIED BY ’ossim_pass’ WITH GRANT OPTION; mysql> GRANT ALL PRIVILEGES ON ossim_acl.* TO ’ossim’@’localhost’ -> IDENTIFIED BY ’ossim_pass’ WITH GRANT OPTION; mysql> FLUSH PRIVILEGES;

Ici, nous offrons tous les privil`eges a` l’utilisateur ossim sur les bases de donn´ees n´ecessaires (soit ossim, snort et ossim acl). Pour une configuration graphique, il suffira d’installer le paquetage suivant sur le serveur : # apt-get install phpmyadmin

A.3.2

Serveur Web

Celle-ci se situe dans /etc/apache/httpd.conf. Il est en premier lieu indispensable de charger le module de l’interpr´eteur PHP afin que le site d’Ossim puisse fonctionner. Ceci s’op`ere 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 import´e dans le fichier de configuration principal d’Apache. Le fichier de configuration d’Apache pour Acid2 n’est par contre pas directement fourni dans ce r´epertoire. Il est donc n´ecessaire de le copier afin qu’Apache soit capable de servir les pages web d’Acid : 2

Viewer pour les alertes Snort et Ossim

49

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

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

Il est ensuite n´ecessaire de modifier la configuration par d´efaut d’Apache pour Ossim, afin que celui-ci soit capable de suivre les liens symboliques. En effet, un lien symbolique est utilis´e pour l’affichage des vuln´erabilit´es d´ecouvertes 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 d´ej`a d´efinies) : Options FollowSymLinks

A.3.3

Nessus client-serveur

Il est n´ecessaire d’ajouter un user au serveur Nessus afin le framework (script do nessus.pl) puisse l’utiliser pour ex´ecuter des scans. Ceci s’op`ere sur le serveur a` l’aide de la commande nessus-adduser. Il suffira ensuite de compl´eter les informations requises comme illustr´e ci-dessous : # nessus-adduser Using /var/tmp as a temporary file holder Add a new nessusd user ---------------------Login : Authentication (pass/cert) [pass] : Login password : Login password (again) :

Il faudra maintenant configurer correctement les champs nessus user et nessus pass du sous-menu Main du menu de Configuration du framework afin que les scripts utilisants Nessus soient capables de se connecter au serveur Nessus. Le champ nessus user devra contenir yourUserLogin entr´e ci-dessus et nessus pass devra contenir yourUserPass. Il est maintenant possible de mettre a` jour les r`egles de tests (contenues dans Nessus) sur le framework. Le script update nessus ids.pl s’occupe de c¸a (via l’utilisation du client Nessus et des informations configur´ees ci-dessus) : # /usr/share/ossim/scripts/update_nessus_ids.pl

A.3.4

Cross corr´elation via Nessus

Pour que l’ajustement des priorit´es des alertes en fonction des vuln´erabilit´e de la machine cible (vuln´erabilit´es d´etect´ees par Nessus) soit possible, il est n´ecessaire de mettre a` jour les relations entre les alertes Snort et les r`egles NASL3 Nessus (relations enregistr´ees dans la table plugin reference de Mysql). Ces relations sont contenues dans l’archive snort nessus.sql.gz qu’il faut fournir au client mysql afin que celui-ci mette a` jour la base de donn´ee d’Ossim : 3

Nessus Attack Scripting Language, language permettant d’´etablir des r`egles de test Nessus

50

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

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

51

Institut ICT, Jo¨el Winteregg (cc)

Annexe B

Ajout et configuration d’une sonde Snort Les manipulations d´ecrites ci-dessous requi`erent un serveur Ossim op´erationnel (installation d´ecrite dans la section A).

B.1

Installation

B.1.1

Snort

Son installation sur une distribution Debian (via apt-get) implique l’ajout d’une source de download afin de r´ecup´erer l’application Snort directement patch´ee. Il est n´ecessaire d’ajouter la ligne suivant dans /etc/apt/source.list afin que le gestionnaire de paquets de Debian (aptitude) soit capable de r´ecup´erer les paquetages d’Ossim : deb http://www.ossim.net/download/ debian/

Il est ensuite n´ecessaire de cr´eer un fichier de pr´ef´erences /etc/apt/preferences afin que Debian aille en premier lieu rechercher les paquetages disponibles sur Ossim plutˆot que ceux disponibles sur d’autres serveurs. Nous serons ainsi certain d’obtenir la version patch´ee de Snort : Package: * Pin: release o=ossim Pin-Priority: 995

Apr`es 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

SIMS - Security Intrusion Management System

B.1.2

Ossim-agent

Maintenant qu’aptitude est capable de r´ecup´erer des paquets sur les serveurs d’OSSIM, il suffit de taper la commande suivante afin d’installer Ossim-agent : # apt-get install ossim-agent

L’installeur de paquets de Debian va maintenant vous questionner afin de cr´eer une configuration de base. Reportez-vous a` la section suivante (section B.2.2) pour plus de d´etails.

B.2

Configuration

B.2.1

Snort

Comme mentionn´e plus haut, le logiciel de d´etection d’intrusion Snort utilise son plugin de sortie Mysql afin de transmettre directement ses alertes en direction d’une des bases de donn´ees d’Ossim-server (Snort BD). Celui-ci disposera alors de tous les d´etails de chaque alertes lev´ee par la sonde. Le second plugin de sortie utilis´e est ”logfile=fast.log”. Il s’agˆıt d’un plugin d´evelopp´e par OSSIM tr`es proche de ”alert full”1 directement int´egr´e a` Snort. Fast.log place simplement les diff´erentes alertes dans un fichier de logs qui sera ensuite lu par l’agent Ossim qui s’occupera de transmettre ces informations vers le serveur Ossim (permettant ainsi l’analyse temps r´eel). 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 donn´ee Snort distante. Il est donc n´ecessaire de cr´eer un nouvel utilisateur sur celle-ci afin que la sonde puisse s’y connecter a` l’aide du mot de passe indiqu´e. L’ajout d’un utilisateur sur la base de donn´ee Snort sera d´etaill´e ci-dessous (section B.3). De plus, il est indispensable de retirer le script de d´emarrage automatique de Snort afin que la sonde puisse eˆ tre directement activ´ee par le Serveur (via Ossim-agent). Ceci s’op`ere a` l’aide de la commande suivante : # update-rc.d -f snort remove

Mise a` jour des r`egles sur le serveur Ossim La mise a` jour des r`egles Snort permet l’utilisation de celles-ci dans les sc´enarii de corr´elation. En effet, le menu de ”Correlation - Directives” du framework permet l’utilisation des alertes Snort dans 1

fast.log ajout simplement deux param`etres suppl´ementaire a` alert full afin d’augmenter les performances du serveur. Info sur : https ://sourceforge.net/forum/message.php ?msg id=2627915

53

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

la d´efinition de sc´enarii de corr´elation. L’utilisation du SID des alarmes permet de les r´ef´erencer dans les r`egles de corr´elation. Celui-ci doit donc eˆ tre unique pour chaque plugin. Il convient donc lors de cr´eation de r`egles Snort de ne pas les dupliquer (un contrˆole est quand mˆeme effectu´e par le script /usr/share/ossim/scripts/create sidmap.pl de mise a` jour des r`egles dans la base de donn´ee du serveur Ossim). La mise a` jour des r`egles sur le serveur Ossim requiert le client Mysql puisque le script proc`ede au contrˆole de la duplication des r`egles et fournit les commandes SQL a` entrer dans le client. Ce script doit e´ videmment eˆ tre ex´ecut´e sur l’agent h´ebergeant 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 configur´e pour un connexion vers la base de donn´ee du serveur Ossim (`a e´ crire sur une ligne) : # /usr/share/ossim/scripts/create_sidmap.pl /etc/snort/rules | mysql --host= -u ossim ossim -p

Le user ossim utilis´e pour la connexion du client mysql doit b´en´eficier des droits suffisants pour la commande Sql INSERT. Pour que l’insertion se passe correctement (avec l’enregistremenent du champ msg des r`egles Snort dans la base de donn´ee Ossim), il est n´ecessaire que le champ classtype soit pr´esent dans la r`egle Snort.

Effacer des r`egles de plugins dans Ossim Pour se faire, il est n´ecessaire de directement ”taper” dans la base de donn´ee d’Ossim. Il sera alors n´ecessaire d’utiliser un client Mysql (mysql-client ou phpMyAdmin). Via mysql-client, il suffira de se connecter a` la base de donn´ee a` l’aide d’un user ayant les droits Delete, et de taper la requˆete suivante (avec le bon id et sid) : mysql> DELETE FROM plugin_sid WHERE plugin_id= and sid=;

B.2.2

Ossim-agent

Sa configuration s’effecture directement a` l’aide du menu de configuration des paquets Debian et peut eˆ tre reconfigur´e a` volont´e 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 r´eseau a` utiliser (pour la communication avec le serveur) 3. L’adresse IP du serveur OSSIM 4. Les plugins qui vont eˆ tre connect´e a` cet agent. Dans notre cas, uniquement Snort (illustr´e a` la figure B.1) L’ex´ecutable de l’agent Ossim est ensuite directement li´e dans les runlevels appropri´es afin qu’un d´emarrage automatique s’effectue a` chaque boot de la machine.

54

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

F IG . B.1 – Interface de configuration (dpkg) des plugins a` utiliser sur un agent Ossim

B.3

Configuration d’Ossim-server pour une nouvelle sonde Snort

La proc´edure d’ajout d’un nouveau sensor doit eˆ tre effectu´e via l’interface Web du serveur Ossim. Celleci est d´ecrite dans le manuel disponnible a` l’URL suivante : http ://www.ossim.net/docs/User-Manual.pdf Lors de l’ajout d’un sensor local (agent plac´e sur le serveur Ossim), il faudra bien prendre garde de sp´ecifier correctement l’adresse du serveur Ossim dans la configuration de l’agent (/etc/ossim/agent/config.xml). En effet, pour une bonne g´en´eration des liens HTML du framework, il sera n´ecessaire de ne pas sp´ecifier l’adresse de loopback du serveur comme serverip. Adr_ip_non_loopback

L’ajout d’une nouvelle sonde Snort implique l’ajout de droit d’acc`es dans la base de donn´ee snort afin que cette nouvelle sonde (=nouvel utilisateur) soit capable d’y d´eposer directement ses alertes (comme illustr´e sur la figure 3.1). Il est donc n´ecessaire de se trouver sur la machine serveur afin d’y entrer les requˆetes SQL pour l’ajout d’un utilisateur. Lancement du client Mysql local et utilisation de la base de donn´ee snort : # mysql -u root mysql> use snort;

Requˆetes 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’;

55

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

L’utilisateur snort provenant de sensorIP a maintenant un acc`es total a` la base de donn´ee snort du serveur. Son mot de passe (`a indiquer dans la configuration de Snort, section B.2.1) est maintenant passwordDeSnort.

B.4

Test de fonctionnement

Maintenant que l’agent Ossim est configur´e et que la base de donn´ee snort est accessible depuis celui-ci, nous pouvons tester le fonctionnement de l’agent (le serveur doit eˆ tre en marche). Il est maintenant possible de d´emarrer l’agent Ossim (en mode de debug afin de contrˆoler son bon fonctionnement) 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:05): plugin-start plugin_id="1001"

Vous pouvez maintenant ex´ecuter l’agent Ossim en tˆache de fond : # ossim-agent -d

Votre nouvelle sonde Snort est prˆete a` l’emploi !

B.4.1

Erreur de d´emarrage 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 r´ecup`ere l’agent (pour l’envoi temps r´eel des informations au serveur), n’a pas e´ t´e trouv´e. Il est alors n´ecessaire de modifier la configuration du plugin

56

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

Snort afin d’y indiquer le bon chemin (le bon fichier de log). Celle-ci est d´ecrite dans le fichier XML /etc/ossim/agent/plugins/snort.xml. Il est indispensable de modifier la balise location afin d’y indiquer l’emplacement r´eel du fichier de log de Snort (g´en´er´e par le plugin fast.log de Snort), comme illustr´e ci-dessous :

.......... balises de configuration ........... /var/log/snort/fast.log

57

Institut ICT, Jo¨el Winteregg (cc)

Annexe C

Ajout et configuration de Ntop Les manipulations d´ecrites ci-dessous requi`erent un serveur Ossim op´erationnel, ainsi qu’un agent Ossim install´e sur la machine qui h´ebergera Ntop (l’installation de l’agent est d´ecrite dans la section B.1.2 puisqu’il s’agˆıt, dans notre cas, du mˆeme agent que pour la sonde Snort).

C.1

Installation

C.1.1

Ntop

Installation de Ntop et des librairies n´ecessaires : # 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 n´ecessaire pour l’interrogation de la base de donn´ee Ossim par rrd plugin.pl (permettant la r´ecup´eration de la configuration des seuils d´efini par l’administrateur r´eseau sur le framework) : # apt-get install ossim-utils

Pour les d´etails de la configuration de ce paquetage consultez la section C.2.2. Installation des outils utilis´es par le script rrd plugin.pl pour la r´ecup´eration des informations dans la base de donn´ee RRD : # apt-get install rrdtool librrd0-dev librrdp-perl librrds-perl python-mysqldb

58

SIMS - Security Intrusion Management System

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 mentionn´e dans la section 3.3.1, Ntop dispose d’une interface Web pour le monitoring ainsi que pour sa configuration. Le serveur Web s’installe par d´efaut sur le port 3000. Il est maintenant n´ecessaire de configurer le format des logs de sortie (plugin RRD) afin que le script rrd plugin.pl soit capable de les r´ecup´erer via l’outil RRDtool. Pour ce faire il suffit de se rendre a` l’URL suivante : http ://yourhost :3000/ et d’activer le rrdPlugin dans Admin - plugins. En cliquant sur rrdPlugin le menu de configuration de celui-ci devient e´ ditable. Vous pouvez maintenant cliquer sur Host dans le menu Data to Dump puis entrer votre masque de sous-r´eseau dans Hosts Filter. Il est encore n´ecessaire de contrˆoler que le RRD Files Path soit le mˆeme que celui fournit dans le framework de configuration (Configuration - Main rrdpath ntop). En effet le script Perl rrd plugin.pl r´ecup`ere la configuration des seuils sur le framework, ainsi que les chemins d’acc`es aux fichiers de logs. Il est ensuite n´ecessaire de modifier le fichier /etc/default/ntop afin d’y mettre –no-mac comme GETOPT : GETOPT="--no-mac"

Le script d’analye et de comparaison des seuils (rrd plugin) sera maintenant capable de r´ecup´erer les donn´ees de la base de donn´ee tourniquet afin de les analyser.

C.2.2

L’agent Ossim

Ossim-utils Ce paquetage contenant le script rrd plugin.pl met a` disposition le module perl /usr/lib/perl5/config.pm permettant de r´ecup´erer la configuration e´ tablie dans le framework (configuration e´ tablie dans Configuration - Main). Il est n´ecessaire de configurer correctement ce paquetage afin que ce module soit capable de se connecter a` la base de donn´ee distante. Il faudra lui indiquer un utilisateur Mysql, capable de se connecter depuis l’agent Ossim. Dans notre cas, nous indiquerons l’utilisateur snort pr´ec´edemment confi´ ee a` la main (/etc/ossim/framework/ossim.conf) cette configuration ressemble gur´e (cf. section B.3). Edit´ a` ceci : ################ # OSSIM db configuration ################

59

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

ossim_type=mysql ossim_base=ossim ossim_user=snort ossim_pass=E1ephant ossim_host=10.192.72.172 ossim_port=3306

Celle-ci peut aussi eˆ tre ais´ement e´ dit´ee a` l’aide de dpkg via la commande suivante : # dpkg-reconfigure ossim-utils

Ossim-agent Le script rrd plugin.pl r´ecup`ere de lui mˆeme (sans appel a` config.pm) les informations relatives a` la configuration des seuils dans la base de donn´ee Ossim distante. Il est donc n´ecessaire de lui indiquer correctement les mˆemes 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 utilis´ees par certains plugins (dont le plugin RRD). La d´efinition de l’ENTITY suivant avec les bon param`etres de connexion est n´ecessaire :

´ Il faut ensuite reconfiguer l’agent Ossim afin de pr´eciser que Ntop est activ´e sur cet agent. Etant donn´e que rrd plugin.pl est utilis´e pour l’analyse des donn´ees, il est n´ecessaire d’indiquer que le plugin RRD est aussi en fonction. La figure C.1 illustre cette nouvelle configuration ex´ecut´ee a` l’aide de la commande suivante : # dpkg-reconfigure ossim-agent

F IG . C.1 – Interface de configuration (dpkg) des plugins a` activer sur l’agent Ossim

60

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

C.3

Configuration d’Ossim-server pour une nouvelle sonde Ntop

Si l’ajout de cette sonde a e´ t´e effectu´ee sur un sensor existant (comme dans notre cas), il ne sera pas n´ecessaire d’enregistrer un nouvel agent sur l’interface Web du serveur. L’agent existant transmettra de lui mˆeme l’existance d’une nouvelle sonde au serveur. Dans le cas contraire (mise en place de cette sonde sur un nouvel agent), il sera n´ecessaire de proc´eder a` l’enregistrement du nouvel agent, comme expliqu´e dans le manuel disponnible a` l’URL suivante : http ://www.ossim.net/docs/User-Manual.pdf Il est aussi indispensable d’ajouter les droits suffisants a` l’utilisateur utilis´e lors de la connexion a` la base de donn´ee, afin que celui-ci soit capable de r´ecup´erer la configuration sur le serveur : # mysql -u root mysql> use ossim;

Requˆetes SQL a` entrer pour l’ajout d’un nouvel utilisateur et pour la mise en place de son mot de passe : mysql> GRANT ALL ON ossim.* TO snort@sensorIP; mysql> UPDATE user SET Password = PASSWORD(’passwordDeSnort@sensorIP’) -> WHERE Host = ’sensorIP’ AND User = ’snort’;

Ceci peut aussi eˆ tre effectu´e via phpMyAdmin.

61

Institut ICT, Jo¨el Winteregg (cc)

Annexe D

Ajout et configuration de P0f Les manipulations d´ecrites ci-dessous requi`erent un serveur Ossim op´erationnel (installation d´ecrite dans la section A), ainsi qu’un agent Ossim install´e sur la machine qui h´ebergera P0f (l’installation de l’agent est d´ecrite dans la section B.1.2 puisqu’il s’agˆıt, dans notre cas, du mˆeme agent que pour la sonde Snort).

D.1

Installation

Son installation n´ecessite uniquement l’installation du paquetage P0f : # apt-get install p0f

D.2

Configuration

D.2.1

P0f

P0f ne n´ecessite aucune configuration suppl´ementaire puisque le chemin de son fichier de log lui est fourni par l’agent Ossim lors de son ex´ecution.

D.2.2

L’agent Ossim

Il est n´ecessaire de reconfiguer l’agent Ossim afin de pr´eciser que P0f est activ´e sur cet agent. Celle-ci s’op`ere a` l’aide de la commande suivante : # dpkg-reconfigure ossim-agent

62

Annexe E

Ajout et configuration de TCPTrack Les manipulations d´ecrites ci-dessous requi`erent un serveur Ossim op´erationnel (installation d´ecrite dans la section A), ainsi qu’un agent Ossim install´e sur la machine qui h´ebergera TCPTrack (l’installation de l’agent est d´ecrite dans la section B.1.2 puisqu’il s’agˆıt, dans notre cas, du mˆeme agent que pour la sonde Snort).

E.1

Installation

Celle-ci est vraiment tr`es simple puisqu’il suffira de r´ecup´erer le paquetage Debian de TCPTrack sur le serveur Web d’Ossim1 via la commande suivante : # apt-get install tcptrack

E.2

Configuration

Aucune configuration sp´ecifique n’est n´ecessaire pour TCPTrack puisque c’est le serveur Ossim qui s’occupera d’interoger TCPTrack. Il sera par contre indispensable d’indiquer a` l’agent qu’une nouvelle sonde lui a e´ t´e ajout´ee. Ceci s’op`erera via le menu de configuration offert par la commande suivante : # dpkg-reconfigure ossim-agent

1

Il est donc indispensable d’avoir configur´e aptitude afin qu’il r´ecup`ere directement les paquetages chez Ossim (cf. Section B.1.1). En effet, la version de TCPTrack utilis´ee dans l’architecture d’Ossim est une version modifi´ee de la version originale.

63

Annexe F

Ajout et configuration d’une sonde HIDS Syslog Les manipulations d´ecrites ci-dessous requi`erent un serveur Ossim op´erationnel (installation d´ecrite dans la section A), ainsi qu’un agent Ossim install´e sur la machine qui h´ebergera cette sonde HIDS Syslog (l’installation de l’agent est d´ecrite dans la section B.1.2 puisqu’il s’agˆıt, dans notre cas, du mˆeme agent que pour la sonde Snort).

F.1

Installation

Aucune installation n’est requise puisque le parser de fichiers de log Syslog et directement pr´esent sur tous les agents (fichier /usr/share/ossim-agent/pyossim/ParserSyslog.py).

F.2

Configuration

Il suffira d’activer le plugin voulu afin que celui-ci soit automatiquement ex´ecut´e par l’agent. Pour ce faire, il vous suffira de l’activer a` l’aide du menu de configuration offert par la commande suivante : # dpkg-reconfigure ossim-agent

La configuration du fichier a` contrˆoler peut eˆ tre directement faite en modifiant la balise location du fichier /etc/ossim/agent/plugins/syslog.xml. Par d´efaut celui-ci est /var/log/auth.log. Sous Debian il sera en plus n´ecessaire de modifier (dans le mˆeme fichier de configuration) le nom du daemon de logging puisque celui-ci se nomme sysklogd et non pas syslog. L’ajout de nouvelles r`egles n´ecessitera malheureusement la modification du code du parseur /usr/share/ossimagent/pyossim/ParserSyslog.py puisque celles-ci s’y trouvent directement int´egr´ees. Aucun fichier de configuration des r`egles n’est pour le moment disponnible.

64

Annexe G

Ajout et configuration d’une sonde HIDS IIS Les manipulations d´ecrites ci-dessous requi`erent un serveur Ossim op´erationnel (installation d´ecrite dans la section A), ainsi qu’un agent Ossim install´e sur la machine qui h´ebergera cette sonde HIDS IIS1 (l’installation de l’agent est d´ecrite dans la section B.1.2 puisqu’il s’agˆıt, dans notre cas, du mˆeme agent que pour la sonde Snort).

G.1

Installation du plugin

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

G.2

Installation de Snare IIS (rapatriement des logs vers un serveur Syslog)

Du cˆot´e du serveur web, il est n´ecessaire d’installer un logiciel client capable d’´emettre les logs vers un serveur de logs Linux. Vous pouvez donc t´el´echarger librement le logiciel Open Source Snare disponible a` l’adresse suivante : http ://www.intersectalliance.com/projects/SnareIIS/index.html#Download Son installation est ensuite extrˆement simple. Il vous suffira de suivre les quelques instructions a` l’´ecran... 1

Internet Information Services, serveur Web de Microsoft

65

SIMS - Security Intrusion Management System

G.3

Configuration

G.3.1

Configuration de l’agent OSSIM

Il suffira d’activer le plugin voulu afin que celui-ci soit automatiquement ex´ecut´e par l’agent. Pour ce faire, vous devrez l’activer a` l’aide du menu de configuration offert par la commande suivante : # dpkg-reconfigure ossim-agent

La configuration du fichier de log a` contrˆoler peut eˆ tre directement faite en modifiant la balise location du fichier /etc/ossim/agent/plugins/iis.xml. Par d´efaut celui-ci est /var/log/syslog. Sous Debian il sera en plus n´ecessaire de modifier (dans le mˆeme fichier de configuration) le nom du daemon de logging puisque celui-ci se nomme sysklogd et non pas syslog. L’ajout de nouvelles r`egles n´ecessitera malheureusement la modification du code du parseur /usr/share/ossimagent/pyossim/ParserIIS.py puisque celles-ci s’y trouvent directement int´egr´ees. Aucun fichier de configuration des r`egles n’est pour le moment disponible. Configuration du serveur Syslog Linux (pr´esent sur l’agent OSSIM) Syslogd est le daemon s’occupant de la r´ecup´eration de logs d’une machine Linux. Par d´efaut celui-ci travaille uniquement en local. Lors de son lancement (commande syslogd), via l’argument ”-r”, il est possible de lui indiquer d’ouvrir le port 514 UDP pour la r´ecup´eration de logs distants. Nous modifions donc son script de lancement ”sysklogd” plac´e dans /etc/ini.d/. Il suffira donc d’ajouter le ”-r” dans la variable SYSLOGD d´ej`a pr´esente dans ce fichier, comme illustr´e 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 pr´eciser que le protocole de transfert de logs bas´e sur UDP n’est pas s´ecuris´e. Les trames circulent ”en clair” sur le r´eseau. De plus l’utilisation d’UDP implique une e´ ventuelle possibilit´e de perte des paquets sans qu’aucun des deux partenaires ne s’en rende compte (principe mˆeme d’UDP).

G.3.2

Configuration du serveur IIS (client Snare IIS)

La figure G.1 illustre la configuration du client Snare effectu´ee, afin que la station 192.168.1.2 rec¸oive les logs contenu dans le fichier C :\WINNT\System32\LogFiles du serveur IIS. L’utilisation de Snare implique une configuration rigoureuse du format des logs d’IIS. En effet, il est indispensable de configurer une rotation des logs journali`ere ainsi qu’un format e´ tendu (W3C extended

66

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

F IG . G.1 – Configuration de l’utilitaire de r´ecup´eration des logs d’IIS Log File Format) afin que Snare soit capable de les lire. Cette configuration est accessible dans le menu de configuration de IIS, dans l’onglet Web Site. En cliquant sur le bouton Properties..., il sera possible de d´efinir la p´eriode de rotation des logs ainsi que leur format. De plus, le parser IIS d’OSSIM (/etc/ossim/agent/plugins/iis.xml) n´ecessite un format de log tr`es pr´ecis afin d’ˆetre capable de les interpr´eter. Il sera donc n´ecessaire de configurer les logs d’IIS afin que les informations suivantes soient pr´esentent : – Heure – Date – Client IP – Server IP – Server port – Method – URI stream – URI query – Protocol Status

67

Institut ICT, Jo¨el Winteregg (cc)

Annexe H

Ajout et configuration de PADS Les manipulations d´ecrites ci-dessous requi`erent un serveur Ossim op´erationnel (installation d´ecrite dans la section A), ainsi qu’un agent Ossim install´e sur la machine qui h´ebergera PADS (l’installation de l’agent est d´ecrite dans la section B.1.2 puisqu’il s’agˆıt, dans notre cas, du mˆeme agent que pour la sonde Snort).

H.1

Installation

Celle-ci est vraiment tr`es simple puisqu’il suffira de r´ecup´erer le paquetage Debian de PADS, via la commande suivante : # apt-get install pads

H.2

Configuration

Aucune configuration sp´ecifique n’est n´ecessaire pour PADS puisque le chemin de ses logs de sortie est directement fourni par l’agent Ossim (param`etre lors de son ex´ecution). Il sera par contre indispensable d’indiquer a` l’agent qu’une nouvelle sonde lui a e´ t´e ajout´ee. Ceci s’op`erera via le menu de configuration offert par la commande suivante : # dpkg-reconfigure ossim-agent

68

Annexe I

Cr´eation de r`egles de corr´elation I.1

Introduction

Cette annexe vous apprendra a` cr´eer vos propres directives de corr´elation. La structure et syntaxe de celles-ci est d´ecrite dans ce chapitre.

I.2

Ajout d’un fichier de r`egles sur le serveur

Pour ce faire, il suffit de cr´eer un nouveau fichier de r`egles sur le serveur et de le placer dans le r´epertoire /etc/ossim/server/. Si celui-ci se nomme mesRegles.xml, il sera indispensable d’indiquer au serveur de charger ce fichier afin que les r`egles pr´esentent dans celui-ci soient utilis´ees. Pour se faire, il vous suffit d’´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 ....

]>

... inclusion des r` egles existantes ` a l’affichage ... &myRules; ..... suite de la config ....

Chaque r`egle sera ensuite automatiquement tri´ee lors de son affichage dans le framework. Lors de la cr´eation de r`egles, iI sera indispensable de respecter la num´erotation de l’attribut id des balises direc-

69

SIMS - Security Intrusion Management System

tives mentionn´e dans Directive numbering du sous-menu Directives du framework. De cette mani`ere, les nouvelles r`egles seront directement affich´ees dans la cat´egorie voulue.

I.3

Syntaxe XML

Cette section est partiellement tir´ee du document de S´ebastien Contreras et des exemples fourni aux URLs suivantes : http ://www.ossim.net/docs/correlation engine explained rpc dcom example.pdf http ://www.ossim.net/docs/correlation engine explained worm example.pdf Nous allons, en premier lieu, reprendre la d´efinition des diff´erentes balises utilisables dans les r`egles de corr´elation :

I.3.1

Balise directive

Cette balise englobe la directive de corr´elation enti`ere. Elle permettra de d´efinir les param`etres globaux de celle-ci. Ceux-ci sont : – l’id de la directive de corr´elation, attribut id – le nom de celle-ci affich´e dans le framework, attribut name – la priorit´e de la r`egle, attribut priority

I.3.2

Balise rule

Cette balise permet la d´efinition d’une r`egle utilis´ee dans le processus de corr´elation de la directive. Il sera possible d’en d´efinir ses caract´eristiques a` l’aide des attributs suivants : – Le type de la r`egle, attribut type – Le nom de celle-ci, attribut name – La provenance de l’alerte que nous attendons, attribut plugin id – Le num´ero d’´ev´enement1 de l’alerte du plugin que nous attendons, attribut plugin sid – Le param`etre de fiabitit´e (reliability) entrant dans le calcul du risque, attribut reliability – La fenˆetre temporelle dans laquelle la r`egle doit eˆ tre match´ee, attribut time out – Le nombre de fois que doit eˆ tre match´e la r`egle afin de passer a` la suivante, attribut occurence – Le type de protocole sur lequel s’applique la r`egle, attribut protocol – L’adresse IP source de la trame match´ee par la r`egle, attribut from – L’adresse IP de destination de la trame match´ee par la r`egle, attribut to 1

R´ef´erence chaque plugin offerte par le sous menu Plugins du menu Configuration

70

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

– Le port source de la trame match´ee par la r`egle, attribut port from – Le port de destination de la trame match´ee par la r`egle, attribut port to – La condition a appliquer si le contrˆole d’une quantit´e v´ehicul´ee par l’alerte est n´ecessaire, attribut condition – La valeur a` comparer (`a l’aide de la condition d´efinie par l’attribut pr´ec´edent) a` la quantit´e v´ehicul´ee par l’alerte, attribut value – Valeur permettant de d´efinir si la valeur a` comparer (value) est absolue ou relative, attribut absolute – L’interval dans lequel la r`egle doit s’appliquer (´equivalent au time out mais utilis´e pour les r`egles monitor), attribut interval – Param`etre permettant de geler les param`etres non d´efini2 dans la directive (utilis´e lorsque l’occurence d’une r`egle est sup´erieur a` 1), attribut sticky – Param`etre permettant de forcer un attribut a` eˆ tre diff´erent lorsque plusieurs occurence de la r`egle sont attendues, attribut sticky different Lorsqu’une r`egle (rule) est match´ee, cela a pour effet de d´eclencher le passage a` la r`egle suivante contenue dans la directive. Il s’agit donc d’un ET entre les r`egles impriqu´ees dans rule.

I.3.3

Balise rules

Cette balise permet l’encapsualtion d’une ou plusieurs r`egles (balise rule). Si plusieur r`egles rule sont pr´esentes au mˆeme niveau (sans imbrications) a` l’int´ereur de la balise rules, un OU est op´er´e entre celles-ci (exemple : la 1`ere r`egle ou la deuxi`eme r`egle ou la 3 e` me r`egle... ). Cette balise ne contient aucun attribut.

I.3.4

Syntaxe des attributs de caract´eristiques

Nous allons maintenant reprendre la d´efinition des attributs utilisables (param`etres) dans les diff´erentes balises XML. balise directive id Cet attribut permet la d´efinition de l’identifiant unique de la directive de corr´elation. Cette num´erotation doit suivre les directives e´ mises par Ossim afin que le tri d’affichage effectu´e dans le framework (sousmenu directives du menu correlation) soit effectu´e correctement. Les directives de num´erotation sont disponible dans ce sous-menu. name Cet attribut permet la d´efinition du nom de la directive (affich´e lorsque la directive est match´ee). 2

param`etres non utilis´e dans la directive

71

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

priority Cet attribut permet de d´efinir la priorit´e de la directive de corr´elation. Pour plus d’informations sur la signification de la priorit´e d’un e´ v´enement, conslutez la section 4.3. balise rule Type Cet attribut d´efinit le type de la r`egle. Il existe uniquement deux type de r`egles : Detector r`egles utilisant les informations de d´etecteurs (snort, spade, syslog, ...) contenue dans la base de donn´ee du serveur. Monitor r`egles utilisant les information des moniteurs (TcpTrack, Ntop, etc...). Dans ce cas, c’est le serveur qui aura la tˆache d’interroger le moniteur (agent) afin d’obtenir les informations voulues. name Cet attribut permet de d´efinir le nom de chaque r`egle. Celui-ci sera ensuite affich´e dans le sousmenu backlog du menu correlation, permettant la visualisation des r`egles match´ees par alertes de haut niveau (groupe d’alertes). plugin id Cet attribut d´efinit la provenance de l’alerte attendue par la r`egle. En effet, chaque plugin a un identifiant associ´e (identifiant affich´e dans le sous-menu plugins du menu configuration) permettant de le r´ef´erencer dans les r`egles de corr´elation. plugin sid Cet attribut d´efinit l’´ev´enement associ´e au plugin (plugin id). En effet, tous les e´ v´enement r´ecup´er´e par Ossim sont r´epertori´e (en fonction de leur plugin) et configur´e3 . La configuration des plugin sid est accessible en cliquant sur le plugin id voulu dans le sous-menu plugins du menu configuration. Par exemple, l’alerte fournie par le plugin id 1501 et le plugin sid 400 e´ quivaut a` : ”apache : Bad Request”. A l’aide de ces deux attributs (plugin id et plugin sid), il est possible de d´efinir pr´ecis´ement l’´ev´enement attendu par la r`egle. reliability L’utilit´e de cet attribut est expliqu´e dans la section 4.3. Plus ce param`etre est grand (proche de 10), plus il indique que l’alerte n’est pas un faut positif. Ce param`etre prend alors une grand importance dans le proc´ed´e de corr´elation. En effet, au fur et a` mesure que des r`egles sont match´ees, la probabilit´e que ce groupe d’alerte (alerte de haut niveau) est un faux positif diminue... Il est alors possible, dans chaque balise rule, de modifier la fiabilit´e de l’alerte de haut niveau. La premi`ere r`egle (rule) indique la reliabilit´e de d´epart de l’alerte de haut niveau. Les r`egles suivantes ont ensuite la possibilit´e de faire e´ voluer cette valeur de mani`ere relative (par exemple : +3, signifiant que la reliabilit´e globale augmente de 3 par rapport a` la r`egle pr´ec´edente) ou absolue (par exemple : 7, signifiant que maintenant la reliabilit´e vaut 7). 3

Afin de leur assigner un niveau de priorit´e et de reliability (termes expliqu´es dans la section 4.3)

72

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

time out Cet attribut permet d’indiquer le temps d’attente de l’´ev´enement correspondant a` la r`egle. Si celui-ci n’arrive pas dans le temps imparti (configur´e en secondes a` l’aide de cet attribut), la directive de corr´elation se termine et retourne le r´esultat ”calcul´e” des r`egles pr´ec´edentes. Cet attribut permet de pr´eciser la fenˆetre temporelle dans laquelle l’alerte (´ev´enement) attendue par la r`egle doit apparaˆıtre. occurence Cet attribut permet de cr´eer une unique r`egle lorsque plusieurs occurence d’un mˆeme e´ v´enement est attendu. Il est ainsi possible de d´efinir le nombre d’´ev´enements identique a` attendre avant de passer a` la r`egle suivante. protocol Cet attribut permet de configurer le type d’´ev´enements r´eseau attendu par la r`egle. Il est possible d’en d´efinir trois types : 1. TCP 2. UDP 3. ICMP Cet attribut permet le r´ef´erencement absolu. Cela signifie qu’il est possible de reprendre le type de protocole match´e par des r`egles pr´ec´edentes. Pour ce faire, il suffira par exemple d’indiquer : protocol=”1 :PROTOCOL” afin de pr´eciser que le protocole de cette r`egle est identique au protocole match´e par la r`egle de premier niveau (premi`ere r`egle). Si l’on d´esire r´ecup´erer le protocole match´e par la r`egle du deuxi`eme niveau, il suffira de pr´eciser protocol=”2 :PROTOCOL”. Cet attribut devra uniquement eˆ tre utilis´e lorsque l’´ev´enement attendu par la r`egle fait partie de l’un des trois type de protocole disponible. from Cet attribut permet de pr´eciser l’adresse IP source de l’alerte attendue. Il est possible de la mentionner de six diff´erentes mani`eres : 1. ANY, indique que n’importe quelle adresse source sera match´ee par cet attribut 2. x.x.x.x, adresse IP standard 3. Par r´ef´erencement, fonctionnant sur le mˆeme principe que le r´ef´erencement de l’attribut protocole (exemple : 1 :SRC IP = adresse IP source de l’alerte match´ee par le premier niveau de la directive de corr´elation, 2 :DST IP = adresse IP de destinaion de l’alerte match´ee par le deuxi`eme niveau de la directive de corr´elation) 4. Par nom du r´eseau, il est possible d’utiliser une plage d’adresse IP en utilisant les nom de r´eseaux d´efini a` l’aide du framework (sous-menu network du menu policy). La variable HOME NET d´efinit quant a` elle tous les r´eseaux d´efini dans le framework. 5. Plusieurs adresses, cette syntaxe permet de pr´eciser plusieurs adresses IP s´epar´ees par des virgules 6. N´egations, cette syntaxe permet l’utilisation de n´egations sur des adresses IP ou des nom de r´eseaux (exemple : !192.168.2.203,HOME NET)

73

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

Note sur la premi`ere syntaxe (ANY) : Il est e´ vident qu’au niveau de la r`egle utilisant cette syntaxe cela revient au mˆeme que de ne pas utiliser cet attribut. Cette syntaxe permettra, par contre, le r´ef´erencement (`a l’aide de la troisi`eme syntaxe) de l’adresse IP de cette alerte dans les r`egles suivantes. Cet attribut ne devra pas eˆ tre utilis´e lorsque l’information attendue par la r`egle n’est pas une trame IP. to Cet attribut permet de pr´eciser l’adresse IP de destination de l’´ev´enement attendu par la r`egle. Sa syntaxe est totalement identique a` celle de l’attribut from. Cet attribut ne devra pas eˆ tre utilis´e lorsque l’information attendue par la r`egle n’est pas une trame IP. port from Cet attribut permet de pr´eciser le port source du segment TCP ou datagramme UDP attendu par la r`egle. Celui-ci peut eˆ tre d´ecrit par : – Une liste de ports s´epar´e par des virgules – ANY – Un r´ef´erencement absolu a` l’aide des variables SRC PORT et DST PORT Cet attribut ne devra pas eˆ tre utilis´e lorsque l’information attendue par la r`egle n’est pas un segment TCP ou un datagramme UDP. port to Cet attribut permet de pr´eciser le port de destination du segment TCP ou datagramme UDP attendu par la r`egle. La syntaxe de celui-ci est identique a` celle de l’attribut port from. Cet attribut ne devra pas eˆ tre utilis´e lorsque l’information attendue par la r`egle n’est pas un segment TCP ou un datagramme UDP. condition Cet attribut permet de d´efinir le type de condition appliqu´e entre la quantit´e v´ehicul´ee a` l’aides des r`egles de type monitor et l’attribut value. Le type des quantit´es v´ehicul´ees par les monitor sont d´efinies par le plugin sid du plugin id. Les valeurs de la condition peuvent eˆ tre les suivantes : 1. eq - e´ gal 2. ne - non e´ gal 3. it - plus petit que 4. gt - plus grand que 5. le - plus petit ou e´ gal 6. ge - plus grand ou e´ gal value Cet attribut est simplement la valeur num´erique a` comparer avec la quantit´e v´ehicul´ee par l’alerte d’un moniteur.

74

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

absolute Cet attribut permet d’indiquer si la valeur a` comparer (value) a` la quantit´e v´ehicul´ee par le monitor est absolue ou relative a` la fenˆetre temporelle d’application . Cet attribut prend donc les valeurs true ou false. Absolute=”true” Indique que la valeur (value) doit eˆ tre atteinte afin que la condition soit match´ee Absolute=”false” Indique que la valeur v´ehicul´ee par le plugin sid du plugin id doit eˆ tre incr´ement´ee de value durant la fenˆetre temporelle d’application de la r`egle afin que la condition soit match´ee. interval Cet attribut est similaire a` l’attribut time out, mais il s’applique uniquement aux temps de comparaisons entre les quantit´es v´ehicul´ees par le plugin sid du plugin id et l’attribut value. Il permet ainsi de d´efinir la fenˆetre temporelle utilis´ee par l’attribut absolute. sticky Cet attribut permettra, lors de l’attente de plusieurs occurence d’une mˆeme r`egle (attribut occurence plus grand que 1), de geler les param`etres non d´efinis dans celle-ci. Sans cette possibilit´e, diff´erents e´ v´enements non identiques pourraient eˆ tre match´es comme occurence d’une mˆeme r`egle. En effet, les param`etres non d´efini dans une r`egle sont e´ quivalents a` ANY, provoquant ainsi la validation de l’´ev´enement (matching), mˆeme si celui-ci n’est pas exactement le mˆeme (param`etre non d´efini diff´erents). Lorsque cet attribut est configur´e a` true (sticky=”true”), les caract´eristiques non d´efini des e´ v´enements devront eˆ tre strictement les mˆeme que ceux de la premi`ere occurence afin que l’´ev´enement soit match´e a` nouveau. sticky different Cet attribut permet l’inverse de l’attribut sticky et doit eˆ tre utilis´e conjointement avec celui-ci. En effet, pour la d´etection de scan de ports, il serait int´eressant de d´etecter des e´ v´enements identique ayant uniquement leur port de destination diff´erent. Il est ainsi possible de d´efinir l’attribut devant eˆ tre diff´erent a` chaque occurence de la r`egle. Sticky diff´erent pourra ainsi prendre les valeurs suivantes : – SRC PORT – DST PORT – SRC IP – DST IP – PROTOCOL Ces param`etres pourront aussi utiliser le r´ef´erencement absolu abord´e dans les explications de l’attribut protocol.

I.4 I.4.1

Structures des directives de corr´elation Exemple de structure des directives

L’exemple ci-dessous illustre le fonctionnement des r`egles de corr´elation :

75

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System









La r`egle rule INTRO est la r`egle d´eclencheuse de la directive de corr´elation. Une fois celle-ci match´ee, le moteur de corr´elation attend l’apparition de l’´ev´enement rule A ou rule B avant de continuer (car les r`egles A et B sont encapsul´ees au mˆeme niveau dans une balise rules). Si rule A apparaˆıt, le moteur de corr´elation attend l’apparition de rule C pour finir son travail sur cette directive. Si par contre rule B apparaˆıt a` la place de rule A, la corr´elation est termin´ee et une alerte de haut niveau est g´en´er´ee. L’exemple suivant illustre le fonctionnement de r`egles successives :











La r`egle rule INTRO est la r`egle d´eclencheuse de la directive de corr´elation. Une fois celle-ci match´ee, le moteur de corr´elation attend l’apparition de l’´ev´enement rule A avant de continuer (passer a` la r`egle suivante). Lorsqu’un tel e´ v´enement apparaˆıt, le moteur de corr´elation attendra l’apparition de l’´ev´enement suivant permettant le passage a` ruleB et ainsi de suite. Nous remarquons que les OU logiques entre les r`egles (balise rule) sont construit a` l’aide de r`egles de mˆeme niveau a` l’int´erieur d’une balise rules. Les ET logiques entre r`egles sont quant a` eux simplement

76

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

construit par imbriquation de r`egles (balise rule). De plus, nous remarquons que les balises rules encapsulent obligatoirement les r`egles (balise rule), mˆeme si une unique r`egle est pr´esente.

I.4.2

Structure de corr´elation r´ealisable

La figure I.1, illustre un sch´ema de corr´elation non r´ealisable a` l’aide de la syntaxe XML d’OSSIM. En effet, la syntaxe arborescente des r`egles empˆeche le passage de diff´erents e´ tats sur un e´ tat commun (les e´ tats 2 et 3 de la figure I.1 peuvent passer sur un mˆeme e´ tat ”´etat 4”). Pour qu’une telle structure soit r´ealisable a` l’aide d’OSSIM, il sera indispensable de la d´ecomposer en arbre. Pour ce faire, il serait n´ecessaire de dupliquer certains e´ tats (donc certaines r`egles) afin qu’une r`egle aboutisse toujours sur un/des e´ tats fils et non sur des e´ tats cousins.

F IG . I.1 – Sch´ema de corr´elation non r´ealisable a` l’aide d’OSSIM La figure I.2, illustre le sch´ema typique d’un sc´enario de corr´elation d’OSSIM. En effet, chaque r`egle m`ene a` ses propres sous-r`egles. Il n’y a pas de saut entre des e´ tats adjacents.

77

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

F IG . I.2 – Sch´ema de corr´elation r´ealisable a` l’aide d’OSSIM

78

Institut ICT, Jo¨el Winteregg (cc)

Annexe J

Analyse heuristique - (algorithme Holt-winter) Les explications propres a` la r´ecup´eration des donn´ees sont tir´ees du document suivant : http ://www.mirrors.wiretapped.net/security/network-monitoring/ntop/rrdandntop.pdf

J.1

R´ecup´eration des donn´ees

Comme mentionn´e en section 3.3.1 Ntop fournit les statistiques r´eseaux n´ecessaires a` l’analyse heuristique (ainsi qu’`a l’analyse de d´etection de seuils). Ces donn´ees sont stock´ees dans des bases de donn´ees tourniquets illustr´ees par la figure J.1.

F IG . J.1 – Illustration d’une base de donn´ee tourniquet Une fois le tourniquet plein, les anciennes donn´ees seront petit a` petit remplac´ees par de nouvelles.

79

SIMS - Security Intrusion Management System

A chaque p´eriode d’´echantillonage, le plugin RRD1 de Ntop interrogera les diff´erents compteurs de bytes fourni par celui-ci. Il enregistrera ensuite ces valeurs dans la base de donn´ees tourniquet correspondante. Celles-ci seront ensuite interrog´ees (`a l’aide de RRDtool) par l’agent OSSIM via le plugin RRD2 afin d’y contrˆoler les seuils et les d´epassement de l’algorithme heuristique configur´e a` l’aide du framework (section 4.9.4). L’affichage des informations de Ntop3 utilisera les mˆemes bases de donn´ees afin de produire ses graphiques et statistiques. Il est donc important de comprendre l’impacte de la configuration du plugin RRD de Ntop (plugin natif a` Ntop) sur la p´eriode d’´echantillonage et la quantit´e d’informations (nombre d’´echantillons) collect´ee par les bases de donn´ees tourniquets. Chaque compteur d’information r´eseau fourni par Ntop (IP DNSBytes, IP HTTPBytes, etc...) impliquera la cr´eation de 3 bases de donn´ees tourniquet. Ces trois diff´erentes bases de donn´ees tourniquet sont n´ecessaires afin de permettre l’enregistrement d’au moins 1 ann´ee de statistiques sans pour autant disposer d’une gigantesque base de donn´ees. Si une unique base de donn´ees tourniquet e´ tait utilis´ee afin de stocker 1 an d’´echantillons et que la p´eriode d’´echantillonnage est de 5 minutes (300 secondes), il faudrait exactement : nbJours ∗ nbHeures/jour ∗ nbM inutes/heure ∗ nbSecondes/min 365 ∗ 24 ∗ 60 ∗ 60 = = 30 1530 600Slots periodeEchantillonage[sec] 300 (J.1) Afin de r´eduire la taille des bases de donn´ees tourniquet, des moyennes sont effectu´ees sur les e´ chantillons qui sont ensuite enregistr´e dans deux bases de donn´ees tourniquets annexes permettant le stockage de plus d’une ann´ee de statistiques ”moyenn´es” sans pour autant disposer de plus de 3mios de Slots.

J.1.1

Configuration du plugin RRD de Ntop

Celle-ci s’op`ere a` l’aide de l’interface Web offerte par la sonde Ntop (port 3000 de la sonde). Le sousmenu Plugins du menu Admin permet la configuration du plugin RRD de Ntop. Les quatre premiers param`etres permettent la d´efinition de la taille des 3 bases de donn´ees tourniquet (chaque compteur Ntop utilisera trois base de donn´ees tourniquet) ainsi que la p´eriode d’´echantillonnage utilis´ee par le plugin : Dump Interval Indique la p´eriode d’´echantillonage en secondes. C’est a` dire qu’un nouveau slot du tourniquet sera rempli toutes les N secondes. Valeur par d´efaut = 300 secondes. Dump Hours Indique la taille de la 1`ere base de donn´ees tourniquet en heures (nb d’heures d’informations a` stocker). On pourra en d´eduire le nombre de slots n´ecessaire pour stocker N heures d’informations avant qu’un nouvel e´ chantillon e´ crase un e´ chantillon existant (1 tour du tourniquet). Valeur par d´efaut = 72 heures. 1

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

80

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

Dump Days Indique la taille de la seconde base de donn´ees tourniquet en jours (nb de jours d’informations a` stocker). On pourra en d´eduire le nombre de slots n´ecessaire pour stocker N jours d’informations avant qu’un nouvel e´ chantillon e´ crase un e´ chantillon existant (1 tour du tourniquet). Valeur par d´efaut = 90 jours. Dump Months Indique la taille de la troisi`eme base de donn´ees tourniquet en mois (nb de mois d’informations a` stocker). On pourra en d´eduire le nombre de slots n´ecessaire pour stocker N mois d’informations avant qu’un nouvel e´ chantillon e´ crase un e´ chantillon existant (1 tour du tourniquet). Valeur par d´efaut = 36 mois. Cr´eation des bases de donn´ees tourniquets Les param`etres par d´efauts ci-dessus g´en`erent automatiquement (pour un compteur Ntop, IP HTTPBytes par exemple) les bases de donn´ees tourniquets suivantes (calcul des valeurs moyennes) : RRA:AVERAGE:0.5:1:864 RRA:AVERAGE:0.5:12:2160 RRA:AVERAGE:0.5:288:1080

Structure des commandes RRD : Commande :Fonction :p´eriodeEchantillonage :nbValPourFonction :nbSlots Commande RRA = cr´eation d’une base de donn´ees tourniquet Fonction Fonction math´ematique appliqu´ee aux valeurs (nbValPourFonction) afin de r´eduire la taille des base de donn´ees tourniquet suivante p´eriodeEchantillonage Interval de temps entre le relev´e de deux e´ chantillons nbValPourFonction Nb d’´echantillons appliqu´es a` la fonction math´ematique d´efinie par Fonction nbSlots Nb de slots de la base de donn´ees tourniquet Ainsi, la permi`ere base de donn´ees tourniquet ne contiendra aucune moyenne (uniquement les valeurs instantann´ees), puisque l’AVERAGE est effectu´e avec une unique valeur (nbValPourFonction = 1). Elle contiendra 72 heures d’informations r´ecup´er´ees toute les 300 secondes, ce qui implique : 72 ∗ 60 ∗ 60 nbHeures ∗ nbM inutes/heure ∗ nbSecondes/min = = 864Slots periodeEchantillonage[sec] 300

(J.2)

Pour la seconde base de donn´ees tourniquet : Un slot de celle-ci correspondra a` 12 e´ chantillons (nbValPourFonction) auquels la fonction average (Fonction = AVERAGE) aura e´ t´e appliqu´ee. Un slot contiendra alors la moyenne d’une heure d’´echantillons (12 * 5 = 60 min). Il sera donc n´ecessaire de diposer de 2160 slots afin de pouvoir y stocker 90 jours d’informations : nbJours ∗ nbHeures/jour = 90 ∗ 24 = 20 160Slots

81

(J.3)

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

J.2

Analyse des donn´ees

Cette section vise a` expliquer l’algorithme de pr´evision (heuristique) utilis´e dans OSSIM. Celui-ci r´ecup`ere les informations des bases de donn´ees RRD afin d’en tirer ses pr´evisions. Le fonctionnement des bases de donn´ees RRD est expliqu´e dans la section pr´ec´edente (section J.1). Les explications ci-dessous sont tir´ees des URL suivantes : http ://iut86-fad.univ-poitiers.fr/StatPC/livre/chapitre8/lissexpo.htm http ://www.gpa.etsmtl.ca/cours/gpa548/Chapitre2.pdf&ei=NSIDQ6TAO6GEiAKd-IkZ http ://www.usenix.org/events/lisa2000/full papers/brutlag/brutlag html/index.html

J.2.1

Algorithmes de pr´evision

Les s´eries temporelles sont bas´ees sur l’analyse des donn´es historiques recueillies sur un ph´enom`ene donn´e, durant une certaine p´eriode de temps (statistiques r´eseaux par exemples). Les pr´evisions effectu´ees a` partir de s´eries temporelles ont pour hypoth`ese que le pass´e est garant de l’avenir, que le ph´enom`ene continuera a` se comporter comme il l’a fait dans le pass´e. On isole habituellement trois composantes dans les s´eries temporelles : tendance caract´eristique d’un ph´enom`ene a` d´emontrer, un patron stable de croissance ou de d´ecroissance dans le temps. Le patron peut eˆ tre lin´eaire ou non-lin´eaire. caract´eristique d’un ph´enom`ene qui se r´ep`ete a` intervalles fixes, par exemple tous les hivers, tous les mois, etc... aspect cyclique identique a` la saisonnalit´e mais pour des intervalles plus longs, souvent calcul´es en ann´ees. aspect al´eatoire se dit d’un ph´enom`ene qui ne comporte aucun patron d´ecelable. Divers m´ethodes et mod`eles de pr´evisions sont actuellement utilisables. C’est le type de la fonction temporelle a` pr´edire qui nous indiquera le meilleur algorithme (mod`ele math´ematique) a` utiliser. En effet, il sera inutile d’utiliser un mod`ele math´ematique complex tel que Holt-Winters si aucun ph´enom`ene cyclique n’est pr´esent dans la s´erie temporelle. En effet, dans le cas o`u la s´erie est stationnaire (on ne distingue pas de tendance a` la hausse ni a` la baisse), on utilisera le lissage exponentiel simple. Dans le cas d’une s´erie soumise a` des variations saisonni`eres, on utilise souvent le mod`ele de Holt et Winters. Moyennes glissantes Une moyenne gilssante d’ordre N est d´efinie comme e´ tant la moyenne arithm´etique sur les N derni`eres observations. En m´ethodes pr´evisionnelles, cette moyenne devient la porchaine pr´evision. Math´ematiquement cela donne : Ft =

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

82

(J.4)

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

Avec : Ft La pr´evision effectu´ee a` la p´eriode t-1 pour la p´eriode t. Dt-1 La valeur (mesur´ee) de la s´erie a` la p´eriode t-1. Lissage exponentiel Le lissage exponentiel est une classe de m´ethodes de lissage de s´eries chronologiques dont l’objectif est la pr´evision a` court terme. Ces m´ethodes sont fond´ees sur une hypoth`ese fondamentale : chaque observation a` l’instant t d´epend des observations pr´ec´edentes et d’une variation accidentelle. En r´esum´e, la pr´evision courante est une moyenne pond´er´ee de la derni`ere pr´evision et de la valeur courante. Math´ematiquement cela s’´ecrit sous cette forme : Ft = αDt−1 + (1 − α)Ft−1

(J.5)

Avec : Ft La pr´evision effectu´ee a` la p´eriode t-1 pour la p´eriode t. Dt-1 La valeur (mesur´ee) de la s´erie a` la p´eriode t-1. Ft-1 La pr´evision a` la p´eriode t-1 (p´eriode pr´ec´edente de la nouvelle pr´evision). alpha Param`etre compris entre 0 et 1. A l’aide de la formule J.5, nous remarquons que plus le param`etre alpha est grand (proche de 1) plus nous tenons compte des valeurs pr´ec´edentes mesur´ees. Plus alpha est petit (proche de 0), plus nous tenons compte des valeurs pr´ec´edentes pr´edites.

Holt-Winters La m´ethode de Holt et Winters permet en effet d’effectuer des pr´evisions sur des s´eries chronologiques assez irr´eguli`eres et soumises ou non a` des variations saisonni`eres suivant un mod`ele additif ou multiplicatif. Elle consiste en trois lissages exponentiels simultan´es d´efinit par trois param`etres. On peut choisir les coefficients arbitrairement : faibles si l’on consid`ere que la valeur a` l’instant t d´epend d’un grand nombre d’observations ant´erieures, e´ lev´es dans le cas contraire (mˆeme principe que pour le lissage exponentiel simple). On peut aussi en calculer les valeurs optimales, en minimisant la somme des carr´es des diff´erences entre les valeurs observ´ees et estim´ees. Le param`etrage de la p´eriodicit´e (variation saisonni`ere) est important puisque celui-ci influencera grandement l’algorithme de pr´evision. La figure J.2 illustre l’erreur entre une pr´ediction par lissage exponentiel et la fonction a` observ´ee (en bleu) ainsi que l’erreur entre une pr´ediction par Holt-Winters et la fonction observ´ee (en rouge). La figure J.3, illustre quant a` elle les mˆemes erreurs que la figure pr´ec´edente (figure J.2) avec, cette fois-ci, un mauvais r`eglage du param`etre de p´eriodicit´e de l’algorithme Holt-Winters. Nous remarquons

83

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

F IG . J.2 – Erreurs de pr´edictions avec un bon r´eglage du param`etre de p´eriodicit´e de Holt-Winters donc que la pr´evision par Holt-Winters devient aussi mauvaise (mˆeme pire) qu’une simple pr´ediction par lissage exponentiel. Il est donc tr`es important de bien r´egler ce param`etre afin d’obtenir une pr´ediction optimale... Les feuilles de calcul OpenOffice et Excel permettant de tester et comparer le comportement d’un algorithme de pr´ediction par lissage exponentiel ainsi que par Holt-Winters sont t´el´echargeables a` l’adresse suivante : http ://www.fullsecurity.ch/security/sims/download.jsp

84

Institut ICT, Jo¨el Winteregg (cc)

SIMS - Security Intrusion Management System

F IG . J.3 – Erreurs de pr´edictions avec un mauvais r´eglage du param`etre de p´eriodicit´e de Holt-Winters

85

Institut ICT, Jo¨el Winteregg (cc)