Configurer la supervision matérielle SNMP sur Sophos Firewall

Pour utiliser la supervision matérielle SNMP, on active l’agent sous Administration > SNMP, on crée de préférence un utilisateur SNMPv3, on limite l’accès à l’hôte de supervision sous Administration > Device access et on télécharge la MIB actuelle. La connexion peut ensuite être testée depuis le système de supervision avec snmpget, tandis que snmpwalk permet d’interroger l’arborescence matérielle.

Depuis Sophos Firewall v22, la MIB fournit des métriques matérielles supplémentaires selon le modèle XGS, notamment les températures du CPU et du NPU, la vitesse des ventilateurs, l’état des blocs d’alimentation et les valeurs PoE. SNMP répond principalement aux questions sur l’état de l’équipement. Pour les événements de sécurité individuels, Central Firewall Reporting ou syslog est plus approprié, tandis que sFlow convient mieux aux tendances du trafic.

Pour un contrôle ponctuel directement sur l’appliance plutôt qu’une supervision continue, vérifier la température et le ventilateur Sophos Firewall via SSH explique comment lire sensors et xgs-healthmond.log et interpréter correctement les alarmes apparentes des capteurs bruts.

⚠️ SNMP ne devrait être accessible que depuis un réseau d’administration ou de supervision de confiance. Un accès étendu depuis les zones clients, invités, IoT ou WAN expose inutilement des informations sur le modèle, les interfaces et l’état de fonctionnement.

Configurer SNMP de manière sécurisée

Limiter l’accès à l’hôte de supervision

Si une zone de supervision dédiée doit accéder au service, on active SNMP sous Administration > Device access uniquement pour cette zone. Si, en revanche, un seul serveur avec une adresse IP fixe effectue les interrogations, SNMP reste désactivé pour la zone. Une Local service ACL exception rule autorise alors précisément la source, la destination firewall et le service SNMP. La configuration complète est décrite dans Sécuriser Device Access sur Sophos Firewall.

SNMP est un service local du firewall. Une règle LAN vers WAN classique ne remplace pas Device Access. SNMP ne devrait pas être exposé directement depuis le WAN ; pour une supervision externe, un VPN d’administration offre une connexion plus sûre.

Activer l’agent

Ouvrir Administration > SNMP.
Activer Enable SNMP agent.
Saisir le nom, l’emplacement et le contact, par exemple xgs-zrh-01, ZRH-DC1 / Rack 3 et noc@example.net.
Enregistrer avec Apply.
Utiliser Download MIB pour télécharger la MIB correspondant à la version installée du firewall et l’importer dans le système de supervision.

Les requêtes atteignent l’agent via UDP 161. Les traps sont envoyés au gestionnaire via UDP 162. Le routage et les pare-feu locaux des hôtes entre les deux systèmes doivent également autoriser le trafic dans le sens requis.

Configurer SNMPv3

Sous Administration > SNMP > SNMPv3 users and traps, cliquer sur Add.
Définir un nom d’utilisateur permanent tel que monitoring. Il ne pourra plus être modifié.
Activer Accept queries.
Activer Send traps uniquement si le firewall doit également envoyer des notifications au gestionnaire.
Pour les nouvelles installations, utiliser si possible AES et SHA256 ou SHA512. Les deux phrases de passe doivent comporter au moins douze caractères.
Enregistrer la configuration.

Selon Sophos, Authorized hosts s’applique uniquement aux destinations des traps. Cette liste ne limite pas les requêtes SNMPv3. L’accès aux requêtes dépend des identifiants corrects, de Accept queries et de Device Access.

Utiliser SNMPv1 ou SNMPv2c uniquement si nécessaire

Si le système de supervision ne prend pas correctement en charge SNMPv3, on crée une entrée de communauté sous Administration > SNMP > SNMPv1/v2c. Les champs requis sont le nom, le Community String, IPv4 ou IPv6, l’adresse IP du gestionnaire et Accept queries. Send traps reste désactivé si les traps ne sont pas utilisés.

Le Community String fonctionne comme un mot de passe, mais il est transmis sans chiffrement avec v1/v2c. Il ne doit apparaître ni dans les captures d’écran ni dans les tickets et ne devrait être utilisé que dans un réseau d’administration strictement limité.

Après une mise à niveau vers SFOS 22, il convient de vérifier les entrées v1/v2c existantes. Le firewall copie l’ancien nom dans le Community String et crée un nom préfixé par snmp pour les objets migrés. Cette vérification permet aussi de supprimer les variantes IPv4 ou IPv6 inutiles et les sources de supervision qui ne sont plus utilisées.

Activer les traps de manière sélective

Pour les traps, l’utilisateur SNMP ou l’entrée de communauté ne suffit pas à lui seul. Sous System services > Notification list, il faut activer SNMP traps ainsi que les types d’alertes réellement nécessaires.

La réception doit être testée avec un événement sélectionné qui se produit réellement. Les informs SNMPv3 font l’objet d’un accusé de réception ; selon Sophos, le firewall ne tente pas de renvoyer un inform s’il ne reçoit pas cet accusé. Les traps et les informs ne remplacent donc pas la supervision du processus d’interrogation lui-même.

Métriques matérielles et limites des modèles

SFOS 22 fournit les nouvelles valeurs matérielles pour les appliances XGS :

CPU temperature: tous les modèles XGS.
NPU temperature: tous les modèles XGS sauf 88/88w, 108/108w, 118/118w et 128/128w.
Fan speed: tous les modèles XGS sauf 88/88w et 108/108w.
Power supply status: XGS 2100 et modèles supérieurs.
PoE measurements: modèles XGS compatibles PoE sauf XGS 116/116w.

Sophos documente ces capteurs pour le matériel XGS. Il ne faut pas s’attendre à obtenir des capteurs physiques de l’hôte depuis la MIB SFOS sur des appliances virtuelles, cloud ou logicielles. Même sur XGS, l’absence d’une métrique n’indique pas automatiquement une erreur ; il faut d’abord vérifier si le modèle la prend en charge.

OID et unités de la MIB SFOS 22

L’arborescence matérielle commence à .1.3.6.1.4.1.2604.5.1.9. Les zones les plus importantes sont :

Température du NPU : .1.3.6.1.4.1.2604.5.1.9.1.0
Température du CPU : .1.3.6.1.4.1.2604.5.1.9.2.0
Vitesse du ventilateur : .1.3.6.1.4.1.2604.5.1.9.3.1.2
État du bloc d’alimentation : .1.3.6.1.4.1.2604.5.1.9.4.1.2
Table PoE : .1.3.6.1.4.1.2604.5.1.9.5

Les températures sont renvoyées en dixièmes de degré Celsius : 420 correspond à 42,0 °C. Les valeurs des ventilateurs sont exprimées en RPM. La puissance PoE est indiquée en milliwatts, la tension en millivolts et le courant en milliampères. Pour un bloc d’alimentation, up(1) signifie opérationnel et down(2) signifie défaillant.

Pour disposer de valeurs matérielles exploitables numériquement, il convient d’installer au minimum SFOS 22.0 GA Build 411. Ce build corrige NC-169564, qui renvoyait les valeurs des capteurs sous forme de strings plutôt que d’integers, ainsi que d’autres problèmes de MIB et d’OID.

Après une mise à niveau du firmware, il faut télécharger à nouveau la MIB actuelle, l’importer dans le système de supervision et relancer la découverte. Les modèles de supervision ne doivent pas dépendre uniquement des noms affichés.

Tester la connexion et les valeurs matérielles

Les commandes Bash suivantes s’exécutent sur un hôte de supervision Linux ou macOS équipé de Net-SNMP, et non sur Sophos Firewall. Sous macOS, il faut d’abord lancer bash, car read -p a une autre signification dans le shell zsh utilisé par défaut. Les exemples ont été vérifiés par rapport à la syntaxe Net-SNMP documentée et à la MIB officielle de SFOS 22, mais n’ont pas été exécutés sur le firewall d’un client.

SHA-256 et SHA-512 nécessitent généralement Net-SNMP 5.8 ou une version ultérieure. snmpwalk -h permet de vérifier les algorithmes acceptés par le client installé. Les anciennes versions de macOS peuvent ne prendre en charge que MD5 et SHA.

⚠️ Net-SNMP transmet le Community String et les phrases de passe comme arguments de processus. Leur saisie avec read les exclut de l’historique du shell, mais ne les empêche pas d’apparaître brièvement dans la liste des processus. Ces tests ne doivent être exécutés que sur un hôte de supervision de confiance.

Tester SNMPv3 avec AuthPriv

Adapter l’adresse IP et le nom d’utilisateur, saisir les phrases de passe et interroger d’abord l’OID standard sans risque sysUpTime.0 :

FIREWALL_IP="192.0.2.1"
SNMP_USER="monitoring"

read -r -s -p "Mot de passe d’authentification SNMPv3 : " SNMP_AUTH
printf '\n'
read -r -s -p "Mot de passe de chiffrement SNMPv3 : " SNMP_PRIV
printf '\n'

snmpget -v3 -l authPriv -u "$SNMP_USER" \
  -a SHA-256 -A "$SNMP_AUTH" \
  -x AES -X "$SNMP_PRIV" \
  -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.2.1.1.3.0

snmpwalk -v3 -l authPriv -u "$SNMP_USER" \
  -a SHA-256 -A "$SNMP_AUTH" \
  -x AES -X "$SNMP_PRIV" \
  -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.4.1.2604.5.1.9

unset SNMP_AUTH SNMP_PRIV

Une première requête réussie renvoie sysUpTime.0 sous forme de Timeticks. Le walk suivant affiche uniquement les capteurs pris en charge par le modèle concerné.

Utiliser SNMPv2c comme test de compatibilité

Pour un gestionnaire v2c configuré volontairement :

FIREWALL_IP="192.0.2.1"

read -r -s -p "Communauté SNMP : " SNMP_COMMUNITY
printf '\n'

snmpget -v2c -c "$SNMP_COMMUNITY" -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.2.1.1.3.0

snmpwalk -v2c -c "$SNMP_COMMUNITY" -t 3 -r 1 \
  "$FIREWALL_IP" .1.3.6.1.4.1.2604.5.1.9

unset SNMP_COMMUNITY

Un test d’uptime réussi prouve l’accessibilité et la validité des identifiants, mais pas encore la plausibilité de toutes les valeurs des capteurs. Il faut ensuite comparer le hostname, le modèle, le firmware, la version de la MIB et les valeurs avec WebAdmin, l’appliance et le fonctionnement normal. Avant d’activer les alertes de température et de PoE, il convient d’établir une référence sur plusieurs jours.

Alertes et HA

Les alertes utiles signalent une anomalie opérationnelle, et pas seulement une mesure isolée :

L’accessibilité SNMP ou une interface attendue tombe en panne.
La température du CPU ou du NPU reste supérieure à sa valeur de référence.
Un ventilateur installé indique 0 RPM ou ne renvoie aucune valeur.
Un bloc d’alimentation redondant passe à down(2).
La consommation PoE se rapproche du budget disponible.
Les erreurs ou les drops d’une interface augmentent de manière anormale.

Des seuils de température universels et fixes seraient trompeurs. Le modèle, le rack, la température ambiante et la charge déterminent la plage normale. Un runbook d’alerte doit d’abord vérifier la valeur, son évolution et la limite du modèle, puis évaluer le refroidissement, l’alimentation électrique, le câblage, le port du switch ou les équipements PoE.

Les alertes doivent distinguer au minimum les niveaux Avertissement et Critique. Pour chaque niveau, le runbook doit définir le responsable, la première vérification et le processus d’escalade.

Lorsqu’une défaillance matérielle est confirmée, on documente le modèle, le numéro de série, le firmware, l’heure et l’historique. Le processus de garantie et de remplacement est décrit dans Préparer un RMA et le remplacement du matériel Sophos. Pour les supports de stockage, Vérifier l’état du SSD avec SMART est plus approprié que SNMP.

Les deux appliances sont importantes dans un cluster HA. L’interrogation de la seule adresse du cluster n’affiche pas nécessairement le ventilateur, le bloc d’alimentation ou le port de l’appliance passive. Si la conception du réseau et la plateforme permettent des accès d’administration séparés, Primary et Auxiliary doivent être identifiés individuellement. L’accessibilité SNMP réelle et l’attribution des valeurs doivent être vérifiées après la configuration HA, puis à nouveau après un failover. Les principes sont expliqués dans Configurer la haute disponibilité de Sophos Firewall.

Les valeurs SNMP ne doivent pas constituer la seule preuve des performances. Interpréter correctement les données de performance de Sophos Firewall explique comment évaluer le débit et l’utilisation.

Résolution des problèmes

Timeout ou absence de réponse

Il faut d’abord vérifier l’adresse IP de supervision, le routage, Device Access, Local Service ACL, Accept queries, la version SNMP et les identifiants. Dans WebAdmin, sous Diagnostics > Packet capture, le filtre host 192.0.2.50 and port 161 peut être utilisé ; Packet Capture dans WebAdmin en explique l’utilisation.

Il est également possible d’utiliser l’option 4, Device Console, pour vérifier si la requête atteint le firewall :

tcpdump 'host 192.0.2.50 and port 161'

Arrêter le test avec Ctrl+C. Si aucun paquet n’arrive, la cause se situe avant l’agent SNMP. Si la requête arrive mais qu’aucune réponse ne repart, il faut ensuite vérifier Device Access, l’adresse IP du gestionnaire, les identifiants et la configuration de l’agent.

Échec de l’authentification ou de l’algorithme

Le nom d’utilisateur, le niveau de sécurité authPriv ainsi que les algorithmes d’authentification et de chiffrement doivent correspondre exactement à la configuration du firewall. Si le client n’accepte pas SHA-256 ou SHA-512, vérifier les algorithmes pris en charge avec snmpwalk -h et mettre Net-SNMP à jour. Il ne faut pas revenir silencieusement à MD5 ou à SNMP sans chiffrement.

En cas d’erreur de requête, il ne faut pas se concentrer sur Authorized hosts : sous SNMPv3, cette liste s’applique uniquement aux destinations des traps.

Valeurs matérielles absentes ou incorrectes

Vérifier les limites du modèle, le firmware et la version de la MIB. Sous SFOS 22.0 GA Build 365, les valeurs matérielles peuvent apparaître sous forme de strings plutôt que d’integers à cause de NC-169564 ; Build 411 corrige ce problème. Après la mise à jour, actualiser la MIB et la découverte du système de supervision.

Les messages les plus récents peuvent être consultés dans Device Console :

show logs snmpd.log lines 100
show logs xgs-healthmond.log lines 100

snmpd.log appartient à l’agent SNMP. xgs-healthmond.log aide à analyser la température du CPU et l’état des ventilateurs. D’autres correspondances figurent dans Logs des services Sophos Firewall.

Les traps n’arrivent pas

Vérifier Send traps, Authorized hosts, UDP 162 et les événements sélectionnés sous System services > Notification list. Dans Device Console, une capture ciblée indique si le firewall envoie du trafic au gestionnaire :

tcpdump 'host 192.0.2.50 and port 162'

Si les paquets quittent le firewall sans arriver à destination, vérifier le routage, les pare-feu intermédiaires et le récepteur de traps. Pour les informs SNMPv3, vérifier également l’accusé de réception du gestionnaire.