PLAN DÉTAILLÉ – Rapport Technique : Supervision Réseau

Avancée avec Nagios

1. Introduction
Thought for a couple of seconds
Dans le contexte actuel où les entreprises s’appuient sur des infrastructures informatiques
complexes et réparties mêlant serveurs physiques, environnements virtualisés et services cloud la
supervision réseau devient un levier essentiel de continuité d’activité. Toute interruption d’un
service critique peut avoir des conséquences lourdes, tant sur la productivité des équipes que sur la
satisfaction des clients et la réputation de l’organisation. C’est pourquoi ce projet vise à déployer
une solution de monitoring centralisée, capable de collecter en temps réel les métriques clés
(connectivité, performances, intégrité des services) et de fournir une vision unifiée de l’état de santé
de l’ensemble des composants réseau. L’objectif est de permettre aux équipes d’exploitation de
détecter instantanément les anomalies, qu’il s’agisse de défaillances matérielles, de saturation de
ressources ou d’incidents de sécurité, et d’intervenir de manière proactive avant qu’une dégradation
de service n’impacte les utilisateurs finaux.
Pour répondre à ces enjeux, plusieurs objectifs ont été fixés : d’abord garantir une disponibilité
maximale des équipements et applications critiques en assurant un monitoring 24h/24 et 7j/7 des
indicateurs essentiels (latence réseau, charge CPU, usage mémoire, espace disque, etc.). Ensuite,
renforcer la sécurité en détectant les tentatives d’intrusion (brute force, scans de ports, trafic
anormal) et en déclenchant automatiquement, lorsque cela est pertinent, des actions de mitigation
(blocage d’adresses IP, isolement de serveurs compromis). Parallèlement, l’automatisation est
placée au cœur du dispositif pour faciliter l’intégration de nouveaux hôtes, la génération de
configurations standardisées et le déclenchement de scripts de remédiation via Ansible, Bash ou
Webhooks. Enfin, le système doit faire preuve de résilience, à la fois en maintenant un service de
monitoring fonctionnel même en cas de panne partielle du réseau et en réduisant au maximum le
temps moyen de résolution des incidents (MTTR).
Au centre de cette architecture se trouve Nagios, un outil libre de supervision réseau et système,
réputé pour sa modularité et son extensibilité. Nagios repose sur un moteur de vérification
périodique d’hôtes et de services, assorti d’un système d’alertes personnalisables (e- mail, SMS,
Slack, webhooks) et d’une interface web offrant une vue consolidée de l’infrastructure. Son
écosystème riche constitué de plugins officiels, de contributions communautaires sur Nagios
Exchange et d’agents tels que NRPE ou NCPA permet d’adapter finement la supervision à chaque
environnement. Grâce à cette architecture modulaire, Nagios offre un contrôle granulaire de la
configuration, prend en charge des scénarios de haute disponibilité et s’intègre parfaitement dans
des chaînes DevOps et d’automatisation, ce qui en fait la solution idéale pour répondre
simultanément aux besoins de disponibilité, de sécurité, d’automatisation et de résilience des
entreprises modernes.
2. Histoire et Évolution de Nagios
2.1 Origines : De NetSaint à Nagios
Nagios trouve ses racines dans un projet open-source initié à la fin des années 1990 sous le nom de
NetSaint. Ce projet a été développé par Ethan Galstad, un administrateur système basé aux États-
Unis, dans le but de répondre à un besoin pressant : superviser efficacement les services réseau et
les serveurs à moindre coût, à une époque où les solutions du marché étaient souvent coûteuses et
complexes. NetSaint a été conçu autour d’un moteur léger, modulaire, capable d’exécuter des
vérifications périodiques des services (HTTP, FTP, SMTP, etc.) et de générer des alertes en cas
d’anomalie.
En 2002, le projet est renommé Nagios (acronyme récursif de "Nagios Ain’t Gonna Insist On
Sainthood") à la suite d’un litige autour du nom "Saint". Ce changement de nom marque aussi une
étape importante dans la professionnalisation et la structuration du projet, qui allait devenir l’un des
piliers de la supervision open-source.

2.2 Le créateur : Ethan Galstad

Ethan Galstad est le développeur principal et fondateur de Nagios. Il a non seulement écrit les
premières lignes de code du noyau de supervision, mais a également défini l'architecture modulaire
qui est encore au cœur de Nagios aujourd’hui. Son objectif était de proposer un outil libre, robuste,
flexible et extensible, adapté aux environnements critiques. Il continue à jouer un rôle actif dans le
développement de la version commerciale (Nagios XI) et dans la communauté open-source à
travers Nagios Enterprises.

2.3 Pourquoi Nagios est resté un standard

Nagios s’est imposé comme un standard dans le domaine de la supervision pour plusieurs
raisons majeures :
 Simplicité et modularité : L’architecture repose sur un noyau stable et une grande variété
de plugins indépendants. Cela permet une personnalisation poussée, sans devoir modifier le
cœur du système.
 Extensibilité : N’importe quel administrateur peut créer ses propres plugins avec de simples
scripts (Bash, Python, Perl…), ce qui permet d’adapter Nagios à tout type de service ou
d’environnement.
 Communauté active : Une large communauté contribue depuis plus de 20 ans à l’évolution
des plugins, à la documentation et aux bonnes pratiques.
 Interopérabilité : Nagios s’intègre facilement avec d’autres outils IT (GLPI, Grafana,
Ansible, ELK, etc.) et peut être utilisé comme base pour des architectures DevOps.
 Stabilité et fiabilité : Nagios est réputé pour sa robustesse et son faible taux de défaillance,
même dans des environnements complexes et à grande échelle.

2.4 Versions clés de Nagios Core (1.x à 4.x)

Nagios Core a connu plusieurs versions majeures depuis sa création :
  Nagios 1.x (2002) : Première version stable. Base solide pour la supervision d’hôtes et de
services. Peu d’interfaces graphiques.
 Nagios 2.x (2005) : Introduction des dépendances hôtes/services, meilleure gestion des états,
performances accrues.
 Nagios 3.x (2008) : Ajout du support des macros avancées, amélioration du moteur
d’événements et de la planification.
 Nagios 4.x (2013 à aujourd’hui) : Refactoring complet du moteur. Exécution multithread,
montée en charge importante, plus grande efficacité pour les très grandes infrastructures
(>10 000 vérifications/minute).
Chaque version a permis de rendre Nagios plus scalable, rapide et personnalisable, en maintenant
une compatibilité ascendante forte.

2.5 Nagios Core vs Nagios XI : libre vs commercial

Nagios existe en deux principales variantes :
 Nagios Core : version entièrement gratuite et open-source, utilisée par une large
communauté. Elle nécessite des compétences en ligne de commande et en configuration
manuelle (fichiers .cfg). Elle offre une grande liberté et flexibilité, mais peu d’outils
visuels intégrés par défaut.
 Nagios XI : version commerciale et propriétaire développée par Nagios Enterprises. Elle
repose sur le moteur de Nagios Core, mais ajoute une interface graphique avancée, des
assistants de configuration, des rapports détaillés, une gestion des utilisateurs, un support
officiel, etc.
Nagios XI s’adresse principalement aux entreprises qui recherchent une solution clé en main avec
un support professionnel et des fonctions avancées prêtes à l’emploi, alors que Nagios Core reste
l’option privilégiée des administrateurs souhaitant un contrôle total sur leur infrastructure de
supervision.

2.6 L’écosystème Nagios : plugins, agents, extensions et forks

L’écosystème de Nagios s’est largement enrichi au fil des années :
 Plugins Nagios : éléments essentiels qui réalisent les vérifications (ex. : check_ping,
check_http, check_disk). Ils peuvent être officiels (paquet nagios-plugins) ou
créés par la communauté (disponibles sur Nagios Exchange).
 Agents : permettent à Nagios de collecter des données sur des machines distantes.
Exemples :
 NRPE (Nagios Remote Plugin Executor)
 NCPA (Nagios Cross Platform Agent)
 SNMP (pour équipements réseaux)
 SSH (exécution distante sécurisée)
 Extensions graphiques :
  NagiosGraph, PNP4Nagios : génération de courbes de performances
 NagVis : cartographie visuelle du réseau
 Grafana : via passerelles InfluxDB ou Prometheus
 Forks et alternatives :
 Icinga : fork moderne de Nagios, plus orienté API et performances, avec une
interface moderne.
 Centreon : fork français avec une interface riche, dédiée aux environnements de
supervision à grande échelle.
 Naemon, Shinken : autres forks plus techniques, certains abandonnés ou intégrés
dans d'autres projets.
Grâce à cet écosystème riche et à ses nombreuses possibilités d’intégration, Nagios s’adapte
facilement aux infrastructures modernes, en couvrant aussi bien la supervision classique que les
environnements cloud, conteneurisés ou hybrides.

3. Méthodes d’Installation de Nagios

Le déploiement de Nagios peut s’effectuer de plusieurs manières, en fonction des objectifs, du
niveau de contrôle souhaité et du contexte d’infrastructure (serveurs classiques, cloud, conteneurs,
etc.). Cette section explore les principales méthodes d’installation, de la plus technique (compilation
depuis les sources) aux solutions automatisées ou conteneurisées, en passant par les paquets
officiels disponibles sur les distributions Linux.

3.1 Installation depuis les sources (méthode recommandée pour maîtriser)

L’installation depuis les sources est la méthode la plus manuelle, mais aussi celle qui offre le plus
haut niveau de personnalisation. Elle permet de comprendre la structure interne de Nagios, de
choisir précisément les chemins d’installation, les utilisateurs système, et de compiler uniquement
les composants nécessaires.
• Étapes de compilation sur Ubuntu (exemple)
1. Pré-requis :
laancer le terminale et entrer les commandes suivantes :
sudo apt update
sudo apt install -y apache2 php gcc make unzip libgd-dev libssl-dev daemon

2. Téléchargement et compilation de Nagios Core :

cd /tmp
wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-
4.4.14.tar.gz
tar xzf nagios-4.4.14.tar.gz
cd nagios-4.4.14
./configure --with-httpd-conf=/etc/apache2/sites-enabled
make all
sudo make install
sudo make install-commandmode
sudo make install-init
sudo make install-config
sudo make install-webconf

3. Ajout de l’utilisateur web et mot de passe d’accès :

sudo usermod -a -G nagios www-data
sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

4. Installation des plugins Nagios :

cd /tmp
wget https://nagios-plugins.org/download/nagios-plugins-2.4.6.tar.gz
tar xzf nagios-plugins-2.4.6.tar.gz
cd nagios-plugins-2.4.6
./configure
make
sudo make install

5. Démarrage de Nagios :
sudo systemctl restart apache2
sudo systemctl enable nagios
sudo systemctl start nagios

• Avantages :
 Contrôle total sur l’installation et la configuration.
 Possibilité d’optimisations, d’intégrations avancées, ou de patchs personnalisés.
 Idéal pour les environnements professionnels complexes ou spécifiques.
• Inconvénients :
 Processus plus long, nécessite des compétences en administration Linux.
 Maintenance plus manuelle (mise à jour par recompilation).

3.2 Installation via les paquets (APT ou YUM)

Les distributions Linux proposent souvent Nagios Core dans leurs dépôts officiels, ce qui facilite
une installation rapide avec les outils de gestion de paquets :
• Exemple sur Ubuntu/Debian :
sudo apt update
sudo apt install -y nagios4 nagios-plugins nagios-nrpe-plugin

• Exemple sur CentOS/RHEL :

sudo yum install -y epel-release
sudo yum install -y nagios nagios-plugins-all

• Avantages :
 Gain de temps considérable.
 Dépendances automatiquement gérées.
 Idéal pour les tests rapides ou les petites infrastructures.
• Limites :
 Versions souvent obsolètes par rapport aux sources officielles.
 Moins de flexibilité pour personnaliser l’installation (chemins, modules, compilation avec
options spécifiques).
 Certaines fonctionnalités ou plugins récents peuvent être absents.

3.3 Installation via conteneur Docker

Le déploiement de Nagios sous forme de conteneur Docker permet d’isoler l’environnement de
supervision du reste du système. Cela facilite les tests, les déploiements CI/CD, ou encore
l’intégration dans des pipelines DevOps.
• Exemple rapide avec Docker :
docker run -d --name nagios \
-p 8080:80 \
-e NAGIOSADMIN_USER=nagiosadmin \
-e NAGIOSADMIN_PASS=admin \
jasonrivers/nagios:latest

• Avantages :
 Environnement prêt à l’emploi et reproductible.
 Isolation complète des dépendances.
 Idéal pour des démonstrations, POC, ou environnements de tests automatisés.
• Inconvénients :
 Moins adapté pour les environnements en production complexes (sauf intégration avancée).
 Stockage des données, persistance et sécurité doivent être gérés via volumes Docker ou
orchestrateurs (Kubernetes, Docker Compose).

3.4 Installation par script automatisé (auto-install)

La communauté Nagios propose divers scripts d’installation automatisée, généralement
disponibles sur GitHub ou sur le site officiel. Ces scripts permettent de déployer rapidement une
instance fonctionnelle de Nagios Core ou Nagios XI avec tous les composants nécessaires.
• Exemple de script communautaire :
wget https://assets.nagios.com/downloads/nagiosxi/scripts/install.sh
chmod +x install.sh
sudo ./install.sh

• Avantages :
 Gain de temps énorme.
 Déploiement tout-en-un : Apache, PHP, Nagios Core, plugins, agents.
 Idéal pour les débutants ou les déploiements rapides en environnement de test.
• Inconvénients :
 Personnalisation limitée : configuration standardisée, difficile à adapter aux besoins
avancés.
 Moins transparent : difficile de savoir ce qui a été installé et comment.
 Risques si le script est obsolète ou non maintenu.

4. Architecture de Supervision : Réseau Simulé et Rôle de

Nagios
4.1 Description du réseau simulé
Dans le cadre de ce projet, un réseau de supervision a été simulé afin de reproduire les conditions
réelles rencontrées en entreprise. Ce réseau est hybride, combinant des machines hôtes physiques,
des machines virtuelles importées dans VirtualBox à partir d’une image OVA de Nagios Core,
ainsi que les postes personnels des membres du groupe.
Le réseau est configuré en mode "réseau interne" ou "réseau hôte uniquement" (Host-Only)
afin de garantir l'isolation de l’environnement de test tout en permettant une interconnexion entre
les systèmes supervisés et le serveur Nagios.
L’objectif est de superviser un ensemble hétérogène de services critiques (serveur web, base de
données, firewall, postes clients), avec une capacité d’alerte et de réaction aux incidents (pannes,
intrusions, indisponibilité de service).

4.2 Liste des hôtes supervisés

Le réseau supervisé comprend les éléments suivants :
 Serveur Web
 Type : Apache ou Nginx selon la VM
 Fonction : hébergement d’un site web statique ou dynamique simulé
 Adresse IP : 192.168.56.10

 Vérifications : disponibilité HTTP (check_http), charge CPU, espace disque

 Serveur de Base de Données

 Type : MySQL ou PostgreSQL
 Fonction : gestion des données critiques d’une application simulée
 Adresse IP : 192.168.56.11

 Vérifications : check_mysql ou check_postgres, ping, charge RAM

 Firewall (pfSense)
 Type : pfSense installé dans une VM dédiée
 Fonction : pare-feu du réseau interne simulé, contrôle des accès
  Adresse IP : 192.168.56.1

 Vérifications : ping, disponibilité des interfaces, charge système via SNMP

 Postes Clients
 Type : Windows 10/Linux Mint (machines physiques ou virtuelles des membres)
 Fonction : clients simulant des connexions au serveur web et BDD
 Adresses IP : 192.168.56.20 à 192.168.56.30

 Vérifications : accessibilité réseau (ping), processus critiques, ports ouverts

 Serveur Nagios Core (VM OVA)
 Adresse IP : 192.168.56.100

 Fonction : centralisation de la supervision, moteur de vérification, alertes, tableau de

bord

4.3 Schéma topologique avec adresses IP et fonctions

Voici un aperçu textuel de la topologie réseau. .
+--------------------+
| Poste client 1 | (192.168.56.20)
+--------------------+
|
|
+--------------------+ +------------------+ +--------------------+
| Serveur Web |---| Réseau local |---| Serveur BDD |
| (Apache/Nginx) | | 192.168.56.0/24 | | (MySQL/PostgreSQL) |
| 192.168.56.10 | +--------+---------+ | 192.168.56.11 |
+--------------------+ | +--------------------+
|
|
+-------------+
| Firewall | (pfSense - 192.168.56.1)
+-------------+
|
|
+-------------------+
| Nagios Core VM | (192.168.56.100)
+-------------------+

4.4 Rôle du serveur Nagios dans l’architecture

Le serveur Nagios Core joue un rôle central et stratégique dans cette architecture :
 Collecte des données de supervision : il exécute des vérifications actives via des plugins
(ICMP, HTTP, MySQL, SSH, etc.) ou passives via des agents comme NRPE ou SNMP.
 Centralisation des informations : toutes les alertes, états de service, courbes de
performance sont consolidés sur l’interface web (CGI) de Nagios.
 Détection d’anomalies : dès qu’un seuil critique est atteint ou qu’un service devient
indisponible, Nagios déclenche une alerte.
  Notification des incidents : des notifications sont émises par email (ou plus tard SMS,
webhook, etc.) aux administrateurs, facilitant une réponse rapide.
 Résilience du système : grâce à la redondance des vérifications et au suivi historique,
Nagios permet une analyse post-incident précise pour prévenir les futures pannes.
En résumé, Nagios agit comme le centre nerveux de la surveillance réseau, détectant
proactivement les anomalies et facilitant la résilience de l’infrastructure.

5. Configuration initiale des hôtes et services dans Nagios Core

Dans cette section, nous allons présenter les étapes complètes pour la mise en place de chaque
composant du réseau supervisé, depuis l’installation jusqu’à l’intégration dans l’interface de
supervision Nagios Core.

5.1 Installation de Nagios Core (via OVA)

Étapes :
1. Importation de l’OVA dans VirtualBox
 Ouvrir VirtualBox > Fichier > Importer une appliance

Figure 1: image d accueill de virtualbox

 Sélectionner le fichier .ova de Nagios Core
Figure 2: image de la selection du fichier ova

2. Configuration de la machine
 Attribuer 2 CPU, 2 Go de RAM minimum
 Choisir les paramètres réseau : mode Réseau Interne (VmntO)

Figure 3: image de la configuration des resource minimum

Figure 4: image de la fin de limportation de l ova

3. Accès à l’interface Nagios Core

 Démarrer la VM pour debuter l instalation
Figure 5: image du debut de l instation de nagios

Figure 6: image de la fin d installation

 Accéder à l’interface : http://192.168.10.155

 Utiliser le compte nagiosadmin

Figure 7: image de lancement dans le navigateur

Figure 8: image de la configuration graphque des preferences

Figure 9: image du lancement de l instalation graphique

Figure 10: image de la page de connexion

Figure 11: page d accueil de nagios

5.2 Installation de pfSense (Firewall)

Étapes :
1. Téléchargement de l’ISO pfSense
 Depuis : https://www.pfsense.org/download/
2. Création d’une VM pfSense dans VirtualBox
 Type : BSD, Version : FreeBSD (64-bit)
 1 CPU, 512 Mo RAM, 4 Go disque
 2 interfaces réseau : NAT (WAN) + Réseau interne (LAN)
3. Installation pfSense
 Démarrer l’installation, suivre les instructions
 Configurer l’interface LAN avec IP statique : 192.168.10.0/24
Figure 12: lancement de pfsense

Figure 13: fin d e l istallation de pfsense

4. Activer l’accès WebGUI

 Accéder depuis navigateur via http://192.168.1.50
Figure 14: image de la page d e login de pfsense

utilisons les indentifiant suivant

Figure 15: page d accueil de pfsense

 Autoriser Ping, SNMP et HTTP dans pfSense

2. Ajouter les règles dans le pare-feu (interface LAN)

Étapes :
1. Allons dansle menu : Firewall > Rules > LAN
2. Clique sur "Add" (flèche vers le haut = placer en haut de la liste)
3. Crée les trois règles suivantes, une par protocole :
Autoriser le ping (ICMP)
 Action : Pass
 Interface : LAN
 Protocol : ICMP
 ICMP type : Echo Request
 Source : any (ou spécifie l’IP de Nagios : 192.168.56.100)

 Destination : This firewall (ou l’adresse IP LAN de pfSense)

 Description : Autoriser ICMP/ping depuis Nagios
✅ Clique sur Save, puis Apply Changes.
Figure 16: configuration des relgles 1

Autoriser SNMP (port 161 UDP)

 Action : Pass
 Interface : LAN
 Protocol : UDP
 Source : 192.168.56.100 (serveur Nagios)

 Destination : This firewall

 Destination port : SNMP (161)
 Description : Autoriser SNMP depuis Nagios
✅ Clique sur Save, puis Apply Changes.
Figure 17: Autoriser SNMP (port 161 UDP)

Autoriser l’accès HTTP (WebGUI)

 permettre à d’autres hôtes d’accéder à l’interface web :
 Action : Pass
 Interface : LAN
 Protocol : TCP
 Source : any (ou 192.168.56.100)

 Destination port : HTTP (port 80)

 Description : Autoriser accès WebGUI pfSense
✅ Clique sur Save, puis Apply Changes.
Activer le service SNMP dans pfSense
1. Va dans le menu : Services > SNMP
2. Coche "Enable SNMP Daemon and its controls"
3. Configure les options SNMP :
 Read Community String : public

 Location : ex : Data Center Test

 Contact : groupe@gmailcom

 Interface binding : LAN

 System Description : pfSense firewall for lab
 4. En bas, clique sur Save puis Apply Changes

Figure 18: Activer le service SNMP dans pfSense

Vérification depuis Nagios

Sur le serveur Nagios, installe snmpwalk si ce n’est pas déjà fait :
sudo apt install snmp

Figure 19: installation de snmpwalk

Puis exécute :
snmpwalk -v 2c -c public 192.168.1.128

Figure 20: resultat snmpwalk -v

Figure 21: snmpwalk -v

5.3 Mise en place du Serveur Web
Étapes :
1. Création d’une VM (Linux Debian/Ubuntu)
 IP statique : 192.168.1.1
2. Installation d’Apache ou Nginx
sudo apt update
sudo apt install nginx -y

3. Vérification du service
 Accéder à http://192.168.56.10

 Installer le plugin NRPE pour supervision distante :

sudo apt install nagios-nrpe-server nagios-plugins -y

4. Configuration de NRPE
 Fichier : /etc/nagios/nrpe.cfg

 Ajouter IP du serveur Nagios :

allowed_hosts=127.0.0.1,192.168.56.100

5. Redémarrer NRPE
sudo systemctl restart nagios-nrpe-server

5.4 Mise en place du Serveur de Base de Données (MySQL/PostgreSQL)

Étapes :
1. Création d’une VM (Linux)
 IP statique : 192.168.56.11
2. Installation MySQL ou PostgreSQL
 MySQL :
sudo apt install mysql-server -y

 PostgreSQL :
sudo apt install postgresql -y

3. Ajout de NRPE et configuration

 Même processus que pour le serveur web
 Ajouter un check spécifique :
command[check_mysql]=/usr/lib/nagios/plugins/check_mysql -u root

4. Redémarrage du service NRPE

sudo systemctl restart nagios-nrpe-server

5.5 Mise en place des postes clients

Étapes :
1. Machines physiques ou VMs (Windows/Linux)
 IPs dans la plage : 192.168.56.20 à 192.168.56.30
2. Supervision des postes
 Ping ICMP
 Vérification de ports ouverts (SSH, HTTP)
 Pour Windows :
 Installer NSClient++ (agent NRPE/NSCA pour Windows)
 Configurer nsclient.ini pour autoriser le serveur Nagios
3. Sur Linux :
 Installer NRPE et configurer comme ci-dessus
 Ajouter des commandes personnalisées (CPU, RAM, uptime)

5.6 Intégration des hôtes et services dans Nagios

Fichiers de configuration :
 hosts.cfg :
define host {
use linux-server
host_name serveur-web
alias Serveur Web Apache
address 192.168.56.10
}

 services.cfg :
define service {
use generic-service
host_name serveur-web
service_description HTTP
check_command check_http
}

 Redémarrage de Nagios :
sudo systemctl restart nagios

 Vérification de la configuration :
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Souhaites-tu maintenant que je développe la gestion des incidents et scénarios de crise (ex :
serveur piraté, détection d’un service compromis, alertes automatiques) ou que je t’ajoute une
partie sur les bonnes pratiques avancées et l’automatisation de la supervision ?
6. Surveillance des Hôtes et Services
 Ajout manuel d’hôtes et services
 Plugins essentiels utilisés (check_http, check_ping, etc.)
 Création d’un plugin personnalisé en Bash (ex : vérification d’un fichier)
 Configuration des dépendances entre services

7. Automatisation de la Configuration
 Génération automatique de fichiers .cfg

 Script Python/Bash pour ajouter un hôte via un modèle

 Introduction à Ansible :
 Déploiement de l’agent NRPE/NCPA sur les hôtes
 Ajout automatique dans Nagios Core
 Exemple de playbook YAML

8. Cas Pratique : Simulation de Crise

8.1 Scénario 1 : Serveur Web piraté
 Symptômes observés :
 CPU élevée, Apache indisponible
 Connexions entrantes suspectes
 Réaction :
 Envoi d’alertes par mail et webhook
 Exécution d’un script pour isoler le serveur
8.2 Scénario 2 : Tentative de brute force SSH
 Détection dans les logs via check_log

 Bannissement automatique avec fail2ban

 Notification à l’admin avec détails du journal

9. Alertes et Notifications Avancées

 Configuration des utilisateurs et groupes de contacts
 Escalade d’alertes
 Intégration avec Slack, Telegram, Email, webhook
 Notifications conditionnelles (ex : jours ouvrés)
10. Visualisation des Données
 Interface web de Nagios
 Graphiques de performance :
 NagiosGraph
 PNP4Nagios
 Export vers Grafana via InfluxDB
 Cartographie réseau avec NagVis

11. Sécurité du Système Nagios

 Sécurisation de l’interface web (HTTPS + auth)
 Protection du répertoire de commandes externes
 Sécurisation des agents : certificats, pare-feu
 Détection d’intrusions (check_rootkit, etc.)

12. Perspectives et Améliorations Futures

 Supervision distribuée (NRDP + satellites)
 Intégration à un SIEM (Wazuh, ELK)
 Monitoring orienté SLA/ITIL
 Intégration avec GLPI, CMDB, ticketing

13. Conclusion
 Résumé des apports techniques
 Résilience démontrée face aux crises
 Potentiel d’extension et d’intégration

14. Annexes
 Fichiers de configuration réels
 Scripts d’automatisation et de réaction
 Liste des plugins personnalisés
 Références officielles (Nagios Exchange, docs, etc.)