profciel.fr
// réseau

Supervision réseau : l’outil qui surveille devient aussi un système à maintenir

Un format court pour transformer un avis LibreNMS en activité CIEL : inventorier l’outil de supervision, vérifier sa version, limiter ses droits et garder une preuve.

· 3 min de lecture · réseau · cybersécurité · supervision · LibreNMS · veille · Bac Pro CIEL

Dans un lab réseau, la supervision est rassurante : on voit les équipements, les interfaces, les alertes, les graphes.

Le piège, c’est de la traiter comme un tableau de bord neutre.

Un outil de supervision, ce n’est pas juste “un écran avec des voyants”. C’est un système qui parle aux équipements, stocke de la configuration, déclenche parfois des notifications, et tourne souvent avec des droits qu’on oublie de regarder.

Le signal de la semaine

Le 11 juin 2026, le CERT-FR publie un avis sur LibreNMS, un outil de supervision réseau open source. L’avis indique une vulnérabilité permettant une exécution de code arbitraire à distance.

Le périmètre annoncé est précis :

LibreNMS versions 21.6.x à 26.x antérieures à 26.5.0

La source éditeur, publiée via GitHub Security Advisory le 10 juin 2026, décrit un problème dans le module de transport d’alerte Signal. Le scénario mentionné suppose un administrateur authentifié capable d’ajouter une entrée de transport d’alerte, puis de provoquer une injection de commande via des appels exec insuffisamment protégés.

Conclusion utile pour les élèves : ce n’est pas “LibreNMS est dangereux”. C’est plutôt :

Si un outil supervise le réseau, il fait partie du réseau à maintenir.

Ce que ça change en CIEL

On peut en faire une activité courte, sans exploitation, sans démo cowboy.

Objectif : partir d’un avis réel et produire une décision technique propre.

1. Avons-nous LibreNMS, Centreon, Zabbix, Grafana, Prometheus ou autre ?
2. Où tourne l’outil ? VM, conteneur, poste, serveur de lab ?
3. Quelle version est installée ?
4. Quels comptes ont un rôle administrateur ?
5. Quelles notifications ou scripts l’outil peut-il déclencher ?
6. Quelle preuve garde-t-on après vérification ou mise à jour ?

L’intérêt pédagogique n’est pas de retenir le nom d’une CVE par cœur. L’intérêt, c’est de comprendre qu’un service technique devient un actif à gérer dès qu’il a :

  • des comptes ;
  • des accès aux équipements ;
  • une interface web ;
  • des plugins ou intégrations ;
  • des alertes qui lancent des actions ;
  • une version à maintenir.

Mini-activité : fiche “outil de supervision”

Donner aux élèves un outil de supervision réel ou fictif dans un petit schéma de lab.

Ils remplissent cette fiche :

Nom de l’outil :
Rôle dans le lab :
Adresse / emplacement :
Version observée :
Comptes administrateurs identifiés :
Équipements supervisés :
Notifications / scripts / intégrations :
Exposition : local seulement / VLAN admin / Internet / inconnu
Décision : à jour / à corriger / à isoler / à vérifier
Preuve conservée : capture, commande, journal, page version, ticket

Exemples de preuves acceptables :

# Selon l'installation, à adapter au contexte réel
php validate.php
./lnms --version
docker compose ps
docker compose logs --tail=50 librenms
capture de la page About / Version
capture de la liste des transports d’alerte configurés

Le professeur peut aussi ajouter une contrainte simple : pas de mot de passe en clair dans la copie, pas de capture contenant un secret, pas d’adresse publique réelle.

La phrase à faire retenir

Un bon réflexe CIEL :

Je ne supervise pas seulement les équipements.
Je supervise aussi l’outil qui supervise.

Ça oblige à poser les bonnes questions : version, droits, exposition, sauvegarde, preuve.

C’est moins spectaculaire qu’une alerte rouge sur un écran. Mais c’est beaucoup plus proche du travail réel d’un technicien réseau ou cyber.

Sources