📊 Supervision réseau — SNMP et Nagios fondements

🎯 Introduction (10 min)

Le 4 octobre 2021, la panne BGP de Facebook a montré que la supervision peut détecter une anomalie globale en moins de 30 minutes (routes BGP retirées), mais que l'absence de procédures d'escalade efficaces et la nécessité d'interventions physiques prolongent la remise en service à plusieurs heures. Ce cas illustre qu'une simple alerte technique n'est pas suffisante : il faut une chaîne opérationnelle (notification, escalade, action) pour réduire le MTTR.

Dans cette séance nous posons les fondations techniques : comment SNMP permet de collecter l'état matériel et applicatif, et comment Nagios peut matérialiser des contrôles actifs/passifs et des politiques de notification.

🎯 Objectifs de la séance

• Configurer et expliquer les différences entre SNMP v1/v2c et SNMP v3 (USM authPriv), et connaître les risques associés aux community strings par défaut.
• Interroger une MIB et interpréter des OID (sysDescr, interfaces.ifTable.ifDescr, hrStorage.hrStorageTable) avec snmpget/snmpwalk, et distinguer GET / GETNEXT / GETBULK / SET / TRAP / INFORM.
• Créer un check Nagios basique (ping et check_ssh), ajouter deux hôtes et vérifier que les checks remontent correctement dans l'interface Nagios.

📖 1. Fondements et architecture SNMP (80 min)

SNMP (Simple Network Management Protocol) repose sur un modèle manager / agent : un manager (outil de supervision centralisé) interroge des agents SNMP présents sur les équipements (switch, routeur, serveurs). Les agents exposent des objets organisés dans des MIBs (Management Information Base), identifiés par des OID (Object Identifiers) dans un arbre hiérarchique. La communication SNMP classique utilise UDP (port 161 pour requêtes, port 162 pour traps) ; c'est léger mais nécessite des précautions de sécurité.

1.1 Manager / Agent — principes et schéma

Le manager envoie des requêtes (GET, GETNEXT, GETBULK, SET) à l'agent qui retourne des valeurs. Les agents peuvent aussi initier l'envoi d'événements (TRAP ou INFORM) vers un manager configuré.

• TRAP : non sollicité, unidirectionnel — aucune confirmation requise.
• INFORM : trap avec accusé de réception — utile quand on veut s'assurer que l'alerte a bien été reçue.

            +--------------------------+
            |      SNMP Manager        |
            |  (Zabbix / Nagios / PRTG)|
            +-----------+--------------+
                        | UDP 161/162
        ---------------+-----------------------------
       |                                    |
+--------------------+          +--------------------+
| win-srv01 (agent)  |          | cisco-switch (agent)|
| SNMP v3 authPriv   |          | SNMP v2c / v3       |
+--------------------+          +--------------------+

1.2 Versions SNMP et sécurité

SNMP v1/v2c reposent sur des community strings en clair ; il est fréquent de rencontrer encore les chaînes par défaut public (lecture seule) et private (lecture/écriture) — ces valeurs sont non sécurisées et doivent être remplacées ou, mieux, migrées vers SNMPv3.

SNMPv3 introduit USM (User-based Security Model) avec trois niveaux :

• noAuthNoPriv — ni authentification ni chiffrement.
• authNoPriv — authentification uniquement (ex. SHA-256).
• authPriv — authentification et chiffrement (ex. SHA-256 + AES-256).

1.3 MIB, OID et exemples utiles

Une MIB est un dictionnaire d'objets ; chaque objet est identifié par un OID. L'arbre standard mib-2 se situe sous 1.3.6.1.2.1 (iso.org.dod.internet.mgmt.mib-2).

1.4 Opérations SNMP : GET, GETNEXT, GETBULK, SET, TRAP, INFORM

Exemples de commandes (depuis debian-srv01)

# Lister les objets de system (mib-2.1) en SNMPv2c (exemple NON sécurisé)
snmpwalk -v2c -c public 192.168.10.5 1.3.6.1.2.1.1

# Récupérer la description système (scalaire) - SNMPv2c
snmpget -v2c -c public 192.168.10.5 sysDescr.0
# Sortie attendue :
# SNMPv2-SMI::mib-2.1.1.0 = STRING: "Microsoft Windows Server 2022 Standard ..."

# En SNMPv3 authPriv (SHA / AES) - lire le sysDescr
snmpwalk -v3 -u monitor -l authPriv \
  -a SHA -A 'AuthPass123' \
  -x AES -X 'PrivPass123' \
  192.168.10.5 1.3.6.1.2.1.1

# Envoyer un trap SNMP v2c (exemple)
snmptrap -v2c -c public manager '' .1.3.6.1.6.3.1.1.5.3

📖 2. Nagios : architecture et principes (60 min)

Nagios Core est un moteur de supervision qui exécute des contrôles (plugins) sur des hôtes et services définis dans des fichiers de configuration. Deux modes coexistent : les checks actifs (Nagios interroge l'hôte) et les checks passifs (l'hôte ou un agent envoie le résultat au serveur Nagios). Pour exécuter des commandes à distance sur un hôte (métriques locales non exposées en SNMP), on installe un agent NRPE ou on utilise des sondes qui publient des résultats passifs.

Composants clés

• nagios-core : moteur qui orchestre les vérifications et notifications.
• Plugins : scripts (check_ping, check_ssh, check_nrpe…) qui retournent OK / WARNING / CRITICAL.
• NRPE (ou agents alternatifs) : exécution distante de plugins sur l'hôte supervisé.
• Fichiers d'objets : définitions hosts / services / commands / contacts / contact_groups.

2.1 Exemples de configuration Nagios (syntaxe classique)

Définition de commandes dans commands.cfg :

define command{
  command_name    check-host-alive
  command_line    $USER1$/check_ping -H $HOSTADDRESS$ -w 100.0,20% -c 500.0,60% -p 5
}

define command{
  command_name    check-ssh-port
  command_line    $USER1$/check_ssh -H $HOSTADDRESS$ -p 22
}

Définition d'un hôte et d'un service SSH dans hosts.cfg / services.cfg :

define host{
  use           generic-host
  host_name     win-srv01
  alias         win-srv01
  address       192.168.10.5
}

define service{
  use                 generic-service
  host_name           win-srv01
  service_description SSH
  check_command       check-ssh-port
}

2.2 Checks actifs vs passifs, escalades et notifications

Les notifications sont construites à partir de contacts / contact_groups et d'actions définies sur des triggers d'état. Les escalades (escalations) permettent de contacter des personnes différentes selon la durée d'un incident :

• 1ère alerte → on-call N1
• Après 30 min → manager
• Après 2h → intervention physique

🛠️ Travaux Pratiques — TP S1 (70–80 min)

Prérequis techniques

• Accès administrateur sur win-srv01 et sur le Catalyst (mode enable/config).
• Accès SSH/root sur debian-srv01 (serveur de supervision) et accès au serveur Nagios.
• Outils sur debian-srv01 : snmp, snmp-mibs-downloader

sudo apt install -y snmp snmp-mibs-downloader

Étape 1 — Activer SNMP v3 authPriv sur win-srv01 (Net-SNMP)

1. Installer Net-SNMP pour Windows (si l'agent SNMP natif ne supporte pas v3).
2. Créer/modifier le fichier snmpd.conf (chemin typique : C:\usr\etc\snmp\snmpd.conf) :

# snmpd.conf (extrait) - SNMPv3 user authPriv
createUser monitor SHA "AuthPass123" AES "PrivPass123"
# Limiter la vue si besoin :
rouser monitor

3. Démarrer/réinitialiser le service SNMP (PowerShell en Administrateur) :

net stop snmpd
net start snmpd
Get-Service -Name snmpd

Étape 2 — Activer SNMP v3 sur Cisco Catalyst 2960

enable
configure terminal
! Vue restreinte
snmp-server view INNOVATTECH_RO 1.3.6.1.2.1 included
! Groupe v3 avec confidentialité
snmp-server group MGMT v3 priv read INNOVATTECH_RO write INNOVATTECH_RO
! Utilisateur v3 SHA / AES-256
snmp-server user monitor MGMT v3 auth sha AuthPass123 priv aes 256 PrivPass123
end
write memory

Étape 3 — Vérifier l'accès depuis debian-srv01

# SNMPv3 authPriv (SHA / AES) - lecture de sysDescr
snmpwalk -v3 -u monitor -l authPriv \
  -a SHA -A 'AuthPass123' \
  -x AES -X 'PrivPass123' \
  192.168.10.5 1.3.6.1.2.1.1

# SNMPv2c (si l'agent n'est pas encore migré)
snmpwalk -v2c -c public 192.168.10.5 1.3.6.1.2.1.1

Étape 4 — Créer un check Nagios basique (PING + SSH)

1. Définir les commandes dans commands.cfg :

define command{
  command_name    check-host-alive
  command_line    $USER1$/check_ping -H $HOSTADDRESS$ -w 100.0,20% -c 500.0,60% -p 5
}

define command{
  command_name    check-ssh-port
  command_line    $USER1$/check_ssh -H $HOSTADDRESS$ -p 22
}

2. Ajouter les hôtes et services (hosts.cfg / services.cfg) :

define host{
  use           generic-host
  host_name     win-srv01
  alias         win-srv01
  address       192.168.10.5
}

define service{
  use                 generic-service
  host_name           win-srv01
  service_description PING
  check_command       check-host-alive
}

define host{
  use           generic-host
  host_name     debian-srv02
  alias         debian-srv02
  address       192.168.30.5
}

define service{
  use                 generic-service
  host_name           debian-srv02
  service_description SSH
  check_command       check-ssh-port
}

3. Vérifier la configuration et recharger Nagios :

sudo nagios -v /etc/nagios/nagios.cfg
sudo systemctl restart nagios
sudo systemctl status nagios --no-pager

Livrable attendu

• Un fichier snmpd.conf (win-srv01) ou capture de la configuration SNMP v3 Cisco.
• Un extrait des fichiers Nagios (commands.cfg, hosts.cfg, services.cfg) montrant les définitions ajoutées.
• Un court rapport (1 page) avec les sorties snmpwalk prouvant l'accès et une capture d'écran Nagios montrant les services en OK.

Critères de réussite

• ☑ snmpwalk sur SNMP v3 retourne sysDescr.0 pour win-srv01 et pour le switch.
• ☑ Nagios affiche les hôtes win-srv01 et debian-srv02 avec les services PING/SSH en état OK.
• ☑ Les fichiers de configuration Nagios sont valides (nagios -v sans erreur).

🔁 Synthèse (10 min)

Cette séance a posé les bases de la supervision réseau : SNMP fournit un modèle standardisé pour interroger et surveiller des objets sur des équipements, avec des versions (v1/v2c/v3) aux niveaux de sécurité très différents. Nagios offre un moteur de checks et de notifications très modulable, adapté aux contrôles actifs et aux escalades opérationnelles.

En attendant la séance suivante (Zabbix), vous devez être capable d'interroger une MIB, d'expliquer la différence entre TRAP et INFORM, et d'ajouter un check Nagios simple pour un hôte.

📝 QCM — Testez vos connaissances