Configurer une supervision SNMP sécurisée pour Sophos Switch

La page SNMP de Sophos Fusion gère deux flux distincts : un gestionnaire SNMP interroge le switch et le switch peut envoyer des notifications à un récepteur. Pour toute nouvelle intégration, utilisez SNMPv3, Privilege, SHA et AES_CFB128. Une Read view strictement limitée suffit à la supervision ; n’accordez aucun droit d’écriture.

Procédure rapide :

1. Vérifier l’accessibilité, la licence, la portée du changement et les OID nécessaires.
2. Sous Switches > [Switch, Stack or Site] > SNMP > Global settings, activer SNMP sans modifier Engine ID.
3. Créer sous Users & Communities un utilisateur SNMPv3 avec Privilege.
4. N’accorder que les lectures requises dans Groups, Views et Access lists.
5. Importer les MIB du modèle et tester positivement et négativement l’interrogation.
6. Si nécessaire seulement, configurer Target parameters, Notifications et Target address.
7. Valider séparément l’interrogation et la réception des notifications.

SNMPv1/v2c transmet le Community String en clair. Laissez Enable SNMP v1/v2c for this user désactivé, sauf pour un ancien système justifié sans SNMPv3.

Prérequis, rôles et accessibilité

Chaque switch géré centralement doit disposer d’une Subscription Sophos Switch Support and Services valide pour être modifié dans Fusion. Sans elle, le switch fonctionne localement mais Fusion ne peut pas appliquer de changements. Voir Licences Sophos Fusion.

La configuration revient à un administrateur Sophos Fusion autorisé sur le switch, stack ou site sélectionné ; aucun rôle SNMP dédié n’est documenté. Le responsable de la supervision fournit les données du gestionnaire, importe les MIB et effectue les tests. Échangez les secrets par un canal approuvé, jamais dans un ticket ou une capture d’écran.

Avant d’enregistrer, déterminez la cible et la portée réelle, les IP de gestion et du gestionnaire, le routage et les filtres dans les deux sens, le port UDP du récepteur, les branches MIB/OID nécessaires, un nom unique et deux secrets robustes distincts, ainsi que le besoin éventuel de Traps ou d’Informs.

Les Access lists limitent les droits OID d’un groupe ; elles ne remplacent pas une ACL réseau et ne filtrent pas les IP sources. Limitez donc le réseau de gestion aux systèmes prévus et vérifiez le port d’interrogation réel. Pour un site ou un stack, commencez par un switch pilote. Configuration source indique l’origine du réglage ; Not set applique la configuration locale et ne signifie pas forcément Off.

Définir le modèle de sécurité SNMPv3

En production, choisissez Privilege. Authentication protocol propose MD5 (HMAC-MD5) et SHA (HMAC-SHA-96), tandis que Encryption protocol propose DES_CBC et AES_CFB128. La combinaison disponible la plus forte est SHA avec AES_CFB128.

Adaptez ces noms, générez aléatoirement les deux secrets et stockez-les séparément. Choisissez les OID dans les MIB du modèle réellement déployé ; il n’existe pas d’OID Sophos universelle pour ce besoin.

1. Définir les paramètres SNMP globaux

Dans Switches, sélectionnez le switch, stack ou site puis SNMP. Sous Global settings, réglez SNMP status sur On, conservez Default pour Engine ID, cliquez sur Update, puis contrôlez Configuration source et l’état effectif. Une Engine ID manuelle doit être hexadécimale et comporter 10 à 64 caractères.

Clear réinitialise les valeurs de la vue ; il ne restaure pas automatiquement l’état de production antérieur.

2. Créer l’utilisateur SNMPv3

La liste Users & Communities affiche Name, Protocols, Authentication et Configuration source. Sous Users & Communities, cliquez sur Add. Saisissez un Name de 4 à 20 caractères, par exemple swmon_v3; choisissez Privilege comme Privilege mode, SHA comme Authentication protocol, un Authentication password neuf de 8 à 32 caractères, AES_CFB128 comme Encryption protocol et un Encryption password neuf de 8 à 40 caractères. Laissez Enable SNMP v1/v2c for this user désactivé, cliquez sur Add et vérifiez la liste.

Le nom et les mots de passe ne doivent contenir ni espace ni ", \, %, &, ?, ', !, ;, |, +. Si v1/v2c est exceptionnellement activé, Fusion dérive une Community du Name. Son Transport tag doit correspondre au Tag identifier sous Notifications > Target address. Cette exception en clair doit avoir un plan de retrait daté.

3. Construire groupe, vue et liste d’accès selon le moindre privilège

Créer le groupe

Sous Groups, cliquez sur Add, entrez un Group name de 1 à 30 caractères tel que monitor_ro, sélectionnez uniquement l’utilisateur prévu dans v3, enregistrez avec Add, puis ouvrez le groupe pour vérifier l’appartenance. Les mêmes caractères sont interdits. Si le privilège ne convient pas au Security mode, ou si l’utilisateur appartient déjà à un groupe équivalent, Fusion crée le groupe sans cet utilisateur : l’existence du groupe ne suffit donc pas.

Limiter la vue OID

Sous Views, cliquez sur Add, saisissez un View name de 1 à 20 caractères tel que monitoring, puis Add new mapping. Renseignez une branche nécessaire dans Subtree OID, un entier de 1 à 20 dans Subtree mask, et Included ou Excluded dans View type. Le masque indique le niveau de l’arbre MIB auquel il s’applique. Ajoutez les correspondances avec Add new mapping, puis cliquez sur Save. Préférez des branches Included explicites ; pour une entrée Excluded, Sophos recommande une inclusion chevauchante. N’ouvrez pas tout l’arbre par précaution.

Affecter la liste d’accès

Une Access list nécessite au moins un groupe. Sous Access lists, cliquez sur Add, choisissez le groupe, contrôlez Security mode, définissez Privilege mode v3 sur Privilege et affectez la vue comme Read view. Pour une simple supervision, n’affectez aucune Write view. N’utilisez Notify view que pour les notifications prévues, puis Save et vérifiez la ligne. Read view, Write view et Notify view contrôlent séparément les OID de lecture, d’écriture et de notification. Si le firmware impose une sélection d’écriture, clarifiez le comportement sur un pilote au lieu de choisir une vue large.

4. Importer les MIB du modèle

Ouvrez My Environment > Installers, puis sous Switches, cliquez sur Download SNMP MIB files. Conservez et extrayez l’archive de façon sûre, importez les fichiers du modèle utilisé dans le gestionnaire et contrôlez les OID avec cette version. L’archive contient les MIB de tous les modèles Sophos Switch. Une MIB référence les informations structurées de l’équipement et chaque OID identifie une variable que SNMP peut lire ou définir. L’existence d’une OID dans la MIB ne garantit ni son autorisation par la Read view, ni sa disponibilité sur tous les modèles.

5. Configurer et tester l’interrogation

L’intervalle est défini par le gestionnaire, pas par cette page. Configurez l’IP de gestion correcte, SNMPv3, l’utilisateur, Privilege, SHA avec Authentication Password et AES_CFB128 avec Encryption Password. Interrogez une OID autorisée et vérifiez une valeur plausible ; rapprochez nom, IP et modèle de l’inventaire ; vérifiez qu’une OID volontairement interdite ne renvoie rien ; observez plusieurs cycles ; confirmez l’absence de Write view sans modifier d’OID de production ; puis rapprochez SNMP status, utilisateur, groupe, Read view et Configuration source du plan. Si un test d’écriture est nécessaire, effectuez-le uniquement dans un laboratoire autorisé.

Un seul succès ne valide pas tous les capteurs. Un délai d’attente ne prouve pas un défaut d’identifiants : isolez d’abord routage, filtres, IP, port, version et profil du gestionnaire.

6. Configurer traps ou informs uniquement si nécessaire

Target parameters définit version, sécurité, privilège et utilisateur ; Notifications définit type et tag ; Target address définit récepteur, port UDP, tag et paramètres. Les Traps sont unidirectionnels : ni la réception ni la livraison ne sont acquittées ni garanties. Les Informs, disponibles en SNMPv2c/v3, demandent un acquittement et sont plus fiables, mais consomment davantage de ressources. Cet acquittement n’ajoute ni authentification ni chiffrement : un inform SNMPv2c reste protégé uniquement par sa Community String et circule en clair. Pour un nouveau déploiement SNMPv3, préférez Informs si le récepteur les prend en charge et si un acquittement opérationnel est requis ; sinon, traitez les Traps comme un canal explicitement non acquitté.

Target parameters

Sous Notifications > Target parameters, cliquez sur Add. Donnez un Name de 1 à 30 caractères (notify_v3), réglez Message processing model et Security mode sur v3, Privilege mode sur Privilege, choisissez le User, puis Save.

Notification

Sous Notifications > Notifications, cliquez sur Add. Saisissez un Notify name de 1 à 32 caractères (ops_inform) et un Tag identifier de 1 à 20 caractères (ops_nms), choisissez Traps ou Informs sous Notify type, puis Save.

Target address

Sous Notifications > Target address, cliquez sur Add une fois un Target Parameter créé. Saisissez un Target address name de 1 à 32 caractères, l’IP address du récepteur (192.0.2.60) et son UDP port exact. Pour Informs, définissez Timeout et Retry. Réutilisez exactement le Tag identifier ops_nms, choisissez Target parameter, puis Save. Les noms excluent espaces et ", \, %, &, ?, ', !, ;, |, +.

Aucun choix d’événement ni bouton Send test n’est documenté. Déclenchez un événement connu et sans risque pendant la maintenance et décodez le message avec la MIB. Sinon, notez que le chemin de bout en bout attend le premier événement réel.

Validation de bout en bout

Validez séparément : SNMP status: On et Configuration source correcte ; appartenance v3, Privilege, Read view, absence d’écriture et éventuelle Notify view ; lectures répétées d’une OID autorisée et refus d’une interdite ; chemins réseau limités ; message reçu avec expéditeur, contexte v3, heure et champs décodés ; acquittement des Informs sans répétitions inexpliquées, ou absence explicitement reconnue de preuve de livraison pour les Traps ; responsable des identifiants, date de rotation, liste OID/capteurs, récepteur et retour arrière documentés sans secrets.

Une tâche Fusion en attente ou en échec signifie que le réglage n’est pas effectif. Voir Exploiter les flottes, sites et stacks Sophos Switch pour Configuration source et Task queue.

Dépanner par symptôme

Aucune interrogation possible

Contrôlez SNMP status, cible, Configuration source, routage, filtres, version, utilisateur, Privilege, algorithmes, secrets issus du coffre sans les exposer, appartenance et liste d’accès ; retestez une OID autorisée. N’ouvrez pas tous les réseaux sources.

Les OID autorisées ne renvoient rien

Comparez Subtree OID, Subtree mask, Included/Excluded et Read view avec la MIB du modèle. N’ouvrez pas tout l’arbre.

SNMPv3 échoue après un changement d’Engine ID

La modification de l’Engine ID supprime les utilisateurs locaux. Recréez utilisateurs et dépendances, puis réinitialisez et redécouvrez dans le gestionnaire l’Engine ID et l’état USM. Si le produit ne sait pas les actualiser, recréez l’équipement ou le capteur. Ne changez pas encore l’ID à titre d’essai.

Le groupe existe, mais l’utilisateur manque

Le privilège ne satisfait pas Security mode, ou l’utilisateur appartient déjà à un groupe équivalent. Corrigez puis vérifiez l’appartenance réelle.

Impossible de créer l’Access List

Créez d’abord au moins un utilisateur et un groupe, puis affectez les vues pour chaque version active.

Aucune notification reçue

Vérifiez la liaison entre Target parameters, Notifications et Target address, le même Tag identifier, l’IP, le vrai UDP port, le chemin réseau, puis Privilege mode, utilisateur, SHA/AES et Notify view. Pour Informs, vérifiez acquittement, Timeout et Retry ; pour Traps, aucun acquittement n’existe. Confirmez qu’un événement s’est produit.

Informs n’est pas disponible

Il requiert SNMPv2c ou SNMPv3. Utilisez v3 dans Target Parameters et gardez version et sécurité cohérentes.

Le gestionnaire v1/v2c ne reçoit aucune réponse

Contrôlez Community et Transport tag, qui doit correspondre au Tag identifier sous Notifications > Target address. N’élargissez pas durablement l’accès en clair.

Faire tourner les identifiants sans interruption

Ne changez pas l’Engine ID. Créez un nouvel utilisateur SNMPv3 distinct avec Privilege, SHA, AES_CFB128 et de nouveaux secrets ; ajoutez-le au groupe et vérifiez ; testez une OID autorisée et une interdite ; basculez le Target parameter et retestez les notifications ; migrez tous les jobs après validation ; retirez l’ancien utilisateur des groupes et mappings ; supprimez-le avec Delete sous Users & Communities ; actualisez coffre, documentation et prochaine date de rotation. Tant que l’ancien existe, le retour arrière consiste à repointer gestionnaire et Target Parameter vers lui. Attendez la fin de la période d’observation avant de le supprimer.

Retour arrière et exploitation courante

Documentez sans secrets les valeurs, Configuration source, relations et profil du gestionnaire. Revenez en ordre inverse : arrêtez ou restaurez jobs et réception ; supprimez Target address, puis Notifications et Target parameters inutilisés ; retirez Access lists, Views, Groups et Users & Communities nouveaux s’ils ne servent plus. Pour arrêter SNMP, choisissez SNMP status: Off puis Update. Pour réappliquer une configuration locale connue, choisissez Not set puis Update. Vérifiez que l’ancien utilisateur ne peut plus interroger et que la destination supprimée ne reçoit plus rien.

Ne modifiez jamais l’Engine ID pendant le retour arrière. Not set n’est sûr que si l’état local est connu. Contrôlez régulièrement Subscription, firmware, Configuration source, utilisateurs, groupes, vues minimales, IP du gestionnaire, port du récepteur et version MIB. Après changement de gestionnaire, rotation, remplacement du switch, firmware ou vues OID, répétez tests positif, négatif et notifications.