Configurer la surveillance matérielle SNMP sur Sophos Firewall
Avec la surveillance matérielle SNMP, il est possible d’intégrer plus efficacement l’état d’un Sophos Firewall dans un système de surveillance existant. Outre les valeurs classiques de disponibilité et d’interface, depuis Sophos Firewall v22, des métriques matérielles supplémentaires sont disponibles via les MIBs. Selon le modèle, cela inclut la température du CPU, la température du NPU, les ventilateurs, l’état de l’alimentation et les valeurs PoE.
Cela est particulièrement intéressant pour les installations XGS en production. Un pare-feu peut être accessible via le WebAdmin, mais présenter néanmoins des signes de problèmes thermiques, de ventilateurs défectueux, d’une alimentation défaillante ou d’une charge PoE inattendue. Ces états ne devraient pas être découverts uniquement lors de la prochaine connexion manuelle.
Quand SNMP est-il pertinent sur le pare-feu
SNMP est pertinent lorsqu’un système de surveillance est déjà en place et que le pare-feu doit y être surveillé en tant que composant d’infrastructure.
Cas d’utilisation typiques :
- Surveiller l’état matériel des appliances XGS.
- Observer la température du CPU et du NPU au fil du temps.
- Intégrer l’état des ventilateurs et des alimentations dans une surveillance NOC ou MSP.
- Contrôler la charge PoE sur les modèles XGS avec ports PoE.
- Comparer les valeurs d’interface avec la surveillance des commutateurs, routeurs et fournisseurs.
- Corréler les alertes du pare-feu, du commutateur, de l’onduleur et de la température ambiante.
SNMP ne remplace pas l’analyse des journaux. Pour les questions de trafic et de sécurité, Log viewer, Central Firewall Reporting, Syslog ou un SIEM restent plus importants. Pour les modèles de trafic sur les interfaces, sFlow Monitoring sur Sophos Firewall est plus adapté. SNMP répond principalement aux questions d’état : l’appareil est-il accessible, les interfaces fonctionnent-elles, les valeurs matérielles sont-elles normales et les valeurs changent-elles au fil du temps ?
Prérequis
Avant la configuration, il est important de clarifier ces points :
- Un système de surveillance prenant en charge SNMP est disponible.
- Le pare-feu est accessible via un réseau de gestion ou de surveillance.
- L’accès SNMP est autorisé sous Device Access uniquement pour le système de surveillance.
- Le MIB approprié de Sophos Firewall est importé dans le système de surveillance.
- Il est clair quels modèles de pare-feu seront surveillés et quelles valeurs matérielles ces modèles fournissent.
- Les règles d’alerte sont planifiées de manière à signaler de vrais problèmes opérationnels et non seulement du bruit.
⚠️ SNMP ne devrait pas être largement accessible depuis les zones Client, Invité, IoT ou WAN. Les données de surveillance peuvent rendre visibles le modèle, les interfaces, les valeurs de statut et les états opérationnels. L’accès doit être limité à un réseau de gestion ou de surveillance de confiance.
Séparer clairement SNMP, sFlow et Reporting
SNMP, sFlow et Reporting fournissent des réponses différentes.
| Outil | Bonne question | Pas idéal pour |
|---|---|---|
| SNMP | Le pare-feu est-il accessible, quelles sont les valeurs matérielles et d’interface ? | Règle de pare-feu individuelle, blocage d’URL ou erreur VPN |
| sFlow | Quels flux de trafic passent par une interface ? | Analyse précise des paquets ou des règles |
| Log Viewer / Syslog / Central Reporting | Quelle règle, quel module ou quel utilisateur était impliqué ? | État matériel et valeurs de sondage d’interface à long terme |
| Packet Capture | Que voit-on réellement sur l’interface ? | Surveillance permanente |
En pratique, ces outils sont combinés. SNMP signale par exemple une température élevée ou des erreurs d’interface. Ensuite, on vérifie Log Viewer, Packet Capture, le port du commutateur, la température ambiante ou le segment de réseau concerné.
Quelles valeurs matérielles SFOS 22 fournit
Sophos a décrit dans les notes de version de SFOS 22 des métriques matérielles SNMP supplémentaires. Leur disponibilité dépend du modèle de pare-feu.
| Métrique | Disponible selon Sophos pour |
|---|---|
| Température du CPU | tous les modèles XGS |
| Température du NPU | modèles XGS sauf XGS 88/88w, 108/108w, 118/118w, 128/128w |
| Vitesse du ventilateur | modèles XGS sauf XGS 88/88w et 108/108w |
| État de l’alimentation | XGS 2100 et supérieur |
| Mesures PoE | modèles XGS avec PoE, sauf XGS 116/116w |
Ce tableau est important pour les attentes. Si un petit modèle de bureau ne fournit pas de valeur de ventilateur ou de température NPU, ce n’est pas automatiquement une erreur de surveillance. Il faut d’abord vérifier si le modèle prend en charge la métrique en question.
Sécuriser l’accès SNMP
Le premier contrôle de sécurité ne se fait pas dans le système de surveillance, mais sur le pare-feu lui-même.
Sous Administration > Device access, SNMP ne devrait être accessible que depuis le réseau où se trouve le serveur de surveillance. Si le système de surveillance a une adresse IP fixe unique, une Local service ACL exception rule est généralement préférable à une autorisation de zone large.
Règles de base sensées :
- Ne pas autoriser SNMP depuis
WAN. - Ne pas autoriser SNMP pour des zones complètes de clients ou de serveurs si seul un hôte de surveillance interroge.
- Définir le serveur de surveillance comme un objet hôte ou un réseau de gestion distinct.
- Vérifier l’accès après les modifications avec Packet Capture ou un test de surveillance.
- Supprimer les règles SNMP inutilisées et les anciennes sources de surveillance.
Device Access contrôle le trafic vers le pare-feu lui-même. Une règle de pare-feu normale pour le trafic LAN-vers-WAN ne remplace pas ce paramètre.
Choisir consciemment la version SNMP
Si possible, SNMPv3 devrait être utilisé car il permet l’authentification et, avec une configuration AuthPriv appropriée, le chiffrement. SNMPv1 et SNMPv2c fonctionnent avec des Community Strings. Ces Community Strings ne sont pas des comptes utilisateurs, mais des secrets partagés et doivent être protégés en conséquence.
Pour SNMPv1/v2c, Sophos mentionne dans SFOS 22 un changement : il est possible d’ajouter le Community String et de choisir si la configuration s’applique à IPv4 ou IPv6. Lors de la mise à niveau, le pare-feu reprend les noms existants comme Community String et génère des noms d’objets migrés avec le préfixe snmp.
Après une mise à niveau, il convient de vérifier :
- Y a-t-il d’anciens Community Strings SNMPv1/v2c ?
- Les objets
snmpmigrés automatiquement sont-ils nommés de manière compréhensible ? - IPv4, IPv6 ou les deux sont-ils vraiment nécessaires ?
- Les anciennes sources de surveillance peuvent-elles être supprimées ?
- SNMPv3 est-il possible ou v2c reste-t-il nécessaire pour des raisons de compatibilité ?
⚠️ Les Community Strings ne doivent pas être traités comme de simples étiquettes. Ces chaînes appartiennent à un concept de mot de passe ou de secrets, ne doivent pas être copiées dans des tickets et ne doivent pas être visibles dans des captures d’écran.
Importer le MIB et vérifier les OIDs
Pour qu’un système de surveillance reconnaisse correctement les valeurs Sophos, il a besoin du fichier MIB approprié. Le MIB décrit quelles OIDs sont disponibles pour les valeurs de pare-feu, d’interface et de matériel.
Approche pratique :
- Obtenez le fichier MIB actuel depuis le Sophos Firewall ou la documentation Sophos appropriée.
- Importez le MIB dans le système de surveillance.
- Ajoutez le pare-feu avec SNMPv3 ou une configuration v1/v2c choisie consciemment.
- Laissez le modèle, la version du firmware et les OIDs accessibles être reconnus.
- Vérifiez les métriques matérielles par rapport au modèle concret.
- Effectuez un sondage manuel et validez les valeurs.
- Activez les règles d’alerte uniquement après cela.
Après les mises à niveau du firmware, la page MIB doit être vérifiée à nouveau. Les nouvelles versions de SFOS peuvent ajouter des OIDs ou modifier des zones existantes. Si un système de surveillance ne résout plus correctement les valeurs après une mise à jour, il ne faut pas d’abord suspecter le pare-feu, mais vérifier la version du MIB, la découverte et l’attribution des OIDs.
Alerte pertinente
La surveillance SNMP n’est utile que si les alertes sont correctement définies. Des seuils trop serrés génèrent du bruit, des seuils trop larges signalent les problèmes trop tard.
Domaines d’alerte typiques :
| Domaine | Vérification pertinente |
|---|---|
| Accessibilité | Le pare-feu ne répond plus via SNMP ou Ping |
| Température du CPU | La température dépasse durablement la plage normale |
| Température du NPU | Tendance de température inhabituelle ou durablement plus élevée que les valeurs de comparaison |
| Vitesse du ventilateur | Valeur du ventilateur manquante, nulle ou nettement en dehors de la plage normale |
| Alimentation | Alimentation redondante manquante ou signalant une erreur |
| PoE | La charge PoE approche du budget disponible |
| Interfaces | Port en panne, compteur d’erreurs, bande passante inhabituelle |
Pour les valeurs de température, une ligne de base est importante. Un petit pare-feu de bureau dans une armoire technique chaude se comporte différemment d’une appliance en rack dans une salle climatisée. Par conséquent, il est conseillé d’observer quelques jours de fonctionnement normal avant de définir des seuils productifs.
Définir un Runbook d’alerte et des responsabilités
Une alerte SNMP n’est utile que si l’on sait ensuite qui réagit et quelle procédure s’applique. Les valeurs matérielles sont souvent des indicateurs précoces : une température croissante, une valeur de ventilateur manquante ou une alerte d’alimentation ne signifient pas automatiquement que l’appliance doit être immédiatement remplacée. Cela signifie cependant que l’état doit être évalué et documenté.
Pour les pare-feux en production, une entrée de Runbook courte devrait exister :
| Alerte | Première vérification |
|---|---|
| Pare-feu non accessible via SNMP | Vérifiez le réseau de gestion, l’accès aux appareils, le routage, le serveur de surveillance et l’accessibilité de l’appliance |
| Température augmente durablement | Comparez la température ambiante, la ventilation, la position du rack, la poussière, la charge et la tendance |
| Valeur du ventilateur manquante ou inhabituelle | Vérifiez la limite du modèle, la valeur du capteur, le bruit, la tendance de température et la pertinence du support |
| Alimentation signale une erreur | Contrôlez l’alimentation, l’onduleur, les câbles, l’alimentation redondante et le risque HA |
| Charge PoE élevée | Vérifiez les appareils connectés, le budget PoE et les réserves planifiées |
| Erreurs d’interface augmentent | Vérifiez les câbles, le port du commutateur, le duplex/vitesse, le module SFP et la remise au fournisseur |
L’ordre est important : d’abord vérifier la visibilité et la plausibilité, puis évaluer le risque, ensuite préparer le processus de support ou de remplacement. En cas de suspicion de défaut matériel, il convient également de documenter le numéro de série, le modèle, la version du firmware, le moment, la métrique concernée, la tendance et une capture d’écran ou un extrait de surveillance. Les questions de garantie et de RMA dépendent à la fin non seulement de l’alerte, mais de l’appareil concret, du statut de support et de l’image de l’erreur.
Pour les sujets SSD, SNMP n’est pas la voie principale appropriée. Si l’état du disque ou la charge d’écriture est au centre des préoccupations, Vérifier la santé du SSD de Sophos Firewall via SMART est plus adapté.
HA-Cluster et plusieurs pare-feux
Dans les environnements HA, il est important de définir clairement comment les deux appareils seront surveillés. Il ne suffit pas toujours de surveiller uniquement l’adresse du cluster. Pour les valeurs matérielles, les deux appliances sont souvent pertinentes, car un ventilateur, une alimentation ou un port sur l’appliance passive peut également tomber en panne.
Questions importantes :
- Les appareils primaire et auxiliaire sont-ils reconnus séparément ?
- Les deux appareils ont-ils leurs propres adresses IP de gestion pour la surveillance ?
- Le numéro de série, le nom d’hôte ou le modèle sont-ils affichés de manière unique dans la surveillance ?
- Les alertes restent-elles compréhensibles après un basculement ?
- Une erreur d’alimentation sur l’appliance passive est-elle également signalée ?
Pour le fonctionnement HA lui-même, Configurer la haute disponibilité sur Sophos Firewall est approprié. SNMP ne devrait pas être planifié isolément, mais en conjonction avec les mises à jour du firmware, les tests de basculement, le concept de sauvegarde et la documentation opérationnelle.
Validation après la configuration
Après la configuration SNMP, il ne suffit pas de vérifier si la surveillance est verte. Il est important de savoir si les bonnes données proviennent de la bonne source.
Liste de contrôle :
- L’accès SNMP n’est possible que depuis le réseau de surveillance.
- Le pare-feu est reconnu avec le bon nom d’hôte, modèle et version du firmware.
- Le MIB Sophos est importé et les valeurs matérielles sont correctement nommées.
- Les métriques non prises en charge sont documentées comme des limites de modèle, pas comme des erreurs.
- Les valeurs de température, de ventilateur, d’alimentation et de PoE sont plausibles.
- Une alerte de test est déclenchée et atteint le bon destinataire.
- Dans les clusters HA, les deux appareils ou la logique de cluster souhaitée sont vérifiés.
- Après une mise à niveau du firmware, la découverte est testée à nouveau.
Pour les questions de performance et de débit, les valeurs SNMP ne doivent pas être surinterprétées. L’interprétation des données de performance de Sophos est décrite dans l’article Comprendre correctement les données de performance de Sophos Firewall.
Dépannage
Le pare-feu ne répond pas à SNMP
Vérifiez d’abord si le système de surveillance provient de la zone attendue et si SNMP est autorisé sous Administration > Device access. Ensuite, vérifiez l’adresse IP, le routage, les règles ACL locales, la version SNMP, le Community String ou les informations d’identification SNMPv3.
Si vous ne savez pas si les paquets atteignent le pare-feu, Packet Capture sur l’interface concernée peut aider. Une règle de pare-feu normale ne résout pas ce problème si le trafic est destiné au pare-feu lui-même.
Le MIB est importé, mais les valeurs manquent
Vérifiez d’abord si la métrique manquante est disponible pour le modèle utilisé. Les petits modèles XGS ne fournissent pas toutes les valeurs matérielles. Ensuite, comparez la version du MIB, l’attribution des OIDs et la version du firmware.
Après la mise à niveau, les objets SNMP sont nommés différemment
Avec SNMPv1/v2c, SFOS 22 peut générer des objets migrés avec le préfixe snmp. Après une mise à niveau, il convient donc de vérifier les Community Strings, les noms d’objets et la découverte de la surveillance. Si la surveillance fonctionne avec des noms au lieu d’OIDs stables, des modèles peuvent devoir être ajustés.
La surveillance signale trop d’alarmes de température
Les seuils sont probablement trop serrés ou définis sans ligne de base. Commencez par enregistrer les valeurs normales sur plusieurs jours. Ensuite, définissez les seuils en fonction du modèle, de l’emplacement et de la température ambiante. Les pics courts individuels doivent être évalués différemment d’une tendance de température en augmentation constante.
Le cluster HA n’affiche qu’un appareil
Il faut alors vérifier si la surveillance interroge uniquement l’adresse du cluster ou si les deux appliances sont accessibles séparément. Pour l’état matériel, l’appliance passive est également pertinente. Dans les clusters en production, il convient de documenter quelle adresse IP représente quel appareil et quel rôle.
Liste de contrôle opérationnelle
- Autoriser SNMP uniquement depuis les réseaux de gestion ou de surveillance.
- Préférer SNMPv3 si le système de surveillance le prend en charge correctement.
- Traiter les Community Strings SNMPv1/v2c comme des secrets.
- Importer le MIB Sophos et vérifier après les mises à niveau du firmware.
- Documenter les limites de modèle pour les valeurs matérielles.
- Définir les seuils de température et de PoE en fonction de lignes de base réelles.
- Nommer clairement les appareils HA et les évaluer séparément.
- Documenter le Runbook d’alerte avec première vérification, escalade et responsabilité.
- En cas de suspicion de matériel, sécuriser le modèle, le numéro de série, la version du firmware et la tendance.
- Tester régulièrement les alertes et clarifier la responsabilité.
- Combiner les données SNMP avec les journaux, sFlow, Packet Capture et Central Reporting.