Mémoire mastère ips

Click here to load reader

  • date post

    14-Mar-2016
  • Category

    Documents

  • view

    240
  • download

    6

Embed Size (px)

description

Développement d'un IPS personnalisé dans un système d'information

Transcript of Mémoire mastère ips

  • Dveloppement et Intgration dun IPSpersonnalis dans un Systme dInformation

    18 juin 2013

  • Ralis par : RAOUAFI Ayoub & SMII Mondher

    Au sein de : AXELARIS

    Encadr par : BEN STA Hatem & AMOR Achraf

    [email protected]

    [email protected]

  • Table des matires

    1 Introduction gnrale 2

    2 Prsentation de lorganisme 62.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Donnes gnrales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 manags . . . . . . . . . . . . . . . . . . . . . . . 9

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

    3 tude dAlienVault 113.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Prsentation gnrale de la solution dAlienVault . . . . . . . . . . . . . . 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 dAlienvault . . . . . . . . . . . . . . . . 13

    3.5 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5.1 La dtection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

    3.5.1.1 Mthodes de dtection . . . . . . . . . . . . . . . . . . . . 163.5.2 Lanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

    3.5.2.1 Dfinition de la priorit des alarmes . . . . . . . . . . . . 173.5.2.2 valuation des risques . . . . . . . . . . . . . . . . . . . . 183.5.2.3 Corrlation . . . . . . . . . . . . . . . . . . . . . . . . . . 18

    3.5.3 Le monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5.3.1 Moniteur de risque . . . . . . . . . . . . . . . . . . . . . . 203.5.3.2 Console lgale . . . . . . . . . . . . . . . . . . . . . . . . 203.5.3.3 Panneau de contrle . . . . . . . . . . . . . . . . . . . . . 20

    3.6 Avantages et inconvnients majeurs dAlienvault . . . . . . . . . . . . . . 213.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

    4 Spcification et conception 234.1 Spcification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

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

    1

  • 4.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 234.1.4 Diagramme de cas dutilisation . . . . . . . . . . . . . . . . . . . . 24

    4.1.4.1 Diagramme de cas dutilisation gnral . . . . . . . . . . 244.1.4.2 Diagramme de cas dutilisation de linterface 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 Schma physique de la base de donnes . . . . . . . . . . . . . . . 314.2.5 Diagramme dactivits . . . . . . . . . . . . . . . . . . . . . . . . . 31

    4.2.5.1 Diagramme dactivits : coeur du module . . . . . . . . . 324.2.5.2 Diagramme dactivits : Interface web . . . . . . . . . . . 35

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

    5 Ralisation 395.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

    5.2.1 Environnement matriel . . . . . . . . . . . . . . . . . . . . . . . . 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 rcupration . . . . . . . . . . . . . . . . . . . . 405.3.1.2 Phase de synchronisation . . . . . . . . . . . . . . . . . . 40

    5.3.2 Agent IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.2.1 Phase dauto identification . . . . . . . . . . . . . . . . . 425.3.2.2 Phase dexcution 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 Intgration du module IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2 Bibliothque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

  • Table des figures

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

    3.1 Architecture dAlienvault . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Cheminement du flux dinformations . . . . . . . . . . . . . . . . . . . . . 143.3 Principe de la corrlation . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

    4.1 Diagramme de cas dutilisation gnral . . . . . . . . . . . . . . . . . . . . 244.2 Diagramme de cas dutilisation de linterface Web . . . . . . . . . . . . . . 254.3 Interaction du module IPS avec le systme . . . . . . . . . . . . . . . . . . 274.4 Diagramme de classes : coeur du module . . . . . . . . . . . . . . . . . . . 294.5 Diagramme de classes : Interface web ( Menu ) . . . . . . . . . . . . . . . 304.6 Schma physique de la BD . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.7 Diagramme dactivits : Serveur IPS . . . . . . . . . . . . . . . . . . . . . 334.8 Diagramme dactivits : Agent IPS . . . . . . . . . . . . . . . . . . . . . . 344.9 Diagramme dactivits : 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 bloques, acceptes . . . 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/inconvnients Alienvault . . . . . . . . . . . . . . . . . . . . . . 21

  • INTRODUCTION GENERALE

    1

  • 1 Introduction gnrale

    IntroductionDe nos jours, le Systme dInformation S.I est devenu vital pour la majorit des

    entreprises. Garant de lactivit de lentreprise pour certaine ou simple garant des don-nes confidentielles pour dautres, une interruption de service du S.I induirait des risquesmajeurs pour lentreprise :

    Risque de perte financire, Risque de petre dimage de marque, Risque dimpact juridique.

    Ces risques augmentent lors de lutilisation dun systme dinformation existantdans un environnement du cloud computing.

    La scurit du cloud est un sous domaine du cloud computing en relation avec lascurit informatique. Assurer la scurit de cet environnement revient garantir lascurit des rseaux, du matriel et les stratgies de contrles dployes afin de protgerles donnes, les applications et linfrastructure associe au cloud computing.

    Etat de lexistantUn aspect important du cloud est la notion dinterconnexion avec divers matriels

    qui rend difficile et ncessaire la scurisation de ces environnements. Un problme descurit dans une plateforme sur le cloud peut engendrer une perte conomique maisgalement une mauvaise rputation si toutefois cette plateforme est oriente au grandpublic.

    Tout systme informatique peut tre la cible dune menace qui cherchera exploiter sesvulnrabilits. Pour attnuer cette menace, les intervenants du cloud devraient investirmassivement dans lvaluation des risques informatiques afin de sassurer que les donnessont bien protges, mettre une politique de scurit en se basant sur des outils desupervision du trafic rseau et des solutions de dtection/prvention dintrusion. Toutceci afin dtablir la confiance dans cette nouvelle technologie quest le cloud computing.

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

    2

  • 1 Introduction gnrale

    Bref, il nexiste pas vraiment de standard mme si certaines solutions sortent du lot etsimposent naturellement de part leur reconnaissance auprs des acteurs de la scurit.

    Autre inconvnient majeur, lexprience montre que la mise en oeuvre de telles solu-tions nest valable que si les remontes dinformations sont suivies et traites.En scurit informatique tout particulirement, loutil nest utile que si les donnes

    remontes sont pertinentes et que celles-ci sont analyses et traites.

    Contexte et objectifsEn partant du postulat nonc au paragraphe prcdent, la socit AXELARIS

    souhaite renforcer sa position en articulant bien ses offres autour des problmatiquesde scurisation de son systme dinformation existant dans un environnement du cloudcomputing afin dtre comptitive. Elle a implment une solution Open Source : Alien-vault qui fait partie des logiciels SIEM, leur principe est de grer les vnements duSystme dInformation.

    Cette solution permettant de grer de manire centralise les remontes dinformationde diffrents outils, de les stocker et les traiter afin de faciliter ladministration et lagestion de la scurit pour les administrateurs. Elle regroupe un grand nombre doutilsOpen Source citant comme exemple lIDS SNORT, Nagios, PADS ... mais ne contenantpas un outil permettant de bloquer dune faon automatique les intrusions. En effet,AXELARIS gre les intrusions sur deux tapes : la premire est la dtection de lintrusionet lenvoi dune alarme au responsable de la scurit du SI et la deuxime est le blocagemanuel de cette intrusion. Certes ce systme est performant dans sa premire partie,mais le fait de laisser le blocage manuel peut engendrer des pertes en cas dabsence dupersonnel .

    Notre projet se situe dans ce contexte. Aprs concertation avec le dirigeant de laDivision dOpration M. AMOR Achraf et aux vues des besoins, nous avons tablielobjectif du projet qui consiste dvelopper et intgrer un module IPS personnalisdans la plateforme Alienvault.

    Plan du rapportle prsent rapport est une synthse du travail ralis au sein de la socit Axelaris, il

    est organis en cinq chapitres de la manire suivante :

    Le premier chapitre comporte un prsentation gnrale de lorganisme daccueil etdu contexte de travail ainsi que ses offres commerciales

    Le deuxime intitul tude dAlienvault est consacr dtailler la plateforme desupervision Alienvault

    3

  • 1 Introduction gnrale

    Le troisime intitul Spcification et conception est ddi analyser les besoinsfonctionnels et non fonctionnels de ce module et dtaill la conception architecturaledu module

    Le quatrime chapitre intitul Ralisation prsente les outils utiliss afin de ra-liser ce projet, et dcrit avec des captures dcrans le travail labor.

    Finalement, nous achevons notre rapport par une conclusion gnrale .

    4

  • PRESENTATION DELORGANISME

    5

  • 2 Prsentation de lorganisme

    2.1 IntroductionDans ce chapitre, nous allons prsenter lorganisme qui nous a accueilli tout au long

    de notre stage. Nous prsenterons son domaine dactivit, son effectif, son contexte tech-nologique et ses offres commerciales.

    2.2 Donnes gnralesRaison Sociale : AXELARIS SA.

    1er Responsable : M. Zied BEN SALEM

    Adresse : 08 Impasse N2 Avenue Youssef ROUISSI, 2092 - Manar II - TUNIS

    Tlphone : (+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 dactivit : 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 Tlcommunication 24

    Cadres Administratifs 3

    6

  • 2 Prsentation de lorganisme

    2.3 Contexte technologiqueToutes les socits souhaitant rduire leurs cots directs informatiques (infra-

    structure et logiciels) et galement les cots indirects lis la maintenance techniqueet fonctionnelle, la formation des personnels... Le Clouding sadresse aussi bien auxPME/ETI souhaitant se concentrer sur leur coeur de mtier en exploitant un systmedinformation volutif et les grands comptes confronts une globalisation de leuractivit et trs souvent une croissance externe.

    Le Cloud Computing est une technique o les ressources informatiques logicielleset matrielles 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 nouveauts dans la consommation du service infor-matique : Modle dacquisition : bas sur lachat du service. Business Modle : bas sur le pay as you go en dautres termes pay uniquement

    ce que vous avez consomm. Modle daccs : sur Internet (avec ou sans VPN) avec nimporte quel quipement

    (PC, Terminal, Mobile, ...). Modle technique : Scalable, lastique, dynamique, multi-tenant, mutualis.

    Figure 2.1: Acces Model

    7

  • 2 Prsentation de lorganisme

    2.4 Offres commerciales2.4.1 Cloud priv, public ou hybride

    Les solutions Axelaris Cloud Business peuvent tre exploites de plusieurs faonsen fonction des processus de business, de la structure de lentreprise, des politiques descurit ou des modles dutilisation. Priv ou sur site : sur les serveurs propres au client. Public ou En ligne : Pour rduire nettement linvestissement et le cot de mainte-

    nance, assurer la flexibilit maximale ainsi que lvolutivit, . . . Hybrid : Combiner les deux options dhbergement pour crer un mlange optimum

    du contrle, vitesse, fiabilit, flexibilit, accessibilit et protection.

    Figure 2.2: Stack de service

    8

  • 2 Prsentation de lorganisme

    2.4.2 Offre service SaaSLa socit 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 rtribution unitaire la consommation. Le service peut tre factur par utilisateur,par facture gnre, par capacit de stockage, . . .

    Figure 2.3: Service SaaS

    2.4.3 Offre des services managsLa socit AXELARIS assure pour ses clients nationaux et internationaux une

    prestation de services manags. Le service se compose de : Performance Mangement des plateformes informatique et tlcommunication. Security information event management. TMA : Tierce Maintenance Applicative. Infogrance des plateformes de production.

    2.5 ConclusionDans ce chapitre nous avons prsent lorganisme daccueil au sein duquel nous

    avons ralis notre projet. Le prochain chapitre sera consacr pour ltude de la solutionAlienvault.

    9

  • TUDE DALIENVAULT

    10

  • 3 tude dAlienVault

    3.1 IntroductionLe prsent chapitre est rserv ltude de la solution Alienvault. Nous allons dtaill

    son achitecture ainsi que le pricnipe de son fonctionnement.

    3.2 Prsentation gnrale de la solution dAlienVaultAlienvault est un projet open source de management de la scurit de linformation.

    Cette solution sappuie sur une gestion des logs bases sur la corrlation de ceux-ci ainsiquune notion dvaluation des risques.

    Cette solution est ne du constat selon lequel il est difficile encore ce jour dobtenir uninstantan de son rseau et des informations qui y transitent avec un niveau dabstractionsuffisant pour permettre sur une surveillance claire et efficace.

    Le but dAlienvault est donc de combler ce vide constat quotidiennement par lesprofessionnels de la scurit [1].

    3.3 Principe techniqueAlienvault est une solution fdrant dautres produits open-source au sein dune

    infrastructure complte de supervision de la scurit (Framework 1).

    Le Framework au sein dAlienvault pour objectif de centraliser, dorganiser et dam-liorer la dtection et laffichage pour la surveillance des vnements lis la scurit dusystme dinformation dune entreprise.

    La solution Alienvault fournit donc par le biais de son framework un outil administratifqui permet de configurer et dorganiser les diffrents modules natifs ou externes qui vontcomposer la solution.

    Le Framework est ainsi constitu des lments de supervision suivantes : Un panneau de contrle Des moniteurs de supervision de lactivit et des risques Des moniteurs de supervision rseau et des consoles dinvestigation (Forensic 2)1. Littralement Cadre dapplication2. Lgal. Souvent traduit par Console dinvestigation

    11

  • 3 tude dAlienVault

    Ces lments sappuient sur des mcanismes de corrlation, de gestion des prioritset dvaluation des risques afin damliorer la fiabilit et la sensibilit des dtections ausein de la solution.

    3.4 ArchitectureLarchitecture dAlienvault est divise en 2 principaus tages :

    1. Pr-processing : remonte dvnements des moniteurs et dtecteurs dans unebase de donnes commune

    2. Post-processing : analyse centraliseLa figure 3.1 illustre le fonctionnement en 2 tages.

    Figure 3.1: Architecture dAlienvault

    3.4.1 Pr-processing (Alienvault agent)Le pr-processing ou le pr-traitement est assur par les moniteurs dvnements et

    autres lments de dtection.les quipements qui prennent en charge ce prtraitement peuvent tre dploys en

    mme temps quAlienvault ou bien faire partie de larchitecture existante.On retrouve parmi ces quipements, les sondes de dtections dintrusions (IDS), les

    Firewall, les syslog, etc...

    12

  • 3 tude dAlienVault

    Le prtraitement de linformation, assur au niveau de ces quipements, consiste enla collecte des informations de logs ainsi que la normalisation des celles-ci afin de lesstockers de manire uniforme et de pouvoir les traiter efficacement durant ltape depost-traitement.

    3.4.2 Post-processing (Alienvault server)Le post-processing ou le post-traitement est constitu de lensemble des processus

    interne la solution Alienvault qui vont prendre en charge linformation brute telle quelleest collecte (puis normalise), pour ensuite lanalyser, la traiter et enfin la stocker.Les diffrents traitements appliques aux informations recueilies dpendant des outils

    activs au sein de la solution mais aussi de politiques dfinies par le biais de panneau decontrle.Les informations sont priorises. Les risques sont valus en fonction de la politique

    dfinie, et enfin les informations sont corrles avant dtre stockes dans la base desvnements.

    3.4.3 Le flux de fonctionnement dAlienvaultAfin daider la comprhension, nous allons dtailler le cheminement dune alarme

    dans larchitecture dfinie par la figure 3.1. Le schma de la figure 3.2, illustre le chemi-nement du flux dinformations

    13

  • 3 tude dAlienVault

    Figure 3.2: Cheminement du flux dinformations

    1. Dtection dun vnement suspect par un dtecteur2. Si ncessaire, des alarmes sont regroupes (par le dtecteur) afin de diminuer le

    trafic rseau3. Le collecteur reoit la/les alarme(s) via diffrents protocoles de communications

    ouverts4. Le parser 3 normalise et sauve les alarmes dans la base de donnes dvnements5. Le parser assigne une priorit aux alarmes reues en fonction de la configuration

    des politiques de scurit dfinies par ladministrateur scurit6. Le parser value le risque immdiat reprsent par lalarme et envoie si ncessaire

    une alarme interne au Control Panel7. Lalerte est maintenant envoye tous les processus de corrlation qui mettent

    jour leus tats et envoient ventuellement une alerte interne plus prcise (groupedalerte provenant de la corrlation) au module de centralisation

    8. Le moniteur de risque affiche priodiquement ltat de chaque risque calculs parCALM

    3. Lanalyseur

    14

  • 3 tude dAlienVault

    9. Le panneau de contrle affiche les alarmes les plus rcentes et met jour les indicesdes tats qui sont compars aux seuils dfinis par ladministrateur. Si les indicessont suprieurs aux seuils configurs, une alarme interne est mise

    10. Depuis le panneau de contrle, ladministrateur a la possibilit de visualiser etrecherche des liens entre les diffrentes alarmes laide de la console forensic.

    3.5 Principe de fonctionnementLe pricnipe de fonctionnement dAlienvault est form de trois grandes catgories

    dcomposes elles-mmes en sous catgories :1. La dtection IDS (pattern matching 4) Dtection danomalie Firewalls

    2. Lanalyse et le monitoring Coorlation valuation de la dangerosit des alarmes valuation du risque sur larchitecture protger

    3. Le management Inventaire des ressources informatiques 5

    Dfinition de la topologie Dfinition des politiques de scurit Dfinition des rgles de corrlation Liens avec diffrents outils daudits Open Sourceles diffrents procds cits ci-dessus seront dtaills dans les sections suivantes.

    3.5.1 La dtectionCelle-ci videmment effectue laide de sondes capables de traiter linformation 6 en

    temp rel et dmettre des alarmes lorsquune situation risque est dtecte.

    4. signatures5. machines, systmes dexploitation, services6. trames transitants par le rseau ou log dune application

    15

  • 3 tude dAlienVault

    3.5.1.1 Mthodes de dtection

    Une sonde peut utiliser diffrentes approches afin de dterminer si une vnement est risque ou non. En effet, deux grandes principes complmentaires (et non concurrent)sont prsents dans la dtection dintrusions :

    1. Bas sur des signatures2. Bas sur la dtection danaomalie

    Dtection par signatures

    La dtection par signatures identifie des vnements de scurit qui tentent dutiliserun systme de faon non standard. Les reprsentations dintrusions sont donc stockeset compares lactivit du systme.

    Lorsquune intrusion connue est repre lors de lutilisation du systme, une alarmeest leve. La dtection par signatures a des limites. Elle ne connait pas lobjectif delactivit correspondant une signature et va donc dclencher une alerte mme si letrafic est normal. De plus, la dtection par signature exige de connaitre pralablementlattaque afin de gnrer la signature prcise correspondante (fonctionnement par listenoire, exemple : antivirus ). Ceci implique qune attaque encore inconnue ne pourra pastre dtecte par signature.

    Dtection danomalie

    La dtection danomalie identifie une activit suspecte en mesurant une norme 7 surun certain temps. Une alerte est ensuite gnre lorsque le modle sloigne de cettenorme.

    Le principale avantage de la dtection danomalie est quelle nexige aucune connais-sance pralable des attaques. Si le module de dtection par anomalie dtermine quuneattaque diffre de faon significative de lactivit normale, il peut la dtecter.

    Comme la dtection par recherche de pattern, la dtection danomalie possde seslimites. Toutes la difficult rside dans la priode de collecte des donnes correspondant une activit dsigne comme normale pour alimenter la base de donnes de rfrence.

    3.5.2 LanalyseLa mthode de traitement des donnes peut tre dcompose en trois phases distinctes :

    1. Preprocessing : gnration des alarmes et envoi de celles-ci.2. Rassemblement : toutes les alarmes prcdemment envoyes (preprocessing) sont

    emmagasines dans un serveur central.

    7. activit normale

    16

  • 3 tude dAlienVault

    3. Post-processing : le traitement des donnes que lon a emagasin.

    Les deux premires tapes (preprocessing et rassemblement ) ne prsentent rien denouveau dans le cadre dAlienvault. Celles-ci font principalement partie des mthodesde dtection mentionnes ci-dessus (SousSection 3.4.1). Alienvault offrira uniquementde nouvelles mthodes danalyse et daffichage des donnes rcoltes. Il napportera enaucun cas de nouvelles solutions dans la dtection et le rassemblement de donnes.

    Diffrentes mthodes danalyse sont implmentes dans le cadre dAlienault : Dfinition de la priorit des alarmes valuation des risques Corrlation

    3.5.2.1 Dfinition de la priorit des alarmes

    Ce procd permettra de dduire la priorit dune alarmes en fonction de son type, dela source de lventuelle attaque ainsi que de sa cible. Les exemples suivants illustrentfacilement lutilit de cette tape danalyse : Une machine fonctionnant avec le systme dexploitation UNIX et hbergeant un

    serveur Web Apache est mentionne comme cible dune attaque. Cette attaque aprcdemment t dtecte comme possible laide dun scanner de vulnrabilits.La priorit de lalerte sera donc maxiamle puisque le serveur Web est vulnrable lattaque en question. Un procd de cross-corrlation est donc appliqu toutesles alertes.

    Si la connexion un serveur gnre une alarme, la configuration de politique descurit en fonction des utilisateurs permettra facilement la dfinition de la prioritde celle-ci. En effet, diffrents cas sont envisageables : Priotit maximale de lalarme si lutilisateur (source de lattaque) est extrieurau rseau de lentreprise et que la connexion a pour cible une base de donneimportantes.

    Basse priorit si lutilisateur (source de lattaque) est interne au rseau de len-treprise et que la connexion a pour cible une imprimante.

    Alarme discrdite si lutilisateur (source de lattaque) fait partie de lquipe dedveloppement et que la cible de la connexion est un serveur de test.

    La dfinition de priorit fait partie dune tape de mise en place de contextes desalarmes. Celles-ci est uniquement possible si lenvironnement de lentreprise est dfinidans une base de donnes des connaissances. Cette base de donnes est dfinie parlinventaire des bien informatiques ainsi que sur des politiques daccs des serveurset/ou services. La dfinition de ces diffrentes politiques de scurit implique la mise disposition dun outil de management permettant une configuration prcise des politiques

    17

  • 3 tude dAlienVault

    de scurit ainsi que des machines du rseau.Cette tape reprsente une part importante du filtrage des alarmes et ncessitera une

    constante mise jour de la base de donnes des connaissances.

    3.5.2.2 valuation des risques

    Le risque peut tre dfini comme tant la probabilit de menace de lvnement. Endautres termes, cette tape tente de dfinir si la menace est relle ou pas.Limportance donner un vnement dpend principalement de trois facteurs :

    1. La valeur du bien attaqu2. La menace reprsente par lvnement3. La probabilit que lvnement apparaisse

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

    Risque intrinsque Ce risque peut tre dfini de la faon suivante : La mesure delimpact potentiel de la menace sur le bien informatique, en fonction de la probabilitque cette menace apparaisse, tout en tenant comptre de la fiabilit du capteur ayantmit lalarme.Le risque est traditionnellement reprsent par le risque intrinsque reprsentant le

    risque quune organisation court de par les biens quelle possde.

    Risque immdiat tant donn quAlienvault offre un traitement temps rel des alarmes,le calcul du risque immdiat peut tre associ la situation courante.Ce risque offre une vision de lvaluation des dgats quune alarme reue pourrait

    engendrer. Cette valuation prendra aussi en compte la fiabilit du capteur ayant miscette alarme. Le risque immdiat est donc calcul pour chaque alarmes reues et indiquelimportance de lalarme en terme de scurit.

    3.5.2.3 Corrlation

    Ce procd permet nottament de retrouver ceertaines relations entre difrentes alarmesindpendantes. Ceci permettra par exemple de dcouvrir des attaques noyes dans le flotdes alarmes ou encore de discrtiser des alarmes (dcouverte de faux positifs).La corrlation peut tre simplement dfinie comme un procd traitant des donnes

    (inputs) et retournant un rsultat (outputs). Alienvault utilise deux types dinputs :

    1. Information du moniteur (qui fournit normalment des indications ladministra-teur)

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

    18

  • 3 tude dAlienVault

    Le rsultat de ce traitement sera lui aussi dun des deux genres cits ci-desssus (dumoniteur ou des dtecteurs ). Les modles de corrlations utiliss par Alainevault ontles objectifs suivants : Utilisation de mthodes par signatures, pour la dtection dvnements connus et

    dtectables Utilisation de mthodes sans signature, pour la dtection dvnements non connus Utilisation dune machine dtats configurables par lutilisateur, pour la description

    de signatures complexes Utilisation dalgorithmes volus, pour laffichage gnrale de la scurit

    Principe technique de la corrlation sous Alienvault

    a ) En entre (input) :Deux lments bien dfinis fournissent des informations aux fonctions de corrlation : Les moniteurs qui fournissent normalment des indicateurs Les dtecteurs, qui fournissent normalment des alertesb ) En sortie (output) :On retrouve galement lun de ces deux lments : alertes ou indicateurs.Les fonctions de corrlation deviennent en fait de nouveaux dtecteurs et moniteursLa figure 3.3 montre le principe de la corrlation :

    Figure 3.3: Principe de la corrlation

    Le modle de corrlation dAlienvault a pour objectifs de :

    Dvelopper des modles spcifique pour dtecter le connu et le dtectable

    19

  • 3 tude dAlienVault

    Dvelopper des modles non spcifiques pour dtecter linconnu et lindtectable

    Fournir une machine dinfrence qui peut tre configure en utilsiant des rgles encorrlation et qui a la capacit de dcrire des modles plus complexes

    Fournir la capacit de lier des dtecteurs et des moniteurs de manire rcursive pourcrer des objets plus dtaills et plus utiles

    Dvelopper les algorithmes pour montrer une vue gnrale de la situation de lascurit

    3.5.3 Le monitoringLe monitoring consiste en laffichage des informations fournies. Les consoles de moni-

    toring utilisent les diffrentes donnes produites par les procds de corrlation (dcritci-dessus) pour la construction dun affichage efficace et/ou rsum.

    3.5.3.1 Moniteur de risque

    Ce moniteur appl RiskMeter permet laffichage des donnes produites par lalgo-ruthme CALM. Les informations C (mesure de fiabilit) et A (mesure du niveaudattaque) sont illustrs graphiquement par ce moniteur.

    3.5.3.2 Console lgale

    Cette console offre laccs toutes les informations recueillies et stockes par le collec-teur. Elle est donc un outil de recherche sur la base de donnes dvnements. Celle-cipermet une analyse postriori dtaille et approfondie des lments rseaux.

    3.5.3.3 Panneau de contrle

    Cette console offre un aperu de haut niveau de la scurit. Cette console permet ladfinition de seuils gnrant des alarmes de haut niveau destination de ladministrateurrseau en charge de la scurit. Laffichage est simple est le plus concis possible et permetla visualisation des informations suivantes : Monitoring constant du niveau de risque Monitoring constant du rseau (statistiques dutilisation) Monitoring des seuils dfinis Monitoring des profiles dpassant les seuils

    20

  • 3 tude dAlienVault

    3.6 Avantages et inconvnients majeurs dAlienvault

    Avantages InconvnientsSolution Open source avec une

    communaut activeSolution complexe mettre en oeuvre.Ncessite une dmarche daudit et

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

    scurit souhaiteSolution base sur des outils de scurit

    open source. Permet une grandemodularit et offre un panel de

    fonctionnalit consquent

    Configuration difficile

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

    Intervention manuelle lors de dtectiondalarme

    Table 3.1: Avanatges/inconvnients Alienvault

    Compte tenu de la Table 3.1 et aprs avoir tudi les fonctionnalits dAlienvault, ilest galement possible de dvelopper des modules aux besoins.Comme nous avons mentionn dans lintroduction, le problmatique dAlienvault est

    lintervention manuelle de ladministrateur lors de la gnration dune alarme pour lebut de bloquer la source de cette dernire et sauver le rseau de lentreprise dun dangerimminent. Pour combler ce problme, nous avons eu lide de dvlopper un module IPSqui sera integr au sein de la solution Alienvault pour automatiser lintervention.

    3.7 ConclusionDans ce chapitre nous avons donn une ide sur la solution Alienvault avec laquelle

    notre module va intragir. Maintenant, on peut entamer la partie spcification et concep-tion.

    21

  • SPCIFICATION ETCONCEPTION

    22

  • 4 Spcification et conception

    4.1 Spcification4.1.1 IntroductionLa premire tape du dveloppement de toute application consiste dresser la liste des

    fonctionnalits qui devront tre ralises par lapplication. Cette phase est imprativepour dterminer les caractristiques de lapplication. Ce chapitre prsente les diffrentesfonctionnalits exiges dans le module.

    Suivant le cahier des charges, nous avons pu exprimer les besoins fonctionnels sousforme de diagrammes des cas dutilisation exprimant les scnarios que nos acteurs prin-cipaux peuvent raliser. Nous utilisons pour cela le langage UML tout au long du cyclede dveloppement [10].

    4.1.2 Besoins fonctionnelsUn besoin fonctionnel est un besoin spcifiant une action qun systme doit tre ca-

    pable deffectuer. Notre module doit satisfaire les besoins fonctionnels suivants : Dtecter les intrusions : ce service permet de dtecter les tentatives dattaques

    et dintrusions au niveau des htes du Cloud Catgoriser les vnements : cette fonctionnalit permet de classer les vents

    selon les paramtres internes du systme de supervision Alienvault Vrifier les sources dattaques : vrifier lappartenance du source dattaque au

    systme de production de lentreprise Bloquer les intrusions : ce service permet de bloquer les sources dattaques en

    provenance de lextrieur ou bien de lintrieur Grer les sources dattaques : cette fonctionnalit offre la possibilit au Respon-

    sable de la Scurit du Systme dInformation RSSI dajouter, modifier ou supprimerune source dattaque

    4.1.3 Besoins non fonctionnelsUn besoin non fonctionnelle est une restriction ou une contrainte qui pse sur un

    service de systme, telle les contraintes lies la scurit, les exigences en matire deperformance et la facilit de maintenace.

    23

  • 4 Spcification et conception

    Quelques aspects classiques seront prise en compte : Accessibilit : le module doit tre facile implmenter Perforamnce : le module doit tre rapide dans lintervention Ergonomie : linterface doit tre conviviale, concise et bien structure de point de

    vue contenu informationnel.

    4.1.4 Diagramme de cas dutilisation4.1.4.1 Diagramme de cas dutilisation gnral

    Aprs la corrlation des vnements, une alarme va tre gnrer pour informer lad-ministrateur quun vnement suspect a t dtect suite une attaque.Notre module est capable danalyser les vnements pour quil puisse dtecter les

    intrusions. Une fois une intrusion a t dtecte, il commence par vrifier lappartenancede la source dattaque au systme de production de lentreprise pour distinguer le typedattaque (interne, externe). Ensuite, il bloque cette source si elle nappartienne pas auxmembre de lentreprise (Pentester).La phase de blocage se fait au niveau de la couche systme travers le FW iptables :

    une ligne system-log va tre gnre pour informer Alienvault que cette opration estfaite par notre module IPS.La figure 4.1 donne un aperu sur le fonctionnement de notre module :

    Figure 4.1: Diagramme de cas dutilisation gnral

    24

  • 4 Spcification et conception

    4.1.4.2 Diagramme de cas dutilisation de linterface web

    Figure 4.2: Diagramme de cas dutilisation de linterface Web

    Le RSSI ne peut accder linterface web quaprs avoir procd pralablement uneauthentification. Il peut ajouter, supprimer, accepter ou bloquer une adresse depuis laliste (black ou white) comme il la possibilit de gnrer un rapport des adresses IPbloques ou acceptes selon une date choisie.

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

    besoins ont t noncs laide des diagrammes de cas dutilisation. Ainsi, nous pouvonsentamer ltude conceptuelle de notre module.

    25

  • 4 Spcification et conception

    4.2 Conception4.2.1 IntroductionLa conception permet de dcrire la manire non ambige du fonctionnement dsir du

    systme afin den faciliter la ralisation et la maintenance. Pour ce faire, nous prsen-tons dans une premire partie une conception globale de notre module ensuite dans ladeuxime partie nous dtaillerons la conception en utilisant les diagrammes de classeset les diagrammes dactivits dcrivant le fonctionnement du module.

    4.2.2 Conception globaleNotre module et selon les besoins spcifis, sera intgr dans le Framework Alienvault.

    Il est divis en deux parties. La premire partie est le serveur IPS (partie intgrerdans la machine ou Alienvault est instal) et la deuxime partie est lagent IPS (partie intgrer dans les agents superviss).

    Au niveau de la premire partie, il existe deux modes de fonctionnement :

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

    gnre et affiche sur le control panel. Suite cette alerte, le serveur IPS intervienten slectionnant la source dintrusions et lenvoie tous les agents superviss afin de labloquer par le firewall iptables.

    Mode manuel :Ce mode est accessible via une interface web permettant lutilisateur de grer les

    adresses bloqus par le module. Depuis cette interface, lutilisateur peut : Grer les sources dattaques : bloquer ou accepter une adresse Visualiser les graphiques sur le tableau de bord grer un rapport Ajouter ou supprimer une adresse depuis la blacklist ou la whitelist.

    La figure 4.3 dcrit le comportement du module :

    26

  • 4 Spcification et conception

    Figure 4.3: Interaction du module IPS avec le systme

    4.2.3 Diagramme de classesDans cette partie, nous dtaillons la conception en utilisant la mthodologie UML, le

    diagramme de classes et le diagramme dactivits qui permettent de mieux analyser lecas dutilisation et de dcrire les interactions entre le coeur de notre module et linterfaceweb.

    27

  • 4 Spcification et conception

    4.2.3.1 Diagramme de classes : coeur du module

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

    syncServer : Cest la classe qui orchestre les appels et linstanciation des autresclasses afin de crer les processus de synchronisation (threads)

    syncThread : Cest la classe qui soccupe de la synchronisation des ordres envoyspar le serveur au agent

    ips-DB : Elle est charg par la cration de la base de donnes du serveur ainsi queles diffrents tables. Elle accde la BD pour charger les diffrentes listes (white,black, agents)

    Target : Cest une classe abstraite qui se compose de plusieurs attributs communsentre les classes Agent et Suspect_ip

    suspect_ip : Hrite de la classe target, cest la classe qui prsente la source dalarme(intrus)

    Agent : Cest la classe qui prsente lagent IPS.

    28

  • 4 Spcification et conception

    Figure4.4:

    Diagram

    mede

    classes:c

    oeur

    dumod

    ule

    29

  • 4 Spcification et conception

    4.2.3.2 Diagramme de classes : interface web

    Le diagramme de classe ci-dessous est compos de : Base : cest la classe permettant la connexion la base de donnes Blacklist : elle permet de rcuprer la liste des adresses bloques Whitelist : cest la classe permettant de lister les adresses acceptes Event : cest la classe permettant dafficher les vnements Utility : cest une classe abstraite qui sert afficher lentte et le pied du tableau

    ainsi que le formulaire Report : cest la classe permettant de gnrer le rapprot PDF Intervention : cest la classe qui permet dajouter une adresse IP manuellement

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

    30

  • 4 Spcification et conception

    4.2.4 Schma physique de la base de donnesNotre module est constitu de quatre tables dont deux entre eux appartiennent au

    plateforme Alienvault (acid_event, alarm).

    acid_event : cest la table contenant les vnements normaliss envoys par les dif-frents agents dAlienvault qui sont chargs de collecter toutes les donnes envoyespar les diffrents dispositifs existants sur le rseau.

    alarm : cest la table la plus importante dans notre module, elle contiennent lesadresses IP des attaquants

    blacklist : cest la table ncessaire a stocker les adresses IP bloques

    whitelist : cest la table contenant les adresses IP autorises

    La figure ci-dessous montre le schma physique de la Base de donnes et le lien entreles tables.

    Figure 4.6: Schma physique de la BD

    4.2.5 Diagramme dactivitsCette partie sera consacre la description du fonctionnement des diffrentes parties

    constituant notre module.

    31

  • 4 Spcification et conception

    4.2.5.1 Diagramme dactivits : coeur du module

    Les deux figures ci-dessous dcrient les diffrentes phases du Serveur IPS et Agent IPSqui forment le coeur du module(le fonctionnement complet sera dtaill dans le chapitreRalisation).

    Serveur IPSDabord, Le serveur IPS rcupre les nouvelles alarmes de la table alarm et les stocke

    dans la table Blacklist. Ensuite, il lance un processus lger qui soccupe de la crationdun socket pour synchroniser les sources de ces alarmes (adresses IP malveillantes) aveclagent supervis afin de les bloquer.

    Agent IPSUne fois les alarmes sont reues, lagent IPS vrifie les ordres envoyes (bloquer, ac-

    cepter, supprimer) avec les soruces dalarmes et excute ces derniers.

    32

  • 4 Spcification et conception

    Figure 4.7: Diagramme dactivits : Serveur IPS

    33

  • 4 Spcification et conception

    Figure 4.8: Diagramme dactivits : Agent IPS

    34

  • 4 Spcification et conception

    4.2.5.2 Diagramme dactivits : Interface web

    Aprs la russite de lauthentification, ladministrateur peut accder au menu de notremodule.

    Il peut visualiser les adresses bloques/acceptes, comme il peut bloquer ou autoriserune adresse IP manuellement et gnrer un rapport comportant des informations sur lesadresses sources des alarmes

    En plus , ladministrateur peut voir des graphes qui donnent un aperu sur :

    le nombre des IP acceptes/bloques

    le nombre des agents superviss

    le pourcentage de chaque adresse IP dans la table alarm

    La figure 4.9 explique linteraction entre ladministrateur, le systme et la base dedonnes.

    35

  • 4 Spcification et conception

    Figure 4.9: Diagramme dactivits : interface web

    36

  • 4 Spcification et conception

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

    nous permet de passer directement au dveloppement. Dans le chapitre suivant, nousexposons la ralisation de notre travail ainsi que les rsultats obtenus.

    37

  • Ralisation

    38

  • 5 Ralisation

    5.1 IntroductionDans ce chapitre, nous prsenterons la partie ralisation de notre module. Dans un

    premier temps, nous prsenterons lenvironnement matriel et logiciel. Dans un secondtemps, nous dtaillerons le fonctionnement de notre module et nous proposerons unaperu du menu ajout linterface Web en utilisant des captures dcran et des figuresillustratives.

    5.2 Environnement de travailCe paragraphe dcrit lenvironnement matriel mis la disposition du prsent projet

    aisni que lenvironnement logiciel qui nous a permis la mise en place de notre module.

    5.2.1 Environnement matrielPour mener terme ce travail, nous avons utilis un ordinateur ayant les caractris-

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

    5.2.2 Environnement logicielNous prsentons dans cette partie, les logiciels utiliss pour la mise en place de notre

    module Windows 7 Edition Professionnelle : Sytsme dexploitation Backtrack 5R3, Kali : distributions Linux destines aux diffrents acteurs de la

    securit des systmes dinformation Creatly : outil de modlisation UML pour dessiner les diagrammes UML en ligne Putty : mulateur de terminal pour la connexion SSH Vmware Workstation : il permet de crer des machines virtuelles et de les excuter

    en mme temps au-dessus dun systme dexploitation hte

    39

  • 5 Ralisation

    Dropbox : un service de stockage et de partage de copies de fichiers locaux en ligne Lucid charts : outil de dessin rseau et graphes en ligne Prezi : Logiciel de prparation des prsentations

    5.3 Principe de fonctionnement du moduleLe prsent projet est divis essentiellement en 3 parties importantes :

    La premire partie est lie ltude du Serveur IPS de point de vue fonctionnement,architecture et technologie

    La deuxime partie est consacr pour la description du Agent IPS [2]

    La troisime partie prsente la description du menu ncessaire linteraction avecle module [3]

    5.3.1 Serveur IPSLe serveur IPS cest la partie responsable de la rcupration des alarmes et lenvoi de

    ces dernires aux agents superviss pour les bloquer.

    Il se compose de deux phases principales :

    Phase de rcupration : le module rcupre les nouvelles alarmes gnres suite des vnements malveillantes

    Phase de synchronisation : le module envoie la source dalarme aux agents IPS,existant dans chaque agents superviss, afin de les bloquer.

    5.3.1.1 Phase de rcupration

    Durant cette phase, le module IPS interagit avec le systme Alienvault, en vrifiant laprsence dune nouvelle alarme au niveau de sa base de donnes.

    A ce niveau, le serveur IPS lance une requte SQL et applique des rgles de comparai-son entre la table des alarmes et sa table blacklist. Puis, il enregistre les alarmes retenuespour des raisons de scurit, de suret et de traabilit.

    5.3.1.2 Phase de synchronisation

    A ce stade, notre module a pris la dcision dintervention. Il lance la procdure din-tervention qui se droule sur deux tapes :

    Rcupration de la liste des agents superviss

    Paquetage de la source dattaque dans un message

    40

  • 5 Ralisation

    Le paquetage cest lopration de prparation des ordres envoyes aux agents super-viss, dont le format du message est :

    Operation-IP_source_alarme-TABLE

    Avec :

    Operation : cest laction applique par lagent IPS, elle peut tre : ADD : ajouter la source dalarme la table TABLE DEL : supprimer ladresse IP de la table TABLE

    IP_source_alarme : ladresse IP sur laquelle on va appliquer lopration

    TABLE : nom de la table o on va stocker la source dattaque. On a deux nomsde tables : BL : Blacklist WL : Whitelist

    Exemple :

    ADD-192.168.5.3-BLDEL-192.168.2.40-WL

    Aprs lopration de paquetage, le serveur IPS charge la liste des agents supervissinscrits dans sa base de donnes, puis il cre un processus lger (Thread) pour chaqueagent.

    Ce dernier prend en charge la cration dun socket pour communiquer avec les agentssuperviss. Ces derneirs crent leurs tours des sockets et restent en mode coute, puisle seveur IPS dmarre le transfet des ordres.

    Au niveau du serveur IPS, on a intgr un sous-module dauto-dtection des nouveauxagents superviser qui permet denvoyer denvoyer les ordres dj excutes par lesanciens agents.

    5.3.2 Agent IPSLagent IPS cest la partie quon va intgrer dans les agents superviss pour excuts

    les ordres envoyes par le serveur IPS.

    Il se compose de trois phases principales :

    Phase dauto identification des nouveaux agents superviss dans la base dedonnes

    Phase dexcution des ordres envoys par le serveur IPS

    41

  • 5 Ralisation

    Phase de sauvegarde des ordres excuts dans une base de donnes (sous formede fichier)

    5.3.2.1 Phase dauto identification

    Aprs lintgration de notre serveur IPS, il est possible dajouter de nouveaux agents superviss qui ne reconnaissent pas les ordres envoys par le serveur IPS aux anciensagents.

    Pendant cette phase, le nouvel agent sidentifie afin de recevoir les anciens ordres.

    5.3.2.2 Phase dexcution des ordres

    Aprs la rception dun ordre envoy par le serveur IPS, lagent IPS doit dpaqueterlordre reu afin de dterminer les oprations faire.

    4 opration sont envisageables :

    Blocage dune adresse : ajout la blacklist

    Autorisation dune adresse : ajout la whitelist

    Suppression dune adresse du whitelist pour lignorer

    Suppression dune adresse du blacklist pour la librer

    Ensuite et selon lordre reue, lagent IPS va interagir au niveau de la couche systme laide du Firewall iptables en excutant lune des commandes suivantes :

    Si laction faire est bloquer iptables -I INPUT 1 -s IP_source_alarme -j DROP

    Si laction faire est autoriser iptables -I INPUT 1 -s IP_source_alarme -j ACCEPT

    Si laction faire est librer iptables -D INPUT -s IP_souce_alarme -j DROP

    Si laction faire ignorer iptables -D INPUT -s IP_source_alarme -j ACCEPT

    Avec :

    -s IP_source_alarme : ladresse IP source

    -j Action : Laction appliquer pour cette rgle est qui peut tre : ACCEPT : accepter les paquets reues de la source -s IP_source_alarme

    42

  • 5 Ralisation

    DROP : rejeter les paquets reues de la source -s IP_source_alarme I INPUT X : insrer une adresse dans la chane INPUT la position X

    -D : supprimer une rgle dont ladresse source est -s IP_source_alarme

    5.3.2.3 Phase de sauvegarde

    A cause des contraintes dindpendance entre notre module et la base de donnes desmachines supervises, dans la partie agents IPS on va utiliser une base de donnes 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 diffrents en rapport avec notre module.

    5.3.3.1 Arborescence du menu

    La figure 5.1 montre larborescence du menu de notre module.

    Figure 5.1: Arborescence du menu

    43

  • 5 Ralisation

    5.3.3.2 Architecture du menu

    Pour accder au menu, ladministrateur doit russir son authentification, il a la possi-bilit de choisir entre trois sous-menus.

    Sil choisit le sous-menu Manage list, une interface va tre affiche offrant beaucoupde fonctionnalits.

    A partir de cette interface, ladminisrateur peut slectionner une adresse IP soit de laBlacklist soit de la Whitelist et choisit laction appliquer sur cette adresse.

    Trois actions sont envisageables :

    Delete : permet de supprimer ladresse IP de la base de donnes

    Trust : en premier lieu, celle-ci permettra lactivation du script python/usr/share/ossim/www/ossimServer/ifaceHandler.py, qui procdera lenvoi deladresse IP choisie aux agents afin de laccepter en excutant une commande sys-tme iptables -I INPUT 1 -s IP_adresse -j ACCEPT. En deuxime lieu, ladresseen question sera ajoute dans la Whitelist figure 5.2.

    Figure 5.2: White list

    Block : en premier lieu, celle-ci permettra lactivation du script python/usr/share/ossim/www/ossimServer/ifaceHandler.py, qui procdera lenvoi deladresse IP choisie aux agents afin de laccepter en excutant une commande sys-tme iptables -I INPUT 1 -s IP_adresse -j DROP. En deuxime lieu, ladresse enquestion sera ajoute dans la Blacklist figure 5.3.

    Figure 5.3: Black list

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

    44

  • 5 Ralisation

    Ce bouton fait appel son tour au script python dcrit ci-dessous, qui excutera unecommande systme iptables tout en se basant sur le choix de la liste.

    Figure 5.4: Ajout adresse IP

    ifaceHandler.py : Ce script joue le rle de lintermdiaire entre le coeur du module etlinterface.Depuis linterface, ladministrateur peut aussi gnrer un rapport selon une date choi-

    sie. Ce rapport permet de garder un inventaire sur les IP bloques et/ou acceptes 2jours avant, hier et aujourdhui.

    Figure 5.5: Generate report

    45

  • 5 Ralisation

    Voici ci-dessous un rapport gnr pour la date 24 Mai 2013.

    Figure 5.6: Extrait du rapport

    Dautre part, ladministrateur peut accder au sous-menu Charts qui comporte quatregraphiques illustrant les diffrentes adresses ainsi que leurs nombres.Dans cette partie, notre travail a t bas sur le principe reverse engineering et sur

    deux bibliothques PHP qui pemettent dafficher des graphes en Flash [11] (voir Annexe).Ce sous-menu permet dobserver le nombre des adresses bloques/acceptes par notre

    module et le nombres des agents superviss comme le montre le graphique figure 5.7.Les requtes suivantes nous montre comment on a obtenu ce rsultat pour la table

    whitelist :Nombre des adresses daujourdhui :SELECT COUNT(*)FROM whitelistWHERE timestamp > CURDATE()

    46

  • 5 Ralisation

    Nombre des adresses dhier :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 bloques, acceptes

    Le graphique de la figure 5.8 offre une vision sur le pourcentage des services utiliss,suite un scan avec loutil Nmap, dans les machines supervises.

    Figure 5.8: Pourcentage des services

    47

  • 5 Ralisation

    La figure 5.9 Events : TOP 10 offre une vision des adresses IP sources des vnementsdtects. Il permet dobserver les 10 adresses figurant le plus souvent comme source desvnements.Voici la requte lance dans le fichier XML permettant davoir ce rsultat :

    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 aperu sur les 10 machinesfigurant le plus souvent comme sources des alertes (Top Attacker). Ces adresses vonttre automatiquement bloques par notre module.Voici la requte lance dans le fichier XML permettant davoir ce rsultat :

    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 Ralisation

    Figure 5.10: Top 10 Alarms

    5.4 ConclusionTout au long de ce derneir chapitre, nous avons expos la ralisation de notre travail.Dans un permeir lieu, nous avons explicit lenvironnement de notre travail (matriel

    et logiciel). Ensuite, nous avons dtailler les diffrentes parties formant notre module.Enfin, nous avons prsent des captures dcrans illustrant linterface web.

    49

  • Conclusion et perspectives

    50

  • 6 Conclusion et perspectivesActuellement la demande en matire de scurit est de plus en plus importante. Les

    attaques quant elles, sont devenues invitables et les outils de dtection/prventionprsentent certaines limites. La tendance optimiser ces dernies va de pair avec larecherche de nouvelles sources de donnes exploitables.

    Cest dans ce cadre que se prsente notre projet de fin dtudes intitul Dveloppementet intgration dun module IPS dans un systme dinformation ralis au sein de la socitAxelaris.

    Dabord, nous avons commenc par une premire partie dans laquelle nous avons pr-sent le cadre de ce projet, outre nous avons fait une tude sur le systme de supervisionAlienvault. Puis, nous avons dtaill la partie conceptuelle. Enfin, nous avons terminpar la ralisation dans laquelle nous avons dcrit lenvironnement de tarvail ralis etnous avons illustr le fonctionnement de notre IPS.

    Malgr les problmes que nous avons rencontr durant notre travail, en particulier ladifficult de familiarisation avec Alienvault qui parait en premier instant trs compliqupuisquil renferme beaucoup doutils open source pour amliorer la dtection dintrusionset une base de donnes trop complexe. Ce projet nous a t profitable. En effet, parmi lesapports dont nous avons bnfici, la dcouverte de nouveaux langages tels que Python etPHP5. Ces langages nous ont t considrablement enrichissants. Nous avons galementappris communiquer avec les encadrants et travailler en groupe en partageant lestches en grant le temps avec discernement.

    Dautres part, ce projet nous a galement offert lopportunit dacqurir une meilleuremaitrise des diagrammes UML ainsi damliorer nos comptences de rdaction de rap-port.

    En effet, une perspective de ce projet sera de russir dvelopper, pour ce module,une interface graphique purement en python pour que nous puissions lintgrer dansnimporte quel systme.

    En fin, nous esprons que ce projet soit le premier pas vers la vie professionnelle et unguide pour ceux qui sintressent la matire.

    51

  • Annexe

    52

  • 7 Annexe

    7.1 Intgration du module IPSAprs avoir install Alienvault, nous nous sommes penchs sur le dveloppement du

    module permettant dautomatiser le blocage dune source dalarme.

    Voici ce que nous attendons de notre module :

    Rcuprer ladresse source dalarme

    Stocker cette alarme dans la Black list

    Envoyer la source vers les agents superviss

    Bloquer la source dintrusion

    Le module se compose de trois rpertoires :

    Server IPS

    Agent IPS

    Interface

    Server IPSLe rpertoire Server IPS va tre localis

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

    voici la description des diffrents fichiers :

    syncServer.py : crer les processus de synchronisation (threads)

    init.py : initialiser les variables ncessaire pour la connexion la base de donnes

    ipsDb.py : crer la base de donnes et les tables

    syncThread.py : envoyer les ordres aux agents superviss

    53

  • 7 Annexe

    Figure 7.1: Organigramme des fichiers du Serveur IPS

    Agent IPSLe rpertoire Agent IPS va tre localis dans

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

    voici la description des diffrents fichiers :

    syncAgent.py : excuter les ordres reus

    init.py : initialiser les paramtres ncessaire pour la connexion la base de donnes

    records.py : grer la base de donnes

    serverId.py : ajouter lidentifiant de lagent dans la base du serveur

    54

  • 7 Annexe

    Figure 7.2: Organigramme des fichiers du Agent IPS

    InterfaceLe rpertoire interface sera localis dans

    /usr/share/ossim/www/interface.Il se compose dun ensemble de scripts PHP comme le montre la figure 8.3voici la description des diffrents fichiers : php5 : rpertoire contenant les

    utility.php : contient les fonctions permettant dafficher lentte du tableau et duformulaire

    getMan.php : afficher manual intervention getEvenet.php : manipuler les vnements (bloquer, accepter) getWhite : grer la white list getBlack.php : grer la black list getReport.php : afficher le formulaire generate report

    Include : rpertoire contenant les fichiers ncessaires pour la connexion la BD etle dessin des graphs.

    graph : rpertoire contenant les deux bibliothques (FusionCharts et xml/php charts)

    55

  • 7 Annexe

    report : reprtoire contenant le script generate.php generate.php : gnrer le rapport PDF

    Images : rpertoire des images

    Figure 7.3: Organigramme des fichiers du menu RS IPS

    vider la base de donnesCe 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

  • 7 Annexe

    Menu RS IPS

    Figure 7.4: Interface web : Menu RS IPS

    57

  • 7 Annexe

    7.2 BibliothqueFusion charts, xml/php chartsFusion charts et xml/php charts sont deux outils permettant dafficher des graphes en

    Flash sur une page web.

    EZPDFLorganisation R&OS Ltd a dvelopp une bibliothque gratuite pour la cration la

    vole de documents PDF avec le langage PHP.Cette bibliothque se compose dune classe de base : la classe PDF. Cette dernire a

    rcemment t tendue par la classe EZPDF. Ces classes sont livres avec des polices decaractres disponibles dans le rpertoire /fonts du package.

    anyDBMdbm a t le premier dune famille de moteurs de base de donnes, lorigine crit

    par Ken Thompson et publi par AT&T en 1979. Son nom est lacronyme de databasemanager (gestionnaire de base de donnes). dbm stocke des donnes arbitraires parlutilisation dune seule clef (une cl primaire), dans un conteneur en taille fixe et utiliseles techniques de hachage pour permettre laccs rapide aux donnes via la cl.

    SocketUn socket est une interface entre les processus : en rseau, un socket sert donc

    faire communiquer un processus avec un service qui gre le rseau. Chaque socket a uneadresse de socket. Cette adresse est constitue de deux choses : une adresse IP et unnumro de port. Cest grce la programmation de socket que lon dfinit le modle decommunication. Si le socket a t configur de manire envoyer ou recevoir, cest unmodle Half-Duplex. Sil a t configur de manire envoyer et recevoir simultanment,il sagit dun modle Full-Duplex. tant donn que les sockets sont en fait une interfacede programmation dapplications (API), on peut donc sen servir pour programmer desapplications en rseaux (par exemple, crer une application pour faire communiquerun client et un serveur). Dans le souci de vous encourager faire des recherches surla programmation des sockets, voici un schma illustrant une communication entre unclient et un serveur.

    58

  • Bibliographie & Ntographie

    Bibliographie(1) MARTINET P, Mise en oeuvre dun prototype darchitecture 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

    Ntographie(4) https ://www.alienvault.com : Description dAlienvault, 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/ : Crations des charts, visit le 26-03-2013

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

    (13) https ://www.dropbox.com : Stockage des donnes 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 symbolesBD Base de donnes

    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 Scurit du Systme dInformation

    SA Socit Anonyme

    SAAS Software As A Service

    SI Systme dInformation

    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

    Introduction gnralePrsentation de l'organismeIntroductionDonnes gnralesContexte technologiqueOffres commercialesCloud priv, public ou hybrideOffre service SaaSOffre des services manags

    Conclusion

    tude d'AlienVaultIntroductionPrsentation gnrale de la solution d'AlienVaultPrincipe techniqueArchitecturePr-processing (Alienvault agent)Post-processing (Alienvault server)Le flux de fonctionnement d'Alienvault

    Principe de fonctionnementLa dtectionMthodes de dtection

    L'analyseDfinition de la priorit des alarmesvaluation des risquesCorrlation

    Le monitoringMoniteur de risqueConsole lgalePanneau de contrle

    Avantages et inconvnients majeurs d'AlienvaultConclusion

    Spcification et conceptionSpcificationIntroductionBesoins fonctionnelsBesoins non fonctionnelsDiagramme de cas d'utilisationDiagramme de cas d'utilisation gnralDiagramme de cas d'utilisation de l'interface web

    Conclusion

    ConceptionIntroductionConception globaleDiagramme de classesDiagramme de classes : coeur du moduleDiagramme de classes : interface web

    Schma physique de la base de donnesDiagramme d'activitsDiagramme d'activits : coeur du moduleDiagramme d'activits : Interface web

    Conclusion

    RalisationIntroductionEnvironnement de travailEnvironnement matrielEnvironnement logiciel

    Principe de fonctionnement du moduleServeur IPSPhase de rcuprationPhase de synchronisation

    Agent IPSPhase d'auto identificationPhase d'excution des ordresPhase de sauvegarde

    Interface web : Menu RS IPSArborescence du menuArchitecture du menu

    Conclusion

    Conclusion et perspectivesAnnexeIntgration du module IPSBibliothque