Sophos Firewall SNMP Configurer la surveillance du matériel

Avec SNMP Hardware Monitoring, vous pouvez mieux intégrer l’état d’un Sophos Firewall dans un système de surveillance existant. En plus des valeurs classiques d’accessibilité et d’interface, des métriques matérielles supplémentaires sont disponibles via MIB depuis Sophos Firewall v22. Selon le modèle, cela inclut la température CPU, la température NPU, le ventilateur, l’état de l’alimentation électrique et les valeurs PoE.

Ceci est particulièrement intéressant pour les installations XGS productives. Un pare-feu peut toujours être accessible dans WebAdmin, mais il présente toujours des signes de problèmes thermiques, de ventilateurs défectueux, d’une alimentation électrique défaillante ou d’une charge PoE inattendue. De telles conditions ne devraient pas seulement être remarquées lors de votre prochaine connexion manuelle.

Quand SNMP a du sens sur le pare-feu

SNMP est judicieux si un système de surveillance est déjà opérationnel et que le pare-feu doit y être surveillé en tant que composant d’infrastructure.

Cas d’utilisation typiques :

Surveiller la santé matérielle des appliances XGS.
Observer les températures CPU et NPU dans le temps.
Inclut l’état du ventilateur et de l’alimentation électrique dans une surveillance NOC ou MSP.
Vérifiez la charge PoE sur les modèles XGS avec des ports PoE.
Comparez les valeurs de l’interface avec la surveillance des commutateurs, des routeurs et des fournisseurs.
Corréler les alarmes du pare-feu, du commutateur, de l’onduleur et de la température ambiante. SNMP ne remplace pas l’évaluation du journal. Pour les questions de trafic et de sécurité, Log viewer, Central Firewall Reporting, Syslog ou SIEM restent plus importants. Pour les modèles de trafic sur les interfaces, la surveillance sFlow sur Sophos Firewall est une meilleure solution. SNMP répond principalement aux questions d’état : l’appareil est-il accessible, les interfaces fonctionnent-elles, les valeurs matérielles sont-elles discrètes et les valeurs changent-elles au fil du temps ?

Exigences

Avant de vous installer, vous devez clarifier ces points :

Un système de surveillance avec support SNMP est disponible.
Le pare-feu est accessible via un réseau de gestion ou de surveillance.
L’accès SNMP n’est autorisé que sous Device Access pour le système de surveillance.
L’agent SNMP du pare-feu est planifié : nom, emplacement, contact et version SNMP souhaitée sont définis.
Il est clair si le système de surveillance interroge seulement le pare-feu ou si le pare-feu doit également envoyer des traps SNMP.
Le Sophos Firewall MIB approprié est importé dans le système de surveillance.
Il est clair quels modèles de pare-feu sont surveillés et quelles valeurs matérielles fournissent ces modèles.
Des règles d’alarme sont prévues pour signaler de réels problèmes de fonctionnement et pas seulement générer du bruit.

⚠️ SNMP ne doit pas être largement accessible depuis les zones client, invité, IoT ou WAN. Les données de surveillance peuvent rendre visibles les modèles, les interfaces, les valeurs d’état et les états de fonctionnement. L’accès appartient à un réseau de gestion ou de surveillance digne de confiance.

Séparez proprement SNMP, sFlow et les rapports

SNMP, sFlow et les rapports fournissent des réponses différentes.

Les outils répondent à différentes questions :

SNMP : Bon pour les valeurs d’accessibilité, de matériel et d’interface. Pas idéal pour les règles de pare-feu individuelles, les blocages d’URL ou les erreurs VPN.
sFlow : Bon pour les flux de trafic sur une interface. Pas idéal pour une analyse précise des paquets ou des règles.
Log Viewer, Syslog et Central Reporting : Idéal pour le contexte des règles, des modules, des utilisateurs et des événements. Pas idéal pour l’état du matériel et les valeurs d’interrogation d’interface à long terme.
Packet Capture : Bon pour la question de savoir ce qui peut réellement être vu sur une interface. Ne convient pas à une surveillance permanente.

En pratique, ces outils sont combinés. SNMP signale, par exemple, des erreurs de température élevée ou d’interface. Then check Log Viewer, Packet Capture, switch port, ambient temperature or the affected network segment.

Quelles valeurs matérielles SFOS 22 offre

Sophos a décrit des métriques matérielles SNMP supplémentaires dans les notes de version SFOS 22. La disponibilité dépend du modèle de pare-feu.

Indicateurs matériels clés :

CPU temperature : disponible pour tous les modèles XGS selon Sophos.
NPU temperature : pour les modèles XGS sauf XGS 88/88w, 108/108w, 118/118w et 128/128w.
Fan speed : pour les modèles XGS sauf XGS 88/88w et 108/108w.
Statut Power supply : pour XGS 2100 et supérieur.
PoE mesures : pour les modèles XGS avec PoE, sauf XGS 116/116w.

Cette classification est importante pour les attentes. Si un petit modèle de bureau ne fournit pas de valeur de ventilateur ou de température NPU, il ne s’agit pas automatiquement d’une erreur de surveillance. Tout d’abord, il faut vérifier si le modèle prend en charge la métrique respective.

Accès SNMP sécurisé

Le premier contrôle de sécurité n’a pas lieu dans le système de surveillance, mais sur le pare-feu lui-même.

Sous Administration > Accès aux appareils SNMP ne doit être accessible qu’à partir du réseau dans lequel se trouve le serveur de surveillance. Si le système de surveillance possède une seule adresse IP fixe, une règle d’exception ACL de service local est généralement préférable à une version à zone étendue.

Règles de base utiles :

Ne pas autoriser SNMP de WAN.
Ne libérez pas SNMP pour des zones client ou serveur entières si un seul hôte de surveillance interroge.
Définir le serveur de surveillance comme son propre objet hôte ou réseau de gestion.
Vérifiez l’accès aux modifications avec Packet Capture ou test de surveillance.
Supprimez 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 à WAN ne remplace pas ce paramètre.

Configurer l’agent SNMP et les entrées de manager

La configuration de base se fait sous Administration > SNMP. Le pare-feu doit d’abord être activé comme agent SNMP avant qu’un système de surveillance puisse l’interroger utilement.

Configuration de base :

Ouvrir Administration > SNMP.
Activer Enable SNMP agent.
Saisir un nom clair, idéalement aligné sur le hostname du pare-feu.
Renseigner l’emplacement et le contact afin que les alarmes puissent ensuite être associées à un site et à une personne responsable.
Enregistrer avec Apply.
Utiliser Download MIB et importer la MIB dans le système de surveillance.

Sophos décrit deux ports standard pour l’agent : les requêtes arrivent à l’agent via UDP 161, les traps sont envoyés au manager via UDP 162. Ces ports doivent être corrects dans la configuration du pare-feu, mais aussi joignables entre le système de surveillance, le routage, les pare-feu locaux des hôtes et les éventuels segments de réseau de gestion.

Pour SNMPv3, un utilisateur est créé sous Administration > SNMP > SNMPv3 users and traps. Le nom d’utilisateur doit être choisi consciemment car, selon Sophos, il ne peut plus être modifié ensuite. On décide ensuite séparément :

Accept queries : Le pare-feu répond aux requêtes SNMP avec cet utilisateur.
Send traps : Le pare-feu peut envoyer des traps au manager.
Authorized hosts : Selon Sophos, cette liste s’applique uniquement aux destinations de traps, pas comme liste d’accès pour les requêtes SNMP.
Encryption algorithm : AES, DES ou None. En production, le chiffrement devrait être activé si le système de surveillance le prend en charge.
Authentication algorithm : MD5, SHA256 ou SHA512. Les nouvelles installations devraient utiliser SHA256 ou SHA512 si possible.
Mots de passe : Sophos exige au moins 12 caractères pour le chiffrement et l’authentification.

Pour SNMPv1/v2c, une entrée de communauté est créée sous Administration > SNMP > SNMPv1/v2c. On définit le nom, le community string, la version IP, l’adresse IP du manager et les options Accept Queries et Send traps. Le community string fonctionne comme un mot de passe pour les requêtes SNMP et ne doit donc pas apparaître en clair dans les captures d’écran, les tickets ou les modèles de surveillance.

Si des traps sont utilisés, l’entrée SNMP ne suffit pas toujours comme configuration d’alerte complète. Sous System services > Notification list, les traps SNMP et les types d’alerte souhaités doivent également être activés.

Choisissez consciemment la version SNMP

Si possible, SNMPv3 doit être utilisé car il permet l’authentification et, avec la configuration AuthPriv appropriée, le chiffrement. SNMPv1 et SNMPv2c fonctionnent avec Community Strings. Ces Community Strings ne sont pas des comptes d’utilisateurs, mais des secrets partagés et doivent être protégés en conséquence.

Pour SNMPv1/v2c, Sophos mentionne un changement dans SFOS 22 : Vous pouvez ajouter le Community String et choisir si la configuration s’applique à IPv4 ou IPv6. Lors de la mise à niveau, le pare-feu adopte les noms existants comme Community String et crée des noms d’objets migrés avec le préfixe snmp.

Après une mise à niveau, vous devez donc vérifier :

Existe-t-il des anciens SNMPv1/v2c Community Strings ?
Les objets snmp automatiquement migrés sont-ils clairement nommés ? - IPv4, IPv6 ou les deux sont-ils vraiment nécessaires ?
Les anciennes sources de surveillance peuvent-elles être supprimées ?
Est-ce que SNMPv3 est possible ou la v2c est-elle encore nécessaire pour des raisons de compatibilité ?

⚠️ Community Strings ne doit pas être traité comme des étiquettes inoffensives. De telles chaînes appartiennent à un concept de mot de passe ou de secrets, ne doivent pas être copiées dans les tickets et ne doivent pas être visibles dans les captures d’écran.

Importez MIB et vérifiez les OID

Pour qu’un système de surveillance reconnaisse de manière significative les valeurs Sophos, il a besoin du fichier MIB approprié. Le MIB décrit les OID disponibles pour les valeurs de pare-feu, d’interface et de matériel.

Procédure pratique :

Obtenir le fichier MIB actuel sous Administration > SNMP > Download MIB.
Importez MIB dans le système de surveillance.
Ajoutez un pare-feu avec SNMPv3 ou une configuration v1/v2c délibérément choisie.
Détectez le modèle, la version du micrologiciel et les OID accessibles.
Vérifiez les métriques matérielles par rapport au modèle spécifique.
Effectuez un sondage manuel et vérifiez la plausibilité des valeurs.
Ensuite seulement, activez les règles d’alarme.

After firmware upgrades, the MIB page should be checked again. Les nouvelles versions SFOS peuvent ajouter des OID ou modifier des zones existantes. Si un système de surveillance ne résout plus correctement les valeurs après une mise à jour, vous ne devez pas d’abord soupçonner le pare-feu, mais plutôt vérifier la version MIB, la découverte et l’affectation OID.

Alertes utiles

La surveillance SNMP n’est utile que si les alarmes sont réglées judicieusement. Des seuils trop étroits créent du bruit, des seuils trop larges signalent les problèmes trop tard.

Zones d’alarme typiques :

Disponibilité : Le pare-feu ne répond plus via SNMP ou ping.
CPU temperature : La température augmente continuellement au-dessus de la plage normale.
NPU temperature : La tendance de la température est sensiblement ou en permanence supérieure aux valeurs comparatives.
Fan speed : La valeur du ventilateur est manquante, nulle ou nettement en dehors de la plage normale.
Power supply : L’alimentation redondante est manquante ou signale une erreur.
PoE : La charge PoE s’approche du budget disponible.
Interfaces : Port désactivé, compteur d’erreurs ou bande passante inhabituelle. Une ligne de base est importante pour les valeurs de température. Un petit pare-feu de bureau dans une armoire technologique chaleureuse se comporte différemment d’un appareil en rack dans une pièce à température contrôlée. Par conséquent, vous devez d’abord observer le fonctionnement normal pendant quelques jours, puis définir des seuils de production.

Une alarme à deux niveaux est souvent utile pour les emplacements productifs :

Avertissement : La valeur est anormale mais le service est en cours d’exécution. Vérifiez l’historique, l’emplacement, la charge et les modifications récentes.
Critique : La valeur indique un risque aigu, par exemple une panne d’alimentation électrique, une température très élevée en permanence, une perte d’accessibilité ou une augmentation rapide des erreurs d’interface.

Cela signifie que le suivi reste capable d’agir. Il n’est pas nécessaire d’intensifier immédiatement toutes les hausses de température, mais une tendance récurrente ne doit pas disparaître dans le bruit normal du tableau de bord.

Définir le runbook d’alarme et la responsabilité

Une alarme SNMP n’est utile que si l’on sait clairement qui réagit et quelle procédure s’applique. Les valeurs matérielles sont souvent des indicateurs avancés : une augmentation de la température, une valeur de ventilateur manquante ou une alarme d’alimentation électrique ne signifie pas automatiquement que l’appareil doit être remplacé immédiatement. Mais cela signifie que la condition doit être classifiée et documentée.

Une courte entrée du runbook doit exister pour les pare-feu productifs :

Premiers contrôles typiques :

Pare-feu non accessible via SNMP : Vérifiez le réseau de gestion, Device Access, le routage, le serveur de surveillance et l’accessibilité de l’appliance.
La température augmente constamment : Comparez la température ambiante, la ventilation, la position du rack, la poussière, la charge et l’historique.
La valeur du ventilateur est manquante ou anormale : Vérifiez la limite du modèle, la valeur du capteur, le bruit, la tendance de la température et la pertinence du support.
L’alimentation signale une erreur : Vérifiez l’alimentation électrique, l’onduleur, les câbles, l’alimentation redondante et le risque HA.
PoE la charge est élevée : Vérifiez les appareils connectés, le budget PoE et les réserves planifiées.
Les erreurs d’interface augmentent : Vérifiez le câble, le port du commutateur, le duplex/vitesse, le module SFP et le transfert du fournisseur.

L’ordre est important : vérifier d’abord la visibilité et la plausibilité, puis évaluer les risques, puis préparer le processus de support ou d’échange. Dans le cas d’éventuels défauts matériels, le numéro de série, le modèle, la version du micrologiciel, l’heure, la métrique concernée, l’historique et la capture d’écran ou l’extrait de surveillance doivent également être documentés. En fin de compte, les questions de garantie et de RMA dépendent non seulement de l’alarme, mais également de l’appareil spécifique, de l’état du support et du modèle d’erreur.

Pour les sujets SSD, SNMP n’est pas la route principale. Si l’accent est mis sur l’état du disque ou la charge d’écriture, Sophos Firewall Vérifier l’état du SSD via SMART est une meilleure solution.

HA clusters et plusieurs pare-feu

Dans les environnements HA, vous devez définir clairement la manière dont les deux appareils seront surveillés. Il ne suffit pas toujours d’observer l’adresse du cluster. Pour les valeurs matérielles, les deux appareils sont souvent pertinents car un ventilateur, une alimentation ou un port de l’appareil passif peut également tomber en panne.

Questions importantes :

Le primaire et l’auxiliaire sont-ils reconnus séparément ?
Les deux appareils ont-ils leurs propres adresses de gestion IP pour la surveillance ?
Le numéro de série, le nom d’hôte ou le modèle sont-ils clairement affichés dans la surveillance ?
Les alarmes restent-elles compréhensibles après un basculement ?
Une panne d’alimentation électrique sur l’appareil passif est-elle également signalée ? Pour l’opération HA elle-même, Sophos Firewall Configurer la haute disponibilité convient. SNMP ne doit pas être planifié de manière isolée, mais avec les mises à jour du micrologiciel, les tests de basculement, les concepts de sauvegarde et la documentation opérationnelle.

Validation après configuration

Après avoir configuré SNMP, vous ne devez pas seulement vérifier si la surveillance est verte. Ce qui est important est de savoir si les bonnes données proviennent de la bonne source.

Liste de contrôle :

L’accès SNMP n’est possible qu’à partir du réseau de surveillance.
L’agent SNMP est actif et répond sur UDP 161.
Si des traps sont utilisés, les messages de test arrivent au manager via UDP 162.
Le pare-feu est détecté avec le nom d’hôte, le modèle et la version du micrologiciel corrects.
Le Sophos MIB est importé et les valeurs matérielles sont clairement nommées.
Les métriques non prises en charge sont documentées comme une limite du modèle et non comme une erreur.
Les valeurs de température, de ventilateur, d’alimentation et PoE sont plausibles.
Une alarme test est déclenchée et parvient au bon destinataire.
Pour les clusters HA, les deux appareils ou la logique de cluster souhaitée sont vérifiés.
Après une mise à niveau du micrologiciel, Discovery est à nouveau testé.

Pour des problèmes de performances et de débit, vous ne devez pas surinterpréter les valeurs SNMP. La classification des données de performances Sophos est décrite dans l’article Comprendre les données de performances 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 > Accès aux appareils. Vérifiez ensuite l’adresse IP, le routage, les règles ACL locales, la version SNMP, les informations d’identification Community String ou SNMPv3. S’il n’est pas clair si les paquets atteignent le pare-feu, Packet Capture sur l’interface concernée est utile. Une règle de pare-feu normale ne résoudra pas ce problème si le trafic est dirigé vers le pare-feu lui-même.

MIB est importé mais des valeurs sont manquantes

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. Comparez ensuite la version MIB, l’affectation OID et la version du micrologiciel.

Après la mise à niveau, les objets SNMP sont nommés différemment

Pour SNMPv1/v2c, SFOS peut créer 22 objets migrés avec le préfixe snmp. Après une mise à niveau, vous devez donc vérifier Community Strings, les noms d’objets et la découverte de la surveillance. Si la surveillance fonctionne avec des noms au lieu d’OID stables, les modèles devront peut-être être ajustés.

La surveillance signale trop d’alarmes de température

Les seuils sont alors probablement fixés de manière trop étroite ou sans référence. Enregistrez d’abord les valeurs normales sur plusieurs jours. Définissez ensuite des 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 à la hausse permanente de la température.

HA le cluster n’affiche qu’un seul appareil

Il faut ensuite vérifier si la surveillance interroge uniquement l’adresse du cluster ou si les deux appareils sont accessibles séparément. L’appliance passive est également pertinente pour l’état du matériel. Pour les clusters productifs, vous devez documenter quelle adresse IP représente quel appareil et quel rôle.

Liste de contrôle opérationnel

Autoriser uniquement SNMP à partir des réseaux de gestion ou de surveillance.
Préférez SNMPv3 si le système de surveillance le supporte correctement.
Traitez SNMPv1/v2c Community Strings comme des secrets.
Importez Sophos MIB et vérifiez les mises à jour du micrologiciel.
Documenter les limites du modèle pour les valeurs matérielles.
Réglez la température et les seuils PoE en fonction de références réelles.
Nommez clairement les appareils HA et évaluez-les séparément.
Documenter le runbook des alarmes avec vérification initiale, escalade et responsabilité.
Si un matériel est suspecté, sauvegardez le modèle, le numéro de série, la version du micrologiciel et l’historique.
Testez régulièrement les alarmes et clarifiez les responsabilités.
Combinez les données SNMP avec les journaux, sFlow, Packet Capture et Central Reporting.

FAQ

Quelles valeurs matérielles Sophos Firewall peuvent être surveillées via SNMP ?

Depuis le SFOS 22, selon le modèle XGS, des valeurs matérielles supplémentaires sont disponibles via les MIB : température CPU, température NPU, vitesse du ventilateur, état de l’alimentation et mesures PoE. Tous les modèles ne fournissent pas toutes les mesures.

Devez-vous utiliser SNMPv3 pour Sophos Firewall ?

Si le système de surveillance prend correctement en charge SNMPv3, SNMPv3 est le meilleur choix. SNMPv1 et SNMPv2c utilisent Community Strings et ne doivent être utilisés que dans des réseaux de gestion étroits.

Authorized hosts dans SNMPv3 sert-il de liste d'accès pour les requêtes ?

Non. Selon Sophos, la liste Authorized hosts dans SNMPv3 est utilisée uniquement pour les destinations de traps. Pour les requêtes, les utilisateurs, l’authentification, le chiffrement et Device Access sont déterminants.

Pourquoi SNMP valeurs matérielles manquent-elles sur les petits modèles XGS ?

La disponibilité dépend du modèle. Par exemple, selon Sophos, tous les modèles d’ordinateurs de bureau ne fournissent pas NPU de température, de valeurs de ventilateur ou de mesures PoE. Les valeurs manquantes ne sont donc pas automatiquement une erreur dans la configuration SNMP.

SNMP est-il identique à sFlow sur Sophos Firewall ?

Non. SNMP interroge l’état, les valeurs du matériel et de l’interface. sFlow envoie des données de trafic échantillonnées à un collecteur. SNMP convient à l’état du matériel, sFlow est plus adapté à l’analyse des flux.

SNMP doit-il être autorisé dans Device Access ?

Oui, l’accès à SNMP est un service de pare-feu local et est contrôlé via Device Access ou Local Service ACL. Le service ne doit être accessible qu’au système de surveillance ou à un réseau de surveillance dédié.