Vai al contenuto
Avanet

Configurare il monitoraggio hardware SNMP su Sophos Firewall

Sophos Firewall

Per configurare il monitoraggio hardware tramite SNMP, si abilita l’agente in Administration > SNMP, si crea preferibilmente un utente SNMPv3, si limita l’accesso all’host di monitoraggio in Administration > Device access e si scarica la MIB corrente. La connessione può quindi essere verificata dal sistema di monitoraggio con snmpget e l’albero hardware può essere interrogato con snmpwalk.

A partire da Sophos Firewall v22, la MIB fornisce anche temperatura di CPU e NPU, velocità delle ventole, stato degli alimentatori e valori PoE, a seconda del modello XGS. SNMP risponde quindi soprattutto a domande sullo stato. Per i singoli eventi di sicurezza sono più adatti Central Firewall Reporting o Syslog, mentre per i modelli di traffico è preferibile sFlow.

Se serve un controllo immediato direttamente sull’appliance anziché un monitoraggio continuo, controllare temperatura e ventola di Sophos Firewall via SSH spiega come leggere sensors e xgs-healthmond.log e interpretare correttamente gli apparenti allarmi dei sensori grezzi.

⚠️ SNMP dovrebbe essere raggiungibile solo da una rete di gestione o monitoraggio attendibile. Un accesso esteso dalle zone client, guest, IoT o WAN espone inutilmente informazioni su modello, interfacce e stato operativo.

Configurare SNMP in modo sicuro

Limitare l’accesso all’host di monitoraggio

Se deve accedere una zona di monitoraggio dedicata, si abilita SNMP in Administration > Device access solo per quella zona. Se invece esegue il polling un singolo server con indirizzo IP fisso, SNMP rimane disabilitato per la zona. Una Local service ACL exception rule autorizza invece in modo mirato l’origine, la destinazione firewall e il servizio SNMP. La configurazione completa è descritta in Proteggere Device Access su Sophos Firewall.

SNMP è un servizio locale del firewall. Una normale regola LAN-to-WAN non sostituisce Device Access. SNMP non dovrebbe essere esposto direttamente dalla WAN; per il monitoraggio esterno, una VPN di gestione è la connessione più sicura.

Abilitare l’agente

  1. Aprire Administration > SNMP.
  2. Abilitare Enable SNMP agent.
  3. Inserire nome, posizione e contatto, per esempio xgs-zrh-01, ZRH-DC1 / Rack 3 e noc@example.net.
  4. Salvare con Apply.
  5. Usare Download MIB per scaricare la MIB corrispondente alla versione del firewall e importarla nel sistema di monitoraggio.

Le query raggiungono l’agente tramite UDP 161. I trap vengono inviati al manager tramite UDP 162. Anche il routing e i firewall locali degli host tra i due sistemi devono consentire il traffico nella direzione necessaria.

Configurare SNMPv3

  1. In Administration > SNMP > SNMPv3 users and traps, fare clic su Add.
  2. Impostare un nome utente permanente, per esempio monitoring. Non può essere modificato in seguito.
  3. Abilitare Accept queries.
  4. Abilitare Send traps solo se il firewall deve anche inviare notifiche al manager.
  5. Per le nuove configurazioni, scegliere se possibile AES e SHA256 oppure SHA512. Entrambe le passphrase devono contenere almeno dodici caratteri.
  6. Salvare.

Secondo Sophos, Authorized hosts si applica solo alle destinazioni dei trap. L’elenco non limita le query SNMPv3. Per queste sono determinanti credenziali corrette, Accept queries e Device Access.

Usare SNMPv1 o SNMPv2c solo se necessario

Se il sistema di monitoraggio non supporta correttamente SNMPv3, si crea una community in Administration > SNMP > SNMPv1/v2c. Sono necessari nome, Community String, IPv4 o IPv6, indirizzo IP del manager e Accept queries. Send traps rimane disabilitato se non si usano trap.

La Community String funziona come una password, ma con v1/v2c viene trasmessa senza cifratura. Non deve comparire in screenshot o ticket e dovrebbe essere usata solo in una rete di gestione strettamente limitata.

Dopo un aggiornamento a SFOS 22, è opportuno controllare le community v1/v2c esistenti: il firewall copia il nome precedente come Community String e genera per gli oggetti migrati un nome con il prefisso snmp. In questa fase si possono rimuovere le varianti IPv4/IPv6 non necessarie e le origini di monitoraggio non più utilizzate.

Abilitare i trap in modo mirato

Per i trap, il solo utente SNMP o la sola community non sono sufficienti. In System services > Notification list devono essere abilitati SNMP traps e i tipi di avviso effettivamente necessari.

La ricezione dovrebbe essere verificata quando si verifica realmente uno degli eventi selezionati. Gli inform SNMPv3 prevedono una conferma; se il firewall non la riceve, secondo Sophos non tenta un nuovo invio. Trap e inform non sostituiscono quindi il controllo del polling.

Metriche hardware e limiti dei modelli

SFOS 22 fornisce i nuovi valori hardware per le appliance XGS:

  • CPU temperature: tutti i modelli XGS.
  • NPU temperature: tutti i modelli XGS tranne 88/88w, 108/108w, 118/118w e 128/128w.
  • Fan speed: tutti i modelli XGS tranne 88/88w e 108/108w.
  • Power supply status: XGS 2100 e modelli superiori.
  • PoE measurements: modelli XGS con PoE tranne XGS 116/116w.

Sophos documenta questi sensori per l’hardware XGS. Nelle appliance virtuali, cloud o software non ci si deve aspettare sensori fisici dell’host nella MIB SFOS. Anche su XGS, una metrica assente non indica automaticamente un errore; bisogna prima verificare i limiti del modello.

OID e unità della MIB SFOS 22

L’albero hardware inizia da .1.3.6.1.4.1.2604.5.1.9. Le aree principali sono:

  • Temperatura NPU: .1.3.6.1.4.1.2604.5.1.9.1.0
  • Temperatura CPU: .1.3.6.1.4.1.2604.5.1.9.2.0
  • Velocità della ventola: .1.3.6.1.4.1.2604.5.1.9.3.1.2
  • Stato dell’alimentatore: .1.3.6.1.4.1.2604.5.1.9.4.1.2
  • Tabella PoE: .1.3.6.1.4.1.2604.5.1.9.5

Le temperature vengono fornite in decimi di grado Celsius: 420 corrisponde a 42,0 °C. La velocità delle ventole è espressa in RPM. La potenza PoE è indicata in milliwatt, la tensione in millivolt e la corrente in milliampere. Per l’alimentatore, up(1) significa operativo e down(2) guasto.

Per ottenere valori hardware analizzabili come dati numerici, è necessario almeno SFOS 22.0 GA Build 411. Questa build corregge, tra gli altri, il problema NC-169564, per il quale i valori dei sensori venivano forniti come stringhe anziché come numeri interi, oltre ad altri problemi relativi a MIB e OID.

Dopo un aggiornamento del firmware, è opportuno scaricare nuovamente la MIB corrente, importarla nel sistema di monitoraggio e verificare la discovery. I template di monitoraggio non devono dipendere esclusivamente dai nomi visualizzati.

Verificare la connessione e i valori hardware

I seguenti comandi Bash vengono eseguiti su un host di monitoraggio Linux o macOS con Net-SNMP, non su Sophos Firewall. Su macOS, avviare prima bash, perché read -p ha un significato diverso nella shell zsh predefinita. Gli esempi sono stati verificati rispetto alla sintassi Net-SNMP documentata e alla MIB ufficiale di SFOS 22, ma non sono stati eseguiti su un firewall di un cliente.

SHA-256 e SHA-512 richiedono generalmente Net-SNMP 5.8 o versione successiva. Con snmpwalk -h si può verificare quali algoritmi accetta il client installato. Le versioni meno recenti di macOS supportano in parte solo MD5 e SHA.

⚠️ Net-SNMP passa Community String e passphrase come argomenti di processo. L’inserimento tramite read evita che vengano salvati nella cronologia della shell, ma non impedisce che siano visibili per breve tempo nell’elenco dei processi. Eseguire questi test solo su un host di monitoraggio attendibile.

Verificare SNMPv3 con AuthPriv

Adattare indirizzo IP e utente, inserire le passphrase e interrogare prima l’OID standard non invasivo sysUpTime.0:

FIREWALL_IP="192.0.2.1"
SNMP_USER="monitoring"

read -r -s -p "Password di autenticazione SNMPv3: " SNMP_AUTH
printf '\n'
read -r -s -p "Password di cifratura 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

Una prima query riuscita restituisce sysUpTime.0 come Timeticks. Il walk successivo mostra solo i sensori supportati dal modello specifico.

Verificare SNMPv2c per compatibilità

Per un manager v2c configurato consapevolmente:

FIREWALL_IP="192.0.2.1"

read -r -s -p "Community 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 di uptime riuscito dimostra la raggiungibilità e la correttezza delle credenziali, ma non ancora la plausibilità di tutti i valori dei sensori. Successivamente si confrontano nome host, modello, firmware, versione della MIB e valori con WebAdmin, appliance e funzionamento normale. Per gli allarmi relativi a temperatura e PoE, si crea prima una baseline su più giorni.

Allarmi e HA

Gli allarmi utili non segnalano solo un singolo valore misurato, ma un’anomalia operativa:

  • La raggiungibilità SNMP o un’interfaccia prevista viene meno.
  • La temperatura di CPU o NPU supera in modo persistente la propria baseline.
  • Una ventola presente segnala 0 RPM o nessun valore.
  • Un alimentatore ridondante passa a down(2).
  • Il consumo PoE si avvicina al budget.
  • Gli errori o i drop di un’interfaccia aumentano in modo anomalo.

Soglie di temperatura fisse e universali sarebbero fuorvianti. Il modello, il rack, la temperatura ambiente e il carico determinano l’intervallo normale. Un runbook per gli allarmi dovrebbe controllare prima valore misurato, andamento e limiti del modello, quindi valutare raffreddamento, alimentazione, cablaggio, porta dello switch o dispositivi PoE.

Gli allarmi dovrebbero distinguere almeno tra Avviso e Critico; per ogni livello, il runbook deve definire responsabile, primo controllo e percorso di escalation.

Quando il sospetto di un guasto hardware è confermato, si documentano modello, numero di serie, firmware, momento dell’evento e andamento. La procedura per garanzia e sostituzione è descritta in Guasto hardware Sophos: preparare RMA e sostituzione. Per i supporti di archiviazione, Verificare lo stato dell’SSD tramite SMART è più adatto di SNMP.

In un cluster HA, entrambe le appliance sono rilevanti. Una query al solo indirizzo del cluster non mostra necessariamente la ventola, l’alimentatore o la porta dell’appliance passiva. Se l’architettura di rete e la piattaforma consentono accessi di gestione separati, Primary e Auxiliary dovrebbero essere rilevati singolarmente. La raggiungibilità SNMP effettiva e l’associazione devono essere verificate dopo la configurazione HA e dopo un failover. I concetti di base sono descritti in Configurare High Availability su Sophos Firewall.

I valori SNMP non dovrebbero essere utilizzati come unica prova delle prestazioni. L’interpretazione di throughput e utilizzo è descritta in Interpretare correttamente i dati sulle prestazioni di Sophos Firewall.

Risoluzione dei problemi

Timeout o nessuna risposta

Controllare prima IP di monitoraggio, routing, Device Access, Local Service ACL, Accept queries, versione SNMP e credenziali. In WebAdmin, in Diagnostics > Packet capture, si può usare il filtro host 192.0.2.50 and port 161; la procedura è descritta in Packet Capture in WebAdmin.

In alternativa, nell’opzione 4 Device Console, verificare se la query raggiunge il firewall:

tcpdump 'host 192.0.2.50 and port 161'

Terminare il test con Ctrl+C. Se non arriva alcun pacchetto, la causa si trova a monte dell’agente SNMP. Se la richiesta arriva ma non viene restituita alcuna risposta, i controlli successivi riguardano Device Access, IP del manager, credenziali e configurazione dell’agente.

Autenticazione o algoritmo non riusciti

Nome utente, Security Level authPriv, algoritmo di autenticazione e algoritmo di cifratura devono corrispondere esattamente alla configurazione del firewall. Se il client non accetta SHA-256 o SHA-512, verificare con snmpwalk -h i metodi supportati e aggiornare Net-SNMP. Non ripiegare silenziosamente su MD5 o su SNMP non cifrato.

In caso di errore di una query, non concentrarsi su Authorized hosts: con SNMPv3, questo elenco si applica solo alle destinazioni dei trap.

Valori hardware assenti o non plausibili

Controllare limiti del modello, firmware e versione della MIB. In SFOS 22.0 GA Build 365, i valori hardware possono essere restituiti come stringhe anziché come numeri interi a causa di NC-169564; Build 411 corregge il problema. Dopo l’aggiornamento, aggiornare la MIB e ripetere la discovery del sistema di monitoraggio.

Gli ultimi messaggi possono essere letti nella Device Console:

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

snmpd.log appartiene all’agente SNMP. xgs-healthmond.log aiuta per temperatura della CPU e stato delle ventole. Ulteriori associazioni sono disponibili in Log dei servizi di Sophos Firewall.

I trap non arrivano

Controllare Send traps, Authorized hosts, UDP 162 e gli eventi selezionati in System services > Notification list. Nella Device Console, una cattura mirata mostra se il firewall invia dati al manager:

tcpdump 'host 192.0.2.50 and port 162'

Se i pacchetti lasciano il firewall ma non arrivano, controllare routing, firewall intermedi e ricevitore dei trap. Per gli inform SNMPv3, controllare anche la conferma del manager.