Sophos Firewall si riavvia inaspettatamente: verificare la causa

Se Sophos Firewall si riavvia senza un intervento pianificato, non eseguire immediatamente un altro reboot né riavviare servizi per precauzione. Occorre prima stabilire se si è effettivamente riavviata l’intera appliance oppure se si sono interrotti solo WebAdmin, un singolo servizio o il ruolo HA attivo. Un riavvio riuscito può ripristinare l’operatività, ma non spiega ancora la causa.

⚠️ Salvare le prove prima di ulteriori interventi: non eliminare log, non provocare un altro reboot, non modificare lo stato di auto-reboot-on-hang e non avviare sulla base di un sospetto debug, azioni sui servizi, fsck, Factory Reset o Reimage. Questi interventi possono modificare gli indizi, causare nuove interruzioni o nascondere il guasto effettivo.

La procedura rapida e sicura è:

Annotare ora con fuso orario, durata del guasto e ultima osservazione nota in cui il sistema funzionava.
Registrare se traffico, WebAdmin, SSH e console locale sono stati interessati contemporaneamente.
Nel Control Center, salvare uptime, servizi, interfacce, VPN e, in caso di HA, stato del cluster.
In Log viewer > System, esportare gli eventi rilevanti e salvare l’andamento in Diagnostics > System graphs.
In Diagnostics > Tools, scaricare un CTR, sysinit.log, syslog.log e, in caso di HA, i log locali dei nodi.
Nella Device Console, leggere uptime, build e stato del riavvio automatico:

system diagnostics show uptime
system diagnostics show version-info
system auto-reboot-on-hang show

In caso di HA, confrontare ruoli, stato, Last status change e uptime di entrambi i nodi.
Solo successivamente verificare il ramo di cause pertinente e testare completamente l’operatività di produzione.

system auto-reboot-on-hang show non modifica nulla. SFOS attiva questa funzione per impostazione predefinita e può riavviare automaticamente il firewall se il kernel non risponde più. Un enable visualizzato dimostra tuttavia solo la recovery policy configurata, non che un kernel hang abbia causato questo specifico riavvio.

Verificare cosa si è effettivamente interrotto

L’interruzione osservata non dimostra ancora un reboot completo. Questi quattro casi richiedono passaggi successivi diversi:

Reboot completo dell’appliance: l’uptime riparte, più servizi e connessioni sono stati interrotti contemporaneamente e SFOS ha eseguito nuovamente l’avvio del sistema. A questo punto si applica il triage del reboot descritto in questo articolo.
È stato interessato solo WebAdmin o un servizio: l’uptime continua e parte del traffico di produzione può funzionare senza variazioni. In questo caso, un riavvio mirato della GUI WebAdmin o la verifica di un singolo servizio è più appropriato di un reboot dell’appliance.
Failover HA: gli utenti possono notare una breve interruzione anche se sono cambiati solo i ruoli. Uptime, ruolo e log di ogni nodo mostrano se un dispositivo si è effettivamente riavviato. La verifica HA segue più avanti.
Modalità failsafe: il firewall non si avvia normalmente e visualizza uno stato di ripristino sulla console. In questo caso, show failure-reason dal runbook sulla modalità failsafe di Sophos Firewall è il primo comando corretto.

L’uptime è quindi una prova importante del periodo del riavvio, ma non della causa. Viene azzerato anche da una breve interruzione di corrente, un kernel hang, un errore del firmware e un riavvio pianificato dall’amministratore.

Salvare le prove dopo il riavvio

Dopo un reboot non pianificato, alcuni dati volatili potrebbero già mancare. È comunque necessario salvare completamente lo stato raggiungibile prima di apportare ulteriori modifiche.

L’incidente deve includere almeno:

modello, numero di serie e piattaforma: hardware, VM o cloud
versione SFOS completa con MR e build
ora esatta, fuso orario, durata e frequenza del guasto
funzioni interessate: traffico, WebAdmin, SSH, console, VPN e servizi pubblicati
ultima modifica a firmware, configurazione, hypervisor, storage o alimentazione
uptime attuale e stato di servizi, interfacce, VPN e HA
in caso di HA: nodo interessato, ruoli prima e dopo l’evento e stato del peer
eventi UPS, PDU, hypervisor, cloud, switch e monitoraggio disponibili nella stessa finestra temporale

In Diagnostics > System graphs, controllare CPU, Memory, Load e Disk nell’intervallo dell’ora presunta. Un’anomalia può circoscrivere la ricerca. Un valore attuale normale non dimostra invece che anche il carico prima del reboot fosse normale.

In Log viewer > System, filtrare ed esportare gli eventi di avvio, restart, shutdown e HA nella stessa finestra temporale. Log Viewer è un’utile fonte temporale, ma non una prova completa di un crash. Gli eventi non ancora salvati possono mancare dopo un hang.

Leggere lo stato del sistema nella Device Console

Oltre a uptime e build, questi comandi di sola lettura mostrano lo stato attuale:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk

I valori devono essere inseriti nella nota dell’incidente insieme all’ora della query. Descrivono lo stato dopo il riavvio e non devono essere interpretati retrospettivamente come causa.

Controllare i log di avvio e di sistema

Nella Advanced Shell, i file più importanti possono essere letti completamente e senza modifiche:

cd /log
less sysinit.log
less syslog.log
less applog.log
less csc.log

q chiude less. All’interno del file, /termine-di-ricerca avvia una ricerca, per esempio /error; n passa al risultato successivo.

sysinit.log documenta l’avvio del sistema.
syslog.log contiene eventi del kernel e di sistema.
applog.log e csc.log aiutano a classificare azioni interne e modifiche vicine all’evento.

In Diagnostics > Tools > Troubleshooting logs, scaricare anche gli stessi file per conservare i dati originali al di fuori dell’appliance. La mappatura dei log dei servizi Sophos Firewall spiega quale file di log aggiuntivo appartiene a un servizio.

Inoltre, in Diagnostics > Tools > Consolidated troubleshooting report, generare un CTR con System snapshot e All log files. Il CTR contiene lo stato attuale del sistema e molti log in un archivio cifrato. Per impostazione predefinita, i log dei sottosistemi dei servizi contengono al massimo 10'000 righe; per periodi più lunghi restano importanti i singoli log completi. La procedura completa è descritta in Salvare i log di Sophos Firewall per il supporto.

Una sezione di log vuota non esclude un crash o un’interruzione di corrente. Le informazioni non ancora scritte sul disco possono andare perse durante un hang e i log locali possono ruotare. Per questo sono importanti fonti temporali esterne e una cronologia precisa dell’incidente.

Distinguere un failover HA da un reboot del nodo

In System services > High availability, salvare Health, Mode, ruoli, stato, numeri di serie e Last status change. Nella Device Console eseguire inoltre:

system ha show details

Successivamente, verificare l’uptime su entrambi i nodi. Se solo un nodo ha un uptime breve, ciò indica un riavvio di quel dispositivo. Se gli uptime sono invariati ma i ruoli sono cambiati, occorre prima esaminare il trigger HA, come una Monitored Port o un problema del peer. Anche un cambio manuale del ruolo attivo può riavviare il Primary precedente; per questo, anche un possibile intervento dell’amministratore deve essere incluso nella cronologia.

I log HA sono archiviati localmente sul rispettivo nodo e non vengono sincronizzati. Su entrambe le appliance sono quindi rilevanti almeno questi file:

cd /log
less ha.log
less msync.log

ha.log mostra la formazione del cluster e i cambiamenti di stato, mentre msync.log mostra la sincronizzazione. Non avviare un riavvio simultaneo di entrambi i nodi e non forzare un altro failover per riprodurre il problema. La diagnosi completa di ruoli e link è descritta in High Availability di Sophos Firewall.

Circoscrivere la causa in base al contesto

Riavvio pianificato dall’amministratore o dal firmware

Confrontare prima il calendario delle modifiche, le finestre di manutenzione, le azioni degli amministratori, i task Sophos Central e le notifiche con l’ora dell’evento. Le modifiche di configurazione precedenti possono essere classificate tramite gli Audit Trail log. Sophos Firewall genera eventi di sistema per un avvio e per restart o shutdown tramite WebAdmin. Se le notifiche e-mail sono configurate, il messaggio nella casella di posta può inoltre confermare l’ora e il firewall mittente.

Se il riavvio si è verificato durante un processo firmware o hotfix, salvare versione di origine, versione di destinazione, build, ora dell’aggiornamento e fwmgmt.log. Un riavvio fa parte di un normale cambio di firmware; più reboot non pianificati o un build inatteso non ne fanno parte. Per proseguire con la classificazione, utilizzare la procedura Eseguire un aggiornamento firmware di Sophos Firewall.

Kernel hang o errore software

Con auto-reboot-on-hang attivo, SFOS può riavviarsi automaticamente quando il kernel non risponde più. La funzione migliora la disponibilità, ma non lascia sempre una prova locale inequivocabile della causa. Documentare lo stato visualizzato e non modificarlo durante il triage. Circoscrivere il caso in base a ora, log, System graphs, CTR e build esatto.

In SFOS 22.0 MR2 Build 546, Sophos ha corretto diversi casi indipendenti di crash e restart, tra cui:

NC-180974: kernel crash in sdwan_profile con failover HA
NC-178354: kernel crash durante il matching delle regole SD-WAN
NC-178745: riavvio automatico di un dispositivo HA a causa di out-of-memory
NC-180433: crash ripetuto con traffico multicast attraverso un tunnel VPN

Questi issue ID mostrano perché Il firewall si è riavviato non rappresenta ancora una diagnosi. Il percorso di aggiornamento supportato a MR2 Build 546 o a una versione approvata più recente viene verificato solo se build, funzione, traffico e ora dell’errore corrispondono al caso documentato. Se l’errore si ripresenta su questo build o su uno più recente, non deve continuare a essere assegnato automaticamente allo stesso vecchio issue ID. Le altre correzioni sono classificate nella panoramica di SFOS 22.0 MR2.

Non riprodurre intenzionalmente un kernel crash mediante test di carico, multicast, modifiche SD-WAN o un failover forzato. Documentare configurazione e pattern di traffico e valutarli successivamente con Sophos Support.

Carico, spazio o storage

L’andamento di CPU, Memory, Load e Disk può mostrare se prima del reboot era già presente un’anomalia persistente. Sophos indica inoltre /log/system-monitor/cpu_trigger.log per gli stati del sistema acquisiti automaticamente in caso di carico CPU elevato. La documentazione di SFOS 22 aggiunge /log/system-monitor/memory_trigger.log per un carico elevato della memoria; non si deve presumere la presenza di questo file su SFOS 21.5.

Un disco pieno, un carico I/O elevato e un guasto dell’SSD sono problemi diversi. Non eliminare quindi report o log sulla base di un sospetto. Per la verifica in sola lettura e la pulizia prevista utilizzare Controllare spazio e report di Sophos Firewall; Controllare lo stato dell’SSD di Sophos Firewall tramite SMART descrive lo stato hardware del dispositivo di archiviazione.

Alimentazione, temperatura o hardware

Su una XGS fisica, controllare alimentazione, alimentatori, UPS/PDU, temperatura del rack, flusso d’aria, ventole, LED, SSD e console locale. L’assenza di una traccia di shutdown regolare può essere compatibile con un evento elettrico improvviso, ma non lo dimostra. È determinante la cronologia congiunta di firewall, UPS/PDU, monitoraggio e ambiente.

Anche una temperatura attuale dopo il reboot è solo un valore istantaneo. Il controllo di temperatura, ventole e xgs-healthmond.log descrive il ramo delle cause termiche. Gli errori ricorrenti di avvio, I/O, alimentatore, NPU o ventola devono essere inclusi con i dati salvati nella preparazione di un caso hardware e RMA.

Firewall virtuale o cloud appliance

Per una VM, controllare inoltre nello stesso momento gli eventi dell’hypervisor, i riavvii dell’host, la latenza del datastore, i task di snapshot o backup, vCPU, RAM, dischi e vNIC. Per AWS o Azure, gli eventi della piattaforma, lo stato dell’istanza e gli interventi di manutenzione pianificati fanno parte della cronologia dell’incidente.

Un evento dell’host o della piattaforma può riavviare la VM senza che SFOS stesso ne sia la causa. Al contrario, un hypervisor senza anomalie non dimostra che il guest sia privo di errori. Occorre quindi valutare insieme entrambe le cronologie. Sophos Firewall come hardware, VM o cloud appliance spiega le attuali differenze tra piattaforme e risorse.

Controllare l’operatività dopo il riavvio

Una pagina di accesso raggiungibile non costituisce ancora un test di accettazione completo. Dopo aver salvato le prove, controllare in base all’ambiente:

Control Center senza nuovi avvisi relativi a servizi, interfacce, VPN o prestazioni; controllare inoltre System graphs e Notifications per rilevare anomalie di Memory e Disk
WAN, routing, DNS e accesso a Internet tramite il percorso previsto
importanti connessioni VPN Site-to-Site e Remote Access
pubblicazioni centrali DNAT, WAF o di server
DHCP, RED e Wireless, se il firewall fornisce questi servizi
in caso di HA: Health, ruoli, sincronizzazione e uptime di entrambi i nodi
nuovi errori di sistema, kernel o hardware dall’avvio

I flussi operativi reali più importanti devono essere testati deliberatamente e documentati con l’ora. Se l’uptime rimane stabile, ciò dimostra solo che non si è verificato un altro reboot. La causa originaria è considerata chiarita solo quando cronologia, log e osservazioni della piattaforma forniscono una spiegazione affidabile.

Preparare il caso di supporto e il rilevamento futuro

È opportuno aprire un ticket di supporto Sophos se il reboot rimane inspiegato, si ripete, ha causato un’interruzione HA o di una sede oppure sono presenti indicazioni relative a kernel, memoria, storage, NPU o hardware. Nel caso devono essere inclusi ora dell’incidente con fuso orario, piattaforma, build completo, uptime, funzioni interessate, ultime modifiche, ruoli HA, CTR, log pertinenti completi e cronologia esterna dell’alimentazione o dell’hypervisor.

Un monitoraggio preparato migliora le prove disponibili per l’incidente successivo:

Configurare le notifiche e-mail per System started, Restart/Shutdown e cambiamenti di stato HA.
Inviare gli eventi di sistema e HA a Syslog o SIEM affinché la cronologia sia conservata al di fuori del firewall.
Monitorare uptime e stato dell’hardware tramite monitoraggio SNMP.
Gestire gli allarmi UPS/PDU, hypervisor e cloud con lo stesso time server e un’assegnazione chiara alla sede.

In questo modo, al prossimo evento sarà più rapido stabilire se l’interruzione è stata causata da SFOS stesso, da un singolo nodo, dalla piattaforma o dall’ambiente elettrico e hardware.