Mémoire mastère ips

Développement et Intégration d’un IPSpersonnalisé dans un Système d’Information

18 juin 2013

Réalisé par : RAOUAFI Ayoub & SMII Mondher

Au sein de : AXELARIS

Encadré par : BEN STA Hatem & AMOR Achraf

[email protected]

[email protected]

Table des matières

1 Introduction générale 2

2 Présentation de l’organisme 62.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Données générales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Contexte technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Offres commerciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.1 Cloud privé, public ou hybride . . . . . . . . . . . . . . . . . . . . 82.4.2 Offre service SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.3 Offre des services managés . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Étude d’AlienVault 113.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Présentation générale de la solution d’AlienVault . . . . . . . . . . . . . . 113.3 Principe technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4.1 Pré-processing (Alienvault agent) . . . . . . . . . . . . . . . . . . . 123.4.2 Post-processing (Alienvault server) . . . . . . . . . . . . . . . . . . 133.4.3 Le flux de fonctionnement d’Alienvault . . . . . . . . . . . . . . . . 13

3.5 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5.1 La détection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.5.1.1 Méthodes de détection . . . . . . . . . . . . . . . . . . . . 163.5.2 L’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.5.2.1 Définition de la priorité des alarmes . . . . . . . . . . . . 173.5.2.2 Évaluation des risques . . . . . . . . . . . . . . . . . . . . 183.5.2.3 Corrélation . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5.3 Le monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5.3.1 Moniteur de risque . . . . . . . . . . . . . . . . . . . . . . 203.5.3.2 Console légale . . . . . . . . . . . . . . . . . . . . . . . . 203.5.3.3 Panneau de contrôle . . . . . . . . . . . . . . . . . . . . . 20

3.6 Avantages et inconvénients majeurs d’Alienvault . . . . . . . . . . . . . . 213.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Spécification et conception 234.1 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1

4.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 234.1.4 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . 24

4.1.4.1 Diagramme de cas d’utilisation général . . . . . . . . . . 244.1.4.2 Diagramme de cas d’utilisation de l’interface web . . . . 25

4.1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.2 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.3.1 Diagramme de classes : coeur du module . . . . . . . . . 284.2.3.2 Diagramme de classes : interface web . . . . . . . . . . . 30

4.2.4 Schéma physique de la base de données . . . . . . . . . . . . . . . 314.2.5 Diagramme d’activités . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.5.1 Diagramme d’activités : coeur du module . . . . . . . . . 324.2.5.2 Diagramme d’activités : Interface web . . . . . . . . . . . 35

4.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Réalisation 395.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 395.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.3 Principe de fonctionnement du module . . . . . . . . . . . . . . . . . . . . 405.3.1 Serveur IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3.1.1 Phase de récupération . . . . . . . . . . . . . . . . . . . . 405.3.1.2 Phase de synchronisation . . . . . . . . . . . . . . . . . . 40

5.3.2 Agent IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.2.1 Phase d’auto identification . . . . . . . . . . . . . . . . . 425.3.2.2 Phase d’exécution des ordres . . . . . . . . . . . . . . . . 425.3.2.3 Phase de sauvegarde . . . . . . . . . . . . . . . . . . . . . 43

5.3.3 Interface web : Menu RS IPS . . . . . . . . . . . . . . . . . . . . . 435.3.3.1 Arborescence du menu . . . . . . . . . . . . . . . . . . . 435.3.3.2 Architecture du menu . . . . . . . . . . . . . . . . . . . . 44

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Conclusion et perspectives 51

7 Annexe 537.1 Intégration du module IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2 Bibliothèque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Table des figures

2.1 Acces Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Stack de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Service SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Architecture d’Alienvault . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Cheminement du flux d’informations . . . . . . . . . . . . . . . . . . . . . 143.3 Principe de la corrélation . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . 244.2 Diagramme de cas d’utilisation de l’interface Web . . . . . . . . . . . . . . 254.3 Interaction du module IPS avec le système . . . . . . . . . . . . . . . . . . 274.4 Diagramme de classes : coeur du module . . . . . . . . . . . . . . . . . . . 294.5 Diagramme de classes : Interface web ( Menu ) . . . . . . . . . . . . . . . 304.6 Schéma physique de la BD . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.7 Diagramme d’activités : Serveur IPS . . . . . . . . . . . . . . . . . . . . . 334.8 Diagramme d’activités : Agent IPS . . . . . . . . . . . . . . . . . . . . . . 344.9 Diagramme d’activités : interface web . . . . . . . . . . . . . . . . . . . . 36

5.1 Arborescence du menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2 White list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3 Black list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.4 Ajout adresse IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.5 Generate report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.6 Extrait du rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.7 Graphique du nombre des agents et des adresses bloquées, acceptées . . . 475.8 Pourcentage des services . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.9 Top 10 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.10 Top 10 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.1 Organigramme des fichiers du Serveur IPS . . . . . . . . . . . . . . . . . . 547.2 Organigramme des fichiers du Agent IPS . . . . . . . . . . . . . . . . . . . 557.3 Organigramme des fichiers du menu RS IPS . . . . . . . . . . . . . . . . . 567.4 Interface web : Menu RS IPS . . . . . . . . . . . . . . . . . . . . . . . . . 57

Liste des tableaux

3.1 Avanatges/inconvénients Alienvault . . . . . . . . . . . . . . . . . . . . . . 21

INTRODUCTION GENERALE

1

1 Introduction générale

IntroductionDe nos jours, le Système d’Information S.I est devenu vital pour la majorité des

entreprises. Garant de l’activité de l’entreprise pour certaine ou simple garant des don-nées confidentielles pour d’autres, une interruption de service du S.I induirait des risquesmajeurs pour l’entreprise :

– Risque de perte financière,– Risque de petre d’image de marque,– Risque d’impact juridique.

Ces risques augmentent lors de l’utilisation d’un système d’information existantdans un environnement du cloud computing.

La sécurité du cloud est un sous domaine du cloud computing en relation avec lasécurité informatique. Assurer la sécurité de cet environnement revient à garantir lasécurité des réseaux, du matériel et les stratégies de contrôles déployées afin de protégerles données, les applications et l’infrastructure associée au cloud computing.

Etat de l’existantUn aspect important du cloud est la notion d’interconnexion avec divers matériels

qui rend difficile et nécessaire la sécurisation de ces environnements. Un problème desécurité dans une plateforme sur le cloud peut engendrer une perte économique maiségalement une mauvaise réputation si toutefois cette plateforme est orientée au grandpublic.

Tout système informatique peut être la cible d’une menace qui cherchera à exploiter sesvulnérabilités. Pour atténuer cette menace, les intervenants du cloud devraient investirmassivement dans l’évaluation des risques informatiques afin de s’assurer que les donnéessont bien protégées, mettre une politique de sécurité en se basant sur des outils desupervision du trafic réseau et des solutions de détection/prévention d’intrusion. Toutceci afin d’établir la confiance dans cette nouvelle technologie qu’est le cloud computing.

Ces solutions peuvent être soit matérielles, soit logicielles et peuvent intervenir surun poste de travail, sur un serveur de production, sur une architecture de productionetc...

2


Bref, il n’existe pas vraiment de standard même si certaines solutions sortent du lot ets’imposent naturellement de part leur reconnaissance auprès des acteurs de la sécurité.

Autre inconvénient majeur, l’expérience montre que la mise en oeuvre de telles solu-tions n’est valable que si les remontées d’informations sont suivies et traitées.En sécurité informatique tout particulièrement, l’outil n’est utile que si les données

remontées sont pertinentes et que celles-ci sont analysées et traitées.

Contexte et objectifsEn partant du postulat énoncé au paragraphe précédent, la société AXELARIS

souhaite renforcer sa position en articulant bien ses offres autour des problématiquesde sécurisation de son système d’information existant dans un environnement du cloudcomputing afin d’être compétitive. Elle a implémenté une solution Open Source : Alien-vault qui fait partie des logiciels SIEM, leur principe est de gérer les évènements duSystème d’Information.

Cette solution permettant de gérer de manière centralisée les remontées d’informationde différents outils, de les stocker et les traiter afin de faciliter l’administration et lagestion de la sécurité pour les administrateurs. Elle regroupe un grand nombre d’outilsOpen Source citant comme exemple l’IDS SNORT, Nagios, PADS ... mais ne contenantpas un outil permettant de bloquer d’une façon automatique les intrusions. En effet,AXELARIS gère les intrusions sur deux étapes : la première est la détection de l’intrusionet l’envoi d’une alarme au responsable de la sécurité du SI et la deuxième est le blocagemanuel de cette intrusion. Certes ce système est performant dans sa première partie,mais le fait de laisser le blocage manuel peut engendrer des pertes en cas d’absence dupersonnel .

Notre projet se situe dans ce contexte. Après concertation avec le dirigeant de laDivision d’Opération M. AMOR Achraf et aux vues des besoins, nous avons établiel’objectif du projet qui consiste à développer et intégrer un module IPS personnalisédans la plateforme Alienvault.

Plan du rapportle présent rapport est une synthèse du travail réalisé au sein de la société Axelaris, il

est organisé en cinq chapitres de la manière suivante :

– Le premier chapitre comporte un présentation générale de l’organisme d’accueil etdu contexte de travail ainsi que ses offres commerciales

– Le deuxième intitulé «Étude d’Alienvault» est consacré à détailler la plateforme desupervision Alienvault

3


– Le troisième intitulé «Spécification et conception » est dédié à analyser les besoinsfonctionnels et non fonctionnels de ce module et détaillé la conception architecturaledu module

– Le quatrième chapitre intitulé «Réalisation» présente les outils utilisés afin de réa-liser ce projet, et décrit avec des captures d’écrans le travail élaboré.

Finalement, nous achevons notre rapport par une conclusion générale .

4

PRESENTATION DEL’ORGANISME

5

2 Présentation de l’organisme

2.1 IntroductionDans ce chapitre, nous allons présenter l’organisme qui nous a accueilli tout au long

de notre stage. Nous présenterons son domaine d’activité, son effectif, son contexte tech-nologique et ses offres commerciales.

2.2 Données généralesRaison Sociale : AXELARIS SA.

1er Responsable : M. Zied BEN SALEM

Adresse : 08 Impasse N°2 Avenue Youssef ROUISSI, 2092 - Manar II - TUNIS

Téléphone : (+216) 71 883 683

Fax : (+216) 71 883 673

Site web :– www.axelaris.com/– http ://www.wcloudhosting.com/– http ://smartxpbx.com– http ://www.smartxcrm.com/

Domaine d’activité : Cloud Computing

Matricule Fiscale : 1218663X/A/M/000

Registre de commerce : B24177882011

Capital Social : 2 760 000 DT

Effectif NombreCadres de Direction 3

Cadres Commerciaux et Marketing 9Cadres Informatique et Télécommunication 24

Cadres Administratifs 3

6


2.3 Contexte technologiqueToutes les sociétés souhaitant réduire leurs coûts directs informatiques (infra-

structure et logiciels) et également les coûts indirects liés à la maintenance techniqueet fonctionnelle, à la formation des personnels... Le Clouding s’adresse aussi bien auxPME/ETI souhaitant se concentrer sur leur coeur de métier en exploitant un systèmed’information évolutif et les « grands comptes » confrontés à une globalisation de leuractivité et très souvent à une croissance externe.

Le Cloud Computing est une technique où les ressources informatiques logicielleset matérielles sont massivement scalables et élastiques. Ces ressources sont fournies entant que service “as-a-service” aux utilisateurs finaux via Internet.

Le Cloud Computing apporte des nouveautés dans la consommation du service infor-matique :– Modèle d’acquisition : basé sur l’achat du service.– Business Modèle : basé sur le « pay as you go » en d’autres termes payé uniquement

ce que vous avez consommé.– Modèle d’accés : sur Internet (avec ou sans VPN) avec n’importe quel équipement

(PC, Terminal, Mobile, ...).– Modèle technique : Scalable, élastique, dynamique, multi-tenant, mutualisé.

Figure 2.1: Acces Model

7


2.4 Offres commerciales2.4.1 Cloud privé, public ou hybride

Les solutions Axelaris Cloud Business peuvent être exploitées de plusieurs façonsen fonction des processus de business, de la structure de l’entreprise, des politiques desécurité ou des modèles d’utilisation.– Privé ou « sur site» : sur les serveurs propres au client.– Public ou En ligne : Pour réduire nettement l’investissement et le coût de mainte-

nance, assurer la flexibilité maximale ainsi que l’évolutivité, . . .– Hybrid : Combiner les deux options d’hébergement pour créer un mélange optimum

du contrôle, vitesse, fiabilité, flexibilité, accessibilité et protection.

Figure 2.2: Stack de service

8


2.4.2 Offre service SaaSLa société AXELARIS fourni une panoplie de service en mode SaaS (Software as

a Service). Un logiciel en mode SaaS est un logiciel qui se consomme en ligne en payantune rétribution unitaire à la consommation. Le service peut être facturé par utilisateur,par facture générée, par capacité de stockage, . . .

Figure 2.3: Service SaaS

2.4.3 Offre des services managésLa société AXELARIS assure pour ses clients nationaux et internationaux une

prestation de services managés. Le service se compose de :– Performance Mangement des plateformes informatique et télécommunication.– Security information event management.– TMA : Tierce Maintenance Applicative.– Infogérance des plateformes de production.

2.5 ConclusionDans ce chapitre nous avons présenté l’organisme d’accueil au sein duquel nous

avons réalisé notre projet. Le prochain chapitre sera consacré pour l’étude de la solutionAlienvault.

9

ÉTUDE D’ALIENVAULT

10

3 Étude d’AlienVault

3.1 IntroductionLe présent chapitre est réservé à l’étude de la solution Alienvault. Nous allons détaillé

son achitecture ainsi que le pricnipe de son fonctionnement.

3.2 Présentation générale de la solution d’AlienVaultAlienvault est un projet open source de management de la sécurité de l’information.

Cette solution s’appuie sur une gestion des logs basées sur la corrélation de ceux-ci ainsiqu’une notion d’évaluation des risques.

Cette solution est née du constat selon lequel il est difficile encore à ce jour d’obtenir uninstantané de son réseau et des informations qui y transitent avec un niveau d’abstractionsuffisant pour permettre sur une surveillance claire et efficace.

Le but d’Alienvault est donc de combler ce vide constaté quotidiennement par lesprofessionnels de la sécurité [1].

3.3 Principe techniqueAlienvault est une solution fédérant d’autres produits open-source au sein d’une

infrastructure complète de supervision de la sécurité (Framework 1).

Le Framework au sein d’Alienvault à pour objectif de centraliser, d’organiser et d’amé-liorer la détection et l’affichage pour la surveillance des événements liés à la sécurité dusystème d’information d’une entreprise.

La solution Alienvault fournit donc par le biais de son framework un outil administratifqui permet de configurer et d’organiser les différents modules natifs ou externes qui vontcomposer la solution.

Le Framework est ainsi constitué des éléments de supervision suivantes :– Un panneau de contrôle– Des moniteurs de supervision de l’activité et des risques– Des moniteurs de supervision réseau et des consoles d’investigation (Forensic 2)1. Littéralement Cadre d’application2. Légal. Souvent traduit par Console d’investigation

11


Ces éléments s’appuient sur des mécanismes de corrélation, de gestion des prioritéset d’évaluation des risques afin d’améliorer la fiabilité et la sensibilité des détections ausein de la solution.

3.4 ArchitectureL’architecture d’Alienvault est divisée en 2 principaus étages :

1. Pré-processing : remontée d’événements des moniteurs et détecteurs dans unebase de données commune

2. Post-processing : analyse centraliséeLa figure 3.1 illustre le fonctionnement en 2 étages.

Figure 3.1: Architecture d’Alienvault

3.4.1 Pré-processing (Alienvault agent)Le pré-processing ou le pré-traitement est assuré par les moniteurs d’événements et

autres éléments de détection.les équipements qui prennent en charge ce prétraitement peuvent être déployés en

même temps qu’Alienvault ou bien faire partie de l’architecture existante.On retrouve parmi ces équipements, les sondes de détections d’intrusions (IDS), les

Firewall, les syslog, etc...

12


Le prétraitement de l’information, assuré au niveau de ces équipements, consiste enla collecte des informations de logs ainsi que la normalisation des celles-ci afin de lesstockers de manière uniforme et de pouvoir les traiter efficacement durant l’étape depost-traitement.

3.4.2 Post-processing (Alienvault server)Le post-processing ou le post-traitement est constitué de l’ensemble des processus

interne à la solution Alienvault qui vont prendre en charge l’information brute telle qu’elleest collectée (puis normalisée), pour ensuite l’analyser, la traiter et enfin la stocker.Les différents traitements appliquées aux informations recueilies dépendant des outils

activés au sein de la solution mais aussi de politiques définies par le biais de panneau decontrôle.Les informations sont priorisées. Les risques sont évalués en fonction de la politique

définie, et enfin les informations sont corrélées avant d’être stockées dans la base desévénements.

3.4.3 Le flux de fonctionnement d’AlienvaultAfin d’aider à la compréhension, nous allons détailler le cheminement d’une alarme

dans l’architecture définie par la figure 3.1. Le schéma de la figure 3.2, illustre le chemi-nement du flux d’informations

13


Figure 3.2: Cheminement du flux d’informations

1. Détection d’un événement suspect par un détecteur2. Si nécessaire, des alarmes sont regroupées (par le détecteur) afin de diminuer le

trafic réseau3. Le collecteur reçoit la/les alarme(s) via différents protocoles de communications

ouverts4. Le parser 3 normalise et sauve les alarmes dans la base de données d’événements5. Le parser assigne une priorité aux alarmes reçues en fonction de la configuration

des politiques de sécurité définies par l’administrateur sécurité6. Le parser évalue le risque immédiat représenté par l’alarme et envoie si nécessaire

une alarme interne au Control Panel7. L’alerte est maintenant envoyée à tous les processus de corrélation qui mettent à

jour leus états et envoient éventuellement une alerte interne plus précise (grouped’alerte provenant de la corrélation) au module de centralisation

8. Le moniteur de risque affiche périodiquement l’état de chaque risque calculés parCALM

3. L’analyseur

14


9. Le panneau de contrôle affiche les alarmes les plus récentes et met à jour les indicesdes états qui sont comparés aux seuils définis par l’administrateur. Si les indicessont supérieurs aux seuils configurés, une alarme interne est émise

10. Depuis le panneau de contrôle, l’administrateur a la possibilité de visualiser etrecherche des liens entre les différentes alarmes à l’aide de la console forensic.

3.5 Principe de fonctionnementLe pricnipe de fonctionnement d’Alienvault est formé de trois grandes catégories

décomposées elles-mêmes en sous catégories :1. La détection

– IDS (pattern matching 4)– Détection d’anomalie– Firewalls

2. L’analyse et le monitoring

– Coorélation– Évaluation de la dangerosité des alarmes– Évaluation du risque sur l’architecture à protéger

3. Le management

– Inventaire des ressources informatiques 5

– Définition de la topologie– Définition des politiques de sécurité– Définition des règles de corrélation– Liens avec différents outils d’audits Open Sourceles différents procédés cités ci-dessus seront détaillés dans les sections suivantes.

3.5.1 La détectionCelle-ci évidemment effectuée à l’aide de sondes capables de traiter l’information 6 en

temp réel et d’émettre des alarmes lorsqu’une situation à risque est détectée.

4. signatures5. machines, systèmes d’exploitation, services6. trames transitants par le réseau ou log d’une application

15


3.5.1.1 Méthodes de détection

Une sonde peut utiliser différentes approches afin de déterminer si une événement està risque ou non. En effet, deux grandes principes complémentaires (et non concurrent)sont présents dans la détection d’intrusions :

1. Basé sur des signatures2. Basé sur la détection d’anaomalie

Détection par signatures

La détection par signatures identifie des événements de sécurité qui tentent d’utiliserun système de façon non standard. Les représentations d’intrusions sont donc stockéeset comparées à l’activité du système.

Lorsqu’une intrusion connue est repérée lors de l’utilisation du système, une alarmeest levée. La détection par signatures a des limites. Elle ne connait pas l’objectif del’activité correspondant à une signature et va donc déclencher une alerte même si letrafic est normal. De plus, la détection par signature exige de connaitre préalablementl’attaque afin de générer la signature précise correspondante (fonctionnement par listenoire, exemple : antivirus ). Ceci implique q’une attaque encore inconnue ne pourra pasêtre détectée par signature.

Détection d’anomalie

La détection d’anomalie identifie une activité suspecte en mesurant une norme 7 surun certain temps. Une alerte est ensuite générée lorsque le modèle s’éloigne de cettenorme.

Le principale avantage de la détection d’anomalie est qu’elle n’exige aucune connais-sance préalable des attaques. Si le module de détection par anomalie détermine qu’uneattaque diffère de façon significative de l’activité normale, il peut la détecter.

Comme la détection par recherche de pattern, la détection d’anomalie possède seslimites. Toutes la difficulté réside dans la période de collecte des données correspondantà une activité désignée comme normale pour alimenter la base de données de référence.

3.5.2 L’analyseLa méthode de traitement des données peut être décomposée en trois phases distinctes :

1. Preprocessing : génération des alarmes et envoi de celles-ci.2. Rassemblement : toutes les alarmes précédemment envoyées (preprocessing) sont

emmagasinées dans un serveur central.

7. activité normale

16


3. Post-processing : le traitement des données que l’on a emagasiné.

Les deux premières étapes (preprocessing et rassemblement ) ne présentent rien denouveau dans le cadre d’Alienvault. Celles-ci font principalement partie des méthodesde détection mentionnées ci-dessus (SousSection 3.4.1). Alienvault offrira uniquementde nouvelles méthodes d’analyse et d’affichage des données récoltées. Il n’apportera enaucun cas de nouvelles solutions dans la détection et le rassemblement de données.

Différentes méthodes d’analyse sont implémentées dans le cadre d’Alienault :– Définition de la priorité des alarmes– Évaluation des risques– Corrélation

3.5.2.1 Définition de la priorité des alarmes

Ce procédé permettra de déduire la priorité d’une alarmes en fonction de son type, dela source de l’éventuelle attaque ainsi que de sa cible. Les exemples suivants illustrentfacilement l’utilité de cette étape d’analyse :– Une machine fonctionnant avec le système d’exploitation UNIX et hébergeant un

serveur Web Apache est mentionnée comme cible d’une attaque. Cette attaque aprécédemment été détectée comme possible à l’aide d’un scanner de vulnérabilités.La priorité de l’alerte sera donc maxiamle puisque le serveur Web est vulnérable àl’attaque en question. Un procédé de cross-corrélation est donc appliqué à toutesles alertes.

– Si la connexion à un serveur génère une alarme, la configuration de politique desécurité en fonction des utilisateurs permettra facilement la définition de la prioritéde celle-ci. En effet, différents cas sont envisageables :• Priotité maximale de l’alarme si l’utilisateur (source de l’attaque) est extérieurau réseau de l”entreprise et que la connexion a pour cible une base de donnéeimportantes.

• Basse priorité si l’utilisateur (source de l’attaque) est interne au réseau de l’en-treprise et que la connexion a pour cible une imprimante.

• Alarme discréditée si l’utilisateur (source de l’attaque) fait partie de l’équipe dedéveloppement et que la cible de la connexion est un serveur de test.

La définition de priorité fait partie d’une étape de mise en place de contextes desalarmes. Celles-ci est uniquement possible si l’environnement de l’entreprise est définidans une base de données des connaissances. Cette base de données est définie parl’inventaire des bien informatiques ainsi que sur des politiques d’accès à des serveurset/ou services. La définition de ces différentes politiques de sécurité implique la mise àdisposition d’un outil de management permettant une configuration précise des politiques

17


de sécurité ainsi que des machines du réseau.Cette étape représente une part importante du filtrage des alarmes et nécessitera une

constante mise à jour de la base de données des connaissances.

3.5.2.2 Évaluation des risques

Le risque peut être défini comme étant la probabilité de menace de l’événement. End’autres termes, cette étape tente de définir si la menace est réelle ou pas.L’importance à donner à un événement dépend principalement de trois facteurs :

1. La valeur du bien attaqué2. La menace représentée par l’événement3. La probabilité que l’événement apparaisse

Les trois facteurs vus ci-dessus sont la base du calcul du risque intrinsèque.

Risque intrinsèque Ce risque peut être défini de la façon suivante : La mesure del’impact potentiel de la menace sur le bien informatique, en fonction de la probabilitéque cette menace apparaisse, tout en tenant comptre de la fiabilité du capteur ayantémit l’alarme.Le risque est traditionnellement représenté par le risque intrinsèque représentant le

risque qu’une organisation court de par les biens qu’elle possède.

Risque immédiat Étant donné qu’Alienvault offre un traitement temps réel des alarmes,le calcul du risque immédiat peut être associé à la situation courante.Ce risque offre une vision de l’évaluation des dégats qu’une alarme reçue pourrait

engendrer. Cette évaluation prendra aussi en compte la fiabilité du capteur ayant émiscette alarme. Le risque immédiat est donc calculé pour chaque alarmes reçues et indiquel’importance de l’alarme en terme de sécurité.

3.5.2.3 Corrélation

Ce procédé permet nottament de retrouver ceertaines relations entre diférentes alarmesindépendantes. Ceci permettra par exemple de découvrir des attaques noyées dans le flotdes alarmes ou encore de discrétiser des alarmes (découverte de faux positifs).La corrélation peut être simplement définie comme un procédé traitant des données

(inputs) et retournant un résultat (outputs). Alienvault utilise deux types d’inputs :

1. Information du moniteur (qui fournit normalment des indications à l’administra-teur)

2. Informations des détecteurs (qui fournissent normalement des alarmes)

18


Le résultat de ce traitement sera lui aussi d’un des deux genres cités ci-desssus (dumoniteur ou des détecteurs ). Les modèles de corrélations utilisés par Alainevault ontles objectifs suivants :– Utilisation de méthodes par signatures, pour la détection d’événements connus et

détectables– Utilisation de méthodes sans signature, pour la détection d’événements non connus– Utilisation d’une machine d’états configurables par l’utilisateur, pour la description

de signatures complexes– Utilisation d’algorithmes évolués, pour l’affichage générale de la sécurité

Principe technique de la corrélation sous Alienvault

a ) En entrée (input) :

Deux éléments bien définis fournissent des informations aux fonctions de corrélation :– Les moniteurs qui fournissent normalment des indicateurs– Les détecteurs, qui fournissent normalment des alertesb ) En sortie (output) :

On retrouve également l’un de ces deux éléments : alertes ou indicateurs.Les fonctions de corrélation deviennent en fait de nouveaux détecteurs et moniteursLa figure 3.3 montre le principe de la corrélation :

Figure 3.3: Principe de la corrélation

Le modèle de corrélation d’Alienvault a pour objectifs de :

– Développer des modèles spécifique pour détecter le connu et le détectable

19


– Développer des modèles non spécifiques pour détecter l’inconnu et l’indétectable

– Fournir une machine d’inférence qui peut être configurée en utilsiant des règles encorrélation et qui a la capacité de décrire des modèles plus complexes

– Fournir la capacité de lier des détecteurs et des moniteurs de manière récursive pourcréer des objets plus détaillés et plus utiles

– Développer les algorithmes pour montrer une vue générale de la situation de lasécurité

3.5.3 Le monitoringLe monitoring consiste en l’affichage des informations fournies. Les consoles de moni-

toring utilisent les différentes données produites par les procédés de corrélation (décritci-dessus) pour la construction d’un affichage efficace et/ou résumé.

3.5.3.1 Moniteur de risque

Ce moniteur appélé «RiskMeter» permet l’affichage des données produites par l’algo-ruthme CALM. Les informations «C» (mesure de fiabilité) et «A» (mesure du niveaud’attaque) sont illustrés graphiquement par ce moniteur.

3.5.3.2 Console légale

Cette console offre l’accès à toutes les informations recueillies et stockées par le collec-teur. Elle est donc un outil de recherche sur la base de données d’événements. Celle-cipermet une analyse à postériori détaillée et approfondie des éléments réseaux.

3.5.3.3 Panneau de contrôle

Cette console offre un aperçu de haut niveau de la sécurité. Cette console permet ladéfinition de seuils générant des alarmes de haut niveau à destination de l’administrateurréseau en charge de la sécurité. L’affichage est simple est le plus concis possible et permetla visualisation des informations suivantes :– Monitoring constant du niveau de risque– Monitoring constant du réseau (statistiques d’utilisation)– Monitoring des seuils définis– Monitoring des profiles dépassant les seuils

20


3.6 Avantages et inconvénients majeurs d’Alienvault

Avantages InconvénientsSolution Open source avec une

communauté activeSolution complexe à mettre en oeuvre.Nécessite une démarche d’audit et

évaluation des risques pour être pertientdans la configuration de la politique de

sécurité souhaitéeSolution basée sur des outils de sécurité

open source. Permet une grandemodularité et offre un panel de

fonctionnalité conséquent

Configuration difficile

Pas de solution vraiment concurrente àce jour (commerciale ou open source)

Intervention manuelle lors de détectiond’alarme

Table 3.1: Avanatges/inconvénients Alienvault

Compte tenu de la Table 3.1 et après avoir étudié les fonctionnalités d’Alienvault, ilest également possible de développer des modules aux besoins.Comme nous avons mentionné dans l’introduction, le problématique d’Alienvault est

l’intervention manuelle de l’administrateur lors de la génération d’une alarme pour lebut de bloquer la source de cette dernière et sauver le réseau de l’entreprise d’un dangerimminent. Pour combler ce problème, nous avons eu l’idée de dévélopper un module IPSqui sera integré au sein de la solution Alienvault pour automatiser l’intervention.

3.7 ConclusionDans ce chapitre nous avons donné une idée sur la solution Alienvault avec laquelle

notre module va intéragir. Maintenant, on peut entamer la partie spécification et concep-tion.

21

SPÉCIFICATION ETCONCEPTION

22

4 Spécification et conception

4.1 Spécification4.1.1 IntroductionLa première étape du développement de toute application consiste à dresser la liste des

fonctionnalités qui devront être réalisées par l’application. Cette phase est impérativepour déterminer les caractéristiques de l’application. Ce chapitre présente les différentesfonctionnalités exigées dans le module.

Suivant le cahier des charges, nous avons pu exprimer les besoins fonctionnels sousforme de diagrammes des cas d’utilisation exprimant les scénarios que nos acteurs prin-cipaux peuvent réaliser. Nous utilisons pour cela le langage UML tout au long du cyclede développement [10].

4.1.2 Besoins fonctionnelsUn besoin fonctionnel est un besoin spécifiant une action q’un système doit être ca-

pable d’effectuer. Notre module doit satisfaire les besoins fonctionnels suivants :– Détecter les intrusions : ce service permet de détecter les tentatives d’attaques

et d’intrusions au niveau des hôtes du Cloud– Catégoriser les événements : cette fonctionnalité permet de classer les évents

selon les paramètres internes du système de supervision Alienvault– Vérifier les sources d’attaques : vérifier l’appartenance du source d’attaque au

système de production de l’entreprise– Bloquer les intrusions : ce service permet de bloquer les sources d’attaques en

provenance de l’extérieur ou bien de l’intérieur– Gérer les sources d’attaques : cette fonctionnalité offre la possibilité au Respon-

sable de la Sécurité du Système d’Information RSSI d’ajouter, modifier ou supprimerune source d’attaque

4.1.3 Besoins non fonctionnelsUn besoin non fonctionnelle est une restriction ou une contrainte qui pèse sur un

service de système, telle les contraintes liées à la sécurité, les exigences en matière deperformance et la facilité de maintenace.

23


Quelques aspects classiques seront prise en compte :– Accessibilité : le module doit être facile à implémenter– Perforamnce : le module doit être rapide dans l’intervention– Ergonomie : l’interface doit être conviviale, concise et bien structurée de point de

vue contenu informationnel.

4.1.4 Diagramme de cas d’utilisation4.1.4.1 Diagramme de cas d’utilisation général

Après la corrélation des événements, une alarme va être générer pour informer l’ad-ministrateur qu’un événement suspect a été détecté suite à une attaque.Notre module est capable d’analyser les événements pour qu’il puisse détecter les

intrusions. Une fois une intrusion a été détectée, il commence par vérifier l’appartenancede la source d’attaque au système de production de l’entreprise pour distinguer le typed’attaque (interne, externe). Ensuite, il bloque cette source si elle n’appartienne pas auxmembre de l’entreprise (Pentester).La phase de blocage se fait au niveau de la couche système à travers le FW iptables :

une ligne system-log va être générée pour informer Alienvault que cette opération estfaite par notre module IPS.La figure 4.1 donne un aperçu sur le fonctionnement de notre module :

Figure 4.1: Diagramme de cas d’utilisation général

24


4.1.4.2 Diagramme de cas d’utilisation de l’interface web

Figure 4.2: Diagramme de cas d’utilisation de l’interface Web

Le RSSI ne peut accéder à l’interface web qu’après avoir procédé préalablement à uneauthentification. Il peut ajouter, supprimer, accepter ou bloquer une adresse depuis laliste (black ou white) comme il à la possibilité de générer un rapport des adresses IPbloquées ou acceptées selon une date choisie.

4.1.5 ConclusionDans ce chapitre, nous avons présenté les besoins que doit satisfaire notre module. Ces

besoins ont été énoncés à l’aide des diagrammes de cas d’utilisation. Ainsi, nous pouvonsentamer l’étude conceptuelle de notre module.

25


4.2 Conception4.2.1 IntroductionLa conception permet de décrire la manière non ambigüe du fonctionnement désiré du

système afin d’en faciliter la réalisation et la maintenance. Pour ce faire, nous présen-tons dans une première partie une conception globale de notre module ensuite dans ladeuxième partie nous détaillerons la conception en utilisant les diagrammes de classeset les diagrammes d’activités décrivant le fonctionnement du module.

4.2.2 Conception globaleNotre module et selon les besoins spécifiés, sera intégré dans le Framework Alienvault.

Il est divisé en deux parties. La première partie est le serveur IPS (partie à intégrerdans la machine ou Alienvault est instalé) et la deuxième partie est l’agent IPS (partieà intégrer dans les agents supervisés).

Au niveau de la première partie, il existe deux modes de fonctionnement :

Mode automatique :Si un attaquant fait une action malveillante sur les agents supervisés, une alarme sera

générée et affichée sur le control panel. Suite à cette alerte, le serveur IPS intervienten sélectionnant la source d’intrusions et l’envoie à tous les agents supervisés afin de labloquer par le firewall iptables.

Mode manuel :Ce mode est accessible via une interface web permettant à l’utilisateur de gérer les

adresses bloqués par le module. Depuis cette interface, l’utilisateur peut :– Gérer les sources d’attaques : bloquer ou accepter une adresse– Visualiser les graphiques sur le tableau de bord– gérer un rapport– Ajouter ou supprimer une adresse depuis la blacklist ou la whitelist.

La figure 4.3 décrit le comportement du module :

26


Figure 4.3: Interaction du module IPS avec le système

4.2.3 Diagramme de classesDans cette partie, nous détaillons la conception en utilisant la méthodologie UML, le

diagramme de classes et le diagramme d’activités qui permettent de mieux analyser lecas d’utilisation et de décrire les interactions entre le coeur de notre module et l’interfaceweb.

27


4.2.3.1 Diagramme de classes : coeur du module

le diagramme de classes ci-dessus figure 4.4 est composé de :

– syncServer : C’est la classe qui orchestre les appels et l’instanciation des autresclasses afin de créer les processus de synchronisation (threads)

– syncThread : C’est la classe qui s’occupe de la synchronisation des ordres envoyéspar le serveur au agent

– ips-DB : Elle est chargé par la création de la base de données du serveur ainsi queles différents tables. Elle accède à la BD pour charger les différentes listes (white,black, agents)

– Target : C’est une classe abstraite qui se compose de plusieurs attributs communsentre les classes Agent et Suspect_ip

– suspect_ip : Hérite de la classe target, c’est la classe qui présente la source d’alarme(intrus)

– Agent : C’est la classe qui présente l’agent IPS.

28


Fig

ure4.4:

Diagram

mede

classes:c

oeur

dumod

ule

29


4.2.3.2 Diagramme de classes : interface web

Le diagramme de classe ci-dessous est composé de :– Base : c’est la classe permettant la connexion à la base de données– Blacklist : elle permet de récupérer la liste des adresses bloquées– Whitelist : c’est la classe permettant de lister les adresses acceptées– Event : c’est la classe permettant d’afficher les événements– Utility : c’est une classe abstraite qui sert à afficher l’entête et le pied du tableau

ainsi que le formulaire– Report : c’est la classe permettant de générer le rapprot PDF– Intervention : c’est la classe qui permet d’ajouter une adresse IP manuellement

Figure 4.5: Diagramme de classes : Interface web ( Menu )

30


4.2.4 Schéma physique de la base de donnéesNotre module est constitué de quatre tables dont deux entre eux appartiennent au

plateforme Alienvault (acid_event, alarm).

– acid_event : c’est la table contenant les événements normalisés envoyés par les dif-férents agents d’Alienvault qui sont chargés de collecter toutes les données envoyéespar les différents dispositifs existants sur le réseau.

– alarm : c’est la table la plus importante dans notre module, elle contiennent lesadresses IP des attaquants

– blacklist : c’est la table nécessaire a stocker les adresses IP bloquées

– whitelist : c’est la table contenant les adresses IP autorisées

La figure ci-dessous montre le schéma physique de la Base de données et le lien entreles tables.

Figure 4.6: Schéma physique de la BD

4.2.5 Diagramme d’activitésCette partie sera consacrée à la description du fonctionnement des différentes parties

constituant notre module.

31


4.2.5.1 Diagramme d’activités : coeur du module

Les deux figures ci-dessous décrient les différentes phases du Serveur IPS et Agent IPSqui forment le coeur du module(le fonctionnement complet sera détaillé dans le chapitreRéalisation).

Serveur IPSD’abord, Le serveur IPS récupère les nouvelles alarmes de la table alarm et les stocke

dans la table Blacklist. Ensuite, il lance un processus léger qui s’occupe de la créationd”un socket pour synchroniser les sources de ces alarmes (adresses IP malveillantes) avecl’agent supervisé afin de les bloquer.

Agent IPSUne fois les alarmes sont reçues, l’agent IPS vérifie les ordres envoyées (bloquer, ac-

cepter, supprimer) avec les soruces d’alarmes et exécute ces derniers.

32


Figure 4.7: Diagramme d’activités : Serveur IPS

33


Figure 4.8: Diagramme d’activités : Agent IPS

34


4.2.5.2 Diagramme d’activités : Interface web

Après la réussite de l’authentification, l’administrateur peut accéder au menu de notremodule.

Il peut visualiser les adresses bloquées/acceptées, comme il peut bloquer ou autoriserune adresse IP manuellement et générer un rapport comportant des informations sur lesadresses sources des alarmes

En plus , l’administrateur peut voir des graphes qui donnent un aperçu sur :

– le nombre des IP acceptées/bloquées

– le nombre des agents supervisés

– le pourcentage de chaque adresse IP dans la table alarm

La figure 4.9 explique l’interaction entre l’administrateur, le système et la base dedonnées.

35


Figure 4.9: Diagramme d’activités : interface web

36


4.2.6 ConclusionNous avons maintenant terminé la phase de conception de notre application ce qui

nous permet de passer directement au développement. Dans le chapitre suivant, nousexposons la réalisation de notre travail ainsi que les résultats obtenus.

37

Réalisation

38

5 Réalisation

5.1 IntroductionDans ce chapitre, nous présenterons la partie réalisation de notre module. Dans un

premier temps, nous présenterons l’environnement matériel et logiciel. Dans un secondtemps, nous détaillerons le fonctionnement de notre module et nous proposerons unaperçu du menu ajouté à l’interface Web en utilisant des captures d’écran et des figuresillustratives.

5.2 Environnement de travailCe paragraphe décrit l’environnement matériel mis à la disposition du présent projet

aisni que l’environnement logiciel qui nous a permis la mise en place de notre module.

5.2.1 Environnement matérielPour mener à terme ce travail, nous avons utilisé un ordinateur ayant les caractéris-

tiques suivantes :– Marque : HP– Processeur : Processeur Intel® Core i3– RAM : 8,00 Go– Disque Dur : 500 Go

5.2.2 Environnement logicielNous présentons dans cette partie, les logiciels utilisés pour la mise en place de notre

module– Windows 7 Edition Professionnelle : Sytsème d’exploitation– Backtrack 5R3, Kali : distributions Linux destinées aux différents acteurs de la

securité des systèmes d’information– Creatly : outil de modélisation UML pour dessiner les diagrammes UML en ligne– Putty : émulateur de terminal pour la connexion SSH– Vmware Workstation : il permet de créer des machines virtuelles et de les exécuter

en même temps au-dessus d’un système d’exploitation hôte

39

5 Réalisation

– Dropbox : un service de stockage et de partage de copies de fichiers locaux en ligne– Lucid charts : outil de dessin réseau et graphes en ligne– Prezi : Logiciel de préparation des présentations

5.3 Principe de fonctionnement du moduleLe présent projet est divisé essentiellement en 3 parties importantes :

– La première partie est liée à l’étude du Serveur IPS de point de vue fonctionnement,architecture et technologie

– La deuxième partie est consacré pour la description du Agent IPS [2]

– La troisième partie présente la description du menu nécessaire à l’interaction avecle module [3]

5.3.1 Serveur IPSLe serveur IPS c’est la partie responsable de la récupération des alarmes et l’envoi de

ces dernières aux agents supervisés pour les bloquer.

Il se compose de deux phases principales :

– Phase de récupération : le module récupère les nouvelles alarmes générées suiteà des événements malveillantes

– Phase de synchronisation : le module envoie la source d’alarme aux agents IPS,existant dans chaque agents supervisés, afin de les bloquer.

5.3.1.1 Phase de récupération

Durant cette phase, le module IPS interagit avec le système Alienvault, en vérifiant laprésence d’une nouvelle alarme au niveau de sa base de données.

A ce niveau, le serveur IPS lance une requête SQL et applique des règles de comparai-son entre la table des alarmes et sa table blacklist. Puis, il enregistre les alarmes retenuespour des raisons de sécurité, de sureté et de traçabilité.

5.3.1.2 Phase de synchronisation

A ce stade, notre module a pris la décision d’intervention. Il lance la procédure d’in-tervention qui se déroule sur deux étapes :

– Récupération de la liste des agents supervisés

– Paquetage de la source d’attaque dans un message

40

5 Réalisation

Le paquetage c’est l’opération de préparation des ordres envoyées aux agents super-visés, dont le format du message est :

Operation-IP_source_alarme-TABLE–

Avec :

– Operation : c’est l’action appliquée par l’agent IPS, elle peut être :• ADD : ajouter la source d’alarme à la table TABLE

• DEL : supprimer l’adresse IP de la table TABLE

– IP_source_alarme : l’adresse IP sur laquelle on va appliquer l’opération

– TABLE : nom de la table où on va stocker la source d’attaque. On a deux nomsde tables :• BL : Blacklist

• WL : Whitelist

Exemple :

ADD-192.168.5.3-BL–DEL-192.168.2.40-WL–

Après l’opération de paquetage, le serveur IPS charge la liste des agents supervisésinscrits dans sa base de données, puis il crée un processus léger (Thread) pour chaqueagent.

Ce dernier prend en charge la création d’un socket pour communiquer avec les agentssupervisés. Ces derneirs créent à leurs tours des sockets et restent en mode écoute, puisle seveur IPS démarre le transfet des ordres.

Au niveau du serveur IPS, on a intégré un sous-module d’auto-détection des nouveauxagents à superviser qui permet d’envoyer d’envoyer les ordres déjà exécutées par lesanciens agents.

5.3.2 Agent IPSL’agent IPS c’est la partie qu’on va intégrer dans les agents supervisés pour exécutés

les ordres envoyées par le serveur IPS.

Il se compose de trois phases principales :

– Phase d’auto identification des nouveaux agents supervisés dans la base dedonnées

– Phase d’exécution des ordres envoyés par le serveur IPS

41

5 Réalisation

– Phase de sauvegarde des ordres exécutés dans une base de données (sous formede fichier)

5.3.2.1 Phase d’auto identification

Après l’intégration de notre serveur IPS, il est possible d’ajouter de nouveaux agentsà supervisés qui ne reconnaissent pas les ordres envoyés par le serveur IPS aux anciensagents.

Pendant cette phase, le nouvel agent s’identifie afin de recevoir les anciens ordres.

5.3.2.2 Phase d’exécution des ordres

Après la réception d’un ordre envoyé par le serveur IPS, l’agent IPS doit dépaqueterl’ordre reçu afin de déterminer les opérations à faire.

4 opération sont envisageables :

– Blocage d’une adresse : ajout à la blacklist

– Autorisation d’une adresse : ajout à la whitelist

– Suppression d’une adresse du whitelist pour l’ignorer

– Suppression d’une adresse du blacklist pour la libérer

Ensuite et selon l’ordre reçue, l’agent IPS va interagir au niveau de la couche systèmeà l’aide du Firewall iptables en exécutant l’une des commandes suivantes :

Si l’action à faire est bloquer– iptables -I INPUT 1 -s IP_source_alarme -j DROP

Si l’action à faire est autoriser– iptables -I INPUT 1 -s IP_source_alarme -j ACCEPT

Si l’action à faire est libérer– iptables -D INPUT -s IP_souce_alarme -j DROP

Si l’action à faire ignorer– iptables -D INPUT -s IP_source_alarme -j ACCEPT

Avec :

– -s IP_source_alarme : l’adresse IP source

– -j Action : L’action à appliquer pour cette règle est qui peut être :• ACCEPT : accepter les paquets reçues de la source -s IP_source_alarme

42

5 Réalisation

• DROP : rejeter les paquets reçues de la source -s IP_source_alarme

– I INPUT X : insérer une adresse dans la chaîne INPUT à la position X

– -D : supprimer une règle dont l’adresse source est -s IP_source_alarme

5.3.2.3 Phase de sauvegarde

A cause des contraintes d’indépendance entre notre module et la base de données desmachines supervisées, dans la partie agents IPS on va utiliser une base de données à basede fichiers tout en se basant sur le module anyDBM du langage Python

5.3.3 Interface web : Menu RS IPSCe menu offre trois sous-menus différents en rapport avec notre module.

5.3.3.1 Arborescence du menu

La figure 5.1 montre l’arborescence du menu de notre module.

Figure 5.1: Arborescence du menu

43

5 Réalisation

5.3.3.2 Architecture du menu

Pour accéder au menu, l’administrateur doit réussir son authentification, il a la possi-bilité de choisir entre trois sous-menus.

S’il choisit le sous-menu Manage list, une interface va être affichée offrant beaucoupde fonctionnalités.

A partir de cette interface, l’adminisrateur peut sélectionner une adresse IP soit de laBlacklist soit de la Whitelist et choisit l’action à appliquer sur cette adresse.

Trois actions sont envisageables :

– Delete : permet de supprimer l’adresse IP de la base de données

– Trust : en premier lieu, celle-ci permettra l’activation du script python/usr/share/ossim/www/ossimServer/ifaceHandler.py, qui procédera à l’envoi del’adresse IP choisie aux agents afin de l’accepter en exécutant une commande sys-tème iptables -I INPUT 1 -s IP_adresse -j ACCEPT. En deuxième lieu, l’adresseen question sera ajoutée dans la Whitelist figure 5.2.

Figure 5.2: White list

– Block : en premier lieu, celle-ci permettra l’activation du script python/usr/share/ossim/www/ossimServer/ifaceHandler.py, qui procédera à l’envoi del’adresse IP choisie aux agents afin de l’accepter en exécutant une commande sys-tème iptables -I INPUT 1 -s IP_adresse -j DROP. En deuxième lieu, l’adresse enquestion sera ajoutée dans la Blacklist figure 5.3.

Figure 5.3: Black list

L’ administrateur peut aussi ajouter une adresse IP manuellement figure 6.4. D’abord,il tape l’adresse et choisit le type de la liste (White, Black). Puis, il appuie sur le boutonADD.

44

5 Réalisation

Ce bouton fait appel à son tour au script python décrit ci-dessous, qui exécutera unecommande système iptables tout en se basant sur le choix de la liste.

Figure 5.4: Ajout adresse IP

ifaceHandler.py : Ce script joue le rôle de l’intermédiaire entre le coeur du module etl’interface.Depuis l’interface, l’administrateur peut aussi générer un rapport selon une date choi-

sie. Ce rapport permet de garder un inventaire sur les IP bloquées et/ou acceptées 2jours avant, hier et aujourd’hui.

Figure 5.5: Generate report

45

5 Réalisation

Voici ci-dessous un rapport généré pour la date 24 Mai 2013.

Figure 5.6: Extrait du rapport

D’autre part, l’administrateur peut accéder au sous-menu Charts qui comporte quatregraphiques illustrant les différentes adresses ainsi que leurs nombres.Dans cette partie, notre travail a été basé sur le principe reverse engineering et sur

deux bibliothèques PHP qui pemettent d’afficher des graphes en Flash [11] (voir Annexe).Ce sous-menu permet d’observer le nombre des adresses bloquées/acceptées par notre

module et le nombres des agents supervisés comme le montre le graphique figure 5.7.Les requêtes suivantes nous montre comment on a obtenu ce résultat pour la table

whitelist :Nombre des adresses d’aujourd’hui :SELECT COUNT(*)FROM whitelistWHERE timestamp > CURDATE()

46

5 Réalisation

Nombre des adresses d’hier :SELECT COUNT(*)FROM whitelistWHERE timestamp > DATE_ADD(CURDATE(), INTERVAL -1 DAY)AND timestamp < CURDATE()

Nombre des adresses 2 jours avant :SELECT COUNT(*)FROM whitelistWHERE timestamp > DATE_ADD(CURDATE(), INTERVAL -2 DAY)AND timestamp < DATE_ADD(CURDATE(), INTERVAL -1 DAY)

Figure 5.7: Graphique du nombre des agents et des adresses bloquées, acceptées

Le graphique de la figure 5.8 offre une vision sur le pourcentage des services utilisés,suite à un scan avec l’outil Nmap, dans les machines supervisées.

Figure 5.8: Pourcentage des services

47

5 Réalisation

La figure 5.9 Events : TOP 10 offre une vision des adresses IP sources des événementsdétectés. Il permet d’observer les 10 adresses figurant le plus souvent comme source desévénements.Voici la requête lancée dans le fichier XML permettant d’avoir ce résultat :

SELECT INET_NTOA(ip_src) AS source, COUNT (ip_src) AS counterFROM acid_eventWHERE ip_src !=0 AND ip_dst !=0GROUP BY ip_srcORDER BY counter DESC LIMIT 10 ;

Figure 5.9: Top 10 Events

Le graphique (figure 5.10) Alarms : TOP 10 donne un aperçu sur les 10 machinesfigurant le plus souvent comme sources des alertes (Top Attacker). Ces adresses vontêtre automatiquement bloquées par notre module.Voici la requête lancée dans le fichier XML permettant d’avoir ce résultat :

SELECT INET_NTOA(src_ip) AS source, COUNT (src_ip) AS numberFROM alarmWHERE src_ip !=0 AND dst_ip !=0GROUP BY src_ipORDER BY number DESC LIMIT 10 ;

48

5 Réalisation

Figure 5.10: Top 10 Alarms

5.4 ConclusionTout au long de ce derneir chapitre, nous avons exposé la réalisation de notre travail.Dans un permeir lieu, nous avons explicité l’environnement de notre travail (matériel

et logiciel). Ensuite, nous avons détailler les différentes parties formant notre module.Enfin, nous avons présenté des captures d’écrans illustrant l’interface web.

49

Conclusion et perspectives

50

6 Conclusion et perspectivesActuellement la demande en matière de sécurité est de plus en plus importante. Les

attaques quant à elles, sont devenues inévitables et les outils de détection/préventionprésentent certaines limites. La tendance à optimiser ces dernies va de pair avec larecherche de nouvelles sources de données exploitables.

C’est dans ce cadre que se présente notre projet de fin d’études intitulé Développementet intégration d’un module IPS dans un système d’information réalisé au sein de la sociétéAxelaris.

D’abord, nous avons commencé par une première partie dans laquelle nous avons pré-senté le cadre de ce projet, outre nous avons fait une étude sur le système de supervisionAlienvault. Puis, nous avons détaillé la partie conceptuelle. Enfin, nous avons terminépar la réalisation dans laquelle nous avons décrit l’environnement de tarvail réalisé etnous avons illustré le fonctionnement de notre IPS.

Malgré les problèmes que nous avons rencontré durant notre travail, en particulier ladifficulté de familiarisation avec Alienvault qui parait en premier instant très compliquépuisqu’il renferme beaucoup d’outils open source pour améliorer la détection d’intrusionset une base de données trop complexe. Ce projet nous a été profitable. En effet, parmi lesapports dont nous avons bénéficié, la découverte de nouveaux langages tels que Python etPHP5. Ces langages nous ont été considérablement enrichissants. Nous avons égalementappris à communiquer avec les encadrants et à travailler en groupe en partageant lestâches en gérant le temps avec discernement.

D’autres part, ce projet nous a également offert l’opportunité d’acquérir une meilleuremaitrise des diagrammes UML ainsi d’améliorer nos compétences de rédaction de rap-port.

En effet, une perspective de ce projet sera de réussir à développer, pour ce module,une interface graphique purement en python pour que nous puissions l’intégrer dansn’importe quel système.

En fin, nous espérons que ce projet soit le premier pas vers la vie professionnelle et unguide pour ceux qui s’intéressent à la matière.

51

Annexe

52

7 Annexe

7.1 Intégration du module IPSAprès avoir installé Alienvault, nous nous sommes penchés sur le développement du

module permettant d’automatiser le blocage d’une source d’alarme.

Voici ce que nous attendons de notre module :

– Récupérer l’adresse source d’alarme

– Stocker cette alarme dans la Black list

– Envoyer la source vers les agents supervisés

– Bloquer la source d’intrusion

Le module se compose de trois répertoires :

– Server IPS

– Agent IPS

– Interface

Server IPSLe répertoire Server IPS va être localisé

/usr/share/ossim/www/IPS-Module/ossimServer/.Il se compose d’un ensemble de scripts python comme le montre la figure 8.1.

voici la description des différents fichiers :

– syncServer.py : créer les processus de synchronisation (threads)

– init.py : initialiser les variables nécessaire pour la connexion à la base de données

– ipsDb.py : créer la base de données et les tables

– syncThread.py : envoyer les ordres aux agents supervisés

53

7 Annexe

Figure 7.1: Organigramme des fichiers du Serveur IPS

Agent IPSLe répertoire Agent IPS va être localisé dans

/usr/share/ossim/www/IPS-Module/ossimAgent/.Il se compose d’un ensemble de scripts python comme le montre la figure 8.2.

voici la description des différents fichiers :

– syncAgent.py : exécuter les ordres reçus

– init.py : initialiser les paramètres nécessaire pour la connexion à la base de données

– records.py : gérer la base de données

– serverId.py : ajouter l’identifiant de l’agent dans la base du serveur

54

7 Annexe

Figure 7.2: Organigramme des fichiers du Agent IPS

InterfaceLe répertoire interface sera localisé dans

/usr/share/ossim/www/interface.Il se compose d’un ensemble de scripts PHP comme le montre la figure 8.3voici la description des différents fichiers :– php5 : répertoire contenant les

• utility.php : contient les fonctions permettant d’afficher l’entête du tableau et duformulaire

• getMan.php : afficher manual intervention• getEvenet.php : manipuler les événements (bloquer, accepter)• getWhite : gérer la white list• getBlack.php : gérer la black list• getReport.php : afficher le formulaire generate report

– Include : répertoire contenant les fichiers nécessaires pour la connexion à la BD etle dessin des graphs.

– graph : répertoire contenant les deux bibliothèques (FusionCharts et xml/php charts)

55

7 Annexe

– report : repértoire contenant le script generate.php• generate.php : générer le rapport PDF

– Images : répertoire des images

Figure 7.3: Organigramme des fichiers du menu RS IPS

vider la base de donnéesCe script permettant de stocker les valeurs des tables dans des fichiers et supprimer

leurs cotenus chaque Samedi à 13h.

Algorithme 7.1 clean.sh# !/bin/shmysqldump -uroot -pSLsM48Kqgx inter blackList > black.sqlmysqldump -uroot -pSLsM48Kqgx inter whiteList > white.sqlmysql inter -uroot -pSLsM48Kqgx <�<EOFDELETE FROM whiteList WHERE timestamp<DATE_SUB(NOW(), INTERVAL 7DAY) ;DELETE FROM blackList WHERE timestamp<DTAE_SUB(NOEW(), INTERVAL 7DAY) ;EOF

56

7 Annexe

Menu RS IPS

Figure 7.4: Interface web : Menu RS IPS

57

7 Annexe

7.2 BibliothèqueFusion charts, xml/php chartsFusion charts et xml/php charts sont deux outils permettant d’afficher des graphes en

Flash sur une page web.

EZPDFL’organisation R&OS Ltd a développé une bibliothèque gratuite pour la création à la

volée de documents PDF avec le langage PHP.Cette bibliothèque se compose d’une classe de base : la classe PDF. Cette dernière a

récemment été étendue par la classe EZPDF. Ces classes sont livrées avec des polices decaractères disponibles dans le répertoire /fonts du package.

anyDBMdbm a été le premier d’une famille de moteurs de base de données, à l’origine écrit

par Ken Thompson et publié par AT&T en 1979. Son nom est l’acronyme de databasemanager (gestionnaire de base de données). dbm stocke des données arbitraires parl’utilisation d’une seule clef (une clé primaire), dans un conteneur en taille fixe et utiliseles techniques de hachage pour permettre l’accès rapide aux données via la clé.

SocketUn socket est une interface entre les processus : en réseau, un socket sert donc à

faire communiquer un processus avec un service qui gère le réseau. Chaque socket a uneadresse de socket. Cette adresse est constituée de deux choses : une adresse IP et unnuméro de port. C’est grâce à la programmation de socket que l’on définit le modèle decommunication. Si le socket a été configuré de manière à envoyer ou recevoir, c’est unmodèle Half-Duplex. S’il a été configuré de manière à envoyer et recevoir simultanément,il s’agit d’un modèle Full-Duplex. Étant donné que les sockets sont en fait une interfacede programmation d’applications (API), on peut donc s’en servir pour programmer desapplications en réseaux (par exemple, créer une application pour faire communiquerun client et un serveur). Dans le souci de vous encourager à faire des recherches surla programmation des sockets, voici un schéma illustrant une communication entre unclient et un serveur.

58

Bibliographie & Nétographie

Bibliographie(1) MARTINET P, Mise en oeuvre d’un prototype d’architecture OSSIM, Lyon, 2006,

65p

(2) BRUECK D& TANNNER S, Python 2.1 Bible, New York : Edition Hungry Minds,2001, 769p

(3) BOIS FX, PHP5 Le guide complet, Paris : Edition Micro Application, 2011, 704p

Nétographie(4) https ://www.alienvault.com : Description d’Alienvault, visité le 18-03-2013

(5) http ://www.python.org/ : Fondement du langage Python, visité le 20-03-2013

(6) http ://www.tutorialspoint.com/ : Tutoriels sur les langages, visité le 20-03-2013

(7) http ://php.net/manual/fr/index.php : Fondement du langage PHP, visité le 25-03-2013

(8) https ://www.snort.org : Fonctionnement du SNORT, visité le 10-04-2013

(9) http ://stackoverflow.com/ : Forum du programmation, visité le 20-03-2013

(10) https ://creately.com : Diagrammes UML, visité le 23-04-2013

(11) http ://www.maani.us/xml_charts/ : Créations des charts, visité le 26-03-2013

(12) http ://docs.fusioncharts.com/widgets/ : Création des charts, visité le 26-03-2013

(13) https ://www.dropbox.com : Stockage des données en ligne, visité le 24-05-2013

(14) http ://www.inetdoc.net/guides/iptables-tutorial/ : Principe du firewall iptables,visité le 04-04-2013

59

7 Annexe

60

Liste des symboles

BD Base de données

CALM Compromise and Attack Level Monitor

FW Firewall

HP Hawlett Packard

IDS Intrusion Detection Sytem

IP Internet Protocol

IPS Intrusion Prevention Sytem

PADS Passive Asset Detection System

PC Personal Computer

PDF Portable Document Format

PHP Hypertext Preprocessor

RAM Random-Access Memory

RS Raouafi Smii

RSSI Responsable de Sécurité du Système d’Information

SA Société Anonyme

SAAS Software As A Service

SI Système d’Information

SIEM Security Event Information Management

SQL Structured Query Language

SSH Secure Shell

TMA Tierce Maintenance Applicative

UML Unified Modeling Language

VPN Virtual Private Network

XML Extensible Markup Language

Mémoire mastère ips

Documents

Transcript of Mémoire mastère ips