Rapport Final Pfe (Saadaoui Marwen)

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
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.
1
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
2
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.
3
Chapitre 1
Cadre générale du projet
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.
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².
5
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 :
6
 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
7
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
8
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
9
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
10
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.
11
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.
12
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

13
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.
14
Chapitre 2 : Conception de la solution cible
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
Chap2-Partie 1 : Étude conceptuelle de Supervision
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.
16
 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.
17
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

18
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
19
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…).
20
 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.
21
- 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]
22
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
23
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
Linux Unix Unix Unix

Environnement de L’installation
CentOS
Base de donné MYSQL C++ PHP, C Python
SNMP SNMP, HTTP, FTP SNMP

Protocole
ICMP
Gestion d’authentification et des OUI OUI OUI OUI
rôles
Création des graphes simple à OUI NON OUI OUI
partir des mesures
Utilisation d’agents sur les OUI OUI Agent Check-mk
machines cibles Windows/Unix win
Installation et configuration OUI NON OUI OUI
simple
Intégration simple des nouvelles OUI NON OUI OUI
host à superviser
Possibilité de mettre en place une
supervision centralisée entre OUI NON OUI OUI
plusieurs sous réseaux
Compatibilité avec la plateforme OUI OUI OUI NON
de virtualisation VMware)
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
24
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,
25
 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].
26
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.
27
 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é
28
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.).
29
- 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
30
 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
31
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.
32
Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux
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
33
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
34
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.
35
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
36
 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
37
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
38
 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.
39
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
UDP BSD Syslog, UDP BSD et syslog IETF,

HTTP, AMQP, OMQ
Protocole syslog IETF, IETF TCP, FAES, GELF via Http
Kafka
GELF AMQP
Elastic-Search ,
Stockage Elastic-Search Elastic-Search
MongoDB
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
40
Tableau II- 3 : Tableau comparatif SIEM- Fonctionnement
Plateforme ELK-Stack Fluentd Graylog
L’installation est un Installation similaire

Installation simple, en
peu complexe mais à ELK (Graylog utilise
créant un compte sur le
reste relativement également Elastic-
Installation site officiel et en
simple grâce à la Search), avec une
récupérant le fichier
documentation en bonne
d’installation
Ligne documentation.
Configuration un peu Configuration simple

complexe car il faut et similaire à Fluentd
Configuration simple qui se
configurer Logstash car elle se fait là aussi
Configuration fait depuis l’interface Web
(il faut donc maîtriser depuis l’interface
un minimum les web.
langages de script)
Simple pour utilisation Utilisation basique
Syntaxe de recherche basique, il suffit de taper le simple, similaire à
Recherche avancée basée sur la mot clé recherché pour Fluentd et ELK.
syntaxe Lucene. qu’il s’affiche en Syntaxe proche de
surbrillance. Lucene.
Dashboard interactif Dashboard facile à
Dashboard non interactif.
par défaut. Barre de créer et à modifier
Barre de recherche et
recherche et barre de mais ils ne sont pas
temps non disponible par
temps toujours interactif et la barre
Dashboard défaut. Il faut configurer les
disponible. de recherche /
Dashboard pour les rendre
Dashboard facile à temps n’est pas
compatible avec les
créer et à modifier. disponible. Point
affichages
Point fort d’ELK. faible de Graylog.
41
6. Choix de plateforme
En partant de l’étude comparative énoncée au paragraphe précédent, nous avons décidé de
choisir la solution ELK. Dans la section suivante nous réaliserons une étude détaillée sur cette
dernière.
6.1 Présentation générale de la solution ELK stack
ELK stack est une solution open source complète, ou plutôt plateforme complète
d’administration des réseaux et du management du système informatique.
ELK stack utilise plusieurs produits issus de la même stratégie (Open Source) afin d’y intégrer
une infrastructure de monitoring en temps réel de la sécurité du réseau d'où l'intérêt de mettre
en place des outils d'analyse des logs applicatifs comme la suite ElasticSearch.
ElasticSearch, Logstash et Kibana : ces trois outils ont chacun un rôle bien précis dans le
workflow permettant de passer des logs bruts au format fichier à des Dashboard avec
graphiques et statistiques, qui montreront de manière synthétique le contenu des logs.
C’est une plateforme d’administration et supervision réseau, de management de la société de

l’informatique et de la gestion instantanée des activités et des événements survenues sur le
réseau informatique.
ELK stack assure les fonctionnalités d’un SIEM :
 La collecte des Logs

 L’agrégation
 La normalisation
 La corrélation
 Le reporting
 L’archivage
 Le rejoue des évènements
6.2 Le principe technique de la solution ELK stack
La stack ELK transforme des flux de données brutes en un ensemble de données structurées.
Cela inclut donc bien plus que des logs d'erreurs : on peut aussi l'utiliser pour vérifier le bon
fonctionnement de son application en analysant ses propres fichiers de logs.
Les différentes étapes de la transformation par le serveur sont :
42
1. La réception du flux d'informations brutes provenant des fichiers de logs

2. L’analyse du flux à l'aide d'un filtre présent sur le serveur
3. Le découpage de chaque ligne selon un pattern grok défini dans le filtre
4. Le stockage des informations structurées dans Elasticsearch.
6.3 Architecture d'ELK stack
Figure II- 23 : Architecture ELK-Stack
L’architecture de la stack est assez simple : des shippers s’occupent de récupérer les logs, un ou
plusieurs nœuds Logstash découpent les logs en éléments sémantiques (un timestamp, un
serveur, une action, un résultat, un code de retour, …) et le transmettent à Elasticsearch, un ou
plusieurs noeuds Elasticsearch indexent et stockent, Kibana gère la présentation en se basant
sur les données lues dans Elasticsearch [B22].
6.4 Les composants d'ELK stack

6.4.1 ElasticSearch
6.4.1.1 Présentation d’ElasticSearch
Elasticsearch est un moteur de recherche et d'indexation Open Source nouvelle génération.

Basé sur la librairie Apache Lucene, ce moteur de recherche offre des fonctionnalités avancées
telles que les recherches par coordonnées géographiques, l'analyse et la catégorisation par
43
agrégations, le filtrage de résultats ou encore la recherche sur plusieurs index et types de

documents différents. Taillé pour le Cloud, ElasticSearch a été spécialement conçu pour indexer
de très gros volumes de données tout en assurant une montée en charge performante et une
forte tolérance aux pannes.
6.4.1.2 Moteur de recherche et moteur d'indexation
Si nous parlons de moteurs de recherche, nous citons certainement Google, Bing...qui sont des
applications web permettant de retrouver des liens, des images...
Cependant, pour pouvoir donner des résultats pertinents, un moteur de recherche doit savoir à
l’avance où sont les ressources que nous pourrions lui demander. Pour le savoir, de nombreux
moteurs de recherche ont des robots qui parcourent Internet à la recherche de nouvelles
ressources. Ils se basent donc sur des moteurs d’indexation, dont le rôle est de collecter des
ressources, et d’extraire les mots-clés les plus significatifs. Un moteur d’indexation n’est donc
qu’un sous ensemble du moteur de recherche.
Tandis que les géants du Web utilisent des moteurs d’indexation propriétaires, dans le monde
de l’open source, Apache Lucene, une bibliothèque d’indexation développée en Java s’est fait
une grosse réputation, et est devenue aujourd’hui le standard sur lequel se basent les meilleurs
moteurs d’indexation. C’est le cas d’Elasticsearch, lui aussi basé sur Apache Lucene, qui est
aujourd’hui un des meilleurs moteurs d’indexation du marché.
6.4.1.3 Les fonctionnalités d'ElasticSearch

 La réplication des données
Dans un cluster Elasticsearch, lorsque vous avez plusieurs nœuds, les données stockées sur ces
derniers sont répliquées entre elles. Ceci permet entre autres de conserver l’intégralité des
données en cas de perte d’un nœud.
La réplication est faite de manière automatique. Rajouter un nœud ou un shard déclenche la

réplication automatique.
 La recherche en temps réel et contextuelle
La recherche dans Elasticsearch est l’une des plus performantes du marché. Nous parlons de
recherche distribuée. Quand nous lançons une recherche sur le nœud principal, ce dernier va
renvoyer la recherche sur les autres nœuds et les résultats seront renvoyés au demandeur.
44
L’une des particularités du moteur est qu’il regroupe les éléments indexés en rapprochant
selon le contexte de la donnée.
 Les facettes
Elasticsearch supporte les facettes, qui sont des regroupements de résultats de recherche. Ce
qui permet aux utilisateurs d’avoir une vue agrégée de leurs données. Il existe plusieurs types
de facettes disponibles dans Elasticsearch, parmi lesquelles :
 Filter : renvoie le nombre de hits correspondant à un filtre.

 Geo distance : regroupe les données par intervalle de distance géographique.
 Query : renvoie le nombre de hits correspondant à une requête.
 Terms : renvoie les termes les plus fréquents.
 Statistical : permet de calculer les données de type somme, minimum, moyenne,
maximum, variance, etc. sur des données de type numériques.
6.4.2 Logstash
6.4.2.1 Présentation de Logstash
Cet outil permet de mettre en place l’analyse des logs. Les points d’entrée (input) utilisés pour
aller chercher l’information sont définis via un fichier de configuration. Plusieurs types de point
d’entrée peuvent être choisis, notamment les fichiers : dans ce cas, on indique à Logstash
l’emplacement où aller lire les fichiers de log. Logstash lit ensuite ces fichiers ligne par ligne. Il
est alors possible d’appliquer certains “filtres” sur ces lignes : il ne s’agit pas seulement de
sélectionner certaines informations et d’en écarter d’autres, mais également de faire des
opérations plus complexes, comme du mapping. Par exemple dans le cas d’un log avec UID, il
est possible de résoudre l’ID en “Nom, Prénom” en faisant un appel externe. Il est également
possible d’extraire des informations spécifiques et les stocker dans des champs spécifiques, ou
encore d’exécuter du code Ruby. Autre exemple : le filtre GROK permet d’extraire des
informations à l’aide de RegEx (expressions régulières) pour matcher certains patterns, comme
un numéro de version.
Une fois que les points d’entrée et les filtres sont définis, on indique à Logstash où envoyer les
résultats : plusieurs points de sortie, ou adaptateurs, peuvent être définis.
Le plus utilisé est Elasticsearch, mais il pourrait s’agir d’une BDD, ou d’un fichier… Logstash est
bien un ETL (Extract Transform Load, des entrées, des sorties, un traitement entre les deux).
45
6.4.2.2 Principe de fonctionnement de Logstash

Logstash fonctionne sur un principe simple, un peu comme un routeur de messages. Il est
possible de parler de chaînes de liaisons entre ces différents composants.
Figure II- 24 : Principe de fonctionnement Logstash
Tous les différents éléments que nous allons détailler sont implémentés sous forme de plugins
ce qui rend très facile d’ajouter des possibilités à Logstash. La liste de ces plugins ne cesse
d’ailleurs de croître.
 Les entrées
Logstash accepte à peu près tout ce qui peut être représenté sous forme de chaîne de
caractères en entrée; texte, nombre, date…. La liste des entrées disponibles est
impressionnante et couvre des plugins particuliers pour Collectd, Graphite, websocket, les
interruptions SNMP et même l’IRC.
Des plugins plus génériques sont bien sûr disponibles comme Syslog, AMQP pour recevoir des
messages depuis ce genre de bus messages.
 Les encodeurs/décodeurs
Les codecs sont arrivés pour pouvoir normaliser et packager un ensemble de filtres. Il existe de
nombreux codecs dont Graphite pour encoder/décoder le format natif des métriques
Graphite ou encore Netflow, qui permet l’encodage, décodage des flux Netflow, très utilisé
pour la supervision réseau.
 Les filtres
Les filtres permettent de triturer tout message arrivant dans Logstash. Par triturer, nous
entendons découper un message en plusieurs parties et inversement, formater les dates
46
normaliser le nom des champs mais pas seulement. Au programme, des filtres pour créer des
sommes de contrôles, extraire des nombres, supprimer des messages avant stockage et bien
sûr Grok.
Grok est sûrement l’un des plus puissants et permet de structurer n’importe quel message,
comme des logs Apache 2 par exemple. Sa force réside dans sa capacité à construire des
expressions complexes à partir d’expressions régulières plus simples.
%{SYSLOGHOST:syslog_hostname}
Dans l’exemple ci-dessus, SYSLOGHOST est une expression Grok qui permet de capturer une
partie du message correspondant aux expressions régulières nécessaires pour reconnaître un
nom d’hôte FQDN.
 Les sorties
Une fois que Logstash a opéré sur les messages, ceux-ci peuvent désormais être routés vers les
plugins de sortie qui permettent d’envoyer les messages vers un bon paquet d’outils tierces, en
plus de la sortie de Logstash, à savoir Elasticsearch.
6.4.3 Kibana
6.4.3.1 Présentation de Kibana
Kibana est le dernier outil de notre suite destinée à l’analyse des logs applicatifs : les données
brutes sont analysées dans Logstash, stockées dans Elasticsearch, mais ne sont pas encore
exploitables.
Kibana qui est une interface homme machine permettant de consulter les documents d’une
base Elasticsearch et d’en sortir des tableaux de bords, qui nous permettent de juxtaposer les
visualisations que nous avons créées
6.4.3.2 Principe de fonctionnement de Kibana

Kibana est une interface Web qui se connecte au cluster Elasticsearch, et permet de faire des
requêtes en mode texte pour générer des graphiques (histogrammes, barres, cartes…), ou des
statistiques. De nombreux composants graphiques sont disponibles pour donner une dimension
visuelle aux données stockées dans Elasticsearch. La création de tableaux de bord est intuitive
grâce à une interface WYSIWYG (pas de code à créer). Les tableaux de bord ainsi générés sont
exploitables par les développeurs, les profils techniques, mais aussi par les interlocuteurs du
métier ou les managers.
47
7. Conclusion
La deuxième partie de ce chapitre, a été consacrée pour la définition des systèmes SIEM et de
la notion de centralisation des journaux, ainsi que la réalisation d’une étude comparative entre
les produits SIEM les plus utilisés, finissant par le choix de la solution Appropriée à
l’accomplissement du notre projet.
Tout le long de ce deuxième chapitre, on a mis le point sur les éléments les plus importants de
notre projet, nous passerons dans le prochain chapitre à la simulation de quelques méthodes
implémentées dans la solution envisagée.
48
Chapitre 3
Émulation de la topologie de la
solution
Même si la majorité de notre travail est simulée, puisqu’il est impossible de fournir de
nouveaux équipements sophistiqués et assez chers. Nous avons dépensé tout ce qu’on a
comme enthousiasme pour avoir le résultat le plus proche de la réalité
1. Introduction
Après une présentation de solution proposée et des différents outils utilisés pour la supervision
et la centralisation des journaux pour fournir une étude théorique sur le projet, nous allons
attaquer dans ce chapitre la phase de simulation de la topologie cible du projet, en simulant la
Backbone IP/MPLS de SOTETEL en utilisant l’outil de virtualisation des réseaux GNS3.
2. Environnement de simulation
2.1 Prérequis Matériels
Pour réaliser cette partie, nous avons utilisés un ordinateur portable présentant les
caractéristiques suivantes :
 Processeur : Intel® Coré™ i5 CPU

 Mémoire installé (RAM) : 8Go
 Type de système : Système d’exploitation 64 bits
 Système d’exploitation : Windows 10
2.2 Prérequis logiciel
Nous avons une multitude d’outils de simulation de réseaux, quoi qu’une minorité prenne en
charge la mise en œuvre de MPLS. C’est pour cette raison que nous avons choisi GNS3. En effet
ce dernier présente plusieurs avantages. Parmi lesquels nous citons :
 Il s’agit d’un logiciel Open source et multiplateformes supportant MPLS et ses dérivés
(VPN/VRF).
 Il peut être lié aux logiciels permettant l’émulation de machines telle que VirtualBox et
VMware et il supporte la connexion aux réseaux physiques.
 Il charge de véritables images IOS des routeurs Cisco dans un environnement virtuel.
En fin, il est nécessaire d’insister sur le terme émulation, dans la mesure où GNS3 s’appuie sur
de véritable IOS téléchargeables et leur confère l’intégralité des fonctionnalités d’origine
contrairement aux autres outils qui sont des simples simulateurs limités aux fonctionnalités
implémentées par les développeurs de ces outils.
Figure III- 1 : LOGO GNS3

50
GNS3 (Graphical Network Simulator) est un simulateur d'équipements Cisco libre qui
fonctionne sur de multiples plateformes, incluant Windows, Linux, et Mac. GNS3 est capable de
faire fonctionner des routeurs Cisco virtuellement en les rendant totalement réels. Le contact
avec le routeur se fait via une liaison console coté routeur et l’affichage est avec l’outil Putty,
les routeurs doivent avoir un système d’exploitation appelé IOS. Contrairement à certains
autres produits comme le Packet Tracer proposé par l’équipementier CISCO. L’un des avantages
de GNS3 c’est qu’on peut capturer et sniffer le trafic transitant sur une interface à l’aide de
Wireshark. [B23]
3. Présentation de la topologie du Backbone
Avant de commencer l’implémentation de la topologie sous GNS3, nous allons évoquer la

structure du Backbone de SOTETEL sur l’échelle nationale. Ce dernier est composé de 9 LSR et
18 LER répartis comme suit :
 4 LSR situés dans la capitale, à Kasbah, Belvédère, Ouardia et Hached.

 5 LSR répartis à Gabes, Sfax, Sousse, Kairouan et Béja.
 9 LER situés au voisinage des LSR ainsi présentés.
 9 LER situés dans La Marsa, Menzah, Ariana, Bardo, Bizerte, Ben Arous, Nabeul,
Moknine et Gafsa.
Pour des raisons liées aux performances de la machine physique, nous avons réduit la topologie
du Backbone afin de mener notre simulation dans de bonnes conditions. La figure ci-dessous
montre la topologie du Backbone.
Figure III- 2 : Maquette de simulation
51
Comme il est montré par la figure, l’architecture de notre maquette comporte 3 routeurs qui
forment la partie cœur du Backbone, 1 Provider « P » et 2 Provider Edge (PE1 et PE2), ainsi que
4 clients (CPE11, CPE12, CPE21 et CPE22) pour la connexion des clients.
 CPEi,j : ( i : représente le Client et j : représente le numéro de site)

 Tous les routeurs sont de type Cisco, la gamme 7200 utilisant comme image IOS
« c7200-advipservicesk9-mz.152-4.S5.bin» supportant la technologie MPLS
3.1 Technologies et plateformes utilisées
On a choisi pour cette tache les technologies suivantes :

 OSPF pour le routage intra-area (PE/P) et inter-areas (CPE/PE)
 MPLS avec activation de CEF (Cisco Expressing Forwarding)
 LDP pour la distribution des labels au sein du réseau dorsal
 OSPF-TE comme protocole de routage intra-nuage à contrainte de liens
 MP-BGP en guise de protocole d’activation des sessions VPNv4 pour l’échange des
routes des VPN entre PE
3.2 Méthodologie d’approche
Tout au long de cette partie on a suivi cette démarche, décrite généralement par :
 Configuration de base des interfaces
 Configuration de protocole de routage de la zone backbone (OSPF intra-areas)
 Configuration de l’MPLS
 Mise en place des VPN
 Mise en place du protocole de routage aux niveaux des clients (OSPF inter-areas)
 Configuration du MP-BGP pour les VPN layer3
3.3 Plan d’adressage
Pour envisager le plan d’adressage, nous devons nous intéresser principalement à deux
éléments importants à savoir :
3.3.1 Coté Backbone

La plage d’adresses 10.1.1.0/24. Ainsi, nous utiliserons pour les sous réseaux du backbone des
adresses appartenant à la dite plage. Donc la distribution se fera comme suit :
 PE1 – Provider : 10.1.1.0/30
 PE2 – Provider : 10.1.1.8/30
52
 Loopback0 de PE1 : 1.1.1.1/32

 Loopback0 de PE2: 2.2.2.2/32
 Loopback0 de Provider : 3.3.3.3/32
3.3.2 Coté Client
Nous utiliserons la plage d’adresse 172.16.0.0/16 pour les LAN et la plage d’adresse
192.168.1.0/24 pour le WAN. La distribution d’adresses sera comme suit :
 CPE11 –PE1 : 192.168.1.0/30

 CPE21 –PE1 : 192.168.1.4/30
 CPE12 –PE2 : 192.168.1.8/30
 CpE22 –PE2 : 192.168.1.12/30
 Loopback0 de CE11 : 172.16.11.11/32
 Loopback0 de CE12 : 172.16.12.12/32
 Loopback0 de CE21 : 172.16.21.21/32
 Loopback0 de CE22 : 172.16.22.22/32
3.3.3 Table d’adressage
Le tableau ci-dessous récapitulera l’adressage des différentes interfaces des routeurs
implémentés :
Tableau III- 1 : Adressage de la maquette
Routeur Interface Adresse IP

G0/0 Connect to PE1 192.168.1.2/30
CPE11
Loopback0 172.16.11.11/32
G0/0 Connect to PE2 192.168.1.10/30
CPE12
Loopback0 172.16.12.12/32
G0/0 Connect to PE1 12.168.1.6/30
CPE21
Loopback0 172.16.21.21/32
G0/0 Connect to PE2 192.168.1.14/30
CPE22
Loopback0 172.16.22.22/32
Loopback0 1.1.1.1/32
G0/0 Connect to Provider 10.1.1.1/30
PE1
G1/0 Connect to CPE21 192.168.1.5/30
G2/0 Connect to CPE11 192.168.1.1/30
53
G0/0 Connect to Provider 10.1.1.10/30
PE2
G1/0 Connect to CE12 192.168.1.9/30
G2/0 Connect to CE22 192.168.1.13/30
Provider G0/0 connect to PE1 10.1.1.2/30
G1/0 connect to PE2 10.1.1.19/30
4. Configurations et tests
4.1 Configuration des interfaces
Dans une première étape, nous devons configurer les différentes interfaces des routeurs à
utiliser. Ci-dessous, un exemple de configuration de quelques interfaces du routeur PE1 est
illustré. (D’autre exemple de configuration sont illustrés dans l’annexe 1.)
PE1# conf t
PE1(config)# interface Loopback 0
PE1(config-if)#ip address 1.1.1.1 255.255.255.255
PE1(config-if)#interface g0/0
PE1 (config-if)#ip address 10.1.1.1 255.255.255.252
PE1(config-if)#no shutdown
4.2 Configuration des protocoles de routage intra-nuage
4.2.1 Routage OSPF de Backbone IP/MPLS
Au niveau du Backbone, nous avons choisi d’implémenter OSPF comme protocole de routage
dynamique et ce, pour plusieurs raisons à savoir :
 Convergence rapide.
 Réduction des mises à jour et ce grâce à l’utilisation des areas et aux mises à jour
incrémentales.
 Intègration la notion de taille de masque variable (VLSM).
 Réduction de la taille des tables de routage par segmentation en areas et
implémentation des résumés de routes.
 Support du Trafic Engineering (OSPF-TE).
54
Pour l’implémentation d’OSPF, on a segmenté l’architecture globale en différentes zones

(areas) comme suit :
 Area 0 : c’est la zone Backbone ; elle contient le routeur provider et les 2 routeurs
Provider Edge « PE1 et PE2 ».
 Area ij : chaque site « ij » aura une area « ij» contenant le WAN et LAN (dans notre
cas Loopback 0 de CEij) du site.
Ainsi, l’architecture OSPF sera illustrée comme suit :
Figure III- 3 : Architecture OSPF
Nous appliquerons le protocole OSPF sur tous les routeurs du Backbone IP/MPLS tout en
prenant en considération Area 0.
Nous donnerons un exemple de configuration ci-dessous du routeur PE1 (D’autre exemple de

configuration sont illustrés dans l’annexe 2.)
PE1(config)# router ospf 1

PE1(config-router)# network 10.1.1.0 0.0.0.3 area 0
Pour vérifier le voisinage OSPF, on tape la commande show ip ospf neighbor qui permet
d’afficher la table de Voisinage OSPF .La commande show ip route ospf permet d’afficher la
table de routage OSPF du routeur.
(Nous donnerons dans l’annexe 3 les résultats de ces commandes)
Enfin, on teste le bon fonctionnement du routage intra-nuage en faisant un Ping du routeur PE-
1 à l’interface G0/0 de PE-2 .Le résultat est montré comme dans la figure ci-dessous :
55
Figure III- 4 : Test de bon fonctionnement d’OSPF
4.2.2 Configuration de MPLS
La technologie MPLS fonctionne par commutation des labels. Ainsi, il est obligatoire d’activer le
protocole MPLS sur les routeurs du Backbone tout en prenant en considération les paramètres
exigés. Pour ce faire, nous procédons comme il est noté ci-dessous (Exemple de configuration
PE1) en tapant les dites commandes sur toutes les routeurs appartenant au Backbone MPLS/IP
(les détails de configuration dans l’annexe 4).
PE1# conf t
PE1(config)# ip cef
PE1(config)# mpls ip
PE1(config-if)# mpls label protocol ldp
PE1(config-if)# mpls ldp router-id loopback 0 force
PE1(config)#interface g 0/0
PE1(config-if)# mpls ip
Afin de vérifier le bon fonctionnement de la commutation des paquets au sein du Backbone

nous pouvons utiliser les commandes suivantes :
 Show mpls ldp neighbors : affichage des voisins

 Show mpls forwarding table: vérification de la LFIB
 Show mpls ip binding: affichage des bindings des labels MPLS récupérés par LDP.
Donnant le test d’affichage de table de voisinage de routeur PE1
56
Figure III- 5 : Table de voisinage de routeur PE1
(On montre dans l’annexe 5 les résultats des autres commandes de vérification du bon
fonctionnement de la commutation MPLS au sein du Backbone).
4.3 Mise en place des VPN
4.3.1 Configuration de VRF

Afin d’isoler les trafics et implémenter la fonctionnalité de virtualisation de MPLS, nous
implémentons les VRF sur nos routeurs PE. A cet égard, nous commençons dans cette partie
par la création de deux VRF : VPN_Customer1 et VPN_Customer2.
Ainsi, sur tous les providers Edge (PE1 et PE2) du Backbone, on crée les deux VRF
VPN_Customer1 et VPN_Customer2. La configuration du VRF se fera en deux étapes à savoir :
On donne l’exemple de l’implémentation de VRF sur PE1. (On illustre dans l’annexe 6 la
configuration de routeur PE2)
 Création du VRF
PE1(config)# ip vrf VPN_Customer1

PE1(config-vrf)#rd 100 :1
PE1(config-vrf)# route-target both 100:1
57
 Activation du VRF sur les interfaces

Sur les deux PE sur lesquels nous avons attaché des sites clients, nous configurons le VRF
précédemment créé et ce sur l’interface raccordée avec le client. Ainsi, nous donnons dans ci-
dessous la configuration du routeur PE1 (on illustre dans l’annexe 6 la configuration de
routeur PE2).
PE1(config)#interface g2/0
PE1(config-if)#ip vrf forwarding VPN_Customer1
4.4 Configuration de routage OSPF au niveau CPE
Nous appliquerons le protocole OSPF sur tous les routeurs du CEij tout en prenant en
considération Area ij.
Nous donnerons un exemple de configuration ci-dessous le routeur CE11 (la configuration des
autres routeurs CPE est illustrées dans Annexe 7)
CE11(config)# router ospf 1

CE11(config-router)# network 192.168.1.0 0.0.0.3 area 11
CE11(config-router)# network 172.16.11.11 0.0.0.0 area 11
4.5 Configuration de MP_BGP
Pour que le VRF fonctionne, nous distribuons le chemin vers tout le réseau. Les commandes ci-
dessous seront exécutées sur PE1 ayant les interfaces sur laquelle est attaché le VRF. (La
configuration de routeur PE2 est illustrée dans Annexe 8)
PE1#conf t
PE1(config)# router bgp 100
PE1(config-router)#no bgp default ipv4-unicast
58
PE1(config-router)# neighbor 2.2.2.2 remote-as 100

PE1(config-router)# neighbor 2.2.2.2 update-source loopback 0
PE1(config-router)# address-family vpnv4 unicast
PE1(config-router-af)# neighbor 2.2.2.2 activate
PE1(config-router-af)# neighbor 2.2.2.2 send community both
PE1(config-router-af)#address-family ipv4 vrf VPN_Customer1
PE1(config-router-af)#redistribute ospf 100 vrf VPN_Customer1
PE1(config-router-af)#address-family ipv4 vrf VPN_Customer2
PE1(config-router-af)#redistribute ospf 200 vrf VPN_Customer2
PE1(config-router-af)#exit
PE1(config-router)#exit
PE1(config)#router ospf 100 vrf VPN_Customer1
PE1(config-router)# redistribute bgp 100 subnets
PE1(config)#router ospf 200 vrf VPN_Customer2
PE1(config-router)# redistribute bgp 100 subnets
Pour vérifier le fonctionnement du VPN, nous tapons les commandes suivantes au niveau PE1
et PE2 :
 Show ip bgp vpnv4 vrf VPN_Customer1: Affichage Instance BGP

 Show ip bgp vpnv4 vrf VPN_Customer2: Affichage Instance BGP
 Show ip route vrf VPN_Customer1: Affichage la table de routage de VRF de
VPN_Customer1
 Show ip route vrf VPN_Customer2: Affichage la table de routage de VRF de
VPN_Customer2
(Les résultats de ces commandes seront montrés dans l’annexe 9)
Pour vérifier la connexion entres les différents sites de clients, nous tapons les commandes
suivantes au niveau CEij :
 Show ip route : Affichage Table de routage
 Ping @IP: (example: CE11#ping 172.16.12.12)
59
On donne un exemple de test de la connectivité VRF de CPE-11 vers les clients de Site 2 (le test
des autres sites est montré dans l’annexe 10)
Figure III- 6 : Test de la connectivité VRF au niveau de PE1
Comme il est montré dans la figure, on peut constater que la connectivité est effectuée
qu’entre le client 1 de site 1 (routeur CPE-1.1) et le client 1 de site 2 (routeur CPE-1.2). Et ceci
confirme bien évidement le besoin pour lequel qu’on a implémenté le VRF, c’est de séparer le
trafic des clients
5. Conclusion
Dans ce chapitre, nous avons essayé de simuler, à une échelle réduite, le fonctionnement des
couches inférieures de l’architecture de notre solution envisagée, à savoir l’accès, l’adaptation
et le transport. Nous avons entamé par la configuration de la dorsale partagée IP/MPLS tout en
mettant l’accent sur les différents protocoles intrinsèques (OSPF, MP-BGP, LDP), finissant par la
mise en places des VPN / VRF Clients afin de mieux organiser les services de Backbone.
Dans le chapitre suivant nous mettrons en place les deux serveurs de notre solution, ce qui
nous permettra de gérer les équipements réseaux qu’on a simulés au cours de ce chapitre, le
serveur de supervision Eyes-Of-Network, et le serveur de centralisation des journaux
d’événement ELK-stack.
60
Chapitre 4
Management de la solution
Dans ce chapitre nous attaquons la partie pratique de notre projet Il sera subdivisé en deux
parties principales
En premier lieux nous mettrons en place un système de surveillance afin de superviser notre
architecture précédemment simulée sur GNS3.
En second partie nous concentrons par l’administration d’un système SIEM de centralisation
des journaux des équipements réseaux du Backbone de SOTETEL
Chap4- Partie 1 : Mise en place de serveur de supervision
Partie 1 : Mise en place de serveur de supervision
1. Introduction
La solution de supervision permet à la fois de garder un œil sur l'état du réseau, de détecter les
pannes et de limiter les déplacements de l’administrateur pour résoudre une panne, comme
elle notifie l’administrateur lorsqu’un problème ou un dysfonctionnement survient.
C’est dans cette optique que s’inscrit cette partie du projet qui consistera à mettre en place, à
faible coût de revient, une solution de supervision d’un réseau SOTETEL qui permettra de gérer
aisément sa topologie Backbone.
2. Prérequis logiciel
Pour l’implémentation du serveur de supervision, nous avons eu recours à des outils logiciels
suivants:
 VMware® Workstation 12 Pro
VMware Workstation est un hébergé hyperviseur qui fonctionne sur nombreux versions des
systèmes d'exploitation Windows et Linux, il permet aux utilisateurs de créer des machines
virtuelles (VM) sur une seule machine physique, et de les utiliser simultanément avec la
machine réelle. Chaque machine virtuelle peut exécuter son propre système d’exploitation, y
compris les versions de Microsoft Windows, Linux, BSD, et MS-DOS.
 SE CentOS
CentOS, une distribution GNU / Linux principalement destinée aux serveurs. Tous ses paquets,
sont des paquets compilés à partir des sources de la distribution RHEL (Red Hat Enterprise
Linux). Utilisée par 20 % des serveurs web Linux, elle est l'une des distributions Linux les plus
populaires pour les serveurs web.
3. Association du GNS3-VMWare
Une fois notre topologie installée et opérationnelle sur le simulateur GNS3, nous procédons
dans cette partie à mettre en place la machine virtuelle qui hébergera le serveur de supervision
Dans une première étape, nous créons une machine virtuelle, à l’aide du logiciel de
virtualisation des systèmes d’exploitation supporté par GNS3, à savoir VMware Workstation
62
Pro12. Puis la dite machine a base Cent-OS ainsi créée accueillera la plateforme EyesOfNetwork
5.0 une distribution s’inscrivant sous la fondation Linux .On a opté pour cette version de
système d’exploitation pour sa convivialité et sa communauté très active.
3.1 Installation de superviseur EyesOfNetwork
Après avoir téléchargé le fichier « image.iso » du système de supervision EyesOfNetwork 5.0 il

nous reste que l’importer dans le logicielle de virtualisation des systèmes « VMware
Workstation » et lancer le processus de l’installation. [B24]
Figure IV- 1 : VMware-Workstation 12 pro
Figure IV- 2 : Processus d’installation d’Eyes-Of-Network
(On mettra dans l’annexe 11 les autres étapes de l’installation)

3.1.1 Paramétrage réseaux
Arrivant à la tâche la plus importante au cours de la phase d’installation, c’est le paramétrage

d’adresse IP de notre superviseur. En effet via cette adresse nous accèderons à l’interface web
(Dashboard) du superviseur à fin d’administrer et gérer les différentes équipements réseaux.
63
Figure IV- 3 : Adressage réseaux du superviseur
Subséquemment, nous pouvons visualiser l’adresse IP de cette interface en tapant la

commande « ifconfig » dans le terminal de la machine virtuelle. Le résultat est donné par la
figure 4 :
Figure IV- 4 : Adresse IP d’EyesOfNetwork
64
3.1.2 Accès à la plateforme
La dernière étape, qui nous mène face aux différents services de la supervision offerts par le
système choisi, c’est l’accès au tableau de bord via l’interface d’authentification du système en
utilisant les données d’accès par défaut.
Identifiant : admin
Mot de passe : admin
Figure IV- 5 : Interface authentification EyesOfNetwork
Figure IV- 6 : Dashboard EyesOfNetwork
3.2 Couplage Backbone-EyesOfNetwork
Pour rétablir la connexion entre la Backbone et le superviseur, dans une première étape, nous
allons créer une interface entre notre machine virtuelle et le logicielle de simulation GNS3 dans
lequel notre maquette a été réalisé, et ce en ajoutant une carte réseau virtuelle (network
adapter) tel que montre la figure suivante :
65
Figure IV- 7 : Carte réseaux de la machine virtuelle
Par la suite nous avons lié notre zone backbone à superviser dans la maquette sur GNS3 via un
cloud connecté directement à la même interface virtuelle déjà accordé dans la machine
virtuelle EyesOfNetwork. Comme il est montré dans la figure ci-dessous.
Figure IV- 8 : Cloud Backbone-EyesOfNetwork
Afin de vérifier la connectivité entre la machine virtuelle de notre superviseur

« EyesOfNetwork » et les différents équipements réseaux de la zone Backbone à superviser, il
est nécessaire d’exécuter un Ping de la console d’EyesOfNetwork vers les interfaces des
routeurs à superviser du Backbone, par la commande « ping _ l’adresse IP du routeur »
66
Figure IV- 9 : Test de couplage Backbone-EON
On peut constater que la connectivité entre le serveur de supervision et tous les routeurs du
Backbone, a été rétablie avec sucées
4. Mise en place de Nagios
Nagios est un système de supervision des réseaux d’information complet. Fonctionnant à base
du protocole SNMP, il retourne des informations sur des ressources système, des services et
protocoles réseau. Il permet aussi de notifier, cartographier et générer des rapports. Bien qu’il
opère dans des environnements Linux, il est capable de surveiller toute sorte de systèmes
d’exploitation.
 SNMP
Le protocole SNMP permet aux administrateurs réseaux de contrôler, superviser l’état des
équipements réseaux à un instant ‘T’. L’équipement réseau envoi des informations vers un
serveur NMS afin de tracer des graphs qui permettront d’analyser l’état du CPU, de la mémoire,
des entrées/sorties… [B4]
4.1 Configuration SNMP

Notons que Nagios se base sur le protocole SNMP (Simple Network Management Protocol) d’où
il faut en premier lieu configurer le nom de la communauté SNMP dans la section « Nagios
67
Ressources » dans l’interface d’administration du Nagios (on a choisi une communauté

publique appelée « EON »). Cette procédure est montrée par la figure 10 :
Figure IV- 10 : Configuration SNMP-EON
Et bien évidement on n’a pas oublié d’activer ainsi le protocole SNMP dont le même nom de
communauté sur tous les routeurs du backbone avec les commandes suivantes :
Figure IV- 11 : Configuration SNMP-Router

4.2 Ajout des équipements du Backbone
Comme il est montré dans la figure ci-dessous, il faut remplir les informations liées à
l’équipement à ajouter
 son nom
 une description
 son adresse IP
Et surtout lui associer à une Template pour que ce dernier hérite les services de la supervision.
On a montré par cette figure l’ajout de routeur « Provider » du backbone. Par la même
méthode nous avons ajouté les deux autres routeurs du backbone PE-1 et PE-2
Figure IV- 12 : Ajout –Nagios du routeur Provider
68
Comme il est montré dans la figure ci-dessus l’ajout d’un routeur du Backbone se fera en
l’associant à la Template « CISCO» prédéfinie dans Nagios, qui hérite les services de supervision
d’un ensemble de plugin configuré par default
4.3 Programme plugins

En standard, le protocole SNMP ne remonte que des informations système basique
enregistrées dans la table MIB de la machine à superviser. Pour aller plus loin, Nagios a mis à
disposition de l’utilisateur un système de plugins locaux. Il s’agit des scripts externes au serveur,
qui émettent des requêtes vers les hôtes et retournent un code et d’éventuels messages
courts. Le code retour à une des significations suivantes :
 Code 0 : OK : tout va bien

 Code 1 : WARNING: Le premier seuil d’alerte a été dépassé
 Code 2 : CRITICAL: Le deuxième seuil d’alerte a été dépassé
 Code 3 : UNKNOWN: Problème lors de l’exécution du plugin
Pour tirer profit au maximum de Nagios, des centaines de plugins ont été implémentés par les
développeurs de sa communauté. On peut même faire combiner deux ou plusieurs plugins
pour les adapter à nos besoins. En ce qui concerne notre étude, on s’est intéressé aux plugins
ci-dessous :
 Check_snmp_mem.pl : vérifier l’état de la mémoire

 check_snmp_load.pl: vérifier l’état du processeur
 check_snmp_uptime.pl : vérifier la disponibilité de l’équipement via SNMP
 check_snmp_env.pl : vérifier l’enivrement de la communauté SNMP
 Check_snmp_int.pl : vérifier l’état des interfaces
 check_ospf_counters : détecter les pannes OSPF
 Check_bgp.pl : vérifier le routage BGP
Comme nous avons annoncés précédemment, un certain nombre de plugin sont configurés par
default tel que le service d’état du processeur et de la mémoire, par contre si on veut
superviser d’autres services spécifiques tel que les services de routage, on doit ajouter des
plugins manuellement. Dans la section suivante nous expliquerons comment les ajouter
69
4.3.1 Ajout des plugins
La communauté officielle de Nagios, met à la disposition des utilisateurs un nombre limité des
plugins open source téléchargeable sous la forme des fichiers d’extension « .PL » contenant le
code source et les paramètres qui définissent le service de supervision.
Parmi les plugins open source disponibles, nous citons les plugins de supervision d’état de
l’OSPF, BGP et l’état des interfaces. Malheureusement, les autres plugins tels que les plugins de
supervision des services de VRF, MPLS et VPN qu’on a implémenté sur notre maquette sont
payantes
 Chargement des Plugins dans Nagios

En premier lieu nous avons téléchargé les plugins open source précédemment cités du site
officiel de Nagios, Une fois le Plugins sont téléchargés, il faut les transférer dans le répertoire
des Plugins Nagios /srv/eyesofnetwork/nagios/plugins. L’opération sera réalisée en utilisant
une application de transfert FTP comme WinSCP.
Figure IV- 13 : Chargement de plugin
 Modification des droits et du propriétaire

Le fichier Plugin doit ensuite être rendu exécutable par Nagios. Il faut lui attribuer le
propriétaire Nagios et les droits d’utilisation de modification et d’exécution. Dans la console
d’administration d’eyes-of-network on doit taper les commandes suivantes :
Chown nagios nom_du_plugin
Chmod 775 nom_du_plugin
70
Finalement on peut vérifier l’existence des plugins ajoutés et activés dans Nagios en tapant la
commande « ls » dans la console d’administration d’eyes-of-networ.
Figure IV- 14 : Liste des plugins Nagios
4.4 Vérification
La figure suivante affiche l'état de toutes les machines surveillées. On peut constater que tous
les routeurs supervisés sont fonctionnels
Figure IV- 15 : Affichage de la liste des routeurs surveillés
71
Pour visualiser l’état des interfaces, l’occupation mémoire et le CPU utilisé ainsi que l’état des
protocoles SNMP, BGP et OSPF, on clique sur l’icône sous forme de loupe à coté de chaque
routeur .On visualise la page qui suit :
Figure IV- 16 : Interface des services surveillés
5. Mise en place de Cacti
Cacti est un logiciel permettant d’étudier des indicateurs de performances réseau. Il génère des
graphes sur les équipements qui utilisent SNMP régulièrement (la période par défaut est 5mn,
elle peut être changée dynamiquement). Les dits indicateurs portent sur la charge CPU, la QoS,
le débit des interfaces ou encore la latence. Un avantage considérable de Cacti est qu’il utilise
le stockage RRDtools (un outil de gestion de base de données de taille fixe, sert à stocker des
données cycliques et tracer des graphes de données chronologiques).
L’accès à l’espace d’administration de Cacti est possible depuis le tableau de bord d’eyes-of-
network via la section /Administration/Liens externe/CACTI
Figure IV- 17 : Interface web de Cacti
72
5.1 Création d’un graphe

La création d’une arborescence de graphe, est une étape très importante vue que tous les
équipements que nous ajouterons dans la prochaine partie de configuration de Cacti, seront
associés à ce graphe.
Tout d’abord, il faut sélectionner le menu « management » dans la console de Cacti, puis clique
sur «graph trees », « default tree », ensuite « add ». Comme le montre la figure suivante :
Figure IV- 18 : Création de graphe Cacti
5.2 Création d’Hôte :

Dans le but d’étudier le comportement des nœuds de notre topologie en termes de
performance, on a pour mission d’ajouter les routeurs à superviser par Cacti, dans un premier
temps, on doit cliquer sur « Management », puis sur «Devcies », enfin «Add», comme le montre
la figure suivante :
Figure IV- 19 : Création d’hôte Cacti
73
Il faut ajouter les informations nécessaires :
 Description : Le nom d’hôte affiché par Cacti.

 Hostname : on peut saisir un nom ou une adresse IP entièrement qualifié pour cet
appareil.
 Host template : c'est le modèle d'hôte à utiliser pour définir les modèles de graphiques
et les requêtes de données par défaut associées à cet hôte.
 Downed Device Detection : c’est la méthode que Cacti utilisera pour déterminer si un
hôte est disponible pour l’interrogation. Dans ce cas, on a choisi la méthode « SNMP
Uptime »
 SNMP Version : on a choisi la version 2.
 SNMP Community: c’est le nom de communauté SNMP v2 pour ce périphérique.
(dans notre cas « EON »)
Le paramétrage d’un hôte est plus simple, il suffit en effet de remplir quelques champs et de
sélectionner certains paramètres nécessaires à la supervision du nouvel hôte.
Après la création des hôtes, on peut visualiser l’état de ces derniers, comme le montre la figure
suivante :
Figure IV- 20 : États des routeurs surveillés par Cacti

5.3 Graphe de Cacti
Afin de bien modéliser le concept de supervision des équipements nous avons eu recourt à la
schématisation de ces états sous forme de graphes personnalisées adaptées aux besoins de
l’administrateur. La figure suivante représente l’usage de processeur du routeur en
pourcentage.
74
Figure IV- 21 : Graphe CPU Usage du routeur Provider
Par la même Cacti nous donne la main de visualiser la connectivité actuelle, l’état et la
disponibilité des routeurs. Ce dernier envoi une requête d’écho ICMP à l’adresse IP de cet
équipement à fin d’examiner si le routeur est connecté au réseau. La figure suivante montre la
connectivité et la disponibilité du routeur Provider Edge 1
Figure IV- 22 : État de PE1 à superviser
Ainsi Cacti nous permet aussi de visualiser le trafic généré au niveau des interfaces des
équipements supervisés, la figure suivante affiche le trafic de l’interface G0/0 du routeur
Provider Edge 1.
Figure IV- 23 : Graphe de Traffic G0/0 PE1
75
6. Mise en place de Nagvis
Nagvis est un outil cartographie pour Nagios permettant d’apporter des fonctions de
visualisations graphiques à Nagios, la création des cartes Navgis nécessite la configuration des
équipements au niveau de Nagios, puisque Nagvis utilise le statut des équipements supervisés
par Nagios
6.1 Création de carte
Pour créer une carte Navgis, il faut accéder au menu «Options» puis choisir «Gérer la carte»
Figure IV- 24 : Création de carte Nagvis
Il faut associer à la carte les informations nécessaires : un nom, un alias et un arrière-plan

finalement cliquer sur « Create » et voilà notre carte Nagvis vierge est prête.
6.2 Ajout des hôtes
Après la création, la carte va s’ouvrir et il va être possible d’ajouter les routeurs (Provider, PE1,
et PE2) qu’on a déjà surveillés par Nagios
Pour cela il faut cliquer sur le bandeau en haut partie «Editer la carte» (A noter que sur une
carte existante, il faut déverrouiller la carte via un clic sur «Tout bloquer/débloquer»), ensuite
l’accès au menu « Ajouter une icône / Host » va permettre d’ajouter des icônes qui changeront
de couleur suivant l’état Nagios de ces routeurs…
Figure IV- 25 : Ajout équipements Nagvis
76
Et voilà finalement notre Cartographie est terminée, pour la visualiser, il faut accéder à la
section «Tableau de bord / Nagvis».
Figure IV- 26 : Carte Nagvis
7. Mise en place de Weathermap
Avant d’utiliser Weathermap il est nécessaire d’avoir au préalable configuré un équipement

sous Cacti
7.1 Création de carte

Pour créer une carte wethermap il faut cliquer sur «Weathermap editor» et il est possible
d’utiliser un modèle existant par défaut à partir d’un fichier vierge.
Figure IV- 27 : Création de carte wedhermap
Comme la montre la figure ci-dessus nous avons créé une carte nommée « test » basée sur un
modèle par default « simple.conf »
7.2 Ajout des nœuds
Après la création de la carte, on peut créer des nœuds auxquels on pourra associer des icônes
ou des noms pour symboliser nos routeurs.
77
Pour cela, on doit cliquer sur «Add node», le pointeur de la souris va être modifié. Cliquer
ensuite sur le fond de carte pour «déposer» le «node».
Figure IV- 28 : Ajout de nœud-weathermap

7.3 Ajout des liens
Subséquemment, à l’aide de «Add Link», nous pouvons affecter un lien entre les nœuds
« routeur » déjà ajoutés. Pour cela, cliquer sur «Add Link» puis sur «provider», «PE1 » et
« PE2 », ce qui nous permet de visualiser par une graphe le trafic générer au niveaux des
interfaces qui relient les routeurs du Backbone entre eux
Figure IV- 29 : Ajout d’un lien wethermap
Et voilà finalement notre carte wethermap est prête pour être visualisé avec le trafic généré sur
les interfaces
Figure IV- 30 : Carte weathermap
78
8. Génération des Rapport
Parmi les points forts d’Eyes-of-network, il offre la possibilité de générer des rapports vus de
Nagios et Cacti. Il donne aussi la main de les télécharger en format PDF, XLS ou HTML et même
de les envoyer par email.
Dans ce qui suit nous présenterons quelques rapports générés par EON qui résument l’état des
équipements de Backbone de SOTETL que nous avons supervisés
8.1 Rapport SLA Technique
Figure IV- 31 : Rapport SLA de routeur Provider
Le rapport d’évènement SLA technique, permet de synthétiser le temps moyen de résolution de

panne pour une période donnée. Dans cet exemple, c’est la vue d’équipement routeur Provider
du Backbone datant d’une semaine.
8.2 Rapport Tendances
Le rapport disponibilité / tendance, permet d’avoir la disponibilité d’un hôte ou service sur une
période de temps donnée. L’exemple présenté par la figure ci-dessous, c’est la vue de
disponibilité de routeur Provider Egde 1 du Backbone.
79
Figure IV- 32 : Rapport tendances PE1
8.3 Rapport performances
Ce type de rapport de mesure de capacité, affiche toutes les graphes Cacti disponible sur une
période donnée afin d’avoir un résumé de l’état de «charge», l’exemple ci-dessous affiche un
résumé de l’état de charge de CPU de tous les routeurs du Backbone de SOTETEL.
Figure IV- 33 : Rapport performance Backbone SOTETEL
9. Notification par Email
La notification par Email, permet d’envoyer des alertes à l’administrateur sur l’état des
équipements en temps réel, pour cela il est indispensable d’implémenter cette partie dans la
mise en place de notre application. Pour ce faire, il faut d’abord renseigner l’adresse mail de
l’administrateur par l’accès au menu «Administration» puis sur «configuration Nagios» ensuite
cliquer sur le lien «contacts », « admin » ensuite sur « Edit ». Subséquemment, il faut
redémarrer le service Nagios pour qu’il prenne compte de la configuration
80
Figure IV- 34 : Notification par email

Et voilà finalement, en consultant le courrier électronique, nous trouverons les mails venus de
la part de Nagios qui nous notifient du statut des équipements supervisées
Figure IV- 35 : Réception des mails de Nagios

10. Conclusion
Au cours de cette première phase de la partie management de notre solution, nous avons
implémenté un ensemble d’outils de supervision offert par Eyes-of-network permettant à
l’administrateur de gérer les équipements réseaux du Backbone de SOTETEL en contrôlant
l’état du DATA protocole (Ex : OSPF, BGP…), l’état d’interface et l’état d’application.
Ainsi, qu’on a essayé au maximum d’enrichir cette partie de monitoring, par des outils
supplémentaires offerts par EON qui fournissent une importance robuste à notre solution de
supervision, tel que la gestion des rapports et la gestion des notifications.
Cependant, la supervision reste un élément insuffisant vue qu’on n’aperçoit l'incident que
lorsqu'il se produit. Alors comment peut-on détecter les incidents suspects et réagir d’une
façon proactive face à ces incidents, avant qu’ils proviennent et provoquent un arrêt du
système ?
81
Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux
Partie 2 : Mise en place de serveur de centralisation des

journaux
1. Introduction
La réponse à l’obsession des administrateurs réseaux précédemment posée, est articulée dans
cette deuxième partie de la phase Management de notre solution. Où nous mettrons en place
un serveur de collecte et d’analyse des journaux d’évènements appelé « ELK-STACK » qui
permet d’identifier et de régler les anomalies qui peuvent provenir sur les équipements, avant
qu’elles provoquent des erreurs de production de l’architecture réseaux du backbone de
SOTETEL
2. Mise en place de l’environnement
La solution de centralisation L'ELK Stack peut être installée en utilisant une variété de méthodes
et sur un large éventail de systèmes d'exploitation et d'environnements différents.
Notre choix a été arrêté sur l’installation de la pile sur une machine virtuelle récipient le
système d’exploitation Ubuntu version 18.04 LTS, une distribution s’inscrivant sous la fondation
Linux. On a opté pour cette version de système d’exploitation pour sa convivialité, stabilité et sa
communauté très active.
2.1 Installation de la machine virtuelle
En utilisant la plateforme des virtualisation des systèmes d’exploitation Vmware Workstation

pro 12, nous avons créé une machine virtuelle contenant le système d’exploitation ubuntu
18.04 LTS
Figure IV- 36 : Processus d’installation d’Ubuntu 18.04
82
2.2 Connexion Gns3-Machine virtuelle
Pour rétablir la connexion entre la Backbone et le serveur ELK, Dans une première étape, nous
allons créer une interface entre notre machine virtuelle et GNS3, et ce en ajoutant une 2ème
carte réseau virtuelle « VMnet10 » appartenant à la plage d’adresse publique 192.168.72.0 tel
que montre la figure suivante :
Figure IV- 37 : Ajout d’interface virtuelle
Il faut relancer le processus networking avec la commande «/etc/init.d/networking

restart » pour que la nouvelle interface soit prise en compte. On arrive enfin à visualiser
l’adresse IP de cette interface en tapant la commande « ip address show » dans le terminal de
la machine virtuelle. Le résultat est donné par la figure 38.
Figure IV- 38 : Adresses IP de l’interface de la machine hébergeant le serveur ELK

Par la suite nous avons lié notre zone Backbone dans la maquette sous GNS3, via un cloud
connecté directement à la même interface virtuelle déjà accordée dans la machine virtuelle
hébergeant la pile ELK. Comme il est montré dans la figure ci-dessous.
83
Figure IV- 39 : Couplage Backbone-ELK
Afin de vérifier la connectivité entre la machine virtuelle hébergeant ELK-stack et les différents
équipements réseaux de la zone Backbone, il est nécessaire d’exécuter un Ping de la console
d’Ubuntu vers les interfaces Loopback des routeurs, par la commande « ping _ l’adresse
loopback du routeur »
Figure IV- 40 : Test de connectivité Backbone-ELK
On peut constater que la connectivité entre le serveur ELK et tous les routeurs du Backbone, a
été rétablie avec sucées
84
3. Installation de la pile ELK-stack
Après avoir installé la machine virtuelle Ubuntu 18.04 et réalisé le couplage entre la dite
machine et notre zone Backbone, nous passerons en revue tous les éléments nécessaires pour
créer la pile fonctionnelle ELK-stack [B25]
 Logstash : composant responsable de traitement des journaux entrants

 Elasticsearch : composant responsable de stocke et d’analyse des journaux
 Kibana : l’Interface Web responsable de la recherche et la visualisation des journaux
3.1 Installation de Java 8
Elasticsearch et Logstash nécessitent Java, nous allons donc installer une version récente
d'Oracle Java 8 car c'est ce que recommande Elasticsearch. Il devrait cependant fonctionner
correctement avec OpenJDK.
L’installation de java est répartie en quatre étapes, en premier lieu on doit ajouter le référentiel
Oracle Java dans la base de paquet APT de système
Figure IV- 41 : Ajout d’un référentiel Oracle Java
Par la suite, il faut mettre à jours la base de données des paquets APT pour la prise en compte
de la modification apportée
Figure IV- 42 : Mise à jour de base de données de paquets APT
85
Ensuite, on doit installer la dernière version stable d'Oracle Java 8 comme il est montré dans la
figure suivante :
Figure IV- 43 : Installation Java 8
Et finalement, il ne reste que Vérifier la bonne l’installation et version du Java
Figure IV- 44 : Version java
3.2 Installation d’Elasticserach
Elasticsearch peut être installé avec un gestionnaire de paquets en ajoutant la liste des sources
de paquets d'Elastic.
D'abord, on doit ajouter la clé de signature d'Elastic pour que le paquet téléchargé puisse être
vérifié
Figure IV- 45 : Clé de signature d'Elastic
L'étape suivante consiste à ajouter la définition du référentiel dans le système avec la

commande suivante :
86
Tous ce qui reste à faire, est de mettre à jour des référentiels et installer Elasticsearch :
Figure IV- 46 : Installation d’Elasticserach

3.3 Installation de Logstash
Arrivant maintenant à l’installation de Logstash, Le package Logstash est disponible dans le

même référentiel qu'Elasticsearch, et puisque nous avons déjà installé cette clé publique, il ne
reste que créer la liste source Logstash par la commande suivante :
On doit maintenant Mettre à jour la base de données de paquets apt et installer logstash en
utilisant les dites commandes suivante :
3.4 Installation de Kibana
Kibana peut être installé avec un gestionnaire de paquets en ajoutant la liste des sources de
paquets d'Elastic. Donc on présente la commande suivante qui permet de créer la liste des
sources de Kibana:
Par la suite on doit Mettre à jour la base de données de paquets apt et Installer Kibana avec les
commandes suivantes :
87
Afin de vérifier le bon fonctionnement des trois composants de la pile ELK-stack, on doit tout
d’abord les démarrer puis afficher leurs états de service. Les figures ci-dessous montrent le bon
fonctionnement de la triade d’ELK.
Figure IV- 47 : Activation et état de service d’elasticsearch
Figure IV- 48 : Activation et état de service Logstash
Figure IV- 49 : Activation et état de service de Kibana
Pour offrir une meilleure flexibilité d’utilisation de la pile ELK-stack, on peut activer ses services
d’une façon automatique lors du démarrage du système. Pour ce faire on doit exécuter les
commandes suivantes :
Figure IV- 50 : Activation automatique des services ELK-stack
88
4. Configuration de la pile ELK
Après l’installation des services d’ELK-stack, il faut maintenant les configurer pour qu’ils
puissent recevoir et analyser les logs des routeurs de la zone Backbone du SOTETEL
4.1 Paramétrage d’Elasticserach
La configuration Elasticsearch utilise un fichier de configuration appelé « elasticsearch.yml » qui

nous permet de configurer les paramètres généraux tels que le nom de nœud, et les
paramètres réseau (Adresse IP hôte et numéro de port)
Ce fichier est accessible par la commande suivante :
Figure IV- 51 : Configuration Elasticsearch
Comme il est montré dans la figure ci-dessus, nous avons associés Elasticsearch à l’adresse IP
de notre machine virtuelle hébergent la pile ELK, ainsi que nous avons restreint l'accès extérieur
à l’instance Elasticsearch par l’affectation du port 9200, de sorte que les utilisateurs externes ne
puissent pas lire les données.
4.2 Paramétrage de Logstash
Le fichier de configuration de Logstash est au format JSON, il se trouve dans

/etc/logstash/conf.d. La configuration prend en considération deux paramètres importants, en
premier lieu on doit affecter l’adresse IP de notre serveur ELK-stack, ainsi que le numéro de
port d’écoute « 5044 » utilisé par moteur d’indexation Logstash pour recueillir les logs et les
89
collecter dans la Base de données Elasticsearch. La figure ci-dessous montre la configuration

effectuée.
Figure IV- 52 : Configuration Logstash
4.3 Paramétrage de Kibana
Il faut maintenant appliquer les paramètres nécessaires de Kibana en modifiant son fichier de
configuration « Kibana.yml » existant sous le répertoire /etc/kibana/kibana.yml. Comme il est
montré dans la figure ci-dessous, les paramètres spécifiques indiquent à Kibana à quelle
connexion Elasticsearch va se connecter et quel port va-t-il utiliser. Cette adresse sera utilisée
par la suite pour qu’on puisse connecter à l’interface graphique d’ELK-stack et visualiser les
journaux
Figure IV- 53 : Configuration Kibana
90
5. Analyse des journaux

5.1 Configuration des routeurs
À ce stade là, tout ce qui reste à faire est de rétablir l’envoie des logs de la part des routeurs
Backbone vers le serveur ELK. En premier lieu, nous avons recours à activer le service logging
aux niveaux de tous les routeurs du Backbone en spécifiant l’adresse source d’envoie et
l’adresse destination du serveur auquel le routeur va envoyer ses journaux ainsi que le type et
le numéro du protocole.
Figure IV- 54 : Configuration logging du routeur Provider

Comme il est montré dans la figure, on a activé l’envoie des journaux d’évènement au niveau
de routeur provider du Backbone, en indiquant son adresse « loopback 0 » comme adresse
source d’envoie des logs, et l’adresse IP « 192.168.72.128 » comme adresse destination de
serveur ELK-stack ainsi que spécifier le type de journaux à envoyer. Et comme nous le savons, il
existe sept niveaux de sécurité d’évènements qui peuvent être envoyé vers le serveur
d’analyse de log partant de 0 à 6 en fonction de degrés d’urgence :
 Niveaux de sécurité « 0 » - Urgence

 Niveaux de sécurité « 1 » - Alerte
 Niveaux de sécurité « 2 » - Critique
 Niveaux de sécurité « 3 » - Erreur
 Niveaux de sécurité « 4 » - Avertissement (warning)
 Niveaux de sécurité « 5 » - Notification
 Niveaux de sécurité « 6 » - Information
91
Pour éviter la saturation du serveur par des évènements normaux tel que les notifications les
informations, nous avons choisi d’activer l’envoie des logs, seulement pour les cinq premiers
type d’évènements les plus urgents (urgence, alerte, critique, erreur et avertissement) par la
commande « logging trap warning ».
Et finalement, on n’a pas oublié bien sûr d’indiquer le protocole UDP et son port 5514, sur
lequel connectent les routeurs pour transférer ses journaux
5.2 Configurations de script de log
Pour cette étape, nous avons créé un fichier script appelé log2.conf qui doit être exécuté lors
du démarrage du serveur ELK-stack, ce fichier contient les paramètres nécessaires pour la
réception, l’indexation et la recherche des journaux envoyées par les routeurs du Backbone.
 Input/beats : Le numéro de port d’écoute « 5044 » utilisé par moteur d’indexation

logstash pour recueillir les logs et les collecter
 Protocole : le type et le numéro de port du protocole auquel les routeurs vont envoyer
les journaux
 Type de log : « Windows-Event-log » puisque dans notre cas les équipements qui vont
envoyer ses journaux sont implémentés dans un environnement Windows (GNS3 sous
Windows 10)
 Output : Logstash, après qu’il collecte les logs, il faut les indexer dans une Base de
données et moteur de recherche Elasticsearch. La dite tâche est assurée par la section
output, où nous avons indiqué l’adresse ip et le port du moteur de recherche
ELasticsearch.
La figure ci-dessous montre les paramètres procédés aux niveaux du fichier script log2.conf
Figure IV- 55 : Configuration de script log2.conf
92
5.3 Test d’analyse de log
Arrivant à la phase finale de vérification et test d’envoie des journaux des évènements des
routeurs du Backbone vers le serveur ELK-stack. Pour réaliser cette tache nous avons recours en
première étape d’exécuter le script « log2.conf » qu’on a créé précédemment, par la dite
commande suivante :
Par la suite, on va produire une sorte d’incident comme la désactivation d’une interface de
n’importe quel routeur de la zone Backbone de SOTETEL. Nous avons pris l’exemple de la
désactivation/activation de l’interface Giga-Ethernet 0/0 du routeur PE-1. Le résultat dans
l’interface graphique de Kibana est montré dans la figure ci-dessous.
Figure IV- 56 : Test d’analyse de log par ELK-stack
Les messages affichés annoncent à une date précise, que l’interface Giga-Ethernet 0/0 a été
désactivée ce qui a provoqué l’arrêt du service de voisinage de routage OSPF (LDP Neighbors)
entre le routeur Provider et le Provider Edge 1. Avant qu’il se réactivera de nouveaux ainsi que
le service OSPF. Ces informations sont détectables par l’interface Loopback 0 « 1.1.1.1 » du
Provider Edge 1
6. Gestion de l’interface Web de Kibana

L'interface de Kibana est composée de plusieurs parties dont les plus importantes:
 Discover
 Visualize
 Dashboard
93
Après la connexion à Kibana, nous allons être redirigés vers la page « Discover » où nous
trouverons les logs reçus les plus récents.
Kibana offre un tableau de bord intéressant avec une variété de représentations des différents
résultats collectés par les shippers. Dans la figure ci-dessous, nous trouverons un histogramme
qui illustre la fréquence d’arrivée des messages pendant une durée de temps donnée.
Figure IV- 57 : Découvert des logs par Kibana

6.1 Recherche des messages
Kibana nous permet de chercher un type de message donné en tapant dans la barre de
recherche le message souhaité avec un intervalle de temps précis. Nous pouvons aussi chercher
par source en donnant une adresse IP.
Figure IV- 58 : Recherche des messages sur Kibana
94
6.2 Tableau de bord et visualisation
Dans la section « Visualize », nous pouvons créer, modifier et voir nos propres visualisations. Il y
a différents types de visualisations comme les histogrammes, les Pie charts, les tableaux de
données, etc... Les visualisations peuvent être sauvegardés et partagés avec d'autres
utilisateurs qui ont l'accès à l'instance Kibana.
Figure IV- 59 : Création de nouvelle visualisation
La troisième section de Kibana: « Dashboard », nous permet de combiner toutes nos

visualisations crées en une seule page pour pouvoir les gérer facilement. Les tableaux de bord
peuvent être filtrés selon nos requêtes de recherche.
Figure IV- 60 : Création d'un Tableaux de bord
95
6.3 Génération des rapports
La plateforme ELK nous permet d’élaborer des rapports d’informations concernant les
équipements réseaux et système, tout en sauvegardant dans sa base de données les différents
logs des utilisateurs de ce réseau. Les rapports peuvent être affichés sous format HTML. Ce qui
est très pratique pour l’administrateur s’il a des messages logs importants dont il veut garder
une copie pour la disponibilité.
7. Conclusion
Dans cette deuxième partie, nous avons exposé en détail les étapes de l'installation avec les
conditions préalables de la pile ELK-Stack. Comme une deuxième étape, nous avons configuré
les équipements réseaux de la zone backbone de SOTETEL simulée sous GNS3, pour qu’ils
puissent envoyer ses journaux. Finissant par le test de la solution d’analyse des logs
Ce chapitre a également étudié les caractéristiques offertes par les deux serveurs virtuels
implémentés dans notre projet, le serveur de supervision « Eyes-Of-Network » et le serveur
d’analyse de log et « ELK-Stack », qui sont très utiles à l'administrateur réseaux pour faciliter
son travail en créant des statistiques de supervision et des analyses à l’aide des journaux
d’évènements reçue.
96
Conclusion générale
Conclusion générale
Ce rapport s'inscrit dans le cadre d'un projet de fin d'études élaboré au sein de la société
tunisienne d’entreprise de télécommunication « SOTETEL ». Durant ce stage, nous étions
chargées pour la conception et la mise en place d’un centre d’opération de service. Comme
nous venons de le voir, la mise en place de cette solution n'est pas forcément complexe, mais,
elle exige tout de même qu'on suive une démarche structurée et rigoureuse. De ce fait, un
travail considérable de recherche sur Internet, aussi une étude minutieuse sur les outils de
travail et une analyse de l'environnement dans lequel fonctionne notre solution, ont été faits
afin de dégager les besoins et les exigences ciblées.
Le projet s’articulait ainsi autour de trois principaux volets à savoir :
- La simulation d’une topologie prototype de la zone Backbone de SOTETEL, par

l’émulation de quelques techniques proposées.
- La mise en place d’un système de supervision qui pourra détecter les pannes du
Backbone simulé de SOTETEL, en surveillant le statut des équipements réseaux existant
dans laquelle.
- La mise en place d’un système de centralisation et d’analyser des journaux des
équipements réseaux, dont le but est d’anticiper les pannes qui peuvent se produit
Le travail dans le cadre de ce projet de fin d'étude, était d'une importance considérable dans la
mesure où il nous a servi comme portail vers le monde professionnel et la vie en entreprise.
L'environnement du travail dans ce cadre nous a permis de renforcer nos capacités de
communication, de s'intégrer au sein d'une équipe et de faire face aux difficultés inhérentes
telles que la gestion du temps et des efforts.
En termes de perspectives, Plusieurs améliorations restent envisageables dans ce travail, ces

améliorations touchent essentiellement l'extensibilité de notre solution pour prendre en charge
d'autres fonctionnalités à savoir :
 CRM (Customer Relationship Management en anglais), c'est l'art d'optimiser les
interactions de l’opérateur avec ses clients en termes de réclamations sur les arrêts de
service
 Corrélation des logs entre le serveur de supervision et le serveur SIEM
 Intégration de la notification par sms dans Eyes-Of-Network et ELK-stack
97
Références bibliographiques
[B1] : Site web de SOTETEL URL: https://www.tunisietelecom.tn. Consulté le [10-fevrier-2018]
[B2] : THÈSE réalisé par [ÉRIC LUNAUD NGOUPÉ] le [05-juin 2015] URL :
[https://constellation.uqac.ca/3337/1/Ngoupe_uqac_0862D_10137.pdf] Consulté le [12-
fevrier-2018]
[B3] : Gestion de réseaux URL : https://fr.wikipedia.org/wiki/Gestion_de r%C3%A9seaux.

Consulté le [12-fevrier-2018]
[B4] : Protocole SNMP URL : https://www.commentcamarche.com/contents/537-le-protocole-

snmp Consulté le [15-Mars-2018]
[B5] : principe supervision URL : https://wiki.monitoring-fr.org/supervision/ Consulté le [17-

fevrier-2018]
[B6] : Objectifs de monitoring : Projet de Fin d’étude réalisé par [Mouhsine-MERZOUK] le [15-
juillet 2013] URL : [Développement d’une solution de supervision basée sur EON.html]
Consulté le [20-fevrier-2018]
[B7] : Définition SCOM URL : https://docs.microsoft.com/en-us/system-center/scom/manage-

operations-guide-overview?view=sc-om-1801 Consulté le [22-fevrier-2018]
[B8] : Définition HP-OpenView URL : https://searchitoperations.techtarget.com/definition/HP-

OpenView Consulté le [22-fevrier-2018]
[B9] : Article sur IBM-TRIVOLI réalisé par [Aldric GOUJON] publié le [24/10/2016] URL :
[https://www.supinfo.com/articles/single/ 3035-ibm-tivoli-c-est-quoi.html] Consulté le [22-
fevrier-2018]
[B10] : Nagios open source URL : [https://www.nagios.org/] Consulté le [23-fevrier-2018]
[B11] : Article supervision réseaux ZABBIX réalisé par [Vincent BENOIST] publié le [08/10/2016]
URL : [https://www.supinfo.com/articles/single/2482-supervision-reseau-zabbix] Consulté le
[23-fevrier-2018]
[B12] : Introduction check-mk URL : [https://wiki.monitoring-

fr.org/nagios/addons/check_mk/start] Consulté le [23-fevrier-2018]
98
[B13] : Article université de toulon [MISE EN PLACE D’UNE SOLUTION DE SUPERVISION] réalisé
par [Jean-Philippe BARUTEU] publié [21 avril 2016] URL : [https://dumas.ccsd.cnrs.fr/dumas-
01305578] Consulté le [15-Mars-2018]
[B14] : Documentation en ligne configuration Eyes Of Network URL :

[https://www.eyesofnetwork.com/?lang=fr] Consulté le [20-Mars-2018]
[B15] : Tutoriel Weathermap URL [https://openmaniak.com/fr/weather.php] Consulté le [20-

Mars-2018]
[B16] : introduction Nagvis URL : [http://www.nagvis.org/] Consulté le [21-Mars-2018]
[B17] : Article LOG URL : https://support.ankama.com/hc/fr/articles/203790076-Qu-est-ce-qu-

un-log publié [15 Janvier 2014] Consulté le [30-Mars-2018]
[B18] : Article [LA GESTION DES ÉVÈNEMENTS ET DES INCIDENTS] Auteur [Lionel GUILLET]
publié le [14-aout-2011] Consulté le [6-fevrier-2018]
[B19] : Documentation Graylog 2.4 architecture et composant URL :

[http://docs.graylog.org/en/2.4/pages/architecture.html] Consulté le [6-fevrier-2018]
[B20] : Blog officiel de fluentd URL : [https://www.fluentd.org/blog/] Consulté le [6-fevrier-

2018]
[B21] : Déploiement ELK en conditions réelles : Présentation faite lors de l'édition 2016 du
BreizhCamp à Rennes URL : [https://fr.slideshare.net/GeoffroyArnoud/dploiement-elk-en-
conditions-relles] Publié le [25 mars 2016] consulté le [6-fevrier-2018]
[B22] : Article Introduction à ELK : publié par [Olivier Jan] Le [30 avril 2014] URL :
[https://wooster.checkmy.ws/2014/04/elk-elasticsearch-logstash-kibana/] consulté le
[15-Mars-2018].
[B23] : Communauté offciel GNS3 : URL [https://gns3.com/] Consulté le [29 Mars 2018]
[B24] : Document Aide EyesOfNetwork 5.0 v1.0 : publié par [Letort Alexis] le [05/04/2017]
consulté le [10 mars 2018]
[B25] : Le guide complet de la pile ELK – 2018 Mis à jour le [2 avr. 2018] par [Daniel Berman]
URL : [https://logz.io/learn/complete-guide-elk-stack/#intro] Consulté le [20-mail-2018]
99
Annexes
Annexes
Annexe 1 : Configuration des interfaces
PE2# conf t
PE2 (config)# interface Loopback 0
PE2 (config-if)#interface g0/0
PE2 (config-if)#no shutdown
Provider# conf t
Provider (config)# interface Loopback 0
Provider (config-if)#ip address 3.3.3.3 255.255.255.255
Provider (config-if)#interface g0/0
Provider (config-if)#no shutdown
100
Annexes
CPE-21# conf t
CPE-21 (config)# interface Loopback 0
CPE-21 (config-if)#ip address 172.16.21.21 255.255.255.255
CPE-21 (config-if)#interface g0/0
CPE-21 (config-if)#ip address 192.168.1.6 255.255.255.252
CPE-21 (config-if)#no shutdown
Annexe 2 : Configuration de routage OSPF de Backbone IP/MPLS
Provider(config)# router ospf 1

Provider(config-router)# network 10.1.1.0 0.0.0.3 area 0
PE2(config)# router ospf 1

Annexe 3: Vérification de voisinage et affichage de table de routage OSPF
 Voisinage OSPF pour le routeur Provider
 Table de routage OSPF pour le routeur Provider
 Voisinage OSPF pour le routeur PE-2
101
Annexes
 Table de routage OSPF pour le routeur PE-2 :
Annexe 4: Configuration de MPLS

 Activation d’IMPLS sur les interfaces de routeur Provider :
Provider# conf t
Provider(config)# ip cef
Provider(config)# mpls ip
Provider(config-if)# mpls label protocol ldp
Provider(config-if)# mpls ldp router-id loopback 0 force
Provider(config)#interface g 0/0
Provider(config-if)# mpls ip
Provider(config)#interface g 1/0
Provider(config-if)# mpls ip
 Activation d’IMPLS sur les interfaces de routeur PE-2 :
PE2# conf t
PE2(config)# ip cef
PE2(config)# mpls ip
PE2(config-if)# mpls label protocol ldp
PE2(config-if)# mpls ldp router-id loopback 0 force
PE2(config)#interface g 0/0
PE2(config-if)# mpls ip
Annexe 5: Vérification MPLS-Backbone
 Table de voisinage IMPLS de routeur Provdier :
102
Annexes
 Table de Forwarding IMPLS de routeur Provdier :
 Table des identifiants MPLS :
Annexe 6 : Configuration de VRF sur PE-2

 Création des VRF sur PE2-2

 Activation des VRF sur PE2-2
103
Annexes
Annexe 7 : Configuration de routage OSPF au niveau CPE

 Configuration OSPF pour CPE-12
CPE-12(config)# router ospf 1

CPE-12(config-router)# network 192.168.1.8 0.0.0.3 area 12


Annexe 8 : Configuration de MP_BGP sur PE-2
PE-2#conf t
PE-2(config)# router bgp 100
PE-2(config-router)#no bgp default ipv4-unicast
PE-2(config-router)# neighbor 1.1.1.1 remote-as 100
PE-2(config-router)# neighbor 1.1.1.1 update-source loopback 0
PE-2(config-router)# address-family vpnv4 unicast
PE-2(config-router-af)# neighbor 1.1.1.1 activate
PE-2(config-router-af)# neighbor 1.1.1.1 send community both
PE-2(config-router-af)#address-family ipv4 vrf VPN_Customer1
PE-2(config-router-af)#redistribute ospf 100 vrf VPN_Customer1
PE-2(config-router-af)#address-family ipv4 vrf VPN_Customer2
PE-2(config-router-af)#redistribute ospf 200 vrf VPN_Customer2
PE-2 (config-router-af)#exit
PE-2(config-router)#exit
PE-2(config)#router ospf 100 vrf VPN_Customer1
PE-2(config-router)# redistribute bgp 100 subnets
104
Annexes
PE-2(config-router)# network 192.168.1.8 0.0.0.3 area 12

PE-2(config)#router ospf 200 vrf VPN_Customer2
PE-2(config-router)# redistribute bgp 100 subnets
PE-2(config-router)# network 192.168.1.12 0.0.0.3 area 22s
Annexe 9 : Vérification le fonctionnement du VPN

 Affichage distance BGP de PE-1 pour le VPN Client 1
 Affichage distance BGP de PE-1 pour le VPN Client 2
 Affichage la table de routage de VRF de PE-1 pour le VPN_Client1
 Affichage la table de routage de VRF de PE-1 pour le VPN_Client2
105
Annexes
Annexe 10 : test de la connectivité VRF de CPE-22 vers les clients de site 1
Annexe 11 : Installation de superviseur EyesOfNetwork

 Choix des outils supplémentaire d’Eyes-of-Network (EX : nagios,Cacti..)
 Choix du disque sur lequel nous installerons le système.
 Configuration de mot de passe
106
Résumé : (en Français)
Ce travail s’inscrit dans le cadre du projet de fin d’études en vue de l’obtention du diplôme National
d’Ingénieur en génie Informatique option Réseaux Informatiques. L’objectif de ce projet, est de concevoir
un centre d’opération de service « SOC » au profit de SOTETEL, qui lui permet de satisfaire ses clients en
termes de qualité de service. La réalisation du présent projet est répartit en trois phases, l’implémentation
d’une solution convergente de technique MPLS/VRF, permettant à l’entreprise de partitionner son
infrastructure réseaux, faciliter la gestion des clients et de répondre à ces besoins. La mise en place d’une
solution open source de supervision appelée « Eyes Of Network » capable de garder un œil sur l'état du
réseau du Backbone IP/MPLS de SOTETEL. Et finalement la mise en œuvre d’un système SIEM appelé
« ELK-Stack » qui permet d’anticiper les pannes de service réseaux et de réagir d’une façon proactive face à
ces incidents avant qu’ils se produisent.
Mots-clés : GNS3, EON, ELK, SNMP, MPLS, VRF, CISCO, Supervision, centralisation des Log
Abstract : (en Anglais)

This work is a part of the graduation project to obtain the National Diploma of Engineers in Computer
Engineering : Computer Networks. The objective of this project is to design a service center; "SOC" in favor
of "SOTETEL", which will make its customers satisfied in terms of service quality. The implementation of
this project is divided into three phases; the implementation of a convergent solution of MPLS / VRF
technique, allowing the company to facilitate the management of its network infrastructure and to meet the
needs of its customers. The implementation of an open source monitoring solution called "Eyes Of
Network" that is able to keep an eye on the network status of SOTETEL IP / MPLS Backbone. Finally, the
implementation of a SIEM system called "ELK-Stack" that anticipates network service failures and responds
proactively to incidents before they occur
Keywords : GNS3, EON, ELK, SNMP, MPLS, VRF, CISCO, Supervision, log centralization
Nom et Adresse de l’établissement où a été réalisé le Projet de Fin d’Etude :
Nom : Société Tunisienne d'Entreprises de Télécommunications

Adresse : Rue des Entrepreneurs ZI Charguia II Ariana Tunis BP-640 1080.
Téléphone : +216 71 941 100
Email : contact@sotetel.tn

Rapport Final Pfe (Saadaoui Marwen)

Transféré par

Droits d'auteur :

Formats disponibles

Rapport Final Pfe (Saadaoui Marwen)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Final Pfe (Saadaoui Marwen)

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’enseignement supérieur

Mémoire de Projet de Fin d’Etudes

Diplôme National d’Ingénieur en

Option Réseaux Informatiques

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

Année Universitaire : 2017/2018

À mon encadrant pédagogique Monsieur HDIJI Tarek,

Ingénieur Expert réseaux à la Tunisie Télécom et enseignant à la Polytechnique centrale, nous

À mon encadrant professionnel Monsieur GHARBI Walid,

Expert réseaux, directeur technique à la SOTETEL et enseignant à la Polytechnique centrale

Tous les mots ne sauraient exprimer la gratitude, l’amour, le respect, la reconnaissance…

À mes chers parents,

Vous avez su m’inculquer le sens de la responsabilité, de l’optimisme et de la confiance en soi

Que Dieu vous procure bonne santé et longue vie.

À mes chers frères, À ma chère sœur,

SAADAOUI Marwen …

Table des matières

Partie 1 : Étude conceptuelle de la supervision ..................................................................... 16

3.1 SEM (Gestion des événements de sécurité) ................................................................... 35

3.3 Plan d’adressage ............................................................................................................. 52

7.1 Création de carte ............................................................................................................ 77

Liste des figures

Figure I- 1 : Planification Du Déroulement Du Projet ..................................................................... 2

Figure IV- 7 : Carte réseaux de la machine virtuelle ..................................................................... 66

Figure IV- 51 : Configuration Elasticsearch ................................................................................... 89

Liste des tableaux

SOC : Centre d’opération de service

Durant ces dernières années, l’industrie des technologies de l’information et des

Il consiste d’une part à concevoir et implémenter une solution convergente de technique

L’objectif de la planification du projet est de déterminer les étapes du projet et le timing. Ce

Figure I- 1 : Planification du déroulement du projet

Chapitre 1 : Cadre générale du projet

Figure I- 2 : Logo SOTETEL

Les principaux actionnaires de SOTETEL sont « Tunisie-Télécom » avec un pourcentage de 35%,

2.2.1 Réseau d'Accès

 La croissance financière rentable et performante.

 La maitrise acquise dans la conduite des grands projets.

Dans le but de réussir sa mission d'intégrateur, il a été question d'engager un programme de

 Le suivi systématique des nouveautés et des opportunités.

2.4 Organisme de SOTETEL

 D.C.F (Direction Centrale Financière) responsable à la gestion financière, comptabilité

Figure I- 3 : Organigramme de SOTETEL

3.1 Description de l’existant

3.2 Critique de l’existant

3.2.2 Gestion de configuration

3.2.3 Enoncé du problème de supervision

Souciante de sa réputation concernée par la satisfaction et le confort de ses clients, la société

3.2.4 Enoncé du problème de journalisation

3.2.5 Entraves de SOTETEL

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

Il s’agit donc et sans doute d’une :

Un système de supervision offrira à l’administrateur la possibilité de contrôler et de vérifier

Figure I- 4 : Architecture de la solution de supervision

Avec le protocole SNMP, il pourra contrôler la consommation de la bande passante

4.2 Modèle conceptuel de la solution de journalisation

Figure I- 5 : Architecture de solution de journalisation