Rapport Final Pfe (Saadaoui Marwen) [PDF]

Zitiervorschau

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

3.

4.

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

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

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

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

3.

2.1

Les Objectifs du monitoring : ........................................................................................ 16

2.2

Domaines de surveillance ............................................................................................. 17

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

4.

5.

6.

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

Produit SIEM .......................................................................................................................... 37 4.1

Graylog ............................................................................................................................ 37

4.2

Fluentd ............................................................................................................................ 38

4.3

ELK stack ......................................................................................................................... 39

Analyse comparative.............................................................................................................. 40 5.1

Caractéristiques ............................................................................................................ 40

5.2

Fonctionnement ........................................................................................................... 40

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

3.

2.1

Prérequis Matériels ........................................................................................................ 50

2.2

Prérequis logiciel ............................................................................................................ 50

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 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

5.

Coté Backbone ........................................................................................................ 52

Configuration de VRF .............................................................................................. 57

4.4

Configuration de routage OSPF au niveau CPE .............................................................. 58

4.5

Configuration de MP_BGP .............................................................................................. 58

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

3.1.1

Paramétrage réseaux : ............................................................................................ 63

3.1.2

Accès à la plateforme .............................................................................................. 65

3.2 4.

5.

6.

7.

Installation de superviseur EyesOfNetwork ................................................................... 63

Couplage Backbone-EyesOfNetwork .............................................................................. 65

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

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

Mise en place de Nagvis......................................................................................................... 76 6.1

Création de carte ............................................................................................................ 76

6.2

Ajout des hôtes ............................................................................................................... 76

Mise en place de Weathermap .............................................................................................. 77

Table des matières

8.

9.

7.1

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

7.2

Ajout des nœuds............................................................................................................. 77

7.3

Ajout des liens ................................................................................................................ 78

Génération des Rapport......................................................................................................... 79 8.1

Rapport SLA Technique .................................................................................................. 79

8.2

Rapport Tendances ......................................................................................................... 79

8.3

Rapport performances ................................................................................................... 80

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

3.

2.1

Installation de la machine virtuelle ................................................................................ 82

2.2

Connexion Gns3-Machine virtuelle ................................................................................ 83

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

6.

7.

5.1

Configuration des routeurs ............................................................................................ 91

5.2

Configurations de script de log ....................................................................................... 92

5.3

Test d’analyse de log ...................................................................................................... 93

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

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

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

Introduction générale 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

Introduction générale 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 Chapitre 1 : Cadre générale du projet

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.

Chapitre 1 : Cadre générale du projet 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

Chapitre 1 : Cadre générale du projet 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

Chapitre 1 : Cadre générale du projet  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

Chapitre 1 : Cadre générale du projet 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

Chapitre 1 : Cadre générale du projet 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

Chapitre 1 : Cadre générale du projet 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

Chapitre 1 : Cadre générale du projet 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

Chapitre 1 : Cadre générale du projet 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

Chapitre 1 : Cadre générale du projet 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

Chapitre 1 : Cadre générale du projet 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

Chap2-Partie 1 : Étude conceptuelle de Supervision  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

Chap2-Partie 1 : Étude conceptuelle de Supervision 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

Chap2-Partie 1 : Étude conceptuelle de Supervision 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

Chap2-Partie 1 : Étude conceptuelle de Supervision 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-OFNETWORK 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

Chap2-Partie 1 : Étude conceptuelle de Supervision  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

Chap2-Partie 1 : Étude conceptuelle de Supervision -

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

Chap2-Partie 1 : Étude conceptuelle de Supervision 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

Chap2-Partie 1 : Étude conceptuelle de Supervision En deuxième lieu pour mieux enrichir notre étude comparative, nous donnons le tableau comparatif ci-dessous qui résume les différentes caractéristiques des outils de supervision open source précédemment cités, qui présentent les points faibles et les points forts de ces derniers. Ce qui nous aide bien évidemment à prévoir le meilleur choix de la solution adoptée pour la phase de supervision. Tableau II- 1 : Tableau comparatif des outils de supervision open source Critère Fonctionnels

EON

Nagios

Zabbix

Check_MK

Environnement de L’installation

Linux CentOS

Unix

Unix

Unix

Base de donné

MYSQL

C++

PHP, C

Python

Protocole

SNMP

SNMP, ICMP

HTTP, FTP

SNMP

Gestion d’authentification et des rôles

OUI

OUI

OUI

OUI

Création des graphes simple à partir des mesures

OUI

NON

OUI

OUI

Utilisation d’agents sur les machines cibles

OUI

OUI

Agent Windows/Unix

Check-mk win

Installation et configuration simple

OUI

NON

OUI

OUI

Intégration simple des nouvelles host à superviser

OUI

NON

OUI

OUI

Possibilité de mettre en place une supervision centralisée entre plusieurs sous réseaux

OUI

NON

OUI

OUI

Compatibilité avec la plateforme de virtualisation VMware)

OUI

OUI

OUI

NON

Possibilité d’ajouter les plugins

OUI

OUI

OUI

NON

Générer des alertes

OUI

OUI

OUI

OUI

Générer des rapports

OUI

OUI

NON

NON

24

Chap2-Partie 1 : Étude conceptuelle de Supervision 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-Ofnetwork 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

Chap2-Partie 1 : Étude conceptuelle de Supervision  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

Chap2-Partie 1 : Étude conceptuelle de Supervision

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

Chap2-Partie 1 : Étude conceptuelle de Supervision  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

Chap2-Partie 1 : Étude conceptuelle de Supervision 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

Chap2-Partie 1 : Étude conceptuelle de Supervision -

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

Chap2-Partie 1 : Étude conceptuelle de Supervision  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

Chap2-Partie 1 : Étude conceptuelle de Supervision 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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux

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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux 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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux 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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux  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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux

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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux  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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux 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,

syslog IETF, IETF TCP,

FAES, GELF via Http

GELF

AMQP

Protocole

HTTP, AMQP, OMQ Kafka

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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux

Tableau II- 3 : Tableau comparatif SIEM- Fonctionnement Plateforme

ELK-Stack

L’installation est un peu complexe mais Installation

reste relativement simple grâce à la documentation en

Fluentd

Installation simple, en créant un compte sur le site officiel et en récupérant le fichier d’installation

Ligne

Configuration un peu complexe car il faut Configuration

configurer Logstash (il faut donc maîtriser

Graylog

Installation similaire à ELK (Graylog utilise également ElasticSearch), avec une bonne documentation.

Configuration simple Configuration simple qui se fait depuis l’interface Web

un minimum les

et similaire à Fluentd car elle se fait là aussi depuis l’interface web.

langages de script)

Recherche

Simple pour utilisation

Utilisation basique

Syntaxe de recherche

basique, il suffit de taper le

simple, similaire à

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 par défaut. Barre de recherche et barre de Dashboard

temps toujours disponible. Dashboard facile à créer et à modifier.

Dashboard non interactif. Barre de recherche et temps non disponible par défaut. Il faut configurer les Dashboard pour les rendre compatible avec les affichages

Point fort d’ELK.

41

Dashboard facile à créer et à modifier mais ils ne sont pas interactif et la barre de recherche / temps n’est pas disponible. Point faible de Graylog.

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux 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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux 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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux 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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux 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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux 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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux 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

Chap2- Partie 2 : Étude conceptuelle de centralisation des journaux 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

Chapitre 3 : Émulation de la topologie de la solution

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é

Chapitre 3 : Émulation de la topologie de la solution 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

Chapitre 3 : Émulation de la topologie de la solution 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

Chapitre 3 : Émulation de la topologie de la solution 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

Chapitre 3 : Émulation de la topologie de la solution  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 CPE11

CPE12

CPE21

CPE22

PE1

Interface

Adresse IP

G0/0 Connect to PE1

192.168.1.2/30

Loopback0

172.16.11.11/32

G0/0 Connect to PE2

192.168.1.10/30

Loopback0

172.16.12.12/32

G0/0 Connect to PE1

12.168.1.6/30

Loopback0

172.16.21.21/32

G0/0 Connect to PE2

192.168.1.14/30

Loopback0

172.16.22.22/32

Loopback0

1.1.1.1/32

G0/0 Connect to Provider

10.1.1.1/30

G1/0 Connect to CPE21

192.168.1.5/30

G2/0 Connect to CPE11

192.168.1.1/30

53

Chapitre 3 : Émulation de la topologie de la solution

PE2

Provider

Loopback0

2.2.2.2/32

G0/0 Connect to Provider

10.1.1.10/30

G1/0 Connect to CE12

192.168.1.9/30

G2/0 Connect to CE22

192.168.1.13/30

Loopback0

3.3.3.3/32

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

Chapitre 3 : Émulation de la topologie de la solution 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 PE1(config-router)# network 1.1.1.1 0.0.0.0 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 PE1 à l’interface G0/0 de PE-2 .Le résultat est montré comme dans la figure ci-dessous :

55

Chapitre 3 : Émulation de la topologie de la solution

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

Chapitre 3 : Émulation de la topologie de la solution

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 PE1(config)# ip vrf VPN_Customer2 PE1(config-vrf)#rd 100 :2 PE1(config-vrf)# route-target both 100:2

57

Chapitre 3 : Émulation de la topologie de la solution  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 cidessous 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 PE1(config-if)#ip address 192.168.1.1 255.255.255.252 PE1(config-if)#no shutdown PE1(config)#interface g1/0 PE1(config-if)#ip vrf forwarding VPN_Customer2 PE1(config-if)#ip address 192.168.1.5 255.255.255.252 PE1(config-if)#no shutdown 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 cidessous 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

Chapitre 3 : Émulation de la topologie de la solution 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)# network 192.168.1.0 0.0.0.3 area 11 PE1(config)#router ospf 200 vrf VPN_Customer2 PE1(config-router)# redistribute bgp 100 subnets PE1(config-router)# network 192.168.1.4 0.0.0.3 area 21 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

Chapitre 3 : Émulation de la topologie de la solution 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 Chapitre 4 : Management de la solution

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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision

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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision

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

Chap4- Partie 1 : Mise en place de serveur de supervision

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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision 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-ofnetwork via la section /Administration/Liens externe/CACTI

Figure IV- 17 : Interface web de Cacti 72

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision

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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision 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

Chap4- Partie 1 : Mise en place de serveur de supervision

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

Chap4- Partie 1 : Mise en place de serveur de supervision

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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux

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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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 commande suivante : 86

système avec la

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux

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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

Chap4- Partie 2 : Mise en place de serveur de centralisation des journaux 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

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]

[https://constellation.uqac.ca/3337/1/Ngoupe_uqac_0862D_10137.pdf]

Consulté

URL : 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-protocolesnmp Consulté le [15-Mars-2018] [B5] : principe supervision URL : https://wiki.monitoring-fr.org/supervision/ Consulté le [17fevrier-2018] [B6] : Objectifs de monitoring : Projet de Fin d’étude réalisé par [Mouhsine-MERZOUK] le [15juillet 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/manageoperations-guide-overview?view=sc-om-1801 Consulté le [22-fevrier-2018] [B8] : Définition HP-OpenView URL : https://searchitoperations.techtarget.com/definition/HPOpenView 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 [22fevrier-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 :

fr.org/nagios/addons/check_mk/start] Consulté le [23-fevrier-2018] 98

[https://wiki.monitoring-

Références bibliographiques [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/dumas01305578] 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 [20Mars-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-quun-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-fevrier2018] [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-enconditions-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)#ip address 2.2.2.2 255.255.255.255 PE2 (config-if)#interface g0/0 PE2 (config-if)#ip address 10.1.1.10 255.255.255.252 PE2 (config-if)#no shutdown PE2 (config-if)#interface g2/0 PE2 (config-if)#ip address 192.168.1.13 255.255.255.252 PE2 (config-if)#no shutdown PE2 (config-if)#interface g1/0 PE2 (config-if)#ip address 192.168.1.9 255.255.255.252 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)#ip address 10.1.1.2 255.255.255.252 Provider (config-if)#no shutdown Provider (config-if)#interface g1/0 Provider (config-if)#ip address 10.1.1.9 255.255.255.252 Provider (config-if)#no shutdown Provider (config-if)#interface g2/0 Provider (config-if)#ip address 192.168.85.10 255.255.255.0 Provider (config-if)#no shutdown Provider (config-if)#interface g3/0 Provider (config-if)#ip address 192.168.72.10 255.255.255.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 Provider(config-router)# network 10.1.1.8 0.0.0.3 area 0 Provider(config-router)# network 3.3.3.3 0.0.0.0 area 0 PE2(config)# router ospf 1 PE2(config-router)# network 10.1.1.8 0.0.0.3 area 0 PE2(config-router)# network 2.2.2.2 0.0.0.0 area 0 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 PE2(config)# ip vrf VPN_Customer1 PE2(config-vrf)#rd 100 :1 PE2(config-vrf)# route-target both 100:1 PE2(config)# ip vrf VPN_Customer2 PE2(config-vrf)#rd 100 :2 PE2(config-vrf)# route-target both 100:2  Activation des VRF sur PE2-2 PE2(config)#interface g1/0 PE2(config-if)#ip vrf forwarding VPN_Customer1 PE2(config-if)#ip address 192.168.1.9 255.255.255.252 PE2(config-if)#no shutdown PE2(config)#interface g2/0 PE2(config-if)#ip vrf forwarding VPN_Customer2 PE2(config-if)#ip address 192.168.1.13 255.255.255.252 PE2(config-if)#no shutdown

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 CPE-12(config-router)# network 172.16.12.12 0.0.0.0 area 12  Configuration OSPF pour CPE-21 CPE-21(config)# router ospf 1 CPE-21(config-router)# network 192.168.1.4 0.0.0.3 area 21 CPE-21(config-router)# network 172.16.21.21 0.0.0.0 area 21  Configuration OSPF pour CPE-22 CPE-22(config)# router ospf 1 CPE-22(config-router)# network 192.168.1.12 0.0.0.3 area 22 CPE-22(config-router)# network 172.16.22.22 0.0.0.0 area 22 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 : [email protected]