1

Epigraphe

Toutes choses sont bonnes ou mauvais par la

comparaison
 2

DEDICACE

Je dédie ce travail à toute la communauté scientifique dans le domaine de sciences informatiques,

particulièrement au département réseau et télécommunication.
 3

REMERCIEMENT

Au terme de nos études Universitaires de 3em bachelier en Informatique de réseau et

télécommunication, qu'il nous soit permis d'exprimer nos sentiments de gratitude à notre Dieu tout
puissant et aux différentes personnes qui nous ont encadrées et soutenues tout au long de notre
formation, rendant ainsi possible l'accomplissement du présent travail. Notre gratitude s'adresse
tout particulièrement au professeur Blaise FYAMA, qui en dépit de ses multiples occupations et
sollicitations a accepté de diriger ce travail. Notre reconnaissance va aussi tout droit à l'assistant
Freddy KADIATA, qui a accepté de lire et porter des correctifs à ce travail. Mais aussi l'assistant
Alain KANKU, pour ses conseils et suggestions éclairés, qui nous ont été utiles pour l'élaboration
de ce travail. Nous nous sentons également redevable à l'égard de tous les Professeurs et Assistants
de l’université protestante de Lubumbashi et ceux de la faculté d’Informatique en particulier, pour
le savoir qu'ils nous ont transmis. Qu'ils trouvent à travers ce travail le fruit de leur encadrement.
J’adresse mes sincères remerciements à mes parents, Sébastien NKULU NGOY et Marie claire
MAJONDO, qui ses dépassaient malgré les difficultés économiques d'assurer notre formation, et
pour l'amour témoigné à mon égard, Je serai ingrat si je vous abandonne. Mes remerciements les
plus chaleureux au : Au couple Nemerlin MWAMBA et Joëlle BALOMBANE, Pasteur Iréné
ILUNGA et Chantale KAMIN, Théophile UMPAFU et Fifi, Jeff YUMBA et Falonne, Jean Mari
KYUNGU et Anne Marie NGOIE WA NGOIE, pour les efforts, les encouragements, les soutiens
tant morale, financiers que spirituel qui ne nous ont jamais fait défaut et leur confiance en notre
humble personnalité ; Que Dieu vous comble sa grâce. À mes très chers frères et sœurs, Tresor
MWEPU, Ernestine MWEPU, Narcisse TSHINYAMA, Ruth KABAMBA WA ILUNGA,
Cherrubin, Fayol UMPAFU, pour tant d'affections, des sacrifices et d'efforts consentis en ma
faveur. Sans oublier mes compagnons de lutte et amis Narcisse TSHINYAMA, Silas MUKENDI,
Delphin NYEMBO, Delville KIBUNDULU, Emmanuel MATALA, Nasaire… Je tiens à
remercier et à témoigner toute ma reconnaissance à tous ceux qui nous ont soutenus de près ou de
loin durant la période de notre formation.
 4

Liste de figures
Figure 1 Fonctionnement du SNMP ........................................................................................................... 15
Figure 2 Structure d'un système d'administration ....................................................................................... 16
Figure 3 représentation de l'architecture netflow ....................................................................................... 18
Figure 4 Interface d'accueil PRTG ............................................................................................................. 20
Figure 1Diagramme de cas d'utilisation SNMP ......................................................................................... 28
Figure 2 Diagramme de séquence SNMP................................................................................................... 29
Figure 3 diagramme de séquence gérer réseau ........................................................................................... 30
Figure 4 Mode de fonctionnement du protocole syslog ............................................................................. 31
Figure 5 Structure du protocole syslog ....................................................................................................... 32
Figure 6 Diagramme de cas d’utilisation Syslog ....................................................................................... 33
Figure 7 Diagramme de séquence syslog ................................................................................................... 33
Figure 1 exemple de logs sur un serveur syslog ......................................................................................... 36
Figure 2 fonctionnement du SNMP ............................................................................................................ 40
Figure 1 Gestion de la configuration .......................................................................................................... 46
Figure 2 Gestion des fautes ........................................................................................................................ 47
Figure 3 Gestion de performance ............................................................................................................... 48
Figure 4 Gestion de la comptabilité ............................................................................................................ 50
Figure 5 Gestion de la sécurité ................................................................................................................... 51
 5

Liste de tableaux
Tableau 1 Comparaison des outils de supervision...................................................................................... 21
Tableau 1 Format de requête ...................................................................................................................... 25
Tableau 2 message de gravité ..................................................................................................................... 34
Tableau 1 Etude comparative de SYSLOG et SNMP ................................................................................ 43
 6

Liste des abréviations

CMIP : Common Management Information Protocol) et le

SNMP : Simple Network Management Protocol

CMIS : Common Management Information Service

IETF : Internet Engineering Task Force

NMS : Network Management Stations

NE : Network Elements

MIB : Management Information Base

SSH : Secured Shell

HSRP : Hot Standby Routing Protocol

ISO : International Organization for Standardization

PDU : Protocole Data Unit

ASN.1 : Abstract Syntax Notation 1

OID : Object Identifier

N2TR : Nouvelles Technologies des Télécommunications et Réseaux

UML Unified Modeling Language

ISO : International standard organization

UP : Unified Process
 7

INTRODUCTION GENERALE
En effet, la supervision, dénommée aussi surveillance informatique où monitoring, est le
procédé qui consiste à Contrôler et Vérifier, l’activité d’un système informatique.
Les principales solutions de supervision s’intègrent dans l’activité quotidienne informatique et
permettent de surveiller, analyser, piloter en agissant directement après avoir reçu des alertes
informant des potentielles anomalies. Ces alertes peuvent être remontées via des scripts, des mails,
des fax, des appels vocaux où bien par l’envoi de simple SMS d’alerte. [1]
Ainsi donc, La supervision informatique permet de mettre en avant, les anomalies
éventuelles du système d’information de l’entreprise, en alertant et en alarmant dès la connaissance
du souci, l’opérateur concerné pourra intervenir à distance et réparer si besoin l’anomalie
constatée. [1]
C’est dans ce cadre que nous avons intitulé notre travail « étude fonctionnelle et
comparative des protocoles de supervision et leurs impacts dans un réseau d’entreprise » il
s’agit des protocoles SNMP et SYSLOG, Nous avons constaté sur les réseaux physiques que des
nombreux composants sont donc à surveiller : l’utilisation de la largeur de bande, l'état de
fonctionnement des liens, les éventuels goulets d'étranglement, les problèmes de câblage, le bon
cheminement de l'information entre les machines, mais que faut-il faire pour choisir le protocole
permettant de surveiller ces équipements, car chaque protocole fonctionnement selon une norme
préétablie voilà pourquoi nous avons choisi ce sujet pour étudier et comparer ces protocoles de
supervisons SNMP et SYSLOG.
Dans ce travail nous poursuivons à faire une étude approfondie sur le fonctionnement des
protocoles de supervision cité ci-haut afin d’en trouver quel est le meilleur que nous pouvons
proposer dans la supervision d’un réseau d’entreprise. Nous avons ajouté un plus grâce à cette
recherche par l’explication de plusieurs méthodes de gestion de réseau, cette étude comparative va
permettre aux scientifiques de trouver solution aux problèmes qui ronge les réseaux du point de
vue l'analyse des fichiers logs où journaux se trouvant sur des nœuds réseaux.

Nous ne sommes pas le premier à parler sur ce thème, ce qui nous a poussé à recourir quelques
travaux dont :

 ABIR TRABELSI de l’université virtuelle de Tunis dans son rapport du projet de fin d’études
pour l’obtention du diplôme de master professionnel en nouvelles technologies des
 8

télécommunications et réseaux (N2TR) en 2015 : « mise en place d’un outil de supervision

système et réseau open source ».
Dans son cas, il avait envisagé de mettre en place une console d’administration réseau pour la
société tunisienne de sidérurgie. Cette console permettait de superviser et de contrôler l’état des
équipements informatiques. [5]
 HIEN K. RODRIGUE ROMARIC de l’université de POLYTECHNIQUE DE BOBO
DJOULASSO (U.P.B) en 2010, dans son mémoire de fin de cycle « étude et proposition d'une
solution de supervision réseau base sur le logiciel libre Nagios » il avait comme problème : Le
parc infonuagique de la CARFO compte près d'une centaine d'ordinateurs tous connecté sur le
réseau et est en pleine croissance. Ainsi, pour mieux gérer ce parc et être efficace dans les
interventions pour la résolution de problèmes, il a mis en place une solution de supervision basée
sur le logiciel NAGIOS en configurant le protocole SNMP. [2]
La démarcation de notre travail et nos prédécesseurs se base du point de vues objectifs poursuivis
dans le travail, à ce qui nous concerne, il s’agira de l’étude de fonctionnement de deux protocoles de
supervisions et leurs avantages dans le réseau d’entreprise, après comparaison nous proposerons le
meilleur protocole à implémenter dans un réseau
Pour ce faire différents points stratégiques sont à observer comme les routeurs, les concentrateurs, les
liens, les postes, les imprimantes. Ainsi, en cas de panne ou de mauvais fonctionnement sur le réseau,
l'administrateur doit pouvoir interpréter l'information reçue pour identifier la source du problème.
Plusieurs protocoles de gestion sont nécessaires pour exercer les fonctions de gestion sur un réseau.
Par conséquent si l’administrateur n’est capable de dialoguer avec tous les éléments du réseau, les
protocoles de supervisions ont était mise en place pour répondre à ces besoins.
C’est ainsi que chaque administrateur utilise une méthode voulu pour superviser les réseaux et
ces méthodes ou ces politiques de supervision dépendent d’un protocole à l’autre, comme le protocole
SNMP et SYSLOG qui proposent des politiques différente du point de vues :
 L'analyse des fichiers logs ou journaux,
 L'exécution et la récupération des résultats des commandes réseaux et des scripts locaux ou
distantes,
 Interroger un agent installé sur chaque équipement,
 Recevoir les alertes émises par les équipements,
C’est qui nous renvoie à nous poser les questions suivantes :

 Quelle démarche méthodologique peut-on utiliser pour analyser et comparer les protocoles
SNMP et SYSLOG ?
 Quel est l’impact de ces normes SNMP et SYSLOG dans un réseau d’entreprise ?
 9

Pour répondre aux questions précédemment posées :

Nous allons recourir à la démarche UP faisant recours au langage de modélisation unifié (UML)
qui vas nous aider d’analyser les différents scénarios du fonctionnement des protocoles SNMP et
SYSLOG. Partant de l’expression de besoins jusqu’à l’analyse.

Les protocoles de supervision ont un impact positif dans le réseau comme Gestion des
performances, Gestion des configurations, Gestion de la comptabilité, Gestion des anomalies,
Gestion de la sécurité, Structure de gestion des réseaux.

Nous avons fait recours aux techniques suivantes : La technique d’administration

système et réseau : elle est celle qui assure le bon fonctionnement du système informatique d’une
entreprise, la mise en place des nouveaux matériels et des logiciels, les politiques de sécurité à
faire appliquer, la surveillance de l’infrastructure réseau et la gestion quotidienne du système
d’information. [8]
La technique de modélisation : notre choix s’est porté sur le langage UML (Unified Modeling
Language) où langage de modélisation unifié. UML est avant tout un support de communication
performant, qui facilite la représentation et la compréhension de solutions. Sa notation graphique
permet d'exprimer visuellement une solution, ce qui facilite la comparaison et l'évaluation de
solutions. [9] Dans notre travail nous avons pris le cas de la norme SNMP et SYSLOG.
Vu la grandeur du sujet que nous abordons, notre travail sera subdivisé en 4 chapitres hormis
l'introduction et la conclusion générale :

 GENERALITE SUR LA SUPERVISION : Dans le premier chapitre nous avons parlé

de la généralité sur la supervision réseau et des quelques définitions sur des concepts
fondamentaux, les principes et l'objectif de la supervision, les protocoles des supervisions
et leurs avantages ;
 ANALYSE FONCTIONNELLE DES PROTOCOLES SNMP ET SYSLOG : Dans le
deuxième chapitre nous avons étudié les fonctionnements c'est-à-dire leurs principes
d'utilisation dans l'administration réseau.
 ETUDE COMPARATIVE DES PROTOCOLES DE SUPERVISION SNMP ET
SYSLOG : Dans le troisième chapitre nous avons comparé les deux protocoles du point
de vue gestion des logs, interrogations des nœuds réseaux et définition des alertes sur les
événements, et sur les équipements.
 IMPACTS DE PROTOCOLES SNMP ET SYSLOG : Dans le quatrième chapitre Nous
avons présenté le résultat entre les deux protocoles et leurs avantages dans le réseau
d’entreprisse.
 10

CHAPITRE I. GENERALITE SUR LA SUPERVISION RESEAU

I.1 Introduction partielle
Dans ce chapitre il sera question pour nous de parler sur le concept de base sur la supervision
réseau, les notions sur l’administration réseau, les protocoles d’administration réseau. Ainsi que
les outils de supervision et leur comparaison.

I.2. La supervision
On supervise pour avoir une visibilité sur le système d'information. Cela permet d'avoir
des informations rapidement, de connaître l’état de santé du réseau, des systèmes, des
performances. Donc on a rapidement une image de notre système. Superviser permet aussi de
prévenir les pannes et d’anticiper les pannes. En effet on obtient une alerte quand un disque dur
atteint 80% de sa capacité. On peut donc éviter un crash du système à cause d'un disque dur plein.
Grâce à un outil de supervision, on peut aussi remonter les informations d’IDS et fournir des
indicateurs au DSI. Cela centralise les informations remontées par divers outils.

I.2.1. Objectif de la supervision

Les objectifs de l’administration des réseaux pour l’administrateur sont :

 Supervision du fonctionnement des réseaux

 Optimisation pour l’utilisation des ressources.
 Détection et prévision des erreurs.
 Signalisation des pannes.
 Calculs statistiques.
 Calculs de facturations à l’utilisation des ressources.
 Le support technique pour utilisateurs (help desk).
I.2.2. Principe de la supervision
La supervision se définit comme une technique utilisant au mieux les ressources
informatiques pour obtenir des informations sur l'état des réseaux et de leurs composants. Ces
données seront ensuite traitées et affichées afin de mettre ma lumière sur d'éventuels problèmes.
La supervision peut résoudre les problèmes automatiquement ou dans le cas contraire prévenir via
un système d'alerte (email ou SMS par exemple) les administrateurs. Cette définition de la
supervision est décrite plus en détail dans la norme ISO7498/4. Plusieurs actions sont ainsi
réalisées : Acquisition de données, analyse, puis visualisation et réaction.
Un tel processus est réalisé à plusieurs niveaux d'un parc de machines : Au niveau interconnexions
(Réseau), au niveau de la machine elle-même (Système) et au niveau des services offerts par cette
machine (Applications).
 11

I.3. Les types de supervision en informatique

I.3.1. Supervision système
La surveillance se cantonne dans ce cas à la machine elle-même et en particulier ses
ressources. Si l'on souhaite par exemple contrôler la mémoire utilisée où la charge processeur sur
le serveur voire l’analyser les fichiers de logs système.

La supervision système porte principalement sur les trois types principaux de ressources système
:

• Le processeur ;

• La mémoire ;

• Le stockage.

• Commutateurs : utilisation des ressources, métrologie.

• Serveurs : utilisation des ressources.

I.3.2. Supervision des applications

Cette technique est plus subtile, c'est elle qui va nous permettre de vérifier le
fonctionnement d'une application lancée sur une machine. Cela peut être par exemple une tentative
de connexion sur le port de l'application pour voir si elle retourne ou demande bien les bonnes
informations, mais aussi de l'analyse de logs applicatifs.

La supervision des applications (où supervision applicative) permet de connaître la

disponibilité des machines en termes de services rendus en testant les applications hébergées par
les serveurs. À titre d'exemple, un serveur web peut avoir une supervision système et réseau avec
des signaux au vert, et la machine ne sera pourtant pas disponible au sens du service web si apache
n'est pas présent ou n'est pas en mesure de servir des pages web.

La supervision applicative passe donc par des mesures faites aussi sur le flux de service.
On parle alors de validation fonctionnelle. On utilise souvent un sous-ensemble des tests ayant
permis la recette d'une application pour n'en prendre que les tests qui sont représentatifs de
l'activité sans pour autant générer une charge trop importante où modifier les données applicatives.
La supervision applicative ne peut se faire sans considérer la sécurité applicative.

I.3.3. Supervision Réseau

Par le terme réseau on entend ici l'aspect communication entre les machines. Le rôle est de
s'assurer du bon fonctionnement des communications et de la performance des liens (débit, latence,
taux d'erreurs). C'est dans ce cadre que l'on va vérifier par exemple si une adresse IP est toujours
 12

joignable, ou si tel port est ouvert sur telle machine, ou faire des statistiques sur la latence du lien
réseau.

La supervision réseau porte sur la surveillance de manière continue de la disponibilité des

services en ligne, du fonctionnement, des débits, de la sécurité mais également du contrôle des
flux. Elle comprend un ensemble de protocoles, matériels et logiciels informatiques permettant de
suivre à distance l'activité d’un réseau informatique. Ces solutions permettent également de
cartographier le réseau. La supervision permet la surveillance de l'état de santé des systèmes
d'informations. Elle permet aux administrateurs d'effectuer les actions suivantes sur le SI :

La supervision consiste à surveiller les systèmes et à récupérer les informations sur leur
état et leur comportement, ce qui peut être fait par interrogation périodique où par remontée non
sollicitée d’informations de la part des équipements de réseaux eux-mêmes.

Le plus grand souci d’un administrateur est la panne. En effet, il doit pouvoir réagir le plus
rapidement possible pour effectuer les réparations nécessaires. Il faut pouvoir surveiller de manière
continue l’état des réseaux afin d’éviter un arrêt prolongé de celui-ci. La supervision doit permettre
d’anticiper les problèmes et de faire remonter les informations sur l’état des équipements et des
logiciels.

Plus le système est important et complexe, plus la supervision devient compliquée sans les
outils adéquats. Une grande majorité des logiciels de supervision sont basés sur le protocole SNMP
qui existe depuis de nombreuses années. La plupart de ces outils permettent de nombreuses
fonctions dont voici les principales :

 Surveiller le système d’information ;

 Visualiser l’architecture du système ;
 Analyser les problèmes ;
 Déclencher des alertes en cas de problèmes ;
 Effectuer des actions en fonction des alertes ;
 Réduire les attaques entrantes.
La tâche de l’administrateur est alors simplifiée. Il n’a plus qu’à faire une vérification ou réaliser
une action en fonction d’une alerte déclenchée.
 13

1.4. Administration réseau

L'administration désigne plus spécifiquement les opérations de contrôle du réseau avec la gestion
des configurations et de sécurité. De façon générale, une administration de réseaux a pour objectif
d'englober un ensemble de techniques de gestion mises en œuvre pour :

 Offrir aux utilisateurs une certaine qualité de service ;

 Permettre l'évolution du système en incluant de nouvelles fonctionnalités ;
 Rendre opérationnel un système
I.4.1. Les protocoles d’administration
Chaque fournisseur de réseau propose des outils permettant de mettre en place la gestion du
réseau. De ce fait, si l’on dispose de plusieurs systèmes hétérogènes, il est très difficile de faire
coopérer les différents outils de gestion de réseau de chaque système. Cependant L’échange
d’informations entre systèmes hétérogènes a été rendu possible par l’intermédiaire de la
normalisation de l’ISO. C’est ainsi que des protocoles d’administration ont vu le jour. Les
protocoles d’administration permettent à la plate-forme de gestion d’aller chercher les
informations sur les éléments de réseaux et aussi de changer les paramètres sur ces derniers. De
plus, ils permettent à la plate-forme de gestion de recevoir des alertes provenant des éléments de
réseaux. Deux protocoles d’administration réseaux ont été normalisés par l’ISO :

La CMIP (Common Management Information Protocol) et le SNMP (Simple Network

Management Protocol).

I.4.1.1. Le protocole CMIP

Le protocole CMIP est un protocole d’administration de réseau, qui supporte l’échange

d’informations entre l’application d’administration et les agents.

L’information d’administration échangée entre l’application et les agents est faite par le biais
d’objets CMIS (Common Management Information Service), qui représentent l’entité à
administrer. Ces objets peuvent être modifiés ou contrôlés et ils peuvent être utilisés pour effectuer
des tâches sur l’agent administré. Le protocole CMIP est un protocole assez utilisé dans le domaine
des télécommunications (RGT : Réseau de Gestion des Télécommunications). Cependant, ce
protocole consomme beaucoup de ressources sur le système administré, ce qui fait que ce protocole
n’est pas très largement diffusé. De plus, le protocole CMIP est défini pour fonctionner sur la pile
du protocole OSI. Cependant, le standard utilisé de nos jours dans la majorité des environnements
de réseaux locaux est le protocole TCP/IP.
 14

Il existe une panoplie de protocoles et d’outils de supervision de réseau aidant à collecter

des informations sur les nœuds réseau et vérifier leur bon fonctionnement tels que SSH, ICMP, et
SNMP. Mais en termes d’efficacité et consistance c’est le protocole SNMP qui se situe en premier
rang.

I.4.1.2. SNMP (Simple Network Management Protocol)

Est le protocole de gestion de réseaux proposé par l’IETF (Internet Engineering Task Force).
Il est actuellement le protocole le plus utilisé pour la gestion des équipements de réseaux. SNMP
est un protocole relativement simple ; toutefois l’ensemble de ses fonctionnalités est suffisamment
puissant pour permettre la gestion des réseaux hétérogènes complexes. Il est utilisé aussi pour la
gestion à distance des applications : les bases de données, les serveurs, les logiciels, etc. L’usage
du protocole SNMP peut aussi dépasser largement le cadre de la gestion des équipements de
réseaux. L’environnement de gestion SNMP est constitué de plusieurs composantes :

 Une station de gestion de réseau (NMS- Network Management Stations) ;

 Des éléments de réseaux (NE, Network Elements) ;
 Des variables MIB et d’un protocole.
I.4.1.3. Le protocole Telnet
Le premier protocole historique est Telnet. Ce protocole TCP est largement utilisé pour le
contrôle à distance de matériel réseau. La conception est excessivement simple : une fois que l’on
est connecté à la machine distante, les touches tapées au clavier sont directement transmises à la
machine distante et telnet nous renvoie les réponses de ladite machine. Généralement, la machine
distante commence la transaction par nous demander un mot de passe d’accès, puis nous donne
accès à un shell sur lequel nous pouvons lancer nos commandes.

I.4.1.4. Le protocole SSH

Comme nous pouvons le constater, telnet n’est pas un protocole fournissant une interface
commune à tout le matériel réseau. Chaque constructeur inclut son propre gestionnaire telnet
personnalisé, et la gestion du réseau n’est donc pas uniforme suivant le type de matériel. Telnet
assure intrinsèquement la fiabilité de la transaction de par l’utilisation du protocole TCP, toutefois
la communication entre l’administrateur et le matériel n’est pas cryptée et la seule sécurité apportée
est l’authentification initiale. Le protocole SSH comble cette lacune en cryptant la transaction via
le protocole SSL. Il permet également d’effectuer des transferts de fichiers entre les deux hôtes
(protocole SCP). Toutefois l’interface reste propre à chaque matériel et ne permet pas d’effectuer
des transactions parallèles ou une gestion uniforme de ceux-ci.
 15

I.4.2 L’EXPLOITATION RESEAU

De nos jours, les systèmes d'exploitation à savoir les systèmes UNIX, MacOs et Windows
gèrent tous l'aspect de l’exploitation des réseaux, les procédures, et les fonctions associées. Un
système d’administration réseau est une collection d’outils pour la supervision et le contrôle du
réseau qui sont intégrés dans le sens qu’ils impliquent :

 Une interface opérateur unique avec un puissant, mais convivial ensemble de

commandes pour exécuter toutes les tâches d’administration réseau.
 Un nombre minimal d’équipements séparés qui sont le plus souvent des
composants matériels et logiciels requis pour l’administration réseau, et
incorporés dans les équipements utilisateurs existants.
Les objectifs (les finalités) de l’administration des réseaux pour un administrateur

 Supervision du fonctionnement des réseaux ;

 Optimisation pour l’utilisation des ressources ;
 Détection et prévision des erreurs ;
 Signalisation des pannes ;
 Calculs de facturations à l’utilisation des ressources ;
 Le support technique pour utilisateurs.
L’administration d’un réseau suppose l’existence d’un système d’information décrivant le
réseau de l’entreprise et recensant toutes les données et événements relatifs à chaque constituant
du réseau administré.

Figure 1 Fonctionnement du SNMP

Un réseau comporte un grand nombre de composants (objets) que le système d’administration

surveille. Dans chaque objet, un programme en tâche de fond (Daemon) transmet régulièrement,
ou sur sollicitation, les informations relatives à son état.
 16

Figure 2 Structure d'un système d'administration

I.5. Principes fonctionnels et structuration d’un système d’administration réseau

 La prévoyance : anticiper l’avenir et préparer l’organisation à s’adapter aux
changements ;
 L’organisation : construire une structure, définir les responsabilités ou charges,
sélectionner, entrainer les managers ;
 Les commandements : qui administrent quoi ?
 La coordination : mettre de l’harmonie, concilier les activités afin que les fonctions
travaillent dans le même sens, à la réalisation de mêmes objectifs ;
 Le contrôle : vérifier si les objectifs sont réalisés conformément aux ordres et aux
principes.
I.5.1. Supervision selon La norme ISO 7498/4
Le concept de supervision a été normalisé par l’ISO (International Organization for
Standardization). Voici les différentes fonctions qui ont été défini par l’ISO :

I.5.2. Gestion des performances

Elle doit pouvoir évaluer les performances des ressources du système et leur efficacité. Elle
comprend les procédures de collecte de données et de statistiques. Elle doit aboutir à
l’établissement de tableaux de bord. Les informations recueillies doivent aussi permettre de
planifier les évolutions du réseau.
Les performances du réseau sont évaluées à partir de quatre paramètres :
 Le temps de réponse
 17

 Le débit

 Le taux d’erreur par bit

 La disponibilité

I.5.3. Gestion des configurations (Management Configuration)

La gestion de configuration permet d’identifier, de paramétrer et de contrôler les différents
objets du réseau. Les procédures requises pour gérer une configuration sont :
 La collecte d’information
 Le contrôle d’état
 La sauvegarde historique de configurations de l’état du système.

I.5.4. Gestion de la comptabilité (Accounting Management)

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

I.5.5. Gestion des anomalies (Fault Management)

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

I.5.6. Gestion de la sécurité (Security Management)

La gestion de la sécurité contrôle l’accès aux ressources en fonction des politiques de droits
d’utilisation établies. Elle veille à ce que les utilisateurs non autorisés ne puissent accéder à
certaines ressources protégées. Elle a également pour rôle de mettre en application les politiques
de sécurité.
I.6. Présentation du protocoles netflow
La technologie NetFlow a été développée parce que les professionnels des réseaux avaient
besoin d'une méthode efficace permettant d'assurer le suivi des flux TCP/IP au sein du réseau et
que le protocole SNMP ne suffisait pas à réaliser cet objectif. Le NetFlow se concentre sur la
fourniture de statistiques relatives aux paquets IP circulant entre les périphériques réseau, Tandis
que le protocole SNMP tente d'offrir une très large gamme de fonctionnalités et d'options de
gestion du réseau.
 18

I.6.1. Architecture du NetFlow

Des éléments réseau (commutateurs et routeurs) établissent des statistiques sur les données
des flux réseau qu'ils exportent vers des collecteurs. Ces statistiques détaillées peuvent porter sur
les nombres de paquets et d'octets, les ports applicatifs, les adresses IP, les champs de qualité.

I.6.2. Flux Réseau NetFlow

De service, les interfaces par lesquelles ils transitent, etc. L’architecture de NetFlow est
comme suite :

Figure 3 représentation de l'architecture netflow

Un flux réseau NetFlow est unidirectionnel. Il est caractérisé par 7 champs clés :

Le protocole de couche 3 (en général IPv4, mais d'autres protocoles sont possibles)
L'adresse IP source
L'adresse IP de destination
Le port source (UDP ou TCP, 0 pour les autres protocoles)
Le port de destination
Le champ Type of Service
L'interface en entrée
I.7. Les outils de supervision
I.7.1. NAGIOS
Créé en 1999 par Ethan Galstad, Nagios est un logiciel qui permet de superviser un système
d'information. Il est considéré comme étant la référence des solutions de supervision open source.
Il dispose de nombreuses fonctions telles que l'héritage multiple, les dépendances, l'escalade de
 19

notifications, les Template de services et d'hôtes, le support des surveillances actives et passives,
etc. L'interface web est la partie graphique, via un serveur web tel qu’Apache, et qui va permettre
à l'administrateur d'avoir une vue d'ensemble de son réseau, de visualiser la supervision des
équipements et de produire des rapports d’activités.
I.7.2. Centreon
Anciennement appelé Oreon1, Centreon est un logiciel de supervision des applications, systèmes
et réseaux, basé sur les concepts de Nagios. C’est une solution complète destinée aux
administrateurs et exploitants du service de supervision. Il apporte de nombreuses fonctions telles
que la consultation de l'état des services et des machines supervisées, la métrologie, le reporting,
l'accès aux événements de supervision, la gestion avancée des utilisateurs via des listes de
contrôle d’accès (ACL), etc. Il s’appuie sur les technologies Apache et PHP pour l'interface web,
MySQL pour le stockage des données de configuration et de supervision.

I.7.3. ZABBIX
Zabbix est un logiciel libre qui permet de surveiller l'état de divers services réseau, serveurs
et autres matériels réseau et produisant des graphiques dynamiques de consommation des
ressources. Le « serveur ZABBIX » peut être décomposé en trois parties séparées : Le serveur de
données, l'interface de gestion et le serveur de traitement. Chacune d'elles peut être disposée sur
une machine différente pour répartir la charge et optimiser les performances. Il repose sur du
C/C++, PHP pour la partie front end et MySQL/ PostgreSQL/ Oracle pour la partie BDD. Et
d'algorithmes soigneusement conçues pour atteindre de très faibles frais généraux par nœud et
haute concurrence.

I.7.4. PRTG
1. Présentation

PRTG a les fonctionnalités suivantes :

 Interface HTML complète et simple à utiliser.

 Applications IOS et Android.
 Surveillance réseau complète : 200 types de capteurs.
 Gestion avancées des alertes.
 Gestion des clusters pour la haute disponibilité.
 Distribution de la surveillance à l’aide de probes à distance.
 Les cartes et la publication des données de la surveillance
 20

Figure 4 Interface d'accueil PRTG

2. Avantages

Il est un outil unique pour une supervision centralisée :

 Gestion des alertes avec envoi de notifications.

 Cartographies.
 Rapports.
 Facile à utiliser.
 Produit bien établi et fiable : PRTG est utilisé par plus de 150.000
utilisateurs chaque jour.
 Monitoring temps réel

PRTG est certifié par des différents leaders technologiques : Cisco compatible, Works with
Windows 2008 Server by Microsoft, VMware technology alliance partner, etc. Pas besoin d’un
serveur dédié car il peut être installé même sur une machine cliente.
 21

3. Pourquoi PRTG
Comme nous avons pu le voir plus haut, nous avons une pléthore d’outils de supervision à notre
disponibilité. Le choix de l’utilisation de PRTG comme outil de supervision s’est fait sur certains
critères.

La disponibilité en Entreprise : Au sein de l’entreprise, un projet en suspens sur ce thème existait

déjà, d’où la disponibilité de l’outil PRTG. Facilité d’utilisation : PRTG comporte énormément
d’utilitaires et pas besoin d’installer des plugins pour améliorer son utilisation car tout ce dont
nous avons besoin pour la supervision s’y trouve.
I.8. Comparaison des outils de supervision

Tableau 1 Comparaison des outils de supervision

OUTILS AVANTAGES INCONVENIENTS

-Une interface vaste mais -Interface est un peu vaste, la
claire. mise en place des Templates
-Une gestion des Templates n'est pas évidente au début :
poussée, avec import/export petit
XML, modifications via Temps de
ZABBIX L’interface formation nécessaire.
Compatible avec MySQL, -L'agent Zabbix
PostgreSQL, Oracle, SQLite. communique par défaut en
clair les informations ;
nécessité de sécuriser
Ces données (via VPN par
exemple).
-Une solution complète -Interface non ergonomique
Permettant le reporting, la et peu intuitive
gestion de panne et -Configuration
D’alarmes, gestion fastidieuse via
utilisateurs, ainsi que la beaucoup de fichiers
cartographie du réseau. -Pour avoir toute les
NAGIOS
-Beaucoup de fonctionnalités il
documentations sur le web faut installer des
Performances du moteur
 22

plugins de base et c'est assez

limité.

-La robustesse et -L'interface peut paraître

la renommée de complexe car il existe
Nagios. beaucoup d'options, de vues
-Une interface beaucoup plus etc. Cela
sympathique, permettant de nécessite une petite
CENTREON tout configurer, de garder un formation.
œil -Le développement n'est pas
sur tout le réseau encore en phase avec celui de
en permanence. Nagios : Parfois des
-Les utilisateurs de Nagios ne Problèmes de
seront pas perdus pour compatibilité. -
Autant, l'interface reprenant Il est plus lourd
Avantageusement certaines
vues Nagios.
PRTG -Outil unique pour une supervision centralisée
-Pas besoin d’un serveur dédié car il peut être installé même
sur une machine cliente.

Compte tenu de tous les avantages de PRTG énumérées comme la gratuité de la licence a vie pour
un maximum de 100 capteurs, la facilité de déploiement nous pouvons déduire que la solution de
supervision la mieux adaptée pour notre travail est PRTG.

I.9. Conclusion

Dans ce chapitre nous avons étalé les notions de base sur la supervision réseau, l’objectif de la
supervision réseau, types de supervision réseau et nous avons également parlé sur les outils de
supervision, ainsi que le protocole.
 23

CHAPITRE II. ÉTUDE FONCTIONNELLE DE PROTOCOLES

SNMP ET SYSLOG
II.1. Introduction

Dans le deuxième chapitre nous allons étudier les fonctionnements c'est-à-dire leurs principes
d'utilisation dans l'administration réseau.

II.2. La protocoles SNMP

II.2.1 Présentation générale
SNMP (Simple Network Management Protocol) est le protocole de gestion de réseaux proposé par
l’IETF. Il est actuellement le protocole le plus utilisé pour la gestion des équipements de réseaux.
SNMP est un protocole relativement simple. Pourtant l’ensemble de ses fonctionnalités est
suffisamment puissant pour permettre la gestion des réseaux hétérogènes complexes. Il est aussi
utilisé pour la gestion à distance des applications : les bases de données, les serveurs, les logiciels,
etc.

II.2.2 Principe de fonctionnement du protocole SNMP

Le système de gestion de réseau est basé sur deux éléments principaux qui sont :

 Un superviseur et des agents. Le superviseur est la console qui permet à l'administrateur

réseau d'exécuter des requêtes de management.

 Les agents sont des entités qui se trouvent au niveau de chaque interface connectant
l'équipement managé au réseau et permettant de récupérer des informations sur différents
objets.

II.3 L’environnement de gestion SNMP

Le protocole SNMP est constitué de plusieurs composantes qui sont : la station de supervision,
les éléments actifs du réseau, les variables MIB et un protocole. Les composantes du protocole
SNMP sont les suivantes :

 Les éléments actifs du réseau sont les équipements ou les logiciels que l’on cherche à gérer.
Cela va d’une station de travail à un concentrateur, un routeur, un pont, etc. Chaque élément
du réseau dispose d’une entité dite agent qui répond aux requêtes de la station de
supervision.

 Les agents sont des modules qui résident dans les éléments réseau. Ils vont chercher
l’information de gestion comme par exemple le nombre de paquets en reçus ou transmis.
 24

 La station de supervision (appelée aussi manager) exécute les applications de gestion qui
contrôlent les éléments réseaux physiquement, la station est un poste de travail.

 La MIB (Management Information Base) est une collection d’objets résidant dans une base
d’information virtuelle. Ces collections d’objets sont définies dans des modules MIB
spécifiques.

 Le protocole, qui permet à la station de supervision d’aller chercher les informations sur
les éléments de réseaux et de recevoir des alertes provenant de ces mêmes éléments.

II.4 Fonctionnement
Sur chaque équipement on trouve un agent snmp. Cet agent gère les informations relatives à
l’équipement et sont stockées dans une base de données propre : la MIB (Management Information
Base). On positionne un manager Snmp sur l'unité qui va servir de console d'administration.

De là quatre opérations sont possibles :

 get-request / get-response : l’administrateur interroge une variable particulière de la MIB.

 get-next-request / get-response : l’administrateur interroge toute une table de la MIB.

 set-request / get-response : l’administrateur met une valeur à jour dans la MIB.

 trap : l’agent prévient l’administrateur qu’un événement particulier s’est produit.

A. Les réponses de SNMP

À la suite de requêtes, l’agent répond toujours par GetResponse. Toutefois si la variable demandée
n’est pas disponible, le GetResponse sera accompagné d’une erreur noSuchObject.

Les alertes (Traps, Notifications)

Les alertes sont envoyées quand un événement non attendu se produit sur l’agent. Celui-ci en
informe la station de supervision via une trap. Les alertes possibles sont : ColdStart, WarmStart,
LinkDown, LinkUp, AuthentificationFailure.

II.4.1 L'agent SNMP

Sur une machine à superviser, pour que le protocole SNMP envoie les informations que l'on
souhaite, il faut qu'un agent soit installé sur celle-ci. Cet agent écoute le port 161 et attend que le
serveur (manager) lui envoie sur le port 162 des requêtes afin qu'il réponde. L'agent pourra lui
envoyer des alertes si celles-ci ont été configurées. Par exemple, pour surveiller l'occupation CPU
d'une machine, l'administrateur définira une valeur critique à partir de laquelle une alerte doit lui
 25

être émise. Donc, Sur chaque équipement on trouve un agent SNMP. Cet agent gère les
informations relatives à l'équipement qui sont stockées dans une base de données propre. On
positionne ensuite un manager SNMP sur l'unité qui va servir de console d'administration. Pour
finir l'agent pourra ainsi agir sur l'environnement local tandis que, le manager se charge d'élaborer
les requêtes.

Schématiquement, nous avons ceci :

B. Les requêtes SNMP

Les commandes Get-request, Get next request, Set request sont émises du manager vers l'agent, et
la commande Get response est émise de l'agent vers le manager. Ces commandes représentent les
différents types de PDU (Protocole Data Unit). La commande Trap est une alerte. Elle est toujours
émise par l'agent vers le manager, et celle-ci n'attend pas de réponse. Le format PDU de Get
request, Get next request, Get response, et Set request est représenté comme suit :

Tableau 2 Format de requête

Types de ID de la Erreur de Erreurs de Objet 1 Objet2 Ect..

PDU requête statut l'index Valeur 1 Valeur2

 L'id de la requête est en fait un nombre entier qui met en relation la requête demandée par le
manager, et la réponse de l'agent.

 L'erreur de statut indique si les opérations effectuées sont valides ou invalides. Si celles-ci ne sont
pas valides il renvoie un nombre entier afin de spécifier de quel type d'erreur il s'agit.

 L'erreur d'index identifie l'entrée dans la liste d'attaches variable qui a causé l'erreur. ? Les objets
et valeurs représentent les différentes variables se liant entre elles avec leurs noms et leurs valeurs.

Ainsi, nous avons :

 26

Le protocole SNMP grâce à un système de récolte d'informations permet aux administrateurs de

connaître en temps réel l'état de leur réseau. Son efficacité et sa simplicité en ont fait un des
protocoles les plus utilisés dans le monde de l'administration réseau.

Généralement, l'administrateur possède un outil permettant de centraliser ce que lui retournent tous
les agents. C'est donc cet outil qui va interroger les équipements du réseau afin de pouvoir gérer
le réseau tout entier.

C. La MIB

La MIB (Management Information base) est la base de données des informations de gestion maintenue par
l’agent, auprès de laquelle le manager va venir pour s’informer.

Deux MIB publics ont été normalisées : MIB I et MIB II (dite 1 et 2). Un fichier MIB est un document
texte écrit en langage ASN.1 (Abstract Syntax Notation 1) qui décrit les variables, les tables et les alarmes
gérées au sein d’une MIB.

La MIB est une structure arborescente dont chaque noeud est défini par un nombre ou OID (Object
Identifier). Elle contient une partie commune à tous les agents SNMP en général, une partie commune à
tous les agents SNMP d’un même type de matériel et une partie spécifique à chaque constructeur. Chaque
équipement à superviser possède sa propre MIB. Non seulement la structure est normalisée, mais également
les appellations des diverses rubriques. Ces appellations ne sont présentes que dans un souci de lisibilité.
En réalité, chaque niveau de la hiérarchie est repéré par un index numérique et SNMP n’utilise que celui-
ci pour y accéder.

SNMP (Simple Network Management Protocol) est le protocole de gestion de réseaux proposé par
l'IETF. Il est actuellement le protocole le plus utilisé pour la gestion des équipements de réseaux.
SNMP est un protocole relativement simple. Pourtant l'ensemble de ses fonctionnalités est
suffisamment puissant pour permettre la gestion des réseaux hétérogènes complexes. Il est aussi
utilisé pour la gestion à distance des applications : les bases de données, les serveurs, les logiciels,
etc. [3]

 Les buts du protocole SNMP sont de :

 Connaître l'état global d'un équipement (actif, inactif, partiellement

opérationnel...)

 Gérer les évènements exceptionnels (perte d'un lien réseau, arrêt brutal
d'un équipement...) ;
 27

 Analyser différentes métriques afin d'anticiper les problèmes futurs

(engorgement réseau...) ;

 Agir sur certains éléments de la configuration des équipements.

II.4.1.2. Diagramme de cas d’utilisation SNMP

Le fonctionnement de ce protocole est détaillé dans le diagramme ci-dessous :
Le système de gestion de réseau est basé sur deux éléments principaux : un superviseur (serveur)
et des agents. Le superviseur est la console qui permet à l'administrateur réseau d'exécuter des
requêtes de management. Les agents sont des entités qui se trouvent au niveau de chaque interface
connectant l'équipement managé au réseau et permettant de récupérer des informations sur
différents objets. Switchs, hubs, routeurs et serveurs sont des exemples d'équipements contenant
des objets manageables.

Ces objets manageables peuvent être des informations matérielles, des paramètres de
configuration, des statistiques de performance et autres objets qui sont directement liés au
comportement en cours de l'équipement en question. Ces objets sont classés dans une sorte de base
de données appelée MIB ("Management Information Base"). SNMP permet le dialogue entre le
superviseur et les agents afin de recueillir les objets souhaités dans MIB. De gestion du réseau
proposée par le protocole SNMP est donc basée sur trois principaux éléments :

 Les équipements managés ou hôtes (managed devices) sont des éléments du réseau
(ponts, hubs, routeurs ou serveurs), contenant des "objets de gestion" (managed objects)
pouvant être des informations sur le matériel, des éléments de configuration ou des
informations statistiques ;

 Les agents, c'est-à-dire une application de gestion de réseau résidant dans un périphérique
et chargé de transmettre les données locales de gestion du périphérique au format SNMP ;

 Les systèmes de management de réseau (network management systems notés NMS),

c'est-à-dire une console au travers de laquelle les administrateurs peuvent réaliser des
tâches d'administration.
 28

II.4.1.3 Diagramme de cas d’utilisation de gestion du réseau avec le protocole SNMP

Figure 5Diagramme de cas d'utilisation SNMP

 29

II.4.1.3 Diagramme de séquence s’authentifier

Figure 6 Diagramme de séquence SNMP

II.4.1.4 Diagramme de séquence gérer réseau

Simple Network Management Protocol (abrégé SNMP), en français « protocole simple de gestion
de réseau », est un protocole de communication qui permet aux administrateurs réseau de gérer
les équipements du réseau, de superviser et de diagnostiquer des problèmes réseaux et matériels à
distance.

Dans la gestion du réseau l’administrateur effectue souvent les opérations suivantes :

 Modifier la configuration
 Lancer requetés
 Gérer évènement
 30

Figure 7 diagramme de séquence gérer réseau

 31

II.5 LA PROTOCOLES SYSLOG

II.5.1 Présentation Syslogd
Syslog est le protocole de journalisation standard sous Linux. Syslog gère le journal d’événement
Linux, que ce soit pour le noyau Linux ou pour les services hébergés sur la station. Architecture
en couches Syslog. Son architecture en couches est formée de trois composants : le périphérique
réseau qui génère les journaux, le relais Syslog qui transmet les journaux à un collecteur et le
collecteur Syslog (ou serveur) qui recevra et stockera les journaux.

Figure 8 Mode de fonctionnement du protocole syslog

Le protocole Syslog Il fonctionne sur le modèle client/serveur. La partie client émet les
informations sur le réseau, via le port UDP 514. Il est possible d’utiliser TCP. La partie serveur
collectent l’information et se chargent de créer les journaux.

II.5.2 L’environnement Syslog

Le protocole Syslog définit la notion de périphérique, de relais et de collecteur dans une
architecture Syslog. Un périphérique est une machine ou une application qui génère des messages
Syslog. Un relais est une machine ou une application qui reçoit des messages Syslog et les
retransmet à une autre machine. Un collecteur est une machine ou une application qui reçoit des
messages Syslog, mais qui ne les retransmet pas.
 32

Figure 9 Structure du protocole syslog

Tout périphérique ou relais sera vu comme un émetteur lorsqu'il envoie un message Syslog et tout
relais ou collecteur sera vu comme un récepteur lorsqu'il reçoit un message Syslog. Un journal au
format syslog comporte dans l’ordre les informations suivantes :

 La date à laquelle a été émis le log,

 Le nom de l’équipement ayant généré le log (hostname),

 Une information sur le processus qui a déclenché cette émission,

 Le niveau de priorité du log,

 Un identifiant du processus ayant généré le log

 le corps de message.

II.6 FONCTIONNEMENT DE SYSLOG

II.6.1 Diagramme de cas d’utilisation Syslog
Le serveur Syslog centralise les messages du kernel Linux ou des services dans des fichiers.
Des modules existent pour rediriger les logs vers une base de données. En mode client/serveur, les
clients envoient leurs logs vers un serveur syslog sur le port 514. Ce serveur peut ensuite stocker
les logs de ses clients vers un serveur de base de données.
 33

Figure 10 Diagramme de cas d’utilisation Syslog

II. 6.2 Diagramme de sequence syslog

Figure 11 Diagramme de séquence syslog

 34

II.7 le message syslog

Les messages Syslog Les messages Syslog sont déclenchés par des événements au sein d'un
système. Ils sont conçus pour nous alerter lorsqu'un événement important se produit dans un
système qui pourrait nous intéresser. Il existe différents niveaux de messages Syslog du niveau 0
(messages d'urgence) au niveau 7 (messages de débogage). Le format de chaque journal comprend
les horodatages, les adresses IP des hôtes, le message d'événement, la gravité, les diagnostics, etc.
Des exemples de journaux peuvent être des modifications de configuration et des tentatives
d'authentification.

Tableau 3 message de gravité

Code Gravité Mot-clé Description
0 Emrgency emerg (panic) Système inutilisable
1 Alert alert Une intervention
immédiate est
nécessaire

2 Critical Crit Erreur critique pour le

système.
3 Erro Err(error) Erreur de
fonctionnement
4 Warning warn (warning) Avertissement (une
erreur peut intervenir
si aucune action n’est
prise).
5 Notice Noctice Événement normal
méritant d’être
signalé.
6 Informational Info Pour information.
7 Debugging debug Message de mise au
point.

 Périphériques (Clients)

En mode client/serveur, les clients envoient leurs logs (les messages orientés selon leur gravité)
vers un serveur syslog sur le port 514. Ce serveur peut ensuite stocker les logs de ses clients vers
 35

un serveur de base de données. Ainsi, un attaquant ne peut pas effacer ces traces qui sont déportées
sur un serveur distant. Logs sont des messages générés par le client

 Relais Syslog ou serveur Syslog

C’est un point unique de centralisation auquel le clients envoies leurs logs() par le port UDP 514
pour le stockage est dans lequel les journaux peuvent ensuite être consulté et analyser engin de
fournir une surveillance et un dépannage.

 Collecteur Syslog

C’est un point central de stockage de journaux de donnée de différents degrés, est delà les journaux
peuvent ensuite être consultés et analysés afin de fournir une surveillance et un dépannage.

II.8 Conclusion
Notre objectif poursuivi dans ce deuxième chapitre était de faire une étude sur ces des protocoles
SNMP et SYSLOG, voilà au cours de cette étude nous avons eu à connaitre plus largement les
principes de fonctionnement de ces deux protocoles de supervision, leur structuration c’est-à-dire
les éléments qui composent chaque protocole et leur mode d’échange des messages entre la station
de gestion et les équipements gérés.
 36

CHAPITRE III : ETUDE COMPARATIVE DU PROTOCOLE SNMP ET SYSLOG

III.O INTRODUCTION
Dans ce chapitre il sera question pour nous de faire une étude comparative entre les deux
protocoles de supervision réseau SNMP et SYSLOG.

III. I PROTOCOLE SYSLOG

SYSLOG est un protocole qui permet de transmettre les logs générés par les équipements réseau
vers un serveur SYSLOG à travers le port UDP 514. Son intérêt est la centralisation de tous les
messages des équipements du réseau pour faciliter le dépannage. Lorsqu’un problème survient, on
peut facilement retrouver sa source en consultant les logs du serveur SYSLOG sans avoir à
analyser chaque équipement du réseau un par un.

Un message de type SYSLOG sur un équipement réseau permet d’afficher plusieurs informations
comme la date exacte du jour de l’équipement, le processus déclencheur, le niveau de sévérité18
et le corps du message. Si on consulte les logs sur un serveur Syslog, on a comme information
supplémentaire le nom ou l’IP de l’équipement et la date du serveur.

Figure 12 exemple de logs sur un serveur syslog

Il faut savoir que Syslog permettra également de récolter les données des outils Nfsen
et Cacti décrits plus haut si on les configure correctement. Le fait de tout centraliser sur
notre serveur Syslog peut être une bonne chose pour autant que l’on retrouve les
informations souhaitées. En effet, Syslog génère énormément de log, il faudra donc
trouver une technique pour filtrer les informations recherchées.

III.1.1 Alerter avec Syslog

Dans cette partie on va s’intéresser à comment récupérer les informations sur le serveur Syslog.
En principe, les trappes générées par les équipements Cisco vont se stocker dans les logs.
Maintenant que nous avons vu comment alerter par email, une des prochaines étapes est de
consulter les logs pour avoir plus d’information sur cette alerte
 37

Nous allons expliquer comment filtrer nos logs sans avoir besoin d’une éventuelle application
supplémentaire, c’est-à-dire en n’utilisant que les commandes de Linux. La méthode qui vous sera
présentée ci-dessous est une idée parmi d’autres, il en existe probablement d’autres. Avant de
commencer, il est judicieux de configurer le logrotate21 afin de toujours être certain de savoir où
se trouve l’information que nous recherchons. Une configuration pour créer un fichier syslog par
jour et les conserver durant sept jours est disponible en annexe.

La première étape est de créer un nouveau fichier de log (sous /var/log par exemple)
où vont aller s’afficher les informations qu’on souhaite récupérer.

La deuxième étape consiste à créer un script qui va :

 Parcourir le fichier Syslog

 Récupérer l’information souhaitée grâce à la commande « grep »
 Rediriger le contenu trouvé avec la commande « > » dans notre fichier créé à la première
étape

Cela parait simple à première vue, mais, un problème essentiel se pose. Comment récupérer les
logs de manière continue puisque rappelons-le, le fichier Syslog se met à jour très souvent. Un
parcours unique ne permettra pas à notre filtre de récupérer les informations qui arriveront après
le lancement du script étant donné que la plupart des langages de programmation sont prévus,
lorsqu’on parcourt un fichier, pour s’arrêter à la fin de celui-ci (end of file). Une solution qui
permet de contourner ce problème (certainement pas la plus efficace) est de créer une boucle
infinie dans notre script qui va analyser en continue le fichier Syslog afin d’y répertorier les
éventuels nouveaux messages qui arriveront après coup. Certes le fait d’avoir une boucle infinie
qui tourne en arrière-plan n’est certainement pas la meilleure des méthodes, mais ça marche.
La troisième et dernière étape est facultative, mais peut s’avérer utile.

Elle consiste simplement à envoyer par email les fichiers de log créés. Vous trouverez en annexe
les étapes pour réaliser des filtres Syslog via Linux ainsi que l’envoi par email de ceux v
Idéalement, le mieux serait d’avoir une interface web pour gérer les logs et ainsi pouvoir les filtrer
ou les exporter directement. Il en existe plusieurs comme Kiwi qui dispose d’énormément de
fonctionnalités en plus d’être très connu mais qui est malheureusement payant (240 euros). Kiwi
dispose aussi d’une version light gratuite moins intéressante (uniquement cinq équipements
peuvent envoyer des logs en même temps). Une autre alternative et gratuite cette fois ci est
Graylog2 qui est une solution open source qui utilise une interface web écrite en Ruby (langage
de programmation) qui permet entre autre de filtrer les logs via des cases à cocher. Cependant, les
 38

messages Syslog sont souvent consultés « à la volée », d’où le fait d’avoir présenté une méthode
automatisée ci-dessus. Pour filtrer les logs via une interface web, il sera plus difficile de réaliser
automatiquement les tâches de filtrage et une personne physique devra probablement être présente.

III.1.2 Alerter avec prudence

Nous venons de voir quelques moyens d’alerter lorsqu’une congestion se produit dans un réseau.
Bien que cette étape soit très importante, il faut avoir en tête que trop d’alertes tuent les alertes. Si
on en reçoit plusieurs par jour, on ne va plus y prêter attention. Il faudra donc bien faire attention
à définir des seuils avec parcimonie afin de ne pas inonder les administrateurs de messages inutiles.
Par exemple, il sera important de bien faire la différence entre un pic de trafic de quelques secondes
et un long trafic de plusieurs minutes. Pour cela plusieurs techniques existent. Avec Nfsen par
exemple, on peut décider après combien d’occurrence se déclenchera une alerte et pendant
combien de cycle nous voulons la bloquer, ainsi, on pourra facilement ignorer une petite pointe de
trafic sans importance.

III.1.2 Sécurité :
Syslog n'a pas été pensé pour fonctionner dans un environnement agressif. Il est facile à abuser, à
inonder avec de fausses alertes,
 Les hôtes distants pouvant envoyé des événements via réseau ne sont pas authentifiés :
syslogd est donc vulnérables à l'usurpation (spoofing). En cas de compromission d'un poste
sur le réseau, il faut être très méfiant vis à vis des entrées concernant ce poste mais aussi
de celles concernant les autres postes.
 Les informations circulent en clair sur le réseau et peuvent donc être sniffées
 Syslog s'appuie sur UDP qui est en mode non connecté sans garantie de délivrance :
certains paquets peuvent être perdus. Un attaquant peut tenter d'augmenter le pourcentage
de pertes de paquets pour diminuer le nombre d'événements reçus par le syslog distant.
Certains syslog récents ou outils équivalents sont capables de travailler en TCP.
Les journaux contiennent une masse d'événements anodins dans lesquels il va falloir détecter les
entrées pertinentes. Extraire les événements dignes d'intérêt est une tâche difficile qui doit
répondre à deux contraintes opposées : 1) ne pas laisser passer des choses apparemment anodines
mais pouvant se révéler importantes (=> rapports plus gros) et 2) avoir des rapports courts et
synthétiques pour limiter le temps de lecture. Comme ces deux contraintes sont impossibles à
satisfaire, il est usuel d'avoir des rapports synthétiques courts (et donc incomplets) permettant de
surveiller les points vitaux.
 39

Deux types d'outils sont disponibles pour aider à l'analyse des journaux :
 Des outils d'analyse de journaux comme logcheck, swatch, logsurfer, ... qui se contente de
sélectionner des lignes en fonction de critères configurables. SEC est un outil plus évolué
qui permet de définir des critères embrassant plusieurs événements. Ces outils sont
relativement simples à configurer mais ils ne sont capables de faire des liens entre des
opérations différentes apparemment anodine mais dont l'ensemble constitue par exemple
une attaque. Exemple classique : scan de port et cartographie préludant une attaque.
 Les systèmes de détection d'intrusion : l'analyse des journaux est l'un des multiples sources
d'informations à partir de laquelle travaillent ces outils. Ils ont le défaut d'être plus lourds
à déployer et, surtout, dans un souci d'exhaustivité, de fournir des rapports longs comme
un jour sans pain qui finissent par ne plus être lus faute de temps. Quel que soit la solution
utilisée, elle doit garantir que les trois types de messages suivants sont signalés à
l'administrateur :
 Messages relatifs à la sécurité
 Messages qui indiquent que les disques sont remplis
 Message qui arrive plusieurs fois

III.2 Le protocole SNMP

Le protocole SNMP (Simple Network Management Protocol, ou autrement dit « protocole de

gestion réseau simplifié »), que nous allons étudier plus en détails dans la partie suivante, a pour
rôle exclusif la gestion réseau, et offre en conséquence un grand nombre d’avantages que n’ont
pas les autres protocoles. SNMP propose une interface de transaction commune à tous les
matériels, et donc la plus homogène possible. Son utilisation reste peu importante suite à des débuts
difficiles, mais SNMP tend à devenir à terme l’une des références en matière de gestion réseau.

III.2.1 présentation
SNMP est un protocole de la famille TCP/IP (Internet protocol), et peut donc être utilisé
sur tous les réseaux de type Internet. Il exploite les capacités du protocole de transport UDP :

 Chaque trame possède une adresse source et une adresse destination qui permet aux
protocoles de niveaux supérieurs comme SNMP de pouvoir adresser leurs requêtes.
 Le protocole UDP peut utiliser un checksum optionnel qui couvre l'en-tête et les
données de la trame. En cas d'erreur, la trame UDP reçue est ignorée : gage de fiabilité.
 Le protocole UDP fonctionne en mode non connecté, c’est-à-dire qu’il n’existe pas de
lien persistant entre la station d’administration et l’agent administré. Cela oblige les deux
 40

parties à s’assurer que leurs messages sont bien arrivés à destination, ce qui apporte
également un important gage de fiabilité pour la gestion réseau.
 Deux ports sont désignés pour l'utilisation de SNMP :
 Port 161 pour les requêtes à un agent SNMP.
 Port 162 pour l'écoute des alarmes destinées à la station d'administration.

Figure 13 fonctionnement du SNMP

III.2.2La sécurité
Sous SNMPv1 et SNMPv2c, la sécurité est assurée par deux choses :

 Dans sa requête, il faut envoyer une chaîne de communauté, qui correspond en quelque
sorte à un mot de passe, et dont les droits varient suivant cette chaîne : il est ainsi possible
d’autoriser certaines personnes un accès en lecture seule, et à d’autres personnes un accès
complet suivant la communauté qu’ils utilisent.
 L’agent peut vérifier et contrôler l’origine des données, afin de vérifier que la personne en
question a accès aux informations. Il s’agit généralement d’une vérification basée sur
l’adresse IP source.

Nous constatons toutefois que la sécurité est particulièrement lacunaire pour deux raisons : le
contenu de la transaction n’est pas crypté, et il suffit que la communauté soit connue de n’importe
qui pour que cette personne puisse lire les informations.
 41

Ces différents problèmes ont été résolus dans SNMPv3. En effet, celui-ci propose plusieurs
modèles de sécurités différents :

Le premier modèle est dépourvu de sécurités et est comparable à SNMPv1/v2c.

 Le second modèle offre des capacités d’authentification par utilisateur, c’est-à-

dire que chaque utilisateur dispose d’un mot de passe d’accès, ainsi que d’une clé publique
de cryptage permettant de sécuriser le contenu de la transaction.
 Le troisième modèle ajoute au précédent un niveau de cryptage supplémentaire en utilisant
le principe d’échange des clés privées : le contenu des paquets est ainsi totalement crypté mais ce
modèle n’est applicable qu’en fonction des lois sur la cryptographie en vigueur.

III.2.3 Fonctionnement pratique

Lorsqu’une commande est expédiée à un agent, on attend de celui-ci une réponse.
Plusieurs cas peuvent se produire :

 Aucune réponse (Temps d’attente dépassé)

 Erreur dans la requête
 La requête a réussi.

III.2.3.1 Aucune réponse

Plusieurs cas sont susceptibles de produire une absence de réponse de la part du matériel interrogé
: SNMP est basé sur UDP et il peut arriver que les paquets n’arrivent pas à destination. Dans ce
cas, le temps d’attente de réponse finit par s’écouler et il convient alors de réémettre la requête.

 Suivant l’implémentation des agents et la version de SNMP utilisée, si l’authentification

échoue (mauvaise communauté, mot de passe incorrect), l’agent peut ne pas répondre à la
requête.
 Le temps d’attente de réponse peut être paramétré dynamiquement et il est possible que le
temps défini soit trop court pour permettre à la réponse de revenir.
 Enfin, dans le pire des cas, il est possible qu’il n’y ait pas d’agent SNMP disponible sur le
matériel interrogé. Nous ne pouvons en conséquence avoir de réponse à notre requête.

III.2.3.2 Erreur
Plusieurs cas sont susceptibles de conduire au renvoi d’une erreur :

 Lorsqu’on l’on essaie d’écrire sur une variable en lecture seule

 42

 Lorsque l’on essaie de définir la valeur d’une variable avec un type de données incorrect
(si l’on essaie d’écrire une chaîne de caractères dans une variable de type entier par
exemple).
 Lorsque la variable n’existe pas.
 Lorsque la trame SNMP est incorrecte (corruption, longueur non valide…)
 Lorsque l’authentification SNMPv3 a échoué.

III.2.3.3 Réussite
Lorsque la requête à l’agent SNMP réussit, celui-ci nous envoie la valeur de la variable à laquelle
on a accédé (que ce soit en lecture ou en écriture).

III.3 Les implémentations existantes du protocole SNMP

Il existe des centaines d’implémentations différentes du protocole SNMP, de par le fait
qu’il s’agit d’un protocole parfaitement bien défini et qu’il est de plus en plus exploité au sein des
réseaux. Chaque implémentation a ses propres avantages et inconvénients. Certaines ont pour but
de fournir des applications de gestion SNMP, d’autres ont pour but de fournir des bibliothèques
de fonctions (API) pour la gestion SNMP. Certaines fournissent les deux, comme la distribution
net-SNMP du domaine libre. Celle-ci propose les applications de base pour débuter et utiliser
efficacement SNMP.

On retrouve dans la plupart des distributions le même ensemble d’applications de base

pour la gestion du matériel via SNMP. Il s’agit des applications suivantes :

 Snmpget : Permet de lire une variable d’un agent SNMP

 Snmpset : Permet de définir la valeur d’une variable d’un agent SNMP
 Snmpwalk : Permet de parcourir une liste de variables d’un agent SNMP.
 Snmptrap : Envoie une trap à un manageur
 Snmpbulkget, Snmpbulkwalk : Identique à Snmpget et Snmpwalk mais en utilisant des
requêtes de type Snmpbulk.
 Snmpinform : Envoie une requête Inform à un manageur

Ces applications sont généralement basées sur la même architecture de programmation. Certains
programmes contiennent directement les applications, ou l’implémentation du protocole, de
manière à accélérer la vitesse de traitement des informations.
 43

Voici le tableau qui résume l’étude comparative comparatif de deux protocoles

Tableau 4 Etude comparative de SYSLOG et SNMP

CRITERES SNMP SYSLOG

UTILITE SNMP permet la surveillance à distance du SYSLPG est un protocole diffèrent qui peut être utilisé pour
périphérique SNMP-autorise sur le réseau. échanger des messages de journal de divers degrés de gravité
vers un périphérique réseau capable de recevoir des messages
syslog
ROLE SNMP est utilisé pour alerter sur les actions critiques SYSLOG est également collecté, ce qui permet de creuser plus
comme les changements d’état HSRP profondément pour comprendre pourquoi le changement d’état
HSRP se produit
FONCTIONNEMENT SNMP fonctionne sur poll-mécanisme de ressource SYSLOG fonctionne sur le mécanisme push sur le périphérique
avec le serveur SNMP interrogeant le périphérique final pour envoyer les informations de journalisation
pour une réponse sur l’interface/état/ processus
TEMPS SNMP est utilisé pour obtenir des informations en SYSLOG est généralement appelé à acquérir des données
temps réel historiques
CONFIGURATION La configuration du terminal peut être effectuée via le La configuration du périphérique final ne peut pas être effectuée
set SNMP via l’ensemble syslog
DONNEE Les traps SNMP sont partagés au format binaire Les évènements syslog sont partagés en texte brut.
SECURTE SNMP sécurise SYSLOG est peu sûr
MODE Actif Passif
PORT SNMP utilise le numéro de port UDP 161/162 SYSLOG utilise les numéros de port TCP/UDP 514
 44

III. 4 Conclusion
Ce chapitre à portée une présentation détaillée de deux protocole de supervision réseau ainsi
faire une étude comparative de ces deux protocoles de supervision réseau (SYSLOG et SNMP).
 45

CHAPITRE IV : IMPACTS DU PROTOCOLE SNMP ET SYSLOG

IV.1. Introduction
Comme nous l’avions dit dans notre introduction, le protocole SNMP et SYSLOG ont un
impact positif dans la gestion et supervision réseau d’entreprise. A travers eux les taches
d’administrateur pour répondre aux besoins des utilisateurs sont simplifiées.

IV.2. Attente d'une administration réseau

L'administrateur réseau est celui qui est chargé, de la lourde tâche de s'occuper du réseau, Son
travail regroupe beaucoup de chose. A cet égard l'ISO (International standard organization)
l'organe habileté à standardiser les normes de réseau a définit l'étendue du travail
d'administration est à retenue cinq domaine fonctionnels de gestion suivant :

 La gestion des configurations ;

 La gestion des fautes ;
 La gestion de performances ;
 La gestion des sécurités ;
 La gestion des coûts ou la gestion des comptabilités.

IV.3. La gestion de la configuration

La gestion de la configuration permet de désigner et de paramétrer différents objets. Une

configuration peut être faite manuellement par un opérateur (via l'interface graphique) ou par
téléchargement complet (lors d'une réinitialisation d'un équipement par exemple).

Procédure

Les procédures requises pour gérer une configuration sont :

 La collecte d'informations ;
 Le contrôle de l'état du système ;
 Et enfin la sauvegarde de l'état dans un historique.
 46

Figure 14 Gestion de la configuration

La gestion de la configuration couvre l'ensemble des fonctionnalités suivantes :

 Démarrage, initialisation des équipements ;

 Positionnement des paramètres ;
 Cueillette des informations d'état et intervention dans les paramètres ;
 Modification de la configuration du système ;
 Association des noms aux objets gérés ;
 Changement de l'adresse IP d'une machine ;
 Changement de l'adresse IP d'un routeur ;
 Changement de la table de routage.

IV.4. La gestion des fautes

Ce domaine recouvre la détection, l'isolement et la correction des pannes survenant sur un

équipement. L'action curative qui en découle peut être faite à distance (si l'équipement répond)
ou par un contact humain qui agira sur l'équipement. Un historique des évènements est
également disponible.
 47

Figure 15 Gestion des fautes

Type de panne

Les pannes peuvent être d’origines internes, à caractère permanent (composant en pannes) ou
externes (goulets d'étranglement, trafic intense, etc.), Cette dernière est plus difficile à détecter,
car elle est à caractère aléatoire. La gestion de faute couvre l'ensemble des fonctionnalités
suivantes :

 La détection des fautes : elle comprend la préparation de rapports d'incidents de

fonctionnement, la gestion de compteurs ou des seuils d'alarme, le filtrage d'événements
par filtrage en amont des informations, l'affichage des dysfonctionnements.
 La localisation : on y procède au moyen de rapports d'alarme, de mesures et de tests.
 La réparation : elle consiste à prendre les mesures correctives (réaffectation de
ressources, routages, limitation du trafic par filtrage, maintenance), ou encore à rétablir
le service (tests de fonctionnement, gestion de systèmes de secours, etc.).
 L'enregistrement des historiques d'incidents et statistiques : la gestion des fautes ne peut
se limiter à ces actions ponctuelles, nécessaires mais insuffisantes pour donner le service
attendu. C'est la raison pour laquelle elle comporte aussi, d'une part, l'enregistrement
d'historiques d'incidents et la compilation de statistiques qui peuvent porter sur la
probabilité des pannes, leur durée, les délais de réparation et, d'autre part, un rôle
 48

d'interface avec les usagers qui consiste à les informer des problèmes réseau et à leur
donner la possibilité de signaler eux-mêmes des incidents telle que :
 La déconnexion d'un câble ;
 Une mauvaise configuration d'un équipement ;
 Une interface défectueuse d'un routeur ;
 La réinitialisation accidentelle

IV.5. La gestion de la performance

Ce domaine comprend la collecte des données et l'analyse statistique permettant la
création de tableaux de bord. Ce domaine est essentiellement lié à l'évolution du
réseau (permet de planifier les changements à apporter afin d'améliorer les
performances du réseau).

Figure 16 Gestion de performance

L'objectif est d'établir des statistiques à partir des paramètres du réseau.

 Débit ;
 Temps de réponse ;
 Taux d'erreur ;
 Temps d'établissement des connexions ;
 Elle fournit des fonctions qui permettent à des fins de planification des ressources du
réseau ;
 De recueillir des données statistiques (taux d'erreurs, temps de transit, débit, etc.) ;
 De maintenir et analyser des journaux sur l'historique de l'état du système (événements).
Les informations obtenues serviront à l'analyse et à la planification du réseau. On peut
 49

diviser cette partie en deux : l'une traitant de la gestion de la performance en temps réel
et l'autre en temps différé. Pour gérer la performance d'un réseau en temps réel, il faut
mettre en place les fonctionnalités suivantes :
 Enregistrements des mesures de performance : cela passe par l'établissement et la mise
à jour des critères et des conditions de mesure, la gestion de la collecte d'informations,
le filtrage, la compilation de statistiques, l'adoption de mesures à la demande ou encore
la gestion des fichiers de collecte.
 Surveillance de l'activité du réseau par visualisation de l'utilisation des ressources, le
signalement des dépassements de seuils et l'analyse de la performance : cela implique
une visualisation du fonctionnement du réseau (avec comme variables pertinentes par
exemple la répartition de la charge, les différents débits, les temps de réponse ou encore
la disponibilité) et une analyse des causes possibles de dépassement de seuil par
corrélation avec les pannes d'équipements, au moyen de divers indicateurs.
 Changement de configuration proactive et réactive : le fait de gérer la performance en
temps réel suppose que l'on soit capable de prendre des mesures correctives (ou
réactives) et préventives (ou proactives). La gestion réactive vise à établir lors de la
détection d'un problème de performance des mesures de réaffectation des ressources par
modification des paramètres de configuration ou par redistribution du trafic. Ces
mesures, de par leurs natures, sont prises afin de répondre à un problème déjà existant.
La gestion proactive consiste à prendre des mesures initiales permettant d'éviter d'arriver
à une situation critique. Cette tâche est effectuée en temps différé et comporte quant à
elle un ensemble de sous-tâches :
 L'analyse des informations par la compilation de statistiques, d'historiques ou encore
d'indicateurs de qualité du service ;
 L'édition de tableaux de bord et de rapports, qu'ils soient périodiques ou qu'ils soient
effectués à la demande ;
 Une certaine forme d'analyse prévisionnelle par la constitution de matrices de trafic, par
la détection de risques de saturation ou d'engorgement, par des simulations de scénarios,
par le suivi de la gestion corrective, et enfin par la planification et le dimensionnement
du réseau.

Exemples

 Relevé des pertes de connexions entre deux routeurs.

 Relevé des temps de réponse entre deux sites.
 50

IV.6. La gestion de la comptabilité

La gestion de la comptabilité permet de connaître les charges des objets gérés, les coûts de
communication, etc. Cette évaluation est établie en fonction du volume et de la durée de la
transmission.

Figure 17 Gestion de la comptabilité

Elle couvre l'ensemble des fonctionnalités suivantes :

 Les mesures sur l'utilisation des ressources, et leur enregistrement en vue d'obtenir des
historiques ;
 Le contrôle des quotas par utilisateur en faisant des mises à jour des consommations
courantes et en vérifiant les autorisations de consommation ;
 le suivi et le contrôle des dépenses par stockage et mise à jour des tarifs des opérateurs,
par gestion des tickets de taxation, par évaluation en temps réel de la consommation
courante, par vérification des factures, et enfin par suivi des coûts d'exploitation et de
matériels (investissement, amortissement et maintenance) ;
 La gestion financière : bien évidemment, on retrouve dans la gestion comptable une ;
 Partie financière qui consiste à ventiler les coûts (par service, par utilisateur ou encore
par application), à analyser et prévoir les dépenses et enfin à étudier les possibilités de
réduction des coûts ;
 51

 La facturation : finalement, l'activité de gestion comptable aboutit à une facturation

interne, ce qui implique la gestion des clients et des trafics, la production de tickets de
taxation et de factures, le contrôle de la facturation et enfin le stockage des historiques.

Exemples

 Coût d'utilisation d'un réseau RNIS.

IV.7. La gestion de la sécurité

La gestion de la sécurité est une fonction de gestion qui concerne le contrôle et la distribution
des informations utilisées pour la sécurité. Elle englobe le cryptage et la liste des droits d'accès.

Figure 18 Gestion de la sécurité

À l'appui des politiques de réseau, la gestion de réseau consiste à collecter les informations de
gestion et à les interpréter. Voici les fonctionnalités qui doivent être mises en œuvre :

 Dans ce contexte, il faut dans un premier temps assurer la sécurité relative à

l'administration de réseau elle-même, c'est-à-dire gérer les droits d'accès aux postes de
travail, gérer les droits liés aux attentes des opérateurs, et enfin les autorisations d'accès
aux informations de gestion.
 Ensuite, il faut garantir la sécurité des accès au réseau géré ; pour cela, il faut mettre en
place des mécanismes qui impliquent des fonctions telles que la définition des
 52

conditions d'utilisation, l'activation ou la désactivation des mécanismes, la modification

de certains paramètres ou encore la gestion des listes d'autorisation (aux machines, à
différents services ou à divers éléments de réseau) ; il faut évidemment en outre
effectuer un contrôle des accès (identités, horaires, temps de connexion, destination) et
une détection des tentatives d'accès frauduleuses (enregistrement, compilation de
statistiques et déclenchement d'alarmes si nécessaire).
 Enfin, il faut garantir la sécurité de l'information par la gestion de mécanismes de
protection, de cryptage et de décryptage, et par la détection d'incidents et de tentatives
de fraude. Voici les fonctions de gestion de sécurité qui doivent être mises en œuvre
pour supporter cette activité :
1. Soutien à l'authentification.
2. Contrôle et maintenance des autorisations.
3. Contrôle et maintenance des commandes d'accès.
4. Gestion des clés.
5. Maintenance et examen des fichiers de sécurité.

Exemples

 Détection d'intrusions.
 Détection d'une attaque par IP Flooding.
 Détection de virus.

IV.9. Conclusion

Ce chapitre nous a permis de démontrer les rôles que vont jouer les protocoles cités ci haut dans
un réseau d’entreprise concernant les attentes d’administration réseau. Un administrateur grâce
à ces protocoles, il ne peut pas souffrir de localiser la panne étant toujours dans son bureau
climatisé.
 53

Conclusion générale
Le travail qui arrive à terme par cette conclusion avait pour problématique : Faire le choix
d’un meilleur protocole de supervision réseau parmi tant qui existent en vue de prévenir les
erreurs, les pannes et dialoguer avec les équipements pour assurer le bon fonctionnement du
réseau. Nous avions pour objectif principal, faire une étude fonctionnelle et comparative
approfondie de deux protocoles de supervision et leurs avantages dans le réseau d’entreprise
(SNMP et SYSLOG), puis proposer le meilleur à implémenter un jour dans un réseau. C’est
ainsi que dans le premier chapitre nous avons parlé de quelques définitions de concepts
fondamentaux sur la supervision réseau, nous avons démontré les objectifs et les type de
protocoles de supervision avec leurs avantages.

De ce fait, avec la démarche UP faisant recours au langage de modélisation unifié (UML)

nous avons fait une analyse de différents scénarios du fonctionnement des protocoles SNMP
et SYSLOG, partant de l’expression de besoin jusqu’à l’analyse.

Dans Le deuxième chapitre, nous avons fait, une étude fonctionnelle du protocole SNMP et
SYSLOG, dont nous avons découvert que le SNMP a trois composants principaux (agent snmp,
mib et station snmp), qui font à ce que l’administrateur réseau soit informé à tout moment le
changement d’état d’un équipement en se base par l’envoie périodique des requêtes et par la
remonté non sollicitée des alertes qui pourront permettre à l’administrateur de prendre de
précautions nécessaires ; et alors le SYSLOG aussi a trois composants principaux qui entrent
en jeux pour la journalisation des événements des équipements (le périphérique réseau qui
génère les journaux, le relais Syslog qui transmet les journaux à un collecteur et le collecteur
Syslog (ou serveur) qui recevra et stockera les journaux). Il travaille en mode
Client/Serveur,Son intérêt est la centralisation de tous les messages des équipements du réseau
pour faciliter le dépannage. Lorsqu’un problème survient, on peut facilement retrouver sa
source en consultant les logs du serveur SYSLOG sans avoir à analyser chaque équipement du
réseau un par un.

Dans le troisième chapitre, nous avons fait une étude comparative entre ces deux
protocoles de supervision du point de vue :

 fonctionnelle : SNMP fonctionne sur poll-mécanisme de ressource avec le serveur

SNMP interrogeant le périphérique pour une réponse sur l’interface/état/ processus ;
tandis que SYSLOG lui fonctionne sur le mécanisme push sur le périphérique final pour
envoyer les informations de journalisation.
 54

 Sécuritaire : SNMP est sécurise ; alors que SYSLOG est peu sûr.
 Configuration : La configuration du terminal peut être effectuée via le set SNMP ; mais
du côté SYSLOG La configuration du périphérique final ne peut pas être effectuée via
l’ensemble syslog.
 Temporelle : SNMP est utilisé pour obtenir des informations en temps réel ; alors que
SYSLOG est généralement appelé à acquérir des données historiques.

Partant de cette étude comparative faite entre ce deux protocoles, nous trouvons que le protocole
SNMP et le plus meilleur par rapport au protocole SYSLOG quoi qu’il précise la période dont
l’équipement était tombé en panne.

Et enfin, dans le quatrième chapitre nous avons conclu en disant que les protocoles de
supervision ont un impact positif non négligeable dans le réseau d’entreprise, car ils font à ce
que l’administrateur gère tous les équipements comme si ces derniers étaient atour de lui dans
le bureau climatisé. Et comme perspective, nous aimerions envisager nos recherches pour
passer à l’implémentation du protocole SNMP Un jour dans un réseau d’entreprise.
 55

Bibliographie

[1] CLEVER, Le monitoring, la Supervision et ses principaux protocoles reseaux, paris: Clever
technolhie, 16 juillet 2020.

[2] A. Trabelsi, dans l'etude et Mise en place d’un outil de supervision système et réseau open source,
a Tunis: a l'Université Virtuelle de Tunis, en 2014-2015.

[3] J.-L. Archimbaud, Cours Interconnexion et conception de réseaux informatiques, Ecole

d’ingénieurs réseaux, 2015.

[4] a. cisco, Modélisation Hiérarchique du Réseau informatique, [Link], 2009.

[5] Y. K. FOUOLAP, Supervision réseau et monitoring des onduleurs, Université des Montagnes,
2011.
 56

Table des matières

INTRODUCTION GENERALE .......................................................................................................... 4
CHAPITRE I. GENERALITE SUR LA SUPERVISION RESEAU .............................................. 10
I.1 Introduction partielle ................................................................................................................ 10
I.2. La supervision ........................................................................................................................... 10
I.2.1. Objectif de la supervision .................................................................................................. 10
I.2.2. Principe de la supervision ................................................................................................. 10
I.3. Les types de supervision en informatique ............................................................................... 11
I.3.1. Supervision système ........................................................................................................... 11
I.3.2. Supervision des applications ............................................................................................ 11
I.3.3. Supervision Réseau ............................................................................................................ 11
1.4. Administration réseau .............................................................................................................. 13
I.4.1. Les protocoles d’administration ....................................................................................... 13
I.4.1.2. SNMP (Simple Network Management Protocol) ......................................................... 14
I.4.2 RESEAU .............................................................................................................................. 15
I.5. Principes fonctionnels et structuration d’un système d’administration réseau .................. 16
I.5.1. Supervision selon La norme ISO 7498/4 .......................................................................... 16
I.5.2. Gestion des performances ................................................................................................. 16
I.5.3. Gestion des configurations (Management Configuration) ............................................. 17
I.5.4. Gestion de la comptabilité (Accounting Management) .................................................. 17
I.5.5. Gestion des anomalies (Fault Management) .................................................................... 17
I.5.6. Gestion de la sécurité (Security Management) ................................................................ 17
I.6. Présentation du protocoles netflow ......................................................................................... 17
I.6.1. Architecture du NetFlow ................................................................................................... 18
I.6.2. Flux Réseau NetFlow ......................................................................................................... 18
I.7. Les outils de supervision........................................................................................................... 18
I.7.1. NAGIOS.............................................................................................................................. 18
I.7.2. Centreon ............................................................................................................................. 19
I.7.3. ZABBIX .............................................................................................................................. 19
I.7.4. PRTG .................................................................................................................................. 19
I.8. Comparaison des outils de supervision ................................................................................... 21
CHAPITRE II. ÉTUDE FONCTIONNELLE DE PROTOCOLES SNMP ET SYSLOG ........... 23
II.2. La protocoles SNMP ................................................................................................................ 23
II.2.1 Présentation générale ........................................................................................................ 23
II.2.2 Principe de fonctionnement du protocole SNMP ........................................................... 23
II.3 L’environnement de gestion SNMP.......................................................................................... 23
 57

II.4 Fonctionnement......................................................................................................................... 24
II.4.1 L'agent SNMP ................................................................................................................... 24
II.5 LA PROTOCOLES SYSLOG .................................................................................................... 31
II.5.1 Présentation Syslogd.......................................................................................................... 31
II.6 FONCTIONNEMENT DE SYSLOG ..................................................................................... 32
II.6.1 Diagramme de cas d’utilisation Syslog ............................................................................ 32
II.7 le message syslog ........................................................................................................................ 34
II.8 Conclusion ..................................................................................................................................... 35
CHAPITRE III : ETUDE COMPARATIVE DU PROTOCOLE SNMP ET SYSLOG.............. 36
III.O INTRODUCTION ................................................................................................................. 36
III. I PROTOCOLE SYSLOG ....................................................................................................... 36
III.1.1 Alerter avec Syslog........................................................................................................... 36
III.1.2 Alerter avec prudence ..................................................................................................... 38
III.2 Le protocole SNMP................................................................................................................. 39
III.2.1 présentation ...................................................................................................................... 39
III.2.2La sécurité ......................................................................................................................... 40
III.2.3 Fonctionnement pratique ................................................................................................ 41
III.3 Les implémentations existantes du protocole SNMP ........................................................... 42
III. 4 Conclusion .................................................................................................................................. 44
CHAPITRE IV : IMPACTS DU PROTOCOLE SNMP ET SYSLOG .......................................... 45
IV.1. Introduction ............................................................................................................................ 45
IV.2. Attente d'une administration réseau .................................................................................... 45
IV.3. La gestion de la configuration ............................................................................................... 45
IV.4. La gestion des fautes .......................................................................................................... 46
IV.5. La gestion de la performance ................................................................................................ 48
IV.6. La gestion de la comptabilité............................................................................................. 50
IV.7. La gestion de la sécurité......................................................................................................... 51
Conclusion générale ............................................................................................................................ 53
Bibliographie........................................................................................................................................ 55