Vai al contenuto
Avanet

Configurare in sicurezza il monitoraggio SNMP di Sophos Switch

La pagina SNMP di Sophos Fusion controlla due flussi distinti: un manager SNMP interroga lo switch e lo switch può inviare notifiche a un destinatario. Per le nuove integrazioni usare SNMPv3 con Privilege, SHA e AES_CFB128. Una Read view strettamente limitata è sufficiente per il monitoraggio; non assegnare diritti di scrittura.

Procedura rapida:

  1. Verificare raggiungibilità, licenza, ambito della modifica e OID necessarie.
  2. In Switches > [Switch, Stack or Site] > SNMP > Global settings, attivare SNMP senza cambiare Engine ID.
  3. In Users & Communities, creare un utente SNMPv3 con Privilege.
  4. In Groups, Views e Access lists, concedere solo la lettura necessaria.
  5. Importare le MIB del modello e provare il polling in positivo e in negativo.
  6. Solo se servono notifiche, configurare Target parameters, Notifications e Target address.
  7. Collaudare separatamente polling e ricezione delle notifiche.

SNMPv1/v2c usa il Community String come password e lo trasmette in chiaro. Lasciare disattivato Enable SNMP v1/v2c for this user, salvo un sistema legacy giustificato senza supporto SNMPv3.

Prerequisiti, ruoli e raggiungibilità

Ogni switch gestito centralmente richiede una Subscription Sophos Switch Support and Services valida per le modifiche via Fusion. Senza licenza continua a funzionare localmente, ma Fusion non può modificarlo. Vedere Licenze Sophos Fusion.

La configurazione è eseguita da un amministratore Sophos Fusion autorizzato sullo switch, stack o sito scelto; non è documentato un ruolo amministrativo SNMP dedicato. Il responsabile del monitoraggio fornisce i dati del manager, importa le MIB e prova polling e notifiche. Scambiare le credenziali tramite un canale segreto approvato, mai in ticket o screenshot.

Prima di salvare definire: oggetto e ambito effettivo; IP di gestione e IP del manager; routing e filtri in entrambi i sensi; porta UDP del destinatario; rami MIB e OID necessari; nome utente univoco e segreti distinti e robusti; necessità di soli polling oppure anche Traps o Informs.

Le Access lists limitano i diritti OID del gruppo, non sono ACL di rete e non filtrano gli IP sorgente. Limitare quindi la rete di gestione ai sistemi previsti e verificare la porta reale. Per siti o stack iniziare da uno switch pilota. Configuration source indica l’origine dell’impostazione: Not set usa la configurazione locale e non equivale necessariamente a Off.

Definire il modello di sicurezza SNMPv3

ModalitàEffetto
No authenticationnessuna autenticazione
Authenticationutente autenticato
Privilegeutente autenticato e messaggi cifrati

In produzione usare Privilege. Authentication protocol offre MD5 (HMAC-MD5) e SHA (HMAC-SHA-96); Encryption protocol offre DES_CBC e AES_CFB128. La combinazione più forte disponibile è SHA con AES_CFB128.

ScopoEsempio
Utente SNMPv3swmon_v3
Gruppomonitor_ro
Read Viewmonitoring
Target Parameternotify_v3
Notifica e tagops_inform e ops_nms
IP manager192.0.2.60 (rete di documentazione)

Adattare i nomi al proprio standard, generare casualmente i due segreti e conservarli separatamente. Scegliere le OID dalla MIB del modello installato e dal fabbisogno reale; non esiste una OID Sophos universale.

1. Impostare i parametri SNMP globali

Aprire Switches, scegliere switch, stack o sito e poi SNMP. In Global settings, impostare SNMP status su On, mantenere Default per Engine ID, salvare con Update e controllare Configuration source e stato effettivo. Una Engine ID manuale deve essere esadecimale e lunga 10–64 caratteri.

Clear azzera i valori inseriti nella vista; non ripristina automaticamente lo stato di produzione precedente.

2. Creare l’utente SNMPv3

L’elenco Users & Communities mostra Name, Protocols, Authentication e Configuration source. In Users & Communities, fare clic su Add. Inserire un Name di 4–20 caratteri, ad esempio swmon_v3; scegliere Privilege come Privilege mode, SHA come Authentication protocol, una nuova Authentication password di 8–32 caratteri, AES_CFB128 come Encryption protocol e una nuova Encryption password di 8–40 caratteri. Lasciare disattivato Enable SNMP v1/v2c for this user, fare clic su Add e verificare l’elenco.

Nome e password non possono contenere spazi né ", \, %, &, ?, ', !, ;, |, +. Se v1/v2c viene eccezionalmente attivato, Fusion ricava una Community dal Name. Il Transport tag deve corrispondere al Tag identifier in Notifications > Target address. Questa eccezione in chiaro deve avere una scadenza.

3. Creare gruppo, vista e access list con privilegi minimi

Creare il gruppo

In Groups, fare clic su Add, inserire un Group name di 1–30 caratteri come monitor_ro, selezionare solo l’utente previsto in v3, salvare con Add e aprire il gruppo per verificarne i membri. Valgono gli stessi caratteri vietati. Se manca il privilegio richiesto dal Security mode, o l’utente appartiene già a un gruppo equivalente, Fusion crea il gruppo senza l’utente: il solo nome del gruppo non prova il successo.

Limitare la vista OID

In Views, fare clic su Add, inserire un View name di 1–20 caratteri come monitoring, quindi Add new mapping. Indicare un ramo necessario in Subtree OID, un intero tra 1 e 20 in Subtree mask e Included o Excluded come View type. La maschera identifica il livello dell’albero MIB a cui si applica. Aggiungere le mappature con Add new mapping e fare clic su Save. Preferire rami Included espliciti; per una voce Excluded Sophos raccomanda un’inclusione sovrapposta. Non aprire l’intero albero per comodità futura.

Assegnare l’access list

Un’Access list richiede almeno un gruppo. In Access lists, fare clic su Add, scegliere il gruppo, controllare Security mode, impostare Privilege mode v3 su Privilege e assegnare la vista come Read view. Per il solo monitoraggio non assegnare una Write view; assegnare Notify view solo per notifiche pianificate. Salvare con Save e verificare. Read view, Write view e Notify view controllano separatamente le OID leggibili, scrivibili e di notifica. Se il firmware obbliga una vista di scrittura, chiarire il comportamento sul pilota invece di scegliere una vista ampia.

4. Importare le MIB del modello

Aprire My Environment > Installers e, in Switches, fare clic su Download SNMP MIB files. Conservare ed estrarre l’archivio in modo protetto, importare nel manager i file del modello usato e verificare le OID rispetto a quella versione. L’archivio contiene le MIB di tutti i modelli Sophos Switch. Una MIB è il riferimento per le informazioni strutturate del dispositivo e ogni OID identifica una variabile che SNMP può leggere o impostare. La presenza nella MIB non garantisce che l’OID sia consentita dalla Read view o valorizzata su ogni modello.

5. Configurare e verificare il polling

L’intervallo è pianificato dal manager, non dalla pagina SNMP. Configurare l’IP corretto, SNMPv3, utente, Privilege, SHA con Authentication Password e AES_CFB128 con Encryption Password. Interrogare una OID autorizzata e ottenere un valore plausibile; confrontare nome, IP e modello con l’inventario; verificare che una OID volutamente negata non restituisca dati; osservare più cicli; confermare l’assenza di Write view senza modificare OID di produzione; confrontare SNMP status, utenti, gruppo, Read view e Configuration source con il piano. Eseguire un eventuale test di scrittura solo in un laboratorio autorizzato.

Un singolo polling riuscito non valida tutti i sensori. Un timeout non prova un errore di credenziali: isolare prima routing, filtri, IP, porta, versione e profilo manager.

6. Configurare trap o inform solo se necessari

Target parameters definisce versione, sicurezza, privilegio e utente; Notifications definisce tipo e tag; Target address definisce destinatario, porta UDP, tag e parametri. I Traps sono unidirezionali: ricezione e consegna non sono né confermate né garantite. Gli Informs, disponibili solo con SNMPv2c/v3, chiedono conferma e sono più affidabili ma consumano più risorse. La conferma non aggiunge autenticazione o cifratura: un inform SNMPv2c resta protetto solo dalla Community String e viaggia in chiaro. Per una nuova implementazione SNMPv3, usare Informs se il destinatario li supporta e serve una conferma operativa; altrimenti trattare i Traps come un canale esplicitamente non confermato.

Target parameters

In Notifications > Target parameters, fare clic su Add. Inserire un Name di 1–30 caratteri (notify_v3), impostare Message processing model e Security mode su v3, Privilege mode su Privilege, scegliere User e Save.

Notification

In Notifications > Notifications, fare clic su Add. Inserire un Notify name di 1–32 caratteri (ops_inform) e un Tag identifier di 1–20 (ops_nms), scegliere Traps o Informs in Notify type e Save.

Target address

Dopo aver creato un Target Parameter, in Notifications > Target address fare clic su Add. Inserire un Target address name di 1–32 caratteri, l’IP address del destinatario (192.0.2.60) e la sua esatta UDP port. Per Informs impostare Timeout e Retry. Usare lo stesso Tag identifier ops_nms, scegliere Target parameter e Save. I nomi escludono spazi e ", \, %, &, ?, ', !, ;, |, +.

La pagina non documenta né selezione eventi né un pulsante Send test. Generare durante la manutenzione un evento noto e innocuo e decodificare il messaggio con la MIB. Se non è possibile, documentare che il percorso end-to-end resta da confermare al primo evento reale.

Collaudo end-to-end

Verificare separatamente: SNMP status: On e Configuration source corretta; appartenenza v3, Privilege, Read view, nessun diritto di scrittura ed eventuale Notify view; lettura ripetuta di una OID consentita e diniego di una vietata; percorsi di rete limitati; messaggio con mittente, contesto v3, orario e campi decodificati; conferma degli Informs senza retry inspiegabili oppure assenza esplicita di garanzia per i Traps; titolare delle credenziali, data rotazione, lista OID/sensori, destinatario e rollback documentati senza segreti.

Un task Fusion in attesa o fallito significa che l’impostazione non è effettiva. Vedere Gestire flotte, siti e stack Sophos Switch per Configuration source e Task queue.

Risolvere i problemi per sintomo

Polling impossibile

Controllare SNMP status, destinazione, Configuration source, routing, filtri, versione, utente, Privilege, algoritmi, segreti prelevati dal vault senza esporli, membri del gruppo e access list; riprovare una OID sicuramente consentita. Non aprire reti sorgente arbitrarie.

Le OID consentite non restituiscono dati

Confrontare Subtree OID, Subtree mask, Included/Excluded e Read view con la MIB del modello. Non aprire l’intero albero.

SNMPv3 smette di funzionare dopo una modifica dell’Engine ID

La modifica dell’Engine ID elimina gli utenti locali. Ricreare utenti e dipendenze, quindi azzerare e riscoprire nel manager Engine ID e stato USM. Se il prodotto non può aggiornarli, ricreare dispositivo o sensore con ID e credenziali correnti. Non cambiare di nuovo l’ID per prova.

Il gruppo esiste, ma manca l’utente

L’utente non ha il privilegio richiesto dal Security mode o è già in un gruppo equivalente. Correggere e verificare i membri effettivi.

Impossibile creare l’Access List

Creare prima almeno un utente e un gruppo, poi assegnare le viste per ogni versione attiva.

Il destinatario non riceve notifiche

Verificare collegamento tra Target parameters, Notifications e Target address, identico Tag identifier, IP, reale UDP port, percorso di rete, quindi Privilege mode, utente, SHA/AES e Notify view. Per Informs controllare conferma, Timeout e Retry; i Traps non hanno conferma. Verificare che sia avvenuto un evento.

Informs non è selezionabile

Richiede SNMPv2c o SNMPv3. Usare v3 nei Target Parameters e mantenere coerenti versione e sicurezza.

Il manager legacy v1/v2c non riceve risposta

Controllare Community e Transport tag, che deve corrispondere al Tag identifier in Notifications > Target address. Non ampliare stabilmente l’accesso in chiaro.

Ruotare le credenziali senza interruzione

Non cambiare Engine ID. Creare un nuovo utente SNMPv3 chiaramente distinto con Privilege, SHA, AES_CFB128 e nuovi segreti; aggiungerlo al gruppo e verificare; provare una OID consentita e una negata; aggiornare il Target parameter e riprovare le notifiche; migrare tutti i job solo dopo il collaudo; rimuovere il vecchio utente da gruppi e mapping; eliminarlo con Delete in Users & Communities; aggiornare vault, documentazione e prossima data. Finché esiste, il rollback consiste nel ripristinarlo nel manager e nel Target Parameter. Eliminarlo solo dopo la finestra di osservazione.

Rollback e gestione continua

Documentare senza segreti valori, Configuration source, relazioni e profilo manager. Procedere in ordine inverso: fermare o ripristinare job e ricezione; eliminare Target address, poi Notifications e Target parameters inutilizzati; rimuovere Access lists, Views, Groups e Users & Communities nuovi se inutilizzati. Per disattivare SNMP scegliere SNMP status: Off e Update. Per ripristinare consapevolmente una configurazione locale nota scegliere Not set e Update. Verificare che l’utente rimosso non possa interrogare e la destinazione non riceva più nulla.

Non modificare l’Engine ID nel rollback. Not set è sicuro solo se lo stato locale è noto. Riesaminare regolarmente Subscription, firmware, Configuration source, utenti, gruppi, viste minime, IP manager, porta destinatario e versione MIB. Ripetere test positivo, negativo e notifiche dopo cambio manager, rotazione, sostituzione switch, firmware o viste OID.