INTRODUCTION GENERALE

Les équipements informatiques indispensables à des structures de nos jours

présentent certaines difficultés à savoir la gestion des serveurs distants et le monitoring de ses
équipements étant le plus grand souci de l’administrateur. Tout problème ou panne peut avoir
de lourdes conséquences aussi bien financières qu’organisationnelles. La supervision des
réseaux est alors nécessaire et indispensable d’où l’apparition du mot Monitoring qui nous
présente le thème d’aujourd’hui « NAGIOS ». De ce, de quoi s’agit-il ? Quel est son mode de
fonctionnement ?quel est son avantage ? Voilà les questions quel nous nous attèlerons à
répondre durant notre devoir.

1
 I- HISTORIQUE

Nagios est un logiciel libre distribué sous licence GPL qui permet de superviser un système
d’information complet. Utilisé par de nombreuses sociétés, il fait l’objet de contribution et
recherche très actives.

Etant le successeur de NetSaint dont la première version date de 1999, ce logiciel est
considéré comme une évolution de ce dernier auquel a été ajoutée, entre autre, la gestion du
protocole SNMP. Il apparaît sous le nom de Nagios le 10 mai 2002 aux conditions de la GNU
General Public License. Cet outil repose sur une plate-forme de supervision, fonctionnant sous
Linux et sous la plupart des systèmes Unix. Il centralise les informations récoltées
périodiquement par le fonctionnement modulaire dont il est caractérisé, ce qui le rend beaucoup
plus attractif que ses produits concurrents. En revanche sa configuration peut se révéler
complexe.

Le développeur principal est Ethan Galstad.

• Mars 1999 : première version de NetSaint
• Mars 2002 : dernière version de NetSaint
• Novembre 2002 : première version stable de Nagios 1.0
• Courant 2005 : sortie de la version 2.0 de Nagios
• Mars 2008 : sortie de la version 3.0 de Nagios
• Mars 2010 : dernière version stable 3.2.3.

2
 II- PRESENTATION

Nagios (anciennement appelé Netsaint) est une application permettant la surveillance système
et réseau. Elle surveille les hôtes et services spécifiés, alertant lorsque les systèmes ont des
dysfonctionnements et quand ils repassent en fonctionnement normal. C'est un logiciel libre
sous licence GPL.

Pour vouloir monitorer un système informatique individuel, une base de données ou un serveur,
il n’est pas nécessaire d’installer le logiciel sur chaque dispositif, en effet l’installer sur un
serveur Nagios séparé est amplement suffisant. A partir de là nous pouvons simplement
configurer quel système ou quel processeur doit être surveillé. Tout cela s’articule autour des
quatre composants ou objets suivants :

 Hôte : en tant que hôte, vous définissez les serveurs, bases de données et appareils, etc.
du réseau que vous souhaitez surveiller. L’indicateur le plus important pour un hôte est
l’adresse IP respective.

 Services : avec ce composant vous pouvez définir quelles caractéristiques de l’hôte

Nagios doit vérifier. Cela peut aussi être les services en cours d’exécution sur l’hôte
(http, FTP, etc.), des attributs internes comme l’espace disque disponible mais aussi des
caractéristiques physiques comme la température de votre matériel.

 Commandes : avec ce volet vous contrôlez la séquence de monitorage. Vous pouvez

configurer la façon dont la surveillance des hôtes et des services doit être conçu et quand
Nagios doit vous avertir quand un évènement se produit.

 Contacts : avec la définition des contacts, Nagios peut alors envoyer des notifications
à des contacts administratifs via un email, un message texte ou encore un message vocal.

Même si Nagios n’est pas installé sur les différents hôtes, les plugins (qui vérifient les données
internes) fonctionnent eux directement sur les hôtes. L’accès à distance peut également être
utilisé pour cette exécution, mais cette méthode est rarement employée puisqu’elle demande
plus d’effort et l’utilisation d’un système disproportionnée (avec une connexion sécurisée).
C’est pourquoi l’alternative la plus simple est l’installation de programmes spécifiques sur les
hôtes. Cela s’effectue seulement à partir des requêtes du système qui sont préconfigurées
et transmettent les résultats via les ports réseau vers le serveur Nagios. Le NRPE (Nagios

3
Remote Plugin Executor) est utilisé par défaut et avec cette combinaison, Nagios peut aussi
monitorer les systèmes Windows.

C'est un programme modulaire qui se décompose en trois parties :

1. Le moteur de l'application qui vient ordonnancer les tâches de supervision.

2. L'interface web, qui permet d'avoir une vue d'ensemble du système d'information et des
possibles anomalies.
3. Les sondes (appelées greffons ou plugins), une centaine de mini programmes que l'on
peut compléter en fonction des besoins de chacun pour superviser chaque service ou
ressource disponible sur l'ensemble des ordinateurs ou éléments réseaux du SI.

Vu le manque de réactivité du développeur principal de Nagios et sa volonté de ne plus diffuser

tous les modules sous licence libre, certains développeurs actifs sur le projet ont fait diverger
Nagios pour créer Icinga . Rebaptisé en 2002, il tire alors son nom du grec άγιος (agios)
signifiant saint. Puis en rétro acronymie Nagios Ain’t Gonna Insist On Sainthood.

 Superviser des services réseaux : (SMTP, POP3, HTTP, NNTP, ICMP, SNMP,
LDAP, etc.)
 Superviser les ressources des serveurs (charge du processeur, occupation des disques
durs, utilisation de la mémoire paginée) et ceci sur les systèmes d'exploitation les plus
répandus.
 Interface avec le protocole SNMP.
 La supervision à distance peut utiliser SSH ou un tunnel SSL (notamment via un agent
NRPE).
 Les plugins sont écrits dans les langages de programmation les plus adaptés à leur
tâche : scripts shell (Bash, ksh, etc.), C++, Perl, Python, Ruby, PHP, C#, etc.
 La vérification des services se fait en parallèle.
 Possibilité de définir une hiérarchie dans le réseau pour pouvoir faire la différence
entre un serveur en panne et un serveur injoignable.
 La remontée des alertes est entièrement paramétrable grâce à l'utilisation de plugins
(alerte par courrier électronique, SMS, etc.).
 Acquittement des alertes par les administrateurs.
 Gestion des escalades pour les alertes (une alerte non acquittée est envoyée à un
groupe différent).

4
  Limitation de la visibilité, les utilisateurs peuvent avoir un accès limité à quelques
éléments.
 Capacité de gestion des oscillations (nombreux passages d'un état normal à un état
d'erreur dans un temps court).
 Créer ses propres plugins, dans le langage désiré. Il suffit de respecter la norme
Nagios des Codes retour
o 0 OK (tout va bien)
o 1 WARNING (le seuil d'alerte est dépassé)
o 2 CRITICAL (le service a un problème)
o 3 UNKNOWN (impossible de connaître l'état du service)
 Les possibilités de tests deviennent donc infinies, il suffit d'écrire tout plugin qui
n'existerait pas déjà sur les sites spécialisés.

III- PRINCIPE DE FONCTIONNEMENT

1- Fonctionnalité
 Nagios est un système de surveillance de services réseau (SMTP, HTTP…) et de
ressources système (CPU, espace disque…).
 Plus précisément, dans la terminologie Nagios, il s'agit de monitorer des services et des
hosts, chaque service étant affecté à un host ou à un groupe de hosts. A un instant "t",
un host se trouve dans un état down, unreachable ou ok, et un service dans un état
critical, warning, unknown ou ok.
 Conceptuellement, Nagios est un moteur :

o d’acquisition d’états de hosts et de services (checks),

o de déclenchement conditionnel d’actions préventives et curatives (handlers), et
o de déclenchement conditionnel de notifications.

Ces acquisitions, actions et notifications sont assurées par des plugins.

5
  L'outil s'adresse aussi bien à de petites infrastructures (une dizaine de service) qu'à des
architectures conséquentes (plusieurs milliers de serveurs repartis sur plusieurs sites)
pour lesquelles il propose un modèle de supervision distribuée.
 Nagios offre une interface web qui permet de visualiser l'état des services et des hosts
que l'on veut surveiller (tableau de bord). Cette interface web permet également
l'administration (très partielle) du monitoring.

Autres fonctionnalités

 Le déclenchement d'une acquisition d'état est normalement à l'initiative de Nagios : cela

s'appelle un active check. Mais Nagios est aussi à l'écoute pour recevoir des états de
services/hosts de toute provenance (déclenchés par exemple par cron jobs) : ce sont les
passive checks.
 L'envoi d'alertes, hautement paramétrable, peut se faire par mail, par SMS, etc. Une
personnalisation est possible par host, par service, par état, par destinataire (contact),
suivant le jour de la semaine, suivant l'heure de la journée, etc. Les alertes peuvent être
réémises périodiquement, et peuvent s'escalader : par exemple, on peut faire en sorte
que le weekend, l'équipe d'astreinte reçoive les alarmes en premier, et qu'en cas de
problèmes persistants, toute l'équipe d'exploitation soit automatiquement avertie.
 Lorsqu'un problème est décelé, le host ou le service passe d'abord dans un état de type
soft : il est en alarme dans le tableau de bord, mais les alertes ne sont pas encore
envoyées et il est possible de tenter de le résoudre en exécutant un handler (par exemple
en effaçant les fichiers temporaires sur une partition pleine). Après plusieurs checks et
tentatives de résolution infructueuse (dont le nombre est paramétrable par service/host),
l'état passe dans le type hard, et les alertes sont envoyées.
 Il est possible de programmer des périodes de maintenance (scheduled downtime) pour
un host donné. Pendant ces périodes, l'envoi d'alarmes relatives à ce hosts est suspendu.

Interopérabilité

 Les plugins sont des programmes autonomes, développés et distribués indépendamment

du moteur Nagios. Une distribution de plusieurs dizaines de plugins, sous forme de
petits programmes C, scripts shell et Perl, est téléchargeable sur le site officiel.

6
  La description de l’infrastructure à monitorer (hosts, services, etc.) et du contexte
(contacts, commandes, périodes, etc.) est exprimée dans un formalisme objet (avec
notion d'héritage), sous forme de fichiers textes.
 Il existe nombre d'outils permettant de générer cette base de données d'objets
(notamment via une interface web).
 Les états courants des hosts/services sont mémorisés dans des fichiers textes et exprimés
dans un formalisme objet.
 Les informations collectées sont archivées dans des logs au format texte. L’addon
NDOutils, téléchargeable sur le site officiel, permet de stocker ces informations dans
une base MySQL.
 D'autres addons sont téléchargeables sur le site officiel, les deux plus connus étant
NRPE et NSCA, qui permettent de faire du client/serveur entre Nagios et ses plugins.

Toutes ces fonctionnalités sont assurées grâce la gestion et supervision du réseau et ses
différentes entités d’une manière centralisée. La figure suivante modélise cet aspect :

Figure 1 : Centralisations d'informations par Nagios

7
 2- Architecture

L’architecture de Nagios se base sur le paradigme serveur-agent. D’une manière

spécifique, un serveur faisant office de point central de collecte des informations tandis que les
autres machines du réseau exécutent un agent chargé de renvoyer les informations au serveur.
L’architecture globale de Nagios peut être décomposée en 3 parties coopératives entre elles :
 Un noyau qui est le cœur du serveur Nagios, lancé sous forme de démon et responsable de
la collecte et l’analyse des informations, la réaction, la prévention, la réparation et
l’ordonnancement des vérifications (quand et dans quel ordre).
C’est le principe de répartition des contrôles au mieux dans le temps qui nous évite la surcharge
du serveur et des machines à surveiller.
 Des exécutants : ce sont les plugins dont un grand nombre est fourni de base, responsables
de l’exécution des contrôles et tests sur des machines distantes ou locales et du renvoie des
résultats au noyau du serveur Nagios.
 Une IHM : C’est une interface graphique accessible par le web conçue pour rendre plus
exploitable les résultats. Elle est basée sur les CGI (Common Gateway Interface) fournis
par défaut lors de l’installation de Nagios qui interprètent les réponses des plugins pour les
présenter dans l’interface.
Cette interface sert à afficher de manière claire et concise une vue d’ensemble du
système d’information et l’état des services surveillés, de générer des rapports et de visualiser
l’historique. D’une manière générale avoir la possibilité de détecter en un simple coup d’œil,
les services ou hôtes ayant besoin d’une intervention de leur administrateur.
Il est possible de coupler Nagios à une base de données MySQL ou Postgres, lorsque le
nombre d’objets à superviser devient conséquent. La figure suivante modélise l’architecture de
Nagios.

Figure 2: Architecture de Nagios

8
 3- Plugins

Nagios fonctionne grâce à des plugins écris en Perl ou en C. Sans eux, il est totalement
incapable de superviser et se résume en un simple noyau.

Ces plugins sont des programmes externes au serveur, des exécutables qui peuvent se
lancer en ligne de commande afin de tester une station ou service. Ils fonctionnent sous le
principe d’envoi de requêtes vers les hôtes ou services choisis lors d’un appel du processus de
Nagios, et la transmission du code de retour au serveur principale qui par la suite se charge
d’interpréter les résultats et déterminer l’état de l’entité réseau testée.

La relation entre le noyau et les plugins est assuré d’une part par les fichiers de configuration
(définitions des commandes) et d’autre part par le code retour d’un plugin. Cette relation peut
se résumer par le tableau suivant:

Tableau 1 : Signification des codes de retours

Nagios est livré avec un « package » de greffons standards regroupant les plus utilisés. Pour
une utilisation basique et simple, ils devraient être suffisants. En voilà quelques exemples:

 check_http : Vérifie la présence d'un serveur web.

 check_load : Vérifie la charge CPU locale.
 check_ping : Envoie une requête Ping à un hôte.
 check_pop : Vérifie la présence d'un serveur POP3.
 check_procs : Compte les processus locaux.
 check_smtp : Vérifie la présence d'un serveur SMTP.
 check_snmp : Envoie une requête SNMP (passée en argument) à un hôte.

9
 check_ssh : Vérifie la présence d'un service SSH.
 check_tcp : Vérifie l'ouverture d'un port TCP (passé en argument).
 check_users : Compte le nombre d'utilisateurs sur la machine locale.

Il est possible de créer son propre plugin et l’interfacer avec Nagios tout en respectant les
conventions des codes de retours précédemment expliqués. La vivacité de la communauté Open
Source et celle de Nagios 2 en particulier permet de disposer d'un grand nombre de plugins
supplémentaires. Comme on peut le constater sur la figure suivante, les plugins peuvent
fonctionner soit en effectuant des tests en local, à distance par le biais de divers moyen comme
l’installation des agents NRPE ou NSClient ou autres.

Figure 3 : Principe de fonctionnement des plugins

4- Les fichiers de configuration

Nagios s'appuie sur différents fichiers textes de configuration pour construire son
infrastructure de supervision. Nous allons à présent citer et définir ceux qui sont les plus
importants :

 Nagios.cfg est le fichier de configuration principal de Nagios. Il contient la liste des

autres fichiers de configuration et comprend l'ensemble des directives globales de
fonctionnement.
 Cgi.cfg contient un certain nombre de directives qui affectent le mode de
fonctionnement des CGI. Il peut être intéressant pour définir des préférences concernant
l'interface web de Nagios.

10
 Resource.cfg permet de définir des variables globales réutilisables dans les autres
fichiers. Etant inaccessible depuis les CGI qui génèrent l'interface, ce fichier peut être
utilisé pour stocker des informations sensibles de configuration.
 Commands.cfg contient les définitions des commandes externes, telles que celles qui
seront utiles pour la remontée d'alerte.
 Checkcommands.cfg contient les définitions des commandes de vérification
prédéfinies et celles définies par l'utilisateur.
 Hosts.cfg définit les différents hôtes du réseau à superviser. A chaque hôte est associé
son nom, son adresse IP, le test à effectuer par défaut pour caractériser l'état de l'hôte,
etc.
 Services.cfg associe à chaque hôte ou à chaque groupe d'hôtes l'ensemble des services
qui doivent être vérifiés.
 Hostsgroups.cfg définit des groupes d'hôtes pour regrouper des hôtes selon des
caractéristiques communes. Un hôte peut appartenir à plusieurs groupes.
 Contacts.cfg déclare les contacts à prévenir en cas d'incident et définit les paramètres
des alertes (fréquences des notifications, moyens pour contacter ces personnes, plages
horaires d'envoi des alertes...).

11
IV- LES VARIABLES DU MODELE NAGIOS

Mars 1999 : première version de NetSaint

• Mars 2002 : dernière version de NetSaint
• Novembre 2002 : première version stable de Nagios 1.0
• Courant 2005 : sortie de la version 2.0 de Nagios
• Mars 2008 : sortie de la version 3.0 de Nagios
• Mars 2010 : dernière version stable 3.2.3.

12
 V- LA SECURITE
Pour une meilleure sécurité

Utilisez un serveur de supervision dédié. Je vous recommande d'installer Nagios sur un

serveur dédié à la supervision (et à d'autres tâches d'administration éventuellement). Protégez
votre serveur de supervision comme si c'était l'un des plus importants de votre réseau.
Maintenez le nombre de services à tourner le plus bas possible et protégez leurs accès avec des
wrappers TCP, des pare-feu, etc. Vu que le serveur Nagios est autorisé à discuter avec vos
serveurs et peut traverser des pare-feu, autoriser des accès utilisateurs sur votre serveur de
supervision peut représenter un risque de sécurité. Gardez à l'esprit qu'il est plus facile d'obtenir
des privilèges root au travers d'un trou de sécurité quand vous avez un compte local est
disponible sur une machine.

Ne pas faire fonctionner Nagios en tant que root ! Il n'est pas nécessaire d'être root
pour faire fonctionner Nagios, alors ne le faîte pas. Vous pouvez obliger Nagios à abandonner
des privilèges après le lancement et à fonctionner avec les droits d'un autre utilisateur/groupe
en utilisant les paramètres nagios_user et nagios_group dans le fichier principal de
configuration. Si vous avez besoin d'exécuter des gestionnaires d'événements ou des plugins
qui requièrent des accès root, vous pouvez essayer d'utiliser sudo.

Verrouillez le répertoire des résultats de contrôle. Assurez-vous que seul

l'utilisateur nagios à le droit de lecture/écriture sur le répertoire des résultats de contrôle. Si
d'autres utilisateurs que nagios (ou root) sont capables d'écrire dans ce répertoire, ils peuvent

13
potentiellement envoyer des résultats de contrôles erronées au démon Nagios. Cela pourrait
vous valoir quelques désagréments comme des notifications erronées ou des problèmes de
sécurité (gestionnaires d'événements déclenchés).

Verrouillez le fichier des commandes externes. Si vous activez les commandes

externes, assurez-vous d'avoir les permissions appropriées sur le répertoire
/usr/local/nagios/var/rw. Vous voulez uniquement que les utilisateurs Nagios
(habituellement nagios) et web (habituellement nobody, http, apache2 ou www-data) puissent
écrire dans le fichier des commandes. Si vous avez installé Nagios sur une machine dédiée à
la supervision et aux tâches d'administration qui n'a pas de comptes publics, cela devrait aller.
Si vous l'avez installé sur une machine publique ou multi-utilisateurs (pas recommandé),
autoriser l'utilisateur du serveur web peut être un problème de sécurité. Après tout, vous ne
souhaitez pas que n'importe quel utilisateur du système puisse contrôler Nagios à partir du
fichier des commandes externes. Dans ce cas, je vous suggère de donner les droits
uniquement à l'utilisateur nagios et d'utiliser quelque chose comme CGI Wrap pour faire
fonctionner les CGIs avec l'utilisateur nagios plutôt que nobody.

Authentification requise pour les CGIs. Je vous recommande fortement de

protéger l'accès aux CGIs par une authentification. Ceci fait, lisez la documentation sur les
droits par défaut dont disposent les contacts autorisés et n'accordez qu'exceptionnellement une
autorisation à des contacts spécifiques. Les instructions pour la configuration des droits se
trouvent ici. Si vous désactivez l'authentification préalable à l'accès aux CGIs par la
commande use_authentication dans le fichier de configuration des CGIs, le CGI de
commande refusera d'écrire la moindre commande dans le fichier des commandes externes.
De toute façon, vous ne souhaitez pas que tout le monde puisse contrôler votre Nagios ?

Implémentez les mesures renforcées de sécurité des GCIs. Je vous recommande

chaudement de considérer l'implémentation des mesures de sécurité pour les CGIs comme
indiqué ici. Ces mesures peuvent aider à s'assurer que l'utilisateur/mot de passe que vous
utilisez pour accéder à l'interface web de Nagios ne puisse intercepter par de tierces parties.

Utilisez les chemins complets dans la définition des commandes. Lorsque vous
définissez des commandes, assurez-vous d'avoir bien précisé le chemin d'accès complet de
tous les scripts ou binaires que vous exécutez.

14
 Cachez les informations sensibles à l'aide des macros $ARGn$. Les CGIs
parcourent le fichier de configuration principal et le(s) fichier(s) de configuration des objets,
n'y laissez donc pas d'informations sensibles (noms d'utilisateur, mots de passe, etc.). Si vous
avez besoin de préciser un mot de passe ou un nom d'utilisateur dans une définition de
commande, utilisez $USERn$ macro pour le cacher. $USERn$ Les macros $USERn$ sont
définies dans un ou plusieurs fichiers de ressources. Les CGIs ne parcourant pas les fichiers
de ressources, vous pouvez leur donner des permissions beaucoup plus restrictives (600 ou
660). Consultez le fichier resource.cfg dans la distribution de base de Nagios, il vous
donnera un exemple de définition de la macro $USERn$.

Éliminez les caractères dangereux des macros. Utilisez le paramètre

illegal_macro_output_chars pour filtrer les caractères dangereux des chaînes issues des
macros $HOSTOUTPUT$, $SERVICEOUTPUT$, $HOSTPERFDATA$ et $SERVICEPERFDATA$ avant
qu'elles ne soient utilisées pour des notifications, etc. Des caractères dangereux peuvent être
tout caractère qui peut être interprété par un shell, ouvrant ainsi un trou de sécurité. Un bon
exemple est la présence de la quote inverse (`) dans $HOSTOUTPUT$, $SERVICEOUTPUT$,
$HOSTPERFDATA$, et/ou $SERVICEPERFDATA$ qui pourrait permettre à un attaquant d'exécuter
un commande arbitraire comme l'utilisateur nagios (une autre bonne raison pour ne pas
exécuter Nagios avec l'utilisateur root).

Sécurisez l'accès aux agents distants. Assurez-vous d'avoir verrouiller l'accès aux
agents (NRPE, NSClient, SNMP, etc.) sur les systèmes distants en utilisant des pare-feu, des
listes d'accès, etc. Vous ne voulez pas que n'importe qui soit capable d'interroger vos systèmes
sur leurs états. Cette information peut être utilisée par un attaquant pour exécuter des
gestionnaires d'événements distants ou pour déterminer une fenêtre de temps pour une attaque
discrète.

15
 Sécurisez vos canaux de communication. Assurez-vous d'avoir chiffré les canaux de
communication entre vos différents serveurs Nagios et entre Nagios et les agents de supervision
quand cela est possible. Vous ne voulez pas que quelqu'un puisse sniffer les informations d'états
lorsqu'elles transitent sur le réseau. Ces informations peuvent être utilisées par un attaquant
pour déterminer un intervalle de temps pour une attaque discrète.

Choix du logiciel
Les différentes solutions commerciales déjà présentées (HPOpenview, Patrol,
BigBrother, etc..) nécessitent un investissement important pour leur mise en place, et pour des
raisons propres à l’entreprise, toutes ces solutions sont à écarter de mon liste de choix. Parmi
les solutions les plus connues, recommandées et surtout Libres, on citera Nagios et Zabbix.
Voici un tableau comparatif des deux logiciels choisis.

Présentation -Open source, libre -Open source, Libre.

-Multiplateformes -Conçu pour les plateformes
-Homogène. Unix.
-Moteur en C, interface web -Modulaire.
utilisateur en PHP, base de données -Moteur en C, perl, Sharp…,
SQL (MySQL, Oracle…) interface web en PHP, base de
-Configuration centralisée sur une données SQL.
même interface graphique. -Configuration plus ou moins
Peut monitorer de 3 manières : complexe
-LANCEMENT d’un processus sur les Peut monitorer de 2
machines à monitorer pour collecter manières:
des données locales, grâce à l’agent -L’utilisation des journaux
Zabbix (obtenir des infos sans utiliser d’exploitation par l’envoie des
SNMP). évènements issus des fichiers

16
 -Requêtes SNMP. log en temps réel vers un serveur
-Check externes qui sert à tester les centrale offrant les informations
services réseaux (rien à installer sur nécessaires à la supervision.
l’équipement surveillé, tests limités à -Supervision active des services
des pings ou test de protocoles). et infrastructure qui nous
permet de garder l’historique
des performances.
Fonctionnalités -Offre une interface web de -Offre une interface web basée
consultation et d’administration. sur les CGL avec gestion des
-Peut générer des graphes. droits pour la consultation.
-Peut lever des alertes en envoyant -Génère des rapports de
des mails. surveillance.
-Supervise des équipements SNMP. - -Il a la possibilité de monitorer à
Gère les pannes et les performances distance à travers un firewall.
-Il peut définir des serveurs
esclaves qui prennent le relais si
le serveur maitre tombe en
panne.
-Surveillance des ressources des
serveurs (CPU, mémoire…)
-Surveillance des services
réseaux.
-Arrêt temporaire de la
supervision locale ou globale.
-Génère des graphes par
l’interfaçage avec RRDTools.
Architecture Architecture généralement basée sur Architecture généralement
: -Serveur Zabbix, le cœur et moteur basée sur :
de l’application programmé en C. -Le moteur de l’application qui
-Agent Zabbix pour la collection des sert à ordonnancer les tâches de
informations locales. supervision écrit en C.
-Une interface web d’administration -Une interface web réalisée à
et consultation des données. l’aide des GCI, décrivant la vue
-Une base de données SQL.

17
 d’ensemble su système et les
anomalies possibles.
-Plusieurs plugins qui peuvent
être complétés en fonction des
besoins.

VI- FONCTIONNEMENT PRATIQUE

On commence par mettre à jour le système en saisissant les commandes suivantes:

# sudo apt-get update

# sudo apt-get upgrade

Dans cette série d'articles nous allons avoir besoin de compiler des sources de logiciels, il faut
donc dans un premier temps installer le package "build-essential" qui comporte les librairies de
développement de bases:
# sudo apt-get install build-essential

18
Nagios offre aux utilisateurs une interface de type Web. Il faut donc installer un serveur http
sur notre machine de supervision. On ne va pas être très original... On va utiliser Apache 2.
Bien qu’il soit possible d’utiliser des solutions plus légères et rapides comme Nginx.
# sudo apt-get install apache2 wget

19
Pour des raisons évidentes de sécurité, le processus Nagios ne sera pas lancé en root (droit
administrateur). Nous allons créer un utilisateur système nommé nagios et un groupe associé
également nommé nagios. Le groupe nagios comprendra les utilisateurs nagios et www-data
(utilisateur avec lequel le serveur Apache est lancé par défaut).

On commence par décompresser les sources:

Nous allons lancer la compilation grâce aux commandes suivantes:

Se placer dans le répertoire nagios-4.3.4 en utilisant la commande cd

Une fois la fin de cette commande ; exécutons les commandes suivantes :

20
21
On installe ensuite le script de démarrage pour que Nagios se lance automatiquement avec votre
serveur de supervision:

Il faut ensuite installer l’interface Web:

Nous allons donc tester les fichiers de configuration grâce à la commande suivante:

22
Ensuite, on peut lancer le serveur Nagios

Il ne reste plus qu'à lancer un navigateur Web sur un PC de votre réseau et à saisir l'URL
suivante (attention de bien mettre le / à la fin de l’URL): http : //l’adresse IP du
serveur/nagios/

Après une bannière d'authentification (login: nagiosadmin / password: <votremotdepasse>),

nous devrions voir s'afficher:

23
24
 VII- AVANTAGES ET INCONVENIENTS

Avantages

Performance, disponibilité, configuration et opération

 Une offre complète, évolutive et pérenne

 Chef d'orchestre de l'offre globale et intégrée d'administration des infrastructures
 Supervision de l'infrastructure (matériels, logiciels, et réseaux) au niveau de chaque
composant comme de toute l'entreprise ou en fonction d'un système métier
 Centralisation de l'administration d'une infrastructure hétérogène et globale
 Des logiciels multiplateformes, ouverts et sécurisés
 Support technique IBM de qualité

Administration du stockage

 Solution modulaire et extensible

 Les versions Express destinées aux PME-PMI sont à faible coût et d'une extrême
simplicité de mise en œuvre
 Stockage des sauvegardes et des archives sur des équipements hors-ligne
 Solution intégrée de gestion du stockage
 Solution haute performance, fiable et éprouvée
 Automatisation complète des activités
 Secours de site et des données intégré
 Solution ouverte et multiplateformes
 Support technique IBM de qualité

Sécurité

 Solution complète et évolutive pour une gestion centralisée de la sécurité et du

contrôle d'accès

25
  Réutilisation des composants sécuritaires dans le développement d'application
 Solution ouverte et multiplateformes
 Support technique IBM de qualité

INCONVENIENTS

Bien que Nagios soit l’outil de supervision le plus utilisé, il dispose de plusieurs handicapes à savoir :
 Le déploiement de l’agent assez robuste
 Configuration compliquée qui oblige une très bonne connaissance de Nagios
 Graphes pas assez clairs.
 Administration compliquée.

Face à tous ces problèmes, on ne pourrait dit de Nagios un outil irréprochable.

26
 CONCLUSION GENERALE

La supervision est devenue indispensable dans tout système d’information. Elle

est à la base du bon fonctionnement d’une architecture réseau et permet de réagir rapidement
en cas de problèmes ou pannes. Elle se base à l’heure actuelle principalement sur le protocole
SNMP qui depuis de nombreuses années a quand même du mal à évoluer. En effet, de nombreux
logiciels sont encore basés sur la version 1 du protocole qui commence un peu à vieillir et qui
n’est pas du tout sécurisé. En effet la version 2, apportant notamment la sécurité n’a été qu’une
phase de transition vers la version 3 et 4 qui est encore très peu utilisée. Les logiciels de
monitoring sont très nombreux qu’ils soient du monde du libre ou propriétaires et supportent
les principales plateformes des systèmes d’information. La plupart sont encore basés sur le
protocole SNMP.

27
 WEBOGRAPHIE

1- How To Install Nagios Core 4.1.1 In Ubuntu 15.10_16.04 _ Unixmen.html consulté le

07/09/2017 à 21h45
2- http://Mémoire Online.com/download/document nagios-pdf/2013/10.html(Etude et mise en œuvre
d’un serveur de supervision réseau) rapport de AWAWOU Viviane consulté le 19/09/2016 à 17h25
3- http://blog.nicolargo.com/2008/07/mise-a-jour-des-plugins-dansnagios.html (téléchargement et
installation des plugins de nagios) consulté le 08/09/2017 à 00h35

28