Sophos Firewall in modalità failsafe: procedere in sicurezza

Quando Sophos Firewall segnala failsafe, occorre trattare la situazione come un incidente di ripristino. La documentazione pubblica di SFOS 22 non descrive un comando diagnostico generale che identifichi in modo affidabile la causa di ogni stato failsafe. Questo runbook non usa quindi né show failure-reason né un sostituto inventato.

Prima si salva senza modifiche il messaggio visualizzato, poi si valutano piattaforma, ruolo HA, build del firmware e ultima modifica. Finché la causa non è dimostrata, non modificare manualmente database, firme, regole o file di sistema.

⚠️ Documentare prima del riavvio: Un riavvio può cambiare l’errore visibile. Fotografare l’intera console, inclusi i primi messaggi di boot, e annotare ora, modello, numero di serie, versione SFOS completa di build e, in HA, il Node interessato. Reset to Factory Defaults, Remove Firewall Rules e le modifiche manuali al database o al file system non sono una diagnosi iniziale sicura.

Acquisire in sicurezza il messaggio failsafe

1. Usare la console diretta disponibile: locale o seriale per l’hardware, console dell’hypervisor per una VM. Rimane utilizzabile quando WebAdmin o la rete non sono raggiungibili.
2. Fotografare il messaggio parola per parola insieme alle righe di boot immediatamente precedenti. Non sostituire il messaggio reale con un output di esempio trovato online.
3. Annotare piattaforma e modello, numero di serie, build SFOS completa, ora del guasto e ultima ora di funzionamento nota.
4. Registrare le modifiche recenti, soprattutto upgrade del firmware, rollback, restore, modifiche a regole o oggetti, risorse VM, dischi virtuali, vNIC ed eventi di storage.
5. In HA, annotare Node interessato, ruolo, stato del peer e ultimo cambio di ruolo. Non riavviare insieme entrambi i Nodes né disattivare HA sulla base di un’ipotesi.

La sola indisponibilità di WebAdmin non dimostra uno stato failsafe. Se il firewall si avvia normalmente e il traffico continua a passare, ma solo l’interfaccia non risponde, eseguire prima la verifica mirata o il riavvio della GUI WebAdmin. Un messaggio failsafe esplicito viene invece trattato come problema di avvio o ripristino.

Circoscrivere le cause documentate

Sophos documenta diversi trigger specifici, ma non esaustivi, per SFOS 22. Le Release Notes di SFOS 22.0 MR2 Build 546 includono un failsafe causato dalla partizione di configurazione piena (NC-181331), un logging daemon che non si avviava sul dispositivo HA Primary (NC-180110), failsafe sul dispositivo Primary iniziale dopo l’upgrade a 22.0 GA (NC-177441) e Failed to start Red server service (NC-178906). Queste voci dimostrano difetti noti e risolti, non una matrice generale di riparazione.

Se lo stato osservato, la piattaforma o il ruolo HA e la cronologia delle versioni corrispondono precisamente a una voce delle Release Notes, inserire l’Issue ID e la build installata nel caso di supporto. Una corrispondenza parziale non dimostra né la stessa causa né che una modifica non coordinata del firmware ripristini il firewall. Sophos cita testualmente il messaggio visualizzato solo per NC-178906. Se il firewall si avvia normalmente e solo un tunnel RED è offline, seguire invece la procedura di troubleshooting RED.

Software appliance

Per una software appliance SFOS 22 installata su hardware proprio, Sophos indica, tra gli altri, i seguenti requisiti minimi rilevanti per il sistema in funzione e dichiara esplicitamente che il firewall passa in modalità fail-safe se non vengono rispettati:

• CPU x86-64 e Legacy BIOS
• almeno 4 GB di RAM
• HDD o SSD di almeno 32 GB; sono consigliati 64 GB
• 2 schede di rete

Documentare lo stato attuale prima di qualsiasi modifica. In caso di discrepanza confermata, chiedere a Sophos Support se è sufficiente un adeguamento supportato delle risorse o se occorre un reimage controllato. Non improvvisare modifiche al disco o alla modalità di avvio. Differenze tra piattaforme e requisiti delle risorse descrive più dettagliatamente appliance hardware, virtuali e software.

Appliance virtuale e hardware

Per una VM, registrare vNIC e dischi virtuali presenti e connessi, CPU, RAM, controller del disco e modifiche recenti dell’hypervisor. Le piattaforme cloud e hypervisor hanno requisiti supportati propri; non applicare automaticamente i valori della software appliance a ogni deployment virtuale.

Per l’hardware, includere nel caso di supporto errori di boot ricorrenti, eventi di alimentazione, indicazioni I/O o SSD, temperatura e ventole. Un singolo riavvio riuscito non esclude un difetto. Le verifiche di temperatura e ventole, stato dell’SSD e preparazione della RMA aiutano a preparare il caso.

Salvare log e backup

Se Advanced Shell è ancora accessibile, sysinit.log, syslog.log e, in presenza di un’indicazione sul database, postgres.log sono log ufficiali di troubleshooting pertinenti. Per il messaggio RED documentato, includere anche red.log. Questo runbook non fornisce volutamente comandi shell per copiare, eliminare o riparare: percorso di accesso e strumenti disponibili possono differire nello stato di ripristino.

Quando WebAdmin torna disponibile, generare un archivio di troubleshooting o CTR. La procedura è descritta in Salvare i log di Sophos Firewall per il supporto. Log e archivi possono contenere dati riservati di rete, utenti e configurazione e devono essere trasmessi in modo protetto solo a destinatari autorizzati.

Prima di restore o reimage devono essere disponibili un backup idoneo, la relativa password e il Secure Storage Master Key associato. Backup e restore di Sophos Firewall spiega queste dipendenze.

Usare fsck-on-nextboot solo con Sophos Support

system fsck-on-nextboot non è un controllo generale dello stato. Sophos avverte che deve essere usato solo su raccomandazione di Sophos Support. È previsto per errori di mount di /sig, /conf o /var; se hardware o SSD non sono integri, il controllo può danneggiare il file system.

La sintassi documentata della Device Console è:

system fsck-on-nextboot [on | off | show]

on forza il controllo di tutte le partizioni al successivo riavvio, off lo annulla prima di tale riavvio e show visualizza la configurazione corrente; il valore predefinito è off. SFOS può programmare automaticamente il controllo in modalità failsafe se il database di configurazione, report o firme non si avvia, se non è possibile applicare una migrazione o se non viene trovato il deployment mode.

Non riavviare solo perché viene visualizzato on. Inserire prima nello stesso piano di manutenzione raccomandazione del supporto, accesso stabile alla console, alimentazione, backup, possibili errori I/O e, in HA, stato del peer. Sophos non indica né una durata fissa né una garanzia di successo.

Scegliere un percorso di ripristino sicuro

• Requisito software chiaramente sotto il minimo: Salvare lo stato attuale ed eseguire in una finestra di manutenzione l’adeguamento o il reimage confermato da Sophos Support. Osservare il successivo avvio dalla console.
• Messaggio corrispondente a un problema noto delle Release Notes: Salvare build completa e Issue ID. Far confermare da Sophos Support il percorso di recovery, upgrade o rollback per questo stato.
• Incidente HA: Proteggere il peer ancora operativo. Niente riavvii simultanei o modifiche non pianificate a ruoli o cluster. Vedere High Availability di Sophos Firewall.
• Errore di storage, database, regole, NPU, I/O o sconosciuto: Non rimuovere file o elementi di configurazione sulla base di ipotesi. Eseguire l’escalation a Sophos Support con console, log e cronologia.
• Reimage: Usarlo solo se Sophos Support o un piano di ripristino documentato lo giustifica e sono presenti tutti i prerequisiti di restore. Vedere Reinstallare Sophos Firewall OS.

Dopo ogni intervento, non controllare soltanto WebAdmin e il login. Verificare l’avvio normale da console, stato HA, interfacce, routing e connessioni Internet e VPN necessarie. Se il messaggio ritorna, aggiungere ora e output invariato al caso invece di apportare altre modifiche improvvisate.

Coinvolgere Sophos Support

Coinvolgere Sophos Support non appena la causa dell’incidente failsafe non può essere limitata a una discrepanza di risorse documentata e correggibile senza rischi. Il caso Sophos Support deve includere almeno:

• foto o copia completa dei messaggi failsafe e di boot
• modello, numero di serie, piattaforma e build SFOS completa
• ora del guasto, ultima ora funzionante e cronologia delle modifiche
• per HA: Node, ruolo, stato del peer e ultimo cambio di ruolo
• log pertinenti o CTR e indicazioni di storage, I/O, NPU o alimentazione
• backup disponibile e stato di password e SSMK, senza rivelare segreti nel testo del ticket
• riavvii o modifiche già eseguiti e relativi risultati

Se WebAdmin è disponibile e Sophos richiede l’accesso remoto, attivare temporaneamente Support access in Diagnostics > Support access. Condividere l’Access ID generato solo tramite il canale di supporto concordato; l’accesso può essere disattivato in qualsiasi momento.