Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )

Ministère de l’enseignement supérieur
et de la Recherche Scientifique
Département Informatique
Mémoire de Projet de Fin d’Etudes
Présenté pour l’obtention du
Diplôme National d’Ingénieur en
Génie Informatique
Option Réseaux Informatiques
et réalisé par
SAADAOUI Marwen
Sujet : Conception et Mise en place de Centre d’Opération de service « SOC »
Soutenu le 07/07/2018 devant le jury d’examen composé de :
M. OULD ELHASSAN Mohamed (Maitre-Assistant) Président
AFI Sahbi (Docteur Télécom) Examinateur
HDIJI Tarek (Ingénieur Expert) Encadreur Universitaire
GHARBI Walid (Directeur Technique) Encadreur Industriel
Année Universitaire : 2017/2018

Remerciements
Remerciements
Nous ne pouvons pas laisser passer l’occasion de la présentation de ce rapport sans exprimer
nos meilleurs remerciements à tous ceux qui ont bien voulu apporter l'assistance nécessaire au
bon déroulement de ce projet.
À mon encadrant pédagogique Monsieur HDIJI Tarek,
Ingénieur Expert réseaux à la Tunisie Télécom et enseignant à la Polytechnique centrale, nous
avons eu le grand honneur de travailler sous votre direction. Votre compétence professionnelle
incontestable ainsi que vos qualités humaines vous valent l’admiration et le respect de tous.
Veuillez, cher monsieur, trouver dans ce modeste travail l’expression de notre haute
considération, de notre sincère reconnaissance et de notre profond respect.
À mon encadrant professionnel Monsieur GHARBI Walid,
Expert réseaux, directeur technique à la SOTETEL et enseignant à la Polytechnique centrale
pour avoir dirigé ce travail, ses efforts pour m’intégrer dans l’environnement, ses remarques
pertinentes, et ses conseils judicieux, pour sa patience, sa disponibilité, son soutien moral et
pour la confiance qu’il m’a accordé. Qu’il trouve ici l’expression de ma plus profonde gratitude
et que ce travail soit à la hauteur du grand effort et du temps qu’il m’a consacré.
Mes remerciements les plus distingués sont adressés aux membres de jury,
Qui m’ont fait l’honneur de bien vouloir accepter d’évaluer ce travail, je leurs suis reconnaissant
du temps qu’ils y ont consacré.
Aux cadres pédagogiques de la polytechnique Centrale, pour la qualité de formation qui m’a
été dépensée.

Dédicaces
Dédicaces
Tous les mots ne sauraient exprimer la gratitude, l’amour, le respect, la reconnaissance…
Aussi, c’est Tout simplement que Je dédie ce projet de fin d’études...
À mes chers parents,
Vous avez su m’inculquer le sens de la responsabilité, de l’optimisme et de la confiance en soi
face aux difficultés de la vie. Vos conseils ont toujours guidé mes pas vers la réussite. Je vous
dois ce que je suis aujourd’hui et ce que je serai demain et je ferai toujours de mon mieux pour
rester votre fidélité et ne jamais vous décevoir
Que Dieu vous procure bonne santé et longue vie.
À mes chers frères, À ma chère sœur,
Pour votre soutient et encouragements, vous occupez une place particulière dans mon cœur.
À mes amis proches, À tous ceux que j’aime et tous qui me sont chers…
SAADAOUI Marwen …

Table des matières
Table des matières
Remerciements
Dédicaces
Table des matières
Liste des figures
Liste des tableaux
Glossaire
Introduction générale ............................................................................................................1
Chapitre 1 : Cadre générale du projet
1. Introduction .............................................................................................................................5
2. Présentation de l'organisme d'accueil.....................................................................................5
2.1 Présentation générale ......................................................................................................5
2.2 Activités de SOTETEL ........................................................................................................6
2.2.1 Réseau d'Accès..........................................................................................................6
2.2.2 Réseau « Core » et « Backbone »..............................................................................6
2.2.3 Réseau Wireless ........................................................................................................6
2.2.4 Services Convergents ................................................................................................6
2.3 Objectifs de SOTETEL........................................................................................................6
2.4 Organisme de SOTETEL.....................................................................................................8
3. Etude de l’existant ...................................................................................................................9
3.1 Description de l’existant...................................................................................................9
3.2 Critique de l’existant.........................................................................................................9
3.2.1 Complexité de configuration.....................................................................................9
3.2.2 Gestion de configuration...........................................................................................9
3.2.3 Enoncé du problème de supervision.......................................................................10
3.2.4 Enoncé du problème de journalisation...................................................................10
3.2.5 Entraves de SOTETEL...............................................................................................10
3.2.6 Nécessité des centres d’opération de services (SOC).............................................11
4. Solution envisagé...................................................................................................................11
4.1 Modèle conceptuel de la solution de supervision .........................................................12
4.2 Modèle conceptuel de la solution de journalisation......................................................13
5. Conclusion..............................................................................................................................14
Chapitre 2 : Conception de la solution cible

Table des matières
Partie 1 : Étude conceptuelle de la supervision.....................................................................16
1. Introduction ...........................................................................................................................16
2. Monitoring, surveillance réseau informatique :....................................................................16
2.1 Les Objectifs du monitoring : ........................................................................................16
2.2 Domaines de surveillance .............................................................................................17
3. Les outils de monitoring ........................................................................................................18
3.1 Les plateformes éditeurs................................................................................................18
3.1.1 Scom........................................................................................................................18
3.1.2 HP OpenView...........................................................................................................19
3.1.3 IBM Trivoli Monitoring ............................................................................................19
3.2 Les plateformes libres.....................................................................................................20
3.2.1 Nagios......................................................................................................................20
3.2.2 Zabbix ......................................................................................................................21
3.2.3 Check _MK...............................................................................................................22
3.2.4 Eyes-Of-Network .....................................................................................................22
4. Etude Comparatif...................................................................................................................23
5. Choix de Plateforme...............................................................................................................25
5.1 Composition d’Eyes-Of-Network....................................................................................25
5.2 Architecture d’EyeOfNetwork ........................................................................................26
5.2.1 Programmes-plugins ...............................................................................................27
5.2.2 Les fichiers de configuration ...................................................................................27
5.2.3 Compléments d’Eyes-Of-Network...........................................................................28
5.2.3.1 NAGIOS....................................................................................................................29
5.2.3.2 CACTI .......................................................................................................................30
5.2.3.3 Wethermap .............................................................................................................31
5.2.3.4 NagVis......................................................................................................................31
6. Conclusion..............................................................................................................................32
Partie 2 : Étude conceptuelle de la centralisation des journaux.............................................33
1. Introduction ...........................................................................................................................33
2. Centralisation des journaux...................................................................................................33
2.1 Logs.....................................................................................................................................33
2.2 Journalisation locale ..........................................................................................................33
2.3 Centralisation des journaux................................................................................................34
3. Système de gestion des évènements ....................................................................................35

Table des matières
3.1 SEM (Gestion des événements de sécurité)...................................................................35
3.2 SIM (Gestion de l'information de sécurité) ....................................................................35
3.3 SIEM (Informations sur la sécurité et gestion des événements) ...................................36
4. Produit SIEM ..........................................................................................................................37
4.1 Graylog............................................................................................................................37
4.2 Fluentd............................................................................................................................38
4.3 ELK stack .........................................................................................................................39
5. Analyse comparative..............................................................................................................40
5.1 Caractéristiques............................................................................................................40
5.2 Fonctionnement ...........................................................................................................40
6. Choix de plateforme ..............................................................................................................42
6.1 Présentation générale de la solution ELK stack..............................................................42
6.2 Le principe technique de la solution ELK stack...............................................................42
6.3 Architecture d'ELK stack.................................................................................................43
6.4 Les composants d'ELK stack............................................................................................43
6.4.1 ElasticSearch............................................................................................................43
6.4.1.1 Présentation d’ElasticSearch...................................................................................43
6.4.1.2 Moteur de recherche et moteur d'indexation........................................................44
6.4.1.3 Les fonctionnalités d'ElasticSearch .........................................................................44
6.4.2 Logstash...................................................................................................................45
6.4.2.1 Présentation de Logstash........................................................................................45
6.4.2.2 Principe de fonctionnement de Logstash ...............................................................46
6.4.3 Kibana......................................................................................................................47
6.4.3.1 Présentation de Kibana ...........................................................................................47
6.4.3.2 Principe de fonctionnement de Kibana...................................................................47
7. Conclusion..............................................................................................................................48
Chapitre 3 : Émulation de la topologie de la solution
1. Introduction ...........................................................................................................................50
2. Environnement de simulation ...............................................................................................50
2.1 Prérequis Matériels ........................................................................................................50
2.2 Prérequis logiciel ............................................................................................................50
3. Présentation de la topologie du Backbone............................................................................51
3.1 Technologies et plateformes utilisées............................................................................52
3.2 Méthodologie d’approche..............................................................................................52

Table des matières
3.3 Plan d’adressage.............................................................................................................52
3.3.1 Coté Backbone ........................................................................................................52
4. Configurations et tests...........................................................................................................54
4.1 Configuration des interfaces ..........................................................................................54
4.2 Configuration des protocoles de routage intra-nuage...................................................54
4.2.1 Routage OSPF de Backbone IP/MPLS....................................................................54
4.2.2 Configuration de MPLS............................................................................................56
4.3 Mise en place des VPN ...................................................................................................57
4.3.1 Configuration de VRF ..............................................................................................57
4.4 Configuration de routage OSPF au niveau CPE ..............................................................58
4.5 Configuration de MP_BGP..............................................................................................58
5. Conclusion..............................................................................................................................60
Chapitre 4 : Management de la solution
Partie 1 : Mise en place de serveur de supervision................................................................62
1. Introduction ...........................................................................................................................62
2. Prérequis logiciel....................................................................................................................62
3. Association du GNS3-VMWare ..............................................................................................62
3.1 Installation de superviseur EyesOfNetwork...................................................................63
3.1.1 Paramétrage réseaux : ............................................................................................63
3.1.2 Accès à la plateforme..............................................................................................65
3.2 Couplage Backbone-EyesOfNetwork..............................................................................65
4. Mise en place de Nagios ........................................................................................................67
4.1 Configuration SNMP .......................................................................................................67
4.2 Ajout des équipements du Backbone.............................................................................68
4.3 Programme plugins.........................................................................................................69
4.4 Vérification .....................................................................................................................71
5. Mise en place de Cacti ...........................................................................................................72
5.1 Création d’un graphe......................................................................................................73
5.2 Création d’Hôte : ............................................................................................................73
5.3 Graphe de Cacti ..............................................................................................................74
6. Mise en place de Nagvis.........................................................................................................76
6.1 Création de carte............................................................................................................76
6.2 Ajout des hôtes...............................................................................................................76
7. Mise en place de Weathermap..............................................................................................77

Table des matières
7.1 Création de carte............................................................................................................77
7.2 Ajout des nœuds.............................................................................................................77
7.3 Ajout des liens ................................................................................................................78
8. Génération des Rapport.........................................................................................................79
8.1 Rapport SLA Technique ..................................................................................................79
8.2 Rapport Tendances.........................................................................................................79
8.3 Rapport performances ...................................................................................................80
9. Notification par Email ............................................................................................................80
10. Conclusion..............................................................................................................................81
Partie 2 : Mise en place de serveur de centralisation des journaux...........................................82
1. Introduction ...........................................................................................................................82
2. Mise en place de l’environnement ........................................................................................82
2.1 Installation de la machine virtuelle ................................................................................82
2.2 Connexion Gns3-Machine virtuelle................................................................................83
3. Installation de la pile ELK-stack..............................................................................................85
3.1 Installation de Java 8 ......................................................................................................85
3.2 Installation d’Elasticserach .............................................................................................86
3.3 Installation de Logstash..................................................................................................87
3.4 Installation de Kibana .....................................................................................................87
4. Configuration de la pile ELK ...................................................................................................89
5. Analyse des journaux.............................................................................................................91
5.1 Configuration des routeurs ............................................................................................91
5.2 Configurations de script de log.......................................................................................92
5.3 Test d’analyse de log ......................................................................................................93
6. Gestion de l’interface Web de Kibana ...................................................................................93
6.1 Recherche des messages................................................................................................94
6.2 Tableau de bord et visualisation ....................................................................................95
6.3 Génération des rapports ................................................................................................96
7. Conclusion..............................................................................................................................96
Conclusion générale......................................................................................................................97
Références bibliographiques.........................................................................................................98
Annexes.......................................................................................................................................100

Liste des figures
Liste des figures
Figure I- 1 : Planification Du Déroulement Du Projet .....................................................................2
Figure I- 2 : Logo Sotetel .................................................................................................................5
Figure I- 3 : Organigramme De Sotetel ...........................................................................................8
Figure I- 4 : Architecture de la solution de supervision................................................................12
Figure I- 5 : Architecture de solution de journalisation................................................................13
Figure II- 1 : Interface graphique SCOM .......................................................................................18
Figure II- 2 : Interface graphique HP OpenView...........................................................................19
Figure II- 3 : Interface graphique IBM Trivoli................................................................................19
Figure II- 4 : Logo Zabbix...............................................................................................................21
Figure II- 5 : Logo Check-mk..........................................................................................................22
Figure II- 6 : Logo Eyes-of-network...............................................................................................22
Figure II- 7 : Diagramme radar......................................................................................................23
Figure II- 8 : Eyes of network ........................................................................................................25
Figure II- 9 : Composants d’Eyes-of-network................................................................................26
Figure II- 10 : Architecture d’EyeOfNetwork ................................................................................27
Figure II- 11 : Outils d’Eyes-Of-Network ......................................................................................28
Figure II- 12 : Interface graphique de Nagios ...............................................................................29
Figure II- 13 : Interface graphique CACTI......................................................................................30
Figure II- 14 : Vue de la carte Wethermap....................................................................................31
Figure II- 15 : Vue de la carte Nagvis ............................................................................................31
Figure II- 16 : Architecture log local..............................................................................................34
Figure II- 17 : Architecture SIEM...................................................................................................36
Figure II- 18 : Logo graylog............................................................................................................37
Figure II- 19 : Architecture Graylog...............................................................................................38
Figure II- 20 : Logo Fluentd ...........................................................................................................38
Figure II- 21 : Architecture Fluentd...............................................................................................38
Figure II- 22 : ELK-stack.................................................................................................................39
Figure II- 23 : Architecture ELK-Stack............................................................................................43
Figure II- 24 : Principe de fonctionnement Logstash....................................................................46
Figure III- 1 : LOGO GNS3..............................................................................................................50
Figure III- 2 : Maquette de simulation ..........................................................................................51
Figure III- 3 : Architecture OSPF....................................................................................................55
Figure III- 4 : Test de bon fonctionnement d’OSPF.......................................................................56
Figure III- 5 : Table de voisinage de routeur PE1..........................................................................57
Figure III- 6 : Test de la connectivité VRF au niveau de PE1.........................................................60
Figure IV- 1 : VMware-Workstation 12 pro ..................................................................................63
Figure IV- 2 : Processus d’installation d’Eyes-Of-Network ...........................................................63
Figure IV- 3 : Adressage réseaux du superviseur..........................................................................64
Figure IV- 4 : Adresse IP d’EyesOfNetwork...................................................................................64
Figure IV- 5 : Interface authentification EyesOfNetwork .............................................................65
Figure IV- 6 : Dashboard EyesOfNetwork .....................................................................................65

Liste des figures
Figure IV- 7 : Carte réseaux de la machine virtuelle.....................................................................66
Figure IV- 8 : Cloud Backbone-EyesOfNetwork ............................................................................66
Figure IV- 9 : Test de couplage Backbone-EON ............................................................................67
Figure IV- 10 : Configuration SNMP-EON......................................................................................68
Figure IV- 11 : Configuration SNMP-Router..................................................................................68
Figure IV- 12 : Ajout –Nagios du routeur Provider .......................................................................68
Figure IV- 13 : Chargement de plugin ...........................................................................................70
Figure IV- 14 : Liste des plugins Nagios.........................................................................................71
Figure IV- 15 : Affichage de la liste des routeurs surveillés..........................................................71
Figure IV- 16 : Interface des services surveillés ............................................................................72
Figure IV- 17 : Interface web de Cacti...........................................................................................72
Figure IV- 18 : Création de graphe Cacti .......................................................................................73
Figure IV- 19 : Création d’hôte Cacti.............................................................................................73
Figure IV- 20 : États des routeurs surveillés par Cacti ..................................................................74
Figure IV- 21 : Graphe CPU Usage du routeur Provider................................................................75
Figure IV- 22 : État de PE1 à superviser ........................................................................................75
Figure IV- 23 : Graphe de Traffic G0/0 PE1...................................................................................75
Figure IV- 24 : Création de carte Nagvis........................................................................................76
Figure IV- 25 : Ajout équipements Nagvis.....................................................................................76
Figure IV- 26 : Carte Nagvis...........................................................................................................77
Figure IV- 27 : Création de carte wedhermap...............................................................................77
Figure IV- 28 : Ajout de nœud-weathermap.................................................................................78
Figure IV- 29 : Ajout d’un lien wethermap ...................................................................................78
Figure IV- 30 : Carte weathermap ................................................................................................78
Figure IV- 31 : Rapport SLA de routeur Provider..........................................................................79
Figure IV- 32 : Rapport tendances PE1 .........................................................................................80
Figure IV- 33 : Rapport performance Backbone SOTETEL............................................................80
Figure IV- 34 : Notification par email............................................................................................81
Figure IV- 35 : Réception des mails de Nagios..............................................................................81
Figure IV- 36 : Processus d’installation d’Ubuntu 18.04 ..............................................................82
Figure IV- 37 : Ajout d’interface virtuelle .....................................................................................83
Figure IV- 38 : Adresses IP de l’interface de la machine hébergeant le serveur ELK ...................83
Figure IV- 39 : Couplage Backbone-ELK........................................................................................84
Figure IV- 40 : test de connectivité backbone-ELK.......................................................................84
Figure IV- 41 : Ajout d’un référentiel Oracle Java ........................................................................85
Figure IV- 42 : Mise à jour de base de données de paquets APT .................................................85
Figure IV- 43 : Installation Java 8..................................................................................................86
Figure IV- 44 : Version java...........................................................................................................86
Figure IV- 45 : Clé de signature d'Elastic.......................................................................................86
Figure IV- 46 : Installation d’Elasticserach....................................................................................87
Figure IV- 47 : Activation et état de service d’elasticsearch ........................................................88
Figure IV- 48 : Activation et état de service Logstash ..................................................................88
Figure IV- 49 : Activation et état de service de Kibana.................................................................88
Figure IV- 50 : Activation automatique des services ELK-stack....................................................88

Liste des figures
Figure IV- 51 : Configuration Elasticsearch...................................................................................89
Figure IV- 52 : Configuration Logstash..........................................................................................90
Figure IV- 53 : Configuration Kibana.............................................................................................90
Figure IV- 54 : Configuration logging du routeur Provider...........................................................91
Figure IV- 55 : Configuration de script log2.conf..........................................................................92
Figure IV- 56 : Test d’analyse de log par ELK-stack.......................................................................93
Figure IV- 57 : Découvert des logs par Kibana..............................................................................94
Figure IV- 58 : Recherche des messages sur Kibana....................................................................94
Figure IV- 59 : Création de nouvelle visualisation ........................................................................95
Figure IV- 60 : Création d'un Tableaux de bord............................................................................95

Liste des tableauxx
Liste des tableaux
Tableau II- 1 : Tableau comparatif des outils de supervision open source ..................................24
Tableau II- 2 : Tableau comparatif SIEM - caractéristique............................................................40
Tableau II- 3 : Tableau comparatif SIEM- Fonctionnement..........................................................41
Tableau III- 1 : Adressage de la maquette....................................................................................53

Glossaire
Glossaire
A
AS : Autonomous System
B
BGP : Border Gateway Protocol
C
CPE : Customer Provider Edge
CPU : Central Processing Unit
G
GNS3 : Graphical Network Simulator
GE : Giga Ethernet
I
ICMP : Internet Control Message Protocol
IP : Internet Protocol
IOS : Internetwork Operating System
L
LAN : Local Area Network
LDP : Label Distribution Protocol
LER : Label Edge Router
LSR : Label Switch Router
M
MPLS : Multi-Protocol Label Switching
O
OSPF : Open Shortest Path First
P
P : Provider
PE : Provider Edge
S
SOTETEL : Société Tunisienne d'Entreprises de Télécommunication

Glossaire
SOC : Centre d’opération de service
SIEM : Security Information and Event Management
SEM : Security Event Management
SIM : Security Information Management
SNMP : Simple Network Management Protocol
SLA : Service-level agreement
U
UDP : User Datagram Protocol
V
VPN : Virtual Private Network
VRF : Virtual Routing and Forwarding

Introduction générale
1
Durant ces dernières années, l’industrie des technologies de l’information et des
télécommunications témoigne une évolution considérable. En conséquence, cette évolution
entraine le développement de nouveaux services multimédia qui exigent des garantis en terme
de qualité de service.
En revanche, avec un besoin croissant d'offrir des services plus personnalisés à leurs abonnés
tout en faisant face à la complexité croissante de leurs réseaux, et les défis posés par une
diversification de leurs modèles d'affaires vers le cloud et les services numériques, les
opérateurs réseaux doivent passer de CNP (centres d'opérations réseau) à SOC (centre
d’opération de service).
D’autant plus, suite à l’augmentation continue des petites et moyennes entreprises souhaitant
héberger et gérer à distance leurs infrastructures et systèmes d’informations et accélérer leur
transformation numérique, SOTETEL doit améliorer son réseau cœur afin de mieux répondre
aux besoins de ses clients professionnels en leur offrant une plus grande flexibilité dans le
développement et l’administration de leurs systèmes d’informations. Cette nécessité d’évoluer
a permis de créer une solution de migration vers la technologie MPLS pour supporter sur le
même Backbone différents services (data, voix, vidéo, internet).
Par ailleurs, dans un environnement caractérisé par une concurrence accrue, les moindres
problèmes qui peuvent survenir sur le Backbone peuvent avoir de lourdes conséquences aussi
bien organisationnelles que fonctionnelles. Pour cette raison et afin de réduire ce risque au
minimum, il est nécessaire de surveiller le réseau et d’agir quand une erreur se produit. Pour ce
faire, il faut obtenir les données de gestion et contrôler les équipements de réseaux. Dans ce
contexte et pour répondre à ces exigences, La Société Tunisienne d'Entreprises de
Télécommunications « SOTETEL » nous a proposé ce projet intitulé « Conception et mise en
place de centre d’opération de service SOC » visant à détecter et isoler tout type de
dysfonctionnement dans le réseau.
Ce projet est réalisé au sein de « SOTETEL », dans le cadre d’un projet de fin d’études pour
l’obtention du diplôme national d’ingénieur spécialité réseaux informatique.

2
Il consiste d’une part à concevoir et implémenter une solution convergente de technique
MPLS/VRF, permettant à l’entreprise de répondre aux besoins de ses clients. D’autre part, il
consiste à implémenter une solution open source de supervision appelée « Eyes Of Network »
capable de de gérer et de superviser la totalité du réseau du Backbone IP/MPLS de SOTETEL.
Par la suite nous serons en mesure de mettre en place un système SIEM de centralisation des
logs des équipements réseaux du Backbone IP/MPLS, qui va permettre de fournir des
statistiques utiles pour faire des prévisions et générer des événements reflétant l’état de
réseau.
L’objectif de la planification du projet est de déterminer les étapes du projet et le timing. Ce
planning joue un rôle primordial pour la réalisation et le suivi du projet. En vue de modéliser
cette planification, nous avons eu recours à l’outil de gestion de projet « Office-Time-Line » afin
de dresser le diagramme de Gant montrant les différentes étapes de notre projet.
Figure I- 1 : Planification du déroulement du projet
Le plan envisagé dans le reste de ce document adopte une démarche répartie en quatre
modules :
En premier lieu, le rapport s’ouvrira sur une présentation détaillée de l’entreprise ainsi
que du sujet de stage. Il sera clôturé par une étude de l’existant afin de dévoiler les
entraves que rencontre l’opérateur. Finissant par la solution proposée
Le deuxième chapitre sera subdivisé en deux parties consacrées pour l’étude
conceptuelle du notre centre d’opération de service. Où nous définirons dans une
première partie la notion du monitoring réseaux et ses objectifs, ainsi qu’une étude
comparative des différentes plateformes existantes dans le domaine de la surveillance

3
réseau, finissant par le choix de l’outil adopté. La deuxième partie de ce chapitre portera
sur l’étude de concept de centralisation et d’analyse des journaux des équipements
réseaux, cette partie sera valorisée par une étude comparative des systèmes SIEM de
centralisation des journaux existant, finissant par le choix opté pour notre solution.
Le troisième chapitre s’intéressera à la mise en place et la simulation, à une échelle
réduite, de la topologie de notre solution. On fera l’émulation de quelques techniques
proposées.
Le quatrième chapitre tracera la fonction de management de la topologie ainsi créée .Il
sera subdivisé en deux parties. La première partie comporte l’installation et la
configuration d’un système de supervision réseau et un système d’étude de
performances. La deuxième partie sera dédiée pour la mise en place d’un Système SIEM
par l’implémentation d’un serveur de journalisation et d’analyse de log des équipements
réseaux cœur de SOTETEL
Nous clôturons le rapport par une conclusion générale traçant les grandes lignes de
notre travail suivie par des perspectives que nous désirons accomplir dans un travail
futur.

Ce chapitre présente, d’une manière générale, le contexte du travail afin de fixer les objectifs
de ce projet de fin d’études.
Chapitre 1
Cadre générale du projet

5
1. Introduction
Dans ce chapitre, nous présentons d’abord l’établissement d'accueil au sein duquel notre stage
a été accompli, par une description générale, des objectifs et du domaine d'activité, ensuite
nous allons étudier les problématiques posées. Enfin nous présenterons la solution adoptée
pour ces derniers
2. Présentation de l'organisme d'accueil
2.1 Présentation générale
La Société Tunisienne d'Entreprises de Télécommunications SOTETEL est un acteur de référence
dans le domaine des télécommunications en Tunisie et à l'étranger, elle se positionne comme le
partenaire privilégié des principaux équipementiers internationaux opérant en Tunisie.
Elle a été créée en septembre 1981 avec un capital de 23,184 Million DT, en 2013 le chiffre
d'affaire de la société a atteint 37,789 Million DT, La société est leader dans la mise en œuvre
et la maintenance des infrastructures de tous types de réseaux de télécommunication.
Les ressources humaines et matérielles de la société présentant toujours des bénéfices devant
ses concurrents et garantissant la position dominante de la société sur le marché de
télécommunication ce qui explique son rôle prépondérant dans le déploiement de
l'infrastructure des télécommunications en Tunisie en prenant part presque à tous les projets
réalisés pour le compte de l'opérateur national « Tunisie Télécom » [B1]
Figure I- 2 : Logo SOTETEL
Elle dispose d'un effectif total de 530 employés dont 70 ingénieurs, un parc de moyens
logistiques important composé notamment de 225 véhicules ,90 engins et outils spécialisés 6
micros trancheuses.
La société est constituée actuellement de 14 sites dont un siège construit sur une superficie de
plus de 6 000 m²,4 complexes régionaux abritant principalement les structures administratives
et techniques qui leur sont rattachées et dont 3 ont une superficie qui dépasse les 3 000 m² un
hangar d'une superficie de 6 000 m² environ , 7 espaces commerciaux dont un transformé en
un « Espace entreprises » et deux loués à Tunisie Télécom et Un terrain de plus de 1600 m².

6
Les principaux actionnaires de SOTETEL sont « Tunisie-Télécom » avec un pourcentage de 35%,
« Al-Atheer-Funds » avec un pourcentage de 7.47% et des divers porteurs avec un pourcentage
de 57.53%, parmi les partenaires on cite :
 CISCO
 HUAWEI
 NEC
 SAGEM
 VMware
2.2 Activités de SOTETEL
Les activités de la SOTETEL couvrent plusieurs domaines des réseaux de télécommunication
dont on cite :
2.2.1 Réseau d'Accès
 Ingénierie des réseaux de Télécommunications.
 Réseau d'accès par FTTX.
 Réseaux d'accès par câbles Cuivre.
2.2.2 Réseau « Core » et « Backbone »
 Aménagement des locaux techniques.
 Intégration des systèmes IP-MSAN.
 Maintenance des réseaux des opérateurs.
 Réseaux PSTN et PLMN.
 Réseaux Metro Fibre et Backbone.
2.2.3 Réseau Wireless
 Couverture Wireless Indoor.
 Mise en place des sites 3G.
 Optimisation des réseaux radios.
2.2.4 Services Convergents
 Autorisation et authentification.
 Communications unifiées et travail collaboratif.
 Distribution et mobilité.
2.3 Objectifs de SOTETEL
Les objectifs stratégiques de SOTETEL ont été organisés autour de 5 axes :

7
 La croissance financière rentable et performante.
 La mise à niveau technologique concentrée sur le cœur de métier.
 Le développement d'une approche commerciale cohérente et proactive.
 La performance et la mise à niveau des ressources humaines.
 L'excellence opérationnelle des processus et systèmes clés.
La stratégie de développement de la SOTETEL a été basée sur les avantages compétitifs dont
elle dispose, notamment :
 La maitrise acquise dans la conduite des grands projets.
 La notoriété historique et l'image de marque.
 La consistance du carnet d'adresse et l'importance des références.
 La compétence et la spécialisation des ressources humaines techniques.
 La confiance des autorités publiques.
 La présence sur l'ensemble du territoire
Dans le but de réussir sa mission d'intégrateur, il a été question d'engager un programme de
transformation visant à assurer une forte réactivité suivant une structure légère et un modèle
de gestion souple et responsabilisant.
Pour ce fait, un plan d'affaires a été élaboré pour la période 2009-2011 visant notamment à :
 Recentrer les activités de l'entreprise.
 Fixer les objectifs de rentabilité.
 Optimiser les ressources.
 Développer les ressources et les compétences.
 Mettre en place un système d'incitation basé sur la productivité.
 Mettre en place un modèle de management favorisant le suivi et l'évaluation des
performances.
Une nouvelle organisation a été instaurée reflétant une volonté permanente de faire
développer les compétences et de faire évoluer les activités et les solutions, Une organisation
dynamique centrée sur les clients et tirée conjointement par trois soucis permanents :
 Le suivi systématique des nouveautés et des opportunités.
 Le développement des activités à forte valeur ajoutée.
 Le respect des normes de qualité et de performance

8
2.4 Organisme de SOTETEL
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. [B1]
 D.C.F (Direction Centrale Financière) responsable à la gestion financière, comptabilité
et administration.
 D.C.C (Direction Centrale Commerciale) responsable de la gestion des ventes, du chiffre
d'affaires et du marketing.s
 D.C.R.H (Direction Centrale Ressources Humaines) responsable du recrutement,
intégration et formation du personnel, gestion administrative et paie et communication
interne.
 D.C.S.E (Direction Centrale Solution d'Entreprise) responsable de l'étude, installation et
maintenance des réseaux privés.
 D.C.RX (Direction Centrale des Réseaux) responsable de la mise en œuvre de
l'infrastructure des réseaux de transmissions et des réseaux d'accès (Réseaux publics).
Figure I- 3 : Organigramme de SOTETEL

9
3. 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
3.1 Description de l’existant
L’évolution fulgurante des réseaux informatiques et Internet a fait accroitre la charge de travail
des administrateurs réseaux, occasionnant ainsi un accroissement des ressources humaines
consacrées à leur gestion. Les capacités de gestion de réseau ont été poussées à leurs limites et
sont donc devenues plus complexes et source d’erreurs. [B2]
3.2 Critique de l’existant
3.2.1 Complexité de configuration
La gestion des réseaux informatiques est toujours un travail pénible, laborieux, sujet aux
erreurs et dont la complexité est sans cesse croissante en raison de l’évolution des technologies
et du matériel qui entre en compte.
D’une part, les équipements qui forment le réseau doivent se comporter comme un groupe ;
cependant, chacune de ces machines est gérée et configurée individuellement. La question
fondamentale est la même depuis plusieurs années. Un ingénieur réseaux est responsable d’un
pool de dispositifs dont les configurations individuelles sont gérées pour la plupart
manuellement. Chaque fois qu’un nouveau service doit être ajouté aux appareils du réseau, il
doit s’assurer du réglage parfait et approprié des paramètres de configuration de ces appareils.
Cette délicate opération doit viser deux objectifs : mettre en place la fonctionnalité désirée tout
en permettant la continuité des services existants. Ceci signifie en particulier que les
paramètres de la nouvelle configuration ne doivent pas entrer en conflit avec les paramètres
déjà configurés de ces appareils ou ceux d’autres appareils. Imaginez que lors d’un examen en
vidéo conférence, après quelques échanges fructueux entre l’étudiant et l’examinateur se
trouvant dans une autre ville ou dans une autre université, la communication se coupe.
Comment faire pour renouer la communication avec son enseignant ou son étudiant ?
3.2.2 Gestion de configuration
La diversité des équipements réseaux et des contraintes qui leur sont associées font ainsi
accroitre la complexité de la gestion des configurations, et comme le mentionnent parmi tous

10
les problèmes liés aux équipements réseau, les erreurs de configurations sont les plus difficiles
à résoudre. L’objectif des administrateurs de réseaux est de configurer les équipements
réseaux sans aucune erreur. La réduction du nombre d’erreurs peut conduire à une réduction
des couts des travaux de maintenance pour les entreprises. Des recherches menées dans le
passé ont découvert que 40% des temps d’arrêt de système sont dus aux erreurs
opérationnelles et 44% proviennent des erreurs de configuration. [B3]
3.2.3 Enoncé du problème de supervision
Ayant un très grand nombre de serveurs à gérer, l’administrateur réseaux est incapable de
vérifier leurs disponibilités (en ligne ou pas), déterminer la qualité des services qu’ils offrent, ni
de détecter la défaillance des équipements (charge CPU, Etat mémoire, surcharge du disque…)
ni les surcharges et pénurie temporaire des ressources. Le seul moyen de détecter ces
anomalies, se faite par la réception des différentes plaintes et réclamations des clients.
Souciante de sa réputation concernée par la satisfaction et le confort de ses clients, la société
veut à tout prix éviter la confrontation à des clients mécontents d’où éviter le risque de les
perdre, et ce en travaillant à leur offrir une meilleure qualité de services, en anticipant les
pannes et en évitant les arrêts de longue durée gênant les services qui peuvent causer de
lourdes conséquences aussi bien financières qu’organisationnelles.
3.2.4 Enoncé du problème de journalisation
À l'époque actuelle SOTETEL ,n’a pas de solution pour restaurer ses journaux pour une
utilisation ultérieure qui est à l'origine des problèmes à tant de niveaux, ils ne gardent que la
piste sur les quelques journaux qui sont produits par les logiciels de supervision du réseau ou
des journaux qui sont stockés sur ses bases de données des solutions de gestion, comme le
dépannage du résultat prend plus du temps que prévu et il y a très peu administrateurs qui
aiment se pencher sur les fichiers journaux pour diagnostiquer manuellement et résoudre un
problème de système ou de réseau.
3.2.5 Entraves de SOTETEL
SOTETEL est maintenant engagé via-avis de ses clients par un contrat SLA (Service Level
Agreement) qui formalise l’accord négocié entre les deux parties. Il met par écrit l’attente des
clients sur le contenu des prestations, leurs modalités d'exécution ainsi que les responsabilités
et les garanties du fournisseur. Par exemple, le SLA peut spécifier les limites acceptables en

11
termes de la qualité de service offerte qui peut être mesurée avec des statistiques telles que le
débit, le taux d’utilisation des ressources, le taux de perte, la disponibilité, etc. D’autre part, la
solution actuelle de gestion du Backbone qu’utilise SOTETEL souffre d’un ensemble
d’inconvénients. Par conséquent et pour maintenir la qualité de service minimale exigée dans le
SLA, des outils avancés en gestion du réseau doivent être utilisés.
3.2.6 Nécessité des centres d’opération de services (SOC)
Pour rester au courant des temps en termes de technologies de télécommunication et service
des réseaux, et pour améliorer les capacités de service à la clientèle. les opérateurs autour du
monde , cherchent toujours de développer des centres d’opération de service (SOC) qui lui
permettent de surveiller et de visualiser leurs services, leurs sites et le statut de leurs clients et
de poursuivre l'exploration et l'exploration des instances de services et des sites à l'aide
d'informations sur les performances, les erreurs et la configuration, à travers les domaines, les
réseaux et les topologies.
Les centres d'opérations de service (SOC) regroupent les ressources dans un seul emplacement
et gèrent les flux de données et les événements déconnectés, fournissant des informations sur
la qualité de service (QoS) fournie aux abonnés.
4. Solution envisagé
Pour remédier aux problèmes et entraves de SOTETEL précédemment cités, et pour satisfaire
au maximum aux abonnés en termes de qualité et continuité de service ainsi que pour
atténuer aux problèmes de complexité et de gestion des équipements réseaux. SOTETEL
propose ce projet qui consiste à la mise en place de centre d’opérations de service, comprend
la mise en évidence d’un mécanisme pour contrôler le fonctionnement du son cœur réseaux
« Backbone » et pour étudier les données collectées et définir des seuils d’alertes qui peuvent
servir au déclenchement des alertes lors de détection des problèmes.
Il s’agit donc et sans doute d’une :
Mise en place d’un système de supervision qui pourra grâce aux différentes
fonctionnalités qu’il offre, détecter les pannes en surveillant le statut des équipements
réseaux existant dans la « Backbone », et des divers services réseaux et d’offrir des
renseignements supplémentaires voir charge CPU, espace disque, mémoire disponible.

12
Mise en oeuvre d’un outil de centralisation des journaux des équipements réseaux du
« Backbone » de SOTETEL, qui a pour fonction, anticiper les erreurs el les pannes de
réseaux en suivant méticuleusement le fonctionnement du système par le collecte et
l’analyse des journaux envoyées par les routeurs dans un serveur virtuel afin d’avoir une
vue générale de système et d’avertir si cet outil a détecté des anomalies pouvant causer
un arrêt du service.
4.1 Modèle conceptuel de la solution de supervision
Un système de supervision offrira à l’administrateur la possibilité de contrôler et de vérifier
l’état des équipements réseaux (Ex : CPU, mémoire, Ram etc…) ainsi que les services installés
sur lesquels (Ex : services routage, services application etc...), à l’aide du protocole SNMP. Il
permet de réagir le plus rapidement possible face aux pannes qui peuvent intervenir afin
d’éviter un arrêt de production de trop longue durée.
Figure I- 4 : Architecture de la solution de supervision
La solution de supervision proposée est optée pour un outil de monitoring performant et riche
en fonctionnalités permettant de gérer les équipements réseaux de sa Backbone de façon
simple et unifiée.
Une des tâches confiées à l’administrateur réseau est de surveiller et de contrôler les
périphériques, tels qu’hôtes, routeurs, serveurs et switch.

13
Le protocole SNMP qui doit être configuré sur ces équipements, permettra d'avoir un aperçu
plus clair des ressources du réseau entier. Ceci fait, on aura la possibilité de gérer ces
ressources de manière optimisée, amplifiant ainsi les performances du système.
Avec le protocole SNMP, il pourra contrôler la consommation de la bande passante
et l’occupation mémoire CPU et superviser des problèmes importants, tels que la disponibilité
et les niveaux trafic. [B4]
4.2 Modèle conceptuel de la solution de journalisation
Avec l’évolution flagrante des architecture réseaux et le trafic très critique qu’elles génèrent
(trafic financier, trafic bancaire, trafic Datacenter...), la supervision reste un élément insuffisant
vue qu’on n’aperçoit l’incident que lorsqu’il se produit.
C’est pour cela que cette partie de notre projet détermine des lignes directrices pour le choix
d'une solution de collecte et d’analyse des journaux des équipements réseaux du Backbone de
« SOTETEL » permettant à l’administrateur réseaux de détecter les incidents suspects et de
réagir d’une façon proactive face à ces incidents qui peuvent provoque un arrêt de système
Donc l'objectif principal de cette partie est de refléter l'importance qui réside sur la collecte et
l’analyse des événements des équipements réseaux avec un système centralisé et les corréler
pour générer des alertes afin de suivre efficacement tout état de cause dans le réseau dans un
délai nécessaire.
Figure I- 5 : Architecture de solution de journalisation

14
On parle céans de la mise en place d’un système SIEM (Security Information and Event
Management) qui permet à l’aide de la réception des journaux de la part de différents
équipements existant dans l’infrastructure réseaux de l’entreprise de :
 Contrôler les vulnérabilités de l’infrastructure réseaux de l’entreprise
 Détecter d’une manière précoce les cyberattaques en maintenant une surveillance
permanente
 Réagir pro-activement face aux incidents qui peuvent se produire (Ex : si on détecte une
mauvaise qualité de lien entre deux routeurs, on peut régler le problème avant qu'il
provoque l'échec de service de routage).
Comme il est montré dans la figure de la solution, le principe de fonctionnement d’un système
SIEM est réparti en cinq principales phases :
 La collecte : consiste à recueillir des journaux système provenant des différentes sources
(routeur, pare-feu, serveur...)
 La normalisation : permet de convertir les logs originaux collectés dans un format
universel et de les classer dans des catégories utiles. (Ex : modifications d’une
configuration, accès aux fichiers ou encore Attaque par surcharge de tampon)
 Analyse : permet d’analyser les journaux à partir de requêtes paramétrables
 La corrélation : Les règles de corrélation permettent d'identifier un événement qui a
causé la génération de plusieurs autres (Ex : un hacker qui s'est introduit sur le réseau
puis a manipulé tel équipement…)
 Reporting : sert à la création des rapports standards et planifiés qui prendront en
compte toutes les vues historiques des données recueillies par le produit SIEM
5. Conclusion
Ce chapitre a été conçu pour familiariser l’environnement de travail en présentant l’entreprise
d’accueil et l’architecture réseaux dont elle dispose. Les problèmes que rencontre SOTETEL se
sont imposés suite à l’étude de l’existant et à sa critique. Pour finir par la proposition de la
solution qui répond aux exigences cités tout en détaillant ses modèles conceptuels et ses
architectures ciblés, dans le deuxième chapitre, On va définir les deux concepts qu’indiquent
notre solution, le concept de supervision et le concept de journalisation. Ainsi que réaliser une
étude comparative entre les outils propriétaires et libres les plus utilisés afin de choisir les plus
adoptés entre eux pour l’implémentation de notre application.

Chapitre 2 : Conception de la solution cible
Chapitre 2 : conception de la solution cible
Ce chapitre sera subdivisé en deux parties principales
Nous nous intéresserons dans une première étape à la définition du concept de la supervision
réseaux, nous valoriserons cette partie par une étude comparative entre les outils disponibles
Dans une deuxième étape, nous mettrons les points sur les éléments qui définissent le concept
de centralisation des journaux tout en spécifiant les différentes plates-fromes disponibles
finissant par le choix de l’outil adopté pour notre projet
Chapitre 2
Conception de la solution Cible

Chap2-Partie 1 : Étude conceptuelle de Supervision
16
Partie 1 : Étude conceptuelle de la supervision
1. Introduction
Dans cette présente partie, d’abord nous allons définir la notion de la supervision et ses
objectifs, ensuite nous analyserons les différentes plateformes existantes dans le domaine de la
surveillance réseau, en décrivant leurs avantages et leurs inconvénients par une étude
comparative entre eux, pour arriver enfin à la sélection de la plateforme adoptée pour notre
projet.
2. Monitoring, surveillance réseau informatique
Le monitoring ou monitorage est une activité de surveillance et de mesure d’une activité
informatique. On parle aussi de supervision.
En informatique, la supervision est une technique de suivi, qui permet de surveiller, analyser
rapporter et d’alerter les fonctionnements anormaux des systèmes informatiques.
La supervision informatique consiste à indiquer et/ou commander l’état d’un serveur, d’un
équipement réseau ou d’un service software pour anticiper les plantages ou diagnostiquer
rapidement une panne. [B5]
2.1 Les Objectifs du monitoring
Les objectifs sont multiples :
 Eviter les arrêts de service.
 Remonter des alertes.
 Détecter et prévenir les pannes.
Les raisons peuvent être variées :
 Mesure de performance, en termes de temps de réponse par exemple.
 Mesure de disponibilité, indépendamment des performances.
 Mesure d’intégrité, l’état des processus sur une machine Unix par exemple.
 Mesure de changement, surveillance de sites de News avec Google Actualités.
Exemples d’éléments à superviser :
 Serveurs : CPU, mémoire, processus, espace disque, service.
 Matériels : Disques, cartes Raid, carte réseau, température, alimentation, onduleurs.

17
 Réseau : Bande passante, protocoles, switch, routeurs, firewall, accès externes, bornes
Wi-Fi.
Si je ne supervise pas :
 Je peux être piraté sans le savoir.
 Mes serveurs peuvent être fatigués.
 Mes performances peuvent tomber.
La simple installation de l’outil de supervision ne suffit pas. La clé d’une surveillance réseau
assez efficace, est d’assurer que l’outil de réseau choisi a été configuré pour contrôler les
paramètres essentiels : la disponibilité, la vitesse et la bonne utilisation d’un réseau.
La supervision est une fonction informatique de suivi utilisée pour améliorer l'exploitation des
ressources mis en place à travers l'installation d'un outil sur une machine serveur qui permet
d'analyser, de surveiller, de visualiser, de piloter, d'agir et d'alerter les fonctionnements
anormaux des systèmes informatiques. Son but est de fournir une vision précise sur des
équipements et d'alerter l'administrateur suite à la détection d'un événement indésirable, cette
alerte doit se faire avant que le problème n'engendre des répercussions sur la satisfaction des
clients et la productivité finale des utilisateurs. [B6]
Ainsi, la supervision sert à rentabiliser les activités par une exploitation maximale des
ressources pour un cout minimal tout en offrant un service de qualité aux utilisateurs.
2.2 Domaines de surveillance
La supervision est une tache extensive Concerne tout ce qui est :
 Réseau (débits, bande passante, protocoles...)
 Systèmes (la vérification de l'état des ressources matérielles d'un serveur tel que le CPU
la mémoire, le disque dur...)
 Services (SMTP, FTP, HTTP/HTTPS..).
 Ressources techniques (activité d'un équipement, disponibilité, performance, qualité de
service...).
 Les attaques connues sur un pare-feu par exemple.

18
3. Les outils de monitoring
Plusieurs outils de supervisions peuvent être utilisés, ces outils peuvent être triés selon les
objectifs attendus et précisés par les administrateurs mais aussi par la valeur des équipements
à superviser et par l'impact économique puisque on retrouve toujours des outils gratuits et
d'autres payants. Dans la suite nous présentons quelques solutions.
3.1 Les plateformes éditeurs
Depuis la naissance du terme de supervision, les grands éditeurs de logiciel ont rapidement
compris que la supervision devient un besoin exigé par les entreprises qui essayent toujours de
garantir la disponibilité de leurs services, pour cela les éditeurs de logiciel ont commencé à
développer des outils de surveillance payants au profit de ces entreprises.
Actuellement on retrouve des logiciels de supervision proposés par les plus populaires éditeurs
de logiciel tel que Scom(Microsoft), HP OpenView(HP), IBM Trivoli Monitoring(IBM), BMC
Patrol(BMC).
Dans ce qui va suivre, nous présenterons trois leaders des logiciels payants de supervision :
Scom, HP OpenView et IBM Trivoli Netview
3.1.1 Scom
Scom (System Center Operations Manager) anciennement connu sous le nom de MOM
(Microsoft Operations Manager) est un programme de supervision réseau Microsoft développé
par Microsoft qui permet le monitoring des différents équipements grâce à une interface
logicielle, l'outil peut supporter seulement les matériaux et produits Microsoft (Switch,
serveurs...) [B7]
Figure II- 1 : Interface graphique SCOM

19
3.1.2 HP OpenView
HP OpenView est parmi les logiciels majeurs de la supervision. Il permet la supervision des
équipements réseaux et l'affichage de l'état courant des équipements grâce à une interface
graphique. Un système d'alarme intégré permet de synchroniser tous les équipements et de
communiquer avec les machines par le protocole SNMP.
Le logiciel HP OpenView permet le contrôle d'un réseau distribué depuis un seul point. HP
OpenView envoie des requêtes SNMP périodiques vers les agents, si un état change ou un
périphérique devient injoignable, une alarme est directement déclenchée [B8]
Figure II- 2 : Interface graphique HP OpenView
3.1.3 IBM Trivoli Monitoring
La solution IBM Tivoli Monitoring est conçue pour faciliter la gestion des applications critiques
en surveillant de façon proactive les principales ressources informatiques.
Figure II- 3 : Interface graphique IBM Trivoli

20
IBM Tivoli Monitoring est capable d'apporter la réponse la plus adaptée aux différents
événements et incidents survenant pendant une exploitation informatique, typiquement d’agir
directement sur le composant logiciel ou sur le système (réseau, serveurs, ..) responsable d'un
mauvais temps de réponse. [B9]
3.2 Les plateformes libres
Il existe des solutions de supervision libres et professionnelles. 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 des participations aux forums.
Parmi les plus répandues, reconnues du moment nous pouvons citer Nagios, ZABBIX, EYES-OF-
NETWORK et FAN
3.2.1 Nagios
Anciennement (Net saint) est un logiciel de supervision de réseaux créé en 1999 par « Ethan
Galstad ». Il est considéré comme étant la référence des solutions de supervision Open Source.
C’est un outil très complet pouvant s'adapter à n'importe quel type d'utilisation avec des
possibilités de configuration très poussées. La modularité et la forte communauté (> 250 000)
qui gravite autour de Nagios (en participant au développement de nombreux plugins et addons)
offrent des possibilités en terme de supervision qui permettent aujourd'hui de pouvoir
superviser pratiquement n'importe quelle ressource. [B10]
 Avantages
- La supervision à distance peut utiliser SSH ou un tunnel SSL (notamment via un agent
NRPE).
- Les plugins sont écrits dans les langages de programmation les plus adaptés à leurs
tâches : scripts shell (Bash, ksh, etc.), C++, Perl, Python, Ruby, PHP, C#.
- La remontée des alertes est entièrement paramétrable grâce à l'utilisation de plugins
(alerte par courrier électronique, SMS, etc…).

21
 Inconvénients
- Difficile à installer et à configurer
- Dispose d’une interface compliquée
- Ne permet pas d’ajouter des hosts via Web
- Besoin d’un autre outil comme CACTI pour faciliter sa configuration
- Pas de représentations graphiques
- Les mises à jour de la configuration se font en mode « ligne de commande » et elles
doivent être réalisées côté supervision comme côté équipement à superviser.
3.2.2 Zabbix
Figure II- 4 : Logo Zabbix
C’est un outil de supervision, ambitionnant de concurrencer Nagios et MRTG. Il fait la
supervision technique et applicative, il offre des vues graphiques (générés par RRDtool) et des
alertes sur seuil. C’est une solution de monitoring complète embarquant un front-end web, un
ou plusieurs serveurs distribués, et des agents multiplateformes précompilés (Windows, Linux,
AIX, Solaris). Il est également capable de faire du monitoring SNMP et IPMI ainsi que de la
découverte de réseau. Il repose sur du C/C++, PHP pour la partie front end et
MySQL/PostgreSQL/Oracle pour la partie BDD. [B11]
 Avantages
- Richesse des sondes et tests possibles (supervision d'applications Web, par exemple).
- Réalisation de graphiques, cartes ou screens.
- Configuration par la GUI (interface graphique).
- Mise à jour de la configuration via l’interface Web de Zabbix.
- Serveur Proxy Zabbix.
- Surveillances des sites web: temps de réponse, vitesse de transfert...
 Inconvénients
- Interface est un peu vaste, la mise en place des templates n'est pas évidente au début :
petit temps de formation nécessaire.

22
- L'agent zabbix communique par défaut en clair les informations, nécessité de sécuriser
ces données (via VPN par exemple).
3.2.3 Check _MK
C’est une solution de supervision open source développée par Mathias KETTNER en 2008. En
réalité c’est une extension de Nagios, qui est l’outil de monitoring le plus connu et le plus utilisé
dans les entreprises. [B12]
Figure II- 5 : Logo Check-mk
 Avantages
- Installation et configuration facile
- L’interface Web est beaucoup plus intuitive et elle intègre des outils, comme PNP4Nagios
et RRDTtool.
- L’interface permet une configuration entièrement graphique.
- Check_MK est capable de réaliser un inventaire automatique des services disponibles sur
un hôte à superviser.
- Pas besoin redéveloppé des sondes.
 Inconvénients
- Offre plus de services sur l’environnement Unix
3.2.4 Eyes-Of-Network
Figure II- 6 : Logo Eyes-of-network
Eyes Of Network « EON » est une solution complète de supervision, basée sur la distribution
GNU/Linux CentOS, gérée et administrée via une interface web, qui est accessible par tous les
acteurs d’un système d’informations avec une vue correspondant à chacun de leur métier.[B13]

23
EON est open source et sous licence GPL2, qui englobe plusieurs outils de supervision
monitoring et de gestion, chacun d’eux est spécialisé pour effectuer une tache spécifique de
supervision :
NAGIOS : gestion des incidents et des problèmes
CACTI : gestion des performances
WEATHERMAP : cartographie de la bande passante
BACKUP MANAGER : Outil de sauvegarde de la solution
 Avantages
- Interface de configuration web
- Permet de faciliter le déploiement des outils de supervision
- Noyau linux solide et fiable
 Inconvénients
- Une configuration en interface web qui ne supporte pas la navigation sécurisée (HTTPS)
4. Etude Comparatif
La Comparaison générale des outils de supervision à base open source précédemment
cités a été étudiée en premier lieu avec un diagramme radar en fonction de :
Dynamisme
Ressource
Souplesse et extensibilité
Socle technique
Périmètre fonctionnel
notoriété actuelle
Figure II- 7 : Diagramme radar

24
En deuxième lieu pour mieux enrichir notre étude comparative, nous donnons le tableau
comparatif ci-dessous qui résume les différentes caractéristiques des outils de supervision open
source précédemment cités, qui présentent les points faibles et les points forts de ces derniers.
Ce qui nous aide bien évidemment à prévoir le meilleur choix de la solution adoptée pour la
phase de supervision.
Tableau II- 1 : Tableau comparatif des outils de supervision open source
Critère Fonctionnels EON Nagios Zabbix Check_MK
Environnement de L’installation
Linux
CentOS
Unix Unix Unix
Base de donné MYSQL C++ PHP, C Python
Protocole SNMP SNMP,
ICMP
HTTP, FTP SNMP
Gestion d’authentification et des
rôles
OUI OUI OUI OUI
Création des graphes simple à
partir des mesures
OUI NON OUI OUI
Utilisation d’agents sur les
machines cibles
OUI OUI Agent
Windows/Unix
Check-mk
win
Installation et configuration
simple
OUI NON OUI OUI
Intégration simple des nouvelles
host à superviser
OUI NON OUI OUI
Possibilité de mettre en place une
supervision centralisée entre
plusieurs sous réseaux
OUI NON OUI OUI
Compatibilité avec la plateforme
de virtualisation VMware)
OUI OUI OUI NON
Possibilité d’ajouter les plugins OUI OUI OUI NON
Générer des alertes OUI OUI OUI OUI
Générer des rapports OUI OUI NON NON

25
5. Choix de Plateforme
En se basant, sur l’étude des solutions précédemment citées par le diagramme de Radar opéré
en fonction de quelques critères d’efficacité d’une part, et d’une autre part sur le tableau
comparatif que nous avons présenté tout à l’heure, on a estimé qu’Eyes-Of-Network a été la
solution la plus adaptée aux besoins de notre projet pour plusieurs raisons, En effet Eyes-Of-
network combine deux outils très efficaces et connus dans le domaine de monitoring, chacun
d’eux est spécialisé pour effectuer une tache spécifique de supervision on parle ici de Nagios et
Cacti, en revanche, il inclut d’autres applications intégrées de supervision répondant aux
différents besoins de supervision, qu’on va les détailler plus tard.
Grâce à ses plugins, EON possède une architecture facilement adaptable à l’environnement.
Ces derniers pouvant être ajoutés, modifiés ou même personnalisés et permettent de spécifier
les tâches pour aboutir au résultat voulu. De plus Eyes-of-network est une solution stable
dispose d’une grande communauté de développeurs, et utilisé aussi bien dans les petites et
moyennes infrastructures que dans les grands parcs informatiques. Aussi, utilisé surtout par
plusieurs entreprises renommées, tels que Yahoo (100 000 serveurs), Yellow pipe Web Hosting
(7000 serveurs)
Figure II- 8 : Eyes of network
5.1 Composition d’Eyes-Of-Network
Le “bundle” Eyes-Of-Network est composé d’un système d’exploitation minimaliste incluant un
ensemble intégré d’applications répondant aux différents besoins de supervision [B14] :
 NAGIOS : gestion des incidents et des problèmes,
 THRUK : interface de supervision multibackend,
 NAGVIS : cartographie personnalisée de la disponibilité,
 CACTI et PNP4NAGIOS : gestion des performances,
 WEATHERMAP : cartographie de la bande passante,

26
 BACKUP MANAGER : Outil de sauvegarde de la solution,
 EONWEB : Interface Web unifiée de la solution,
 EZGRAPH : Librairie d’affichage des graphiques,
 SNMPTT : Traduction des traps snmp,
 GLPI / OCS / FUSION : Gestion de parc et inventaire.
Figure II- 9 : Composants d’Eyes-of-network
Au cours de notre projet, nous serions intéressés par un ensemble de ces outils offerts par
Eyes-of-network qu’on va les détailler et les expliquer dans la section suivante
5.2 Architecture d’EyeOfNetwork
Eyes-Of-Network est accessible via une interface Web unique dont l’objectif est de réunir les
différents acteurs d’un système d’informations (DSI, Administrateurs, Techniciens, Opérateurs)
Chacun de ces acteurs dispose d’une vue correspondant à son métier. Toutes les informations
sont consolidées en Base de Données MYSQL [B14].

27
Figure II- 10 : Architecture d’EyeOfNetwork
5.2.1 Programmes-plugins
Eyes-of-Network fonctionne grâce à des plugins. Sans eux, il est totalement incapable de
superviser et se résume en un simple noyau. Ces plugins sont des programmes externes au
serveur, des exécutables qui peuvent se lancer en ligne de commande afin de tester une station
ou service. Ils fonctionnent sous le principe d’envoi de requêtes vers les hôtes ou services
choisis lors d’un appel du processus de Eyes-of-Network, et la transmission du code de retour
au serveur principal qui par la suite se charge d’interpréter les résultats et déterminer l’état de
l’entité réseau testée.
La relation entre le noyau et les plugins est assurée d’une part par les fichiers de configuration
(définitions des commandes) et d’autre part par le code retour d’un plugin.
5.2.2 Les fichiers de configuration
Eyes-of-Network s'appuie sur différents fichiers textes de configuration pour construire son
infrastructure de supervision. Nous allons à présent citer et définir ceux qui sont les plus
importants :
 Eyesofnetwork.cfg est le fichier de configuration principal d’Eyes-of-network. Il contient
la liste des autres fichiers de configuration et comprend l'ensemble des directives
globales de fonctionnement.

28
 Hosts.cfg définit les différents hôtes du réseau à superviser. A chaque hôte est associé
son nom, son adresse IP, le test à effectuer par défaut pour caractériser l'état de l'hôte,
etc.
 Contacts.cfg déclare les contacts à prévenir en cas d'incident et définit les paramètres
des alertes (fréquences des notifications, moyens pour contacter ces personnes, plages
horaires d'envoi des alertes...)
5.2.3 Compléments d’Eyes-Of-Network
Eyes-Of-Network inclut les outils suivants :
 Supervision réseau : NAGIOS + NAGIOSBP + NAGVIS
 Gestion des performances : CACTI + WEATHERMAP
 Interface d’EON: Interface de configuration web et mesure de qualité de service
Figure II- 11 : Outils d’Eyes-Of-Network
Pour la partie supervision de notre projet nous serions intéressés par les quatre éléments
suivants :
 Nagios : dont le rôle est de superviser notre architecture réseaux et la mesure des
disponibilités
 Cacti : c’est pour la mesure de performance
 Wethermap : cartographie de la bande passante
 NagVis : cartographie personnalisée de la disponibilité

29
5.2.3.1 NAGIOS
Nagios (anciennement appelé Netsaint) est une application de monitoring libre (open source)
permet de surveiller l'état de divers services réseau et systèmes, sa fonction principale est
d'alerter l'administrateur suite à la détection d'un événement indésirable d'un équipement et
d'offrir une vision précise sur les hôtes et services à superviser via un simple navigateur. On
retrouve actuellement plusieurs logiciels qui sont basés sur Nagios tel que Centreon, Eyes of
network. [B10]
Nagios est un programme modulaire composé par le moteur de l'application, l'interface web et
les sondes (appelées greffons ou plugins), le moteur de l'application contrôle les équipements
spécifiés par les sondes, un statut d'état sera retourné à Nagios, suite à la détection d'un
problème, une alerte (email, SMS,...) doit être envoyée à l'administration.
Figure II- 12 : Interface graphique de Nagios
 Les qualités de Nagios
- Supervision des services réseaux (SMTP, POP3, HTTP, NNTP, PING, etc.).
- Supervision des ressources des hôtes (charge du processeur, utilisation du disque, etc.).

30
- Un système de plugins permettant aux développeurs facilement de développer des
modules de surveillance.
- L'utilisation du protocole SNMP pour superviser de nombreux types d'équipements.
- Notifications à des contacts de l'apparition ou de la disparition de problèmes sur les
hôtes ou les services (via email, pager, ou toute méthode dénie par l'utilisateur).
- Acquittement des alertes par les administrateurs.
- Limitation de la visibilité, les utilisateurs peuvent avoir un accès limité à quelques
éléments.
5.2.3.2 CACTI
CACTI est une solution de monitoring complète basée sur RRDTOOL (c'est un outil de gestion de
base de données RRD (Round-Robin database) créé par Tobias Oetiker). Il peut être considéré
comme le successeur de MRTG (Multi Router Tra-c Grapher) et également comme une
interface d'utilisation de RRDTool. [B14]
Parmi les facteurs de réussite de cette solution, le tracé du graphique sur toutes les métriques
numériques possibles d'un équipement. CACTI est utilisée par plusieurs outils open source, tels
que lighttpd, et Nagios.
Le RRDTool est un logiciel de stockage des données dans une base de données RRD, il permet
de les utiliser pour créer des graphiques, des données peuvent être obtenues auprès des
différents agents SNMP ou avec l'utilisation de système de script grâce à un script PHP.
Figure II- 13 : Interface graphique CACTI

31
 Les qualités de CACTI
- La simplicité d'installation.
- L'utilisation de Cacti n'exige pas d'être expert des systèmes de monitoring.
5.2.3.3 Wethermap
Weathermap est un outil de visualisation de réseau open source, pour prendre des données
que nous avons déjà et nous montrer un aperçu de notre activité réseau sous forme de carte.
Weathermap est largement utilisé par les FAI nationaux et internationaux, les opérateurs Tiers
les échanges Internet, les opérateurs téléphoniques, les réseaux académiques nationaux, de
nombreuses entreprises du Fortune 500 dans la finance, l'automobile, le médical /
pharmaceutique et d'autres secteurs. [B15]
Figure II- 14 : Vue de la carte Wethermap
5.2.3.4 NagVis
NagVis est une addition de visualisation pour le système de gestion de réseau bien connu
Nagios. Il peut être utilisé pour visualiser des données Nagios, par exemple pour afficher des
processus informatiques comme un système de messagerie ou une infrastructure réseau.
Grâce à NagVis, on peut visualiser l'état global des branches de notre architecture réseaux en
utilisant des cartes incluses dans NagVis. [B16]
Figure II- 15 : Vue de la carte Nagvis

32
6. Conclusion
Tout au long de cette première partie du deuxième chapitre, nous avons essayés d’abord, de
définir la notion de monitoring réseau et réaliser une étude comparative entre les outils de
supervision les plus utilisés finissant par le choix de la solution adéquate pour l’implémenter
dans notre projet, subséquemment nous avons présentés les composants el les extensions de
la solution choisie, achevé par une explication détaillée du principe de fonctionnement de
chacun d’eux.

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux
33
Partie 2 : Étude conceptuelle de la centralisation des
journaux
1. Introduction
Le but de cette deuxième partie et de définir la notion de « centralisation des journaux », ainsi
que présenter les techniques et les recherches actuelles qui sont utilisées et développées dans
le domaine de la gestion des journaux, comment ces outils sont utilisés pour analyser ces
fichiers journaux.
Elle développera également la comparaison des outils de centralisation des journaux
actuellement disponibles par rapport à la fonctionnalité désirée pour arriver à la solution la plus
appropriée
2. Centralisation des journaux
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. [B17]
2.2 Journalisation locale
De nombreux serveurs et systèmes d'exploitation des clients, des commutateurs de réseau,
routeurs, pare-feu, et d'autres équipements de réseau ont la capacité de produire des journaux
en les envoyant à travers le réseau. En fonction de la taille et de la complexité de
l'infrastructure informatique comme on peut le voir dans la figure ci- dessous

34
Figure II- 16 : 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.
2.3 Centralisation des journaux
Le fait de centraliser les logs permet de sécuriser le réseau, d’avoir la meilleure gestion du
système d’information possible et d’avoir une vue d’ensemble de tous les éléments importants
sur le réseau. Certains messages sont anodins, tandis que d’autres peuvent être très
importants, c’est pour cela que la centralisation va faciliter la recherche et l’analyse, qui
pourront ainsi être à la fois très précises et concises sur les activités de plusieurs systèmes, car

35
tout se trouvera au même endroit. De plus, la centralisation sera utile pour détecter les
événements anormaux sur le réseau ou sur les systèmes de tout type en utilisant les logs.
Ils pourront retracer le parcours d’une attaque plus facilement car ils seront d’une part tous
regroupés et d’autre part exportés de la zone d’effet de l’attaquant, il sera donc difficile pour 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.
3. Système de gestion des évènements
Actuellement, il existe trois types d'environnements définis sur les systèmes de gestion des
événements: [B18]
 SEM (Security Event Management)
 SIM (Security Information Management)
 SIEM (Security Information and Event Management)
3.1 SEM (Gestion des événements de sécurité)
Ces produits offrent une gestion des événements, une analyse des menaces en temps réel, une
visualisation, une billetterie, une réponse aux incidents et des opérations de sécurité. Ils sont
généralement basés sur des bases de données SQL d'entreprise telles qu'Oracle.
3.2 SIM (Gestion de l'information de sécurité)
Security Information Management, un type de logiciel qui automatise la collecte des données
du journal des événements à partir des dispositifs de sécurité, tels que les pare-feu, les serveurs
proxy, les systèmes de détection d'intrusion (IPS, IDS) et les logiciels antivirus.

36
3.3 SIEM (Informations sur la sécurité et gestion des événements)
Ces produits combinent des capacités SIM et SEM, les produits SIM sont simples à déployer et à
utiliser, tandis que les produits SEM sont plus complexes.
La technologie SIEM fournit une analyse en temps réel des alertes de sécurité générées par le
matériel et les applications réseau. Les solutions SIEM sont fournies sous forme de logiciels
d’Appliance ou de services gérés. Elles sont également utilisées pour consigner les données de
sécurité et générer des rapports à des fins de conformité.
Figure II- 17 : Architecture SIEM
SIEM décrit les capacités du produit de rassembler, analyser et présenter l'information des
dispositifs de :
 Réseau et sécurité
 Applications de gestion d'identité et d'accès
 Outils de gestion de la vulnérabilité et de conformité aux politiques
 Systèmes d'exploitation

37
 Bases de données
 Journaux d'application
 Données sur les menaces externes
Un objectif clé de SIEM est de surveiller et d'aider à gérer les privilèges des utilisateurs et des
services, les services d'annuaire et d'autres changements de configuration du système; ainsi
que fournir l'audit et l'examen de journal et la réponse aux incidents.
4. Produit SIEM
Il existe un certain nombre d'outils SIEM sur le marché, à la fois open source et commercial.
Avec la montée en puissance de DevOps, de conteneurs et d'autres méthodes de
développement d'applications modernes, les solutions Open Source connaissent un regain
d'intérêt. Jetons un coup d'œil sur certains des meilleurs outils SIEM open source.
4.1 Graylog
Graylog est un logiciel libre développé et écrit en langage Ruby et Java par Lennart Koopmann
en mai 2010, qui permet de centraliser tous les logs d’un parc informatique sur une seule
plateforme, avec des modules de traitements et de mise en page. [B19]
Figure II- 18 : Logo graylog
Une importante communauté s'est fondée autour de cette solution, grâce au suivie régulière
des développeurs. Actuellement la version 2.0 est sortie en Avril 2016. Son but est de pouvoir
répondre rapidement en cas de problème sur le parc informatique. Il a une plage d’action large.
Il peut prévenir l’apparition d’un problème, nous prévenir lorsqu’un problème survient, et il
permet d'analyser les derniers logs de la machine si elle s‘est éteinte subitement. La suite
Graylog est alors composée de quatre parties :
 Elasticsearch permettant le stockage des logs et la recherche textuelle.
 MongoDB qui assure la gestion des métadonnées.
 Le serveur Graylog qui va recueillir les logs sur différents protocoles: UDP, TCP…
 Et l’interface web de Graylog, qui permettre de consulter les logs

38
Figure II- 19 : Architecture Graylog
4.2 Fluentd
Fluentd est un outil open source permettant de collecter des événements et des journaux. Son
architecture permet de collecter facilement les journaux provenant de différentes sources
d'entrée et de les rediriger vers différents récepteurs de sortie. Certains exemples d'entrée sont
des journaux HTTP, syslog ou apache, et certains puits de sortie sont des fichiers, du courrier et
des bases de données (aussi bien SGBDR que NoSQL). Aussi, il permet d'analyser les logs et
d'extraire seulement les parties significatives de chacun d'eux; La sauvegarde de ces
informations structurées sur une base de données permet une recherche et une analyse
beaucoup plus simples. [B20]
Figure II- 20 : Logo Fluentd
Fluentd se compose de trois éléments de base:
Figure II- 21 : Architecture Fluentd

39
 Input: recevoir et extraire les journaux de la source de données
 Buffer: assure la fiabilité. Lorsque la sortie échoue, les événements sont conservés par
la mémoire Buffer et automatiquement rejugé.
 Output: transmettre les journaux d’évènement vers le service de stockage
4.3 ELK stack
ELK stack est une solution de centralisation et d’analyse de journaux, proposée par l’entreprise
Elastic. ELK stack se compose des trois logiciels suivants : Elasticsearch, Logstash et Kibana.
[B21]
Figure II- 22 : ELK-stack
 Logstash
Est un outil de gestion des logs. Il prend en charge pratiquement tous les types de journaux
y compris les journaux système, les journaux d'erreurs et les journaux d'applications
personnalisées. Il peut recevoir des journaux provenant de nombreuses sources, y compris
syslog, messagerie (par exemple, rabbitmq) et jmx, et il peut produire des données de
différentes manières, y compris par courrier électronique, websockets et Elasticsearch.
 Elasticsearch
Est un moteur de recherche et d'analyse en texte intégral et en temps réel qui stocke les
données de journal indexées par Logstash. Il est construit sur la bibliothèque du moteur de
recherche Apache Lucene et expose les données via les API REST et Java. Elasticsearch est
évolutif et est conçu pour être utilisé par les systèmes distribués.
 Kiabana
Est une interface graphique basée sur le Web permettant de rechercher, d'analyser et de
visualiser les données du journal stockées dans les index Elasticsearch. Il utilise l'interface REST
d'Elasticsearch pour extraire les données, aussi il permet aux utilisateurs de créer des vues de
tableau de bord personnalisées de leurs données, mais leur permet également d'interroger et
de filtrer les données de manière ad hoc.

40
5. Analyse comparative
La comparaison des plateformes de centralisation et d’analyse des journaux a base
open source précédemment cités a était étudiés par deux tableaux comparatif dont le
but est de mieux choisir la plateforme la plus adopté pour notre solution
5.1 Caractéristiques
Le premier tableau comparatif ci-dessous a été effectué en fonction de caractéristiques.
Tableau II- 2 : Tableau comparatif SIEM - caractéristique
Plateforme ELK-Stack Graylog Fluentd
Langage JavaScript Java / Ruby Rubis
Licence Apache 2.0 GPLv3 Apache 2.0
Protocole
UDP BSD Syslog, UDP
syslog IETF, IETF TCP,
GELF
BSD et syslog IETF,
FAES, GELF via Http
AMQP
HTTP, AMQP, OMQ
Kafka
Stockage Elastic-Search
Elastic-Search ,
MongoDB
Elastic-Search
Indexation Elastic-Search Elastic-Search Elastic-Search
Transport TCP, UDP TCP, UDP TCP, UDP
5.2 Fonctionnement
On vous présente simultanément, un deuxième tableau, qui réalise une comparaison en
terme de :
 Installation
 Configuration
 Fonctionnalités

Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )

Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )

Similaire à Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 ) (20)

Dernier

Dernier (7)

Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )