Sophos Firewall in modalità failsafe: verificare la causa

Quando un Sophos Firewall si avvia in modalità failsafe, SFOS ha rilevato un errore critico e non ha avviato il normale funzionamento. A seconda della causa, l’elaborazione dei pacchetti, le interfacce e l’accesso di gestione possono essere completamente o parzialmente indisponibili. Non si deve quindi dedurre da una porta di gestione ancora accessibile che il firewall continui a offrire una protezione affidabile.

Il primo passo più importante non è un Factory Reset o un reimage, ma il salvataggio della causa rilevata da SFOS:

1. Connettersi tramite la console locale, seriale o dell’hypervisor.
2. Aprire Device Console nel menu failsafe.
3. Eseguire il seguente comando di sola lettura:

show failure-reason

La console può quindi apparire, ad esempio, così:

failsafe> show failure-reason
Unable to apply Firewall Framework

failsafe> è solo il prompt e non deve essere inserito. Il messaggio esatto può essere diverso. È fondamentale fotografare o copiare l’output invariato e le prime righe visibili della console. Se SSH funziona ancora durante l’errore, è possibile raggiungere Device Console anche in questo modo; in caso di guasto, la console locale, seriale o dell’hypervisor rimane il metodo più robusto.

⚠️ Salvare le informazioni prima di riavviare: Un reboot può modificare o eliminare temporaneamente la situazione di errore visibile. Prima del riavvio, documentare almeno il messaggio di errore, la versione SFOS con il build, il ruolo dell’appliance e l’ora. Reset to Factory Defaults, Remove Firewall Rules e gli interventi manuali sul database o sul file system non sono misure diagnostiche e possono distruggere configurazioni o prove importanti.

Che cosa significa la modalità failsafe

Failsafe è uno stato di protezione e ripristino. SFOS lo attiva quando un componente necessario per il funzionamento sicuro del firewall non si avvia correttamente. I messaggi noti e i casi di errore reali riguardano, ad esempio, il database di configurazione, il framework del firewall, il set di regole, il servizio di logging o di rete, il database delle firme oppure, su un modello XGS dotato di tale unità, la Network Processing Unit (NPU). Questo non è un elenco completo delle procedure di riparazione; rimane determinante l’output specifico della console.

Il solo fatto che WebAdmin non sia raggiungibile non dimostra uno stato failsafe. Se il traffico continua a funzionare e solo l’interfaccia non risponde, eseguire prima la verifica mirata o il riavvio della GUI WebAdmin. Un vero stato failsafe viene identificato sulla console. La possibilità che un accesso di gestione o singole interfacce continuino a funzionare dipende dalla causa e non dimostra che il sistema sia integro.

Questa distinzione è importante: se è guasto un singolo servizio, può essere opportuno riavviarlo in modo mirato. In modalità failsafe, invece, manca un requisito critico per l’avvio. Riavviare più servizi sulla base di semplici ipotesi rischia quindi di nascondere la causa invece di risolverla.

Verificare la causa del failsafe con show failure-reason

show failure-reason deve essere eseguito in Device Console, non nell’Advanced Shell. Il comando non modifica la configurazione. Mostra la categoria di errore rilevata da SFOS durante l’avvio.

L’output è un punto di partenza e non una procedura di riparazione completa. I seguenti gruppi di messaggi aiutano a classificare il problema:

• Configuration database: Il firewall non è riuscito ad avviare correttamente il database di configurazione. Prima di qualsiasi riparazione manuale, salvare il messaggio di errore, il build, l’ultima modifica e il backup disponibile. Non eliminare né modificare i file del database.
• Firewall framework o firewall rules: SFOS non è riuscito ad applicare la base per l’elaborazione dei pacchetti o il set di regole. Sono rilevanti le ultime modifiche a regole, oggetti, restore o firmware. La rimozione indiscriminata di tutte le regole firewall causerebbe una perdita di dati e non costituirebbe una corretta diagnosi iniziale.
• Logging daemon: Un servizio di logging critico non si è avviato. Oltre al messaggio di errore, controllare lo stato dello storage, il build e i log. Non svuotare alla cieca report o log prima di avere salvato i dati necessari.
• Network daemon: I componenti di rete non sono riusciti ad avviarsi correttamente. Per le appliance virtuali, includere nella verifica le vNIC presenti, l’ordine degli adattatori e le modifiche all’hypervisor.
• Signature database: Non è stato possibile caricare un database delle firme necessario. Sono rilevanti lo stato dei pattern, lo storage e la relazione temporale con gli aggiornamenti; non eliminare manualmente i file delle firme.
• NPU: Su un modello XGS dotato di NPU, la prima riga della console può già indicare Network processing unit error. Anche se show failure-reason non fornisce poi un output utile, salvare l’intera console e preparare un caso di supporto o hardware.

La formulazione esatta di un messaggio può variare a seconda della versione SFOS. Per il supporto, l’output invariato è quindi più utile di un riepilogo redatto manualmente come Il firewall non si avvia.

Verificare la piattaforma e l’ultima modifica

Il passaggio successivo dipende dal fatto che sia interessato l’hardware, un’appliance virtuale o software oppure un cluster HA. Lo stesso messaggio di errore non deve portare automaticamente alla stessa misura.

Firewall virtuale e appliance software

Un firewall virtuale può passare alla modalità failsafe semplicemente a causa di risorse non idonee. Per le appliance SFOS 22 eseguite localmente su VMware, Hyper-V, KVM e Citrix, Sophos indica attualmente almeno:

• 1 vCPU
• 4 GB vRAM
• 2 vNICs
• 32 GB Primary Disk
• 80 GB Report Disk

Inoltre, le vCPU e la vRAM configurate non devono superare la licenza acquistata. I valori minimi sono solo limiti tecnici di avvio e non rappresentano un dimensionamento di produzione per IPS, TLS Inspection o throughput elevato.

L’Auxiliary Disk inclusa nelle immagini VM è questa Report Disk separata. Non è opzionale e non sostituisce la Primary Disk. Per AWS e Azure si applicano invece i tipi di istanza cloud supportati e le dimensioni specifiche della piattaforma.

Nell’hypervisor, verificare che entrambi i dischi e tutte le vNIC previste siano ancora presenti, connessi e assegnati nell’ordine atteso. Anche qualsiasi modifica successiva a CPU, RAM, controller del disco o rete virtuale deve essere inclusa nella cronologia dell’incidente. Le differenze tra le piattaforme e i requisiti delle risorse sono trattati più dettagliatamente in un articolo dedicato.

Per un’appliance software SFOS 22, i requisiti relativi all’architettura x86-64, a Legacy BIOS, ad almeno 4 GB di RAM e a due schede di rete non sono in discussione. Per il disco, tuttavia, due pagine Sophos attuali si contraddicono: la panoramica generale delle piattaforme indica un minimo di 10 GB, mentre la pagina specifica più recente relativa all’appliance software indica un minimo di 32 GB e ne consiglia 64 GB. Non esiste quindi un limite Sophos pubblicato in modo uniforme. Per le nuove installazioni, Avanet raccomanda in modo conservativo almeno 32 GB e, se possibile, 64 GB; in questo modo si segue la pagina di prodotto più specifica e si evita un sistema con spazio insufficiente già all’avvio.

Non modificare ripetutamente e arbitrariamente le risorse durante un tentativo di ripristino dalla causa incerta. Documentare prima lo stato attuale, quindi eseguire una correzione pianificata con un test di avvio definito.

Appliance hardware e NPU

Su un XGS fisico, considerare anche gli eventi di alimentazione, la temperatura, le ventole, gli errori SSD o I/O e i primi messaggi di avvio. Un errore NPU su un modello XGS dotato di questa unità non giustifica il tentativo di comandi di reset o di servizio non documentati. Se il messaggio si ripete o la diagnostica stessa non riesce, il passaggio successivo corretto è un caso di supporto con una possibile preparazione della RMA.

Un singolo riavvio riuscito non dimostra che un problema hardware sia stato risolto. In caso di guasti ripetuti, sono utili anche le verifiche disponibili per temperatura e ventole e per lo stato dell’SSD.

Failsafe in un cluster HA

Per HA, determinare innanzitutto quale Node è interessato e se il peer elabora stabilmente il traffico di produzione. Documentare Primary o Auxiliary, lo stato del cluster, l’ultimo cambio di ruolo e lo stesso orario su entrambe le appliance.

Non riavviare entrambi i Nodes contemporaneamente e non disattivare HA sulla base di semplici ipotesi. Una modifica non coordinata può mettere a rischio il percorso ancora funzionante, cambiare la situazione dei ruoli o imporre una ricostruzione. Configurare High Availability su Sophos Firewall spiega i ruoli, la sincronizzazione e i log specifici del Node; la causa concreta del failsafe deve comunque essere salvata sul Node interessato.

Dopo un aggiornamento del firmware o un restore

Se la modalità failsafe si presenta subito dopo un upgrade, un rollback o un restore, registrare la versione di origine, la versione di destinazione e il numero di build completo. In SFOS 22, Sophos ha corretto con MR2 Build 546 diverse cause specifiche di failsafe, tra cui errori dopo l’upgrade a GA, un logging daemon che non si avviava, una partizione di configurazione piena e determinati oggetti di servizio difettosi. La panoramica di SFOS 22 MR2 elenca gli Issue ID risolti.

Ciò non significa che ogni evento failsafe venga risolto con un aggiornamento. Verificare innanzitutto se il messaggio di errore e il build installato corrispondono effettivamente a un fix noto. Una modifica del firmware richiede comunque backup, finestra di manutenzione, piano HA e percorso di ritorno. A tale scopo sono disponibili la preparazione di un aggiornamento firmware e la verifica dell’upgrade a SFOS 22.

Failed to start Red server service

Se il firewall mostra esattamente questo messaggio in modalità failsafe, il quadro dell’errore corrisponde a NC-178906. Sophos ha corretto questo errore di failsafe in SFOS 22.0 MR2 Build 546. Su un build precedente, dopo aver salvato le prove si valuta un percorso controllato di ripristino e upgrade al build 546 o a una versione successiva. Se il messaggio si presenta con il build 546 o una versione successiva, l’Issue ID da solo non dimostra la causa; si apre un caso di supporto con i log salvati.

Prima di un riavvio o di una modifica del firmware, salvare il numero di build completo, l’ora del guasto, il Node HA interessato e le voci di sysinit.log, red.log e syslog.log relative al momento del guasto. Non eliminare sulla base di semplici ipotesi le interfacce RED, il pattern del firmware RED o la configurazione RED e non riavviare ripetutamente il servizio RED. Se il firewall si avvia normalmente e solo un tunnel RED rimane offline, utilizzare invece la risoluzione dei problemi RED.

Salvare le prove prima del ripristino o del riavvio

Per consentire un’analisi affidabile, se possibile raccogliere quanto segue prima della prima misura che modifica lo stato:

• output completo di show failure-reason e prime righe di avvio visibili
• modello, numero di serie e piattaforma hardware, virtuale o software
• versione SFOS esatta, inclusi MR e build
• ora del guasto e ultima ora di funzionamento nota
• ultime modifiche a firmware, restore, regole, oggetti, interfacce, risorse VM o storage
• per HA: Node interessato, ruolo, stato del peer e ora dell’ultimo failover
• backup aggiornato disponibile e Secure Storage Master Key associata
• per le VM: vCPU, vRAM, vNIC, Primary Disk, Report Disk e limite di licenza
• sintomi ricorrenti come reboot o errori I/O, NPU, di temperatura o di storage

Se l’Advanced Shell è ancora accessibile, è possibile salvare anche estratti pertinenti dei log. Questi esempi leggono solo le ultime 200 righe e non modificano il sistema:

tail -n 200 /log/sysinit.log
tail -n 200 /log/syslog.log
tail -n 200 /log/postgres.log

sysinit.log è il log centrale dell’avvio del sistema, syslog.log contiene gli eventi del kernel e del sistema e postgres.log è utile per il database di configurazione. A seconda di show failure-reason, applicare lo stesso comando tail di sola lettura al log dettagliato appropriato, ad esempio:

tail -n 200 /log/networkd.log
tail -n 200 /log/sigdb.log
tail -n 200 /log/npu-startup.log

networkd.log riguarda le interfacce fisiche e virtuali, sigdb.log il database delle firme e npu-startup.log solo i modelli hardware dotati di NPU. Non tutti i file esistono su ogni piattaforma. L’ulteriore associazione è indicata in Servizi e file di log di Sophos Firewall. Gli estratti dei log possono contenere dati riservati e devono essere trasmessi in modo protetto.

Quando WebAdmin torna accessibile, salvare anche un archivio CTR o di troubleshooting. La procedura è descritta in Salvare i log di Sophos Firewall per il supporto.

Scegliere il passaggio successivo sicuro

Dopo avere salvato le prove, è possibile scegliere con maggiore precisione il percorso di ripristino:

1. Chiara discrepanza delle risorse su una VM o un’appliance software: Documentare lo stato attuale, verificare i limiti della licenza e i valori minimi attuali, spegnere la VM in modo controllato, correggere esattamente la discrepanza confermata e osservare l’avvio successivo.
2. Indicazione relativa allo storage o al logging: Verificare in sola lettura la partizione e il tipo di dati interessato. Non eliminare file con rm. Verificare in sicurezza lo spazio di storage e i report illustra le procedure previste per la diagnostica e la pulizia.
3. Errore subito dopo una modifica del firmware: Confrontare il build con i problemi noti e solo dopo scegliere in modo controllato tra il Maintenance Release attuale, un rollback o il supporto.
4. Indicazione NPU, I/O o hardware ricorrente: Preparare un caso di supporto e, se necessario, una RMA. Un reboot temporaneamente riuscito non esclude un difetto.
5. Errore di avvio del database, del framework, delle regole o errore sconosciuto: Salvare l’output e i log, quindi aprire un caso Sophos Support con una descrizione completa dell’errore. Non rimuovere manualmente file del database, set di regole o firme.
6. Reimage come ripristino: Utilizzarlo solo se un danno al sistema operativo, il supporto o il piano di ripristino documentato giustificano questa procedura. Devono essere disponibili prima il backup, la password e la SSMK. La procedura completa è descritta in Reinstallare il sistema operativo Sophos Firewall.

Dopo ogni misura, non controllare solo WebAdmin. Sono determinanti il normale avvio della console, lo stato HA corretto, lo stato delle interfacce e del routing, le connessioni Internet e VPN e l’eventuale ricomparsa dello stesso messaggio di errore. Se la causa rimane incerta o si ripete, non nasconderla con ulteriori modifiche spontanee.