Pdfsammerge 161005214942

République Tunisienne
Ministère de l’Enseignement Supérieur,

de la Recherche Scientifique et de la Technologie
--
Université de Carthage
CODE: P-TRT-2
Rapport de Projet de Fin d'Etudes

Pour l’obtention du diplôme de Licence appliquée en Réseaux de l’Informatique
Spécialité: Technologies de l’Informatique et de Télécommunication
Intitulé:
Mise en place d'une Plateforme de

Supervision et de Détection d'Intrusion
Système et Réseau
Réalisé par:
Alaadine Tlich
Nabil Kherfani
Au sein de:
Hexabyte
Encadré par:
M. Nizar Ben Neji Faculté des Sciences de Bizerte
M. Rached Ben Hassine Hexabyte
Présenté devant le jury composé de:

M. Tarek Ben Mena Président
Mme. Rim Haddad Rapporteur
Année Universitaire
2015 / 2016
Remerciements
Merci Dieu de nous avoir donner la force et le courage d’aller jusqu’au bout sans dou-
ter de nos compétences.
D’abord, nos remerciements les plus sincères à l’encadrant pédagogique M.Nizar Ben
Neji pour ses efforts et ses interventions inestimables qui nous ont bien aidé à avancer et
aller de l’avant.
Nos remerciements s’adressent également à M.Mohamed Ould Lhassan, qui a veillé au

bon déroulement du projet et nous a aidé à ameloirer nos compétences grâce aux forma-
tions durant la période du stage.
Tous nos remerciements vont également à l’encadrant de la société M.Rached Ben

Hassin, qui nous a soutenu et guidé tout au long du projet.
Un Merci à tous nos amis et surtout l’équipe Cod4Squad qui nous ont bien fait perdre
du temps à jouer au lieu de s’occuper de notre travail.
Et bien évidemment, merci aux juris qui ont accépté d’évaluer notre travail.
_____________________Alâa Eddine Tlich & Nabil Kherfani
A.U 2015-2016 1
Table des matières
Introduction 9
1 Présentation générale du projet 11

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.2 Composants du réseau . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Cadre général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.1 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.1.1 Statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.1.2 Principales attaques et menaces . . . . . . . . . . . . . . . 15
1.3.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.3 Travail à faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Étude Comparative des solutions Open-Source . . . . . . . . . . . . . . . . 17
1.4.1 Outils de supervision . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1.1 Présentation des solutions . . . . . . . . . . . . . . . . . . 18
1.4.1.2 Récapitulatif des outils de supervision . . . . . . . . . . . 21
1.4.1.3 Choix de la solution adoptée . . . . . . . . . . . . . . . . . 22
1.4.2 Outils de détection d’intrusion . . . . . . . . . . . . . . . . . . . . 22
1.4.2.1 Présentation des solutions . . . . . . . . . . . . . . . . . . 22
1.4.2.2 Récapitulatif des IDS . . . . . . . . . . . . . . . . . . . . . 25
1.4.2.3 Choix de la solution adoptée . . . . . . . . . . . . . . . . . 26
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2 Supervision réseau 27
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Introduction à la supervision réseau . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.2 Superviser quoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.4 Méthodes de supervisions . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Installation et configuration de Zabbix . . . . . . . . . . . . . . . . . . . . 28
2.3.1 Installation du serveur Zabbix . . . . . . . . . . . . . . . . . . . . . 28
2.3.2 Configuration du serveur Zabbix . . . . . . . . . . . . . . . . . . . 29
2.3.3 Configuration de la base de données de Zabbix . . . . . . . . . . . . 29
2.3.4 Configuration du serveur apache2 . . . . . . . . . . . . . . . . . . . 30
2.4 Ajout d’une station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.1 Installation d’un agent Zabbix . . . . . . . . . . . . . . . . . . . . . 32
2
TABLE DES MATIÈRES
2.4.1.1 Sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.1.2 Sous Windows . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.2 Ajout du nouveau hôte dans le serveur . . . . . . . . . . . . . . . . 33
2.5 Amélioration et Optimisation de la supervision . . . . . . . . . . . . . . . . 33
2.5.1 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5.2 Alerte par Courriel électronique . . . . . . . . . . . . . . . . . . . . 36
2.5.3 Supervision des serveur VOIP . . . . . . . . . . . . . . . . . . . . . 37
2.5.4 Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.5.5 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.5.6 Activation de SSL dans apache2 . . . . . . . . . . . . . . . . . . . . 40
2.5.7 Mise à jour de Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.5.7.1 installation des packages de la release 3 de Zabbix
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5.7.2 Installation de Zabbix 3 . . . . . . . . . . . . . . . . . . . 43
2.5.8 Centralisation des logs . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3 Détection d’intrusion 46
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 Systèmes de détection d’intrusion . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.1 Mode de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.2 Types des IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.2.1 Les HIDS (Host-based IDS) . . . . . . . . . . . . . . . . . 47
3.2.2.2 Les NIDS (Network-based IDS) . . . . . . . . . . . . . . 47
3.3 Installation et mise en place de Prelude-IDS . . . . . . . . . . . . . . . . . 48
3.3.1 Installation de Prelude . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1.1 Libprelude . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1.2 LibpreludeDb . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.1.3 Base de données Prelude-admin . . . . . . . . . . . . . . . 50
3.3.1.4 Prelude-Manager . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1.5 Prelude-Correlator . . . . . . . . . . . . . . . . . . . . . . 51
3.3.1.6 Prelude-LML . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.1.7 Prewikka . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.2 Installation des agents de surveillance . . . . . . . . . . . . . . . . . 54
3.3.2.1 Profil Prelude-Manager . . . . . . . . . . . . . . . . . . . 54
3.3.2.2 Sonde Prelude-Correlator . . . . . . . . . . . . . . . . . . 55
3.4 Optimisation de la détection d’intrusion . . . . . . . . . . . . . . . . . . . 56
3.4.1 Utilisation de Prewikka en tant que service . . . . . . . . . . . . . . 56
3.4.2 Utilisation de Prelude-manager en tant que service . . . . . . . . . 58
3.4.3 Utilisation de Prelude-lml en tant que service . . . . . . . . . . . . 58
3.4.4 Démarrage de Prelude lors du « boot » . . . . . . . . . . . . . . . . 58
3.4.5 Ajout d’une sonde HIDS : OSSEC . . . . . . . . . . . . . . . . . . . 58
3.4.6 Ajout d’une Sonde NIDS : Suricata . . . . . . . . . . . . . . . . . . 60
3.4.7 Gestion des règles de Suricata avec Oinkmaster . . . . . . . . . . . 61
3.4.8 Mise en place du HoneyPot Kippo . . . . . . . . . . . . . . . . . . . 62
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.U 2015-2016 3
TABLE DES MATIÈRES
4 Exploitation et tests 64
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2 Tests d’intrusion : Pentest . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.1 Méthodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.2 Plateforme de test d’intrusion . . . . . . . . . . . . . . . . . . . . . 65
4.2.3 Simulations d’attaques . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2.4 Alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3 Interpretation des statistiques . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.4 Hexadef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Conclusion général 77
Annexe A 80
A.U 2015-2016 4
Table des figures
1.1 Organigramme d’Hexabyte . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 les motivations des attaques informatiques . . . . . . . . . . . . . . . . . . 14
1.3 Évolution du nombre d’événements détectés par l’ANSI en 2015 . . . . . . 15
1.4 Répartition IP par continent en 2015 . . . . . . . . . . . . . . . . . . . . . 15
1.5 Les techniques de piratage les plus utilisées . . . . . . . . . . . . . . . . . . 15
1.6 Architecture de Centreon et sa relation avec Nagios . . . . . . . . . . . . . 19
1.7 Architecture de Shinken . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Liste des scripts développés . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2 démo : “Check Services Status” . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3 Démo : “Disk : Bad Blocks” . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4 Démo : “TopCpu Consumers” . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5 Démo : “Last Activities” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6 Exemple d’un message reçu . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.7 Exemple d’un tableau de bord (screen) . . . . . . . . . . . . . . . . . . . . 38
2.8 exemple d’une “map” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.9 Formulaire de création d’une “map” . . . . . . . . . . . . . . . . . . . . . . 39
2.10 GrayLog 2 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1 Configuration de libprelude . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2 Configuration de libpreludeDb . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Configuration de Prelude-manager . . . . . . . . . . . . . . . . . . . . . . . 50
3.4 Fichier de configuration de Prelude-manager . . . . . . . . . . . . . . . . . 51
3.5 Configuration de Prelude-lml . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.6 Fichier de configuration de Prelude-lml . . . . . . . . . . . . . . . . . . . . 53
3.7 Fichier de configuration de prewikka . . . . . . . . . . . . . . . . . . . . . 54
3.8 Ajout d’un profil Prelude-manager . . . . . . . . . . . . . . . . . . . . . . 55
3.9 Enregistrement de Prelude-lml . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.10 l’uid et le gid de Prelude-correlator . . . . . . . . . . . . . . . . . . . . . . 56
3.11 Installation d’OSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.12 Fichier de configuration d’OSSEC . . . . . . . . . . . . . . . . . . . . . . . 59
3.13 ID de l’utilisateur “OSSEC” . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.14 Fichier de configuration de Suricata . . . . . . . . . . . . . . . . . . . . . . 61
3.15 Liste des Sondes Actives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1 Machines VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2 Réseau de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3 Commande traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4 Scénario Httrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5
TABLE DES FIGURES
4.5 scénario Zenmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.6 Ettercap attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.7 scénario ARP poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.8 Scénario Armitage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9 Alerte : service web attaqué . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.10 Notifications de niveau bas . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.11 Scanne NMAP détecté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.12 Scanne détecté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.13 Fausse alerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.14 Prewikka : Graphe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.15 Prewikka : Graphe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.16 Prewikka : Graphe 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.17 Prewikka : Graphe 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.18 Prewikka : Graphe 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.19 Prewikka : Graphe 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.20 Prewikka : Graphe 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.21 Prewikka : Graphe 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.22 Interface Hexadef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.23 Fichier de configuration de Knockd . . . . . . . . . . . . . . . . . . . . . . 81
4.24 Fichier de configuration du lancement automatique de Knockd . . . . . . . 81
4.25 Connexion au serveur via PuTTY . . . . . . . . . . . . . . . . . . . . . . . 82
4.26 Connexion refusé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.27 Scénario d’accès SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.28 Connexion etablie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.U 2015-2016 6
Liste des tableaux
1.1 liste des serveurs et leurs services . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Tableau comparatif des outils de supervision . . . . . . . . . . . . . . . . . 21
1.3 Tableau comparatif des solutions de détection d’intrusion . . . . . . . . . . 25
7
Abréviations & Acronymes
IDS : Intrusion Detection System

HIDS : Host-based Intrusion Detection System
NIDS : Network-based Intrusion Detection System
IPS : Intrusion Prevention System
LAN : Local Area Network
XDSL : x Digital Subscriber Line
ADSL : Asymmetric Digital Subscriber Line
VSAT : Vulnerability Self Assessment Tool
WIMAX : Worldwide Interoperability for Microwave Access
RTC : Réseau Téléphonique Commuté
GPS : Global Positioning System
ANSI : Agence Nationale de la Sécurité Informatique
DOS : Deny Of Service
SET : Social Engeneering Toolkit
SNMP : Simple Network Management Protocol
API : Application Program Interface
USM : Unified Security Management
SSH : Secure Shell
TTY : Terminal Type
SSL : Secure Sockets Layer
SMTP : Simple Mail Transfer Protocol
VOIP : Voice over Internet Protocol
TLS : Transport Layer Security
IDMEF : Intrusion Detection Message Exchange Format
TCP : Transport Control Protocol
LML : Log Monitoring Lacke
UID : User Identifier
GID : Group Identifier
DVWA : Damn Vulnerable Web App
8
Introduction
A l’heure actuelle, les systèmes d’information ne cesse d’évoluer et leur utilisation de-
vient de plus en plus importante. Cependant, la complexité de la maintenance et de la
gestion de ces systèmes augmente de jour en jour et le garantie de leur sécurité est de
plus en plus difficile. Ces systèmes ont bien mérité leur place au sein des entreprises dans
lesquels ils sont devenus indispensables.
Un bon réseau est un réseau bien sécurisé. Il est donc favorable de suivre certaines
règles afin de garantir l’intégrité des données, la confidentialité, la disponibilité des ser-
vices, la non-répudiation et l’authentification des utilisateurs :
– Intégrité : Vérifier si les données n’ont pas été modifiées durant la communication
de manière intentionnelle ou fortuite.
– Confidentialité : Assurer que seules les personnes autorisées aient accès à une res-
source quelconque.
– Disponibilité : S’assurer qu’un service ou une ressource soit disponible à la demande.
– Non-répudiation : S’assurer qu’aucun des correspondants ne pourra nier les tran-
sactions qui ont eu lieu.
– Authentification : Assurer l’identité d’un utilisateur, c’est à dire garantir à chacun
des correspondants que son partenaire est bien celui qu’il croit être.
Ceci dit, garantir la sécurité d’un système informatique n’est pas évidente. C’est une tâche
compliquée et difficile à gérer. L’administrateur du système doit concevoir le réseau de
manière à prendre en compte tous les scénarios possibles.
Dans ce cadre s’inscrit notre projet de fin d’étude qui consiste à réaliser une étude
sur les solutions libres des supervisions réseaux et des systèmes de détection d’intrusions
et de les installer au sein du réseau d’Hexabyte. Ce travail a été réalisé en vue d’obtenir
le diplôme en technologies de l’informatique et de Télécommunication à la faculté des
sciences de Bizerte. Le présent rapport sera composé de quatre chapitres :
Dans le premier chapitre, l’organisme d’accueil, qui nous a accueilli durant notre pé-
riode de stage, sera présenté en rappelant les produits et les services qu’il offre. Par la
suite, nous rappellerons les problématiques qui se posent dans le réseau de l’entreprise.
Enfin, une étude comparative sera réalisée sur les systèmes de supervision et les systèmes
de détection d’intrusion.
Le second chapitre sera dédié à la supervision. Il aura pour objectif de rappeler le

concept de supervision et d’administration des réseaux. Nous allons installer la solution
choisie dans le réseau et la configurer. Il y aura aussi des configurations avancées afin
9
LISTE DES TABLEAUX
d’optimiser la supervision et la sécurité du réseau.
Le troisième chapitre sera consacré à la détection des intrusions. Il aura pour objectif
de rappeler les méthodes de détection des intrusions et de définir les types des IDS. Nous
allons voir les étapes de l’installation et la configuration du système de détection d’intru-
sion choisi.
Dans le dernier chapitre, nous présenterons notre plate-forme finale. Une démons-
tration de son fonctionnement et des tests relatifs aux divers scénarios possibles seront
effectués.
A.U 2015-2016 10
Chapitre 1
Présentation générale du projet
1.1 Introduction
Dans ce chapitre nous présenterons en premier lieu notre organisme d’accueil Hexa-
byte et les différents composants de son réseau. En second lieu, nous présenterons le cadre
générale de notre projet suivi par la problématique rencontrée, les objectifs visés et la
solution proposée. Une étude comparative fera le sujet de la dernière partie de ce chapitre
dans laquelle les caractéristiques des systèmes de supervision et de détection d’intrusion
seront traitées.
1.2 Organisme d’accueil

1.2.1 Présentation
La société HEXABYTE a été créée en 2001 sous la forme d’une Société Anonyme de
droit tunisien avec un capital social initial de 280.000 DT. A la suite d’une opération
d’incorporation de réserves et d’une autre d’apports en numéraire le dit capital est passé
à la fin de 2010 à 1.750.000 DT réparti en 1 750 000 actions de nominal 1 dinar.
Le siège social de la société est situé à Béja, où se trouve aussi l’essentiel de son maté-
riel d’exploitation.La société HEXABYTE a pour objectif principal de fournir des services
à valeur ajoutée de télécommunication de type internet ainsi que la conception, la pro-
duction et la commercialisation de tous logiciels, matériels et équipements informatiques.
La société dispose des différentes autorisations suivantes :
– Autorisation triennale d’exercice de l’activité de Fournisseur de Service Internet «

FSI » délivrée par le Ministère des technologies de la communication, ayant toujours
fait l’objet de renouvèlements périodiques,
– Autorisation TR2 d’exercice de l’activité d’installation et de maintenance de tout
équipement de transmission et de réception radio,
– Autorisation TM2 d’exercice de l’activité d’installation et de maintenance de tout
équipement de transmission de données numériques.
11
CHAPITRE 1. PRÉSENTATION GÉNÉRALE DU PROJET
Le renouvèlement de ces autorisations est quasiment systématique tant que la société res-
pecte les dispositions légales et règlementaires régissant son activité.
La société Hexabyte s’est toujours distinguée par ses offres innovantes sur le marché
tunisien à travers le lancement de produits (p.ex. : tablettes PC, caméras de surveillance)
ou de services (p.ex. : streaming vidéo ) répondant aux attentes de sa clientèle.
La société est gérée par un jeune Directeur Général en la personne de M. Naceur

HIDOUSSI. Celui-ci est sorti major de l’École Supérieure des Postes et Télécommunica-
tions de Tunis (ESPTT) en 1998 et a obtenu, deux ans plus tard, son master en génie
électrique à la California State Polytechnic University, aux États-Unis. Il a travaillé dans
un premier temps en Californie de janvier 2000 à janvier 2001 pour la compagnie Hu-
ghes and Space Communication, puis dans un deuxième temps, il a mis ses compétences
au service du projet Thuraya : un satellite réalisé pour le compte des Émirats Arabes Unis.
Puis, jusqu’en août 2001, il a loué ses services à Boeing Satellites Systems où il a par-
ticipé à la conception d’un logiciel de gestion d’embauche pour le compte du département
des ressources humaines de l’entreprise, et au développement de l’interface de commande
et de télémétrie du satellite américain Spaceway.
De retour à Tunis, M. Hidoussi s’est occupé d’HEXABYTE, société qu’il a fondée

quelques mois plus tôt avec l’ambition de devenir fournisseur de services Internet pour
toutes les régions du pays. En peu de temps, la société est devenue un incubateur d’idées
en matière de nouvelles technologies et a développé plusieurs produits.
L’activité d’HexaByte est essentiellement basée sur la vente des produits et services
suivants :
– Internet Dial up : connexion via une ligne téléphonique au réseau Internet,

– XDSL Entreprises : Lignes spécialisées/ Lignes « Fibre optique » / VSAT/ WIMAX,
etc...
– ADSL Résidentielle : Pour les particuliers,
– Noms de domaines & hébergement de sites web
– Solutions de surveillance IP & Réseaux
– Packs ordinateurs et connexions RTC (connexions à bas débit)
A.U 2015-2016 12
Figure 1.1 – Organigramme d’Hexabyte
1.2.2 Composants du réseau

Le parc informatiques que nous allons superviser est composé d’un ensemble de postes
de travail, d’imprimantes, de serveurs de marque « DELL RACK power Edge » et de
routeurs Cisco. Les serveurs fonctionnent avec des systèmes d’exploitations différents et
offrent des services tel que le service web, GPS ou la voie sur IP. Ci_dessous, plus de
détails sur les serveurs concernés :
Table 1.1 – liste des serveurs et leurs services

Système d’exploitation Service offert
CentOS release 6.5 VOIP (asterisk)
Ubuntu 12.04 LTS VOIP (asterisk)
Debian 5.0.3 Web (apache) “ www.hexabyte.tn”
Windows server 2003 web (apache) “www.hexavideo.tn”
Ubuntu 14.04 LTS GPS
1.3 Cadre général

Ce travail s’inscrit dans le cadre du projet de fin d’études à la Faculté des sciences
de Bizerte pour l’obtention du diplôme de «licence appliquée en Réseaux Informatique et
Télécommunications». Il a été réalisé au local de l’Hexabyte de Elmanzah 1 pendant une
durée de 4 mois s’étalant du 01/02/2016 jusqu’au 30/05/2016.
A.U 2015-2016 13
1.3.1 État de l’art

1.3.1.1 Statistiques
D’après une statistique faite par “Hackmageddon” en janvier 2016, les motivations
des attaques informatiques sont principalement la Cybercriminalité, le “Hacktivism”, le
Cyber Espionnage et le “Cyber Warfare”.
– La Cybercriminalité : il s’agit de pirater un système informatique en but de détruire

des données et de gagner un accès à des ressources quelconques. Ce genre d’activité
est souvent pratiqué par des pirates de type “black hat”.
– Le “Hacktivism” : Les activités militantes des altermondialistes ne se développent
pas seulement dans la rue, mais aussi sur internet, notamment avec ce qu’on appelle
le « hacktivism ». Il est souvent pratiqué par des groupes de “hackers” et en même
temps des activistes.
– Le Cyber Espionnage : il s’agit de pénétrer des systèmes informatiques afin de gagner
un accès à des documents confidentiels. Il peut s’effectuer entre 2 entreprises rivales
ou même entre des pays.
– Le “Cyber Warfare” : « Une cyberguerre est une guerre dont au moins une des
composantes, dans la réalisation, les motivations et les outils (armes au sens large
du terme) s’appuie sur le champ informatique ou numérique. Ces composantes sont
dénommées des cyber attaques ». Cyberguerre et guerre de l’information (éditions
Lavoisier, 2010).
Figure 1.2 – les motivations des attaques informatiques
En Tunisie, L’ANSI (Agence Nationale de la Sécurité Informatique) a réalisé une étude

statistique sur le nombre des tentatives d’attaques informatiques. Et on a enregistrer 20
millions d’évènements qui ont été détectés par les services de l’ANSI à l’aide du système
SAHER© en cours de l’année 2015.
A.U 2015-2016 14
Figure 1.3 – Évolution du nombre d’événements détectés par l’ANSI en 2015
« Géographiquement, la majorité des adresses IP sources d’évènements est issue de la

Tunisie. Celles provenant de l’étranger sont issues essentiellement du continent asiatique
contribuant à 37%, suivies par le continent européen 31% puis par le continent africain
21%. »
Figure 1.4 – Répartition IP par continent en 2015
1.3.1.2 Principales attaques et menaces

D’après les statistiques faites par Hackmageddon en janvier 2016, 34.0% des techniques
utilisées par les “hackers” sont inconnues :
Figure 1.5 – Les techniques de piratage les plus utilisées
A.U 2015-2016 15
Déni de service (DOS) : Le but de cette attaque n’est pas de gagner un accès à des
données hébergées sur une machine distante, mais d’encombrer un service ou même la
totalité du réseau. Donc les ressources ne seront pas disponibles. La commande la plus
utilisée dans cette attaque est : ping .
Le firewall est la solution la plus qualifiée pour se protéger d’une telle attaque.
Écoute de réseau (Sniffing) : Il s’agit d’une attaque passive, qui permet d’intercepter
certaines informations qui circule sur un réseau local, en assemblant les trames dans
un format plus lisible. Cette attaque est difficile à détecter. Il existe des logiciels qui
permettent cela, nous en citons : “ wireshark”, “tcpdump” et “Ettercap”,
Il est recommandé d’utiliser des commutateurs afin de limiter les possibilités d’écoute.
“Social Engeneering” : Cette attaque est utilisée par des pirates qui possèdent des
compétences bien avancées. A l’aide des moyens de télécommunication usuels le “hacker”
cherche à obtenir des données confidentielles auprès du personnel de l’entreprise en visant
une tentative d’intrusion. Afin de faciliter la réalisation de cette attaque les pirates utilise
le “framework” “Social Engeneering Toolkit” (SET).
Se protéger d’une telle attaque ne se limite pas à des solutions “hardware” ou “soft-
ware”, il faut offrir une formation au personnel.
“Backdoor” : Un “ Backdoor ” est une entrée caché à une machine qui peut être utiliser
afin de contourner les politiques de sécurité. C’est une manière d’accéder à une machine
supposé être secrète. L’exemple principal, est le “ shell upload ” qui s’agit d’installer un
script malveillant souvent écrit en langage PHP(c99,r57), PERL ou Ruby afin de pouvoir
exécuter des commandes sur une machine distante et y avoir accès.
Injection SQL : C’est l’une des attaques web les plus utilisées. Il s’agit d’une technique
qui vise à modifier la requête SQL dans une application web afin d’accéder à des données
confidentielles modifier ces données ou créer un utilisateur privilégié. C’est possible d’in-
jecter le code SQL dans l’URL ou dans un formulaire. Un exemple d’un outil qui utilise
cette technique “SQLmap”, “Havij”, “SQLninja”, etc.
Pour proteger une application de ce genre d’attaque il faut bien sécurisé les formulaires
en utilisant des fonctions spécifiques tel que “ mysql_real_escape_string () ;”.
1.3.2 Problématique
La majorité des ressources informatique est installée dans le réseau que nous allons
protéger. Hexabyte utilise l’outil Nagios comme un système de supervision de réseau, sans
l’avoir configuré d’une manière avancée et personnalisée. Du coup, la supervision existante
est très limitée, peu efficace et n’apporte pas assez d’informations à propos du réseau. En
2013, L’entreprise a installé Suricata comme système de détection d’intrusion réseau. Ce
dernier est très bien connu et efficace en tant que IDS réseau mais seul il ne permet pas
A.U 2015-2016 16
d’assurer la détection d’intrusion assez efficace.
En décembre 2015, nous avons détecté une faille dans une application web hébergé sur
l’un des serveurs de l’entreprise, c’est dans ce contexte que nous avons proposé à Hexabyte
d’améliorer la sécurité du réseau. En effet, Si un “black hat” avait détecté cette faille il
aurait pu avoir accès à la base de données et réaliser des actions malveillantes. Il est donc
obligatoire d’améliorer la sécurité du réseau de l’entreprise.
1.3.3 Travail à faire

Pendant le déroulement du projet, nous allons veiller à satisfaire les besoins de l’entre-
prise. La solution de surveillance à mettre en place doit assurer les besoins fonctionnels
suivants.
– Surveiller l’état physique des machines et des équipements réseaux.
– Surveiller la charge des machine : nombre d’utilisateurs connectés, de requêtes,
l’usage de la CPU, le débit réseau, etc.
– Surveiller la disponibilité des applications, des services et des composants systèmes
par simple surveillance des fichiers logs.
– Surveiller les performances du réseau : débit, latence, taux d’erreur, QoS ...
– Surveiller les modifications et l’intégrité des fichiers critiques.
La solution qui sera mise en place doit fournir un ensemble de mesures qui vont nous
assister à optimiser l’infrastructure réseau et les systèmes utilisés à savoir :
– La mesure de performance, en termes de temps de réponse.

– La mesure de disponibilité des systèmes pour le calcul d’impact en cas de dysfonc-
tionnement.
– La mesure d’efficacité qui va permettre de connaitre l’usage de la bande passante et
des ressources réseau.
– La mesure de la qualité des services fournis.
1.4 Étude Comparative des solutions Open-Source

1.4.1 Outils de supervision
Dans cette partie du chapitre, nous allons étudier quatre solutions libres (Open source)
de supervision, en présentant chaque solution et en mentionnant leurs avantages et leurs
inconvénients.[URL_N1]
A.U 2015-2016 17
1.4.1.1 Présentation des solutions

Nagios
– Langage : C/PHP
– URL : https ://www.nagios.org/downloads
Nagios est un système de supervision réseau, développé par Ethan Galstad dès 1999 et
est actuellement en sa version 4.1.1. Ce logiciel fonctionne sous linux et la plupart des
système UNIX.
Il se décompose en trois parties :
– Le moteur de l’application qui s’occupe de l’ordonnancement des tâches de super-

vision.
– L’interface Web, qui permet la visualisation des informations .
– Les plugins, une ensemble des mini programmes qui complètent Nagios
Il possède plusieurs fonctionnalités, nous en citons quelques unes :
– Envoi des avertissements et des alarmes par courrier électroniques ou par sms.
– Récupération des informations du réseau et des équipements.
– Surveillance des services réseaux (HTTP/ ICMP/SMTP...).
– Surveillance des ressources matérielles ( stations / équipements réseaux . . .).
– Génération des rapports de fonctionnement des services, etc.
Zabbix
– Langage : C/C++/PHP
– URL : http ://www.zabbix.com/download.php
Zabbix[AND_13] est un logiciel open source de supervision des réseaux développée en

C en 2002 . Son interface web est développée en php et en javascript. Il se compose de
quatre parties :
– Zabbix Server, c’est le composant principal. Il s’occupe de la supervision distance

ou local.
– Zabbix Frontend, c’est l’interface web de Zabbix. Il permet de visualiser les évène-
ments.
– Zabbix Proxy, c’est le collecteur des informations
– Zabbix Agent, offre un supervision active es ressources locales de la machine ou il
est installé.
Ces principales fonctionnalités :
– Récolte des informations Via SNMP, tests services et agents Zabbix .

– Supervision répartie du réseau et surveillance des stations et des serveurs web, mail„,
A.U 2015-2016 18
– Récolte des informations depuis les agents installés sur les machines à superviser.
– Visualisation de l’état du réseau et de ces équipements à l’aide d’une interface
graphique web.
– Création et visualisation de la cartographie du réseau.
– Découverte des serveurs et des équipements réseau d’une manière automatique, etc.
Centreon
– Langage : PHP
– URL : https ://download.centreon.com
Centreon est une application libre ( open source ), Elle est basé sur Nagios. Depuis 2012
Centreon utilise son propre moteur de collecte et gestionnaire d’événement .Il est plus
simple à installer et à configurer que Nagios et il offre une interface graphique avancé et
claire. Ces principaux fonctionnalités :
– Mêmes fonctionnalités que Nagios .

– Configuration en ligne via une API.
– Gestion des dépendances entre les services
– Visualisation des graphes et des données avancée
En dessous, un schéma qui explique la relation entre Nagios et centreon :
Figure 1.6 – Architecture de Centreon et sa relation avec Nagios
A.U 2015-2016 19
Shinken
– Langage : Python
– URL : http ://www.shinken-monitoring.org/download.php
Shinken[URL_N2] est un système de supervision open source, il s’agit du cœur de Nagios

réécrit en python. On lui a apporté une nouvelle architecture plus souple et plus facile a
maintenir. Il se compose de plusieurs daemons qui coopèrent entre eux afin de fournir les
mêmes fonctionnalités que Nagios .
Shinken se constitue de plusieurs daemons qui ont chacun son rôle. Le maitre de ces
daemons est l’Arbiter, il lit la configuration, la découpe et l’envoie vers les autres dae-
mons. Il est aussi responsable de la disponibilité des autres daemons. Les daemons de type
pollers ont le rôle de l’ordonnanceur ils ordonnassent la supervision. Ils existe d’autres
daemons comme les Reactionners, Broker et Schedulers .
Figure 1.7 – Architecture de Shinken
A.U 2015-2016 20
1.4.1.2 Récapitulatif des outils de supervision
Table 1.2 – Tableau comparatif des outils de supervision
Avantages Inconvénients
-Complexité de paramétrage : il
+Très bien documenté.
faut passer par la configuration
+Extensible.
textuelle.
+Fiable et robuste.
Nagios -Interface web non ergonomique
+Une large communauté.
et manque de visualisation
+Un très grand nombre de plugins
graphique.
à disposition .
-Évolution lente du logiciel.
+Une application complète.
+Très bien documenté.
-L’agent zabbix envoie par
+L’interface de supervision et de
défaut en claire les informations.
configuration sont plus claires et
-Pas facile à utiliser pour un
plus intuitive que celui de Nagios.
simple utilisateur.
+L’agent peut lancer des scripts
-Interface web compliqué et plein
afin de collecter de l’information.
Zabbix de fonctionnalités.
+Dessiner les graphe en temps réel
-
(mise à jours toute les 30secondes).
-
+Gestion des droits d’accès des
-
utilisateurs .
-
+Configuration des notifications et
-
des alértes facile à l’aide de shell
scripts.
+Interface Web très ergonomique.
-Possibilité de rencontrer des
+Une Solution complète de
Centreon problèmes de compatibilité.
supervision.
-Moins rapide que Nagios.
+Très performant.
+Compatible avec Nagios.
+Interface web ergonomique et
-Shinken utilise beaucoup de
moderne.
ressources par rapport à Nagios.
+Très performant .
-Il dispose d’une architecture
+Développé en python ce qui
compliquée.
permet la séparation des taches.
Shinken -Une installation et une
+Haute disponibilité des services.
configuration difficile et avancée
+Monitoring via : WMI ,
par rapport aux autres logiciels.
NSClient++ pour les machines
-
windows.
-
+Monitoring via SNMP, SSH,local
agent,ICMP,..
A.U 2015-2016 21
1.4.1.3 Choix de la solution adoptée

Après avoir établi une étude comparative sur les quatre solutions libres de supervision
proposées ci-dessus, nous étions hésités entre Zabbix et Shinken.Au final, nous avons
décidé de mettre en place la solution Zabbix. C’est la solution la plus convenable parce
qu’elle répond fidèlement aux besoins de l’entreprise.
1.4.2 Outils de détection d’intrusion

Dans cette partie du chapitre nous allons réaliser une étude de cinq systèmes de détec-
tion d’intrusion libres, en présentant chaque solution et en mentionnant leurs avantages
et leurs inconvénients.
1.4.2.1 Présentation des solutions

SNORT
– URL : https ://www.snort.org/downloads
Snort est un système de détection et de prévention d’intrusion open source conçu en 1997
par Marty Roesh et racheté par SourceFire. Il a le pouvoir d’interagir avec le pare-feu
pour bloquer les intrusions en jouant le rôle d’un IPS (Intrusion Prevention System) en
ajoutant des plugins dédiés spécifiques tels que Snort natif et Snort-inline. Il utilise des
règles basées sur les signatures, les protocoles et l’inspection d’anomalie. Il offre aussi la
possibilité de créer ses propres règles et plugins. C’est le NIDS le plus déployé, il est même
devenu un standard des NIDS et des IPS.
Il joue cinq principaux rôles :

– Packet sniffer : Il effectue l’écoute de réseau dans les différents niveaux.
– Packet logger : Il enregistre les logs dans une fichier texte.
– Alarm correlator : Il gére les notifications et les alertes.
– Detection engine : Il s’occupe de la détection des menaces.
– Pre-processor/Packet decoder : Il prépare les informations afin qu’ils soient lisibles.
Il posséde un ensemble de caractéristques, nous en citons :

– Open source
– Petite taille : ~800K
– Portable : Fonctionne sur plusieur OS : linux, Windows, MacOS X, etc)
– Rapide : Il dispose d’une vitesse de détection trés rapide( ~100MBps)
– Configurable : Son configuration est facile et la language de ses règles est simple.
A.U 2015-2016 22
Prelude IDS
– URL :https ://www.prelude-siem.org/projects/prelude/files
Prélude-IDS est un IDS hybride conçu en 1998. Il joue le rôle d’un :

– NIDS :Network IDS
– HIDS :Host Based IDS
– LML : Log Monitoring Lackey
Il permet de stocker les logs dans une base de données (mysql/PostgreSQL). Il est com-
patible avec Snort, Nessus et plusieurs analyseurs de logs. Il se compose de plusieurs
sous-ensembles :
– La librairie libprélude,
– La sonde réseau Prelude-nids,
– La sonde locale Prelude-lml,
– Le contrôleur Prelude-manager,
– L’interface web Prelude-php-frontend.
prelude dispose de plusieurs fonctionnalités, nous en citons :

– Détection d’intrusion réseau,
– Détection d’intrusion machine,
– Correlation d’événements,
– Vérification d’intégrité des fichiers,
– Scanner les vulnérabilités, etc.
AlienVault OSSIM
– URL : https ://www.alienvault.com/products/ossim
AlienVault OSSIM[URL_N3] ( Open Source Security Information Management ) est un

IDS hybride qui regroupe des outils garantissant la sécurité du réseau, des machines, et
des équipements réseaux en détectant les intrusions et les bloquant .
Ossim se compose d’un ensemble de logiciel Open-source :

Snort : Détection d’intrusion réseau.
Suricata : Détection d’intrusion réseau, c’est le NIDS qui est configuré par défaut.
Ossec : Détection d’intrusion machine.
Prads : Identification des machines et des services.
Nagios : Utilisé pour la supervision du réseau.
Nessus : Analyseur de vulnerabilités.
A.U 2015-2016 23
BRO IDS
– URL : https ://www.bro.org/download/
Bro ids est un système de détection d’intrusion destiné aux réseaux à fort trafic. Cette
application a été lancée en 1998. Il a été conçu pour :
– Minimiser/éviter toute perte de paquet
– Minimiser/éviter tout faux positif
– Optimiser la défense de la sonde contre les attaques
– Envoyer des alertes en temps réel
– Accepter des nouvelles fonctionnalités
Bro c’est :
– Un capteur de packet
– Analyseur de trafic
– Système de détection d’intrusion réseau
– Enregistreur de logs
AlienVault USM
– URL : https ://www.alienvault.com/products
AlienVault[URL_N3] USM (Unified Security Management) est une solution payante pro-
posée par AlienVault. Cette plate-forme enveloppe 5 grandes tâches de sécurité réseaux :
– Détecter les intrusions
– Analyser les comportements des trafics et des services
– Scanner les vulnérabilités et les tester
– Déclencher des activités après l’incident (Alerte, gestion de logs, prévention d’un
événement.)
– Scanner et découvrir les machines qui sont connectées au réseau
A.U 2015-2016 24
1.4.2.2 Récapitulatif des IDS
Table 1.3 – Tableau comparatif des solutions de détection d’intrusion

Avantages Inconvénients
-Les sondes nids peuvent être
+Une très grande
vulnérable.
communauté.
-Nécessite une étude avant le
+Mise à jour régulière de la
placement des sondes.
Snort base de signatures.
-Nombreuses fonctionnalités
+Nombreux plugins
payantes.
documentations riches.
.
+Logiciel libre.
.
-La base de données des signatures
+Compatible avec plusieurs
est moins riche que celle de snort.
autres outils.
-Besoin de connaissances en
+Il intègre les fonctionnalités
Prelude sécurité.
NIDS e HIDS.
IDS .
+Scanne de vulnérabilités.
.
+Format normalisé.
.
+Logiciel libre.
.
+Interface web très claire et
-Documentation faibles
ergonomique.
-Collection de logs limité
+Une très grande entreprise
-Modèles des rapports limités
OSSIM derrière cette solution.
-Moins de fonctionnalités par
+Gestion des événements
rapport à USM ,
simple
.
+Logiciel libre.
+Faux positifs réduits
+Extensible
-Documentations faibles
+Analyses graphiques
-Absence d’une interface graphique
avancées.
Bro IDS -Manque d’informations dans les
+Compatible avec d’autres
rapports d’alerte.
outil.
.
+Compatible avec les règles
de snort grâce à snort2bro.
+Mise à jour hebdomadaire.
-Logiciel payant.
+Application riche en
USM .
fonctionnalités.
.
+Support professionnelle
A.U 2015-2016 25
1.4.2.3 Choix de la solution adoptée

Aprés avoir étudié les différentes solutions de détection d’intrusion, nous avons opté
pour Prelude-IDS. Il s’agit d’une solution compléte et facile à personnaliser et qui répond
aux besoins de l’organisme d’accueil.
1.5 Conclusion
Au cours de ce chapitre, nous avons présenté l’organisme d’accueil qui a adopté ce
projet. Puis un rappel du cadre général à été introduit. Pour finir, nous avons effectué
une étude comparative des solutions libres de supervision et de détection d’intrusion.
Dans le chapitre qui suit nous allons entamer la partie supervision. Dans cette dernière
une introduction à la supervision sera incluse suivi par l’installation de Zabbix.
A.U 2015-2016 26
Chapitre 2
Supervision réseau
2.1 Introduction
Dans ce chapitre, nous rappellerons en premier lieu le principe de la supervision réseau.
Par la suite, une description détaillée de l’installation de zabbix sera introduite suivi par
des configurations basiques et avancées.
2.2 Introduction à la supervision réseau

2.2.1 Principe
Dans un système informatique, la supervision réseau[URL_N4] est devenue une opéra-
tion indispensable qui peut économiser beaucoup d’argent en améliorant les performances
du réseau, le cout de l’infrastructure et la productivité des employés. Un système de super-
vision réseau a comme tâche principale de trouver les problèmes dans un réseau local tel
que : station non connectée, serveurs hors service, modification d’un fichier important, etc.
La supervision réseau ne peut être réalisée qu’en utilisant une variété de logiciels ou
une combinaison de solutions “software” et “hardware”. N’importe quel réseau peut être
supervisé, que ça soit filaire, sans fil, VPN ou même WAN. Il est possible de réaliser la
supervision des machines sous n’importe quel système d’exploitation (Windows, Linux,
Cisco IOS. . .)
Les systèmes de supervision réseau différent des systèmes de détection d’intrusion

(IDS) ou des systèmes de prévention d’intrusions (IPS). Ces derniers détectent et bloquent
les activités des utilisateurs non autorisés dans le réseau.
Par ailleurs, il s’agit d’une opération complexe et composée de plusieurs activités

complémentaires :
– Surveiller (l’état des machines, les statut des services. . .),
– Analyser ( des logs),
– Visualiser ( des graphes),
– Agir ( actions, scripts . . . ),
– Alerter (par SMS / mail ), etc.
27
CHAPITRE 2. SUPERVISION RÉSEAU
2.2.2 Superviser quoi ?

Un système de supervision réseau permet de superviser un ensemble de composants
physique et logique d’un système d’information :
– Le réseau et ses équipements : Commutateurs, routeurs, serveurs, onduleurs, impri-
mantes..
– Systèmes : Utilisations des ressources (CPU, mémoires . . . ).
– Applications : Disponibilité des services, performances . . .
2.2.3 Objectifs
L’objectif de la supervision se résume principalement en :
– Être réactif en envoyant une notification à l’administrateur du réseau en cas de
problème technique dans une partie du réseau.
– Être proactif en anticipant les pannes et les scénario possibles
– Viser les évènements dés leurs apparitions afin d’agir avec pertinence.
2.2.4 Méthodes de supervisions

Pour effectuer une supervision sur un système d’information, on utilise plusieurs mé-
thodes :
– Analyse des fichiers logs : Il s’agit de collecter des informations sur un système, un
service ou une application à partir de son fichier log.
– Commandes : Il s’agit de récupérer le résultat d’une commande (ping,traceroute..)
ou d’un script. Ça peut être des scripts locaux ou distants.
– A l’aide d’un agent ( Zabbix-agent, shinken-agent . . .).
– Via SNMP .
2.3 Installation et configuration de Zabbix

Il est préférable d’utiliser l’outil « Putty » pendant l’installation et la configuration du
serveur Zabbix et ses agents[URL_N5]. Cet outil utilise le protocole SSH afin d’exécuter
les commandes à distance. On doit alors configurer le service SSH sur le serveur.[URL_N4]
2.3.1 Installation du serveur Zabbix

Afin d’installer « zabbix-server » (version 2.2) on doit ajouter les dépôt de Zabbix
dans la liste des dépôts de ubuntu.
# sudo nano /etc/apt/sources.list
Puis copier les lignes ci-dessous dans le fichier , et taper CTRL+x pour enregistrer la
modification du fichier .
# Zabbix repos
deb http://ppa.launchpad.net/tbfr/zabbix/ubuntu precise main
deb-src http://ppa.launchpad.net/tbfr/zabbix/ubuntu precise main
A.U 2015-2016 28
Pour que l’outil apt-get aie confiance en ces nouveaux dépôts, on exécute cette com-
mande.
# sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys

C407E17D5F76A32B
Tout d’abord il faut mettre à jours la liste des dépôts en exécutant la commande sui-
vante.
# sudo apt-get update
En suivant les commandes en dessous on installera Zabbix-server , le serveur apache2

et l’interface web de Zabbix .
# sudo apt-get install Zabbix-server-mysql php5-mysql Zabbix-frontend-php
En cour de l’installation nous allons être demandé de saisir le nouveau mot de passe
de l’utilisateur « root » de MySQL. Il faut bien mémoriser ce mot de passe.
2.3.2 Configuration du serveur Zabbix

Le serveur Zabbix a été installé avec succès, mais il est loin d’être prés à l’utilisation.
Nous allons maintenant commencer la configuration des outils installé.
Tout d’abord il faut configurer le fichier de configuration principale de Zabbix. Pour cela
il faut ouvrir le fichier avec les privilèges "root" :
# sudo nano /etc/zabbix/zabbix_server.conf
Il faut chercher les lignes suivants et les modifier comme ci-dessous :

– DBName=zabbix // Nom de la base de donnée que Zabbix va utiliser
– DBUser=zabbix // Nom de l’utilisateur MySQL .
– DBPassword=MOT_DE_PASSE //Mot de passe de l’utilisateur MySQL
Il faut sauvegarder et fermer le fichier .
2.3.3 Configuration de la base de données de Zabbix

Pour rendre la création des tables dans la base de donnée de Zabbix plus facile, les
fichier SQL sont mis en disposition et sont compressés dans ce chemin " /usr/share/zabbix-
server-mysql/" . Pour les importer dans la base de données on doit tout d’abord les dé-
compresser :
# cd /usr/share/zabbix-server-mysql/
# sudo gunzip *.gz
Puis nous nous connectons à MySQL en tant que " root ".
# mysql -u root -p
A.U 2015-2016 29
Maintenant nous sommes connectés, il faut ensuite créer un utilisateur de nom de "zab-
bix" qui correspond à la configuration que nous avons mis dans le fichier zabbix_server.conf.
Pour cela il faut exécuter les requêtes SQL ci_dessous :
mysql > CREATE USER ’zabbix’@’localhost’ IDENTIFIED BY ’MOT_DE_PASS’;
Ensuite il faut créer la base de donnée "zabbix" , en exécutant cette requête
mysql > CREATE DATABASE Zabbix;
Puis, nous allons donner à l’utilisateur "zabbix" le contrôle sur la base de donnée "zab-
bix".
mysql > GRANT ALL PRIVILEGES ON Zabbix.* TO ’zabbix’@’localhost

mysql > FLUSH PRIVILEGES;
Nous avons finit avec la configuration initial de MySQL, revenons au terminal shell.
mysql > EXIT;
Maintenant que nous avons crée l’utilisateur et la base de donnée, il faut importer les
fichier SQL que Zabbix a besoin pour son fonctionnement.
# mysql -u Zabbix -p Zabbix < schema.sql

# mysql -u Zabbix -p Zabbix < images.sql
# mysql -u Zabbix -p Zabbix < data.sql
La base de données de Zabbix est maintenant prête à être utilisé.
2.3.4 Configuration du serveur apache2

Il faut ajuster quelques valeurs pour que php gére parfaitement les données de su-
pervision. Nous allons donc accéder au fichier de configuration de php en exécutant la
commande suivante.
# sudo nano /etc/php5/apache2/php.ini
Et changer les valeurs suivantes.
post_max_size = 16M
max_execution_time = 300
max_input_time = 300
date.timezone = Africa/Tunis
Puis enregistrer et fermer le fichier. Ensuite nous allons copier le fichier de la configu-
ration php de Zabbix dans le répertoire de configuration de Zabbix.
# sudo cp /usr/share/doc/zabbix-frontend-php/examples/zabbix.conf.php.
example/etc/zabbix/zabbix.conf.php
A.U 2015-2016 30
Il faut configurer le fichier Zabbix.conf.php comme suivant.
# sudo nano /etc/zabbix/zabbix.conf.php
Il faut configurer ce fichier avec les paramètres de connexion mysql qu’on a fait récem-
ment.
$DB[’DATABASE’] = ’zabbix’;
$DB[’USER’] = ’zabbix’;
$DB[’PASSWORD’] = ’MOT_DE_PASSE’;
Enregistrer et fermer le fichier. Pour rendre apache et Zabbix fonctionnent ensembles,
on doit copier l’exemple de configuration d’apache dans " /etc/apache2/conf-available/".
# sudo cp /usr/share/doc/zabbix-frontend-php/examples/apache.conf
/etc/apache2/conf- available/zabbix.conf
Pour activer la nouvelle configuration de Zabbix sous sur apache, on exécute la com-
mande suivante.
# sudo a2enconf Zabbix.conf

# sudo a2enmod alias
La configuration d’apache est maintenant terminé. nous redémarrons le service.
# sudo service apache2 restart
Maintenant nous allons modifier la valeur "START" de "no" à "yes" dans le fichier
/etc/default/zabbix-server pour que le service Zabbix se lance en démarrage du système.
# sudo nano /etc/default/zabbix-server
...
START=yes
...
On lance le service " Zabbix-server ".
# sudo service Zabbix-server start
Si nous voulons que l’interface web de Zabbix s’exécute dans la racine au lieu de "/zab-
bix" on doit modifier la valeur "DocumentRoot" à "/usr/share/zabbix".
# sudo nano /etc/apache2/sites-available/000-default.conf
...
DocumentRoot /usr/share/zabbix
...
A.U 2015-2016 31
2.4 Ajout d’une station

2.4.1 Installation d’un agent Zabbix
2.4.1.1 Sous Linux
l’installation des agents se fait par l’outil apt-get.

# sudo apt-get install Zabbix-agent
Maintenant nous allons commencer à configurer l’agent.
# nano /etc/zabbix/zabbix_agentd.conf
Il faut changer 127.0.0.1 par l’adresse du serveur, et la valeur de "remotecommand"

par "1".
...
Server = 127.0.0.1
...
remotecommand=1
...
Après, on aura besoin d’exécuter des commandes sur les machines agents, c’est pour-
quoi on a activer l’option "remotecommand ". L’agent maintenant est bien installé sur la
machine linux. Il faut redémarrer le service.
# sudo service Zabbix-agent restart
2.4.1.2 Sous Windows

Tout d’abord il faut télécharger l’agent windows de Zabbix qui peut être obtenu à
partir du site officiel[URL_N6]. Par la suite on extrait l’archive zip dans un dossier, soit
C :\Downloads\zabbix_agent\ maintenant on execute la commande ci_dessous dans l’in-
vite de commande.
C:\Users\tlich1337>c:\Downloads\zabbix_agent\bin\win32\zabbix_agentd.exe
–config
C:\Downloads\zabbix_agents\conf\zabbix_agentd.win.conf --install
Après qu’on a installer le service dans la machine windows, on ouvre le fichier Zab-
bix_agentd.win.conf et on modifie les valeures suivantes :
– Server= l’adresse ip du serveur Zabbix
– ServerActive=l’adresse ip du serveur Zabbix
– Hostname=le « FQDN » de la machine windows
Nous sauvegardons la modification et on démarre le service.
D:\Users\tlich1337>D:\Downloads\zabbix_agentsbin\win32\zabbix_agentd.exe
--start
A.U 2015-2016 32
Le service est maintenant disponible, il ne reste plus que de donner au service Zabbix-
agent le droit de passer le « firewall » si il y en a un.
2.4.2 Ajout du nouveau hôte dans le serveur

Il faut maintenant ajouter l’agent dans la liste des hôtes supervisionnés. Dans la barre
d’adresse du navigateur on met l’adresse ip du serveur Zabbix suivis par "/zabbix". Puis
on se connecte avec le compte par défaut de Zabbix.
Username = admin
Password = Zabbix
On clique sur l’onglet "configuration", "hosts" puis sur "Create host". On remplit le
formulaire d’ajout d’hôte comme suit :
– Hostname : Nom de la machine
– Visible name : Nom Affiché ajouter la machine dans "Linux Servers"
– Ajouter l’adresse ip de la machine
– Cocher l’option « enabled » pour activer la supervision sur cette nouvelle machine
On clique maintenant sur l’onglet "Template"ensuite on suit les étapes ci-dessous :

1. Cliquer sur "Select" pour ajouter une nouvelle "Template"
2. Choisir "Template OS Linux" puis cliquer sur "Select"
3. On peut choisir le template « SNMP Template » si on veut utiliser la supervision
avec snmp.
4. Cliquer sur "add" pour ajouter le "Template" dans le nouveau hôte.
5. Cliquer sur "update"
2.5 Amélioration et Optimisation de la supervision

2.5.1 Scripts
Un script est un ensemble de lignes de code, il s’agit d’une suite d’instructions simples
permettant d’automatiser certaine tâches. Il est souvent écrit en langage non compilé
(bash / perl / ruby / python).
Pour créer un script qui fonctionne sous Zabbix, on suit les étapes suivantes :
1. Se connecter sur l’interface web de Zabbix.
2. Sélectionner l’onglet « Administration » puis le menu « Scripts ».
3. Cliquer sur « Create script ».
4. Remplire les champs du formulaire comme ci_dessous.
– Name : Nom Du Script
– Type : Sélectionner « Script »
– Execute on : Choisir si le script va être exécuter sur la machine serveur ou l’hôte
supervisé.
– Commands :Le code du script
– Description : Une bref description de la fonctionnalité qui offre le script pour.
A.U 2015-2016 33
– User groups : Choisir le groupe d’utilisateurs qui peut executer le script.

– Host groups : Choisir le groupe d’hôtes où le script s’exécutera
– Required host permission : Read ( Si le script va seulement lire des données) /write
(Si le script va effectuer des modifications au niveau d’un fichier ) .
– Enabled confirmation : à cocher pour pouvoir utiliser le script.
Cliquer sur « Save » pour enregistrer le script.
À ce niveau, nous avons réaliser un ensemble de scripts qui sont indispensables dans
le domaine d’administration réseau. Ci_dessous une liste de quelques scripts que nous
avons ajouté.
Figure 2.1 – Liste des scripts développés
« Check Services Status » : un script qui permet d’afficher les états des services de la
machine sélectionné.
Figure 2.2 – démo : “Check Services Status”
A.U 2015-2016 34
« Disk :Bad Blocks » : ce script vérifie l’état des disques dure de la machine sélectionné.
En utilisant l’outil Crontab de linux, le script BadBlocks va s’exécuter toutes les 24h et
enregistrera le résultat dans un fichier texte. Quand on exécute ce script il affichera la
dernière version du fichier texte donc le dernier résultat .
Figure 2.3 – Démo : “Disk : Bad Blocks”
« TopCpu consumers » : Ce script affiche les processus qui utilisent plus de ressources.
Il se base sur la commande ‘top’ .
Figure 2.4 – Démo : “TopCpu Consumers”
« Last Activities » : Ce script affiche les activités récente du système ( démarrage,

redémarrage, connexion des utilisateurs sur les interface TTY . . . ).
A.U 2015-2016 35
Figure 2.5 – Démo : “Last Activities”
« Check SSL Expiration » : C’est une fonctionnalité très importante et peut utilisé
dans l’administration système. Ce script permet de surveiller l’expiration du certificat
SSL.
2.5.2 Alerte par Courriel électronique

Dans cette partie nous allons voir comment configurer Zabbix pour qu’on reçoit des
notifications par email. Ainsi, il sera possible de savoir tous les changements des « items »
grâces aux « triggers ».
Commençons par créer un média de type email. Pour cela, il faut se rendre dans l’in-
terface web de Zabbix en accédant au menu « administration » puis « media type ».
Ensuite on clique sur « create media type » et on remplit le formulaire ce cette façon :
– Description : Une description bref du media ou bien le nom du media.

– Type : On selectionne « Email »
– SMTP server : L’adresse ip ou le nom de domaine du serveur SMTP
– SMTP helo : Nom de domaine du serveurs
– SMTP email : L’email qui va émettre les messages
Puis on clique sur « Save ».
Le media est maintenant prêt. Il est nécessaire de créer une action Afin de déclencher
l’envoi d’email à chaque fois qu’un « trigger » se lance. On clique sur l’onglet « Confi-
guration » puis « Actions » puis sur « create Action » pour la création d’une action.
Maintenant on remplit le formulaire comme suit :
– Name : Nom de l’action

– Event source : Sélectionner « triggers »
– Default subject : {TRIGGER.NAME} : {STATUS}
– Default message : {TRIGGER.NAME} : {STATUS}
– Status : Sélectionner « Enabled »
– Aller à la fenétre « Action operations » puis cliquer sur « new »
– Operation type : Selectionner « Send message »
A.U 2015-2016 36
– Send message to : Choisir l’utilisateur qui va recevoir l’email

– User medias : Sélectionner le media qu’on vient de créer
– Cocher l’option Default message
On clique sur « add » puis « save ».
L’alerte par email est maintenant mise en place et active. Un exemple d’email reçue
dans la figure suivante :
Figure 2.6 – Exemple d’un message reçu
2.5.3 Supervision des serveur VOIP

La supervision d’un serveur VOIP nécessite plus de configuration que celle d’un ser-
veur, on a pas seulement besoin de savoir les information générales du systèmes et de ses
applications.
On aura besoin de savoir plus d’informations que prévue, exemple.
Appels actifs.
# sudo /usr/sbin/asterisk -rvvvvvx ’show channels’|grep --text -i ’active

call’|awk ’{print $1}’
Messages fax reçu/envoyé avec succée.
# sudo -u Zabbix sudo /usr/sbin/asterisk -rvvvvvx ’fax show stats’ | grep

’Completed’ | awk ’{print $NF}’
Nous avons utilisé un ensemble de commandes de ce genre dans des scripts pour ef-
fectuer la supervision sur les serveurs VOIP de l’entreprise. Nous avons réussi à réaliser
les fonctionnalités cité ci-dessous :
– Nombre d’appels actif,

– Nombre de sessions courante des fax,
– Nombre et pourcentage des erreurs de transmission des appels,
– Nombre et pourcentage des erreurs de transmission des messages par fax,
– Nombre de fax et de téléphones disponibles, etc.
A.U 2015-2016 37
2.5.4 Screen
Un « screen » est une vue composée de plusieurs graphes, champs de textes et d’autres
forme de données qui facilite la supervision d’un système informatique. Ci_dessous un
exemple sur un des screen que nous avons crée.
Figure 2.7 – Exemple d’un tableau de bord (screen)
Pour créer un « screen » personnalisé, il faut passer par les étapes suivantes :
– Se connecter sur l’interface web de Zabbix
– Sélectionner l’onglet « Configuration » puis « Screens ».
– Cliquer sur « Create screen ».
– Donner un nom à la nouvelle vue, préciser le nombre des colonnes et des lignes.
– Puis remplir les champs par les graphes et les données qu’on veut ajouter.
Notre nouvelle vue est maintenant prête à être utilisé. Pour l’exploiter il faut aller à
l’onglet « Monitoring » puis « Screens » et choisir la vue qu’on veut à partir de la liste
affiché.
2.5.5 Maps
Une « Map » est une carte composée de plusieurs machines interconnectées. Ça per-
met de visualiser l’état de la connexion entre les machines qu’y existent et d’exécuter des
scripts sur une machine quelconque. Ci_dessous un exemple de carte que nous avons crée.
A.U 2015-2016 38
Figure 2.8 – exemple d’une “map”
Pour créer une « map » personnalisé il faut suivre les étapes suivantes :
– Se connecter sur l’interface web de Zabbix.
– Sélectionner l’onglet « configuration » puis « Maps ».
– Cliquer sur « create map ».
– Remplir les champs suivants comme nous le souhaitons.
Figure 2.9 – Formulaire de création d’une “map”
– Ajouter un icône.
– Cliquer sur l’icône.
– Définir le type de l’objet que l’icône représentera(Host,Map,image. . .) dans notre
cas , une machine.
– On remplit le champ « label » par une bref description de la machine, pour ceci nous
allons utiliser des macros qui vont chercher les informations d’une façon dynamique.
Par exemple.
A.U 2015-2016 39
{HOST.NAME}
{HOST.CONN}
(CPU: {{HOST.HOST}:system.cpu.load[percpu,avg1].last(0)} )
{HOST.NAME} : Retourne le nom de la machine.

{HOST.CONN} : Retourne l’adresse ip de la machine.
{{HOST.HOST} :system.cpu.load[percpu,avg1].last(0)} : Retourne l’usage du pro-
cesseur de la machine (une pourcentage).
– Sélectionner l’emplacement de la libelle ,par défaut c’est « bottom » .
– Sélectionner l’hôte que l’icône va présenter dans le champs « Host ».
– Choisir l’icône et sa dimension .
– Cliquer sur « apply » pour effectuer le changement.
Afin d’améliorer améliorer la « map ». Nous allons ajouter une liaison entre deux ma-
chines. Cette liaison présentera la connexion physique ou logique entre les 2 terminaux.
Nous suivrons donc les étapes ci_dessous :
– Sélectionner les deux machines que nous allons les relier.

– Cliquer sur le bouton d’ajout d’un lien.
– Cliquer sur l’icône d’un des terminaux.
– Aller à la fenêtre « Links for the selected element » et cliquer sur « edit » afin de
configurer la liaison.
– Pour afficher le débit montant et descendant de la station nous utilisons des macros
spécifique dans le champ « label ».
In : {zabbixServer:net.if.in[eth0].last(0)}
Out : {zabbixServer:net.if.out[eth0].last(0)}
– Choisir le type du lien ( ligne continue, ligne continue gras. . .)
– Choisir le couleur du lien (vert par défaut)
– Pour que la ligne devienne rouge si la machine n’est pas connectée, nous allons
activer un « trigger » qui va surveiller la connectivité entre les 2 machines. Dans
notre cas ce trigger est intitulé « zabbixServer : Zabbix agent on ZabbixServer is
unreachable for 5 minutes » puis nous sélectionnons la couleur rouge si le trigger
s’active.
– Cliquer sur « apply »
Notre « Map » est maintenant bien configurée. Il ne reste qu’à sauvegarder le changement.
Pour exploiter la « map » nous sélectionnons l’onglet « monitoring » puis « maps » .
2.5.6 Activation de SSL dans apache2

L’interface web de Zabbix fonctionne avec le protocole http. Ce protocole n’est pas
sécurisé car il transfère le trafic sans le crypter. Parfois le serveur envoie au client web des
données confidentielles, et il se peut qu’un intrus intercepte les messages et les exploite
pour effectuer des actions non désirées. C’est pourquoi nous avons activé le module SSL
dans apache2 pour sécuriser le trafic.[URL_N7]
A.U 2015-2016 40
D’abord il faut activer le module SSL puis redémarrer le service apache2.
# sudo a2enmod ssl

Pour la configuration nous aurons besoin d’une certificat ssl. Nous utiliserons donc
l’outil « OpenSSL ».
# sudo mkdir /etc/apache2/ssl

# cd /etc/apache2/ssl
# sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout
/etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
Après avoir entrer la commande ci_dessus, on nous demande de saisir quelques infor-
mations.
Country Name (2 letter code) [AU]:TN

State or Province Name (full name) [Some-State]:Tunis
Locality Name (eg, city) []:Menzah
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Hexabyte
Organizational Unit Name (eg, section) []:IT Department
Common Name (e.g. server FQDN or YOUR name) []: Zabbix.hexabyte.tn
Email Address []: Zabbix@hexabyte.tn
Deux fichier ont été créer dans le dossier « /etc/apache2/ssl » : apache.crt et apache.key.
Maintenant que nous avons la certificat et la clé nous allons configurer apache2 pour qu’il
utilise ces deux fichiers.La configuration se fait dans sur le fichier « default-ssl.conf ».
# sudo nano /etc/apache2/sites-available/default-ssl.conf
Sans les commentaires le fichier sera comme suit.
A.U 2015-2016 41
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster@hexabyte,tn
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/apache.key
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
</IfModule>
Maintenant il ne reste qu’a activer le « SSL-enabled virtual host » et redémarrer le
service apache.
# sudo a2ensite default-ssl.conf

Maintenant que tout est mise en place nous pouvons accéder à l’interface de Zabbix
via HTTPS. Il est nécessaire d’accepter le certificat pour que l’échange des données sera
effectué.
2.5.7 Mise à jour de Zabbix

L’un des plus grands défauts de Zabbix est que ses composants envoient les données
non cryptées d’où le manque de sécurité. Un pirate peut facilement écouter le trafic et en
savoir d’avantage sur le réseau. Dans la version 3.0 de Zabbix sortie le 16 février 2016,
dont le développement a pris deux ans, on a inclus le chiffrement du trafic. Cette version
apporte encore plus de fonctionnalités et d’améliorations graphiques. Il s’agit d’une ver-
sion riche et complète.
Le chiffrement du trafique échangé entre l’ensemble des composants est basé sur le
protocole TLS .
Il y a d’autres nouveautés offerte dans cette version, nous en citons :
– les fonctions « prévision » et « temps restant » qui utilise des algorithmes de prédic-
tion qui permettent de savoir dans combien de temps nous allons passer en dessous
du seuil critique ou de savoir où on en sera de notre espace disque dans 1 heure,
– L’utilisation du processeur par processus ou par utilisateurs,
– Amélioration de la visualisation des graphes en offrant la possibilité de zoomer sur
A.U 2015-2016 42
les graphiques,
– L’ajout d’une fonctionnalité similaire à « Crontab » de linux, qui permet de lancer
un script ou un évènement à une heure précise. etc
Cette mise à jour est disponible à partir de Zabbix 2.2 ou à partir d’une version ultérieur.
Il faut aussi vérifier si la version de php est 5.4.x .
Avant de démarrer la mise à jour[URL_N8] il est préférable de créer un « backup » des
fichiers de configuration et de la base de donnée.
# cp /etc/zabbix/zabbix_server.conf /opt/zabbix-backup
# cp /etc/httpd/conf.d/zabbix.conf /opt/zabbix-backup
# cp /usr/share/doc/zabbix-* /opt/zabbix-backup
# sudo mysqldump -uroot -p Zabbix > Zabbixdb.sql
Afin d’effectuer la mise a jour nous allons suivre les étapes qui suivent.
2.5.7.1 installation des packages de la release 3 de Zabbix
.
# wget http://repo.zabbix.com/zabbix/3.0/ubuntu/pool/main/z/zabbix-release/
zabbix-release_3.0-1+trusty_all.deb
# dpkg -i Zabbix-release_3.0-1+trusty_all.deb
2.5.7.2 Installation de Zabbix 3

Installation du serveur Zabbix
# sudo service Zabbix-server stop

# sudo apt-get install –only-upgrade Zabbix-server-mysql
Installation de la dernière version de l’interface web Zabbix
# sudo apt-get install –only-upgrade Zabbix-frontend-php
Notre serveur Zabbix est maintenant à son version 3 et prés à être utilisé. Il ne reste
que de lancer le service et d’accéder à l’interface via un navigateur.
# sudo service Zabbix-server start
2.5.8 Centralisation des logs

Un log ou journal est une simple notification d’une importance plus ou moins élevée
envoyée par l’OS, un équipement du réseau ou un service. Ces données permettent à l’ad-
ministrateur du système de suivre les éventements et retracer les actions.
Collecter les logs c’est très important, mais pouvoir les centraliser, les traiter et les
analyser c’est encore plus ! C’est pour cette raison que nous avons décidé de mettre un
A.U 2015-2016 43
place un centralisateur de logs qui va s’occuper du traitement des logs de tous le réseau.
Nous avons donc choisis d’installer “GrayLog” [URL_N9].
Graylog est un logiciel de centralisation et d’analyse de logs très puissant. Il possède

une interface web très ergonomique. Cet outil nécessite la mise en place des logiciels sui-
vants.
– Nxlog : Collecteur de logs.

– Elasticsearch : Un serveur de recherche et d’indexation.
– MangoDB : Base de données pour y stocker les informations.
Qu’est ce que nous allons gagner de la centralisation des logs ?
– Recherche et statistique : Centraliser les logs dans une seul machine va nous per-
mettre d’effectuer des recherches trais précises sur l’activité des systèmes et des
utilisateurs tout en étant connecté à partir d’une seule machine.
– Détection d’intrusion : Les plus part des IDS se servent des fichiers de logs afin de
détecter des comportements suspicieux sur une réseau. Dans ce cas l’IDS aura une
source d’information de plus.
– Garantir la disponibilité des logs : Si par malheur un pirate a attaqué notre réseau et
pour éliminer ses traces, il a supprimé les fichiers logs. Dans ce cas, la centralisation
est la solution idéal pour garantir la survie des logs en envoyant des copies au serveur.
Comment la centralisation fonctionne ?
1. Tout d’abord il faut créer les logs, ils sont souvent générés par les services et les
applications.
2. Ensuite, transférer les log dans le serveur de centralisation via des agents.
3. Puis, organiser les logs dans des répertoire ( Exemple : répertoire par machine) et
les filtrer par des critères choisis.
4. Enfin, exploiter les logs : utilisation des Graphes, création des rapports et envoie
des alertes.
Ci-dessous, l’interface web du centralisateur des logs “GrayLog”.
A.U 2015-2016 44
Figure 2.10 – GrayLog 2 GUI
2.6 Conclusion
Au cours de ce chapitre, nous avons vu une introduction au domaine de supervision ré-
seau, suivis par les étapes de l’installation, configuration et optimisation de la supervision.
L’IDS sera le sujet du prochain chapitre. Ce dernier, couvrira le principe et les diffé-
rentes caractéristiques des IDS suivi par l’installation et la configuration de la plateforme
de détection d’intrusion.
A.U 2015-2016 45
Chapitre 3
Détection d’intrusion
3.1 Introduction
Les systèmes de détection d’intrusion, ou souvent appelés IDSs, sont devenus des
composants essentiels dans les offices de sécurité et de l‘administration réseau. Cependant
beaucoup d’experts en sécurité réseaux ignorent les avantages qu’offrent ces systèmes.
Dans ce chapitre nous allons rappeler l’importance des IDSs dans un système d’infor-
mation d’une entreprise et leurs différents types. Une description détaillée des étapes de
l’installation sera par la suite introduite suivi par des configurations et des optimisations.
3.2 Systèmes de détection d’intrusion

3.2.1 Mode de fonctionnement
Comme son nom l’indique un système de détection d’intrusion est fait pour détecter
les intrusions, c’est à dire qu’il a pour but de détecter les attaques ciblant les équipements
du réseau et alerter les personnes concernées. Un IDS installé dans un réseau peut être
comparé à un système d’alarme installé dans une maison. À travers les différentes mé-
thodes, ces deux systèmes détectent les intrusions et envoient une sorte de signal d’alarme
spécifique.
Un IDS peut être configuré afin de pouvoir travailler en coopération avec un firewall
qui vise à contrôler le trafic. Il ne faut pas confondre ces deux outils de sécurité. Un
firewall essaye de stopper les attaques et les accès interdits, il est souvent placé dans la
première ligne de défense. Alors que l’IDS détecte si oui ou non le réseau est attaqué.
C’est sûr que la mise en place d’un IDS va améliorer la sécurité d’un réseau mais il n’offre
pas une garantie totale de la sécurité.
En générale, l’IDS utilise deux techniques de détection[THI_04] : détection d’anoma-

lies et détection par signatures.
Détection d’anomalie C’est une technique utilisée afin de surveiller le comportement

du réseau et de ses équipements. A chaque fois qu’il détecte un comportement anormal
d’une machine, il le classe en tant que tentative d’intrusion : par exemple, si l’IDS détecte
qu’un certain utilisateur s’est connecté sur une machine 15 fois alors que d’habitude il
46
CHAPITRE 3. DÉTECTION D’INTRUSION
ne se connecte qu’une ou deux fois quotidiennement ou si un ordinateur a été utilisé à

3 :00am alors que personne n’est censé être sur son poste. Tout comportement suspicieux
similaire aux exemples cités précédemment sera alerté.
Détection par signatures Cette méthode utilise les signatures des comportements
suspects les plus répandus dans le domaine des intrusions afin de prédire et détecter les
tentatives d’attaques. Prenons l’exemple d’un échec de trois tentatives d’authentification
d’un utilisateur sur une machine, il s’agit d’un cas suspect et doit être alerté afin de vérifier
si c’est bien une tentative d’intrusion ou un simple accident. Dans le cas des attaques
réseaux l’IDS vérifie l’intégrité des paquets et calculera leurs « checksums » pour les
comparer aux signatures suspectes, si ils sont compatibles l’IDS va alerter l’administrateur
de cet incident.
3.2.2 Types des IDS

3.2.2.1 Les HIDS (Host-based IDS)
Les HIDS[THI_04] sont les tous premier IDS à avoir été développés et implémentés.
Ce système collecte et analyse les données d’un hôte qui offre un service tel que service
web ou base de données. Une fois que les données sont collectées, elles seront analysées
par un agent localement ou elles seront envoyées vers une autre machine dédiée à cette
tâche.
Le HIDS peut être sous la forme d’un programme qui est installé sur un système
d’exploitation afin d’analyser les fichiers logs ou les fichiers des résultats d’audit. Ce pro-
gramme est très efficace contre les différentes attaques connues sur les machines, il est
capable de détecter les « backdoors » et les « rootkits ». Aussi, il est capable de détecter
les modifications interdites des fichiers importants.
Cependant, il ne s’agit pas d’un système idéal. Le HIDS a un grand inconvénient,

il peut être détecté facilement par le « hacker » et il peut lui bloquer la collection des
données, il deviendra alors inutile.
Exemple :
OSSEC-HIDS : Il s’agit un HIDS open-source, il est capable d’analyser les logs, vérifier
l’intégrité des fichiers, détecter les « rootkits » et envoyer des alertes en temps réels.
C’est le HIDS open-source le plus utilisé.
3.2.2.2 Les NIDS (Network-based IDS)

C’est un type d’IDS qui est capable d’écouter sur le réseau, sniffer le trafic et analyser
les paquets. Ces paquets seront examinés par le NIDS[THI_04] et comparés avec des don-
née suspectes pour vérifier s’ils sont malicieux ou bien non. Les NIDS sont responsables
de la sécurité de tout un réseau et non pas d’une seule machine comme le cas d’un HIDS.
Ils sont plus distribués.
Au lieu de collecter les données depuis les machines, les NIDS les collectent depuis les
paquets sniffés sur le réseau. Cette surveillance des connexions entre les terminaux rend
le NIDS efficace en détection des tentatives des intrusions et des accès interdits. Il est
A.U 2015-2016 47
capable de détecter les accès non autorisés dans le réseau.
Comme tout système, le NIDS a ses propres défauts : il ne peut pas sniffer tous les
paquets si le débit du réseau est trop élevé. Aussi, il ne peut pas détecter les intrusions si
les paquets contenant les « payloads » sont très bien chiffrés.
Exemples :
Snort : C’est un NIDS Open-Source, il a été développé par « sourcefire ». C’est le père
des NIDS. Il peut aussi jouer le rôle d’un IPS (Intrusion Prevention system). Il est
le plus utilisé.
Suricata : C’est un NIDS de nouvelle génération, il est moins connu que Snort mais c’est
un jeune rival Il a été développé par « Open Information Security Foundation »
(OISF) .
3.3 Installation et mise en place de Prelude-IDS

3.3.1 Installation de Prelude
Pour commencer l’installation de prélude manager[URL_N10] nous devons tout d’abord
installer les librairies pré-requises pour le bon fonctionnement de Prelude.
3.3.1.1 Libprelude
Avant tout nous installons les pré-requises de Libprelude :libgnutls-dev, python2.7-
dev, libpcre3-dev, swig, pkg-config. Ces paquets sont installés par défaut dans le dépôt
de Ubuntu.
# sudo apt-get install libgnutls-dev python2.7-dev libpcre3-dev swig

pkg-config
Ensuite nous téléchargeons l’archive libprelude à l’aide de l’outil WGET et nous le
compilerons.
# cd /tmp
# wget https://www.prelude-siem.org/attachments/download/351/
libprelude-1.2.5.tar.gz
# tar -xzf libprelude-1.2.5.tar.gz
# cd libprelude-1.2.5
Avant de compiler Libprelude nous devons le configurer.
# ./configure --without-lua –with-python=/usr/bin/python2.7

Il faut vérifier que le support de python est activé.
A.U 2015-2016 48
Figure 3.1 – Configuration de libprelude
Pour lancer l’installation nous exécutons la commande suivante.
# make & make install
3.3.1.2 LibpreludeDb
Tout d’abord nous installerons le paquet de support MySQL.
# sudo apt-get install libmysqlclient-dev
Nous installons libprelude en suivant les étapes ci_dessous .
# cd /tmp
libpreludedb-1.2.5.tar.gz
# tar -xzf libpreludedb-1.2.5.tar.gz
# cd libpreludedb-1.2.5
Afin que le « linker » trouve Prelude, nous configurons la variable d’environnement
concerné comme suit.
# sudo export LD_LIBRARY_PATH=/usr/local/lib
Nous lancerons ensuite la configuration.
# ./configure
Il faut vérifier que le plugin MySQL est activé :
Figure 3.2 – Configuration de libpreludeDb
A.U 2015-2016 49
Ensuite nous lançons l’installation.
# sudo make & make install
3.3.1.3 Base de données Prelude-admin

Prelude a besoin d’une base de données pour y stocker les données des alertes et des
évènements. Nous allons donc créer une base de données avec MySQL.
# mysql -u root -p« password »

mysql> CREATE DATABASE Prelude;
mysql> CREATE USER ’prelude’@’localhost’ IDENTIFIED BY ’OPPASSWORD’;
mysql> GRANT USAGE ON *.* TO ’prelude’@’localhost’;
mysql> GRANT ALL PRIVILEGES ON Prelude.* TO ’prelude’@’localhost’;
mysql> exit;
# mysql -u Prelude -pOPPASSWORD Prelude < /usr/local/share/
libpreludedb/classic/mysql.sql
3.3.1.4 Prelude-Manager
Afin d’activer le module IDMEF(Intrusion Detection Message Exchange Format) nous
devons installer les paquets d’XML et de support de la technique d’emballage TCP.
# sudo apt-get install libxml2-dev libwrap0-dev
Maintenant nous pouvons commencer l’installation de Prelude.
# cd /tmp
prelude-manager-1.2.5.tar.gz
# tar -xzf Prelude-manager-1.2.5.tar.gz
# cd Prelude-manager-1.2.5
# ./configure
Il faut s’assurer que le support libCU est activé.
Figure 3.3 – Configuration de Prelude-manager
Prelude manager est maintenant installé, nous passons à sa configuration.
A.U 2015-2016 50
# sudo nano /usr/local/etc/prelude-manager/prelude-manager.conf
Figure 3.4 – Fichier de configuration de Prelude-manager
Il faut saisir les données de connexion dans la base de données : type (MySQL, Post-
greSQL, Oracle), host (l’adresse IP/ nom de domaine du serveur de base de données),
port (3306 par défaut pour MySQL), Name(nom de la base de données), user( nom de
l’utilisateur de la base de données) et le passe(mot de passe de l’utilisateur).
3.3.1.5 Prelude-Correlator
l’installation de Prelude-correlator se fait par l’outil apt-get.
# sudo apt-get install Prelude-correlator
Nous allons configurer la corrélation avec le démarrage du système.
# sudo nano /etc/default/prelude-correlator
Il faut changer la valeur de la variable « RUN » de «no» en «yes».
3.3.1.6 Prelude-LML
il faut d’abord installer libicu-dev, c’est une librairie pré-requise.
# sudo apt-get install libicu-dev
Puis suivre les étapes suivantes.
A.U 2015-2016 51
# cd /tmp
prelude-lml-1.2.5.tar.gz
# tar -xzf Prelude-lml-1.2.5.tar.gz
# cd Prelude-lml-1.2.5
#./configure
Il faut s’assurer que le support liblCU est bien activé :
Figure 3.5 – Configuration de Prelude-lml
Prelude-lml est maintenant installé avec succès, nous passons à l’ajout de règles pour
cette sonde.
# cd /tmp
prelude-lml-rules-1.2.5.tar.gz
# tar -xzf Prelude-lml-rules-1.2.5.tar.gz
# cd Prelude-lml-rules-1.2.5
# cp -r ruleset /usr/local/etc/prelude-lml/
Il ne reste qu’à configurer Prelude-lml via son fichier de configuration.
# sudo nano /usr/local/etc/prelude-lml/prelude-lml.conf
A.U 2015-2016 52
Figure 3.6 – Fichier de configuration de Prelude-lml
Dans ce fichier, nous indiquons l’adresse IP du serveur et les fichiers log que Prelude-
lml va analyser et superviser.
3.3.1.7 Prewikka
Prewikka est l’interface web de Prelude, il permet de visualiser les évènements et les
alertes. Nous allons maintenant installer et configurer cette interface. Pour garantir le bon
fonctionnement de prewikka nous devons d’abord installer des logiciels prérequis.
# sudo apt-get install python-cheetah python-setuptools python-cairo

python-netaddr gettext
Nous allons commencer l’installation de prewikka, en suivant les étapes ci-dessous.
# cd /tmp
prewikka-1.2.5.tar.gz
# tar -xzf prewikka-1.2.5.tar.gz
# cd prewikka-1.2.5
Puis nous l’installons avec python 2.7 .
# sudo python2.7 setup.py install --record prewikka_files.txt --prefix

/usr/local
Maintenant nous allons configurer la base de données de prewikka.
A.U 2015-2016 53
# mysql -u root -p
mysql> CREATE database prewikka;
mysql> CREATE USER ’prewikka’@’localhost’ IDENTIFIED BY
’prewikkaPassword’;
mysql> GRANT USAGE ON *.* TO ’prewikka’@’localhost’;
mysql> GRANT ALL PRIVILEGES ON prewikka.* TO ’prewikka’@’localhost’;
mysql> GRANT ALL PRIVILEGES ON prewikka.* TO ’prelude’@’localhost’;
mysql> exit;
# mysql -u prewikka -pprewikkaPassword prewikka <
/usr/local/share/prewikka/database/ mysql.sql
Nous allons modifier le fichier de configuration de prewikka avec les coordonnées de la
base de données récemment crées.
# sudo nano /usr/local/etc/prewikka/prewikka.con
Figure 3.7 – Fichier de configuration de prewikka
3.3.2 Installation des agents de surveillance

3.3.2.1 Profil Prelude-Manager
Pour créer un profil Prelude-Manager[URL_N10] , nous allons utiliser la commande
« prelude-admin ». L’« uid » et le « gid » doivent passer en arguments pour pouvoir crée
le profil.
# sudo Prelude-admin add Prelude-manager --uid 0 --gid 0
A.U 2015-2016 54
Figure 3.8 – Ajout d’un profil Prelude-manager
Sondes Prelude-LML
Pour que Prelude enregistre une sonde, il faut exécuter deux commandes en parallèle
comme ci_dessous.
TERMINAL_1
# sudo Prelude-admin registration-server Prelude-manager
TERMINAL_2
# sudo Prelude-admin register Prelude-lml "idmef:rw admin:r" 127.0.0.1

--uid 0 --gid 0
Figure 3.9 – Enregistrement de Prelude-lml
3.3.2.2 Sonde Prelude-Correlator

L’utilisateur Prelude-Correlator a déjà été créé pendant l’installation. Nous aurons
besoin de savoir l’« uid » et le « gid » de l’utilisateur, pour cela on exécute la commande
ci-dessous.
A.U 2015-2016 55
# id Prelude-correlator
Figure 3.10 – l’uid et le gid de Prelude-correlator
Dans notre cas : uid=116 & gid=126. C’est avec ces variables que nous allons pouvoir
installer correctement la sonde Prelude-correlator en suivant les étapes suivantes.
TERMINAL_1
TERMINAL_2
# sudo Prelude-admin register Prelude-correlator "idmef:rw admin:r"

127.0.0.1 --uid 116 --gid 126
La sonde Prelude-correlator est maintenant installée.
3.4 Optimisation de la détection d’intrusion

3.4.1 Utilisation de Prewikka en tant que service
Pour simplifier l’utilisation de prewikka et rendre son démarrage et son arrêt plus fa-
ciles, nous avons utilisé un script « bash » que nous avons trouvé après quelques recherches
sur internet. Ce dernier va transformer prewikka en un service qu’on peut démarrer et
arrêter avec des simples commandes.
# sudo service prewikka start|stop ( restart|status )
Il faut tout d’abord copier le code source du script dans un fichier que nous allons
nommer « prewikka » et l’enregistrer dans le répertoire /etc/init.d/ pour, enfin, lui attri-
buer le droit de l’exécution.
# sudo chmod +x /etc/init.d/prewikka
A.U 2015-2016 56
#!/bin/bash
### BEGIN INIT INFO
# Provides: prewikka
# Required-Start: $local_fs $remote_fs $network $syslog $named
# Required-Stop: $local_fs $remote_fs $network $syslog $named
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Interactive: true
# Short-Description: Prewikka est l’interface officielle de Prelude-IDS
### END INIT INFO
# Variables couleurs
CSI="\033["
CEND="${CSI}0m"
-CGREEN="${CSI}1;32m"
# PID du processus
PID=$(netstat -tlnp | awk ’/:8000 */ {split($NF,a,"/"); print a[1]}’)
# Variable d’environnement PYTHONPATH
export PYTHONPATH=/usr/local/lib/python2.7/dist-packages:
/usr/local/bin/prewikkahttpd
start() {
echo -n "Démarrage de Prewikka by Hexabyte..."
/usr/local/bin/prewikka-httpd &
echo -e " ${CGREEN}[OK]${CEND}" }
stop() {
echo -n "Arrêt de Prewikka by Hexabyte..."
kill -9 $PID
echo -e " ${CGREEN}[OK]${CEND}"
}
status() {
if [[ $PID -gt 0 ]]; then
echo -e "Prewikka est actuellement en service ${CGREEN}[OK]${CEND}"
else echo "Prewikka n’est pas en service..."
fi }
case "$1" in
start
) start;;
stop)
stop ;;
restart
) stop
start ;;
status
) status ;; *)
echo "Utilisation: $0 {start|stop|restart|status}"
exit 1
;;
esac
exit 0
A.U 2015-2016 57
3.4.2 Utilisation de Prelude-manager en tant que service

Dans cette partie nous allons installer un script afin de simplifier le démarrage et l’ar-
rêt de Prelude-manager, tout comme nous avons fait pour prewikka. Commençons par
télécharger le scripte dans le répertoire /etc/init.d/.
# wget https://gist.githubusercontent.com/hardware/92ffda173ed4db68be6f/
raw/89e146a5869b09f53863a13f90f146b5d76a408f/prelude-manager
# sudo chmod +x Prelude-manager
Pour lancer le service Prelude-manager nous lançons la commande suivante.
# sudo service Prelude-manager start
3.4.3 Utilisation de Prelude-lml en tant que service

Dans cette partie nous allons installer un script afin de simplifier le démarrage et
l’arrêt de Prelude-lml, tout comme nous l’avons fait pour prewikka et Prelude-manager.
Commençons par télécharger le scripte dans le répertoire /etc/init.d/.
# wget https://gist.githubusercontent.com/hardware/e21731a31e03721a4633/
raw/72eb18e8da30c8972def826e35f520f5d8926f46/prelude-lml
# sudo chmod +x Prelude-lml
Pour lancer le service Prelude-lml nous lançons la commande suivante.
# sudo service Prelude-lml start
3.4.4 Démarrage de Prelude lors du « boot »

Pour que les services de Prelude se lancent en démarrage du système, nous allons exé-
cuter quelque instruction simple.
# sudo update-rc.d Prelude-manager defaults

# sudo update-rc.d Prelude-lml defaults
# sudo update-rc.d prewikka defaults
3.4.5 Ajout d’une sonde HIDS : OSSEC

Nous avons installé Prelude et ses sondes officielles. Mais nous pouvons encore amélio-
rer ses performances en ajoutant une sonde HIDS. Nous allons donc utiliser OSSEC[URL_N11].
L’installation d’OSSEC est très simple à effectuer. Suivons ces étapes.
# cd /tmp
# wget http://www.ossec.net/files/ossec-hids-2.6.tar.gz
# tar zxvf ossec-hids-2.6.tar.gz
# cd ossec-hids-2.6/src
# make setprelude
# ./install.sh
A.U 2015-2016 58
Après la dernière commande nous serons amenés à saisir quelques informations comme
le montre la figure ci_dessous :
Figure 3.11 – Installation d’OSSEC
Les paramètres de l’installation :

– La langue de l’installation : en
– Le type d’installation : server
– Choix du répertoire d’installation : /etc/ossec.
– Envoi de mail : « no » .C’est possible de la modifier après dans le fichier de confi-
guration (/etc/ossec/etc/ossec.conf).
– Pour le reste on laisse par défaut.
L’installation est terminée, nous passons à la configuration de la sonde via son fichier de
configuration.
# sudo nano /etc/ossec/etc/ossec.conf
Figure 3.12 – Fichier de configuration d’OSSEC
Il ne reste qu’à enregistrer Ossec en tant que sonde HIDS pour Prelude, pour cela il
faut chercher l’« uid » et le « gid » de l’utilisateur « OSSEC » :
A.U 2015-2016 59
Figure 3.13 – ID de l’utilisateur “OSSEC”
Comme tout enregistrement de sonde sous Prelude, nous aurons besoin d’utiliser deux
terminaux :
TERMINAL_1
TERMINAL_2
# sudo Prelude-admin register OSSEC "idmef:rw" 127.0.0.1 - -uid 1001 -
-gid 1001
Nous avons terminé l’installation la sonde Ossec.
3.4.6 Ajout d’une Sonde NIDS : Suricata

Bien que notre plate-forme possède des sondes officielles de Prelude et une sonde HIDS
Ossec, il lui manque encore une sonde NIDS pour la surveillance au niveau du réseau. Pour
cela nous avons choisi d’utiliser Suricata[URL_N12].
En premier lieu, nous allons installer les pré-requis.
#sudo apt-get -y install libpcre3 libpcre3-dbg libpcre3-dev \

build-essential autoconf automake libtool libpcap-dev libnet1-dev \
libyaml-0-2 libyaml-dev zlib1g zlib1g-dev libcap-ng-dev libcap-ng0\ make
libmagic-dev
Ensuite, nous aurons besoin de télécharger la dernière version de Suricata à partir du
site officiel : http ://suricata-ids.org/download/
# tar -xzfv Suricata*
Puis, la configuration du paquet avant la compilation.
# ./configure --enable-prelude --with-libprelude-prefix=/usr/local

--prefix=/usr --sysconfdir=/etc –localstatedir=/var # make && make
install-full
Une fois Suricata installée, nous effectuons le paramétrage de son fichier de configura-
tion, mais avant cela il faut remplacer le fichier de configuration par défaut par le fichier
de configuration dedié aux distributions qui sont basées sur Debian. Ce fichier se trouve
ci-dessous.
https://wiki.zentyal.org/wiki/Suricata-debian.yaml
A.U 2015-2016 60
# sudo nano /etc/suricata/suricata.yaml
Figure 3.14 – Fichier de configuration de Suricata
Enfin, pour lancer Surricata, la commande suivante doit être exécutée.
# sudo suricata -c /etc/suricata/suricata.yaml -i eth0
3.4.7 Gestion des règles de Suricata avec Oinkmaster

Chaque jour, nous découvrons un ensemble de nouvelles attaques. C’est pour cela qu’il
faut mettre à jour les règles des IDS afin de protéger notre réseau. Il est possible d’installer
ces nouvelles règles manuellement mais il existe des méthodes plus faciles et plus rapide
parmi lesquelles “Pulled Pork” et “Oinkmaster”[URL_N13]. Dans notre cas nous allons
opter pour “Oinkmaster”.
Nous commençons par l’installation.
# sudo apt-get install oinkmaster
Oinkmaster doit savoir la source ou il peut extraire les nouvelles règles. Elles se
trouvent ici.
http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz
Nous allons ajouter cette source dans le fichier de configuration d’Oinkmaster.
# sudo nano /etc/oinkmaster.conf
Nous commentons l’URL qui existe déjà et on ajoute la nouvelle source de la façons
ci_dessous.
url = http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz
On sauvegarde le fichier.
Ensuite nous allons créer un dossier afin d’y mettre les nouvelle règles.
A.U 2015-2016 61
# sudo mkdir /etc/suricata/rules

# cd /etc
# sudo oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules
Dans le nouveau dossier des règles, nous devons les déclarer dans le fichier de configu-
ration de Suricata.
# sudo nano /etc/suricata/suricata.yaml
Et nous insérons les lignes ci_dessous.
classification-file: /etc/suricata/rules/classifcation.config
reference-config-file: /etc/suricata/rules/reference.config
Pour vérifier que la nouvelle configuration, on lance cette commande.
# Suricata -c /etc/suricata/suricata.yaml -i eth0
Il est recommandé d’effectuer la mise à jour des règles fréquemment. C’est pour ça
nous avons utiliser l’outil Crontab pour lancer la mise à jour quotidiennement
3.4.8 Mise en place du HoneyPot Kippo

Un HoneyPot[URL_N14] ( Pot de miel ) est un faux service (ou parfois une machine
virtuelle) installé sur une machine dans le but d’attirer l’attention des “hackers” et les
piéger en envoyant leur identité.
Kippo est un HoneyPot SSH. Il va prendre la place du service SSH en l’effectuant

une configuration qui va le rendre non sécurisé. Pour cela nous devons changer le port
de standard du protocole concerné. De cette façon, toute connexion au port 22 sur la
machine protégée sera loggé et analyser ultérieurement par l’administrateur.
Avant de commencer l’installation de Kippo, nous effectuons le changement du numéro

de port du protocole SSH.
# sudo nano /etc/ssh/sshd_config
Il est possible de choisir n’importe quel port, il faut qu’il soit libre. (par exemple 13125).
Commençons l’installation de Kippo.
# sudo apt-get install python-twisted
Il faut créer un utilisateur qui va exploiter le service.
# sudo adduser kippo
A.U 2015-2016 62
Ensuite, télécharger et installer le package de Kippo (version 0.8).
# cd/opt
# wget http://kippo.googlecode.com/files/kippo-0.8.tar.gz
# tar -zxvf kippo-0.8.tar.gz
# sudo chown kippo:kippo kippo-0.8 -Rf
Par défaut Kippo écoute sur le port 2222. Nous allons effectuer une configuration afin
que iptables redirige les flux arrivant sur le port 22 vers le port 2222.
# sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT

--to-port 2222
Il ne reste que de lancer le piège.
# cd Kippo-0.8
# su kippo
# ./start.sh
Il est possible de sécuriser le service SSH en utilisant la technique PortKnocking. Pour
en savoir plus, voir l’annexe A.
3.5 Conclusion
Dans ce chapitre nous avons présenté une brève introduction à la détection d’intrusion
en rappelant ses principes et ses méthodes de fonctionnement suivi par les étapes de
l’installation et de la configuration de prelude et ses sondes.
Figure 3.15 – Liste des Sondes Actives
Dans ce qui suit nous allons entamer le dernier chapitre qui sera consacré pour la
présentation de la solution finale suivis par des tests d’intrusion.
A.U 2015-2016 63
Chapitre 4
Exploitation et tests
4.1 Introduction
Dans ce présent chapitre, une brève démonstration de la solution finale sera présentée
afin de montrer comment les logiciels installés ont été exploités et tester les performances
du système de détection d’intrusion (IDS).
4.2 Tests d’intrusion : Pentest

4.2.1 Méthodologies
Il existe deux principaux idéologies de test de pénétration : “Black Box Testing” et
“White Box Testing”.
Black box testing

La société qui contracte une équipe de test de pénétration n’offre pas d’informations.
Ce test est semblable à un boxeur confronté à un adversaire dont il ne connait rien. Ces
deux boxeurs doivent apprendre à se connaitre pendant le combat. Pour ce faire, ils com-
menceront par se tourner autour, pour connaitre les faiblesses de l’autre. Le combat peut
progresser lentement étant donné que chacun d’eux rassemble des informations sur son
adversaire pendant la rencontre. De même, Dans ce test, toutes les informations que les
testeurs détiennent sont des informations collectées par eux-mêmes. Ce type de test s’ap-
parente à une véritable attaque de pirates. Cela pourrait être utile si la société voulait
savoir quels sont les informations qu’un “hacker” pouvait collecter sur elle.
White box testing

Ce type de test est à l’autre bout du spectre. Contrairement au boxeur qui ne sait rien
de son adversaire, dans ce scénario le boxeur a bien préparé son combat. Il a visualisé les
matches de son adversaire. Il a cherché ses faiblesses pour qu’il puisse les exploiter. Le
“white box testing” est similaire à cette approche. Ici l’équipe de test de pénétration peut
accéder aux codes source et à toutes les autres informations que la société peut lui offrir.
Ce type de test est utile car les testeurs peuvent trouver et exploiter les vulnérabilités sans
avoir à chercher l’information d’abord. Bien qu’il soit couteux, ce test peut faire gagner de
l’argent à l’entreprise en permettant à l’équipe d’audit de se concentrer sur la détection et
64
CHAPITRE 4. EXPLOITATION ET TESTS
l’exploitation des vulnérabilités sans perdre beaucoup de temps dans la phase de collecte
d’informations.
Ce que nous allons faire c’est de tester quelques méthodes d’attaques les plus connus
et voir comment l’IDS va réagir.
4.2.2 Plateforme de test d’intrusion

Afin de tester l’IDS nous avons réalisé quelques attaques dans un réseau virtuelle en
utilisant le logiciel “Oracle VM VirtualBox”.
Dans la machine serveur qui est représenté dans la figure qui suit, nous avons installé
les sondes mentionnées dans le chapitre précédent. Une application web vulnérable à été
hébergé sur le serveur. Il s’agit de DVWA(Damn Vulnerable Web App), c’est application
web écrite avec PHP/MySQL qui contient des failles de sécurité. Elle a comme objectif
de permettre aux professionnels de tester leurs compétences en matière de détection et
d’exploitation des vulnérabilités.
Dans un scénario de test que nous allons provoquer ultérieurement, une machine vir-
tuelle sera installée et ajoutée dans le réseau afin de jouer le rôle d’une machine Linux
vulnérables à un ensemble d’attaques. Nous y installerons un OS dédié pour cette tâche
particulière connu sous le nom de “ Exploitable”.
Figure 4.1 – Machines VirtualBox
A.U 2015-2016 65
Figure 4.2 – Réseau de teste
4.2.3 Simulations d’attaques

Dans ce qui suit nous allons montrer les scénarios que nous avons réalisé.
En premier lieu, nous allons lancer une simple commande “traceroute”. il n’y a pas une
méthode plus simple que celle-ci afin de commencer le collecte des informations à propos
du réseau.
Figure 4.3 – Commande traceroute
Comme le montre la figure 4.4, nous avons utiliser l’outil “Httrack”. Cet outil permet
de copier tout le contenue d’un site web ciblé dans la machine du “hacker” afin qu’il puisse
analyser, scanner l’application sans qu’il soit détecté.
A.U 2015-2016 66
Figure 4.4 – Scénario Httrack
Puis nous allons Utiliser l’outil Zenmap afin de scanner le serveur. Zenmap est l’inter-
face graphique du fameux Nmap. La commande Nmap executé dans la figure 4.5 permet
de verifier l’etat de tous les ports TCP( 1-65535 ). Cet étape est trés critique, c’est la oû
le “hacker” aura une vision plus claire sur l’état de la machine ciblée et sur les services
qu’elle offre.
Figure 4.5 – scénario Zenmap
A.U 2015-2016 67
Dans la figure 4.6, une liste des techniques d’attaque disponibles sur l’outil Ettercap.
Figure 4.6 – Ettercap attaques
À l’aide d’Ettercap nous avons simulé une attaque de type “Man in the middle”. Cette
technique consiste à effectuer un sniff de trafic entre deux terminaux choisis. Cela permet
de capturer les données et même de les modifiées.
Figure 4.7 – scénario ARP poisoning
Pour terminer, nous avons utiliser Armitage pour Scanner le serveur. Armitage est
l’interface graphique de l’outil “ Metasploit ”.
A.U 2015-2016 68
Figure 4.8 – Scénario Armitage
4.2.4 Alertes
Nous allons maintenant voir les notifications et les alertes qui ont été causées par les
scénarios d’attaque cités dans la partie précedente.
Comme le montre la figure 4.9, Suricata à bien été en garde afin de détecter les attaques
web que le serveur Ubuntu à subit.
A.U 2015-2016 69
Figure 4.9 – Alerte : service web attaqué
Dans la figure 4.10, un ensemble d’alertes et de notifications, nous en citons :

“Promiscious mode detected” : L’IDS a détecté une machine qui a activé le mode
écoute du trafic dans un des ses interfaces.
“SSHD authentification failed” : une personne à essayé de se connecter au serveur via
SSH mais il n’a pas réussi. Si cela se répète encore, ça peut générer une alerte de niveau
plus élevé.
Figure 4.10 – Notifications de niveau bas
Les alertes qui sont affichées dans la figure 4.11 ont été enclenché après un scanne fait
A.U 2015-2016 70
par Nmap.
Figure 4.11 – Scanne NMAP détecté
Dans la figure 4.12, nous pouvons voir les alertes enclenchées après une attaque effectué
à l’aide de metasploit.
Figure 4.12 – Scanne détecté
Un exemple d’une fausse alerte est affiché dans la figure 4.13. Les resultats de détection
d’intrusion ne sont pas toujours fiables.
A.U 2015-2016 71
Figure 4.13 – Fausse alerte
4.3 Interpretation des statistiques

L’effort de Prewikka ne s’arrête pas à la visualisation des alertes, il peut aussi générer
des graphes de statistiques.
Ci-dessous un exemple de graphe. Ce dernier affiche le taux des alertes classées par
niveau d’urgence sur un échelle temporel.
Figure 4.14 – Prewikka : Graphe 1
Dans ce qui suit un graphe qui représente les alertes les plus rencontrées sur un échelle
temporel.
A.U 2015-2016 72
Les pourcentages des notifications classées par leurs descriptions sont affichées dans le
graphe qui se trouve dans la figure 4.16.
Ensuite, un graphe qui montre le taux des notification classées par leurs groupes de
référence se trouve dans la figure ci-dessous.
A.U 2015-2016 73
La figure 4.18 présente le taux des notifications groupés par niveau d’importance.
La figure 4.18 présente les utilisateurs qui ont été ciblés en mentionnant le nombres
d’attaques qu’ils ont subis.
A.U 2015-2016 74
Dans le figure suivante, les taux des adresses IP qui ont été derrière l’enclenchement
de l’alerte.
Nous avons aussi la possibilité de surveiller les performances des sondes connectées à
prelude via le graphe présenté dans la figure suivante.
4.4 Hexadef
Afin d’utiliser les outils que nous avons mise en place dans le réseau, l’administrateur
doit consulter plusieurs interfaces : Prewikka (interface web de prelude), Zabbix frontend
(interface web de zabbix), nessus et Graylog. Dans l’intention de rendre l’accès à ces
interfaces plus facile, nous avons développé une application web qui regroupe ces quatre
interfaces en une seule. Nous l’avons intitulé « HexaDef » ; “Hexa” comme “Hexabyte”
et “Def” comme “Defender”.
A.U 2015-2016 75
Figure 4.22 – Interface Hexadef
A.U 2015-2016 76
Conclusion général
Notre projet de fin d’étude a eu pour objectif l’installation, la configuration et la mise

en place d’un outil de supervision réseau et d’un autre de détection d’intrusion réseau.
Pour atteindre le but fixé, nous avons d’abord commencé par récolter des informations
sur le réseau de l’entreprise et sur les outils Open d’administration réseau et de détection
d’intrusions réseau. Ensuite, une étude comparative entre les nombreux outils open source
a été menée et nous a permis de faire notre choix. Nous avons en effet choisi d’installé
Zabbix en tant que logiciel de supervision principal suivi par des configurations avancées.
Pour ce qui est du choix d’une solution IDS, nous nous sommes tournés vers Prelude-
IDS et ses sondes. Nous sommes, juste après, passés à l’installation et à la configuration
de ces différentes solutions. Pour finir, Un ensemble de tests d’intrusion a été réalisé afin
de déterminer les performances de la plateforme de détection d’intrusion ; nous avons pré-
senté un ensemble des statistiques que Prelude peut générer suivi par l’application web
que nous avons commencé à développer.
Nous avons, à travers ce stage, découvert le domaine de la supervision et de la détection

d’intrusion réseaux et systèmes. Ce projet nous a également permis d’appliquer et d’amé-
liorer nos connaissances du domaine de l’administration réseau et la sécurité informatique.
En perspective, bien que notre projet ait satisfait les besoins de l’organisme d’accueil,
des améliorations vont être ajoutées pour élargir la supervision et la surveillance du réseau
et des systèmes mises en question.
A.U 2015-2016 77
Bibliographie
[URL_N1] WorkAroud, URL : https ://workaround.org/article/tired-of-nagios-and-cacti-

try-zabbix [ dernière consultation : 10/05/2016]
[AND_13] Andrea Dalle Vacche , Stefano Kewan Lee « Master Zabbix », packt publi-
shing, 2013, ISBN : 9781783283491, 337
[URL_N2] ReadTheDocs, URL https ://shinken.readthedocs.io/en/latest/ [ dernière
consultation : 25/05/2016 ]
[URL_N3] AlienVault, URL :
https ://www.alienvault.com/docs/whitepapers/OSSIM_vs_Commercial_White_Paper.pdf
[URL_N4] MonitoringFR, URL : http ://wiki.monitoring-fr.org/zabbix/start#ii-installation
[ dernière consultation : 25/05/2016 ]
[THI_04] Thierry Evangelista « IDS : Les systèmes de détection des intrusions infor-
matiques », InfoPro, 2004, ISBN : 9782100072576, 261
[URL_N5] TheDutchLab, URL : https ://thedutchlab.com/blog/installing-zabbix-on-
ubuntu-1404 [ dernière consultation : 25/05/2016 ]
[URL_N6] TecMint, URL : http ://www.tecmint.com/install-zabbix-agent-and-add-windows-
host-to-zabbix-monioring/ [ dernièreconsultation : 25/05/2016 ]
[URL_N7] DigitalOcean, URL : https ://www.digitalocean.com/community/tutorials/how-
to-create-a-ssl-certificate-on-apache-for-ubuntu-14-04 [ dernière consultation : 25/05/2016
]
[URL_N8] 2DayGeek, URL : http ://www.2daygeek.com/zabbix-upgrade-from-2-4-x-
to-3-0-network-monitoring-tool-on-centos-rhel-debian-mint-ubuntu/ [ dernière consul-
tation : 20/05/2016 ]
[URL_N9] DigitalOcean, URL : https ://www.digitalocean.com/community/tutorials/how-
to-install-graylog2-and-centralize-logs-on-ubuntu-14-04 [ dernière consultation : 24/05/2016
]
[URL_N10] Prelude-Siem, URL : https ://www.prelude-siem.org/projects/prelude/wiki
[URL_N11] ReadTheDocs, URL : http ://ossec-docs.readthedocs.io/en/latest/index.html
[URL_N12] OpenInfoSecFoundation, URL :
https ://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Installation
[URL_N13] WZDFTPD, URL : https ://www.wzdftpd.net/blog/installing-suricata-with-
oinkmaster-on-debian.html [ dernière consultation : 22/05/2016 ]
78
[URL_N14] IT-Connect, URL :

http ://www.it-connect.fr/honey-pot-ssh-avec-kippo/#III_Test_et_visualisation_des_logs
A.U 2015-2016 79
Annexe A
Principe
Port-Knocking est une méthode qui permette une communication machine à machine
dans laquelle les informations passent à travers des ports qui apparaissent à la première
vue fermés. Pour avoir accès à un port spécifique, il faut d’abord saisir une séquence de
connexions précise. L’utilisateur doit atteindre différents ports distincts dans un ordre
bien précis afin d’ouvrir le port voulu. Les ports sont fermer par un pare-feu tant que la
séquence Knock-Port n’a pas été effectué.
Dans le cas d’un scanne des ports sur un serveur, touts les ports apparaissent fermés
bien que le service qui fonctionne sur ce port soit en actif. C’est le pare-feu qui effectue
un rejet (DROP).
Prenons l’exemple du service SSH qui écoute sur le port 22 sachant que nous l’avons
attribué la séquence de knock-port suivante : 2212 → 2213 → 2214.
Si une personne se connecte au serveur via ssh sans avoir saisi la séquence effectué, le
port 22 restera fermé et l’événement sera loggé.
Si un utilisateur a bien saisie la séquence , le port 22 s’ouvrera pour une durée de

temps limitée . . . les logs générés suite à ces événements peuvent être exploités par les
outils de supervision et de détection d’intrusion.
Installation et configuration de Knockd

Commençons l’installation.
# sudo apt-get install konckd

# sudo nano /etc/knockd.conf
80
Figure 4.23 – Fichier de configuration de Knockd
Knockd utilise le pare-feu Iptable. Ce dernier est disponible par défaut dans la majorité
des distribution linux.
Afin de lancer le service Knockd automatiquement au démarrage du système il faut
modifier la valeur : START_KNOCKD=1.
# nano /etc/default/knockd
Figure 4.24 – Fichier de configuration du lancement automatique de Knockd
Le lancement du service se fait par l’exécution de la commande suivante.
# sudo service knockd start
Une démonstration de demande de connexion directe au port 22 est présentée ci-

dessous.
A.U 2015-2016 81
Figure 4.25 – Connexion au serveur via PuTTY
Le scénario des connexions n’a pas été respecté, ce qui résulte à l’erreur affiché dans
la figure suivante.
Figure 4.26 – Connexion refusé
Dans l’exemple suivant, nous allons suivre les règles d’accès que Knockd propose.
Figure 4.27 – Scénario d’accès SSH
Après la réalisation de ce scenario nous nous connectons au port 22.
A.U 2015-2016 82
Figure 4.28 – Connexion etablie
Comme c’est affiché dans la figure précédente la connexion s’est établie avec succès .
Remarque
Cela dit cette technique n’est pas pratique avec les services publiques tel que le web.
Par contre elle est utilisable avec les services ftp, ssh et telnet.
A.U 2015-2016 83

Pdfsammerge 161005214942

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pdfsammerge 161005214942

Transféré par

Droits d'auteur :

Formats disponibles

République Tunisienne

Ministère de l’Enseignement Supérieur,

Rapport de Projet de Fin d'Etudes

Mise en place d'une Plateforme de

Présenté devant le jury composé de:

Nos remerciements s’adressent également à M.Mohamed Ould Lhassan, qui a veillé au

Tous nos remerciements vont également à l’encadrant de la société M.Rached Ben

_____________________Alâa Eddine Tlich & Nabil Kherfani

1 Présentation générale du projet 11

2.4.1.1 Sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1.1 Organigramme d’Hexabyte . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Liste des scripts développés . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1 Configuration de libprelude . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1 Machines VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.5 scénario Zenmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

1.1 liste des serveurs et leurs services . . . . . . . . . . . . . . . . . . . . . . . 13

IDS : Intrusion Detection System

Le second chapitre sera dédié à la supervision. Il aura pour objectif de rappeler le

d’optimiser la supervision et la sécurité du réseau.

Présentation générale du projet

1.2 Organisme d’accueil

La société dispose des différentes autorisations suivantes :

– Autorisation triennale d’exercice de l’activité de Fournisseur de Service Internet «

La société est gérée par un jeune Directeur Général en la personne de M. Naceur

De retour à Tunis, M. Hidoussi s’est occupé d’HEXABYTE, société qu’il a fondée

– Internet Dial up : connexion via une ligne téléphonique au réseau Internet,

Figure 1.1 – Organigramme d’Hexabyte

1.2.2 Composants du réseau

Table 1.1 – liste des serveurs et leurs services

1.3 Cadre général

1.3.1 État de l’art

– La Cybercriminalité : il s’agit de pirater un système informatique en but de détruire

Figure 1.2 – les motivations des attaques informatiques

En Tunisie, L’ANSI (Agence Nationale de la Sécurité Informatique) a réalisé une étude

Figure 1.3 – Évolution du nombre d’événements détectés par l’ANSI en 2015

« Géographiquement, la majorité des adresses IP sources d’évènements est issue de la

Figure 1.4 – Répartition IP par continent en 2015

1.3.1.2 Principales attaques et menaces

Figure 1.5 – Les techniques de piratage les plus utilisées

d’assurer la détection d’intrusion assez efficace.

1.3.3 Travail à faire

– La mesure de performance, en termes de temps de réponse.

1.4 Étude Comparative des solutions Open-Source

1.4.1.1 Présentation des solutions

Il se décompose en trois parties :

– Le moteur de l’application qui s’occupe de l’ordonnancement des tâches de super-

Il possède plusieurs fonctionnalités, nous en citons quelques unes :

Zabbix[AND_13] est un logiciel open source de supervision des réseaux développée en

– Zabbix Server, c’est le composant principal. Il s’occupe de la supervision distance

Ces principales fonctionnalités :

– Récolte des informations Via SNMP, tests services et agents Zabbix .

– Mêmes fonctionnalités que Nagios .

En dessous, un schéma qui explique la relation entre Nagios et centreon :

Figure 1.6 – Architecture de Centreon et sa relation avec Nagios

Shinken[URL_N2] est un système de supervision open source, il s’agit du cœur de Nagios

Figure 1.7 – Architecture de Shinken

1.4.1.2 Récapitulatif des outils de supervision

Table 1.2 – Tableau comparatif des outils de supervision

1.4.1.3 Choix de la solution adoptée

1.4.2 Outils de détection d’intrusion

1.4.2.1 Présentation des solutions

– URL : https ://www.snort.org/downloads

Il joue cinq principaux rôles :