Copie Finalee
Copie Finalee
Copie Finalee
et de la Recherche Scientifique
Département Informatique
Nous e pouvo s pas laisse passe l’o asio de la p ése tatio de e appo t sa s
exprimer nos meilleurs remerciements à tous ceux qui ont bien voulu apporter l'assistance
nécessaire au bon déroulement de ce projet.
Expert réseaux, chef unit IT à la SOTETEL pour avoir dirigé ce travail, ses efforts pour
’i tég e da s l’e vi o e e t, ses e a ues pe ti e tes, et ses o seils judi ieu , pou
sa patience, sa disponibilité, son soutien moral et pour la confiance u’il ’a a o dé. Qu’il
t ouve i i l’e p essio de a plus p ofo de g atitude et ue e t avail soit à la hauteu du
g a d effo t et du te ps u’il ’a o sa é.
Mes remerciements les plus distingués sont adressés aux membres de jury,
À ma chère mère,
À es ch es sœu s, À o che f e,
Pour votre soutient et encouragements, vous occupez une place particulière dans mon
œu .
HLIMI Ghada
Table des matières
Remerciements
Dédicaces
Introduction ................................................................................................................................ 5
Conclusion ................................................................................................................................ 10
Introduction .............................................................................................................................. 12
1. Définitions ............................................................................................................................. 12
Conclusion ................................................................................................................................ 28
Introduction .............................................................................................................................. 30
Conclusion ................................................................................................................................ 46
Introduction .............................................................................................................................. 48
1.1.Intégration........................................................................................................................... 49
Conclusion ................................................................................................................................ 76
Annexe ...................................................................................................................................... 80
Table des figures
AD = Active directory
DHCP = Dynamic Host Configuration Protocol
DNS = Domain name server
FW = Firewall
HIDS = Host intrusion detection system
IDS = Intrusion detection system
IPS = Intrusion prevention system
IT = Information technology
OSSIM = Open source security information management
SI = System information
SIEM = System information event management
SIM = System information management
SEC = Security event correlation
SOC = Security Operation Center
Vlan = Virtual local area network
Introduction Générale
Face à l’augmentation des volumes et à la complexité des données sur lesquelles se base
l’activité d’une société, les entreprises recherchent des méthodes pour gérer leur infrastructure
TIC. Nécessitant d’être à la fois flexibles et évolutives, ces solutions ne doivent pas pour
autant compromettre la sécurité et la fiabilité des données. Pour répondre à cette demande, de
plus en plus d’entreprises se tournent vers une externalisation du stockage de données grâce
aux prestataires extérieurs fournisseurs de data center.
C’est de ce contexte apparaitre les objectifs de développement des systèmes SIEM « system
information évents management » système de management des évènements des ressources
Data center.
Le système de sécurité et de gestion des événements (SIEM) est relativement nouveau dans le
domaine de la technologie de l'information (IT). Les premiers composants des systèmes
SIEM ont commencé à se manifester sous diverses formes entre 10 et 20 ans, mais ont
commencé tout juste à devenir bien intégrés, en trouvant leur pied au sein des organisations.
Le système SIEM est une collection complexe de technologies conçu pour fournir une vision
et une clarté sur le Data center de l'entreprise dans son ensemble, bénéficiant également aux
analystes de sécurité et aux administrateurs informatiques. Comme vous le verrez dans le les
chapitres suivants, vous pouvez tout faire avec un système SIEM, et plus encore. C'est un
1
ajout puissant à l'infrastructure informatique de pratiquement tous les petits, moyens ou
grande entreprise, département ou entité gouvernementale.
Le plan envisagé dans le reste de ce document adopte une démarche répartie en quatre
chapitre :
2
Après, nous présenterons la solution en cours de fonction est les tests effectuer en cours de
stage, mettant en œuvre une phase d'approche de méthodologies de travail.
Et en finir avec une conclusion générale qui résume le travail réalisé dans ce stage.
3
Chapitre 1 :
Présentation de cadre du projet
4
Introduction
Dans ce chapitre introductif, nous commençons par présenter l’établissement d’accueil au
sein duquel notre stage a été accompli, par une description générale, leurs domaines d’activité
et leurs objectifs. Enfin, nous présentons une étude de l’existant qui nous mène à proposer une
solution pour remédier aux problématiques.
CISCO
HUAWEI
NEC
SAGEM
VMware
5
1.3. Réseau « Core » et « Backbone »
Autorisation et authentification.
Communications unifiées et travail collaboratif.
Distribution et mobilité.
2. Organigramme de l’entreprise
SOTETEL comporte cinq départements principaux, chaque département est responsable de
tâches bien précises et relatives à celles réalisées par les autres départements. [1]
6
Figure 2: Organigramme de la SOTETEL
Dans cette section, nous décrivons le réseau informatique de la SOTETEL (voir figure 3).
Le réseau est constitué d’un site principale héberge les principaux serveurs au sein de
département de data center. La communication entre les différentes agences de SOTETEL
est assurée par l’infrastructure MPLS offerte par la Tunisie Telecom. En utilisons des VPN
pour la sécurisation du trafic.
7
Figure 3: Architecture de réseau informatique de la SOTETEL
4. Etude de l’existant
Dans les dernières années, on a assisté à plusieurs incidents liés à la mal gestion des
équipements réseaux à cause d’une mauvaise vérification des configurations ou tout
simplement à cause de la charge importante du travail des administrateurs.
8
Gestion décentralisée : chaque solution de sécurité est gérée à part.
En cas d’incident, pas d’alertes en temps réel.
Pas de moyens pour mesurer leur niveau de sécurité.
Difficulté d’exploitation des logs : Les logs collectés sont de différents formats.
Aucun rapport direct entre les différents logs : Absence de relation logique entre
les logs provenant des différents équipements.
Les responsables de la sécurité informatique ne peuvent pas exploiter
efficacement les données et logs des différentes solutions de sécurité et de
supervision dont ils disposent.
Absence d’outils qui permettent l’inventaire, l’analyse et le suivi des différentes
vulnérabilités des systèmes d’informations de l’entreprise.
Un Data center doit donc maintenir les normes élevées pour assurer l’intégrité et la
fonctionnalité de ses environnements hébergés.
5. Solution proposée
Après avoir étudié et énumérer les problèmes existants, nous constatons qu’il est nécessaire
de recourir à un outil de gestion centralisée qui permet de faciliter la gestion et la sécurité de
notre réseau ainsi que d’améliorer la gestion des ressources, se fait au niveau du Data Center.
Ce gestionnaire est connu sous le nom de SIEM (Security Information and Event
Management). Par conséquent, il est très important d’implémenter un SIEM et ceci non pas
seulement pour assurer la sécurité d’un tel centre mais aussi pour gagner la confiance des
entités avec lesquelles le système interagit.
Collecte les loges à partir des équipements de sécurité (FW, IPS, les serveurs).
Normalisation et l’agrégation des fichiers logs des divers équipements.
Corrélation et le monitoring (temps réel ou différé) des évènements.
Amélioration de la détection des attaques simples et complexes.
Gestion des alertes, des incidents.
Notre solution qui s’intitule SIEM (Security Information and Event Management) grâce à
l’outil OSSIM (Open Source Security Information Management) présente un fort système de
détection d’intrusion et aussi une bonne gestion des logs basée sur la corrélation et
l’évaluation des risques. C’est une solution qui fédère d’autres produits open source au sein
d’une infrastructure complète de supervision de la sécurité.
9
Conclusion
Dans ce chapitre, nous avons commencé par introduire l’organisme d’accueil de ce projet en
présentant les principales architectures constituant le réseau informatique de l’entreprise tout
en insistant sur leurs domaines d’activité et leurs objectifs. Ensuite nous avons énumérée les
principales problématiques ainsi que la solution proposée.
L’objectif du deuxième chapitre sera consacré pour détailler la sécurité des systèmes
d’informations et présenter une étude de la technologie Datacenter.
10
Chapitre 2 :
Etat de l’art
11
Introduction
Dans ce chapitre, nous nous intéresserons dans une première étape à l’étude de la technologie
Data center tout en présentant sa définition, ses composantes, ses avantages...
Dans une deuxième étape, nous allons présenter la définition la notion des SOC et des SIEM
ainsi leurs étapes de fonctionnement. Ensuite, nous ferons une étude comparative entre les
meilleures solutions de management et d’administration des logs. En s’appuyant sur cette
comparaison, nous allons présenter notre choix qu’nous allons adopter pour terminer par
l’étude théorique de ce choix.
Pour certaines personnes, un Datacenter est un endroit (salle, bâtiment…) où l’on entrepose
les serveurs d’une entreprise sous surveillance. D’autres par contre le définissent comme étant
l’environnement qui part du local aux matériels permettant d’assurer la sécurité, la garantie, la
disponibilité 24h/24h des données de particuliers et/ou d’entreprises.
La définition retenue dans le cade de notre étude est celle qui présente le Datacenter comme
étant un centre de traitement de données (data center en anglais). C’est un site physique sur
lequel se trouvent regroupés des équipements constituants du système d’information de
l’entreprise (mainframes, serveurs, baies de stockage, équipements réseaux et de
télécommunications, etc.). Il peut être interne et/ou externe à l’entreprise, exploité ou non
avec le soutien de prestataires. [3]
12
La soutenance de l’infrastructure : il s’agit de l’espace et des équipements
supplémentaires nécessaires pour appuyer les opérations du centre de données y compris
les transformateurs de puissance, à savoir : sources d’alimentation sans coupure (UPS), les
générateurs, les climatiseurs d’air des salles informatiques (CRAC), des unités de
transmission à distance (RTU), les refroidisseurs, système de distribution d’air, etc. Dans
une haute densité d’un centre de données de niveau (c’est-à-dire un maintenable en même
temps en installation), ces infrastructures d’appui peuvent consommer de l’espace 5 à 6
fois plus que l’espace blanc et doivent être prise en compte dans la planification du centre
de données.
Le matériel informatique : cela comprend les racks, câblage, serveurs de stockage,
système de gestion des équipements nécessaire pour offrir des services d’organisations
informatiques et réseau.
Le fonctionnement : dans ce dernier composant, le personnel des opérations s’assure que
le matériel informatiques et infrastructure sont correctement utilisé, amélioré, et si
nécessaire réparé. Dans la plupart des sociétés il y a une répartition des responsabilités
entre les groupes techniques des opérations informatiques et le personnel responsable de
l’installation de soutiens aux systèmes.
13
La disposition des serveurs en allées a également été pensée de manière à répartir la chaleur
qu'ils dégagent.
Serveur performant
Connexion internet haut débit
Investissement nul
Pas de frais d'installation
Pas de frais de maintenance
Utilisation sur mesure
Gain de place
Sécurité maximale
14
Partie 2 : Étude conceptuelle de la centralisation des
journaux
1. Security Operation Center (SOC)
Le Security Operating Center, ou le centre de supervision et d’administration de la sécurité,
désigne une plate-forme dont la fonction est de fournir des services de détection des incidents
de sécurité. [5] Les SOC ont pour rôle de gérer les évènements et incidents de sécurité qui
surviennent sur le SI surveillé. Il doit être capable de les détecter, de procéder à des
investigations afin d’obtenir le plus d’informations possible à leur sujet, puis de les résoudre.
Le SOC peut également donner des préconisations et règles de bonnes pratiques afin d’éviter
que ces incidents se reproduisent. Il permet également de maintenir un haut niveau de sécurité
sur le système d’information qu’il monitore. Les centres de supervision de la sécurité (SOC)
doivent disposer d’outils d’analyse avancés en mesure de collecter et de parcourir rapidement
les données de sécurité pour présenter les problèmes les plus urgents en contexte. Le système
SIEM devient plus per-formant pour aider les analystes de sécurité à travailler plus
efficacement. [6] La figure suivante présente l’architecture d’un SOC.
15
La première activité d’un SOC est la gestion des IDS, et en particulier leur mise en place et
leur intégration au sein d’un SI. Cette intégration consiste à analyser le périmètre que le client
cherche à monitorer, à designer l’infrastructure du SIEM et des IDS qui seront mis en place,
puis à les installer et les configurer afin d’apporter une configuration de base pour les
premières détections. Afin d’apporter un meilleur niveau de détection, le SOC doit également
maintenir les règles des systèmes de détection d’intrusions à jour, tout comme les directives
de corrélation du SIEM mis en place.
2.1. Logs
Un log, aussi appelé journal d’événement, est la notification d’un événement envoyé par une
application, un système, un service ou une machine sur le réseau. La résolution des pannes
nécessite en général d’étudier les logs des applications, équipements réseaux ou autres, ils
permettent donc de comprendre ce qu’il s’est passé et de pouvoir retracer les actions d’un
système. Ils sont donc très importants en informatique, car ils peuvent donner des explications
sur une ou plusieurs erreurs, sur un crash ou une anomalie. Ils nous permettent de comprendre
certains fonctionnements d’un système par exemple, ils retracent la vie d’un utilisateur, d’un
paquet ou d’une application sur le réseau et peuvent aussi notifier une action quelconque. Les
logs sont donc indispensables pour bien comprendre d’où proviennent certains
dysfonctionnements. [8]
16
Figure 5: Architecture log local
Ces événements journaux varient en importance, mais sont tous nécessaires pour obtenir une
image complète de ce qui se passe dans le réseau et à l'intérieur des systèmes d'exploitation
des nœuds. Par défaut, les journaux sont stockés localement, ce qui entraîne de nombreux
inconvénients. Tout d'abord, il est très complexe de gérer chaque équipement de
l’infrastructure séparément. Deuxièmement, les journaux stockés peuvent être supprimés ou
modifiés localement. Si une attaque s’infiltre dans un périphérique réseau ou un serveur, les
journaux, y compris les dossiers sur la violation de la sécurité pourraient être modifiés ou
supprimés. Dans ce cas, l'attaque ne serait même pas remarquée. En troisième lieu, si une
mémoire de l'appareil est endommagée, les journaux locaux pourraient ne pas être accessibles.
Dans ce cas, il devient impossible de trouver la raison de ce dysfonctionnement. Donc La
gestion du journal central et le système d'alerte d'événement peut aider à résoudre ces
problèmes.
17
le pirate de supprimer les logs pour effacer ses traces. La centralisation permet également de
garantir la pérennité des logs, il est nécessaire de ne pas les stocker sur un système en
production qui peut tomber à tout instant car s’il devient injoignable, la récupération des logs
devient plus compliquée alors que, s’ils sont exportés sur une machine disponible, la vitesse
de récupération de ces derniers sera beaucoup plus rapide et le problème sera traité plus
facilement. Donc, il est d'une importance cruciale pour un service informatique d'une
organisation pour être en mesure de suivre efficacement tout état de cause dans le réseau dans
un délai nécessaire par la mise en œuvre d’un système de gestion des évènements « SIEM »
qui permet d'envoyer tous les journaux dans un serveur central
LMS « Log Management System » : un système qui collecte et stocke des fichiers journaux
(des systèmes d'exploitation, des applications, etc.) de plusieurs hôtes et systèmes dans un
seul emplacement, permettant un accès centralisé aux journaux au lieu d'y accéder
individuellement.
SLM / SEM « Security Log / Event Management » : un LMS, mais commercialisé vers les
analystes de sécurité au lieu des administrateurs système. SEM consiste à mettre en évidence
les entrées de journal comme étant plus importantes pour la sécurité que d'autres.
SIM « Gestion de l'information de sécurité » : un système de gestion d'actifs, mais avec des
fonctionnalités pour rejoindre également les informations de sécurité. Les hôtes peuvent avoir
des rapports de vulnérabilité répertoriés dans leurs résumés, les alertes de détection d'intrusion
et d'antivirus peuvent être montrées mappées aux systèmes concernés [10].
SEC « Corrélations des événements de sécurité » : Pour un logiciel particulier, trois tentatives
de connexion échouées au même compte d'utilisateur provenant de trois clients différents, ne
sont que trois lignes dans leur fichier journal. Pour un analyste, il s'agit d'une séquence
particulière d'événements dignes d'investigation, et Log corrélations (recherche de motifs dans
les fichiers journaux) est un moyen d'augmenter les alertes lorsque ces choses se produisent.
SIEM est l'option "Tout au-dessus", et comme les technologies ci-dessus fusionnent en
produits uniques, est devenu le terme généralisé pour la gestion des informations générées par
les contrôles de sécurité et l'infrastructure.
18
3.1. Présentation de SIEM
Les professionnels de la sécurité et les analystes utilisent le système SIEM pour surveiller,
identifier, documenter, et parfois répondre aux affrontements de sécurité. Certaines de ces
sécurités des événements sont évidents, comme les attaques volontaires et malveillantes de
déni de service (DoS) et les éclosions de virus. Le système SIEM peut également identifier
des événements de sécurité plus insaisissables.
De nombreux événements sont si subtils ou obscurcis par des milliers d'événements par
seconde qu'avec l'aide d'un système SIEM puissant et finement réglé, ils iront totalement
inaperçu. Ces événements de sécurité plus insaisissables comportent des violations de la
politique, les tentatives d'accès non autorisées et celles des personnes hautement qualifiées et
ciblées attaquant, mutuellement et furtivement dans son environnement informatique.
Un objectif majeur pour l'analyste de la sécurité utilisant un système SIEM est de réduire le
nombre d'alertes faussement positives, ce qui représente la palette de foin dans le proverbiale
concept de « l'aiguille dans la maquille ». Des systèmes de sécurité moins sophistiqués, tels
que le système de détection d'intrusion (IDS), sont célèbres (ou plus appropriés, infâme) pour
alerter sur de nombreux événements faussement positifs. Ces nombreux faux positifs alertes
gaspillent le temps et l'énergie de l'analyste de sécurité, et souvent l'attention concentrée de
l'analyste, ce qui rend beaucoup plus facile de ne pas tenir compte et de négliger une alerte
positive vraisemblablement plus rare et plus importante.
Il fournit des données pour chaque événement se produisant dans le réseau et agit ainsi
comme un système complet de surveillance de sécurité centralisée.
En plus de cela, l'outil SIEM peut être configuré pour détecter un incident spécifique. Par
exemple, un utilisateur tente de se connecter à un serveur AD. Pour les 3 premières fois,
19
l'authentification a échoué et la 4ème fois qu'elle a réussi. Maintenant, il s'agit d'un incident à
rechercher.
Il existe de nombreuses possibilités. Peut-être qu'une personne essaie de deviner le mot de
passe d'un autre utilisateur et l'a bien compris, ce qui constitue une violation. Ou peut-être si
l'utilisateur a oublié son mot de passe mais l'a bien compris à la fin, etc. C'est là qu’intervient
la Co-relation.
Pour un tel cas, une règle de Co-relation peut être faite de telle sorte que, si un événement
d'échec d'authentification se produit 3 fois consécutivement, suivi d'un succès dans une
période de temps spécifique, l'alerte apparaît.
Cela peut être davantage étudié en analysant les journaux des machines respectives. Donc, la
définition de Co-relation est : "C'est la règle qui agrège les événements en un incident qui est
défini par une application ou un scénario spécifique".
Les SIEM utilisent des étapes de récupération, analyse et gestion de l’information, ce sont la
collecte, la normalisation, l’agrégation, la corrélation, le rapport et la réponse. [11]
La collecte :
Le principe de l’étape de collecte est de fournir au SIEM des données à traiter. Ces données
peuvent être de nature diverse en fonction de l’équipement ou du logiciel, mais aussi être
envoyées de manières tout à fait différentes. On distingue deux modes de fonctionnement :
Mode Actif : Le SIEM possède un ou plusieurs agents déployés sur les équipements à
superviser. Ces agents ont pour fonction de récupérer les informations des équipements et
logiciels de sécurité et de les envoyer au SIEM. Un élément de sécurité qui a été conçu
nativement pour être un agent du SIEM est appelé une sonde.
Mode Passif : Le SIEM est en écoute directe sur les équipements à superviser. Pour cette
méthode, c’est l’équipement ou le logiciel qui envoie des informations sans intermédiaire au
SIEM. [12]
La normalisation :
Les informations collectées viennent d’équipements et logiciels hétérogènes ayant pour la
plupart leurs propres moyens de formater les données. Cette étape permet d’uniformiser les
informations selon un format unique pour faciliter le traitement par le SIEM. Des formats sont
mis au point par IETF pour structurer les informations de sécurité et pouvoir les échanger et
les traiter plus facilement. C’est pourquoi il est plus judicieux de les énuméré. [12]
IDMEF (Intrusion Détection Message Exchange Format) : C’est un standard, défini dans la
RFC 4765, permettant l’interopérabilité entre les systèmes commerciaux, open-source et de
20
recherche. Il est basé sur le format XML et est un format conçu pour définir les évènements et
des alertes de sécurité. Il est également adapté pour le stockage en base de données,
l’affichage et la gestion des informations. [13]
IODEF (Incident Object Description and Exchange Format) : C’est un standard, défini dans
la RFC 5070, représentant les informations de sécurité échangées entre les équipes CSIRTs
(Computer Security Incident Response Teams). Il est basé sur le format XML et est un format
conçu pour transmettre des incidents de sécurité entre les domaines administratifs et les
parties qui ont une responsabilité opérationnelle. Ce modèle de données encode l’information
des hôtes, des réseaux, des services. [14]
L’agrégation :
L’agrégation est le premier traitement des évènements de sécurité. Il consiste en un
regroupement d’évènements de sécurité selon certains critères. Ces critères sont généralement
définis via des règles appelées règles d’agrégation et s’appliquent à des évènements ayant des
similarités. [9]
La corrélation :
La corrélation correspond à l’analyse d’évènements selon certains critères. Ces critères sont
généralement définis via des règles appelées règles de corrélation. Le but de cette étape est
d’établir des relations entre évènements, pour ensuite pouvoir créer des alertes de corrélations,
des incidents de sécurités, des rapports d’activité. La corrélation se différencie sur plusieurs
points. [14]
Auto-apprentissage et connaissances rapportées : Pour pouvoir fonctionner, les moteurs de
corrélation ont besoin d’informations sur les systèmes et réseaux de l’infrastructure. Ces
informations peuvent être collectées automatiquement et/ou saisies manuellement par un
opérateur. [14]
Temps réel et données retardées : Dans certains cas, les évènements bruts sont forgés et
envoyés directement pour être corrélés en temps réel. Dans d’autres cas, les évènements sont
d’abord stockés, et envoyés après un premier traitement (ex : agrégation), leur envoi peut être
alors conditionné. [14]
Corrélation active et passive : La corrélation active a la possibilité de compléter les
évènements reçus en recueillant des informations supplémentaires pour prendre des décisions.
La corrélation passive est une corrélation qui ne peut pas interagir avec son environnement,
elle reçoit des évènements et prend des décisions. [14]
21
Gestion des alertes :
Il y a plusieurs façons pour un SIEM de gérer des alertes, plusieurs d’entre elles peuvent être
utilisés simultanément :
Le « reporting » : Les rapports générés contiennent à la fois une synthèse des alertes et une
vue d’ensemble de la sécurité du système à un instant T (statistiques, intrusions, vulnérabilités
exploitées, classification des attaques).
Le stockage : Les alertes, incidents et rapports peuvent être stockés dans des bases de données
pour pouvoir être analysés ultérieurement par des moteurs de corrélation.
La réponse : Les mécanismes de réponse aux alertes doivent permettre de stopper une attaque
ou de limiter ses effets de façon automatique. La réponse à une intrusion dépend de la
politique de sécurité. La figure 6 présente le mode de fonctionnement des SIEM.
Afin de s’assurer de la bonne implémentation de notre système, il est impératif de passer par
une étape de choix. Dans ce cas, nous avons mené une étude comparative entre les logiciels
22
les plus connus dans la catégorie des SIEM. Dans ce qui suit, nous présentons les
performances de ces derniers.
S’assurant que le marché des SIEM est un marché porteur, les sociétés se pressent de plus en
plus à investir dans des produits permettant la gestion des événements et des informations de
sécurité en temps réel ainsi qu’une meilleure gestion des réseaux.
Des différentes solutions apparaissent, nous citons les trois leaders du secteur qui sont IBM
QRadar, HP ArcSight et Splunk SIEM. Toutes ces solutions n’ont qu’un seul point commun :
un prix élevé. [16]
IBM QRadar
Avantages Inconvénients
• Adaptable pour petite, moyenne ou grande • Capacités de personnalisation limitées
entreprise • Capacité limité d’effectuer le
• Configuration et déploiement simple développement et l’analyse avancé des cas
• Architecture disponible et hautement d’utilisations
évolutives
HP ArcSight
HP ArcSight est un système qui analyse et met en corrélation tous les événements survenant
sur l’infrastructure de l’entreprise chaque ouverture ou fermeture de session, accès à un
fichier, requête vers une base de données. Il permet de hiérarchiser les risques liés à la
sécurité ou aux violations des exigences des règles de conformité. [18]
23
Tableau 2: Avantage et Inconvénients de HP ArcSight
Avantages Inconvénients
• Support étendu pour collecter les logs • Configuration et déploiement complexe des
différents produits et applications
• Support avancé pour la gestion des
menaces, la gestion des fraudes et l’analyse • Courbe d’apprentissage élevée pour les
du comportement analystes et les opérateurs
Splunk SIEM
Splunk SIEM est un système qui fournit la gestion des journaux, la recherche, l’alerte, la
corrélation en temps réel. Il est déployé par les opérations informatiques et les équipes de
soutien d’application pour l’analyse de gestion des journaux, la surveillance et la recherche
avancée. [19]
Avantages Inconvénients
• Dépannage plus rapide • Limitation à 500 MB d’évènements par jour
• Interface unique pour extraire les jours • Surveillance et alerte des évènements
diverses données machine limitées
Le tableau 4 suivant représente une étude comparative sur les principales fonctionnalités des
différentes solutions SIEM propriétaires :
24
Tableau 4: Tableau comparatif des SIEM propriétaire
Configuration et déploiement
rapide
la gestion des informations et des
évènements de sécurité
La gestion et la découverte
d’actifs
La gestion des journaux
La gestion du réseau
Il existe de plusieurs SIEM libres et professionnels. Parmi les plus répandues, reconnues du
moment nous pouvons citer AlienVault OSSIM, PRELUDE et GrayLog.
L’avantage de ces logiciels libres est la gratuité, la disponibilité du code source et la liberté
d’étudier et de modifier le code selon nos besoins et de le diffuser. De plus, il existe une
communauté importante d’utilisateurs et de développeurs qui participent à l’amélioration des
logiciels et apportent une assistance par la mise en ligne des documentations et les
participations aux forums.
AlienVault OSSIM
25
OSSIM est la version Open-Source du SIEM Alienvault Unified Security Management. Cet
outil est fourni sous la forme d’un système d’exploitation complet, basé sur un OS
GNU/Linux Debian Squeeze. Il intègre les applications qui forment le cœur du SIEM, et des
systèmes de détection d’intrusions avec des configurations complètes pour assurer leur
fonctionnement au sein du SIEM. [20]
Avantages Inconvénients
Concepts d’analyse évolués (comparé à Difficulté de mise en œuvre (trop de
certaines solutions commerciales) modules externes : Snort, Nessus,
Adaptations commerciales possibles Ntop, P0f, etc.)
(licence BSD) Manque de documentation
Robustesse des procédés de collecte
des informations
Prelude
Prelude est une solution de supervision de sécurité qui collecte, filtre, normalise, corrèle,
stocke, indexe et archive les informations issues de sources disparates sur un système
d’information. Il peut fournir une vision globale du niveau de sécurité du système et ainsi
prévenir les attaques et les intrusions. [21]
Avantages Inconvénients
Robustesse Peu de fonctionnalités d’analyse
Sécurité Manque de documentation
Extensibilité
Format des alertes unifié (IDMEF,
RFC 4765)
GrayLog2
Graylog2 est une plateforme open source de gestion de journal entièrement intégré pour la
collecte, l’indexation et l’analyse des données. Il permet d’avoir une gestion centralisée des
logs qui seront stockés dans une base de données et gérés via une interface web. Graylog2
26
affiche les logs des équipements dans son interface web, il permet aussi d’effectuer des
recherches sur des messages spécifiques et de générer des histogrammes et des Dashboard.
[22]
Avantages Inconvénients
Robustesse Il n’accepte que le format Sys log
Sécurité Manque de documentation
Intégration simple avec les applications
Java
Le tableau suivant représente une étude comparative sur les principales fonctionnalités des
différentes solutions SIEM Open Source :
La gestion du réseau
Reporting
27
On prendre en compte que notre projet est une première expérience pour le Data center et ces
personnels nous choisissons de prendre part à une solution open source. Permit les open
sources mentionnée OSSIM, elle permet ainsi de gérer de manière centralisée les remontées
d’information de différents outils, de les stocker et les traiter afin de faciliter l’administration
et la gestion de la sécurité pour les administrateurs. Cette solution est un outil très fiable au
niveau de l’administration du système d’information qui combine des outils et des solutions
complètes de surveillance réseau, de sécurité et d’audit sur une seule console
d’administration. De plus, c’est une Plateforme complète basé sur plusieurs outils Open
source très reconnues dans le marché du réseau. OSSIM possède une interface intuitive, riche
en informations et intègre les détails de chaque solution.
Conclusion
Dans ce chapitre, nous avons présenté une étude de la technologie Datacenter dans la
première partie et la deuxième partie de ce chapitre, a été consacrée pour la définition du SOC
et des systèmes SIEM et de la notion de centralisation des journaux, ainsi que la réalisation
d’une étude comparative entre les produits SIEM les plus utilisés, finissant par le choix de la
solution Appropriée à l’accomplissement du notre projet
L’objectif du chapitre suivant sera dédié pour présenter une étude détaillée de l’outil OSSIM
afin de bien justifier notre choix pour la partie implémentation de notre solution.
28
Chapitre 3 :
Étude de l’outil OSSIM
29
Introduction
Dans ce chapitre, nous présentons une étude sur le logiciel OSSIM (Open Source Security
Information Management) afin de justifier notre choix et énumérer ses fonctionnalités, ses
avantages, son architecture et son efficacité.
OSSIM (open source Security information management) est une solution open source
complète, ou plutôt plateforme complète d’administration des réseaux et du management du
système informatique, développée par la société AlienVault et soutenue par une large
communauté de développeurs open source. OSSIM utilise plusieurs produits issus de la même
stratégie (open source) afin d’y intégrer une infrastructure de monitoring en temps réel de la
sécurité du réseau.
De même, il assure les fonctionnalités d’un SEM (Security Event Management) qui consistent
essentiellement à stocker de grandes quantités de fichiers Logs brutes tout en assurant leurs
intégrités et leurs confidentialités à travers des procédés de chiffrements et de signatures
numériques. De plus, il intègre plusieurs outils open source tels que :
OSSIM 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). Le Framework au sens d’OSSIM a 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é du système d’information d’une entreprise.
La solution OSSIM fournit donc par le biais de son Framework un outil administratif qui
permet de configurer et d’organiser les différents modules natifs ou externes qui vont
composer la solution. Le Framework est ainsi constitué des éléments de supervision suivants :
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.
Ces éléments s’appuient sur des mécanismes de corrélation, de gestion des priorités et
d’évaluation des risques afin d’améliorer la fiabilité et la sensibilité des détections au sein de
la solution. [24]
31
Figure 7: Architecture simple d’ossim
32
Le poste traitement : de l’information assuré par l’ensemble des processus interne à la
solution et qui vont prendre en charge l’information brute telle qu’elle est a été collecté
pour ensuite l’analyser, la traiter et en fin la stocker dans une base de données.
Ces informations collectées par les détecteurs et les moniteurs sont spécifiques et encore
partiels et ne représentent qu’une petite partie de la quantité d’information existante sur le
réseau de l’entreprise étudié. OSSIM a donc la solution : c’est la Corrélation.
En effet, le mécanisme de corrélation peut donc être vu comme la possibilité d’utiliser les
informations remontées par les détecteurs en utilisant un nouveau niveau de traitement, de
compléter et d’améliorer le niveau d’information. Son but est de rendre cette remontée
d’information le plus efficace possible par rapport à la quantité d’information disponible
sur le réseau de l’entreprise. La figure 8 illustre les deux étapes de fonctionnement. [24]
Nous remarquons qu’il existe différentes bases de données permettant la sauvegarde des
informations corrélées (intermédiaire).
33
EDB : La base de données des événements (la plus grande), stockant toutes les alarmes
individuelles.
KDB : La base de données des connaissances, sauvegardant les configurations établies
par l’administrateur en charge de la sécurité.
UDB : La base de données des profils, stockant toutes les informations du moniteur de
Profile.
1. Les détecteurs (quels qu’ils soient) traitent les événements jusqu’à ce qu’une alerte
soit identifiée soit par signature, soit par la détection d’une anomalie.
2. Le collecteur reçoit les alertes au travers des différents protocoles disponibles (SNMP,
etc.)
3. Le parseur normalise ces alertes et les stocke dans la base de données des événements
(EDB)
34
4. Le parseur se charge également de l’affecter des priorités aux alertes en fonction des
politiques définie dans le panneau de contrôle ainsi que de toutes les informations
systèmes dans les inventaires des équipements attaqués.
5. Le parseur évalue aussi les risques immédiats inhérents à l’alerte et remonte si besoin
une alarme au niveau de panneau de contrôle.
6. Les alertes une fois priorisées sont envoyées à chaque processus de corrélation, qui
met à jour leurs variables d'état et renvoie éventuellement de nouvelles alertes aux
informations plus complète ou plus fiable. Ces nouvelles alertes sont renvoyées au
parseur pour être à nouveau stockées, priorisées et évaluées par rapport aux politiques
de risques et ainsi de suite, …
7. Le parseur de risque affiche périodiquement l'état de chaque index de risque selon la
méthode de calcul CALM (Compromise and Attack Level Monitor).
8. Le panneau contrôle quant à lui remonte les alarmes les plus récentes, met à jour l'état
de toutes les métriques qu'il compare à leurs seuils, et envoie alors de nouvelles
alarmes ou effectue les actions appropriées selon les besoins.
9. Depuis le panneau de contrôle, l'administrateur peut également voir et/ou établir un
lien entre tous les événements qui se sont produit à l'heure de l'alerte à l'aide de la
console d’investigation.
10. L'administrateur peut enfin vérifier l'état de la machine impliquée en utilisant les
consoles d’utilisation, de profil ou de session. [24]
3. Fonctionnalités d’OSSIM
Dans cette partie, nous présentons au mieux les différentes possibilités offertes par la solution
OSSIM. Les fonctionnalités d’OSSIM peuvent être représentées de manière simple et
graphique en un découpage sur 9 niveaux tel que le montre la figure 10.
35
Figure 10: niveau de fonctionnalité
36
système doit apprendre un modèle de référence qu’il considère comme une situation normale
et remonter une alerte quand le comportement dévie de ce modèle de référence.
Cette nouvelle fonctionnalité opposée au principe de détection par modèles fournit un point
de vue différent mais complémentaire de la détection par modèles. Par exemple, dans le cas
d’une nouvelle attaque pour laquelle il n'y a toujours aucune signature qui produirait une
anomalie évidente pourtant ignorée par les systèmes de détection de modèle. De même, dans
le cas d’un ver qui aurait été introduit sur le réseau de l’entreprise, une attaque de Spamming,
et même l'utilisation des programmes de P2P qui produiraient un certain nombre de
connections anormales qu’il est facile de détecter.
Une utilisation des services dont la source ou la destination ne serait pas normale.
Une utilisation à des heures anormales.
Une utilisation excessive du trafic ou des connections
Une copie anormale de fichiers sur le réseau interne
Un changement de système d'exploitation sur une machine
Etc …
La remontée de ces informations est prise en tant qu'information additionnelle qui complète
les alertes traditionnelles par modèles, cela permet de mieux évaluer les alertes et donc de
différencier celles qui pourraient avoir des conséquences plus importantes (plus risquées).
[22]
De cette façon, il est donc possible d’observer tous les événements de sécurité pendant une
période donnée (qu’ils viennent d'un routeur, d’un firewall, d’un IDS, ou d’un serveur) sur le
même écran et dans le même format. La normalisation est donc une composante essentielle et
pour cela OSSIM s’appuie sur le standard IDMEF. L’utilisation de ce standard est également
vivement encouragée par la communauté de développeur d’OSSIM et bon nombre d’acteurs
de la sécurité en général.
L’IDMEF est un standard établit par l’IETF. Le modèle de données de l’IDMEF est une
représentation orientée objet au format XML des alertes envoyées par les équipements de
détection vers OSSIM. Les équipements qui vont émettre les alertes sont divers et variés.
Ils n’ont malheureusement pas toujours accès aux mêmes informations systèmes et n’ont pas
non plus le même niveau de détails. C’est pour cela que le standard a été mis au point en se
basant sur un modèle de données flexible, à savoir un modèle objet. Le modèle objet, en effet,
permet facilement l’extension des détails des informations via l’agrégation et l’héritage. En
fait, si l’on considère une alerte remontée à OSSIM par un équipement.
Soit une machine qui tourne sous le système UNIX avec un serveur web Apache. Lorsque,
OSSIM reçoit une alerte pour cette machine au sujet d'une attaque sur Microsoft IIS, L’alerte
devrait se voir attribuer une priorité basse. Autre exemple, si un utilisateur établit une
connexion suspecte à un serveur, le système devrait :
Lui accorder une priorité maximum si l'utilisateur est externe au réseau et attaque la
base de données de client.
Lui accorder une priorité basse si l'utilisateur est interne au réseau et attaque une
imprimante réseau.
Ignorer si l'utilisateur est quelqu'un qui test normalement des serveurs de
développement. [22]
38
Nous nous apercevons que dans la figure 11 que la priorité d'une alerte dépend donc de la
topologie et de l'inventaire des systèmes de l’entreprise.
Les processus de gestion des priorités dans OSSIM sont définis au niveau du Framework dans
lequel il est possible de configurer les éléments suivants :
39
Évaluation de la fiabilité de chacun alerte.
Définition d'alarme.
Le risque est caractérisé par son impact et son degré d’occurrence. La figure 12 présente
l’évaluation des risques.
Traditionnellement, l'évaluation des risques est concernée par des risques intrinsèques, ou des
risques latents en d'autres termes, des risques qu'une entreprise ass ume en vertu à la fois des
équipements qu'elle possède afin de développer ses affaires mais également des menaces
circonstancielles liées à ces équipements. Le poids d’un risque peut être corrigé par un
dispositif de maîtrise des risques (DMR). OSSIM tient lieu ici de DMR. La figure 13 suivante
présente la mesure de risque. [22]
40
Figure 13: La mesure de risque
Grâce aux possibilités de contrôle en temps réel qu’offre OSSIM, il est possible de mesurer le
risque lié à la situation actuelle en temps réel. Dans ce cas, la mesure du risque est pondérée
par les dommages qu'il produirait et la probabilité que la menace se produise au moment
présent. Cette probabilité est en fait un dérivé de l'imperfection des sondes et s'avère n'être
rien de plus que le degré de fiabilité des sondes qui détectent une potentielle intrusion en
cours.
Le risque immédiat peut donc être définit par l'état de risque produit quand une alerte est
reçue et évaluée instantanément comme une mesure des dommages qu'une attaque pourrait
produire, pondérée par la fiabilité du détecteur qui a remonté l’information. OSSIM calcule le
risque immédiat de chaque événement reçu, et utilise cette mesure objective pour évaluer
l'importance de l'événement en termes de sécurité. OSSIM utilise cette mesure seulement pour
évaluer la nécessité d’agir. [22]
La corrélation est au cœur de la solution OSSIM. Les informations collectées par les
détecteurs et les moniteurs sont spécifiques et encore partiels. Elles ne représentent qu’une
petite partie de la quantité d’information que nous souhaiterions obtenir au final.
Le mécanisme de corrélation peut donc être vu comme la possibilité d’utiliser les
informations remontées par les détecteurs et, en utilisant un nouveau niveau de traitement, de
compléter et d’améliorer le niveau d’information. Le but étant de rendre cette remontée
d’information le plus efficace possible par rapport à l’étendue de la quantité d’information
disponible sur le réseau d’entreprise.
41
Le mécanisme de corrélation est en quelque sorte un moyen de gommer un certain manque de
fiabilité ou une sensibilité insuffisante au niveau des détecteurs. En fait, si l’on voulait obtenir
un maximum d’efficacité au niveau des détecteurs, il faudrait imaginer un détecteur capable
de capter tous les événements disponibles sur le réseau. Il lui faudrait ensuite les stocker et les
afficher. Etant donné le volume des informations qui transitent sur un réseau d’entreprise,
cette solution n’est tout simplement pas envisageable. [22]
Nous retrouvons également l'un de ces deux éléments : alertes ou indicateurs. Les fonctions
de corrélation deviennent en fait de nouveaux détecteurs et moniteurs (voir figure 14).
42
Fournir la capacité de lier des détecteurs et des moniteurs de manière récursive pour
cré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 la sécurité.
Pour atteindre ces objectifs, OSSIM utilise plusieurs méthodes de corrélation très différentes,
basées sur les deux principes suivants :
Concentrées sur des attaques connues et détectables qui relie les modèles et les
comportements connus qui définissent une attaque en utilisant des règles mises en application
par un état de référence. L'idée de base pour la détection d’une séquence par modèle est
simple. Il suffit juste de créer une liste de règles. OSSIM utilise évidemment des séquences
plus complexes dans lesquelles sont corrélées les alertes produites par des signatures avec le
comportement caractéristique d'une attaque spécifique.
Cette méthode utilise une approche opposée, mettant en application des algorithmes qui
essayent de détecter des situations risquées en utilisant l'analyse heuristique. Cette méthode
permet de compenser les imperfections de la corrélation par séquences d’événements en
détectant des situations sans connaître ou montrer les détails. Ceci est utile pour détecter des
attaques inconnues et montrer une vue générale de l'état de la sécurité pour un grand nombre
de systèmes. Pour cette méthode, OSSIM met en application un algorithme heuristique simple
en utilisant l'accumulation d'événements (CALM) afin d'obtenir un indicateur ou un
instantané de l'état général de la sécurité du réseau.
Dans ce processus l’objectif premier est d'obtenir le risque immédiat tout d’abord puis une
valeur que l’on pourrait définir comme le risque accumulé. En fait cette méthode de
corrélation permet d’obtenir une sorte de « thermomètre » des situations à risque, et ce, sans
jamais connaître aucun détail au sujet des caractéristiques du problème. Cette méthode fournit
donc une vue globale de la situation. Elle permet également de détecter les modèles possibles
que d'autres systèmes de corrélation pourraient ne pas voir, soit parce que les attaques sont
inconnues, soit à cause d’une certaine imperfection.
o Algorithme CALM
43
CALM (Compromise and Attack Level Monitor) est un algorithme d'évaluation qui emploie
l'accumulation d'événements et leur rétablissement dans le temps. En entrée, il récupère un
volume élevé d'événements, et en sortie il fournit un indicateur unique de l'état général de la
sécurité. Cette accumulation est valable pour n'importe quel objet sur le réseau (n'importe
quelle machine, groupe de machines, segment de réseau, etc.) que l’on souhaite surveiller.
CALM est donc prévu pour la surveillance en temps réel, de ce fait l’algorithme doit accorder
de l’importance aux événements les plus récents et jeter les plus vieux.
La Corrélation Croisée :
Ce procédé permettra d’augmenter la priorité d’une alerte Snort lorsque l’attaque définie
par celle-ci aura été découverte comme possible par Nessus. Les associations entre les
alertes de Snort et les règles de Nessus sont affichées dans la console d’administration
d’OSSIM. [24]
45
Conclusion
Dans ce chapitre, nous avons effectué une étude une sur le logiciel OSSIM tout en présentant
ses principes de fonctionnement, son architecture, ses avantages et ses inconvénients. Nous
commencerons le chapitre suivant par la mise en place de notre solution OSSIM. Ensuite,
nous détaillerons l’étude pratique et la stratégie de mise en place de notre solution.
46
Chapitre 4 :
Réalisation du projet
47
Introduction
Dans ce chapitre, nous présentons la réalisation et la validation de l’OSSIM comme la
solution la plus adéquate au Data center de SOTETEL. Pour s’y faire, nous allons aborder
l’étude pratique notre projet. Nous allons présenter tout d’abord l’environnement matériel et
logiciel de travail de notre projet. Ensuit nous allons présenter la stratégie de mise en place de
l’OSSIM. Nous clôturons ce chapitre par la présentation des différents tests afin de valider
notre solution et voir ses effets sur le Data center de l’entreprise.
Ensuite, nous installons des systèmes de détection d’intrusion HIDS dites « OSSEC » qui
contrôle les activités des diff érentes machines. La figure 16 résume l’installation des OSSEC
dans les diff érentes machines.
48
Figure 16:Architecture cible de la solution
1.1. Intégration
L’intégration du serveur, qui permet de faciliter la gestion et la sécurité de notre réseau ainsi
que d’améliorer la gestion des ressources, se fait au niveau du Data Center.
2. Environnement du travail
Nous présentons dans cette partie l’environnement matériel et logiciel qui nous a permis de
réaliser notre projet.
49
Marque Hp
Processeur Intel Core I5
Mémoire ram 8gb
Disque dur 500 go
S st e d’e ploitatio Windows 10
50
Tableau 9: Tableau des logiciels utilisés
51
Figure 18: Mode d’installation d’OSSIM
A ce stade, nous pouvons configurer la carte réseau. Il faut utiliser une adresse IP avec accès à
Internet pendant le processus d’installation. Cette adresse IP sera utilisée par l’interface de
gestion d’OSSIM dans notre cas l’adresse est 192.168.43.110 et le masque de réseau est
255.255.255.0. Comme le montre la figure 19 suivante :
Ensuite, il faut mettre l’adresse IP de la passerelle par défaut dans notre cas est 192.168.43.1
(voir figure 20).
52
Figure 20: Adresse IP de la passerelle
Une fois que l’installation est terminée, il faut entrer le login et le mot de passe définie lors de
l’installation pour accéder à OSSIM (voir figure 21).
Nous configurons par la suite le serveur OSSIM en éditant le fichier de format XML
/etc/ossim/server/config.xml/ pour modifier certains paramètres comme se suit :
53
Le nom du Framework : AlienVault
L’adresse IP du Framework OSSIM, qui est installé sur la même machine que le
serveur, est : 127.0.0.1 ou local host.
Le port sur lequel écoute le Framework OSSIM, par défaut c’est le port 40003
OSSIM offre un tableau de bord intéressant avec une variété de représentations des différents
résultats collectés par l’agent. Dans le tableau de bord, nous trouvons des graphes résumant
l’état global du système comme indique la figure 23.
54
Figure 23: Tableau de bord d’OSSIM
Ces graphes présentent l’état global du réseau. Nous trouvons donc la courbe qui indique le
nombre d’évènements collecté par intervalle du temps ainsi que l’état des alarmes et des
évènements qui se sont produits récemment sur le réseau. Et, nous trouvons l’état des
évènements produits par sonde. Finalement, nous remarquons des statistiques sur le top 10
évènements selon leurs types et leurs catégories.
55
,
.
Pour ajouter un nouvel hôte, nous cliquons sur new et nous définissons les informations de
l’hôte à ajouter (nom, IP adresse, asset value, os, modèle, …) puis nous cliquons sur OK
comme le montre la figure 25 suivante :
56
Figure 25: Ajout d’un nouvel hôte
57
Pour la détection des alertes, nous utilisons des logiciels de détection des alertes pour savoir
l’endroit de l’affichage des informations à détecter sur la plateforme OSSIM (Figure 26).
Donc, nous trouvons l’interface de visualisation des alertes et menaces détectées en temps réel
par les logiciels de détections correspondantes (OSSEC, Snort,. . .).
Dans la figure 26, nous pouvons avoir une idée sur l’affichage des historiques des alertes et
des attaques survenues sur le réseau, avec les adresses source et destination correspondantes
ainsi que le degré de risque de chaque évènement et sa priorité. De plus, OSSIM offre la
possibilité à l’administrateur de gérer en temps réel les détections d’intrusion à travers son
interface real time. D’autre part, nous pouvons sélectionner le choix du plugin (Figure 27) à
utiliser pour filtrer l’affichage de ces alertes, présenté par la figure 28.
58
Figure 28:Affichage des évènements en temps réel pour le plugin syslog
La plateforme OSSIM nous permet d’élaborer des rapports d’informations concernant les
équipements réseaux et système, tout en sauvegardant dans sa base de données les différents
logs des utilisateurs de ce réseau. Les rapports peuvent être affichés sous format PDF ou
HTML.
En effet, nous avons la possibilité d’avoir un rapport sur un hôte bien définit ce qui nous
permet de savoir les informations sur l’hôte déjà choisi avec leurs adresses IP, leurs systèmes
d’exploitation et le niveau de leurs priorités et les vulnérabilités si existe. D’autre part nous
avons aussi la possibilité d’avoir une vision claire sur les alarmes et les incidents présentés
dans un fichier sous format PDF qu’on peut le visualiser, télécharger ou l’envoyer par mail
comme le montre la figure 29 suivante :
59
Figure 29: Génération des rapports sous OSSIM
- Les événements détectés par OSSIM : Top 10 des machines attaquées, Top 10 des
machines attaquantes, Top 10 des ports utilisés.
- Les alarmes générées.
- La base des vulnérabilités et des menaces qui touchent diff érents services (Apache,
IIS, SMTP, FTP.. ), diff érents équipements de marques diff érentes (Cisco, Juniper,
Fortinet. . . ), les bases de données, les systèmes d’exploitation, . . . .
Ainsi dans un rapport, nous trouvons tous les logs des utilisateurs avec les évènements subits
et leurs détails, comme le présente la figure 30.
60
Figure 30 : Les logs des utilisateurs du réseau
61
Comme son nom l’indique, la base documentaire fournit un accès pour les utilisateurs aux
documents rédigés ou fournis comme solutions aux différents incidents. Un document peut
être lié à un actif, groupe d’actifs, ou à un événement. Il peut aussi être affecté par utilisateur
ou groupe d’utilisateurs. Les documents peuvent être :
OSSEC est une application de détection d’intrusion et plus précisément un HIDS (Host
Intrusion Detection System). De plus, OSSEC est utilisé pour détecter également des attaques
comme les rootkits, les scans de ports et analyse les logs du système, des applications et des
services. Donc, il faut installer et configurer OSSEC dans les différentes machines de notre
architecture réseau pour détecter de différentes attaques qui visent notre réseau.
Inconvénients : Agrégation de mails pas toujours respectée, Peut générer beaucoup de mails.
Pour ajouter un agent OSSEC, dans l’interface graphique d’OSSIM, nous cliquons sur
Environnent ->Detection->HIDS->Agents ->add agent. La figure 32 montre l’ajout d’un
agent OSSEC.
62
Figure 32 : Ajout d’un Agent OSSEC
63
Figure 34 : lancement Manager Agent
64
3.2. Installation, Configuration et Intégration du SNORT avec OSSIM
Snort est un système de détection d’intrusion réseau, capable d’eff ectuer l’analyse du trafic en
temps réel et de la journalisation de paquets sur des réseaux IP.Il utilise un langage de règles
flexible pour décrire le trafic qu’il devrait collecter ou laisser passer, ainsi qu’un moteur de
détection qui utilise une architecture modulaire de plugins.Les règles Snort étant basées sur la
signature des paquets illégitimes, le moteur de Snort doit être capable d’analyser le contenu
des flux réseaux. Afin de réaliser cette opération, Snort dispose donc d’un ensemble de
décodeurs lui permettant d’analyser intrinsèquement le contenu des flux.Les décodeurs
accessibles sont :
TCP
UDP
ICMP
IP
Snort est assez complet en terme de détection d’intrusion réseau et largement reconnu par les
professionnels de la sécurité informatique. Son architecture axée autour de sa propre base de
données nous a semblé intéressante à mettre en œuvre au sein de la solution OSSIM.
65
Figure 36:configuration des interfaces réseaux
Ensuite on redémarre l’interface réseau en vérifiant que LRO et GRO sont désactivés.
Puis il faut télécharger et installer la dernière version de DAQ (Data AcQuisition li-brary) à
partir du site Web Snort. Les étapes ci-dessous utilisent wget pour télécharger la version 2.2.2
de DAQ, qui est la dernière version au moment de la rédaction de ce rapport.
66
3.2.1.3. Installation de Snort
Une fois toutes prérequis sont installées, nous sommes prêts à télécharger la base de données
Snort, à compiler, puis à installer. L’option --enable-sourcefire donne Packet Performance
Monitoring (PPM) , qui nous permet de surveiller les performances des règles et des pré-
processeurs, et construit Snort de la même manière que l’équipe Snort :
Après l’installation nous allons tester Snort en exécutant la commande sudo Snort, en la
passant de l’indicateur -V (qui indique à Snort de vérifier tous ces fichiers de configuration).
67
4 . Tests de la solution
Après le déploiement d'OSSIM, il est très important de tester la capacité de la solution à
détecter les attaques pour s’assurer de son bon fonctionnement, par conséquent, nous avons
défini un environnement de test. Nous avons donc lancé une attaque en utilisant la machine
kali Linux « 192.168.43.239» contre une machine cible Windows 10 « 192.168.43.104 ».
68
OSSIM a généré de son côté une alarme, après que l'attaque consistant en tentatives de
connexion a échoué au système.
69
Après le lancement d’une attaque scan Nmap, nous remarquons l’affichage d’une alerte
détectée par la sonde Snort au niveau d’OSSIM. La figure suivante illustre les caractéristiques
cette alerte.
De même, OSSEC détecte cette attaque et affiche une alerte. La figure 42 présente les
caractéristiques de cette alerte OSSEC.
70
Pour lancer un scan de vulnérabilité nous devons aller sous vulnérabilités, puis appuyer sur
«New scan job ». La figure 43 décrit le lancement d’un scan.
Le scan peut être programmé de façon périodique. Ensuite, nous choisissons le ou les hôtes à
scanner, ou les réseaux à scanner, comme indique la figure ci-dessous.
71
Pour valider notre scan, nous cliquons sur l’icône New Job. Les résultats de scan seront
affichés une fois que ce dernier est terminé comme le décrit la figure 45.
72
Figure 46: Les hosts sélectionnés pour le scan Nmap
Les résultats du scan (Figure 47) sont ensuite affichés présentant les détails suivants :
• Adresse IP de l’host.
• Hostname.
• Le type de système d’exploitation.
• Les services héberges.
• Les ports ouverts.
73
5.2 Supervision par Nagios
Nagios est un outil open source reconnu dans le monde de la supervision, il permet une
supervision active et passive des serveurs, des équipements réseaux et surtout des services
divers et variés. Nous allons donc présenter quelques fonctionnalités de Nagios d’après ce
que nous avons récupéré comme informations concernant l’hôte 192.168.43.104 (Figure 48)
sur la plateforme d’OSSIM. L’accès aux informations d’un hôte ou d’un service possible par :
• Service détail, puis en cliquant sur le nom d’un hôte ou d’un service.
• Host détail, puis en cliquant sur le nom d’un hôte.
• Status Grid, puis en cliquant sur le nom d’un hôte ou d’un service.
La figure 48 présente les informations d’un service d’un hôte donné (l’hôte Monitor
192.168.43.104), son état (curent status), la date de la dernière vérification (last check time),
ou dernière modification (last state change). En haut à gauche se trouve un cadre présentant
des liens vers les éléments de rapport pour ce service.
Dans cette étape, les informations sur les états d’hôtes et services sont présentées sous forme
d’histogramme. L’élément trends (tendance), présente sous forme d’histogramme à barres les
diff érents états d’un hôte et d’un service sur une période de temps donnée. Les pourcentages
relatifs à chaque état sur cette période de temps sont inscrits à droite du diagramme. En
74
première étape, nous choisissons le type de rapport. En deuxième étape, selon le choix de
l’étape précédente, nous sélectionnons l’hôte ou le service désiré. Et nous validons les
diff érents paramètres de rapport et nous cliquons sur Create Report pour crée un rapport des
informations. Enfin, nous obtenons le rapport suivant présenté par la figure 49.
Après avoir un rapport détaillé, nous l’interprétons comme suit : les dates de changement
d’état (ou de redémarrage du programme Nagios) sont représentées par l’abscisse du graphe.
Les noms des diff érents états (la valeur de l’ordonnée définit la hauteur de la barre de
l’histogramme) défini par l’ordonné du graphique. À droite du graphique, se trouvent les
pourcentages avec la correspondance en unité de temps. Aussi, Nagios nous donne la
possibilité d’avoir un résumé sur les états des hôtes et tous les groupes des hôtes (Figure 50).
75
Figure 50: Contrôle de la disponibilité des hôtes
Conclusion
Dans ce dernier chapitre, nous avons détaillé l’étude pratique et la stratégie de mise en place
de l’OSSIM. Et nous clôturons ce chapitre par la présentation des différents tests afin de
s’assurer du bon fonctionnement de la solution.
76
Conclusion générale
La sécurité du réseau informatique est considérée comme une activité stratégique et
primordiale pour le développement d’une entreprise quel que soit son domaine
d’activité. Cependant, vu la taille importante du réseau, La SOTETEL a opté pour
une approche centralisée qui consiste à mettre en place un gestionnaire de sécurité
central plus connu sous le nom de SIEM. Cette solution permet de collecter et
d’analyser les logs des diff érents équipements du réseau et sécurité afin d’identifier
les menaces et les alertes pour les traiter dans les plus brefs délais.
Au cours de ce projet, nous avons essayé de concevoir et de mettre en place une solu-
tion SIEM open source qui permet de sécuriser le réseau de Datacenter. Cette solution
se base sur OSSIM développé par la communauté AlientVault. Nous avons essayé de
l’adapter aux spécificités et aux contraintes du réseau de l’entreprise en intégrant un
certain nombre d’outils open source. En eff et, nous avons mis en place une solution
OSSIM basique à laquelle nous avons intégré un ensemble de plugins pour améliorer
son fonctionnement. Ces plugins comportent un outil de découverte du réseau, des
détecteurs de vulnérabilités, d’anomalies et de disponibilités, des analyseurs de trafic
temps réel, un NIDS Snort, des HIDS et des sondes Syslog .
77
Références bibliographiques
[2] : THÈSE réalisé par [ÉRIC LUNAUD NGOUPÉ] le [05-juin 2015] URL :
fevrier-2018]
[3] : https://www.lebigdata.fr/definition-data-center-centre-donnee
[4] : http://datacenter.fr/caracteristiques-data-center.php
[9] : Security Information and Event Management (SIEM) Implementation: Auteurs: DAV I
DR. MILLER, SHON HARRIS, ALLEN A. HARPER, STEPHEN VANDYKE, CHRIS
BLASK, 2011, Edition McGraw-Hill, ISBN: 978-0-07-170108-2
[10] : Gabriel, R. et al. Analysing Malware Log Data to Support Security Information and
Event Management: Some Research Results. First International Conference on Advances in
Databases.
[11] : Les SIEM (Security Information and Event Management) : Gestion de la sécurité
centralisée N. Cherriere, G. Montassier, R. Picard et E. Thuiller, Sujet R1
78
[13] : http ://www.ietf.org/rfc/rfc4765.txt
79
Annexe
Zimbra
Configuration reseau
1. vim /etc/network/interfaces
1. allow-hotplug eth0
2. iface eth0 inet dhcp
1. allow-hotplug eth0
2. iface eth0 inet static
3. address 192.168.1.X
4. netmask 255.255.255.0
5. gateway 192.168.1.1
6. dns-nameservers 127.0.0.1
7. dns-nameservers 8.8.8.8
1. vim /etc/hosts
2. 127.0.0.1 localhost
3. 188.166.153.117 zcs-886.zimbra.io zcs-886
1. reboot
80
2. Reading package lists... Done
3. Building dependency tree
4. Reading state information... Done
5. The following NEW packages will be installed:
6. dnsmasq
7. 0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
8. Need to get 15.9 kB of archives.
9. After this operation, 71.7 kB of additional disk space will be used.
10. Do you want to continue? [Y/n] y
1. vim /etc/dnsmasq.conf
2. server=8.8.8.8
3. listen-address=127.0.0.1
4. domain=zimbra.io
5. mx-host=zimbra.io,zcs-886.zimbra.io,0
6. address=/zcs-886.zimbra.io/188.166.153.117
81
3. ; <<>> DiG 9.10.3-P4-Ubuntu <<>> zcs-886.zimbra.io
4. ;; global options: +cmd
5. ;; Got answer:
6. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56775
7. ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
8.
9. ;; OPT PSEUDOSECTION:
10. ; EDNS: version: 0, flags:; udp: 1280
11. ;; QUESTION SECTION:
12. ;zcs-886.zimbra.io. IN A
13.
14. ;; ANSWER SECTION:
15. zcs-886.zimbra.io. 0 IN A 188.166.153.117
16.
17. ;; Query time: 0 msec
18. ;; SERVER: 127.0.0.1#53(127.0.0.1)
19. ;; WHEN: Thu Jan 11 13:09:32 UTC 2018
20. ;; MSG SIZE rcvd: 62
1. cd zcs-NETWORK-8.8.6_GA_1906.UBUNTU16_64.20171130041047
1. ## ./install.sh -l
2. /tmp/license.xml
3. Operations logged to /tmp/install.log.luSct9Pm
4. Checking for existing installation...
5. zimbra-chat...NOT FOUND
6. zimbra-drive...NOT FOUND
7. zimbra-imapd...NOT FOUND
8. zimbra-network-modules-ng...NOT FOUND
9. zimbra-rpost...NOT FOUND
10. zimbra-ldap...NOT FOUND
11. zimbra-logger...NOT FOUND
12. zimbra-mta...NOT FOUND
13. zimbra-dnscache...NOT FOUND
14. zimbra-snmp...NOT FOUND
15. zimbra-store...NOT FOUND
16. zimbra-apache...NOT FOUND
17. zimbra-spell...NOT FOUND
18. zimbra-convertd...NOT FOUND
19. zimbra-memcached...NOT FOUND
20. zimbra-proxy...NOT FOUND
82
21. zimbra-archiving...NOT FOUND
22. zimbra-core...NOT FOUND
23.
24. IMPORTANT-READ CAREFULLY: THE TERMS OF THIS END USER LICENSE AGREEMENT ("EULA")
WILL GOVERN YOUR USE OF THE SOFTWARE. BY DOWNLOADING, INSTALLING, OR USING THE
SOFTWARE, YOU (THE INDIVIDUAL OR LEGAL ENTITY) ARE (1) REPRESENTING THAT YOU ARE
OVER THE AGE OF 18 AND HAVE THE CAPACITY AND AUTHORITY TO BIND YOURSELF OR THE
LEGAL ENTITY, AS APPLICABLE, TO THE TERMS OF THIS EULA AND (2) AGREEING ON BEHALF
OF YOURSELF AND/OR AS AN AUTHORIZED REPRESENTATIVE OF THE LEGAL ENTITY, AS
APPLICABLE, TO BE BOUND BY THIS EULA. IF YOU DO NOT AGREE TO THE TERMS OF THIS EULA,
YOU MUST NOT DOWNLOAD, INSTALL, OR USE THE SOFTWARE.
25.
26. EVALUATION LICENSE. If You are licensing the Software for evaluation purposes, Your use of the Software is
only permitted in a non-production environment and for the period limited by the License Key. Notwithstanding any
other provision in this EULA, an Evaluation License of the Software is provided "AS-IS" without indemnification,
support, or warranty of any kind, expressed or implied.
27.
28. 1. DEFINITIONS
29.
30. 12.14 Contact Information. Please direct legal notices or other correspondence to Synacor, Inc., 40 La Riviere Drive,
Suite 300, Buffalo, New York, United States, Attn: Legal Department, email address: [email protected]. Any
questions concerning this EULA should be sent to the foregoing email address: [email protected].
31.
32. 12.15 Trademarks. "Synacor" and "Zimbra" are registered trademarks of Synacor, Inc. and, along with other Synacor
trademarks, services marks and product names, may not be used without the prior permission of Synacor, Inc. Any
third party trademarks, service marks, and product names included in the Software or Documentation or otherwise
provided hereunder may not be used without the prior permission of the owner thereof.
Select ionnez “y” Do you agree with the terms of the software license agreement? [N]y
1.
2. The parties acknowledge and agree that a material breach of this
3. Agreement adversely affecting Autonomy's proprietary rights would cause
4. irreparable harm to Autonomy for which a remedy at law would be inadequate and
5. that Autonomy shall be entitled to injunctive relief in addition to any
6. remedies it may have hereunder or at law.
7.
8. Do you agree with the terms of the software license agreement? [N]y
83
11. Found zimbra-dnscache (local)
12. Found zimbra-snmp (local)
13. Found zimbra-store (local)
14. Found zimbra-apache (local)
15. Found zimbra-spell (local)
16. Found zimbra-convertd (local)
17. Found zimbra-memcached (repo)
18. Found zimbra-proxy (local)
19. Found zimbra-archiving (local)
20. Found zimbra-chat (repo)
21. Found zimbra-drive (repo)
22. Found zimbra-imapd (local)
23. Found zimbra-network-modules-ng (local)
84
34. Checking space for zimbra-store
35.
36. Installing:
37. zimbra-core
38. zimbra-ldap
39. zimbra-logger
40. zimbra-mta
41. zimbra-snmp
42. zimbra-store
43. zimbra-apache
44. zimbra-spell
45. zimbra-convertd
46. zimbra-memcached
47. zimbra-proxy
48. zimbra-chat
49. zimbra-drive
50. zimbra-network-modules-ng
Selecionner “y”
85
30. zimbra-spell will be installed.
31. zimbra-convertd will be installed.
32. zimbra-memcached will be downloaded and installed.
33. zimbra-proxy-components will be downloaded and installed.
34. zimbra-proxy will be installed.
35. zimbra-chat will be downloaded and installed (later).
36. zimbra-drive will be downloaded and installed (later).
37. zimbra-network-modules-ng will be installed.
38.
39. Downloading packages (10):
40. zimbra-core-components
41. zimbra-ldap-components
42. zimbra-mta-components
43. zimbra-snmp-components
44. zimbra-store-components
45. zimbra-jetty-distribution
46. zimbra-apache-components
47. zimbra-spell-components
48. zimbra-memcached
49. zimbra-proxy-components
50. …
51.
52. Installing local packages (22):
53. zimbra-timezone-data
54. zimbra-common-mbox-conf-msgs
55. zimbra-common-mbox-db
56. zimbra-common-mbox-conf
57. zimbra-common-mbox-native-lib
58. zimbra-common-mbox-docs
59. zimbra-common-mbox-conf-attrs
60. zimbra-common-mbox-conf-rights
61. zimbra-core
62. zimbra-ldap
63. zimbra-logger
64. zimbra-mta
65. zimbra-snmp
66. zimbra-mbox-war
67. zimbra-mbox-conf
68. zimbra-mbox-service
69. zimbra-store
70. zimbra-apache
71. zimbra-spell
72. zimbra-convertd
73. zimbra-proxy
74. zimbra-network-modules-ng
75. ...done
76.
77. Installing extra packages (2):
78. zimbra-chat
86
79. zimbra-drive
80. ...done
81.
82. Running Post Installation Configuration:
83. Installing /opt/zimbra/conf/ZCSLicense.xml
84. Operations logged to /tmp/zmsetup.20180111-132052.log
85. Installing LDAP configuration database...done.
86. Setting defaults...
87
19. *** CONFIGURATION COMPLETE - press 'a' to apply
88
34. Initializing mta config...done.
35. Setting services on zcs-886.zimbra.io...done.
36. Adding zcs-886.zimbra.io to zimbraMailHostPool in default COS...done.
37. Creating domain zimbra.io...done.
38. Setting default domain name...done.
39. Setting up default domain admin UI components...done.
40. Granting group [email protected] domain right +domainAdminConsoleRights on zimbra.io...done.
41. Granting group [email protected] global right +domainAdminZimletRights...done.
42. Setting up global distribution list admin UI components..done.
43. Granting group [email protected] global right +adminConsoleDLRights...done.
44. Granting group [email protected] global right +listAccount...done.
45. Creating domain zimbra.io...already exists.
46. Creating admin account [email protected].
47. Creating root alias...done.
48. Creating postmaster alias...done.
49. Creating user [email protected].
50. Creating user [email protected].
51. Creating user [email protected].
52. Setting spam training and Anti-virus quarantine accounts...done.
53. Initializing store sql database...done.
54. Setting zimbraSmtpHostname for zcs-886.zimbra.io...done.
55. Configuring SNMP...done.
56. Setting up syslog.conf...done.
57. Looking for valid license to install...license installed.
58. Enabling zimbra network NG modules features.
59. Starting servers…
60.
61. Starting servers...done.
62. Installing common zimlets...
63. com_zextras_drive_open...done.
64. com_zimbra_bulkprovision...done.
65. com_zimbra_email...done.
66. com_zimbra_ymemoticons...done.
67. com_zimbra_attachcontacts...done.
68. com_zimbra_adminversioncheck...done.
69. com_zimbra_clientuploader...done.
70. com_zimbra_phone...done.
71. com_zimbra_mailarchive...done.
72. com_zextras_chat_open...done.
73. com_zimbra_webex...done.
74. com_zimbra_date...done.
75. com_zimbra_url...done.
76. com_zimbra_attachmail...done.
77. com_zimbra_viewmail...done.
78. com_zimbra_proxy_config...done.
79. com_zextras_client...done.
80. com_zimbra_cert_manager...done.
81. com_zimbra_srchhighlighter...done.
82. com_zimbra_tooltip...done.
89
83. com_zextras_zextras...done.
84. Finished installing common zimlets.
85. Installing network zimlets...
86. com_zimbra_mobilesync...done.
87. com_zimbra_backuprestore...done.
88. com_zimbra_hsm...done.
89. com_zimbra_smime_cert_admin...done.
90. com_zimbra_securemail...done.
91. com_zimbra_click2call_mitel...done.
92. com_zimbra_smime...done.
93. com_zimbra_ucconfig...done.
94. com_zimbra_click2call_cisco...done.
95. com_zimbra_two_factor_auth...done.
96. com_zimbra_delegatedadmin...done.
97. com_zimbra_license...done.
98. com_zimbra_convertd...done.
99. com_zimbra_voiceprefs...done.
100. Finished installing network zimlets.
101. Restarting mailboxd...done.
102. Creating galsync account for default domain...done.
103. Setting up zimbra crontab...done.
Connexion et test
Ajout adresse reseau Du zimbra au carte wifi
90
connexion page Web du serveur zimbra
zimbra administration
91
Envoi les alerte au serveur mail
92
Partition des disques durs
Le premier serveur à installer est le serveur AD (active directory), vue son importance au
niveau des services centralisés d’identification et d’authentification à un réseau d’ordinateurs
93
utilisant le système Windows. On va poursuivre les étapes d’installation de la fonctionnalité
AD DS selon la figure 38
Lorsqu’on termine l’installation on remarque que le service est bien installé mais le domaine
n’est pas encore créé. Pour cela on va créer notre domaine. On choisit le nom de domaine et
on active le service DNS et un mot de passe sécurisé soit pour l’administration soit pour la
restauration des services AD.
Configuration post-déploiement
94
Configuration de déploiement
Vérification de l’adresse IP
95
Connexion Zimbra
Connexion au Snort
96
Connexion au Windows7
97
Résumé : (en Français)
Ce travail s’inscrit dans le cadre du projet de fin d’études en vue de l’obtention du diplôme
National d’Ingénieur en génie des télécommunications. L’objectif de ce projet était de choisir
une solution complète qui répondait aux besoins de SOTETEL en place un centre
d’opérations de sécurité (SOC). En effet, elle a adopté pour une approche centralisée qui
consiste à mettre en place un gestionnaire de sécurité central connu sous le nom de Security
Information and Event Management (SIEM) permettant ainsi de collecter, d’analyser les logs
des diverses équipements réseau afin d’identifier les menaces et les alertes et de les traiter
dans les plus brefs délais.
Mots-clés : OSSIM, SIEM, SOC, nagios, Supervision, centralisation des Log
98
Adresse : Rue des Entrepreneurs ZI Charguia II Ariana Tunis BP-640 1080.
Téléphone : +216 71 941 100
Email : [email protected]
99