N° d’ordre : 02/ M2/ IRS /TCO Année Universitaire : 2016 / 2017

UNIVERSITE D’ANTANANARIVO
----------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-----------------------
MENTION TELECOMMUNICATION

MEMOIRE
en vue de l’obtention
du Diplôme de MASTER
Titre : Ingénieur
Domaine : Sciences de l’Ingénieur
Mention : Télécommunication
Parcours : Ingénierie des Réseaux et Systèmes (IRS)

par : ANDRIAMIANDRA Manovosoa

MONITORING WAN ET CLASSIFICATION DE

TRAFIC PAR MACHINE LEARNING
Soutenu le Jeudi 12 Avril 2018 devant la Commission d’Examen composée de :

Président :
Monsieur RANDRIAMITANTSOA Andry Auguste
Examinateurs :
Monsieur RAJAONARISON Roméo
Madame ANDRIANTSILAVO Haja Samiarivonjy
Monsieur BOTO ANDRIANANDRASANA Jean Espérant
Encadreur professionnel :

Monsieur RAHARISON Hagalalaina

Directeur de mémoire :

Monsieur RATSIMBAZAFY Andriamanga

 REMERCIEMENTS

Je tiens en premier lieu à rendre grâce à Dieu de m’avoir donné le courage, la volonté ainsi que la
force nécessaire pour la réalisation de ce travail. Je tiens aussi à exprimer ma profonde gratitude
aux quelques personnes suivantes sans qui ce mémoire n’aurait pas pu être réalisé :

Monsieur RAMANOELINA Panja, Professeur Titulaire, Président de l’Université

d’Antananarivo.

Monsieur ANDRIANAHARISON Yvon, Professeur Titulaire, Responsable du Domaine Sciences

de l’Ingénieur de l’Ecole Supérieure Polytechnique d’Antananarivo.

Monsieur RAKOTOMALALA Mamy Alain, Maître de Conférences, Responsable de la Mention

Télécommunication.

Monsieur, RANDRIAMITANTSOA Andry Auguste, Maître de Conférences, Président du Jury.

Monsieur RATSIMBAZAFY Andriamanga, Maître de Conférences, en tant que Directeur de

mémoire et Encadreur Pédagogique.

Monsieur ANDRIAMBAHINY Patrick Directeur Général de la Société ARO.

Monsieur, RAKOUTH Zafiarisoa, Directeur Technique de la Société ARO.

Monsieur RATSIMBA Joël, Directeur du Département Système d’Information de la Société ARO.

Monsieur RAHARISON Hagalalaina, Chef de Service du Département des Systèmes

d’Information de la Compagnie d’assurance ARO, en tant que mon Encadreur Professionnel.

Les membres du jury, d’avoir accepté d’examiner ce travail malgré leurs occupations :

− Monsieur RAJAONARISON Roméo, Maître de Conférences ;

− Madame ANDRIANTSILAVO Haja Samiarivonjy, Assistante d’Enseignement et de
Recherche ;
− Monsieur BOTO ANDRIANANDRASANA Jean Espérant, Assistant d’Enseignement et
de Recherche.

Les enseignants et tout le personnel de l’ESPA et de la Compagnie ARO.

Ma famille, mes collègues, mes amis et tous ceux qui de près ou de loin ont contribué à la
réalisation de ce travail.

i
 TABLE DES MATIERES

REMERCIEMENTS ...................................................................................................................................... i

TABLE DES MATIERES ............................................................................................................................ ii

NOTATIONS ET ABREVIATIONS ........................................................................................................ viii

INTRODUCTION GENERALE.................................................................................................................. 1

CHAPITRE 1 PRESENTATION DE L’ORGANISME D’ACCUEIL ET PROBLEMATIQUE DU

THEME GENENERAL ................................................................................................................................ 2

1.1 Introduction ........................................................................................................................................................... 2

1.2 Présentation de la société et analyse des besoins ................................................................................................. 2

1.2.1 Présentation de la société ................................................................................................................................ 2

1.2.1.1 Historique et statut de la société .............................................................................................................................. 2

1.2.1.2 Organigramme et activités de la société .................................................................................................................. 3

1.2.1.3 Les produits de la société ......................................................................................................................................... 4

1.2.1.4 Le réseau ARO ......................................................................................................................................................... 6

1.2.2 Etude de l’existant........................................................................................................................................... 8

1.2.2.1 Connexion entre les différents sites......................................................................................................................... 9

1.2.2.2 Le cœur du réseau ................................................................................................................................................. 10

1.2.2.3 Convention de nommage ....................................................................................................................................... 11

1.2.2.4 Sécurité .................................................................................................................................................................. 11

1.2.3 Problématiques et analyse des besoins ........................................................................................................ 12

1.2.3.1 Problématiques des réseaux privés d’entreprise ................................................................................................... 12

1.2.3.2 Analyse des besoins de la société ........................................................................................................................... 13

1.3 Objectifs et stratégie de résolution des problématiques...................................................................................... 14

1.3.1 Surveillance du lien WAN ............................................................................................................................ 14

1.3.2 Surveillance des serveurs.............................................................................................................................. 14
1.3.3 Surveillance des services ............................................................................................................................... 15
1.3.4 Gestion de la sécurité .................................................................................................................................... 15
1.4 Conclusion ........................................................................................................................................................... 15

CHAPITRE 2 ETAT DE L’ART SUR LA SURVEILLANCE RESEAU ET SUR LA

CLASSIFICATION DE TRAFIC PAR MACHINE LEARNING ......................................................... 16

2.1 Introduction ......................................................................................................................................................... 16

ii
2.2 Le monitoring réseau .......................................................................................................................................... 17

2.2.1 Le concept de la supervision réseau ............................................................................................................ 17

2.2.2 Différents types de supervision .................................................................................................................... 17
2.2.2.1 Supervision Technique .......................................................................................................................................... 17

2.2.2.2 Supervision Applicative ......................................................................................................................................... 17

2.2.2.3 Contrat de service .................................................................................................................................................. 17

2.2.2.4 Supervision Métier ................................................................................................................................................. 18

2.2.3 Nécessité de la supervision ........................................................................................................................... 18

2.2.4 La norme ISO 7498/4 .................................................................................................................................... 18
2.2.4.1. Gestion des performances ..................................................................................................................................... 18

2.2.4.2. Gestion des configurations ................................................................................................................................... 19

2.2.4.3. Gestion de la comptabilité..................................................................................................................................... 19

2.2.4.4. Gestion des anomalies .......................................................................................................................................... 19

2.2.4.5. Gestion de la sécurité ............................................................................................................................................ 19

2.2.5 Différentes techniques de supervision ......................................................................................................... 19

2.2.5.1 Requête PING ........................................................................................................................................................ 19

2.2.5.2 Traceroute .............................................................................................................................................................. 20

2.2.5.3 SNMP ..................................................................................................................................................................... 20

2.2.5.4 Syslog ..................................................................................................................................................................... 24

2.2.5.6 Analyse du fichier Log ........................................................................................................................................... 24

2.2.5.5 IP SLA.................................................................................................................................................................... 25

2.2.6 Terminologies pour la surveillance réseau.................................................................................................. 25

2.2.6.1 Elément à superviser.............................................................................................................................................. 25

2.2.6.2 Acquisition ............................................................................................................................................................. 25

2.2.6.3 Fréquence .............................................................................................................................................................. 26

2.2.6.4 Seuil ....................................................................................................................................................................... 26

2.2.6.5 Reset ....................................................................................................................................................................... 26

2.2.6.6 Réponse .................................................................................................................................................................. 26

2.2.6.7 Requester................................................................................................................................................................ 26

2.2.7 Modes de déploiement des logiciels de supervision .................................................................................... 26

2.2.7.1 Déploiement centralisé .......................................................................................................................................... 26

2.2.7.2 Déploiement hiérarchique ..................................................................................................................................... 27

2.2.7.3 Déploiement distribué ............................................................................................................................................ 27

iii
 2.2.8 Etude comparative des outils de supervision .............................................................................................. 27
2.2.8.1 Nagios .................................................................................................................................................................... 27

2.2.8.2 Cacti ....................................................................................................................................................................... 28

2.2.8.3 Zabix ...................................................................................................................................................................... 29

2.2.8.4 Centreon................................................................................................................................................................. 30

2.2.8.5 Check_mk .............................................................................................................................................................. 30

2.2.9 Choix de l’outil mis en place ........................................................................................................................ 31

2.3 Méthode de classification de trafic réseau par Machine Learning ................................................................... 31

2.3.1 Nécessité de la classification de trafic .......................................................................................................... 31

2.3.2 Méthodes existantes ...................................................................................................................................... 31
2.3.2.1 Classification basée sur les ports ........................................................................................................................... 31

2.3.2.2 Classification basée sur la charge utile et l’inspection des paquets ..................................................................... 33

2.3.3 Fondamentaux du Machine Learning ......................................................................................................... 34

2.3.3.1 Généralités et terminologies .................................................................................................................................. 34

2.3.3.2 Concept du Machine Learning (ML) .................................................................................................................... 35

2.3.3.3 Types d’apprentissage ............................................................................................................................................ 36

2.3.4 Classification de trafic par Machine Learning ........................................................................................... 37

2.3.4.1 Collecte de données................................................................................................................................................ 37

2.3.4.2 Prétraitement des données ..................................................................................................................................... 38

2.3.4.3 Algorithmes d’apprentissages utilisés pour la classification ................................................................................ 38

2.3.4.4 Paramètres d’évaluation du modèle créé .............................................................................................................. 40

2.3.5 Choix de l’algorithme pour la classification de trafic ................................................................................ 40

2.4 Conclusion ........................................................................................................................................................... 40

CHAPITRE 3 IMPLEMENTATION DE LA SOLUTION DE MONITORING.................................. 41

3.1 Introduction ......................................................................................................................................................... 41

3.2 Implémentation de la solution de monitoring .................................................................................................... 41

3.2.1 Simulation de l’architecture réseau ............................................................................................................. 41

3.2.1.1 Présentation de GNS3............................................................................................................................................ 42

3.2.1.2 Configuration des routeurs ................................................................................................................................... 43

3.2.1.3 Emulation des serveurs à superviser ..................................................................................................................... 44

3.2.2 Simulation du lien WAN avec WANem ...................................................................................................... 45

3.2.2.1 Présentation de WANem ........................................................................................................................................ 45

3.2.2.2 Installation de WANem ......................................................................................................................................... 47

iv
 3.2.2.3 Configuration......................................................................................................................................................... 47

3.2.3 Installation de Nagios ................................................................................................................................... 48

3.2.3.1 Présentation de l’architecture Nagios ................................................................................................................... 48

3.2.3.2 Modes de fonctionnement de Nagios..................................................................................................................... 48

3.2.3.3 Installation des prérequis ...................................................................................................................................... 49

3.2.3.4 Compilation et installation de Nagios ................................................................................................................... 50

3.2.3.5 Configuration de l’interface Web .......................................................................................................................... 51

3.2.3.6 Compilation et installation des plugins ................................................................................................................. 52

3.2.3.7 Gestion de démarrage du serveur .......................................................................................................................... 52

3.2.3.8 Vérification de l’installation et démarrage du serveur ......................................................................................... 53

3.2.4 Configuration de Nagios ............................................................................................................................... 53

3.2.4.1 Configuration des machines Windows à surveiller............................................................................................... 53

3.2.4.2 Configuration des machines Linux à surveiller .................................................................................................... 56

3.2.4.3 Configuration des routeurs ................................................................................................................................... 58

3.2.5 Notification par mail ..................................................................................................................................... 62

3.2.5.1 Commandes utilisées pour envoyer les mails ;...................................................................................................... 62

3.2.5.2 Contacts à notifier ; ............................................................................................................................................... 63

3.2.6 Notification par SMS .................................................................................................................................... 64

3.2.6.1 Gateway SMS ......................................................................................................................................................... 64

3.2.6.2 Définition des commandes..................................................................................................................................... 64

3.2.6.3 Définition du contact ............................................................................................................................................. 64

3.2.7 Intégration des outils de graphes ................................................................................................................. 64

3.2.7.1 Installation et configuration de PNP4Nagios ....................................................................................................... 64

3.2.7.2 Installation et configuration de MRTG ................................................................................................................. 67

3.2.8 Interface graphique et tableau de bord ....................................................................................................... 67

3.2.8.1 Tableau de bord ..................................................................................................................................................... 68

3.2.8.2 Graphes .................................................................................................................................................................. 70

3.3 Conclusion ........................................................................................................................................................... 71

CHAPITRE 4 IMPLEMENTATION DE LA METHODE DE CLASSIFICATION DE TRAFIC .... 73

4.1 Introduction ......................................................................................................................................................... 73

4.2 Modèle mathématique ......................................................................................................................................... 73

4.2.1 Notions de bases sur les réseaux Bayésiens ................................................................................................. 73

4.2.1.1 Théorème de Bayes ................................................................................................................................................ 73

v
 4.2.1.2 Réseau Bayésien .................................................................................................................................................... 75

4.2.1.3 Classificateur Naïve Bayes .................................................................................................................................... 75

4.2.2 Modèle mathématique de la méthode de classification de trafic ............................................................... 76

4.2.3 Calcul des indicateurs de base de la performance du modèle ................................................................... 78
4.3 Diagramme de la méthode .................................................................................................................................. 79

4.3.1 Collecte de données brutes ........................................................................................................................... 80

4.3.1.1 Capture du trafic sain ............................................................................................................................................ 80

4.3.1.2 Collecte des trames infectées ................................................................................................................................. 80

4.3.1.3 Collecte des données de test ................................................................................................................................... 81

4.3.2 Sélection et extraction des attributs............................................................................................................. 81

4.3.3 Prétraitement des données ........................................................................................................................... 82
4.3.3.1 Présentation de l’environnement d’apprentissage automatique WEKA .............................................................. 82

4.3.3.2 Conversion en ARFF ............................................................................................................................................. 83

4.3.3.3 Structure d’un fichier ARFF................................................................................................................................. 84

4.3.3.4 Etiquetage des données .......................................................................................................................................... 85

4.3.4 Entrainement de l’algorithme de classification .......................................................................................... 86

4.3.5 Génération du modèle ................................................................................................................................... 87
4.3.6 Test du modèle .............................................................................................................................................. 88
4.3.6.1 Trames à tester ....................................................................................................................................................... 88

4.3.6.2 Test sur WEKA ...................................................................................................................................................... 88

4.3.6.3 Résultats des prédictions ........................................................................................................................................ 90

4.3.7 Comparaison des résultats avec les résultats obtenus par l’outil « Findject »......................................... 91
4.3.7.1 Présentation de l’outil FINDJECT ....................................................................................................................... 91

4.3.7.2 Test avec l’outil FINDJECT ................................................................................................................................. 91

4.3.7.3 Comparaison des résultats ..................................................................................................................................... 92

4.3.8 Interprétation des résultats et évaluation de la performance du modèle ................................................. 92

4.3.8.1 Evaluation du modèle par les résultats pratiques ................................................................................................. 92

4.3.8.2 Evaluation du modèle à partir des métriques calculées par WEKA ..................................................................... 93

4.3.9 Discussion et amélioration du modèle ......................................................................................................... 94

4.3.9.1 Discussion .............................................................................................................................................................. 94

4.3.9.2 Amélioration .......................................................................................................................................................... 94

4.4 Conclusion ........................................................................................................................................................... 95

CONCLUSION GENERALE .................................................................................................................... 96

vi
ANNEXE A1 INSTALLATION ET CONFIGURATION DES ROUTEURS ...................................... 97

ANNEXE A2 INSTALLATION ET CONFIGURATION DU SERVEUR MAIL ............................. 102

ANNEXE A3 DETAILS D’INSTALLATION DE WANEM ................................................................ 106

ANNEXE A4 INSTALLATION DE L’OUTIL MRTG ......................................................................... 115

BIBLIOGRAPHIE .................................................................................................................................... 118

FICHE DE RENSEIGNEMENTS ........................................................................................................... 121

RESUME .................................................................................................................................................... 122

ABSTRACT ............................................................................................................................................... 122

vii
 NOTATIONS ET ABREVIATIONS

1. Minuscules latines

∩ Intersection entre deux ensembles

∈ Appartient à

a Arc d’un réseau bayésien

𝑐1 , 𝑐2 Classes connues

𝑐𝑎 Classe « anomaly »

𝑐𝑛 Classe « normal »

𝑐𝑗 Classe connue 𝑐1 ou 𝑐2

𝑐𝑗 = ∁ (𝑥𝑖 ), L’instance 𝑥𝑖 appartient à la classe 𝑐𝑗

𝑒 Fonction exponentielle

𝑓 Fonction de distribution

𝑖 Identifiant d’un flux de données

k Nombre de classes d’intérêts

n Nœud d’un réseau bayésien

𝑛𝑐𝑗 Nombre d’occurrence de classes

𝑝(𝐴) Probabilité de réalisation de l’évènement A

𝑝(𝐴|𝐵) Probabilité conditionnelle de l’évènement A sachant B

𝑝(𝐴 ∩ 𝐵) Probabilité de réalisation de l’événement A ou de l’événement B

𝑝(𝑐𝑗 ) Probabilité à priori d’appartenance de l’instance 𝐴𝑥 à la classe 𝑐𝑗

𝑝(𝑐𝑗 |𝐴𝑥 ) Probabilité à postériori d’appartenance de l’instance 𝐴𝑥 à la classe 𝑐𝑗

𝑥 Ensemble de données, réalisation de la partition d’évènement X

𝑥𝑖 Instance observée de l’ensemble 𝑥

viii
𝑥→𝐶 L’ensemble 𝐶 est l’image de l’ensemble 𝑥

2. Majuscules latines

𝐴1 , 𝐴2 , 𝐴𝑛 Éléments de la partition 𝐴𝑥 de l’ensemble des évènements E

𝐴1 (𝑖) , 𝐴𝑚 (𝑖) , 𝐴𝑗 (𝑖) Attributs d’un flux i

A Ensemble des arcs d’un réseau bayésien

𝐴 Évènement A

𝐴∗ Évènement complémentaire de A

𝐴𝑘 Évènement appartenant à la partition 𝐴𝑥 , cause la plus probable de

l’évènement la réalisation de B

𝐴𝑥 Partition de l’ensemble des attributs possibles pour la réalisation de B

𝐵 Évènement B

𝐶 Ensemble des classes connues

E Ensemble des évènements

N Ensemble des nœuds d’un réseau bayésien

𝑁 Constante de normalisation

𝑋1 , 𝑋2 , 𝑋𝑖 Variables aléatoires éléments de la partition X

X Partition de l’ensemble des évènements caractérisé par l’apparition des n

attributs éléments de 𝐴𝑥

𝑃𝑟é𝑐𝑖𝑠𝑖𝑜𝑛𝑐𝑙𝑎𝑠𝑠𝑒 𝑐𝑛 Précision sur la prédiction de la classe « normal ».

𝑅𝑎𝑝𝑝𝑒𝑙𝑐𝑙𝑎𝑠𝑠𝑒 𝑐𝑛 Rappel sur la prédiction de la classe « normal ».

𝐹 − 𝑚𝑒𝑠𝑢𝑟𝑒𝑐𝑙𝑎𝑠𝑠𝑒 𝑐𝑛 Mesure de compromis entre précision et rappel pour la prédiction de la

classe 𝑐𝑛

3. Minuscules grecques

𝜎 Ecart-type

ix
𝜎2 Variance

𝜇 Moyenne de la densité de distribution

𝜋 pi

∑𝑐 𝑗 Somme par rapport à 𝑐𝑗

∑𝐴𝑥 ~𝑐𝑗 Somme suivant 𝐴𝑥 pour appartenir à la classe 𝑐𝑗

4. Abréviations

ADSL Asymmetric Digital Subscriber Line

API Application Programming Interface

ARFF Attribute-Relation File Format

ARO Assurances Reassurances Omnibranches

ASCII American Standard Code for Information Interchange

BN Bayesian Network

CD Compact Disc

CHR Cloud Hosted Router

CNN Convolutive Neural Network

CoS Class of Services

CPU Central Processing Unit

CGI Common Gateway Interface

DHCP Dynamic Host Configuration Protocol

DNS Domain Name System

DoS Deny of Services

DPI Deep Packet Inspection

DSI Direction des Systèmes d’Information

x
FTP File Transfer Protocol

GAD Graphe Acyclique Dirigé

GUI Graphic User Interface

HTTP HyperText Transfer Protocol

IANA Internet Assigned Numbers Authority

IA Intelligence Artificielle

ICMP Internet Control Message Protocol

IDS Intrusion Detection System

IETF Internet Engineering Task Force

IHM Interface Homme-Machine

IMAP Internet Message Access Protocol

IP Internet Protocol

IPSLA Internet Protocol Service Level Agreement

ISO International Standard Organization

LAN Local Area Network

LASER Light Amplification by Stimulated Emission of Radiation

LSA Link State Advertisements

MIB Management Information Base

MITM Man In The Middle

ML Machine Learning

MN Managed node

MOTS Man On The Side

MRTG Multi Router Traffic Grapher

xi
MDA Mail Delivery Agent

MTA Mail Transfer Agent

MUA Mail User Agent

NMS Network Management Station

NRPE Nagios Remote Plugin Executor

NSCA Nagios Service Check Acceptor

NTP Network Time Protocol

OID Object Identifier

OSPF Open Shortest Path First

OSI Open System Interconnection

P2P Peer to Peer

PC Personal Computer

PDU Protocol Data unit

PHP Hypertext Preprocessor

POP Post Office Protocol

QoS Quality of Services

RFC Request For Comments

RRD Round-Robin Database

RRDTool Round-Robin Database Tool

RTA Response Time Analysis

SASL Simple Authentication and Security Layer

SDSL Symmetric Digital Subscriber Line

SGMP Simple Gateway Monitoring Protocol

xii
SMI Structure of Management Information

SMS Short Message Service

SMTP Simple Mail Transfer Protocol

SNMP Simple Network Management Protocol

SSH Secure Shell

SSL Secure Sockets Layer

SVM Support Vector Machine

TCS-PERC TATA Consultancy Services - Performance Engineering Research Center

TCP Transmission Control Protocol

TEB Taux d’Erreur Binaire

UDP User Data Protocol

VPN Virtual Private Network

VSAT Very Small Aperture Terminal

WAN Wide Area Network

WANem Wide Area Network emulator

WEKA Waikato Environment for Knowledge Analysis

XML eXtensible Markup Language

xiii
 INTRODUCTION GENERALE

Il y a une dizaine d’années, la sécurité du réseau, était gérée par un administrateur réseau ou un
serveur qui a pour but de garder l’environnement en toute sécurité. Dix années plus tard, aucune
entreprise ne penserait à exclure la sécurisation des systèmes d’information de la liste des
expertises internes incontournables. D’après les études récentes, il en va de même pour la
surveillance professionnelle du réseau. Dans un futur proche, avoir une section spécialisée pour le
monitoring réseau deviendrait tout aussi naturel que d’avoir une section pour la gestion de parc ou
le stockage d’information. En effet, la nature distribuée de l’entreprise typique d’aujourd’hui, et en
particulier le manque de personnel informatique dans les régions éloignées, présentent une série de
défis opérationnels et d’infrastructure. Sans personnel informatique sur ces sites, les
administrateurs réseau ont du mal à obtenir des informations sur les éventuelles pannes et pour les
décisions de déploiement et de planification. De même, le personnel central manque généralement
de visibilité sur le réseau pour résoudre les problèmes ou restaurer les niveaux de performance.
Les équipes du département de systèmes d’information passeront alors énormément de temps et
d’argent à la recherche de problèmes à distance.

Par ailleurs, le nombre de menaces comme le ransomware WannaCry ou le Quantum Insert de la

NSA, augmente de jour en jour sur Internet. Ces genres d’incidents prouvent qu’aujourd’hui plus
que jamais l’information des individus et des organisations sont continuellement à risque. Les
méthodes de détection d’intrusion traditionnelles basées sur le port ou l’inspection de la charge
utile sont souvent dépassées par ce genre d’attaque. De nos jours, à l’âge du Data Mining et du
Machine Learning, de nouvelles approches voient le jour.

Au cœur de ces problématiques se trouve le thème de ce mémoire intitulé : « Monitoring WAN et

classification de trafic par Machine Learning ».

Cet ouvrage est divisé en cinq chapitres : le premier chapitre présentera la société d’accueil et le
thème général du projet. Le deuxième chapitre visera à donner un état de l’art de la surveillance
réseau et de la classification de trafic par Machine Learning tout en expliquant le choix des outils.
Le troisième chapitre parlera de l’implémentation de la solution de monitoring et des résultats
retournés. Le dernier chapitre concernera la modélisation mathématique de la méthode de
classification de trafic avant de présenter son implémentation ainsi que les tests de détection
d’injection de paquets effectués sur des trames TCP.

1
 CHAPITRE 1
PRESENTATION DE L’ORGANISME D’ACCUEIL ET PROBLEMATIQUE DU THEME
GENENERAL

1.1 Introduction
Dans ce chapitre, nous allons effectuer une présentation plus ou moins détaillée de l’organisme
d’accueil et du cadre général du projet, et ainsi expliquer les objectifs du projet.

1.2 Présentation de la société et analyse des besoins

1.2.1 Présentation de la société

La société ARO (Assurance Réassurance Omni branche) est, comme son nom l’indique, une
société anonyme spécialisée dans le secteur des assurances et de réassurances.

Son expérience et sa performance la placent à la tête des compagnies d’assurance à Madagascar :

Elle possède 63,4 % de part du marché national.

Etant donné son importance en termes de couverture nationale, le réseau ARO est un réseau très
étendu.

ARO dispose d’un réseau important composé de 21 agences et de 8 agences générales couvrant
toute l’île. [1]

ARO est membre du réseau GLOBUS depuis septembre 2008. Fondé en 2007, GLOBUS est un
réseau panafricain de sociétés d’assurances qui compte actuellement une trentaine de membres,
réparti dans tout le continent Africain, et qui fournit une offre globalisée de produits/services
d’assurance aux clients multinationaux ayant des intérêts dans toute l’Afrique. [2]

1.2.1.1 Historique et statut de la société

La société ARO a été créée en 1975 suite à la nationalisation de la société française « La
Préservatrice » installée à Madagascar depuis 1935. [1]

− Raison Sociale : ASSURANCES REASSURANCE OMNIBRRANCHES (ARO) ;

− Date de création : 1975 suite à la nationalisation de la société française « La Préservatrice
»;
− Forme juridique : SA (Société Anonyme) ;
− Capital : 7.013.300.000 Ariary ;

2
 − Activités : Assurance / Réassurance/ Investissement institutionnel ;
− Chiffre d’affaires 2016 : 138 Milliards d’Ariary ;
− Part de marché : 63,4%, leader sur le marché Malagasy ;
− Certifiée ISO 9001 : 2015 ;
− Notation : AA- (GCR – Afrique du Sud, traduisant une forte capacité à faire face aux
engagements à l’égard des assurés) ;
− Marge de solvabilité : 8,6 fois le minimum réglementaire ;
− Membre du réseau GLOBUS : un réseau panafricain de sociétés d’assurances ;
− Siège Social : Rue des parlementaires Français 77, Antsahavola ;
− BP : 42, Tél : +261 20 22 201 54, Antananarivo 101 ;
− E-mail : aro1@moov.mg ;
− Site web: http://www.aro.mg/.

1.2.1.2 Organigramme et activités de la société

a) Organigramme

Les employés au sein de la société ARO, sont répartis dans cinq services et six départements.
L’organigramme de la société est représenté par la figure 1.01.

3
 Figure 1.01 : Organigramme de la société.

b) Activités de la société

La compagnie propose un éventail diversifié de produits, qui couvre pratiquement tous les risques
pouvant survenir pour les particuliers et pour les professionnels, quels que soient leurs secteurs
d’activités. [1]

On distinguera ainsi pour les particuliers, les assurances :

− Santé ;
− Responsabilité civile ;
− Rente éducation ;
− Biens : habitation, autos (avec 3 types : A, B, C).

Pour les professionnels, la compagnie offre un grand choix de couvertures :

− Perte d’exploitation ;
− Marchandises transportées ;
− Risques chantiers ;
− Récoltes sur pieds (agriculture) ;
− Mortalité d’animaux d’élevage ;
− Maritimes, etc.

1.2.1.3 Les produits de la société

a) Assurance vie et capitalisation

− Assurance temporaire décès ;

− Assurance vie et accident ;
− Assurance rente éducation ;
− Assurance retraite ;
− Aro tanteraka.

b) Assurance non vie

− Assurance de personne ;
− Assurance personnelle contre les accidents ;
− Assurance famille passager ;

4
 − Assurance santé ;
− Assurance assistance ;
− Assurance accident ;
− Assurance de dommages.

c) Risques divers

− Assurance incendie et risques annexes ;

− Assurance cyclone ;
− Assurance tremblement de terre ;
− Assurance vol ;
− Assurance risques spéciaux des immeubles ;
− Assurance multirisque habitation ;
− Assurance multirisques dommages ;
− Assurance perte exploitation.

d) Responsabilités civiles diverses

− Assurance de responsabilité civile privée ;

− Assurance de responsabilité civile entreprise ;
− Assurance de responsabilité civile des professions libérales ;
− Assurance de responsabilité civile du propriétaire d’immeuble ;
− Assurance de responsabilité civile du propriétaire d’animaux ;
− Assurance de responsabilité civile des établissements d’enseignement ;
− Assurance de responsabilité civile des associations sportives ;
− Assurance de responsabilité civile des spectacles, excursions.

e) Risques techniques

− Assurance matériel électronique ;

− Assurance tous risques informatiques ;
− Assurance bris de machine ;
− Assurance perte de produits en entrepôts frigorifiques ;
− Assurance tous risques chantier / tous risques montage ;
− Assurance de responsabilité civile décennale du constructeur.

5
f) Transport terrestre :

− Assurance automobile ;
− Assurance tierce collision ;
− Assurance de responsabilité civile du transporteur terrestre ;
− Assurance des marchandises transportées.

g) Transport maritime :

− Assurance corps de navire ;

− Assurance embarcation de plaisance ;
− Assurance de responsabilité civile du transporteur maritime ;
− Assurance des marchandises transportées.

h) Aviation:

− Assurance corps aéronefs ;

− Assurance de responsabilité civile aéronefs;
− Assurance individuelle accidents aéronefs ;
− Assurance des marchandises transportées.

1.2.1.4 Le réseau ARO

a) Réseau direct

Le réseau direct est composé de 21 agences réparties dans les différentes régions de l’île :

− Région d’Analamanga : Agence Antsahavola, Ampefiloha, Ankorondrano, Des Grands

Comptes, Analakely, Anosizato ;
− Région Vakinakaratra : Direction Régionale d’Antsirabe ;
− Région Haute Matsiatra : Direction Régionale de Fianarantsoa ;
− Région d’Atsimo Andrefana : Direction Régionale de Toliara ;
− Région Anosy : Agence Régionale de Taolagnaro ;
− Région Menabe : Direction Régionale de Morondava ;
− Région Diana : Direction Régionale d’Antsirananana, Agence Régionale d’Ambanja,
Agence Régionale de Nosy Be ;

6
 − Région Sava : Direction Régionale de Sava, Agence Régionale d’Antalaha ;
− Région Vatovavy Fitovinany : Agence Régionale de Manakara ;
− Région Boeny : Direction Régionale de Mahajanga, Agence Antsohihy ;
− Région Atsinanana : Direction Régionale de Toamasina ;
− Région Alaotra Mangoro : Agence Régionale d’Ambatondrazaka.

b) Agences générales

Les agences générales ne font pas partie du réseau direct mais font partie des branches de la
société : ATHIS, Société Auximad, Cabinet Mitsinjo, Henri Fraise Fils assurances, Ets
RAMANANDRAIBE EXPORT, ADEMA Assurances, ARORIAKA.

Figure 1.02 : Répartition des agences ARO.

7
1.2.2 Etude de l’existant
Cette section traite un aperçu de l’architecture réseau actuellement en place dans la société, ainsi
que des serveurs.

Les éléments présentés ci-après sont à prendre en considération avant l’implémentation de la

solution de monitoring.

En effet, vue que l’adaptation à ce qui est déjà en place est nécessaire, en aucun cas il n’est pas
permis d’imposer un choix qui touche aux politiques déjà établies, que celles-ci soient de sécurité
ou autre lors de la phase d’implémentation du projet.

L’architecture du réseau est de type réseau en étoile. La figure 1.03 représente une architecture
simplifiée du réseau représentant :

− La salle des serveurs du siège ;

− Le parc de postes clients du siège : composé de PC (Personal computer) servant de postes
de travail et d’imprimantes réseaux.
− Le lien de connexion internet : Le routeur R_5 représente le routeur d’accès à internet ;
− Les différents liens vers les agences distantes : les liaisons WAN (Wide Area Network)
reliant le siège aux agences distantes sont caractérisés par différents types de liens avec des
débits variés.
− Les routeurs : Les routeurs R_2, R_3, R_4 représentent les routeurs dans les agences
distantes. Le routeur R_1 représente le routeur central situé au siège.
− Les postes clients des agences distantes : les agences distantes ne possèdent pas de parc de
serveur, elles disposent d’un parc de poste clients et d’imprimantes réseaux.

8
 POSTES CLIENTS

ROUTEURS DISTANTS
INTERNET

SALLE DES SERVEURS

LIAISON WAN

Figure 1.03 : Architecture simplifiée du réseau.

1.2.2.1 Connexion entre les différents sites

Le réseau dispose de plus de 21 sites interconnectés avec des débits variés. Le cœur du réseau se
trouve au siège à Antsahavola.

Deux types de connexions : en fibre optique et en ADSL (Asymmetric Digital Subscriber Line),
sont utilisées pour l’accès à internet.

Un routeur central est dédié uniquement à l’accès à distance des agences distantes aux applications
métiers et aux sites hébergés par le Siège.

Les médias utilisés pour la connexion des sites distants peuvent être de la SDSL (Symmetric
Digital Subscriber Line), de la fibre optique, le VSAT (Very Small Aperture Terminal) ou le
LASER (Light Amplification by Stimulated Emission of Radiation).

Le réseau local du siège a aussi une topologie en étoile dont le concentrateur principal est un
switch dont le débit est de 1Gbps et de plusieurs switches secondaires de 100 Mbps montés en
cascade. Les matériels de connexion utilisés sont listés par le tableau 1.01.

9
Matériels Marques Connexion
Modem Router ADSL SAGEM Passerelle entre internet et le siège

Router Mikrotik Connexion SDSL avec les agences d’Antananarivo

Connexion avec les agences de provinces

Switch principal Dell Partage de connexion aux postes et serveurs du siège

Antsahavola

Switches secondaires D-Link DES 1641 Swiches secondaires

Tableau 1.01 : Les matériels de connexion

1.2.2.2 Le cœur du réseau

Le cœur du réseau est composé d’un parc de serveurs et d’un parc de clients. La société dispose de
19 serveurs dont 16 à Antsahavola (14 opérationnels), 2 à Antsirabe et 1 à Tuléar, les principaux
systèmes d’exploitation utilisés sont Windows et Linux.

a) Le serveur DNS

Un serveur DNS (Domain Name System) ou serveur de système de nom de domaine est
comparable à un annuaire.

En effet lorsque l’on souhaite joindre une machine distante (poste de travail ou serveur) qui se
trouve sur le réseau, un ordinateur envoyer une requête au serveur DNS pour récupérer l’adresse
IP de la machine à joindre.

Le serveur DNS permet de faire la relation entre le nom de la machine et son adresse IP (Internet
Protocol).

b) Le serveur DHCP

Un serveur DHCP (Dynamic Host Configuration Protocol) a pour rôle de distribuer des adresses
IP à des clients sur le réseau pour une durée déterminée (un bail DHCP).

Cela permet de délivrer automatiquement des adresses en fonction de l’endroit où l’on se

connecte.

10
Par convention, seuls les postes de travail bénéficient d’un bail DHCP, et donc d’une durée
effective de l’adresse IP affectée à chaque poste, une fois ce bail dépassé, la machine se verra
attribuer une nouvelle adresse IP.

A contrario les autres éléments placés en réseau doivent absolument avoir une adresse IP fixe,
notamment les serveurs ainsi que les imprimantes multifonctions en réseau.

En effet pour des raisons évidentes, ces machines sont sollicitées et requêtées régulièrement, il
faut donc une adresse fixée.

Des plages d’adresses IP sont donc réservées :

Les serveurs, les imprimantes multifonctions en réseaux sont adressées en 10.0.0.*.

c) Le serveur Mail

Le serveur Mail tourne sur le système d’exploitation Linux configuré avec Postfix.

d) Le parc Imprimantes

Le parc imprimantes se compose d’imprimantes classiques (qui ne disposent pas d’interface

réseau, mais elles sont très rares), d’imprimantes monochromes en réseau, d’imprimantes couleurs
réseau et également d’imprimantes multifonctions réseau.

1.2.2.3 Convention de nommage

En informatique une convention de nommage, est une ou plusieurs règles à respecter, en général
une suite de caractères qui formalise (dans notre cas d’utilisation) un bien matériel.

En effet, chaque bien matériel recensé possède un identifiant unique que l’on appelle un « code
matériel » présent sous la forme d’une étiquette, collée sur chacun d’entre eux.

En respectant ce nommage, l’inventaire du parc est facilité et une fois l’ensemble ramené dans
l’outil EasyVista, cela permettra de mieux identifier chaque matériel.

1.2.2.4 Sécurité
a) Un firewall protège en permanence le système d’information. Un « firewall internet » sert de
rempart contre les attaques provenant de l’extérieur. Il est assuré par l’outil Pfsense.

11
b) Une interconnexion réseau via VPN (Virtual Private Network) multipoints avec partage de
connexion internet, est utilisée notamment pour les interconnexions aux LAN (Local Area
Network) Ampefiloha, Analakely, Ankorondrano, Antsahavola.

c) Les postes de travail ainsi que tous les serveurs sous Windows sont sécurisés par les antivirus
Kaspersky.

d) Le serveur mail, tournant sous Linux est sécurisé par Amavis.

1.2.3 Problématiques et analyse des besoins

1.2.3.1 Problématiques des réseaux privés d’entreprise

L’idée de supervision s’appose spécialement dans un contexte de réseau privé. L’idée principale
de la supervision est de contrôler la bonne santé du réseau et des services informatiques afin de
mesurer la Qualité de Service. Ce concept de QoS (Quality of Services) n’est pas nouveau, mais
est devenu le point d’intérêt central des politiques de développement d’entreprise.

La situation économique actuelle exige des entreprises qu’elles contrôlent leurs dépenses.

Pour les entreprises, la tendance n’est pas à l’investissement dans de nouvelles technologies, mais
à l’optimisation et au rendement de l’existant à moindre coût.

De plus, l’évolution des méthodes de travail au sein même de l’entreprise veut qu’une part de plus
en plus importante de l’activité de celle-ci sollicite les outils informatiques.

Dans le cas des sociétés d’assurance, c’est toute l’activité des employés et dirigeants qui repose
intégralement sur la bonne disponibilité des services informatiques et réseaux.

L’enjeu pour ce genre d’entreprise est donc primordial, puisque leurs chiffres d’affaire dépendent
directement des outils informatiques tels que le mail, le partage de fichier et d’application,
l’intranet etc..

Chaque agence doit pouvoir accéder à ces services à tout instant afin d’offrir une qualité de
service acceptable pour leurs clients. L’objectif des administrateurs d’un système d’information
est donc de pouvoir connaître en permanence l’état du réseau, et d’être averti en temps réel des
différents incidents pour réduire au maximum le délai d’intervention et de coupure du service. [3]

12
D’autre part, le nombre d’attaques sur Internet accroit chaque jour. Récemment, les pirates
informatiques ont attaqué plusieurs entreprises autour du monde avec un ransomware appelé
WannaCry.

En mai 2017, ce ransomware est utilisé lors d’une cyberattaque mondiale massive, touchant plus
de 300 000 ordinateurs, dans plus de 150 pays, principalement en Inde, aux États-Unis et en
Russie et utilisant le système obsolète Windows XP12 et plus généralement toutes les versions
antérieures à Windows 10 n’ayant pas effectué les mises à jour de sécurité.

Cette cyberattaque est considérée comme le plus grand piratage à rançon de l’histoire d’Internet.
[4]

L’information des individus et des organisations sont continuellement à risque. Les méthodes de
détections d’intrusion traditionnels sont souvent dépassées par ce genre d’attaque.

De nos jours, à l’âge du Data Mining et du Machine Learning, de nouvelles approches voient le
jour.

1.2.3.2 Analyse des besoins de la société

Concernant l’entreprise ARO, les besoins suivants ont été spécifiés pour la supervision :

a) Diagnostic et détection automatique des pannes du réseaux dans les agences déportées :

En cas de latence ou de panne du réseau, la DSI (Direction des Systèmes d’Information) doit être
en mesure de détecter l’origine et la position des pannes du réseau en un strict minimum de temps.

b) Monitoring du serveur mail

Une interface graphique pour faciliter la surveillance du flux mail, en cas d’échec ou de panne du
serveur, supervision des emails de l’envoi à la réception et supervision de la disponibilité du
service.

c) Surveillance du débit internet

Le débit de la connexion internet de la société peut aussi être la cause de la latence observée lors
des transactions et des envois de message.

La DSI doit être capable de déterminer si la cause du problème s’y trouve. Pour cela, DSI aura
besoin d’une interface graphique affichant en permanence les résultats du monitoring réseau afin
de permettre la gestion des pannes.

13
d) Sécurisation plus renforcée du parc

Face à la menace croissante présente actuellement sur la sécurisation de l’information,

l’implémentation d’un système de sécurisation additionnel pour protéger contre les attaques
éventuelles provenant de l’extérieur ne devrait pas être négligée.

1.3 Objectifs et stratégie de résolution des problématiques

La solution de supervision réseau proposée aura donc pour but de répondre à ces besoins c’est-à
dire :

− la surveillance du lien WAN ;

− la surveillance des serveurs ;
− la surveillance des services ;
− la gestion de la sécurité.

1.3.1 Surveillance du lien WAN

Nagios et MRTG (Multi Router Traffic Grapher) seront utilisés pour surveiller les liens WAN.
Nagios pings les emplacements distants toutes les 10 minutes, si le lien est plus lent que 100ms,
un avertissement sera reçu, s’il devient plus lent alors un message d’erreur critique sera reçu.
MRTG lit les informations de performance des routeurs distants avec SNMP (Simple Network
Management Protocol) et les représente graphiquement.

De cette façon, on pourra voir exactement l’utilisation de la bande passante des liens.

La mise en œuvre cette solution est primordiale puisque l’agence siège reçoit beaucoup de
questions venant des sites distants, concernant la latence dans leurs connexions au site central et à
internet ou si elles nécessitent une mise à jour de bande passante. Une fois cette solution mise en
place, le responsable de l’administration du réseau pourra répondre à ces questions avec des
graphiques et ainsi ils pourront savoir et constater par eux-mêmes si le problème provient du lien
WAN ou de leur propre réseau.

1.3.2 Surveillance des serveurs

Nagios est aussi utilisé pour surveiller les serveurs Windows et Linux du parc de serveur du siège.
Cette surveillance consiste à surveiller leurs accessibilités sur le réseau et si certaines applications

14
sont toujours en cours d’exécution ainsi que l’état de leurs systèmes d’exploitation, l’état de leurs
processeurs, leurs mémoires etc.

1.3.3 Surveillance des services

Tous les services pour l’infrastructure WAN et LAN sont surveillés par Nagios. Cela signifie
actuellement les services ftp (File Transfer Protocol), http (HyperText Transfer Protocol), smtp
(Simple Mail Transfert Protocol), pop (Post Office Protocol), imap (Internet Message Access
Protocol. D’autres sites de la société demandent rapidement de surveiller également leurs services
internet.

1.3.4 Gestion de la sécurité

Afin de mieux répondre à la norme ISO 7498/4 sur la gestion de la sécurité pour la supervision
réseau, veillant à ce que les utilisateurs non autorisés ne puissent accéder à certaines ressources
protégées, une méthode de classification du trafic TCP (Transmission Control Protocol) par un
algorithme de Machine Learning, le Naïve Bayes, sera utilisé pour la classification automatique du
trafic normal et du trafic anormal. [5]

1.4 Conclusion
Dans ce chapitre a été présenté la société d’accueil ainsi que le cadre général du projet. Par
ailleurs, les problématiques et les besoins du réseau informatique de l’entreprise ayant conduit au
thème de ce mémoire ont aussi été présentés d’une façon plus ou moins exhaustive. Les deux
chapitres suivants présenteront plus en détail le thème en essayant de donner un état de l’art des
deux disciplines mis en jeu qui sont le monitoring réseau et la classification de trafic par Machine
Learning.

15
 CHAPITRE 2
ETAT DE L’ART SUR LA SURVEILLANCE RESEAU ET SUR LA CLASSIFICATION
DE TRAFIC PAR MACHINE LEARNING

2.1 Introduction
Dans ce chapitre sera présenté brièvement dans une première partie, les enjeux du monitoring
réseau, ensuite, les fondamentaux de l’apprentissage automatique et son application à la création
d’un modèle pour la classification de trafic. Avant d’entamer une étude plus détaillée de ces
concepts, il est important de prendre en compte les quelques définitions ci-après.

Définition 2.01 :

Un réseau informatique est un ensemble d’équipements interconnectés et pouvant communiquer

entre eux via un protocole de transport ou de communication commun permettant :

− le partage des ressources (fichiers, applications ou connexion Internet, etc.) ;

− la communication entre les gens (email, chat en direct, etc.) ;
− la communication interprocessus (entre ordinateurs industriels) ;
− la garantie de l’unicité et de l’universalité de l’accès à l’information (base de données de
réseau). [6]

Définition 2.02 :

Un réseau étendu désigne un réseau qui couvre une zone étendue connectant généralement un
nombre multiple de réseaux locaux à travers de larges frontières géographiques. [6]

Définition 2.03 :

La supervision se définit comme une technique utilisant au mieux les ressources informatiques
pour obtenir des informations sur l’état des réseaux et de leurs composants. Ces informations
seront ensuite traitées et affichées afin de mettre en lumière d’éventuels problèmes. [7]

Définition 2.04 :

L’apprentissage automatique est un type d’IA (Intelligence Artificielle) qui permet aux
applications logicielles de prédire plus précisément les résultats sans être explicitement
programmées. La prémisse de base de l’apprentissage par machine est de construire des

16
algorithmes qui peuvent recevoir des données d’entrée et utiliser l’analyse statistique pour prédire
une valeur de sortie dans une plage acceptable. [8]

2.2 Le monitoring réseau

2.2.1 Le concept de la supervision réseau

Le concept de supervision a vu le jour au début des années 1980, lors d’une exposition sur la mise
en place des réseaux informatiques dans les entreprises. C’est donc à cette époque qu’ont été
menées les premières réflexions sur un nouveau concept, celui de la supervision. [9]

Superviser un réseau, en tant que pratiquant d’une discipline professionnelle, signifie assurer
qu’un réseau, des serveurs, des applications, des services soient stables, en bon état, et
fonctionnant à un niveau maximum d’efficacité à tout moment. Ce qui consiste non seulement à
être alerté quand un système a cessé de fonctionner mais surtout, être capable de prédire une panne
et ainsi intervenir pour que celle-ci soit évitée. [10]

2.2.2 Différents types de supervision

La solution et le type de supervision à implémenter doit dépendre de l’activité de l’entreprise mais
aussi de son besoin. On distingue quatre types de supervision.

2.2.2.1 Supervision Technique

Elle consiste à surveiller le réseau, l’infrastructure et les machines du système d’information [9]

2.2.2.2 Supervision Applicative

Elle consiste à surveiller les applications. Elle a pour but d’aider à identifier et résoudre un
problème au niveau de la fourniture de service. Les indicateurs sont généralement regroupés en
trois grandes familles :

− la disponibilité du service ;
− la performance de l’application ;
− l’intégrité des données.[9]

2.2.2.3 Contrat de service

Elle consiste à surveiller le respect des indicateurs, afin de voir si on respecte bien les contraintes
que nous impose par exemple un contrat avec un client. [10]

17
2.2.2.4 Supervision Métier
Elle consiste à surveiller les processus métiers de l’entreprise, à superviser tous les éléments d’un
processus complet et garantir que l’ensemble soit opérationnel. Elle permet aussi d’agir
préventivement et éviter toutes les pannes afin d’assurer le bon fonctionnement de l’entreprise.
[9]

2.2.3 Nécessité de la supervision

On supervise pour avoir une visibilité sur le système d’information. Cela permet de connaître
rapidement l’état de santé du réseau, des systèmes, des performances donc d’avoir une image en
temps réelle de l’état du système.

Superviser se fait aussi dans le but de détecter et anticiper les pannes. En étant notifié par une
alerte quand un disque dur atteint 80% de sa capacité par exemple, permettra d’éviter un crash du
système à cause d’un disque dur plein.

Grâce à la supervision on peut aussi être rapidement en connaissance de l’effet d’une action (ajout
d’un nouveau client, nouvelle machine etc.) sur le système. Donc on pourra connaître et chiffrer
techniquement l’impact de ce type de modification et réagir rapidement si besoin est. [10]

2.2.4 La norme ISO 7498/4

Le concept de supervision a été normalisé par l’ISO (International Organization for
Standardization). Différentes fonctions ont ainsi été définies.

2.2.4.1. Gestion des performances

Les performances du réseau sont évaluées à partir de quatre paramètres :

− le temps de réponse ;
− le débit ;
− le TEB (Taux d’Erreur Binaire) ;
− la disponibilité.

La supervision doit pouvoir évaluer les performances des ressources du système et leur efficacité.
Elle comprend les procédures de collecte de données et de statistiques. Elle doit aboutir à
l’établissement de tableaux de bord. Les informations recueillies doivent aussi permettre de
planifier les évolutions du réseau. [5]

18
2.2.4.2. Gestion des configurations
La gestion des configurations permet d’identifier, de paramétrer et de contrôler les différents
objets du réseau. Les procédures requises pour gérer une configuration sont :

− la collecte d’information ;
− le contrôle d’état ;
− la sauvegarde historique de configurations de l’état du système.[5]

2.2.4.3. Gestion de la comptabilité

Son rôle est de connaître les charges des objets gérés ainsi que leurs coûts de communication. Des
quotas d’utilisation peuvent être fixés temporairement ou non sur chacune des ressources réseaux.
De plus, la gestion de la comptabilité autorise la mise en place de systèmes de facturation en
fonction de l’utilisation pour chaque utilisateur. [5]

2.2.4.4. Gestion des anomalies

La gestion des fautes permet la détection, la localisation et la correction d’anomalies passagères
ou persistantes. Elle doit également permettre le rétablissement du service à une situation normale.

2.2.4.5. Gestion de la sécurité

La gestion de la sécurité contrôle l’accès aux ressources en fonction des politiques de droits
d’utilisation établies. Elle veille à ce que les utilisateurs non autorisés ne puissent accéder à
certaines ressources protégées. [5]

2.2.5 Différentes techniques de supervision

Voici quelques-unes des techniques générales les plus utilisées au cours de l’histoire de la
surveillance réseau.

2.2.5.1 Requête PING

Cet outil est utilisé pour tester l’accessibilité et la disponibilité d’un hôte dans un réseau IP. Les
données issues des résultats peuvent déterminer si un hôte du réseau est actif ou non. En outre, il
peut être utilisé pour mesurer le temps de transmission et la perte de paquets lors de la
communication avec un hôte. PING utilise le protocole ICMP (Internet Control Message Protocol)
pour envoyer des demandes d’écho à un hôte sélectionné. Si la demande est reçue par l’hôte testé,
il répondra avec un message ICMP « Echo Reply ». [11]

19
2.2.5.2 Traceroute
Le test « Trace Route », également appelé « traceroute » et « tracert », est un utilitaire qui mappe
le chemin entre les hôtes testés. Les résultats sont ensuite affichés sous la forme d’une liste de
sauts. Les informations fournies pourraient être utilisées pour identifier un lien faible le long de la
route. Si le test échoue à un certain point, l’adresse IP du dernier routeur ayant répondu
correctement est connue, de sorte que le problème pourrait alors être identifié plus facilement. [11]

2.2.5.3 ICMP

Le protocole ICMP est utilisé par les périphériques réseau tels que les routeurs et les
commutateurs pour envoyer des messages d’erreur indiquant qu’un hôte n’est pas accessible par
l’intermédiaire de certains diagnostics. [11]

2.2.5.3 SNMP
a) Présentation du protocole

Le SNMP (Simple Network Management Protocol) a été créé en 1988 pour remplacer le SGMP
(Simple Gateway Monitoring Protocol). Aujourd’hui, il est utilisé pour échanger des informations
entre les hôtes d’un réseau comprenant un logiciel de surveillance. La plupart des switches,
firewall hardware et routeurs intègrent ce protocole. Le protocole SNMP est un standard défini par
l’IETF (Internet Engineering Task Force). Il est régi par des RFC (Request For Comments). Il
existe actuellement 3 versions différentes du protocole SNMP :

− SNMP v1 (RFC 1155, 1157 et 1212) ;

− SNMP v2c (RFC 1901 à 1908) ;
− SNMP v3 (RFC 3411 à 3418). [12]

b) Fonctionnement général

Sur chaque composant du réseau qui peut être administré ou MN (Managed Node), on installe un
agent SNMP. Cet agent est un programme qui enregistre en permanence certaines informations
liées au composant qui sont identifiés sous forme de clé-valeur unique appelé OID (Object
Identifier) et les stocke dans une base de données : la MIB (Management Information Base).
Depuis une station d’administration, on peut alors interroger chaque MN, prendre connaissance de
son état, consulter des informations, ou encore configurer certaines caractéristiques. [13]

20
SNMP utilise donc le modèle client-serveur où le client est représenté par la station
d’administration ou NMS (Network Management Station) qui interroge des serveurs représentés
par les agents SNMP implantés sur les MN. Ces MN du réseau peuvent être des machines hôtes
(stations de travail ou serveurs), des éléments d’interconnexion (hubs, routeurs ou commutateurs),
ou tout autre composant administrable. [12]

SNMP fonctionne au niveau 7 du modèle OSI mais s’appuie directement sur le protocole UDP
(User Datagram Protocol). Il a donc besoin d’un numéro de port pour communiquer. Du fait qu’il
utilise UDP, SNMP fonctionne en mode non-connecté c’est-à-dire sans contrôle des données
transmises.[13]

Deux ports sont normalement réservés à SNMP :

− port 161 : La station d’administration émet des commandes (set, get, getnext) vers l’agent
qui répond (response). Le port mis en œuvre lors de cet échange est le port 161, tant sur la
NMS que sur le MN.
− port 162 : Les messages d’alerte (traps) émis par l’agent vers la station d’administration
sont échangés sur le port 162.

La NMS et le MN doivent donc disposer du couple protocolaire UDP-IP pour envoyer et recevoir
des messages SNMP sur le port 161 et recevoir les alertes (traps) sur le port 162. [13]

c) La MIB

Chaque variable SNMP peut ainsi être retrouvée soit à partir de son nom, soit à partir de son OID.
Dans un processus SNMP, bien que le protocole de base soit toujours le même, chaque agent
rapporte différents types d’information donc ainsi différents OID. Par exemple les imprimantes
indiquent les niveaux d’encre et de papier, tandis que les serveurs indiquent la charge de leurs
processeurs. Une « MIB » est simplement un fichier qui indique au NMS les informations que cet
agent particulier peut rapporter et quelles commandes il peut accepter. Une MIB est fournie par
chaque fabricant d’agent, et il doit être chargé dans la NMS dans le cadre de la configuration du
nouvel agent. Le nombre des variables à stocker dans les MIB étant très important, l’OSI a défini
une structure de classification appelée SMI (Structure of Management Information). Les OID sont
établis à partir d’une classification arborescente. [13] [14]

21
 Figure 2.01 : Structure en arbre d’une MIB.

d) Techniques de supervision avec SNMP

SNMP peut être utilisé de deux manières distinctes : en utilisant le polling ou les traps.

− Le polling

Le polling consiste à envoyer une requête à intervalles de temps réguliers pour obtenir une
information particulière. Cette technique est appelée vérification active. Si la requête échoue, il est
possible qu’il y ait un problème avec le périphérique. Cependant, vu que le SNMP s’appuie sur
UDP, il est conseillé de réitérer la requête pour confirmer le problème (surtout dans le cas d’une
vérification via Internet).[12]

− Les traps

Les traps consistent à faire de la vérification passive. C’est-à-dire que l’on peut configurer un
périphérique réseau pour qu’il envoie une trap SNMP lors de certains événements. Quand un
événement relié à la trap apparait, l’agent sur le périphérique va envoyer la trap vers une
destination communément appelé « trap host ». Le trap host possède son propre agent SNMP qui
va accepter et traiter les traps lorsqu’ils arrivent. Le traitement des traps est effectué par des « trap
handlers » qui répondent aux traps, par l’envoi d’un email d’alerte par exemple. [14]

22
e) Les requêtes SNMP

Le mécanisme de base du protocole SNMP est constitué d’échanges de type requête/réponse ou

PDU (Protocol Data Unit). En fonction de la version du protocole SNMP utilisé, différentes
commandes sont possibles.

Figure 2.02: Structure d’une trame SNMP.

Le message SNMP comporte trois champs :

− Le champ « Version » assure la compatibilité du protocole entre interlocuteurs. NMS et

agent doivent utiliser le même numéro.
− Le champ « Communauté » repère l’ensemble des équipements répondant à une même
politique d’administration.
− La zone « PDU » contient la demande du NMS ou la réponse d’un agent ainsi que
l’identifiant de la commande, le type d’erreur éventuelle, un index sur l’erreur éventuelle
ou des variables. [13]

Les types de requêtes du NMS vers l’agent SNMP sont :

− Get Request : Le NMS interroge un agent sur les valeurs d’un ou de plusieurs objets d’une
MIB.
− Get Next Request : Le NMS interroge un agent pour obtenir la valeur de l’objet suivant
dans l’arbre des objets de l’agent. Cette interrogation permet de balayer des objets indexés
de type tableau.
− Get Bulk Request : Cette requête permet de mixer la commande GET et GETNEXT pour
obtenir des blocs entiers de réponses de la part de l’agent.
− Set Request : Le NMS positionne ou modifie la valeur d’un objet dans l’agent.

23
Les réponses ou informations de l’agent vers le NMS sont :

− Get Response : L’agent répond aux interrogations du NMS.

− Trap : L’équipement génère un envoi vers son manager pour signaler un événement, un
changement d’état ou un défaut. L’agent n’attend pas d’acquittement de la part du
manager.
− Notification : Introduite avec la version 2 du protocole SNMP. L’équipement génère un
envoi vers son manager pour signaler un événement, un changement d’état ou un défaut.
L’agent n’attend pas d’acquittement de la part du manager.
− Inform : Introduite avec la version 2 du protocole SNMP. L’équipement génère un envoi
vers son manager pour signaler un événement, un changement d’état ou un défaut. L’agent
attend un d’acquittement de la part du manager et il y aura une retransmission en cas
d’absence de réponse. [13] [14]

Figure 2.03 : Les échanges entre le manager et l’agent SNMP.

2.2.5.4 Syslog
Le Syslog est un système de journalisation des messages qui permet à un périphérique d’envoyer
des notifications d’événements dans les réseaux IP. Ces messages peuvent être utilisées pour la
gestion du système, ainsi que pour l’audit de sécurité. Les journaux Syslog sont pris en charge sur
une variété de périphériques allant des imprimantes aux routeurs et aux pares-feux. Les messages
Syslog sont similaires aux traps SNMP. Un service Syslog ou l’agent prend en compte des
événements qui se produisent sur le périphérique et envoie à un système d’écoute à distance. [10]

2.2.5.6 Analyse du fichier Log

Les applications et les processus écrivent des messages dans un fichier texte brut sur l’appareil sur
lequel ils sont exécutés, appelé fichier journal ou Log. La technique de surveillance y afférant

24
consiste à lire ce fichier par l’intermédiaire d’un script ou d’une application et y chercher des
phrases ou des mots clés traduisant une erreur ou une panne quelconque afin de déclencher une
alarme ou un processus. [10]

2.2.5.5 IP SLA
Les IP SLA (Internet Protocol Service Level Agreement) ou accords de niveau de service de
protocole Internet sont un ensemble assez complet de fonctionnalités intégrées aux équipements
CISCO et de nos jours, il est accessible pour beaucoup d’autres équipements. Ses capacités sont
toutes axées pour garantir un environnement WAN, et plus spécifiquement VoIP (Voice Over IP),
en bonne santé en utilisant les périphériques faisant partie de l’infrastructure réseau au lieu de
configurer des périphériques distincts pour exécuter tests. Il permet de mesurer les performances
du réseau, de surveiller les services IP et de dépanner leurs réseaux. [10] [15]

2.2.5.6 Analyse des flux

L’analyse de flux est par définition l’observation de tous les flux transitant sur le réseau. Une fois
le système mis en place, les valeurs remontées et traitées doivent permettre de constituer des
indicateurs clés. L’IETF a pris en charge la normalisation de l’export de données, basé sur la
version 9 de NetFlow. En plus des indicateurs, il faut aussi disposer d’un collecteur d’informations
: son rôle est de collecter les informations envoyées par les éléments du réseau et de les compiler
afin d’afficher les informations désirées, sous des formes exploitables. Présentés sous forme de
tableaux de bord, les résultats des analyses de flux permettent une lecture de la performance du
réseau. [16]

2.2.6 Terminologies pour la surveillance réseau

Il existe quelques aspects fondamentaux d’un système de surveillance, peu importe le logiciel, le
protocole, ou la technique utilisée.

2.2.6.1 Elément à superviser

Un élément est un aspect unique de l’appareil à surveiller, qui renvoie un ou plusieurs types
d’information. [10]

2.2.6.2 Acquisition
L’obtention d’informations est un autre concept clé. Ce processus s’appelle l’acquisition. Il faut
définir si la routine de surveillance doit attendre que l’appareil envoie un statut pour mettre à jour,
ou si l’appareil va de manière proactive interroger le dispositif de surveillance. [10]

25
2.2.6.3 Fréquence
Etroitement liée à l’acquisition, c’est la fréquence à laquelle l’information revient au dispositif de
surveillance. Il faut alors définir si l’appareil envoie un « battement de cœur » toutes les quelques
minutes ou s’il n’envoie des données que lorsqu’il y a un problème. [10]

2.2.6.4 Seuil
Mis à part la collecte de statistiques, l’un des principaux principes de la surveillance est la
vérification d’un seuil. Il peut s’agir d’une ligne simple, ou plus complexe qui une fois dépassée
traduit un état de l’élément à surveiller. [10]

2.2.6.5 Reset
Reset est l’opposé logique du seuil. Il marque le point où un appareil est considéré comme
« retournant à la normale ». [10]

2.2.6.6 Réponse
Que se passe-t-il lorsqu’un seuil est violé ? La réponse définit cet aspect. Une réponse pourrait
être l’envoi d’un e-mail, la lecture d’un fichier son ou exécution ou un scénario prédéfinit dans un
fichier. [10]

2.2.6.7 Requester
Le « requester » est le point à partir duquel les données concernant les équipements sont récoltées.
[10]

2.2.7 Modes de déploiement des logiciels de supervision

Les logiciels de supervision sont des solutions applicatives ayant pour but de connaître à tout
instant l’état des MN et l’état des services tournant sur les différents serveurs. Pour atteindre cet
objectif, ils peuvent être déployés de différentes façons.

2.2.7.1 Déploiement centralisé

La supervision des éléments du réseau est centralisée en un point unique, par ce qu’elle n’est
assurée que par un seul ordinateur. Si cette machine vient à tomber en panne, tout le processus de
supervision est alors compromis. De plus, elle doit être suffisamment robuste pour pouvoir traiter
l’ensemble des données de supervision du réseau. Enfin, la machine effectue la totalité des
requêtes de supervision, ce qui a pour conséquence d’augmenter fortement le trafic réseau en
provenance de cette machine. [9]

26
2.2.7.2 Déploiement hiérarchique
Un serveur de supervision central dialogue avec d’autres serveurs de supervision ne s’occupant
chacun que d’un segment de réseau. Ces mêmes serveurs peuvent aussi avoir d’autres serveurs
sous leur responsabilité. Ce type de déploiement est bien plus délicat à mettre en œuvre qu’un
simple déploiement centralisé mais offre une tolérance aux pannes bien plus élevée. De plus un tel
déploiement permet d’avoir plusieurs visions du réseau. Toutefois, un déploiement hiérarchique
reste plus coûteux en temps de réponse qu’un déploiement centralisé. [9]

2.2.7.3 Déploiement distribué

Ce déploiement combine l’approche centralisée et l’approche hiérarchique. Chaque station de
supervision tient à jour une base de données complète. Toutes les stations échangent donc entre
elles les données de supervision, sans restriction. Cela permet même de spécialiser certaines
machines sur un traitement de supervision précis. [9]

2.2.8 Etude comparative des outils de supervision

Il existe plusieurs outils de supervision utilisés dans les entreprises. Dans cette section seront
présentés les outils les plus utilisés sur le marché qui existent ainsi que leurs comparaisons. Le
choix des outils de supervision pour le comparatif précédent s’est basé sur plusieurs facteurs :

− totalement Open-source ;
− encore supportés ;
− permettent une génération de graphes;
− fonctionnent sur différents équipements (switches, routeurs, serveurs, ...) ;
− disposent d’une interface web ;
− gèrent le SNMPv3.

2.2.8.1 Nagios
a) Présentation de l’outil

NAGIOS, anciennement nommé « 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 forte modularité de Nagios permet
aujourd’hui de pouvoir superviser pratiquement n’importe quelle ressource.

27
b) Avantages

− La supervision à distance peut utiliser SSH (Secure SHell) ou un tunnel SSL (Secure
Sockets Layer) ;
− Les plugins sont écrits dans les langages de programmation les plus adaptés à leurs tâches :
scripts shell , C++, Perl, Python, Ruby, PHP (Hypertext Preprocessor), C# ;
− La remontée des alertes est entièrement paramétrable.

c) 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 « lignes de commandes » et doivent
être réalisées côté supervision comme côté serveur à superviser. [17]

2.2.8.2 Cacti
a) Présentation de l’outil

C’est un logiciel de supervision réseau basé sur RRDTool (Round-Robin Database Tool). Il peut
être considéré comme un successeur à MRTG et également comme une interface à RRDTool.
Cacti permet de représenter graphiquement divers états des périphériques réseau utilisant SNMP
ou encore grâce à des scripts pour avoir par exemple l’espace disque restant ou bien la mémoire
utilisée, la charge du processeur ou le ping d’un élément actif. Les données sont récoltées auprès
des différents agents SNMP (ou auprès des scripts locaux) grâce à un script PHP.

b) Avantages

− Configuration : avec l’utilisation des « templates » pour les machines, les graphiques, et la
récupération des données tout se configure aisément et entièrement via l’interface web.
L’import et l’export des « templates » au format XML (eXtensible Markup Language) est
très simple.
− Gestion des utilisateurs ;

28
 − Communauté sur le web : présence d’une dizaine de plugins permettant d’étendre les
fonctionnalités.

d) Inconvénients :

− Pas de gestion d’alarmes ;

− Pas de gestion de panne et absence d’une cartographie de réseau ;
− Un développement lent. [17] [18]

2.2.8.3 Zabix
a) Présentation de l’outil

C’est un outil de supervision, ambitionnant de concurrencer Nagios et MRTG. Il fait la

supervision technique et applicative, 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 ainsi que de la découverte de
réseau.

b) Avantages

− Richesse des sondes et tests possibles (supervision d’applications Web, par exemple) ;
− Réalisation de graphiques et cartes ;
− Configuration par la GUI (Graphic user Interface) ;
− 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 ;
− Ses agents sont assez légers.

c) Inconvénients

− L’interface est un peu vaste, la mise en place des « templates » n’est pas évidente au début
: petit temps de formation nécessaire ;
− L’agent zabbix communique par défaut en clair les informations, nécessité de sécuriser ces
données ;
− Peu d’interfaçage avec d’autres solutions commerciales. [17]

29
2.2.8.4 Centreon
a) Présentation de l’outil

Anciennement appelé Oréon, créé en 2003 par des français souhaitant améliorer Nagios, il a été
repris par une nouvelle entreprise nommée Merethis. Il se présente comme une évolution de celui-
ci pour tout d’abord sur son interface mais aussi ses fonctionnalités. Il s’appuie également sur les
technologies Apache et PHP pour l’interface web, MySQL pour le stockage des données de
configuration et de supervision.

b) Avantages

− Une installation complète et automatique des packages nécessaires à l’utilisation de

Nagios ;
− Facilite la configuration de Nagios ;
− Une découverte automatique du réseau via NMAP ;
− Graphe le résultat des alertes, système de « reporting ».

c) Inconvénients

− Requiert plus de ressources matérielles que Nagios. [17] [19]

2.2.8.5 Check_mk
a) Présentation de l’outil

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.

b) Avantages

− Installation et configuration facile ;

− L’interface Web est beaucoup plus intuitive et qui 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 de développer des sondes.

30
c) Inconvénients

− Offre plus de services sur l’environnement Unix. [17]

2.2.9 Choix de l’outil mis en place

La solution choisit pour ce projet de mémoire est Nagios, en raison des avantages qu’il présente
mais aussi en raison du fait que ses inconvénients sont les moins négligeables en termes de
fonctionnalité. En effet, ces derniers ne concernent pas sa performance ni sa qualité mais se
résument plutôt à des difficultés au niveau de sa configuration. Par ailleurs, Nagios est la solution
la plus flexible et la plus modulaire, de ce fait il est possible d’intégrer à terme des outils de
graphes, une nouvelle interface graphique ainsi que de nombreux autres extensions.

2.3 Méthode de classification de trafic réseau par Machine Learning

2.3.1 Nécessité de la classification de trafic

Actuellement, les entreprises utilisent de plus en plus de systèmes de détection d’intrusions ou
IDS (Intrusion Detection System) pour compléter le travail des pares-feux. Ces systèmes doivent
traiter deux problèmes : le haut débit et le nombre croissant des signatures d’attaques sur le trafic
internet. Afin de résoudre ces problèmes, la classification de trafic intervient pour :

− faciliter le travail des IDS ;

− fournir un mappage de classe de service ou CoS (Class of Services) ;
− le contrôle de qualité de service ;
− fournir des statistiques pour la surveillance du réseau. [20]

2.3.2 Méthodes existantes

Plusieurs méthodes ont été utilisées pour la classification de trafic. Cette section mettra en
évidence les travaux passés effectués et actuels dans ce domaine, en outre, il va mettre en évidence
les avantages de l’approche par Machine Learning.

2.3.2.1 Classification basée sur les ports

a) Principe de l’approche

Afin de pouvoir envoyer et recevoir des données sur internet, on utilise surtout comme protocoles
de transport : TCP en mode connecté et UDP en mode non connecté. Tous les deux utilisent le

31
concept de ports logiques pour distinguer les connections entre deux extrémités de la connexion.
Les numéros de port TCP et UDP sont codé sur 16 bits délimitant ainsi leurs valeurs entre 0 et
65535. L’IANA (Internet Assigned Numbers Authority) est l’organisme responsable de
l’enregistrement de ces ports qui sont divisés en trois catégories :

− ports connus : 0-1023, requièrent des privilèges d’administrateurs ;

− ports enregistrés : 1024-49151, peuvent être utilisés par les autres utilisateurs pour des
processus courants ;
− ports privés : 49152-65535, ne peuvent pas être enregistrés par l’IANA et ne sont utilisés
que temporairement. [21]

Les ports connus ont la particularité d’être assignés aux applications les plus connues. Le système
de classification regarde alors le numéro de port dans le premier paquet de demande de
synchronisation TCP SYN pour pouvoir le comparer à la liste de port de l’IANA et ensuite
procéder à la classification de l’application. Dans le cas de UDP, la procédure est la même mais
sans établissement de connexion. [21]

Initialise la connexion Accepte la connexion

Figure 2.04 : Diagramme d’établissement de connexion avec TCP.

Figure 2.05 : Structure d’un segment TCP.

32
b) Limites

Avec l’augmentation du trafic Internet et les applications P2P (Peer to Peer) telles que bittorrent,
Napster et Kaaza qui n’utilisent pas des ports enregistrés avec l’IANA, cette méthode présente
actuellement des limites.

En outre, en raison des vulnérabilités connues des différentes applications, les administrateurs
réseau préfèrent utiliser des numéros de port différents plutôt que des ports enregistrés pour des
applications particulières. Ce qui rend la classification difficile. On observe jusqu’à 70% de taux
d’efficacité pour cette méthode soit une incapacité à classifier 30% des paquets. Cette incapacité a
forcé les chercheurs à trouver de nouvelles techniques de classification. [22]

2.3.2.2 Classification basée sur la charge utile et l’inspection des paquets

a) Principe de l’approche

Les méthodes nées de cette problématique utilisent une approche dite basée sur la charge utile ou
encore DPI (Deep Packet Inspection). Ces techniques visent à reconnaitre le type d’application en
se basant sur l’inspection de la charge utile des paquets dans la couche d’application. Une des
méthodes utilisées est la méthode basée sur la signature. Cette méthode vise à rechercher dans la
charge utile les signatures des protocoles connus. [23]

Pour réduire la consommation de ressource engendrée par cette méthode, de nouvelles méthodes
ont vues le jour ayant pour principe de rechercher des chaînes de caractères spécifiques ou des
modèles de séquences de bits dans l’en-tête des paquets. Ces méthodes utilisent donc aussi des
signatures prédéfinies pour classifier le trafic [22].

b) Limites

Certains protocoles sont complexes et ne sont pas faciles à inspecter. Par ailleurs, certains utilisent
le cryptage pour empêcher leurs identifications pour des raisons de sécurité.

En outre l’inspection de la syntaxe de la charge utile des paquets impose une lourde charge
opérationnelle et un retard dû à un temps de traitement important.

Cependant, malgré ses inconvénients, cette méthode est encore largement utilisée en raison de sa
haute fiabilité comparée aux méthodes basées sur le port mais elle n’est pas idéale pour la
classification en temps réel ni pour les réseaux de grande envergure. [22] [23]

33
2.3.2.3 Classification basée sur les statistiques

La plupart des méthodes récentes utilisent l’approche statistique pour la classification de trafic.
L’idée derrière cette approche est que le trafic de la couche réseau a des propriétés statistiques
uniques telles que le temps d’inter-arrivée des paquets, la longueur du paquet, le temps d’inactivité
et la durée du flux qui peuvent être utilisés pour classer le trafic par applications, vue que ces
paramètres diffèrent dans chaque cas. Les résultats de ces études ont donné un nouveau visage aux
techniques de classification du trafic. Avec l’arrivé de l’intelligence artificielle, les chercheurs ont
commencé à appliquer des méthodes d’exploration de données (voir définition 2.06) et
d’apprentissage automatique (voir définition 2.05) afin d’améliorer ces méthodes. [22]

2.3.3 Fondamentaux du Machine Learning

2.3.3.1 Généralités et terminologies

Définition 2.05

Le « Machine Learning » ou Apprentissage Automatique est une technologie d’analyse de

données qui est capable d’extraire des connaissances ou des informations sans être explicitement
programmé pour le faire. Des données provenant de diverses sources potentielles (telles que des
applications, des capteurs, des réseaux d’appareils ou des appareils, les connaissances d’un expert)
alimentent le système d’apprentissage automatique, qui les utilise avec des algorithmes, pour
construire sa propre logique afin de résoudre un problème ou pour tirer des conclusions. [8]

Définition 2.06

Le « Deep Learning » ou apprentissage en profondeur est le processus d’application des

technologies de réseaux neuronaux profonds, c’est-à-dire des architectures de réseaux neuronaux
avec plusieurs couches cachées de neurones, pour résoudre des problèmes. [24]

Figure 2.06 : Architecture standard d’un réseau de neurone convolutif.

34
Définition 2.07

Le « Data Mining » ou « exploration de données » désigne l’analyse de données depuis différentes

perspectives et le fait de transformer ces données en informations utiles, en établissant des
relations entre les données ou en repérant des traits caractéristiques appelés « patterns ». [24]

2.3.3.2 Concept du Machine Learning (ML)

Figure 2.07 : Fonctionnement de base du Machine Learning.

Le concept du ML (Machine Learning) est basé sur les données d’entrées, le processus
d’apprentissage et la donnée de sortie (voir figure 2.07).

a) Données d’entrée

L’entrée d’un processus d’apprentissage automatique est un ensemble de données d’instances ou

d’exemples appelé « data sets ». Ces instances sont obtenues à partir de caractéristiques également
appelées « discriminateurs ». De très gros volumes de données sont souvent utilisés pour entrainer
la machine parce que plus de données donne plus d’idées et de précision. [8]

b) Processus d’apprentissage

Le type d’apprentissage est soit supervisé soit non-supervisé. Cependant, selon la manière de
traiter les données d’entrée, les exigences de calcul et de stockage, on distingue deux méthodes
d’apprentissage :

− Les méthodes d’apprentissage effectives évaluent les données d’apprentissage et procèdent

directement au calcul avant de recevoir de nouvelles données. En conséquence, ces
méthodes ont tendance à consacrer plus de temps au traitement données d’apprentissage ;

35
 − Les méthodes d’apprentissage paresseuses retardent le traitement et l’évaluation des
données jusqu’à ce que de nouvelles données de test soient fournies. En conséquence, ces
méthodes consacrent plus de temps à prédire. [8]

c) Données de sortie

Le Machine Learning peut être utilisé pour fournir des résultats prédictifs ou prescriptives, ou des
classifications d’information.

Ces données de sortie peuvent être stockés pour l’analyse, livrés sous forme de rapports ou servir
d’entrée pour d’autres applications d’entreprise ou systèmes. [8] [24]

2.3.3.3 Types d’apprentissage

a) Apprentissage supervisé

Des paires d’échantillons, appelées données préétiquetées, sont utilisées pour former le système
d’apprentissage afin de reconnaître certaines règles pour corréler les entrées aux sorties. [8]

Définition 2.08

La classification est une forme d’apprentissage supervisé qui a pour but la construction de
modèles pouvant séparer les données en classes distinctes. [24]

Ces modèles sont construits en entrant un ensemble de données d’apprentissage pour lesquelles les
classes sont préétiquetées afin que l’algorithme puisse apprendre. Le modèle est ensuite utilisé en
entrant un ensemble de données différent pour lequel les classes sont retenues, ce qui permet au
modèle de prévoir leur appartenance à une classe en fonction de ce qu’il a appris à partir des
données d’apprentissage.

b) Apprentissage non supervisé

Les étiquettes sont omises : Dans cette forme de Machine Learning, plutôt que d’être « formés »
avec des données échantillons, le système d’apprentissage automatique trouve des structures et des
« patterns » dans la donnée en soi. [8]

Le « clustering » est une forme d’apprentissage non supervisé qui ne nécessite pas de pré-
étiquetage des classes d’instances, c’est-à-dire qu’il apprend par l’observation plutôt que par
l’exemple. [24]

36
2.3.4 Classification de trafic par Machine Learning

Prétraitement des données

Capture du flux •Selection des caractéristiques utilisés
pour la classification
brut •Extraction des caractéristiques
•Conversion de format et étiquetage

Machine Learning
•Application de l’algorithme de ML Evaluation du
•Entrainement du modèle résultat
•Test du modèle obtenu

Figure 2.08 : Diagramme de base de la classification de trafic par ML.

En règle générale, la classification du trafic avec des algorithmes ML peut être effectuée en quatre
étapes illustrées par la figure 2.08.

2.3.4.1 Collecte de données

La collecte de données et le pré-traitement des données, sont les étapes les plus difficiles et elles
requièrent le plus de temps. Il est important de comprendre que la collecte de donnée en soit n’est
pas difficile. Cependant, la collecte des données pertinentes pour l’entrainement du modèle peut
s’avérer être une tâche assez compliquée. Dans le cadre de ce projet de mémoire, qui est la
classification du trafic TCP par ML, les données pertinentes à collecter sont :

− Des traces de trafic TCP sain ;

− Des traces de trafic TCP infecté par des injections de paquets.

Définition 2.09

L’injection de paquets désigne le processus d’interférence avec une connexion réseau établie, en
générant des paquets qui apparaissent comme faisant partie du flux de communication normal.

Elle est souvent utilisée pendant la mise en œuvre des attaques du type MITM (Man In The
Middle), ou de type DoS (Deny of Services).

Par ailleurs l’injection de paquet est aussi utilisée pour les tests de pénétration pour évaluer les
performances des IDS. [25]

37
Les moyens suivants peuvent servir d’approche pour la collecte de données :

− Importer des « datasets » fournis et maintenus par des organismes de recherche ou des
individus volontaires à des fins de recherche ;
− Utiliser des fichiers journaux de différents IDS et pare-feu. Ces fichiers peuvent contenir
des signatures qui peuvent être utilisées à des fins de classification ;
− Simuler une attaque et faire une capture directe du trafic.

2.3.4.2 Prétraitement des données

Le prétraitement des données est la partie la plus importante de l’étape de classification
puisqu’elle comprend la phase de sélection des attributs pour la classification. Pour la
classification des flux TCP, les études et recherches publiées ont conduit à la liste d’attributs
spécifiques suivante qui sera retenue pour la méthode de classification pour ce projet :

− « Frame Length » représente la taille d’un paquet IPv4 sur le réseau ;

− « Source Port » (16 bits) relatif à l’application en cours sur la machine source ;
− « Destination Port » (16 bits) relatif à l’application en cours sur la machine de destination ;
− « TCP Header Length » est la taille de l’en-tête du protocole TCP en octets ;
− « IP Header Length » est la taille de l’en-tête IP en octets ;
− « Protocole IP » représente le type de protocole de communication utilisé ;
− « TCP Sequence Number » est un nombre de 32 bits utilisé pour maintenir la trace des
données TCP ;
− La taille de la fenêtre représente la taille de données en octets pouvant être reçue par le
récepteur dans l’en-tête TCP. [26]

2.3.4.3 Algorithmes d’apprentissages utilisés pour la classification

Il existe plusieurs algorithmes utilisés pour la classification de trafic.

a) Arbre de décision

Un Arbre de décision est un classificateur représenté sous forme d’arbre qui classe les instances en
les triant en fonction de valeurs caractéristiques où chaque nœud de l’arbre teste les attributs, les
branches représentent les valeurs possibles de l’attribut testé et les feuilles représentent les classes
prédites. A chaque niveau de l’arbre de décision, un attribut qui divise le mieux l’arbre en sous-
classes est sélectionné de différentes façons basées sur l’entropie ou le gain d’information.

38
L’avantage de cette méthode sur la classification de trafic est que les arbres sont plus ou moins
explicites et faciles à interpréter. Cependant, l’utilisation de cet algorithme pour la classification
de trafic est très délicate puisqu’une valeur corrompue située près de la racine peut compromettre
tout l’arbre. [27]

b) Naïve Bayes

Le Naïve Bayes est un algorithme de classification issu du réseau Bayésien ou BN (Bayesian

Network). L’application des techniques du réseau bayésien à la classification implique deux sous-
tâches : l’apprentissage du BN (formation) pour obtenir un modèle et une inférence BN pour
classer les instances. L’apprentissage des modèles BN peut être très efficace. Quant à l’inférence
du réseau bayésien, il se réduit à une simple multiplication dans le contexte de classification,
quand toutes les valeurs des attributs du « dataset » sont connues. [28] Naïve-Bayes a été utilisé
comme un classificateur efficace pendant de nombreuses années. Contrairement à beaucoup
d’autres classificateurs, il est facile à construire, cependant il suppose que toutes les
caractéristiques sont indépendantes les unes des autres. [29]

c) Support Vector Machine

Les SVM (Support Vector Machine) sont des algorithmes puissants utilisés pour résoudre les
problèmes de classification et de régression. Ils sont capables de classer des données linéaires et
non linéaires. La limite de séparation optimale, ou les limites, entre les classes sont appelées
hyperplans (Z1 et Z2, voir figure 2.09), sont identifiées en localisant les vecteurs de support, et
leurs marges, qui sont les lignes parallèles à l’hyperplan sont définies par la distance la plus courte
entre un hyperplan et son vecteur de soutien. Les SVM contribuent à une classification très
précise, un autre avantage de ces algorithmes est qu’ils peuvent gérer les valeurs manquantes et le
bruit efficacement. Cependant, ceux-ci sont complexes et ont des exigences de mémoire élevées.
[27]

Figure 2.09 : Support Vertor Machine.

39
2.3.4.4 Paramètres d’évaluation du modèle créé
Il existe des indicateurs qui permettent de mesurer la qualité d’un modèle. Pour mesurer les
performances d’un classifieur, il est d’usage de distinguer quatre types d’éléments classés pour la
classe voulue. Prenons l’exemple de deux classes normale N et anormale A.

− Vrai positif VP. Elément de la classe N correctement prédit ;

− Vrai négatif VN. Elément de la classe A correctement prédit ;
− Faux positif FP. Elément de la classe N mal prédit ;
− Faux négatif FN. Elément de la classe A mal prédit.

Appartient à Normale (N) Anormale (A)

Normale (N) Vrai positif Faux négatif
Anormale (A) Faux positif Faux positif
Tableau 2.01 : Tableau des paramètres d’évaluation.

Ces informations peuvent être rassemblés et visualisés dans une matrice appelée matrice de
confusion. En particulier, si la matrice de confusion est diagonale, le classifieur est parfait. [28]

2.3.5 Choix de l’algorithme pour la classification de trafic

Dans le cadre de ce projet, l’algorithme de classification de trafic Naïve Bayes sera utilisé pour
catégoriser le trafic TCP normal du trafic anormal. Des « datasets » étiquetés, serviront d’entrée
au classificateur Naïve Bayes pour l’apprentissage supervisé.

D’après les résultats obtenus dans les précédentes recherches sur la classification de trafic, en
général 95% de précision peut être obtenue en utilisant des techniques d’analyse bayésiennes. De
plus, les classificateurs bayésiens économisent beaucoup de temps de traitement et d’entraînement
par rapport aux autres algorithmes d’apprentissage. [27]

2.4 Conclusion
L’informatique d’entreprise a considérablement évolué au cours de la dernière décennie.
Aujourd’hui, les équipes informatiques sont, non seulement responsables de la disponibilité et des
performances du réseau, mais aussi de sa sécurité. La solution de surveillance Nagios et la
classification de trafic basée sur l’algorithme d’apprentissage automatique basé sur le réseau
bayésien permettent d’atteindre ces buts. Le chapitre suivant traite l’aspect mathématique du
thème et vise ainsi à donner une modélisation mathématique du modèle de classification obtenu.

40
 CHAPITRE 3
IMPLEMENTATION DE LA SOLUTION DE MONITORING

3.1 Introduction
Dans ce chapitre seront présentés les étapes d’implémentation de la solution de monitoring ainsi
que l’interprétation des résultats retournés.

3.2 Implémentation de la solution de monitoring

3.2.1 Simulation de l’architecture réseau

Afin de tester les fonctionnalités du système de supervision, il est nécessaire de le déployer dans
un premier temps, dans une architecture virtuelle. Ainsi, le bon choix des outils de simulation est
important pour pouvoir recréer à la limite du possible l’environnement où le projet sera
implémenté. L’infrastructure réseau est simulée avec le logiciel GNS3 (Graphical Network
Simulator).

Figure 3.01 : Simulation de l’architecture réseau sur GNS3.

La figure 3.01 représente l’architecture du réseau simulé sur GNS3.

Le parc de serveurs du siège est composé de (de gauche à droite) :

− un serveur sur Ubuntu 16.04 LTS, installé sur une machine virtuelle émulée avec
VirtualBox;

41
 − un serveur de supervision Nagios, installé sur une machine virtuelle Ubuntu 16.04 LTS,
émulée avec VirtualBox ;
− un émulateur de serveurs ou Multiserveur Paessler, installé sur la machine hôte et relié par
une interface Loopback au simulateur GNS3;
− un serveur sur Windows Server, installé sur une machine virtuelle émulée sur VirtualBox.

Les parcs clients sont composés d’un PC virtuel sur VPCS (Virtual PC Simulator) et d’une
imprimante réseau.

Les switches utilisés sont les switches Ethernet par défaut de GNS3.

Les routeurs sont des routeurs Mikrotik avec le système d’exploitation Mikrotik CHR (Cloud
Hosted Router). L’installation et la configuration des routeurs est présentée en annexe (voir
annexe A1).

Le routeur R_1 représente le routeur central du siège.

Les routeurs R_2, R_3, R_4 sont les routeurs des sites distants. Les liaisons du siège avec les sites
distants sont émulées par le logiciel WANem (Wide Area Network Emulator), permettant de
simuler divers types de liaisons pour chaque site (voir tableau 3.01).

Le routeur R_5 est le routeur d’accès à internet, une de ses interfaces est reliée à la machine hôte
pour permettre de partager la connexion internet avec le réseau local simulé.

3.2.1.1 Présentation de GNS3

GNS3 est un simulateur de réseau qui permet à l’utilisateur d’émuler plusieurs systèmes, y
compris des routeurs Cisco, Juniper, Mikrotik, Vyatta, des machines virtuelles sous Linux,
Windows, Mac et bien d’autres systèmes. GNS3 est la rencontre entre plusieurs systèmes
d’émulation, cependant, les systèmes mis en œuvre dans ce projet sont : [30]

a) Dynamips

Il est utilisé pour l’émulation des équipements CISCO et fonctionne sur FreeBSD, Linux, Mac OS
X ou Windows. Il peut émuler le matériel des plates-formes de routage Cisco en démarrant
directement une image logicielle Cisco IOS sur l’émulateur. [31]

42
Nous allons utiliser Dynamips pour l’émulation des switches CISCO. Cependant, pour les
routeurs, qui sont des routeurs Mikrotik, nous allons donc faire appel aux autres émulateurs reliés
à GNS3.

b) Quemu

Quemu (Quick EMUlator) est un émulateur rapide multi-plateforme et open source. Il permet
d’émuler les équipements CISCO, Juniper, Mikrotik ainsi que des machines virtuelles Linux. [30]

c) Oracle VM VirtualBox

Oracle VM VirtualBox (anciennement VirtualBox) est un logiciel libre de virtualisation publié par
Oracle. Nous allons l’utiliser pour l’émulation des serveurs et postes clients à superviser. Avec
VirtualBox, chaque instance de machine génère une copie de son propre système d’exploitation.
Chaque copie entrera en compétition pour l’utilisation du RAM (Random Access Memory) et du
CPU de la machine hôte. [30]

e) Wireshark : permet de visualiser les paquets véhiculant dans le réseau.

f) VPCS: permet de simuler plusieurs postes pour effectuer des requêtes pour les tests de
liaison comme ping et traceroute.

3.2.1.2 Configuration des routeurs

a) Configuration des adresses IPv4 et du routage

La configuration des adresses IPv4 sont statiques (voir annexe A1.3 Tableau A1.01) pour presque
tous les équipements à surveiller sauf pour le routeur internet. Le protocole OSPF (Open Shortest
Path First) est mis en œuvre, les étapes de configuration sont décrites en annexe (voir annexe
A1.4). Dans le cadre de ce protocole, chaque routeur établit un lien avec avec chacun de ses
voisins directs, et échange avec eux des informations sur le réseau, sous forme de message LSA
(Link State Advertisements). Ces messages se propagent entre routeurs adjacents, jusqu’à ce qu’ils
soient propagés dans l’ensemble du réseau. Tous les routeurs ont la même connaissance de la
topologie du réseau, et chacun utilise l’algorithme de Dijkstra pour calculer la route la plus courte
vers chaque sous-réseau de sa base de données. [32]

b) Configuration SNMP

43
Sur presque tous les périphériques, le nom de communauté SNMP par défaut du réseau est «
public ». Si la chaîne de communauté par défaut n’est pas modifiée, elle peut être rapidement et
facilement reconnue par les attaquants. Il est donc fortement recommandé que la chaîne par défaut
soit modifiée. Les détails sur la configuration SNMP des routeurs sont présentés dans l’annexe
A1(voir annexe A1.5).[33]

3.2.1.3 Emulation des serveurs à superviser

a) Emulation du serveur mail

Le serveur mail est installé dans la même machine que le serveur de supervision pour disposer
d’un moyen d’envoyer des e-mails à partir de la ligne de commande pour les notifications Nagios.
Le MTA (Mail Transfer Agent) utilisé est Postfix. Il a été configuré pour qu’il relaie les messages
sortants via l’infrastructure Gmail c’est-à-dire en utilisant le MDA (Mail Delivery Agent) de
Gmail pour bénéficier ainsi de la fiabilité et de la robustesse de l’infrastructure de Gmail. Les
détails concernant l’installation du serveur mail sont décrits dans l’annexe A2.

b) Simulation des autres serveurs avec le Simulateur Multiserveur Paessler

A cause de la limite de ressources pour la virtualisation de l’environnement, un simulateur

multiserveur a été utilisé pour les services du réseau. Le Multi Server Simulator Paessler permet, à
des fins de test, de simuler un réseau virtuel de serveurs sur un PC Windows standard. Cet outil est
surtout utilisé pour l’évaluation et le test des outils de gestion de réseau et de test de réseau. Il a
été initialement développé comme un outil de test interne pour les solutions payantes de
surveillance de réseau PRTG Network Monitor et PRTG Traffic Grapher, mais il peut également
servir pour l’évaluation et le test d’autres outils de gestion de réseau comme Nagios.

Figure 3.02: Interface du simulateur multiserveur Paessler.

44
Pour l’installer, il suffit de télécharger l’installation sur la page web officielle et ensuite faire une
demande de licence pour test. [34] La liste des services proposés est présentée à la figure 3.02.

3.2.2 Simulation du lien WAN avec WANem

3.2.2.1 Présentation de WANem

La simulation d’un réseau WAN doit introduire la simulation de retard de transmission, de
restriction de bande passante et d’autres limites afin de soumettre les applications et les protocoles
à tester à un environnement aussi proche que possible du réel afin de mener à bien les tests de
performance. En réponse à cette problématique, le laboratoire d’innovation TCS-PERC (TATA
Consultancy Services - Performance Engineering Research Center) a créé WANem, un logiciel
libre et non-payant modifiable sous GNU General Public License version 2 publié par la Free
Software Foundation. Avec WANem des ensembles de règles peuvent être utilisées pour définir
les caractéristiques réseaux de différents emplacements. Ceci est très important dans le cadre de
notre projet où des agences distantes sont reliées au siège par différents types de liens. [35]

a) WANanalyser

WANem est livré avec un analyseur de lien WANanalyser qui mesure des caractéristiques du
réseau afin de donner une contribution réaliste à l’émulateur WANem.

Figure 3.03 : Résultats de l’analyse par l’outil WAN analyser.

b) Configuration en mode basique

Seul un jeu de règles permettant de spécifier uniquement la bande passante et la latence peut être
appliqué pour chaque interface réseau. La figure 3.04 illustre une capture d’écran de l’interface
graphique en mode basique de WANem avec une interface réseau. [35]

45
 Figure 3.04 : Interface graphique WANem en mode basique.

c) Configuration en mode avancé

En mode avancé, plusieurs autres caractéristiques peuvent être configurées pour chaque interface
comme la perte de paquet, la gigue et la corrélation. La figure 3.05 illustre l’utilisation de ce mode
de fonctionnement.[35]

Figure 3.05 : Interface graphique WANem en mode avancé.

46
3.2.2.2 Installation de WANem
WANem est basé sur le système d’exploitation Knoppix, qui est une distribution Linux dérivée de
Debian. La version de WANem utilisée pour ce projet est la version 3.0 . Les détails de
l’installation de WANem sont présentés en annexe (voir Annexe A3).

3.2.2.3 Configuration
Nous allons configurer les liaisons pour la simulation de façon à représenter les trois types de
média utilisés pour la liaison entre le routeur central et chacun des routeurs distants.

Equipement Type de liaison Caractéristiques de la liaison

Routeur distant R_1 Fibre Optique OC-9 Bande passante : 466.56 Mbps
Latence : 19 ms
Gigue : 4 ms
Routeur distant R_2 ADSL Bande passante :6.144 Mbps
Latence : 100 ms
Gigue : 6 ms
Routeur distant R_3 Laser Bande passante : 622 Mbps
Latence : 3 ms
Gigue : 1 ms
Tableau 3.01 : Types et caractéristiques des liaisons WAN.

Figure 3.06 : Configuration des liaisons sur WANEM..

47
3.2.3 Installation de Nagios
La version installée du logiciel Nagios est la version 4.3.4 de Nagios Core (version gratuite) et le
serveur sur lequel l’installation sera faite aura un système d’exploitation Linux Ubuntu 16.04 LTS.

3.2.3.1 Présentation de l’architecture Nagios

a) Eléments de l’architecture Nagios

− Un ordonnanceur : Nagios est composé essentiellement d’un moteur gérant

l’ordonnancement des vérifications, ainsi que les actions à prendre sur incidents ;
− Une IHM (Interface Homme-Machine) : La partie visible à travers d’un simple serveur
web, tel Apache, est basée sur des CGI (Common Gateway Interface) ;
− Des sondes : Les sondes de Nagios sont des petits scripts ou programmes qui sont la base
des vérifications. Ils peuvent retourner un code d’état : 0=OK, 1=WARNING,
2=CRITICAL et 3=UNKNOWN. [36]

Nagios fournit en standard un bon nombre de sondes de base, mais il est aussi possible d’écrire
pour ses propres besoins ses propres plugins :

− check_disk : Vérifie l’espace occupé d’un disque dur ;

− check_http : Vérifie le service « http » d’un hôte ;
− check_ftp : Vérifie le service « ftp » d’un hôte ;
− check_mysql : Vérifie l’état d’une base de données ;
− check_nt : Vérifie différentes informations sur un système d’exploitation Windows ;
− check_nrpe: Permet de récupérer différentes informations sur les hôtes ;
− check_ping: Vérifie la présence d’un équipement, ainsi que sa durée de réponse ;
− check_pop: Vérifie l’état d’un service POP (serveur mail) ;
− check_snmp : Récupère divers informations grâce au protocole SNMP. [36]

3.2.3.2 Modes de fonctionnement de Nagios

Les deux modes de fonctionnement se basent sur l’exécution d’un « daemon » sur la machine à
surveiller et se combinent généralement pour une efficacité optimale de la supervision.

a) Supervision avec les plugins actifs et NRPE

A la différence des plugins locaux, le module NRPE (Nagios Remote Plugin Executor) permet
l’exécution de plugins actifs directement sur les machines distantes à surveiller. Dans ce cas, la

48
demande d’exécution du plugin actif est faite à l’initiative de la machine serveur Nagios. Le
serveur Nagios demande, via le client NRPE, l’exécution du plugin P sur la machine M. Le
« daemon » NRPE hébergé sur la machine M, reçoit la requête d’exécution du plugin P. Ensuite le
« daemon » récolte les informations suite à l’exécution du plugin P et envoie le résultat au serveur
Nagios qui interprète les résultats et lance le traitement adéquat. [36]

Figure 3.0.7 : Supervision active.

b) Supervision avec les plugins passifs et NSCA

Le module NSCA (Nagios Service Check Acceptor) propose l’exécution de plugins passifs sur les
machines à surveiller. Leur exécution est déclenchée suite à des critères préalablement définis sur
les machines distantes. Le « daemon » NSCA sur une machine M lance l’exécution du plugin P
suite à un critère de déclenchement vérifié sur la machine M. Le daemon NSCA de la machine M
récolte les informations suite à l’exécution du plugin P et envoi le résultat au serveur Nagios qui
interprète les résultats et lance le traitement adéquat.[36]

Figure 3.08 : Supervision active avec NSCA.

3.2.3.3 Installation des prérequis

Il faut installer quelques bibliothèques utiles pour le bon fonctionnement de Nagios, mais surtout à
son installation et sa compilation :

− apache2, php et gd, utiles pour l’ interface de Nagios.

− make et gcc pour les compilations et snmp pour la supervision.

49
 # apt-get update
# apt-get upgrade
# apt-get install unzip apache2 libapache2-mod-php5 php5-gd php5 make gcc build-essential wget libgd-gd2-perl
libgd2-dev libgd2-xpm libgd2-xpm-dev libnet-snmp-perl libssl-dev snmp daemon
# apt-get install autoconf bc gawk dc libc6 make gcc libmcrypt-dev build-essential wget libssl-dev snmpd snmp scli
xinetd snmp libnet-snmp-perl gettext

3.2.3.4 Compilation et installation de Nagios

Installer Nagios revient à créer un utilisateur et télécharger et installer deux archives : le Core
Nagios et ses plug-ins.

a) Création de l’utilisateur

# groupadd nagios
# useradd -m -g nagios nagios
#passwd nagios

Création d’un groupe « nagcmd « permettant l’exécution des commandes externes à travers
l’interface Web. Rajout des utilisateurs Nagios et Apache à l’intérieur du groupe « nagcmd».

# groupadd nagcmd
# usermod -g nagcmd nagios
# usermod -g nagcmd www-data

b) Téléchargement des archives

# mkdir -p /nagios/download
# cd /nagios/download
/nagios/download# wget https://sourceforge.net/projects/nagios/files/nagios-4.x/nagios-4.3.4/nagios-4.3.4.tar.gz
/nagios/download# wget http://www.nagios-plugins.org/download/nagios-plugins-2.2.1.tar.gz

c) Compilation et installation de Nagios

Il faut d’abord procéder à l’extraction de l’archive téléchargé.

# cd /nagios/download/
# tar -xzf nagios-4.3.4.tar.gz

Puis exécuter le script de configuration en lui précisant le nom du groupe créé précédemment.

50
 /nagios/download # cd nagios-4.3.4/
/nagios/download/nagios # ./configure --with-command-group=nagcmd

La compilation du code source se fait par la commande suivante :

/nagios/download/nagios-4.3.4 # make all

/nagios/download/nagios-4.3.4 # make install

Installation du script de démarrage « /etc/init.d/nagios »:

/nagios/download/nagios-4.3.4# make install-init

/usr/bin/install -c -m 755 -d -o root -g root /etc/init.d
/usr/bin/install -c -m 755 -o root -g root daemon-init /etc/init.d/nagios
/nagios/download/nagios-4.3.2# update-rc.d nagios defaults

Installation des fichiers de configuration :

/nagios/download/nagios-4.3.4# make install-config

Les fichiers seront automatiquement installés dans le répertoire « /usr/local/nagios/etc ».

Installation et configuration des permissions :

/nagios/download/nagios-4.3.4# make install-commandmode

/usr/bin/install -c -m 775 -o nagios -g nagcmd -d /usr/local/nagios/var/rw
chmod g+s /usr/local/nagios/var/rw

3.2.3.5 Configuration de l’interface Web

Installation du fichier de configuration de Nagios dans le répertoire conf.d d’Apache :

/nagios/download/nagios-4.3.4# make install-webconf

/usr/bin/install -c -m 644 sample-config/httpd.conf /etc/apache2/conf.d/nagios.conf
if [ 0 -eq 1 ]; then \
ln -s /etc/apache2/conf.d/nagios.conf /etc/apache2/sites-enabled/nagios.conf; \
fi
/nagios/download/nagios-4.3.4# a2enmod rewrite
/nagios/download/nagios-4.3.4# a2enmod a2enmod cgi

51
Création d’un compte « nagiosadmin » pour se connecter à la page Web Nagios :

/nagios/download/nagios-4.3.4# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Redémarrage du service apache2 :

/nagios/download/nagios-4.3.4# /etc/init.d/apache2 stop

[ OK ] Stopping apache2 (via systemctl): apache2.service.
root@supervision:/nagios/download/nagios-4.3.2# /etc/init.d/apache2 start
[ OK ] Starting apache2 (via systemctl): apache2.service.

3.2.3.6 Compilation et installation des plugins

La version des plugins installés est la version 2.2.1. Comme pour la compilation et l’installation
du core, il faut d’abord procéder à l’extraction des archives téléchargées, les compiler et les
installer :

/nagios/download/nagios-4.3.4# cd /nagios/download/
/nagios/download# tar -xzf nagios-plugins-2.2.1.tar.gz
/nagios/download# cd nagios-plugins-2.2.1/
/nagios/download/nagios-plugins-2.2.1# ./configure --with-nagios-user=nagios --with-nagios-group=nagios
/nagios/download/nagios-plugins-2.2.1# make
/nagios/download/nagios-plugins-2.2.1# make install

3.2.3.7 Gestion de démarrage du serveur

Il est important que Nagios et Apache2 puissent être lancés au démarrage du serveur.

# update-rc.d nagios defaults

Ensuite, modifier le fichier « /etc/init.d/nagios » en rajoutant les lignes suivantes :

# Default-Start: 2345
# Default-Stop: 016
Ces deux lignes définissent l’ordre de démarrage et d’arrêt du script Nagios.

2 : Démarrer en mode multi-utilisateur, ne configure pas les interfaces réseau et n’exporte pas les
services de réseau.

3 : Mode multi-utilisateur avec configuration réseau.

52
4 : Démarrer pour des fins spécifiques en définissant l’utilisateur.

5 : Démarrer le système normalement avec le gestionnaire d’affichage de l’interface graphique.

0 : Halte, arrête le script.

1 : Arrête le script en mode mono utilisateur.

6 : Redémarre script.

Ensuite redémarrer l’utilitaire « update-rc.d » :

# update-rc.d nagios defaults

On peut enfin démarrer Nagios par la commande :

# /etc/init.d/nagios start

3.2.3.8 Vérification de l’installation et démarrage du serveur

Après l’installation, et à chaque modification de Nagios, il faut redémarrer Nagios, et s’assurer
que tous les fichiers de configuration sont conformes en lançant la commande de
vérification suivante :

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

3.2.4 Configuration de Nagios

3.2.4.1 Surveillance du poste de supervision

Certains services sont surveillés par défaut sur le poste de supervision, notamment le swap,
l’espace disque de la partition root /, le ping. Pour modifier les services surveillés par Nagios en
local, il faut modifier le fichier /usr/local/nagios/etc/objects/localhost.cfg.

3.2.4.1 Configuration des machines Windows à surveiller

a) Installation de l’agent

NSClient++ est l’agent de supervision standard Nagios pour les plateformes Windows. Il est
compatible pour toutes versions de Windows qui combine les fonctions de transport NRPE et
NSCA. Nous avons utilisé NSCP qui représente l’évolution de NSClient++. Dans cette section

53
sera illustrée l’installation du Client NSCP sur une machine Windows Server 2003. L’application
a été téléchargée sur le site officiel nsclient.org (NSCP-0.4.4.23 en version msi x32).

Figure 3.09 : Spécification de l’adresse du serveur Nagios.

Figure 3.10: Activation des modules complémentaires.

b) Configuration de Nagios

Il faut modifier le fichier de configuration « /usr/local/nagios/etc/nagios.cfg » en décommentant la

ligne windows.cfg pour pouvoir définir toutes les machines Windows dans un même fichier :

cfg_file=/usr/local/nagios/etc/objects/windows.cfg

c) Définition de l’hôte

If faut ensuite modifier le fichier « usr/local/nagios/etc/objects/windows.cfg » en ajoutant la

définition des hôtes Windows comme suit :

54
 define host {
use windows-server
host_name WIN2003
alias aroDNS
address 10.0.0.7
}

d) Définition des services pour les hôtes Windows

La définition des services se fait dans le même fichier que pour la définition d’hôte.

− Définition du service pour connaître la version de l’agent sur la machine à surveiller :

define service{
use generic-service
host_name WIN2003
service_description NSClient++ Version
check_command check_nt!CLIENTVERSION
}

− Définition du service pour surveiller le temps pendant lequel le serveur est opérationnel :

define service{
use generic-service
host_name WIN2003
service_description NSClient++ Version
check_command check_nt!UPTIME
}

− Définition du service pour surveiller la charge du CPU :

define service{
use generic-service
host_name WIN2003
service_description CPU Load
check_command check_nt!CPULOAD! -l 5,80,90
}

55
Les nombres 5,80 et 90 sont des seuils pour le type de code d’état à envoyer :

• 5 : Si la charge est à 5%, cela correspond au code 0 qui signifie « OK » ;

• 80 : Si la charge est à 80%, cela correspond au code 1 qui signifie « WARNING » ;
• 90 : Si la charge est à 90% cela correspond au code 2 qui signifie « CRITICAL » ;
− Définition du service pour surveiller l’utilisation de la mémoire :

define service{
use generic-service
host_name WIN2003
service_description Memory Usage
check_command check_nt!MEMUSE ! -w 80 -c 90
}

On peut aussi définir les seuils avec les lettres -w pour « WARNING » et -c pour « CRITICAL ».

− Définition du service pour surveiller l’utilisation de l’espace disque :

define service{
use generic-service
host_name WIN2003
service_description Drive Space
check_command check_nt!USEDDISKSPACE ! -l c -w 80 -c 90
}

3.2.4.2 Configuration des machines Linux à surveiller

a) Installation de l’agent

Il faut d’abord installer le daemon NRPE et les plugins Nagios (qui vont être lancés localement
par le daemon NRPE) :

# sudo apt-get install nagios-nrpe-server

# sudo apt-get install nagios-plugins

b) Configuration de Nagios

Il faut aussi installer NRPE sur le serveur Nagios, puis éditer le fichier /etc/nagios/nrpe.cfg pour
modifier la ligne suivante par l’adresse du serveur :

allowed_hosts = 10.0.0.4

56
On automatise le lancement du « daemon » au démarrage du serveur avec la commande :

# chkconfig --add nrpe

On ajoute une règle pour autoriser le Firewall à laisser passer les requêtes NRPE :

# iptables -I RH-Firewall-1-INPUT 10 -p tcp --dport 5666 -j ACCEPT

Il ne reste plus qu’à lancer le « daemon » :

# /etc/init.d/nagios-nrpe-server start

c) Définition de l’hôte

If faut ensuite définir la machine en modifiant le fichier « usr/local/nagios/etc/objects/host.cfg » :

define host {
use linux-server ;
host_name mail-server;
alias mail-server ;
address 10.0.0.5 ;
}

d) Définition des services

− Définition du service ping sur les machines à surveiller :

define service{
use generic-service
host_name mail-server, ftp-server, http-server
service_description PING
check_command check_ping!100.0,20%!500.0,60%
}

Le code d’état du service sera :

• « CRITICAL » si le temps de réponse moyen ou RTA (Response Time Analysis) est plus
élevé que 500 millisecondes ou que le nombre de paquets perdus est égal ou supérieur à
60% ;

57
 • « WARNING » si le RTA est supérieur à 100 ms ou que le nombre de paquets perdus est
égal ou supérieur à 20% ;
• « OK » si le RTA est inférieur à 100 ms et que le nombre de paquets perdus est inférieur à
20%.

− Définition du service pour surveiller le service smtp :

define service{
use generic-service
host_name mail-server
service_description SMTP
check_command check_smtp
}

− Définition du service pour surveiller le service ftp:

define service{
use generic-service
host_name ftp-server
service_description FTP
check_command check_ftp
}

− Définition du service pour surveiller le service http:

define service{
use generic-service
host_name http-server
service_description HTTP
check_command check_http
}

3.2.4.3 Configuration des routeurs

La configuration SNMP des routeurs est présentée dans l’annexe A1.

58
 Figure 3.11: Surveillance des routeurs.

Au niveau du serveur Nagios, il faut modifier le fichier « /usr/local/nagios/etc/nagios.cfg » en

décommentant a ligne suivante :

#cfg_file=/usr/local/nagios/etc/objects/switch.cfg

b) Définition de l’hôte

Cela permet à Nagios de retrouver le fichier de configuration pour les routeurs à définir. Il faut
ensuite modifier le fichier « /usr/local/nagios/etc/objects/switch.cfg » pour ajouter une nouvelle
définition d’hôte pour les routeurs à superviser.

define host {
use generic-switch
host_name R_1
alias Router Central
address 10.0.0.1
}

c) Définitions des services

− Définition du service pour surveiller le service ping:

define service{
use generic-service
host_name R_1,R_2,R_3,R_4,R_5
service_description PING
check_command check_ping!100.0,20%!500.0,60%
}

59
 − Définition du service pour surveiller le service « uptime »:
define service{
use generic-service
host_name R_5
service_description UPTIME
check_command check_snmp! -C nagios -o sysUptime.0 -H 10.0.0.98
}

• -C nagios signifie que « nagios » est le nom de communauté SNMP « nagios » qu’on a
créé (voir annexe A1) ;
• -o sysUpTime.0 indique que l’OID doit être contrôlé.
− Pour s’assurer qu’un port ou interface particulier du routeur est dans un état « UP », on
doit ajouter la définition de service suivante :

define service{
use generic-service
host_name R_5
service_description Port 1 Link Status
check_command check_snmp! -C nagios -o ifOperStatus.1 -H 10.0.0.98 -r 1 -m RFC1213-MIB
}

• -o ifOperStatus.1 fait référence à OID pour l’état opérationnel du port 1 sur le switch ;
• L’option -r 1 indique au plugin check_snmp de retourner un état OK si 1 est trouvé dans la
réponse SNMP (1 indique que le port est up) et CRITICAL sinon ;
• L’option -m RFC1213-MIB est optionnel et indique la MIB à utiliser parmi celles
installées sur votre système et peut aider à accélérer la vérification ;
− Définition du service de supervision de la bande passante avec MRTG :

define service{
use generic-service
host_name R_5
service_description Port 1 Bandwidth Usage
check_command
check_local_mrtgtraf!/var/lib/mrtg/10.0.0.98_1.log!AVG!1000000,2000000!5000000,5000000!10
}

60
Pour superviser l’usage de la bande passante des routeurs en utilisant MRTG, on peut alerter
Nagios quand les valeurs dépassent un seuil spécifié.

On doit faire connaitre l’emplacement du fichier où MRTG stocke ses données, au plugin
check_mrtgtraf ainsi que les seuils. Pour le routeur R_5, le fichier de log de MRTG est stocké
dans /var/lib/mrtg/10.0.0.98_1.log. L’installation de MRTG est décrite en annexe (voir Annexe
A4).

La commande ci-dessus a pour but de superviser les données de bande passante stockées dans ce
fichier :

• l’option /var/lib/mrtg/10.0.0.98_1.log passée à la commande check_local_mrtgtraf indique

au plugin dans quel fichier de log MRTG il doit aller lire ;
• l’option AVG indique qu’il doit utiliser des statistiques basées sur la moyene de la bande
passante. Les arguments 1000000,2000000 sont les seuils de warning (en octets) pour le
taux de trafic entrant ;
• les arguments 5000000,5000000 sont des seuils critiques (en octects) pour le taux de trafic
sortant ;
• l’option 10 indique au plugin de renvoyer un état CRITICAL si le fichier de log MRTG est
plus vieux que 10 minutes (il devrait être mis à jour toutes les 5 minutes).
− Définition du service pour mesurer le débit internet

Pour mesurer le débit internet, un script en python « speedtest-cli.py» permettant d’ effectuer un

« speedtest » par commande en ligne sur les machines linux fut installé. Ce script est utilisé par un
autre script en BASH, servant de plugin à Nagios appelé « check_speedtest-cli.sh ».

Le principe du script en python est d’envoyer des requêtes à des serveurs de « speedtest et de
déterminer les serveurs les plus proches.

Figure 3.12 : Résultat du « speedtest ».

Le résultat du test de la figure 4.12 permet de définir les seuils pour le service.

61
En considérant que ce débit de connexion étant normal, on définit les seuils suivants :

• « WARNING » : débit « download » à 0.7 Mbps, débit « upload » à 0.4 Mbps.

• « CRITICAL » : : débit « download » à 0.5 Mbps, débit « upload » à 0.2 Mbps.

Définition de la commande Nagios :

define command {
command_name check_internet_speed
command_line $USER1$/check_speedtest-cli.sh w $ARG1$ c $ARG2$ -W $ARG3$ -C $ARG4$ -l e
-s $ARG5$ -p
}

Les arguments de la commande sont respectivement : débit seuil pour l’état « WARNING » en
sens descendant, débit seuil pour l’état « CRITICAL», en sens descendant, débit seuil pour l’état «
WARNING » en sens montant, débit seuil pour l’état « CRITICAL » en sens descendant,
identifiant du serveur le plus proche obtenu par le test suivant :

speedtest.py --list

Définition du service pour le routeur R_5 :

define service{
use generic-service
host_name R_5
service_description Internet speed
check_command check_internet_speed!0.7!0.5!0.4!0.2!1672
check_interval 30
retry_interval 5 }

3.2.5 Notification par mail

Les notifications dans Nagios nécessitent l’installation du MTA (Mail Transfert Agent) sur le
serveur Nagios (voir annexe A2).

3.2.5.1 Commandes utilisées pour envoyer les mails ;

Deux commandes sont utilisées pour envoyer les mails de notification : « notify-service-by-
email », pour la notification concernant les services et « notify-host-by-email », pour la

62
notification concernant les hôtes. Leurs définitions se font par modification du fichier
«/usr/local/nagios/etc/objects/commands.cfg ».

define command{
command_name notify-host-by-email
command_line /usr/bin/printf «%b» «[Nagios]\n\nType de notification: $NOTIFICATIONTYPE$\nHôte:
$HOSTNAME$\nEtat: $HOSTSTATE$\nAddresse: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Heure:
$LONGDATETIME$\n» | /usr/bin/mail -s «** $NOTIFICATIONTYPE$ Alerte : $HOSTNAME$ est
$HOSTSTATE$ **» $CONTACTEMAIL$
}
define command{
command_name notify-service-by-email
command_line /usr/bin/printf «%b» «[Nagios]\n\nType de notification:
$NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHôte: $HOSTALIAS$\nAddresse:
$HOSTADDRESS$\nEtat: $SERVICESTATE$\n\nDate/Heure:
$LONGDATETIME$\n\nInformations:\n\n$SERVICEOUTPUT$» | /usr/bin/mail -s «** $NOTIFICATIONTYPE$
Alerte: $HOSTALIAS$/$SERVICEDESC$ est $SERVICESTATE$ **» $CONTACTEMAIL$
}

3.2.5.2 Contacts à notifier ;

La définition des contacts se fait par modification du fichier
« /usr/local/nagios/etc/objects/contacts.cfg ».
define contact{
use generic-contact
contact_name admin1
alias admin1
email n4gios@yandex.com
}

Figure 3.13 : Notification par mail de l’inaccessibilité du routeur 10.3.0.1.

63
3.2.6 Notification par SMS
Si le serveur de mail est éteint, on ne reçoit plus de notification. De ce fait, on se retrouve souvent
à considérer d’autres méthodes de notification afin de garantir une réaction plus rapide en cas de
nécessité. L’une d’entre elles est la notification par SMS.

3.2.6.1 Gateway SMS

La passerelle vers le réseau mobile utilisée pour ce projet est Clockwork SMS Gateway. Il faut
dans un premier temps s’inscrire et obtenir une clé d’API (Application Programming Interface).

3.2.6.2 Définition des commandes

define command{
command_name notify-by-sms
command_line $USER1$/notify_sms.pl -k API_KEY -t $CONTACTPAGER$ -f Nagios -m «Service:
$SERVICEDESC$nHost: $HOSTNAME$nAddress: $HOSTADDRESS$nState: $SERVICESTATE$nInfo:
$SERVICEOUTPUT$nDate: $LONGDATETIME$»
}
define command{
command_name host-notify-by-sms
command_line $USER1$/notify_sms.pl -k API_KEY -t $CONTACTPAGER$ -f Nagios -m «Host
$HOSTNAME$ is $HOSTSTATE$nInfo: $HOSTOUTPUT$nTime: $LONGDATETIME$»
}
3.2.6.3 Définition du contact

Il suffit de modifier le fichier de contact de la notification par SMS en ajoutant la ligne suivante :

pager XXXXXXXXXXX ;

« XXXXXXXXX » désigne le numéro téléphone au format international du contact.

3.2.7 Intégration des outils de graphes

Pnp4Nagios est utilisé avec Nagios pour générer les graphes des services surveillés.

3.2.7.1 Installation et configuration de PNP4Nagios

a) Installation des prérequis

apt-get install rrdtool perl-Time-HiRes rrdtool-perl php-gd

b) Téléchargement et installation

64
 # wget https://sourceforge.net/projects/pnp4nagios/files/PNP-0.6/pnp4nagios-0.6.25.tar.gz
# tar zxfv pnp4nagios-0.6.25.tar.gz
# cd pnp4nagios-0.6.25
#./configure
# make all
#make fullinstall

c) Intégration à Nagios

Il faut modifier le fichier « /usr/local/nagios/etc/nagios.cfg » en ajoutant les lignes suivantes :

process_performance_data=1
service_perfdata_file=/usr/local/pnp4nagios/var/service-perfdata
service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOS
TNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICEC
H$
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=15
service_perfdata_file_processing_command=process-service-perfdata-file
host_perfdata_file=/usr/local/pnp4nagios/var/host-perfdata
host_perfdata_file_template=DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAM
E$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHO
STSTATE::$
host_perfdata_file_mode=a
host_perfdata_file_processing_interval=15
host_perfdata_file_processing_command=process-host-perfdata-file

Ensuite modifier aussi le fichier « /usr/local/nagios/etc/objects/commands.cfg » :

define command {
command_name process-service-perfdata-file
command_line /bin/mv /usr/local/pnp4nagios/var/service-perfdata /usr/local/pnp4nagios/var/spool/service-
perfdata.$TIMET$
}

define command {
command_name process-host-perfdata-file
command_line /bin/mv /usr/local/pnp4nagios/var/host-perfdata /usr/local/pnp4nagios/var/spool/host-
perfdata.$TIMET$
}

65
Modifier le fichier « /usr/local/nagios/etc/objects/templates.cfg » pour créer des nouvelles
« templates »:

define host {
name host-pnp
action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=_HOST_’ class=‘tips’
rel=‘/pnp4nagios/index.php/popup?host=$HOSTNAME$&srv=_HOST_
register 0
}
define service {
name srv-pnp
action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$’ class=‘tips’
rel=‘/pnp4nagios/index.php/popup?host=$HOSTNAME$&srv=$SERVICEDESC$
register 0
}

Afin de pouvoir utilisé l’outil de graphe, il suffit de faire hériter les hôtes créés de « host-pnp » et
les services de « srv-pnp ».

define host{
use linux-server,host-pnp
…
}
define service{
use local-service,srv-pnp
…
}

Figure 3.14 : Réception d’un SMS de notification d’alerte pour le routeur 10.0.0.1.

66
3.2.7.2 Installation et configuration de MRTG
MRTG (Multi Router Traffic Grapher) est un outil utilisé pour la surveillance de la charge du
trafic sur les liens réseaux. MRTG génère des pages HTML contenant des images permettant de
visualiser le trafic réseau en temps réel.

a) Installation

# apt-get install mrtg

b) Configuration

# mkdir -p /var/www/html/mymrtg/
#cfgmaker --global ‘WorkDir: /var/www/html/mymrtg’ --output /etc/mrtg/mymrtg.cfg public@localhost
# indexmaker --output=/var/www/html/mymrtg/index.html /etc/mrtg/mymrtg.cfg
# cp -av /var/www/html/mrtg/*.png /var/www/html/mymrtg/
# mrtg /etc/mrtg/mymrtg.cfg

3.2.8 Interface graphique et tableau de bord

Une nouvelle interface graphique fut intégrée à Nagios pour pouvoir accéder à un tableau de bord
grâce à l’outil Thruk. L’outil Thruk est une interface web centrale pour gérer plusieurs
«bakends »comme Nagios grâce à l’API Livestatus. L’API Livestatus interagit avec Nagios afin
de collecter les données et ensuite les passer à l’interface Thruk.

Figure 3.15: Interface web de Nagios sans l’outil Thruk.

67
3.2.8.1 Tableau de bord
Le tableau de bord affiche une synthèse de l’état des hôtes et services. Chaque hôte et service est
défini par un état :

− Services : OK, WARNING, CRITICAL, UNKNOWN

− Hôtes : UP, DOWN, PENDING,UNRECHABLE

Figure 3.16: Tableau de bord Nagios avec le panorama Thruk.

La figure 3.16 représente le tableau de bord affiché avec l’outil Thruk. De gauche à droite, on
distingue :

− L’état de la machine hébergeant le serveur de supervision : la répartition de la charge du

CPU ainsi que l’utilisation de la mémoire.
− L’état général des hôtes : symbolisé par un disque représentant le pourcentage des hôtes à
l’état « DOWN » signifiant « éteint » en rouge et celui des hôtes à l’état « UP » signifiant
« en fonctionnement » en vert.
− L’état général des services : « OK » signifiant « bon fonctionnement »,
« WANING » signifie que le seuil d’avertissement défini concernant l’ état du service a été
franchi (par exemple une limite sur le nombre de paquets perdus) , « CRITICAL »
signifiant que le seuil critique pour le fonctionnement du service a été dépassé,
« UNKNOWN » signifiant que l’information sur l’état du service n’a pas été retourné.

68
 − Le bilan des temps de réponse des commandes de vérification d’état des hôtes et services.
− Une visualisation plus détaillée de l’état des services par hôtes.

La section « Current status » affiche la synthèse des équipements et des services en affichant leurs
états et leurs nombres.

Figure 3.17: Visualisation des états des équipements et des services associés.

La figure 3.17 représente une visualisation en temps réel de l’état des hôtes et des services grâce à
l’outil Thruk et l’outil Livestatus qui met automatiquement à jour les informations affichées après
chaque vérification. Cette section affiche l’état des services par hôtes ainsi que la date de la
dernière vérification, la durée de fonctionnement des hôtes, le nombre de vérifications effectuées
avant la confirmation de l’état de l’hôte ou du service et enfin les informations sur l’état des
services qui sont les résultats retournés par la commande de vérification. Cette vue permet aussi de
savoir si les notifications sont activées ou non sur chaque hôte ou si l’hôte en question subit
souvent des changements d’états au cours du temps ou « Flapping ».

69
 Figure 3.18: Détails sur l’état d’un hôte.

Il est également possible d’obtenir des détails dur l’état d’un hôte particulier. La figure 3.18
représente les détails sur l’état du routeur R_1 :

L’état actuel de l’hôte : « UP » et le temps de fonctionnement ou « uptime » : depuis 45 min 11s.

Le résultat retourné par la commande PING : les résultats du Ping montrent que tous les paquets
ICMP envoyés ont été reçus : « nombre de paquets perdus 0% ». Ce résultat nous montre que
l’hôte de destination est bien « vivant » au niveau ICMP. Le temps de réponse affecte la
performance des applications réseau. Des temps de réponses élevés vont mener à des
performances faibles. Le RTA informe sur le temps pris par un paquet pour atteindre la destination
et revenir : RTA = 90.84 ms signifie que le réseau n’est pas congestionné.

3.2.8.2 Graphes
Les graphes des services sont générés par l’outil PNP4Nagios.

Figure 3.19: Graphe du service PING pour le routeur central.

70
Le graphe de la figure 3.19 représente le service PING sur le routeur R_1. Il représente les valeurs
du RTA (Round Trip Average) en millisecondes enregistrés au cours du temps (en Mois). La
valeur du RTA est maximale au mois de Décembre 2018, ce qui signifie que la liaison était le plus
faible.

Figure 3.20: Graphe de la bande passante du routeur R_5.

La figure 3.20 illustre la bande passante sur le routeur R_5. La courbe de couleur bleue représente
le débit sortant tandis que la courbe en vert représente le débit entrant sur l’interface reliant au
LAN.

Ce routeur est utilisé pour l’accès internet : ceci justifie le décalage entre le débit d’entré venant du
LAN 76.0 B/s et le débit de sortie venant de l’extérieur 3408.0 B/s.

3.3 Conclusion
Dans ce chapitre ont été présentés les travaux et les résultats pratiques de ce travail de mémoire.
La mise en œuvre de différents outils ont permis l’implémentation d’une solution de surveillance

71
réseau basée sur Nagios. La modularité de cet outil rend les possibilités d’amélioration infinies
pour le monitoring réseau.

72
 CHAPITRE 4
IMPLEMENTATION DE LA METHODE DE CLASSIFICATION DE TRAFIC

4.1 Introduction
Ce chapitre concerne la présentation de la méthode de classification de trafic par machine
Learning pour la détection d’injection de paquets dans les trames TCP. Ce chapitre est divisé en
deux parties : La première concernera l’aspect mathématique de la méthode. La deuxième partie
concernera l’implémentation du modèle pour la classification de trafic par le classificateur Naïve
Bayes par Machine Learning.

4.2 Modèle mathématique

4.2.1 Notions de bases sur les réseaux Bayésiens

4.2.1.1 Théorème de Bayes

Le théorème de Bayes énonce des probabilités conditionnelles : étant donné deux événements A et
B, le théorème de Bayes permet de déterminer la probabilité de A sachant B, si l’on connaît les
probabilités :

− de A ;
− de B ;
− de B sachant A.

Le classificateur Naïve Bayes se base sur le théorème de Bayes. Ce dernier est un classique de la
théorie des probabilités. Ce théorème est une conséquence immédiate des probabilités
conditionnelles et des probabilités totales. La formule générale du théorème peut être retrouvée à
partir de la loi des probabilités conditionnelles. [37]

Soit la loi de probabilité conditionnelle reliant la probabilité de réalisation de l’évènement A

sachant la probabilité de réalisation de l’évènement B :

𝑝(𝐴 ∩ 𝐵) (4.01)
𝑝(𝐴|𝐵) =
𝑝(𝐵)

Or, il est possible de décomposer les membres de la fraction :

− au numérateur :

𝑝(𝐴 ∩ 𝐵) = 𝑝(𝐴). 𝑝(𝐵|𝐴) (4.02)

73
 − au dénominateur:

𝑝(𝐵) = 𝑝(𝐴 ∩ 𝐵) + 𝑝(𝐴∗ ∩ 𝐵) = 𝑝(𝐴). 𝑝(𝐵|𝐴) + 𝑝(𝐴∗ ). 𝑝(𝐵|𝐴∗ ) (4.03)

Où 𝐴∗ est l’événement complémentaire de 𝐴 tel que 𝑝(𝐴∗ ) = 1 − 𝑝(𝐴).

La formule générale du Théorème de Bayes est alors :

𝑝(𝐴). 𝑝(𝐵|𝐴) (4.04)

𝑝(𝐴|𝐵) =
𝑝(𝐴). 𝑝(𝐵|𝐴) + 𝑝(𝐴∗ ). 𝑝(𝐵|𝐴∗ )

Dans la formule générale, le théorème de Bayes a été appliqué avec une seule variable prédictive :
la probabilité de la réalisation de l’évènement A. Dans les applications du théorème de Bayes, on
calcule le résultat en se basant sur plusieurs variables.

Considérons une partition 𝐴1 , 𝐴2 , . . . , 𝐴𝑛 de l’ensemble des événements E.

L’application du théorème de Bayes sur plusieurs variables est :

𝑝(𝐵) = 𝑝(𝐴1 ). 𝑝(𝐵|𝐴1 ) + 𝑝(𝐴2 ). 𝑝(𝐵|𝐴2 ) + ⋯ + 𝑝(𝐴𝑛 ). 𝑝(𝐵|𝐴𝑛 ) (4.05)

Avec :

𝑝(𝐴1 ). 𝑝(𝐵|𝐴1 )
𝑝(𝐴1 |𝐵) =
𝑝(𝐵)

𝑝(𝐴2 ). 𝑝(𝐵|𝐴2 )
𝑝(𝐴2 |𝐵) =
𝑝(𝐵)

𝑝(𝐴𝑛 ). 𝑝(𝐵|𝐴𝑛 )
𝑝(𝐴𝑛 |𝐵) =
𝑝(𝐵)

Les nombres suivants sont appelés « Probabilité à priori de 𝐴𝑘 » :

𝑝(𝐴1 ), 𝑝(𝐴2 ), … , 𝑝(𝐴𝑛 ) (4.06)

Les nombres suivants, appelés « Fonction de vraisemblance de 𝐴𝑘 », expriment des apports

d’informations, c’est-à-dire qu’elle précède toute information sur B :

𝑝(𝐵|𝐴1 ), 𝑝(𝐵|𝐴2 ), … , 𝑝(𝐵|𝐴𝑛 ) (4.07)

74
Les nombres suivants, appelés « Probabilité à postériori de 𝐴𝑘 », expriment comment les
probabilités à priori doivent être adaptées à la sous-population B, c’est-à-dire qu’elles dépendent
directement de B :

𝑝(𝐴1 |𝐵), 𝑝(𝐴2 |𝐵), … , 𝑝(𝐴𝑛 |𝐵) (4.08)

4.2.1.2 Réseau Bayésien

Définition 4.01

Un réseau bayésien ou BN (Bayesian Network) est un GAD (Graphe Acyclique Dirigé), où

chaque nœud n ∈ N représente une variable aléatoire (dans notre cas un attribut dans le dataset), et
chaque arc a ∈ A entre les nœuds reliant ces dernières représente une dépendance probabiliste,
quantifiée en utilisant une distribution de probabilité conditionnelle. [38]

Définition 4.02

Un réseau bayésien est un système représentant la connaissance et permettant de calculer des

probabilités conditionnelles apportant des solutions à différentes sortes de problématiques.

Notons que le graphe est acyclique : il ne contient pas de boucle. Les arcs représentent des
relations entre variables qui sont soit déterministes, soit probabilistes. Ainsi, l’observation d’une
ou plusieurs causes n’entraîne pas systématiquement l’effet ou les effets qui en dépendent, mais
modifie seulement la probabilité de les observer. L’intérêt particulier des réseaux bayésiens est de
tenir compte simultanément de connaissances a priori d’experts (dans le graphe) et de l’expérience
contenue dans les données. [37]

4.2.1.3 Classificateur Naïve Bayes

Soient 𝐴1 , 𝐴2 , . . . , 𝐴𝑛 les causes possibles de la réalisation de B, on peut maintenant établir la
cause la plus probable (éventuellement les causes les plus probables) Ak : c’est celle
où 𝑝(𝐴𝑘 |𝐵) diffère le plus de (𝐴𝑘 ) , ce qui indique que les événements 𝐴𝑘 et B ne sont pas
indépendants. [37]

Généralement, les variables prédictives sont liées entre elles. Pour contourner cela, une approche
consiste à prendre en considération ces variables indépendamment les unes des autres. Il s’agit
donc d’une hypothèse forte. Le terme « naïve » vient du fait qu’on suppose cette indépendance des
variables. [38]

75
Le Naïve Bayes est donc une structure simple dont le nœud représentant la classe à prédire,
représenté par « c », est nœud parent de tous les autres nœuds. Aucune autre connexion n’est
autorisée dans une structure Naïve-Bayes.

4.2.2 Modèle mathématique de la méthode de classification de trafic

Dans cette étude, mise à part l’attribut qui est la classe à prédire, nous avons huit attributs extraits
des données brutes qui sont la longueur de la trame, le port source, le port de destination, la
longueur de l’en-tête TCP, la taille de l’en-tête IP, le type de protocole de communication utilisé,
le numéro de séquence et la taille de la fenêtre.

Considérons que ces huit attributs peuvent être notés :

𝐴𝑥 = {𝐴1 , 𝐴2 , . . . , 𝐴𝑛 }, avec n = 8.

Hypothèse (𝐻1 ) : On suppose que les attributs {𝐴1 , 𝐴2 , . . . , 𝐴𝑛 } sont indépendants entre eux.

Soit un échantillon de données 𝑥 = (𝑥1 , 𝑥2 , … , 𝑥𝑛 ) qui représente l’ensemble de réalisation de 𝑋 =

(𝑋1 , 𝑋2 , … , 𝑋𝑛 ) tel que chaque variable aléatoire 𝑋𝑖 est décrit par 𝑛 attributs {𝐴1 , 𝐴2 , . . . , 𝐴𝑛 } .

𝑋𝑖 = (𝐴1 (𝑖) , . . , 𝐴𝑚 (𝑖) )𝑇 est donc un vecteur aléatoire tel que 𝐴𝑗 (𝑖) représente un attribut comme par
exemple le numéro de séquence dans un flux 𝑖.

Supposons maintenant qu’il existe k classes d’intérêt connues. Dans notre cas, 𝑘 = 2 (trafic
normal et trafic anormal), notons alors 𝐶 = {𝑐1 , 𝑐2 } , l’ensemble des classes connues.

Pour chaque instance 𝑥𝑖 observée de 𝑥, il existe une application connue ∁ ∶ 𝑥 → 𝐶 représentant

l’appartenance de l’instance 𝑥𝑖 à une classe d’intérêt particulière.

Notons 𝑐𝑗 = ∁ (𝑥𝑖 ), signifiant « L’instance 𝑥𝑖 appartient à la classe 𝑐𝑗 ».

Afin de prédire la probabilité d’appartenance de l’instance 𝐴𝑥 à la classe 𝑐𝑗 , la probabilité a

posteriori de Naïve Bayes est donnée par :

𝑝(𝑐𝑗 )𝑓(𝐴𝑥 |𝑐𝑗 ) (4.09)

𝑝(𝑐𝑗 |𝐴𝑥 ) =
∑𝑐𝑗 𝑝(𝑐𝑗 )𝑓(𝐴𝑥 |𝑐𝑗 )

Où 𝑝(𝑐𝑗 ) représente la probabilité d’avoir la classe 𝑐𝑗 indépendamment des données observées

(probabilité à priori), 𝑓(𝐴𝑥 |𝑐𝑗 ) représente la fonction de distribution (ou la probabilité de
𝐴𝑥 sachant 𝑐𝑗 ). Le dénominateur joue le rôle de constante de normalisation.

76
Le but de la classification supervisée par Naïve Bayes est d’estimer 𝑓(𝐴𝑥 |𝑐𝑗 ) étant donné un
ensemble d’entrainement 𝑥. [39]

Pour ce faire, on avance une deuxième hypothèse :

Hypothèse (𝐻2 ) : Les attributs {𝐴1 , 𝐴2 , . . . , 𝐴𝑛 } suivent une loi de distribution Gaussienne
(Normale).

Le problème se réduit alors à estimer les paramètres de la distribution gaussienne et les

probabilités à priori des classes 𝑐𝑛 et 𝑐𝑎 .

La fonction de distribution Gaussienne est décrite par :

1 −(𝑥−𝜇)2
𝑓(𝑥) = 𝑒 2𝜎2 (4.10)
𝜎√2𝜋

Cette expression donne la densité de distribution des valeurs de 𝑥, tel que :

− 𝜎 Représente l’écart-type ;
− 𝜎 2 Représente la variance ;
− 𝜇 Représente la moyenne de la densité de distribution.

Notons 𝑥 = 𝐴𝑥 .

Pour calculer la probabilité à priori, la variance et la moyenne pour les attributs indépendants, sont
calculées à partir de l’ensemble d’entraînement donné.

Sous la forme d’expression mathématique, on écrit :

1 −(−𝜇)2
2)
𝑓𝐴𝑥 |𝑐𝑗 (𝑥; 𝜇, 𝜎 = 𝑒 2𝜎2 (4.11)
𝜎√2𝜋

Les valeurs de 𝜇, 𝜎 2 pour 𝐴𝑥 , qui ne sont pas les valeurs réelles mais les valeurs estimées sont
données par maximum de vraisemblance des résultats des probabilités à priori des événements
calculés dans les données d’entraînement. [23]

𝐴𝑥
𝜇= ∑ (4.12)
𝑛 𝑐𝑗
𝐴𝑥 ~𝑐𝑗

77
Cette expression de la moyenne aide à calculer la probabilité que Aₓ appartienne à la classe 𝑐𝑗
quand une certaine valeur de 𝐴𝑥 est divisée par le nombre total d’occurrences des classes, dans
notre cas il y a 2 classes 𝑐1 et 𝑐2 . Donc, afin de calculer la première moyenne, il suffit de prendre
𝑥 = 1 et 𝑗 = 1. De même, la variance peut être calculée par :

1
𝜎 2 =∑𝐴𝑥 ~𝑐𝑗(𝐴𝑥 − 𝜇)2 𝑛 (4.13)
𝑐𝑗 −1

Maintenant, l’expression finale de la probabilité a posteriori avec la distribution normale ou

gaussienne peut être donnée par :

1
𝑝(𝑐𝑗 ~𝐴𝑥 ) = 𝑓𝐴𝑥 |𝑐𝑗 (𝐴𝑥 , 𝜇, 𝜎 2 ). 𝑝(𝑐𝑗 ). (4.14)
𝑁

Où 𝑁 représente la constante de normalisation.

4.2.3 Calcul des indicateurs de base de la performance du modèle

Il est possible de calculer plusieurs indicateurs résumant la matrice de confusion. Par exemple si
nous souhaitons rendre compte de la qualité de la prédiction sur la classe N, on définit :

− La précision : Proportion d’éléments bien classés pour une classe donnée :

𝑉𝑃 (4.15)
𝑃𝑟é𝑐𝑖𝑠𝑖𝑜𝑛𝑐𝑙𝑎𝑠𝑠𝑒 𝑁 =
𝑉𝑃 + 𝐹𝑃

− Le rappel : Proportion d’éléments bien classés par rapport au nombre d’éléments de la

classe à prédire :
𝑉𝑃
𝑅𝑎𝑝𝑝𝑒𝑙𝑐𝑙𝑎𝑠𝑠𝑒 𝑁 = (4.16)
𝑉𝑃 + 𝐹𝑁
− F-mesure. Mesure de compromis entre précision et rappel :
2 ∗ 𝑃𝑟é𝑐𝑖𝑠𝑖𝑜𝑛 ∗ 𝑅𝑎𝑝𝑝𝑒𝑙
𝐹 − 𝑚𝑒𝑠𝑢𝑟𝑒𝑐𝑙𝑎𝑠𝑠𝑒 𝑁 = (4.17)
𝑃𝑟é𝑐𝑖𝑠𝑖𝑜𝑛 + 𝑅𝑎𝑝𝑝𝑒𝑙

Il est possible de calculer tous ces indicateurs pour chaque classe. La moyenne sur chaque classe
de ces indicateurs donne des indicateurs globaux sur la qualité du classifieur. [39]

1 𝑘 𝑉𝑃𝑖
𝑃𝑟é𝑐𝑖𝑠𝑖𝑜𝑛 = ∑ (4.18)
𝑘 𝑖=1 𝑉𝑃𝑖 + 𝐹𝑃𝑖

78
 1 𝑘 𝑉𝑃𝑖
𝑅𝑎𝑝𝑝𝑒𝑙 = ∑ (4.19)
𝑘 𝑖=1 𝑉𝑃𝑖 + 𝐹𝑁𝑖

2 ∗ 𝑃𝑟é𝑐𝑖𝑠𝑖𝑜𝑛 ∗ 𝑅𝑎𝑝𝑝𝑒𝑙 (4.20)

𝐹 − 𝑚𝑒𝑠𝑢𝑟𝑒 =
𝑃𝑟é𝑐𝑖𝑠𝑖𝑜𝑛 + 𝑅𝑎𝑝𝑝𝑒𝑙

4.3 Diagramme de la méthode

Collecte de trafic
sain

•Capture de •Extraction des Conversion de

paquet sain sur attributs sur format
WIRESHARK TSHARK
•Conversion .csv •Conversion .csv •Ajout de la classe
en .arff sur WEKA •Etiquettage
•Collecte de
Extraction
fichiers PCAP
contenant des
injections
Prétraitement

Collecte de
datasets infectés

Génération du
modèle •Application de
l’algorithme
•Exportation Naïve Bayes
•Sauvegarde
Entrainement
des données

•Prédiction de la
classe :
normal/anormale
Evaluation du •Limites
modèle •Recherche
Test du
d’amélioration
modèle •Evaluation des
résultats
•Metriques de
performance Discussion
•Détection d’
injections avec
•Conversion de l’outil Findject
format
•Ajout de la classe
à prédire FINDJECT.py
Prétraitement
du fichier test

Figure 4.01: Diagramme du processus de classification de trafic.

79
4.3.1 Collecte de données brutes

4.3.1.1 Capture du trafic sain

La capture du trafic sain a été effectuée par le logiciel Wireshark dans un réseau réel protégé par
un Firewall ainsi que le logiciel antivirus Kaspersky correctement mis à jour. De plus, les trames
capturées ont été testées avec l’outil findject et ont retournés des résultats négatifs à la détection
d’injection de paquets.

On suppose alors que le trafic capturé soit sain. Un filtre a été placé pour différencier le flux TCP
des autres flux du réseau. Les données sont ensuite sauvegardées et stockées avec le format
« .pcap » en étant pré-étiquetées « normal » avant d’être utilisées pour l’entrainement du modèle.

Figure 4.02: Visualisation du trafic sain sur Wireshark.

4.3.1.2 Collecte des trames infectées

Pour améliorer la précision du modèle, plusieurs fichiers de capture ont été téléchargés,
rassemblés et combinés en un seul fichier, puis pré-étiquetés « anormal » pour entrainer le modèle.

Voici la liste de ces fichiers :

− fichiers PCAP des travaux de recherche de Gabi Nakibly intitulé : “Website-Targeted

False Content Injection by Network Operators”:

http://www.cs.technion.ac.il/~gnakibly/TCPInjections/samples.zip

− l’injection de paquets utilisé sur le site id1.cn, publiée par Fox-IT à BroCon en 2015 :

80
https://github.com/fox-it/quantuminsert/blob/master/presentations/brocon2015/pcaps/id1.cn-
inject.pcap

− l’injection de paquets contre le site www.02995.com, provoquant une redirection vers le

site www.hao123.com:

https://www.netresec.com/files/hao123-com_packet-injection.pcap

− l’injection de paquet utilisé sur le site id1.cn, provoquant une redirection vers le site
batit.aliyun.com :

https://www.netresec.com/files/id1-cn_packet-injection.pcap

− les travaux de recherche effectués par Bill Marczak, Chercheur post-doctoral à l’université
de Californie à Berkeley :

https://github.com/citizenlab/badtraffic/tree/master/pcap

4.3.1.3 Collecte des données de test

Les trames utilisées pour la phase de test du modèle sont les trames TCP utilisés pour le test de
pénétration sur l’outil d’analyse de trame TCP Honeybadger concernant l’injection de paquets
TCP.

https://github.com/david415/honeybadger-pcap-files

4.3.2 Sélection et extraction des attributs

La sélection des attributs à extraire a déjà été expliquée dans le paragraphe 2.3.4.2 du chapitre 2
concernant le prétraitement des données. Pour effectuer l’extraction, l’utilitaire de ligne de
commande Tshark de Wireshark a été utilisé. Il est aussi possible d’effectuer cette étape en
utilisant l’interface graphique de Wireshark mais le processus est plus rapide avec Tshark.

tshark -r tcp.pcap -T fields -e frame.len -e tcp.dstport -e ip.hdr_len -e tcp.srcport -e tcp.seq -e

tcp.hdr_len -e tcp.window_size -e ip.proto -E header=y -E separator=, -E quote=d -E
occurrence=f > tcp.csv

Cette commande appelle la fonction tshark qui va lire «-r» le fichier «tcp.pcap», «-T» en tant que
fichier texte avec «-e» champs mentionnés qui représentent les attributs. «-E» est l’option

81
d’affichage des données. Cette commande va donc extraire les attributs de la donnée brute et
convertir ces données en « .csv ».

Figure 4.03 : Fichier au format « .csv » contenant les attributs filtrés.

Remarque : Les fichiers téléchargés au format «.pcap » ont été fusionnés en un seul fichier avant
d’être filtrés (extraction des attributs) puis convertis au format « .csv ».

4.3.3 Prétraitement des données

4.3.3.1 Présentation de l’environnement d’apprentissage automatique WEKA

WEKA (Waikato Environment for Knowledge Analysis), est une suite de logiciels
d’apprentissage automatique écrite en Java et développée à l’université de Waikato en Nouvelle-
Zélande. WEKA est un logiciel libre disponible sous la licence publique générale GNU GPL
(General Public License). [39] Les algorithmes peuvent être appliqués directement à un ensemble
de données ou appelés à partir d’un code Java. WEKA contient des outils pour le pré-traitement
des données, la classification, la régression, le clustering, les règles d’association et la
visualisation. WEKA peut également bien s’adapter au développement de nouveaux schémas
d’apprentissage par machine.

WEKA propose cinq types d’interfaces selon l’utilisation voulu :

− « Explorer »: Analyse et exploration de données (« data mining ») ;

− « Experimenter » : Conception d’expériences avec une sélection d’algorithmes et de jeux
de données, d’exécuter des expériences et d’analyser les résultats ;
− « Knowledge Flow »: Conception graphique d’un processus ML ;

82
 − «Workbench» : Tester toutes les fonctionnalités de WEKA ;
− « Simple CLI » : Pour passer des commandes JAVA en ligne de commande.

Les principaux points forts de WEKA sont :

− WEKA est libre et gratuit ;

− Il est portable car il est entièrement implémenté en Java et donc fonctionne sur quasiment
toutes les plateformes modernes, et en particulier sur quasiment tous les systèmes
d’exploitation actuels ;
− Il contient une collection complète de prétraitement de données et de techniques de
modélisation. [40]

La version de WEKA utilisée pour ce projet est la version 3.8.2.

Figure 4.04: Sélecteur d’interface graphique de WEKA.

4.3.3.2 Conversion en ARFF

Un fichier ARFF (Attribute-Relation File Format) est un fichier texte ASCII (American Standard
Code for Information Interchange) qui décrit une liste d’instances partageant un ensemble
d’attributs. Les fichiers ARFF ont été développés par le département d’informatique de
l’université de Waikato pour être utilisés avec le logiciel d’apprentissage automatique WEKA.
[41]

83
Le fichier .csv obtenu après l’extraction des attributs doit donc être converti au format ARFF pour
pouvoir être utilisé dans l’environnement WEKA. La conversion est effectuée sur WEKA en
ouvrant le fichier .csv puis en l’enregistrant au format «. arff ».

Figure 4.05: Conversion du fichier en ARFF.

4.3.3.3 Structure d’un fichier ARFF

@relation “trame tcp”

@attribute frame.len numeric

@attribute tcp.dstport numeric
@attribute ip.hdr_len numeric
@attribute tcp.srcport numeric
@attribute tcp.seq numeric
@attribute tcp.hdr_len numeric
@attribute tcp.window_size numeric
@attribute ip.proto numeric

@data
66,80,10.0.2.201,197.149.58.241,20,49546,0,32,8192,6
66,49546,197.149.58.241,10.0.2.201,20,80,0,32,65228,6
54,80,10.0.2.201,197.149.58.241,20,49546,1,20,65536,6
190,80,10.0.2.201,197.149.58.241,20,49546,1,20,65536,6
60,49546,197.149.58.241,10.0.2.201,20,80,1,20,65536,6
…
Figure 4.06: Structure d’un fichier ARFF.

La figure 4.06 représente un fichier au format « .arff ». Un fichier ARFF est composé de deux
parties principales : l’en-tête et le corps.

− @relation représente le type de données traité ; dans notre cas, il s’agit de trames TCP ;
− @attribute décrit les attributs extraits des données brutes pour la classification ;
− @data représente la partie de données du fichier ARFF.

84
WEKA peut prendre en entrée des données sous différentes formes : des valeurs numériques ou
des valeurs nominales.

4.3.3.4 Etiquetage des données

a) Création de l’attribut « class »

Le dernier attribut d’un fichier ARFF doit représenter la classe qui détermine si la trame est
« normale » ou « anormale ». L’en-tête doit contenir un attribut de classe. Il faut donc modifier le
fichier précédent pour qu’il soit explorable par l’environnement WEKA. On a en tout jusqu’ici 3
fichiers de capture au format « .csv » :

− le fichier contenant les trames saines ;

− le fichier contenant les trames infectées ;
− le fichier test.

On doit créer l’attribut « class « qui prendra les valeurs « normal » et « anomaly ». Pour créer une
classe, on a modifié les fichiers .arff en se référant sur la documentation officielle du format
ARFF.

@relation “trame tcp”

@attribute frame.len numeric

@attribute tcp.dstport numeric

@attribute ip.hdr_len numeric

@attribute tcp.srcport numeric

@attribute tcp.seq numeric

@attribute tcp.hdr_len numeric

@attribute tcp.window_size numeric

@attribute ip.proto numeric

@attribute class {normal,anomaly}

Figure 4.07: Création de l’attribut « class ».

On procède ensuite à l’étiquetage en éditant le fichier sur Notepad et en ajoutant une colonne à la
partie données contenant la valeur « normal » pour le trafic sain, « anomaly » pour le trafic infecté
et « ? » pour le trafic test.

85
 Figure 4.08: Fichier ARFF du trafic « normal » (à gauche) du trafic « anormal « (à droite).

Figure 4.09: Fichier ARFF d’un trafic test.

4.3.4 Entrainement de l’algorithme de classification

Les deux premiers fichiers (trames saines et trames infectées) ont été fusionnés en un seul fichier
ARFF. Après le prétraitement des données, un seul fichier a donc été utilisé pour construire le
modèle de classification. Les étapes suivies sont :

− ouvrir le sélecteur d’interface graphique ;

86
 − cliquer sur le bouton « Explorer » pour ouvrir l’explorateur ;
− charger les données d’entrainement à partir du fichier ARFF ;
− cliquer sur « Classifier » pour ouvrir l’onglet Classifier ;
− choisir le classifier Naïve bayes dans le groupe « Bayes ».

Il y existe trois moyens pour entrainer le modèle :

− en utilisant tout l’ensemble de données : on peut fournir un ensemble de données

d’entrainement séparé qui construira un modèle entraîné ;
− en faisant une validation croisée ou « cross-validation » avec « n-folds » : où « n » est le
nombre d’itérations utilisées pour former le classifieur. Par défaut, la valeur de « n » est 10
cela signifie que WEKA divisera les données d’entraînement en 10 parties égales et
utilisera 9/10 pour la formation et 1/10 pour les tests, le processus se répète 10 fois jusqu’à
ce que tout l’ensemble d’entraînement ait été utilisé pour former et tester le classifieur ;
− en faisant une division en pourcentage ou « percentage split » : la valeur spécifiée va
diviser les données en conséquence : si la valeur en pourcentage sélectionnée est 66%
WEKA utilisera 66% des données pour l’entraînement du classifieur et 34% pour tester la
performance du modèle formé. [41]

4.3.5 Génération du modèle

Le modèle créé a ensuite été enregistré et sauvegardé pour tester d’autres ensembles de données.

Choix de l’algorithme

Choix de la méthode d’entrainement du modèle

Modèle généré

Résultats

Figure 4.10: Génération du modèle.

87
Le modèle créé s’affiche ensuite sur la partie gauche de la fenêtre. La partie gauche de la fenêtre
affiche les résultats c’est-à-dire les caractéristiques et métriques de performances pour l’évaluation
du modèle.

4.3.6 Test du modèle

Un test de prédiction peut maintenant être effectué sur le modèle.

4.3.6.1 Trames à tester

Les trames à tester sont présentés dans un fichier au format ARFF.

Figure 4.11: Trames à tester .

4.3.6.2 Test sur WEKA

Pour tester un ensemble de données sur WEKA, il faut :

− charger le modèle ;
− cliquer sur « Supplied Test Set » et choisir le fichier ;
− choisir les options à afficher en choisissant d’afficher les résultats de prédiction au format
« Plain Text ».

88
 Figure 4.12: Choix des options à afficher.

Figure 4.13: Chargement du fichier test.

Pour lancer le test il faut faire un clic droit sur le modèle créé et choisir « Reevaluate model on
current test set ».

Des tests ont été effectués sur quatre fichiers test particuliers du « dataset » de test pour l’outil
Honeybadger qui sont :

− linkedin_FIN;

89
 − slopy_spray_injection1 ;
− handshake_lost_hijack_netcat_loopback1;
− mots-with-fin_no_3whs.

4.3.6.3 Résultats des prédictions

On observe alors que le modèle a prédit la classe de l’instance numéro 5, en « anomaly » pour le
fichier linkedin_FIN.arff.

Figure 4.14 : Résultats du test du modèle sur linkedin_FIN.arff.

Figure 4.15 : Résultat du test sur slopy_spray_injection1.arff.

90
 Figure 4.16 : Résultat du test sur mots-with-fin_no_3whs.arff.

4.3.7 Comparaison des résultats avec les résultats obtenus par l’outil « Findject »

4.3.7.1 Présentation de l’outil FINDJECT

« Findject.py » est un script python qui permet de trouver des paquets TCP injectés dans les
sessions http, qui lit les fichiers PCAP pour trouver des paquets TCP avec des numéros de
séquence dupliqués mais avec un contenu différent. Findject est un logiciel open source créé par
Erik Hjelmvik, fondateur de la société Netresec, un éditeur de logiciels indépendant spécialisé
dans le domaine de la sécurité réseau en 2016. Il est publié sous la licence publique générale GNU
version 2. [42]

4.3.7.2 Test avec l’outil FINDJECT

python findject.py linkedin_FIN.pcap

Figure 4.17 : Résultats du test linkedin_FIN.pcap avec l’outil FINDJECT.

91
Dans l’exemple de la figure 4.17 on peut voir que findject.py a détecté un paquet TCP injecté dans
le fichier linkedin_FIN.pcap. Les identifiants du paquet sont indiqués par la ligne :

5- tuple: 91.225.248.129:80-10.0.1.4:54015

Figure 4.18 : Résultats du test slopy_spray_injection1.pcap avec l’outil FINDJECT.

4.3.7.3 Comparaison des résultats

Le tableau 4.01 résume les résultats obtenus par les quatre fichiers test et les compare avec ceux
de l’outil FINDJECT.

Fichiers Outils Résultats

linkedin_FIN Classifieur Naïve Bayes anomaly
Findject.py anomaly
slopy_spray_injection1 Classifieur Naïve Bayes normal
Findject.py normal
handshake_lost_hijack_netcat_loopback1 Classifieur Naïve Bayes normal
Findject.py normal
mots-with-fin_no_3whs Classifieur Naïve Bayes normal
Findject.py anomaly
Tableau 4.01: Comparaison des résultats avec l’outil Findject.

4.3.8 Interprétation des résultats et évaluation de la performance du modèle

4.3.8.1 Evaluation du modèle par les résultats pratiques

Les résultats pratiques montrent que le modèle arrive à détecter 3 fichiers sur 4 sur les « dataset »
fournis pour tester l’outil Honeybadger comparé à l’outil Findject.py. Ce qui confirme que le
modèle n’est pas parfait.

92
4.3.8.2 Evaluation du modèle à partir des métriques calculées par WEKA

Figure 4.19: Evaluation du modèle à partir des données d’entrainement.

La figure 4.19 montre que la précision du modèle est de 96.7971%.

Figure 4.20 : Métriques de performance du modèle pour chaque classe.

La figure 4.20 indique la précision, le rappel, le F-mesure pour chaque classe (calculés par les
équations 4.18 ; 4.19 ; 4.20). La matrice confusion qui résume ces métriques est :

Figure 4.21: Matrice de confusion du modèle.

La valeur de « aa » de la matrice (la première rangée première colonne) donne le nombre

d’instances correctement classifiées appartenant à la classe normale, de même « bb » donne le
nombre d’instances correctement classées appartenant à la classe anormale.

93
4.3.9 Discussion et amélioration du modèle

4.3.9.1 Discussion
La performance de ce modèle peut être augmentée en utilisant l’estimation Kernel avec le
classifieur Naïve Bayes. La principale différence entre le Naïve Bayes et le Naïve Bayes avec
estimation Kernel est que la distribution normale utilisée par Naïve Bayes correspond à la
distribution gaussienne sur l’ensemble des données, tandis que l’estimation Kernel estime la
distribution gaussienne pour chaque attribut. Sur WEKA on peut modifier le classifieur et
appliquer l’estimation Kernel.

Figure 4.22: Modification du classifieur avec l’estimateur Kernel.

4.3.9.2 Amélioration

Figure 4.23: Evaluation du modèle après modification du classifieur.

94
La figure 4.23 montre que le modèle a atteint 99% de précision avec l’estimation kernel mais
WEKA a mis plus de temps pour l’entrainement du modèle.

Figure 4.24: Matrice de confusion du modèle amélioré.

La matrice de confusion montre que le nombre d’instances correctement classées appartenant à la

classe anormale a augmenté ce qui signifie que la capacité de détection des injections du modèle a
augmenté.

4.4 Conclusion
Les erreurs des classifieurs sont inévitables puisqu’aucun modèle n’est parfait en pratique. La
méthode de classification de trafic pour détecter les injections de paquets dans les trames TCP par
Machine Learning en utilisant l’algorithme Naïve Bayes a été améliorée par l’ utilisation de
l’estimateur Kernel mais pourrait l’être d’avantage en utilisant plus de données pour
l’apprentissage du modèle et en utilisant d’autres algorithmes de classification plus compliqués
comme les réseaux de neurones.

95
 CONCLUSION GENERALE

Pour conclure, la supervision réseau permet d’avoir une visibilité sur l’environnement WAN
fournissant des données cruciales pour la configuration et les décisions de déploiement. Lorsque
des problèmes surviennent, cette visibilité permet à l’équipe informatique de déterminer d’où
vient le problème que ce soit de la liaison WAN ou des équipements, de l’identifier, de l’isoler et
de le résoudre rapidement afin de restaurer les opérations commerciales.

L’objectif principal de ce mémoire est de mettre en œuvre un système de surveillance de réseau

d’entreprise, qui assurerait la disponibilité des équipements et services réseau du réseau de la
société d’Assurance Réassurance Omni-branche (ARO), dans le cadre d’un stage que j’ai effectué
à l’agence siège sise à Antsahavola.

Nagios fournit un aperçu essentiel de la performance et de la disponibilité du réseau, et répond à

toutes les exigences d’un système de supervision tout en étant un outil libre et gratuit. Cependant
sa configuration et son installation s’avère être une tâche plus ou moins fastidieuse puisqu’ il
requière plusieurs des lignes de configurations sans compter les erreurs fréquentes à corriger afin
de l’adapter au système d’exploitation hôte. En effet, de nos jours plusieurs solutions basées sur ce
core comme EyesOfNetwork ou Shinken sont disponibles fournissant une interface graphique plus
facile à utiliser et ne nécessitant pas de passer en ligne de commande. Cependant, travailler sur
Nagios est plus enrichissant en termes d’expériences vue que le projet permet d’avoir une
connaissance plus approfondie du système.

D’autre part, la classification du trafic normal et anormal n’est pas facile dans le monde moderne
d’Internet. Les techniques de détection d’intrusion ont des limites qui sont exploitées par les
hackers. Afin de répondre aux intérêts de sécurité de base sur le trafic Internet, ces questions
devraient être traitées avec de sérieux efforts. Le domaine de l’apprentissage automatique a
montré des résultats prometteurs qui peuvent être utilisés pour lutter contre la cybercriminalité.
L’étude effectuée dans ce travail de mémoire a pour but d’exploiter les aspects de l’apprentissage
automatique, qui peuvent être utilisés pour étudier la plupart des attaques sophistiquées sur
internet. Dans cette étude, il a été montré comment l’algorithme de Machine Learning Naïve bayes
peut être utilisé pour procéder à une classification du trafic TCP. Il existe cependant des
algorithmes plus complexes tels que les SVM, les arbres de décision et les réseaux de neurones
pouvant être utilisés dans ce domaine.

96
 ANNEXE A1
INSTALLATION ET CONFIGURATION DES ROUTEURS

A1.1 Présentation

Le routeur MikroTik RouterOS est un système d’exploitation indépendant basé sur Linux pour les
routeurs et les thinrouters basés sur PC.

A1.2 Installation et intégration à GNS3

A1.2.1 Choix du système d’exploitation

Afin de pouvoir utiliser les routeurs Mikrotik dans un laboratoire de simulation GNS3, il faut dans
un premier temps télécharger le système d’exploitation sur le site de Mikrotik :

https://mikrotik.com/download

Mikrotik propose plusieurs systèmes d’exploitation pour routeurs sur son site officiel. Le système
d’exploitation idéal pour un environnement virtuel est le CHR (Cloud Hosted Router).

Le CHR est une version de RouterOS destinée à être exécutée en tant que machine virtuelle. Il
prend en charge l’architecture x86 64 bits et peut être utilisé sur la plupart des hyperviseurs
populaires tels que VMWare, VirtualBox, Quemu et autres. Il a toutes les fonctionnalités des
RouterOS pour routeur réels. Il peut être surveillé par SNMP. Pour Quemu, il faut choisir la
version « Raw Disk Image ».

A1.2.2 Intégration à GNS3

GNS3 utilisera Quemu pour émuler le système. Il faut donc importer le système d’exploitation en
ajoutant une nouvelle machine virtuelle Quemu.

Figure A1.01: Création d’une nouvelle machine virtuelle Quemu pour émuler le routeur.

97
 Figure A1.02 : Importation de l’image du routeur.

A1.3 Configuration des adresses IPv4

Les interfaces Ethernet présentes sur un routeur Mikrotik sont identifiées par ether1, ether2, ...

On donne une adresse IP à une interface au moyen de la commande /ip address add :

> ip address add address=10.0.0.98/24 interface=ether1

La majorité des éléments placés en réseau dans la topologie sont notamment des serveurs ainsi ils
doivent absolument avoir une adresse IP fixe. La configuration des adresses IPv4 seront donc
statique. Le plan d’adressage est présenté dans le tableau A1.01.

98
Equipement OS Interfaces et Adresses IPv4
localisation
Routeur Central MikrotikOS-CHR Ether1 liaison WAN 154.126.101.2/24
Mikrotik1 Ether2 réseau local 10.0.0.1/24
Routeur Distant MikrotikOS-CHR Ether1 liaison WAN 154.126.102.2/24
Mikrotik2 Ether2 réseau local 10.1.0.1/24
Routeur Central MikrotikOS-CHR Ether1 liaison WAN 154.126.103.2/24
Mikrotik3 Ether2 réseau local 10.2.0.1/24
Routeur Central MikrotikOS-CHR Ether1 liaison WAN 154.126.104.2/24
Mikrotik4 Ether2 réseau local 10.3.0.1/24
Routeur Internet MikrotikOS-CHR Ether1 liaison Internet DHCP
Mikrotik5 Ether2 réseau local 10.0.0.98/24
Emulateur de lien Linux Knoppix Vers siège 154.126.101.3/24
WANem Vers site distant 1 154.126.102.3/24
Vers site distant 2 154.126.103.3/24
Vers site distant 3 154.126.104.3/24
Nagios Linux Ubuntu 16.06 LTS enp0s3 réseau local 10.0.0.4/24
Serveur Mail Linux Ubuntu 16.06 LTS enp0s3 réseau local 10.0.0.4/24
Multiserveur - Réseau local 10.0.0.6/24
Paessler
Serveur windows Windows Server 2012 Réseau local 10.0.0.7/24
Serveur Linux Linux Ubuntu 16.06 LTS Réseau local 10.0.0.5/24
Serveur distant Windows Server 2012 Lien WAN 10.1.0.4/24
Clients Virtual PC Réseau local Siège 10.0.0.8/24
Imprimante 10.0.0.10/24
Virtual PC Réseau distant 1 10.1.0.4/24
Imprimante 10.1.0.10/24
Virtual PC Réseau distant 2 10.2.0.4/24
Imprimante 10.2.0.10/24
Virtual PC Réseau distant 3 10.3.0.4/24

99
 Imprimante 10.3.0.10/24
Tableau A1.01 : Plan d’adressage pour la simulation du réseau.

A1.4 Configuration du routage OSPF

Une fois le système importé sur GNS3, il existe deux façons our configurer un routeur Mikrotik,
en utilisant une interface graphique appelée Winbox, ou en ligne de commande. L’installation de
Winbox est disponible sur le site de Mikrotik et peut être utilisé sur GNS3.

> routing ospf network add area = backbone network=10.0.0.0/24

Sur chaque routeur, on active OSPF et lui indiquant l’adresse (préfixe) du réseau :

Les routes qui font partie de ce réseau seront prises en charge par OSPF et distribuées sur
l’ensemble des routeurs configurés. Après quelque secondes, les informations de routage ont été
échangées entre les routeurs, et chacun dispose de routes vers chaque sous-réseau connecté à
chaque routeur du réseau. Les routes échangées et reçues par OSPF sont affichées par la
commande suivante:

> routing ospf route print

A1.5 Configuration SNMP

Sur les plateformes MikroTik, il n’est pas possible de supprimer ou de désactiver la communauté
«public» par défaut, mais elle peut être renommée et restreinte :

> snmp community set 0 name=nagios read-access=no write-access=no

Pour la simulation, ne nouvelle communauté SNMP a été définie avec les attributs suivants:

− Nom non défini par défaut ;

− Accès en lecture seule ;

100
 − Authentification sécurisée ;
− Chiffrement.

> snmp community add name=nagios read-access=yes write-access=no authentication-protocol=SHA1

authentication-password=xxxxx encryption-protocol=AES encryption-password=xxxxx security=private

Une seule commande est nécessaire pour activer SNMP :

> snmp set enabled=yes

101
 ANNEXE A2
INSTALLATION ET CONFIGURATION DU SERVEUR MAIL

A2.1 Architecture

Le courrier électronique est basé sur l’utilisation de boîtes aux lettres électroniques. Lorsqu’un
message électronique est envoyé, le message est acheminé de serveur en serveur, jusqu’au serveur
de messagerie du destinataire. Plus précisément, le message est envoyé au serveur de messagerie
chargé du transport des courriers électroniques appelé (MTA Mail Transfer Agent) vers le MTA
du destinataire. Sur Internet, les MTA communiquent entre eux en utilisant le protocole SMTP
(Simple Mail Transfer Protocol), et sont donc logiquement appelés serveurs SMTP.

Le MTA du destinataire remet ensuite l’e-mail au serveur de courrier entrant appelé MDA (Mail
Delivery Agent), qui stocke le courrier électronique en attendant que l’utilisateur l’accepte. Il y a
deux protocoles principaux utilisés pour récupérer l’email sur un MDA:

− POP3, le plus ancien des deux, qui est utilisé pour récupérer des emails et, dans certains
cas, en laisser une copie sur le serveur.
− IMAP, qui est utilisé pour coordonner le statut des emails (lus, supprimés, déplacés) sur
plusieurs clients de messagerie. Avec IMAP, une copie de chaque message est enregistrée
sur le serveur, de sorte que cette tâche de synchronisation peut être terminée.
MDA : Gmail

MTA : Postfix

MUA : Nagios Compte Mail de l’administrateur

Figure A2.01: Architecture pour l’envoi de notification mail.

Pour cette raison, les serveurs de messagerie entrants sont appelés serveurs POP ou serveurs
IMAP, selon le protocole utilisé.

Un MTA a été configuré pour qu’il relaie les messages sortants via Gmail pour bénéficier ainsi de
la fiabilité et de la robustesse de l’infrastructure de Gmail et pour disposer d’un moyen d’envoyer

102
des e-mails à partir de la ligne de commande pour les notifications Nagios. Dans ce projet, Postfix
est utilisé comme MTA.

La figure A2.01 représente l’architecture utilisée pour l’envoi des notifications Nagios :

− MUA : Mail User Agent ou client mail ; Nagios est ici utilisé comme MUA envoyant des
notifications d’alerte par ligne de commande.
− MTA : Mail Transfer Agent ; Postfix est configuré comme MTA.
− MDA : Mail Delivery agent ; Les mail sont relayés aux MDA se Gmail.

A2.2 Installation

Postfix est un MTA gratuit, open-source, activement maintenu et hautement sécurisé. Quelques
paquets doivent être installés avant l’installation :

− postfix : serveur pour envoyer du courrier ;

− mailutils : comme son nom l’indique, outils pour utiliser le courrier ;
− llibsasl2-2 ca-certificates et libsasl2-modules : pour SSL et les certificats SSL.

sudo apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules

La fenêtre de démarrage de l’installation s’affiche et il faut compléter les options de configuration

avec les informations :

− Options pour le serveur : « Site Internet »

− Relai SMTP: [smtp.gmail.com] :587

A2.3 Configuration

Postfix devra être configuré pour permettre l’authentification SASL (Simple Authentication and
Security Layer) au serveur Gmail via le compte utilisateur : « atomicnagios@gmail.com ». Il faut
modifier le fichier « /etc/postfix/main.cf » en rajoutant les lignes suivantes :

smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous

103
Les informations d’identification Gmail doivent être ajoutées pour l’authentification.

Il faut créer un fichier « /etc/postfix/sasl/sasl_passwd » et ajoutez la ligne suivante:

[smtp.gmail.com]:587 atomicnagios@gmail.com :xxxxxxxxxxxxx

Une table de recherche ou « lookup table » Postfix doit être générée à partir du fichier texte
sasl_passwd en exécutant la commande suivante :

postmap /etc/postfix/sasl/sasl_passwd

Ces tables sont utilisées par le MTA pour stocker et rechercher des informations pour le contrôle
d’accès, la réécriture d’adresses et même pour le filtrage de contenu.

Pour des raisons de sécurité, il est conseillé de restreindre l’accès en lecture et en écriture aux
fichiers sasl_passwd :

chown -R root:postfix /etc/postfix/sasl

chmod 750 /etc/postfix/sasl
chmod 640 /etc/postfix/sasl/sasl_passwd*

Puis il faut valider les certificats SSL :

cat /etc/ssl/certs/thawte_Primary_Root_CA.pem | sudo tee -a /etc/postfix/cacert.pem

Enfin, à chaque configuration de postfix, il faut recharger le service pour que les modifications
prennent effet :

sudo /etc/init.d/postfix reload

104
 Figure A2.02: Modification du fichier de configuration Postfix.

A2.4 Test d’envoi de message en ligne de commande

echo «Test mail from postfix» | mail -s «Test Postfix» n4gios@yandex.com

Figure A2.03 : Réception du mail dans la boîte de messagerie.

Une commande similaire est intégrée dans une commande Nagios pour l’envoi de notifications
d’alertes.

/usr/bin/mail -s «** $NOTIFICATIONTYPE$ $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **»

$CONTACTEMAIL$

Figure A2.04 : Réception d’alertes Nagios par mail.

105
 ANNEXE A3
DETAILS D’INSTALLATION DE WANEM

A3.1 Configuration de la machine virtuelle

WANem est basé sur une distribution dérivée de Debian appelé Knoppix. Il s’utilise généralement
en CD (Compact Disc) bootable. Dans ce mode d’utilisation, les configurations seront effacées
après chaque redémarrage d’où l’intérêt de choisir l’installation sur un disque dur. Voici les
caractéristiques de la machine virtuelle sur laquelle on installera le système d’exploitation de
WANnem :

− Type: Linux;
− Version: Debian (64-bit);
− Capacité: 4GB;
− RAM: 384MB;
− CPU: 1;

Ensuite ajouter 4 interfaces configurés en mode « réseau privé de l’hôte » pour permettre la
possibilité de communication avec les autres machines virtuelles sur l’hôte tout en isolant du
réseau externe à la machine hôte :

Figure A3.01 : Configuration des interfaces réseaux.

A3.2 Installation de WAnem

La version installée est la version 3.0 (version Beta).

106
Il faut tout d’abord télécharger l’image du système sur: wanem.sourceforge.net/download.htm.

Il faut ensuite démarrer la machine à partir de l’image « .iso » dans le lecteur optique.

Figure A3.02 : Configuration du démarrage à partir de l’image.

Le système démarre à partir de l’image.

Figure A3.03 : Ecran de démarrage de WANem.

Le système essaye de configurer les interfaces automatiquement en DHCP, cela aboutira en erreur
mais le démarrage se poursuit quand même. Comme il a été décider d’installer le système sur
disque dur, il est inutile de configurer les adressages des interfaces tant qu’on est en mode live.

107
Après le démarrage, l’interface graphique de WANem s’affiche.

Figure A3.04 : Interface graphique de WANem.

Afin de migrer l’installation sur le disque dur, il faut accéder en mode console. WANem dispose
d’une console appelée « LXTerminal ». Cliquer sur le bouton encadré en rouge pour y accéder.

Figure A3.05 : Accès au mode console.

Un terminal avec des informations sur la configuration d’adresse IP s’affiche ainsi qu’ une invite
WANemControl @ PERC>.

Il faut quitter cette invite avec la commande exit2shell pour accéder à l’invite de root Linux.

Pour ce faire, il faut taper la commande suivante :

> exit2shell

108
Knoppix fournit un utilitaire pour permettre d’installer le système sur disque dur, pour l’ utiliser, il
faut lancer la commande suivante :

Figure A3.06 : Commande d’installation sur le disque dur.

Cliquer ensuite sur « Accepter et continuer » deux fois pour les avertissements (ceux-ci sont pour
empêcher de détruire un disque préexistant réel, puisqu’il s’agit d’une machine virtuelle dédiée,
aucun risque n’existe. )

Figure A3.07 : Démarrage de l’installation sur le disque dur.

Figure A3.08 : Avertissement sur l’installation sur le disque dur.

Laisser l’option « auto » sélectionné pour le partitionnement, cliquer sur « OK ».

109
 Figure A3.09 : Choix du mode de partitionnement.

Cliquer sur « Oui » pour démarrer le partitionnement automatique avec 1 Go pour le swap, 3 Go
pour le système de fichiers.

Figure A3.10 : Démarrage du partitionnement automatique.

Il faut sélectionner ensuite la partition / dev / sda2 sur laquelle 0wn va copier les fichiers et cliquer
sur « OK ».

Figure A3.11: Sélection de la partition sur laquelle sera installée le système.

Attendre la copie des fichiers sur le disque dur.

110
 Figure A3.12: Copie des fichiers sur le disque dur.

Une fois les fichiers copiés dur le disque, cliquer sur « OK » lorsqu’ une boîte de dialogue
s’affiche pour confirmer l’installation du GRUB. Il faut ensuite redémarrer le système.

Figure A3.13 : Redémarrage du système.

La machine virtuelle redémarre, puis un Grub s’affiche, et le processus de démarrage commence.

On se retrouve sur l’invite WANemControl @ PERC>, mais pas sans interface graphique ni de
bureau. La machine virtuelle est maintenant permanente, on peut alors retirer l’image du système
dans le lecteur de la machine virtuelle.

Afin d’accéder à l’interface graphique, il suffit de taper la commande :

> startx

A3.3 Configuration des adresses

La configuration des adresses des interfaces peut maintenant être effectuée, vue que les
modifications sur la machine seront permanentes. La commande suivante permet de spécifier les
adresses IP pour chaque interface réseau. Les adresses utilisées pour chaque interface sont
représentées par la figure A3.14.

> resset

111
 Figure A3.14 : Configuration des adresses des interfaces.

La commande « assign » est utilisée pour affecter un hôte à une interface réseau spécifique de
WANem. Selon la topologie du réseau à simuler représentée à la figure 3.01, les interfaces sont
assignées aux routeurs R_1, R_2, R_3 et R_4.

> assign 154.126.101.3 eth0

> assign 154.126.102.3 eth1

> assign 154.126.103.3 eth2

> assign 154.126.104.3 eth3

WANem émule un réseau étendu ces routeurs. Pour un réseau étendu, leur communication doit
être transmise via l’émulateur WANem. En d’autres termes, les paquets transmis d’un hôte à
l’autre et devrait être acheminé via WANem. La table de routage doit donc être modifiée, de
même que les tables de routage des routeurs comme le montre la figure A3.15.

Figure A3.15 : Configuration du routage sur le routeur R_1.

Sur WANem, il faut modifier le fichier de configuration des interfaces « /etc/network/interfaces »

comme illustré par la figure A3.16.

112
 Figure A3.16 : Configuration des adresses des interfaces et du routage.

A3.4 Configuration des jeux de règles pour les liens

Pour configurer les caractéristiques des liens présentés au tableau 3.01, il faut entrer dans la
section mode avancé de l’interface graphique de WANem.

Figure A3.17 : Configuration des jeux de règles pour l’interface eth1 relié à R_2.

Figure A3.18 : Configuration des jeux de règles pour l’interface eth2 relié à R_3.

113
 Figure A3.19: Configuration des jeux de règles pour l’interface eth3 relié à R_4.

Pour tester la configuration, un test de ping a été effectué avant et après l’application de la
configuration des caractéristiques décrites par les figures ci-dessus.

La figure A3.20 illustre les résultats de la commande ping sur le routeur central vers le routeur
distant R_1 avant la configuration avec comme valeur de RTA de 136 ms.

Figure A3.20 : Test de PING entre le routeur R_1 et le routeur R_2 avant configuration.

Figure A3.21 : Test de PING entre le routeur R_1 et le routeur R_2 après configuration.

Après configuration, la valeur de RTA est de 160 ms, ce qui justifie que l’émulation du retard de
19 ms est réussi puisque le temps de réponse est supérieur à 155 ms (136 ms +19ms) .

114
 ANNEXE A4
INSTALLATION DE L’OUTIL MRTG

A4.1 Présentation

MRTG est un outil libre écrit en perl conçu pour le monitoring de charge de trafic et de liens
réseaux. MRTG utilise le protocole SNMP pour lire les données de trafic sur les routeurs et génère
des pages HTML contenant des images au format « .png » affichant le trafic sur chaque interface.
MRTG crée également des représentations visuelles du trafic observé au cours des sept derniers
jours, des cinq dernières semaines et des douze derniers mois. Ceci est possible car MRTG
conserve un journal de toutes les données qu’il a extraites. Par conséquent, avec MRTG il est
possible de surveiller jusqu’à 200 liaisons réseau ou plus ce qui fait de lui le système de graphes le
plus répandu pour superviser de manière très simple et visuelle un réseau. Dans ce projet, il a été
intégré à Nagios pour effectuer une surveillance de la bande passante sur chaque routeur. [43]

A4.2 Installation

La version de MRTG installée est la version 2.17.4. Il fut installé sur le même poste où Nagios est
installé Ubuntu 16.04 LTS.

apt-get install mrtg

sudo apt-get install mrtg

Une fenêtre s’affiche permettant de choisir si les fichiers de configurations seront visibles pour les
autres utilisateurs (permission 644) ou non (permission 640). L’utilisateur « nagios » doit être en
mesure de modifier les fichiers de configurations, la première option est alors la plus appropriée.

Figure A4.01 : Configuration de l’installation de MRTG.

115
Le fichier de configuration de MRTG « /etc/mrtg.cfg » contient les informations venant des
routeurs recueillies par SNMP.
Pour mieux travailler, ce fichier a été déplacé dans le répertoire « /etc/mrtg » avant de commencer
la configuration vue que plusieurs fichiers se trouvent déjà dans « /etc ».

sudo mkdir /etc/mrtg && sudo mv /etc/mrtg.cfg /etc/mrtg

A4.3 Configuration
MRTG inclut un script appelé « cfgmaker » qui aide à remplir « /etc/mrtg/mrtg.cfg » avec les
informations obtenues à partir des routeurs. Mais avant d’exécuter « cfgmaker », le service SNMP
doit être configuré et activé sur les routeurs (voir Annexe A1). La commande permettant de
« peupler » le fichier « /etc/mrtg/mrtg.cfg » prend en paramètre la communauté SNMP à laquelle
appartient les routeurs, « nagios » et leurs adresses IP respectives.

sudo cfgmaker --output /etc/mrtg/mrtg.cfg nagios@10.0.0.1 nagios@10.0.0.98 nagios@10.1.0.1 nagios@10.2.0.1

nagios@10.3.0.1

Cette procédure peut être lancée en mode « cron tab » ou en mode « daemon ».

Le script sera lancé en mode « daemon » en spécifiant l’intervalle de temps entre chaque collecte
de données. MRTG effectuera un « polling » toute les 5 minutes afin de mettre à jour le fichier de
configuration. Pour ce faire, le fichier de configuration a été modifié en ajoutant les lignes
suivantes :

RunAsDaemon : yes

Interval :5

La commande « indexmaker » permet la création des pages HTML affichant les graphes.

Les pages créées sont placées dans le répertoire /var/www/mrtg.

sudo mkdir /var/www/mrtg

sudo indexmaker --output=/var/www/mrtg/index.html /etc/mrtg/mrtg.cfg

Ensuite le fichier de configuration de apache2 a aussi été modifié afin de pouvoir mettre les pages
sur le serveur.

116
 Alias /mrtg "/var/www/mrtg/"
<Directory "/var/www/mrtg/">
Options None
AllowOverride None
Require all granted
</Directory>

A4.4 Démarrage de MRTG

La distribution linux Ubuntu 16.04 LTS utilise le système d’encodage « UTF-8 », pour que
MRTG puisse fonctionner correctement, la variable d’environnement « $LANG » doit être
changée en « C » :

sudo env LANG=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg

MRTG est accessible à l’adresse :

http://10.0.0.4/mrtg

Où 10.0.0.4 est l’adresse du serveur.

L’axe des abscisses représente le temps (en seconde, en jour ou en mois) tandis que l’axe des
ordonnées représente la charge du trafic (en octets par seconde).

Figure A4.02 : Analyse du trafic pour le routeur 10.0.0.98.

Les informations contenues dans ces graphes sont utilisées par Nagios surveiller le trafic sur touts
les routeurs par la définition de différents seuils.

117
 BIBLIOGRAPHIE

[1] http://www.aro.mg/, site consulté le 24/01/2018

[2] http://pixelmada.com/aro/index.php/l-assurance-aro/presentation/124-presentation-de-la-
societe, site consulté le 24/01/2018.

[3] http://www.info-appliquee.com/dossiers/securite.html, site mis à jour le 4/03/2018.

[4] https://www.futura-sciences.com/tech/definitions/securite-wannacry-16434/, site consulté le

25/01/2018.

[5] https://www.iso.org/fr/standard/14258.html, site consulté le 24/01/2018.

[6] C. Servin, « Aide-mémoire de réseaux et télécoms », Sciences et Techniques, édition Dunod,

2012.

[7] http://www.o00o.org/monitoring/bases.html, site consulté le 30/01/2018.

[8] C.E. Sapp, «Preparing and Architecting for Machine Learning», Gartner Technical
Professional Advice, 17/01/2017.

[9] A.S. Alain, « Etude et mise en œuvre d’un outil de supervision des serveurs », Mémoire de fin
d’étude en vue de l’obtention du diplôme d’Ingénieur en Télécommunications, Institut National
Polytechnique de la République de Côte d’Ivoire, soutenu le 04/01/2012.

[10] L. Adato, K. Yang, B. Hale, “Network monitoring for Dummies”, SolarWinds special
edition, John Wiley & Sons, Inc, 2016.

[11] https://www.cisco.com/c/fr_ca/support/docs/ip/routing-information-protocol-rip/13730-ext-
ping-trace.html, site mis à jour le 28/07/2006.

[12] https://wiki.monitoring-fr.org/supervision/snmp, site consulté le 11/02/2018.

[13] https://www.supinfo.com/articles/single/1639-protocole-snmp, article publié le 24/03/2016.

[14] http://www.dpstele.com/snmp/index.php?l=208100001, site consulté le 25/01/2018.

[15] L. Cortes, « Détection et analyse d’un problème de congestion réseau », Travail de Bachelor
réalisé en vue de l’obtention du diplôme de Master HES, Haute École de Gestion de Genève
(HEG-GE) Filière informatique de gestion, soutenu le 26/10/2015.

118
[16] https://www.journaldunet.com/solutions/expert/49711/l-analyse-des-flux-reseaux---une-
problematique-strategique-pour-les-entreprises.shtml, article publié le 16/03/2011.

[17] https://www.supinfo.com/articles/single/3124-comparaison-outils-supervison, publié le

26/10/2016.

[18] http://www.cacti.net/, site mis à jour le 25/03/2018.

[19] https://www.centreon.com/, site consulté le 25/01/2018.

[20] W. Li, K. Abdin, R. Dann, A. Moore, “Approaching Real-time Network Traffic

Classification”, Department of Computer Science, University of Queen Mary London, 2006.

[21] RFC 793, “Transmission Control Protocol DARPA Internet Program Protocol
Specification”, Defense Advanced Research Projects Agency, Septembre 2008.

[22] G. Epiphaniou, “A Traffic Classification Method using Machine Learning Algorithm”,

University of Bedfordshire, 2013.

[23] N. Movahhedinia, M. R. Khayyambashi, S. Kianian, “Real-time Traffic Classification Based

on Statistical and Payload Content Features”, Conference Paper, Department of Computer
Engineering University of Isfahan Isfahan, Iran, 2016.

[24] https://www.kdnuggets.com/2016/05/machine-learning-key-terms-explained.html/2, article

publié en Mai 2016.

[25] https://www.privatetunnel.com/news/packet-injection/, article publié le 10/04/2017

[26] S.T. Brugger, “Data Mining Methods for Network Intrusion Detection”, University of
California, Davis, 2004.

[27] V. Leon, A. Curs, “A new Machine Learning-based Intrusion Detection System”, Ecole
Supérieure Polytechnique, Université Pompeu Fabra Barcelone, 2016-2017.

[28] A. W. Moore, D. Zuev, “Internet traffic classification using Bayesian analysis

techniques”,ACM SIGMETRICS Performance Evaluation Review, 2005.

[29] J. Cheng, R. Greiner, “Learning Bayesian Belief Network Classifiers: Algorithms and
System”, Department of Computing Science, University of Alberta, Edmonton, Alberta, Canada,
2001.

119
[30] C. Welsh, “GNS3 Network Simulation Guide”, RedNectar, édition Packt Publishing, 2013.

[31] http://www.dynamips.com/, site consulté le 12/12/2017.

[32] http://wiki.iapc.ch/index.php?title=HOWTO_Configuration_MikroTik#Routage_dynamique_:_OSPF,
site consulté le 12/12/2017.

[33] https://www.manitonetworks.com/mikrotik/2017/1/2/mikrotik-snmp-configuration, article

publié le 02/01/2017.

[34] https://www.paessler.com/tools/serversimulator, site consulté le 25/02/2018.

[35] “Wide Area Network Emulator WANem 2.0 User Guide”, Performance Engineering Research
Center, TATA Consultancy Service, 2008.

[36] http://djibril.developpez.com/tutoriels/linux/nagios-pour-debutant/, site mis à jour le

10/06/2017.

[37] O. Parent, J. Eustache, “Les réseaux Bayésiens, à la recherche de la vérité”, Master 2

Recherche Connaissance et Raisonnement, Cours Cognition et connaissance - Alain MILLE,
Université Claude Bernard Lyon1, 2006 -2007.

[38] https://mrmint.fr/naive-bayes-classifier, article publié le 26/07/2017.

[39] https://blogs.msdn.microsoft.com/mlfrance/2014/08/05/evaluer-un-modle-en-apprentissage-
automatique/, article publié le 05/06/2014.

[40] https://weka.waikato.ac.nz/dataminingwithweka/preview, cours publié le 15/08/2013.

[41] https://weka.wikispaces.com/ARFF, publié le 01/10/2008.

[42] https://www.netresec.com/?page=Blog&month=2016-10&post=Detect-TCP-content-
injection-attacks-with-findject, article publiée le 25/09/2016.

[43] https://oss.oetiker.ch/mrtg/, site mis à jour le 18/02/2011.

120
 FICHE DE RENSEIGNEMENTS

Nom : ANDRIAMIANDRA

Prénom : Manovosoa

Adresse du logement de l’auteur : Lot II E 81 G M Bis Tsarahonenana Antananarivo 101 –

Madagascar
Tel: +261 33 83 243 74
E-mail: manouvsu@gmail.com

Titre du mémoire :

« MONITORING WAN ET CLASSIFICATION DE TRAFIC PAR MACHINE

LEARNING »

Nombre de pages : 87

Nombre de tableaux :05

Nombre de figures :85

Directeur du mémoire :

Nom : RATSIMBAZAFY

Prénom : Andriamanga

Grade : Maître de Conférences

Tel: +261 33 75 638 84

E-mail: ndriamanga@gmail.com
 RESUME

Malgré la complexité de sa configuration, Nagios reste l’outil de référence pour le monitoring

d’un environnement WAN et pour cette raison, plusieurs solutions ont été dérivées de ce produit.
La maîtrise d’un tel outil reste un atout important pour tout administrateur réseau qui souhaite
comprendre en tant qu’expert la discipline qu’est le monitoring réseau. Par ailleurs, l’analyse de
trafic fait partie des recommandations pour une solution de surveillance idéale. Un algorithme de
Machine Learning qui est le Naïve Bayes modèle a été utilisé pour créer un modèle de
classification de paquets afin de détecter des injections de paquets dans des trames TCP. La
performance du classifieur Naïve Bayes a été amélioré en utilisant l’estimateur Kernel qui
applique la distribution de Gauss sur chacun des attributs de l’ensemble des données.

Mots-clés: Machine Learning, Monitoring WAN, Nagios, Naïve Bayes, SNMP.

ABSTRACT

Despite the complexity of its configuration, Nagios remains the reference tool for monitoring a
WAN environment and for this reason, several solutions have been derived from this product. The
control of such a tool remains an important asset for any network administrator who wants to
understand as an expert the discipline that is network monitoring. In addition, traffic analysis is
part of the recommendations for an ideal monitoring solution. A machine learning algorithm that
is the Naïve Bayes model was used to create a packet classification model to detect packet
injections in TCP frames. The performances of the Naïve Bayes classifier have been improved
using the Kernel estimator which applies the Gaussian distribution to each attribute of the dataset.

Key-words: Machine Learning , Monitoring WAN, Nagios, Naïve Bayes, SNMP.