Aggiornamento firmware Sophos Firewall: preparazione e best practice

Un aggiornamento firmware di Sophos Firewall deve essere approvato solo dopo aver chiarito percorso di upgrade, backup, accesso, stato del sistema, HA e procedura di recovery. Eseguire un aggiornamento firmware di Sophos Firewall descrive l’installazione in WebAdmin o tramite Sophos Fusion (in precedenza Sophos Central).

⚠️ Prima di ogni aggiornamento: Devono essere disponibili un backup recente, il Secure Storage Master Key associato e un piano di rollback concreto. Per SFOS 22 o versioni successive, eseguire anche il controllo per l’upgrade a SFOS 22.

Approvazione in dieci punti

Un cambio firmware è pronto quando è possibile rispondere sì a tutti i dieci punti:

1. La versione attuale, la versione target e il percorso di upgrade supportato sono documentati.
2. Release notes e known issues sono stati controllati per la piattaforma e la configurazione utilizzate.
3. Licenza e diritto al supporto consentono l’installazione.
4. Sono disponibili un backup recente, la relativa password e il Secure Storage Master Key corretto.
5. Spazio libero, stato del sistema e, per i modelli XGS Appliance interessati, firmware SSD soddisfano i requisiti.
6. Stato, ruoli e sincronizzazione HA sono corretti; entrambi i nodi soddisfano i requisiti.
7. Finestra di manutenzione, responsabili, orario limite e criteri di rollback sono definiti.
8. È stato predisposto un accesso di amministrazione locale o alternativo.
9. Sono definiti test per WAN, VPN, DNS, NAT, WAF, autenticazione e applicazioni centrali.
10. Monitoring, comunicazione e documentazione del change sono pronti.

Se manca uno di questi punti, l’aggiornamento non deve essere avviato sotto pressione. Rinviare una finestra di manutenzione costa meno di un reimage o di un intervento in sede non pianificati.

Verificare versione, piattaforma e autorizzazione

Un processo operativo definito verifica almeno una volta al mese in Sophos Fusion o in Backup & Firmware > Firmware se è disponibile un aggiornamento. Vengono inoltre seguite attivamente le nuove release notes e le maintenance release annunciate. Ogni MR deve rientrare nella pianificazione, perché anche una release di sola manutenzione può contenere importanti correzioni di sicurezza. Installazione, test e rollback restano comunque attività controllate da eseguire nella finestra di manutenzione.

Release notes e percorso di upgrade

Prima del change, confrontare nelle release notes la versione SFOS attuale, la versione target e il percorso supportato. Verificare inoltre i problemi noti relativi a piattaforma, HA, VPN, routing, autenticazione e alle funzioni effettivamente utilizzate.

Sophos Firewall può mostrare un avviso per un percorso di migrazione non supportato. Se il cambio viene comunque confermato, il firewall può avviarsi con la Factory Configuration e perdere la configurazione esistente. Il rollback automatico non protegge da un percorso di upgrade non supportato. Utilizzare solo un percorso approvato; per un cambio di versione incompatibile, il metodo corretto è un reimage seguito da un restore.

⚠️ Limite della piattaforma: SFOS 21.0 GA e le versioni successive non supportano le appliance hardware XG e SG. Per questi dispositivi occorre pianificare una migrazione a XGS Appliance prima dell’upgrade.

Il controllo di upgrade a SFOS 22 documenta le versioni di partenza supportate per l’upgrade diretto e l’interpretazione dei blocker di SFOS 22.0 MR2 Build 546. Questa matrice è specifica per tale build e non è un percorso universale per SFOS 22; per qualsiasi altro build target, verificare subito prima del change le versioni di partenza supportate e i blocker applicabili nelle release notes aggiornate.

È necessario escludere esplicitamente due blocker di SFOS 22:

• SFOS 22.0 MR1 e versioni successive: La configurazione legacy di Remote Access IPsec ancora presente blocca l’upgrade. Risolverla secondo le istruzioni di migrazione Sophos aggiornate; la semplice disattivazione non è sufficiente.
• SFOS 22.0 MR2 e versioni successive: Il VLAN tagging legacy configurato tramite CLI sulle interfacce bridge blocca l’upgrade. Identificare i bridge interessati e risolvere prima tale configurazione secondo le release notes.

Il controllo separato copre gli altri temi di SFOS 22, tra cui spazio, nomi delle interfacce, STAS, firmware SSD e piattaforma. Per altre versioni target valgono le rispettive release notes aggiornate.

⚠️ Prima del primo upgrade a SFOS 21 o versioni successive: In Certificates > Certificate authorities, cercare i nomi CA Let’s Encrypt riservati. Una voce esistente con lo stesso identico nome può interrompere la migrazione a causa di NC-146082. Non eliminare la CA senza verifiche: mettere prima al sicuro e controllare il backup, la chiave privata, i certificati dipendenti e i servizi.

Licenza e supporto

A partire da SFOS 19.0 MR1, senza Enhanced Support o Enhanced Plus Support sono consentiti tre passaggi gratuiti a versioni GA, MR o EAP. Successivamente il firmware può ancora essere scaricato, ma non installato; Install è disattivato.

Pattern Updates, hotfix, reimage, Mandatory Firmware Upgrades e Assistant Firmware Upgrades sono esclusi da questa regola di supporto. Prima della finestra di manutenzione verificare comunque che:

• Administration > Licensing mostri la licenza e il diritto al supporto previsti.
• Sophos Fusion mostri il firewall e il numero di serie corretti.
• La versione target e il download siano disponibili.
• Accesso al supporto, contatti e procedura di escalation siano noti.

Se per il change è necessario un accesso esterno, provarlo in anticipo. Per Avanet, vedere Configurare l’accesso di supporto a Sophos Firewall.

Controllare separatamente gli hotfix automatici

Gli hotfix non sono né uno slot firmware né un Pattern Update. SFOS 22 verifica ogni 30 minuti la disponibilità di hotfix e li installa automaticamente per impostazione predefinita. Sophos consiglia di non modificare questa impostazione. Leggere lo stato nella Device Console prima e dopo un change del firmware:

system hotfix show

Per SFOS 22, Sophos indica che gli hotfix già installati rimangono anche dopo un firmware upgrade. L’elenco relativo alla versione in SFOS 23 viene invece rivalutato dopo ogni cambio di versione, come spiegato nella sezione seguente. Se il controllo mostra che l’installazione automatica è disattivata, determinare prima chi l’ha disattivata e perché. In assenza di un’eccezione documentata, riattivarla:

system hotfix enable

system hotfix disable disattiva soltanto l’installazione automatica e non è una procedura generale di troubleshooting. Uno stato attivo non dimostra inoltre che uno specifico hotfix sia già stato applicato o che il percorso di download funzioni. Per un errore concreto, verificare anche build, ora, accesso a Internet, log e riferimento dell’errore Sophos.

SFOS 23: verificare gli aggiornamenti di sicurezza applicati

In SFOS 23, Backup & firmware > Hotfix: Security updates mostra quali aggiornamenti di sicurezza tramite hotfix sono stati applicati dal passaggio alla versione SFOS attualmente in esecuzione. Gli hotfix correggono il sistema in esecuzione senza un upgrade del firmware e non devono essere confusi con l’elenco delle immagini firmware disponibili. L’installazione automatica degli hotfix deve essere attiva; è abilitata per impostazione predefinita. system hotfix show verifica questa impostazione, ma non dimostra che una specifica correzione di sicurezza sia stata applicata.

Per documentare il change prima e dopo il cambio di firmware:

1. Documentare la versione SFOS attiva, il build e l’ora della verifica, quindi aprire la pagina Hotfix: Security updates.
2. Ordinare le voci per data di applicazione e registrare gli aggiornamenti relativi al problema analizzato. Per le vulnerabilità descritte pubblicamente, la colonna Advisory rimanda al relativo avviso di sicurezza. Le correzioni interne possono comparire senza ID CVE e senza link a un advisory.
3. In HA, includere entrambi i dispositivi nella verifica successiva: il Primary attuale riceve l’hotfix e si sincronizza con l’Auxiliary, sul quale viene applicato a sua volta l’hotfix. Una verifica riuscita su un dispositivo non sostituisce la verifica per l’intero cluster.

Una vulnerabilità può comparire più volte, perché per risolverla completamente possono essere necessari più hotfix. Una singola voce pertinente non dimostra quindi, in generale, una protezione completa. Per una specifica correzione di sicurezza, occorre confrontare i requisiti del relativo avviso di sicurezza con il build in esecuzione e gli aggiornamenti effettivamente applicati.

Notifiche e log: In System services > Notification list, nell’area Firmware, attivare l’opzione Email per Security updates. Per questi aggiornamenti non sono disponibili notifiche SNMP. Gli aggiornamenti di sicurezza tramite hotfix compaiono anche nel Log viewer; i relativi Audit Logs vengono generati e inoltrati a Sophos Fusion per Central Firewall Reporting. Queste indicazioni su notifiche e log valgono per gli aggiornamenti di sicurezza tramite hotfix, non in generale per ogni correzione tramite hotfix. La sola assenza di un’email non dimostra quindi né il successo né il fallimento.

Dopo un cambio di versione: SFOS installa prima il nuovo firmware e poi applica gli hotfix disponibili per quella versione. L’elenco precedente degli hotfix viene rimosso e sostituito dall’elenco della nuova versione; non è un archivio che copre più versioni. La stessa correzione può comparire nuovamente perché è stata applicata in modo indipendente alla nuova versione. Se le correzioni precedenti sono già incluse nel nuovo firmware, possono non comparire come voci hotfix separate.

Un elenco vuoto significa soltanto che per la versione attuale non sono ancora stati applicati e visualizzati aggiornamenti di sicurezza tramite hotfix. Non dimostra né l’assenza di protezione, né una protezione completa, né il corretto funzionamento dell’installazione automatica. In caso di dubbi, verificare congiuntamente versione attiva e build, impostazione CLI, avviso di sicurezza, release notes e log; una pagina vuota non giustifica la disattivazione preventiva dell’installazione automatica né un rollback.

Preparare backup, recovery e documentazione

Backup, SSMK e slot firmware

Prima dell’aggiornamento scaricare un backup recente della configurazione e verificare quale Secure Storage Master Key gli appartiene. Registrare inoltre nel change la password del backup, l’accesso amministratore, la versione firmware attiva e la versione target.

Sophos Firewall conserva al massimo due versioni firmware: una attiva e una inattiva. Ogni partizione ha il proprio stato di configurazione. Un rollback attiva quindi non solo il firmware precedente, ma anche la relativa configurazione. Le modifiche eseguite dopo l’upgrade possono andare perse tornando indietro.

Il rollback automatico è disponibile da SFOS 20.0 per determinati errori di migrazione della configurazione. È una funzione di sicurezza, ma non sostituisce il backup o l’analisi della causa e non è disponibile per un percorso di upgrade non supportato.

Il processo completo è descritto in Creare o ripristinare un backup di Sophos Firewall. Se non è possibile un normale cambio di versione, vedere Reinstallare Sophos Firewall OS con una chiavetta USB.

Definire in anticipo i criteri di rollback

Prima di iniziare, definire per quanto tempo verrà analizzato un errore e quando inizierà la recovery. Un rollback è opportuno se WAN, HA, VPN centrali o pubblicazioni critiche per la produzione non possono essere stabilizzate entro il tempo concordato. Per una singola regola, un oggetto o un servizio esterno, il troubleshooting mirato è spesso preferibile.

Per una normale Maintenance Release sono sufficienti come documentazione un backup, uno screenshot della pagina firmware, la finestra e il risultato dei test. Per change più ampi, Sophos Firewall Config Studio aiuta a confrontare le configurazioni e l’Audit Trail registra le modifiche durante la finestra di manutenzione.

Verificare stato del sistema, spazio e HA

Spazio di archiviazione e SSD

Prima di un upgrade importante, verificare in WebAdmin che:

• Control center non mostri avvisi critici irrisolti.
• Backup & Firmware > Firmware mostri gli slot firmware previsti.
• Diagnostics > Log viewer non contenga errori ricorrenti di sistema o migrazione.
• I servizi rilevanti siano stabili.
• Firewall Health Check non contenga punti aperti che influiscono sul change.

Dopo l’accesso SSH, aprire Device Management > Advanced Shell e controllare lo spazio libero:

df -kh

Se una partizione è quasi piena, non eliminare alla cieca file, log o report in Advanced Shell. Individuare prima la causa e utilizzare il metodo di pulizia documentato. Vedere Controllare lo spazio di Sophos Firewall e gestire i report.

SFOS 22 può richiedere spazio aggiuntivo. Su alcuni modelli XGS Appliance deve essere aggiornato prima anche il firmware SSD; WebAdmin mostra un messaggio quando è necessario. In un cluster HA ogni nodo viene valutato separatamente. Se un’appliance non soddisfa i requisiti, può bloccare l’intero upgrade.

Per appliance meno recenti o con problemi di I/O, database o report, controllare anche lo stato dell’SSD con SMART. Senza un riscontro concreto, modifiche manuali a database o file system non sono una preparazione utile.

Sophos indica un riavvio prima dell’upgrade solo come possibilità facoltativa per svuotare la cache di memoria. Non è un requisito e provoca un’interruzione aggiuntiva. Il riavvio va quindi eseguito solo nella finestra di manutenzione, dopo aver salvato i log rilevanti e confermato il percorso di recovery per l’accesso di gestione. Se il firewall mostra un’instabilità non spiegata, l’upgrade deve essere interrotto; un riavvio non deve sostituire l’analisi della causa né far apparire il sistema sano solo temporaneamente.

Cluster HA

Non è necessario disattivare HA per un normale aggiornamento firmware. Prima dell’approvazione, tuttavia, entrambe le appliance devono essere connesse, sincronizzate e chiaramente identificabili come Primary e Auxiliary. Anche un aggiornamento HA richiede una finestra di manutenzione, perché il failover può interrompere brevemente singole sessioni, tunnel VPN o ping.

Prima di iniziare, documentare:

• Ruoli, stato HA e sincronizzazione.
• Stato del link HA.
• Requisiti di firmware, spazio e SSD di entrambi i nodi.
• Accesso di amministrazione alternativo.
• Failover previsto e possibili brevi interruzioni.

L’appliance Auxiliary non deve essere aggiornata separatamente. L’articolo operativo descrive la sequenza esatta: aggiornamento dell’Auxiliary, failover e aggiornamento del precedente Primary. Altri casi HA sono descritti in Cluster HA Sophos Firewall: varianti e manutenzione.

I Pattern Updates vengono installati sul Primary e poi sincronizzati sull’Auxiliary. Gli hotfix e il loro stato devono essere considerati separatamente e controllati su entrambi i dispositivi dopo la finestra di manutenzione.

Pianificare finestra di manutenzione, Central e test

Finestra di manutenzione e accesso

Una finestra di manutenzione comprende più del solo orario di installazione:

• Ora di inizio, termine massimo e decisione di rollback.
• Responsabili di firewall, rete, server, applicazioni e supporto.
• Contatto locale, accesso out-of-band o secondo percorso di amministrazione.
• Canale di comunicazione in caso di guasto WAN o Remote Access.
• Modalità manutenzione per monitoring e alerting.
• Sequenza di test per i processi aziendali più importanti.

Per le sedi remote, non affidarsi esclusivamente a Sophos Fusion o alla connessione VPN esistente. Se proprio quel percorso si interrompe durante l’aggiornamento, devono rimanere disponibili un accesso o una procedura di escalation definiti.

Pianificare il firmware tramite Sophos Fusion

Gli aggiornamenti firmware gestiti da Central vengono preparati e monitorati in My Products > Firewall Management > Firewalls. La Task Queue riguarda group policy e task di configurazione MDR/API e non mostra gli aggiornamenti firmware.

Tramite Central si possono installare solo versioni target che hanno raggiunto la fase Available to all del processo di rilascio. Gli aggiornamenti pianificati iniziano secondo il fuso orario impostato sul firewall, non secondo l’ora del browser dell’amministratore. Per le sedi internazionali, registrare nel change fuso orario, finestra locale e versione target.

Durante l’upgrade, un’icona di stato ruota accanto al firewall e scompare al termine. Successivamente è comunque obbligatorio controllare localmente la versione firmware attiva. In caso di rollback automatico, Central mostra un messaggio corrispondente accanto alla versione.

Configurare gli aggiornamenti di manutenzione ricorrenti

Recurring Firmware Upgrade consente di definire una finestra di manutenzione ricorrente per l’account Sophos Fusion. Il piano si applica a tutti i firewall dell’account; quando è disponibile un firmware adatto, i dispositivi idonei vengono aggiornati secondo questo piano. La funzione richiede un’attivazione consapevole e non garantisce che ogni firewall riceva una nuova versione a ogni scadenza. Backup, percorso di upgrade, diritto al supporto e gli altri punti di approvazione di questo articolo rimangono prerequisiti.

1. In My Products > Firewall Management > Firewalls, aprire Recurring Firmware Upgrade e attivare Schedule maintenance updates.
2. Scegliere Weekly (Default) per una cadenza settimanale e impostare giorno della settimana e ora. Per Monthly, selezionare prima 1st, 2nd, 3rd, 4th o Last come settimana del mese, poi giorno della settimana e ora. Non si tratta di una data di calendario scelta liberamente.
3. In Staging firewalls, selezionare firewall pilota adatti. È possibile selezionare più dispositivi; la sezione successiva spiega la scelta e i suoi limiti.
4. Attivare Schedule major version updates solo dopo aver deciso esplicitamente di automatizzare i passaggi a versioni principali. Senza questa opzione, il piano rimane limitato agli aggiornamenti di manutenzione all’interno della versione principale attuale. Con questa opzione, lo stesso calendario e lo stesso processo di staging si applicano anche alle versioni principali idonee. Le nuove funzioni e le modifiche all’architettura richiedono comunque una verifica di compatibilità separata.
5. Usare Review per controllare le impostazioni e correggerle se necessario. Solo Confirm conferma il piano.
6. Aprire quindi l’icona Scheduled accanto a ogni firewall interessato e controllare la data e l’ora effettivamente pianificate. Registrare nel change versione target, sede, fuso orario del firewall e finestra di manutenzione locale.

Una possibile finestra mensile è Monthly, 2nd, domenica, 02:00. L’esempio indica la seconda domenica del mese alle 02:00 nel fuso orario di ciascun firewall. Non è una raccomandazione per tutte le sedi: la finestra deve essere compatibile con gli orari operativi, l’esecuzione del backup, la disponibilità dei responsabili e i test successivi. Sedi con fusi orari diversi non iniziano contemporaneamente. Prima di confermare, verificare il fuso orario di ogni firewall e le date e ore visualizzate.

Per le coppie HA, Sophos Fusion pianifica il task di upgrade sul Primary. L’Auxiliary viene aggiornato automaticamente attraverso il processo HA esistente e non riceve un task manuale separato. Le verifiche HA e le possibili interruzioni della sezione Cluster HA valgono anche per la pianificazione ricorrente. Né l’orario di avvio né un’icona di stato che indica successo garantiscono un orario di completamento fisso o un funzionamento senza interruzioni; la finestra di manutenzione deve includere anche la validazione e, se necessario, il rollback.

Lo staging è un controllo tecnico, non il collaudo delle applicazioni

I firewall di staging ricevono il firmware per primi. Se il servizio riconosce l’upgrade come riuscito, gli altri firewall vengono aggiornati secondo il calendario. Se un upgrade di staging fallisce, il rollout si arresta e i firewall interessati tornano al firmware precedente. La causa deve essere risolta prima di riprendere il calendario. Il piano di backup e recovery esistente rimane necessario: questo meccanismo del servizio non va interpretato come un percorso di recovery garantito per ogni possibile errore.

I dispositivi pilota devono rappresentare adeguatamente le funzioni e le piattaforme utilizzate, e un loro guasto deve essere gestibile. Una sede con il solo accesso a Internet, ad esempio, non verifica automaticamente la configurazione WAF o VPN di altre sedi. Se non si selezionano firewall di staging, tutti i firewall idonei vengono aggiornati direttamente secondo il calendario; manca quindi la fase pilota preliminare.

⚠️ Nessuna approvazione manuale intermedia: Il successo dello staging rilevato dal servizio non dimostra che DNS, VPN, servizi pubblicati o applicazioni aziendali funzionino. I test funzionali descritti più avanti restano necessari. Per questo processo non è documentato qui un passaggio di approvazione manuale tra lo staging riuscito e il resto del rollout. Se prima deve essere eseguito un collaudo funzionale del pilota, non bisogna confidare che il servizio attenda; attivare la pianificazione automatica solo quando la procedura scelta soddisfa questo requisito.

Modificare o saltare singole scadenze, oppure adeguare lo staging

Senza un piano ricorrente, configurare un aggiornamento singolo tramite l’icona della freccia blu accanto al firewall e Schedule upgrade: scegliere la versione target, selezionare Immediately o At, impostare data e ora per At e confermare con Schedule upgrade. Quando esiste un piano ricorrente, usare invece le seguenti azioni per i singoli firewall. Non modificano il piano ricorrente degli altri firewall.

• Override schedule: Aprire l’icona Schedule accanto al firewall e scegliere Override schedule. Nella finestra Firmware upgrades, selezionare la versione target e Immediately o At. Per At, impostare data e ora tramite l’icona del calendario; confermare con Override schedule. Immediately avvia il task senza una scadenza successiva e va quindi usato solo in una finestra di manutenzione già approvata. Verificare la versione scelta tramite l’icona Release notes; passando il puntatore sull’icona Clock, vengono mostrate data, ora e ora locale del firewall per il piano attuale. Controllare nuovamente la pianificazione visualizzata dopo la modifica.
• Skip occurrence: Aprire l’icona Schedule e scegliere Skip occurrence se si deve saltare soltanto il prossimo aggiornamento pianificato per questo firewall. Il task viene spostato alla ricorrenza successiva. Con una cadenza settimanale il venerdì, significa il venerdì seguente, non un’eccezione permanente. Controllare la nuova data e ora e confrontarle nuovamente con la finestra di manutenzione.
• Remove from upgrade staging: Tramite l’icona Schedule, aprire Remove from upgrade staging. Nella finestra Recurring Firmware Upgrade Schedule, deselezionare il firewall interessato in Staging firewalls, poi eseguire Review e Confirm. Questo rimuove il suo ruolo di pilota, non la sua partecipazione alla pianificazione generale del firmware. Controllare poi i dispositivi di staging rimasti selezionati e la pianificazione del firewall. Per rendere nuovamente pilota il dispositivo, selezionarlo di nuovo nella selezione di staging del piano ricorrente e confermare il piano con Review e Confirm.

Se manca una versione target, verificare prima la fase Available to all, senza aggirare il limite con un caricamento locale improvvisato. Se le scadenze non corrispondono al change, confrontare prima il fuso orario del firewall con l’ora locale mostrata da Clock. Dopo un errore di staging, verificare firmware attivo, messaggio di rollback e log, risolvere la causa ed eseguire i veri test funzionali prima di approvare altri aggiornamenti. Modificare una scadenza o rimuovere un firewall dallo staging non annulla un aggiornamento firmware già eseguito; valgono le procedure di rollback e recovery descritte sopra.

Test funzionali reali

Un ping da solo non dimostra che il firewall funzioni correttamente dopo l’aggiornamento. Definire prima test concreti con source, destination e risultato previsto:

• Accesso a Internet e risoluzione DNS.
• DHCP, VLAN, uplink WAN e route SD-WAN.
• Site-to-Site VPN, Remote Access VPN e RED.
• Regole firewall, NAT e servizi pubblicati.
• WAF, Web Protection e TLS Inspection.
• LDAP, RADIUS, Microsoft Entra ID e altra autenticazione centrale.
• Flusso email e applicazioni aziendali critiche.
• Syslog, SIEM e monitoring.

Validare dopo l’aggiornamento

Dopo il riavvio, controllare prima la versione attiva e lo slot inattivo previsto in Backup & Firmware > Firmware. Quindi:

• Controllare in Control center nuovi avvisi o un rollback automatico.
• Verificare interfacce, WAN, SD-WAN, ruoli HA e sincronizzazione.
• Validare VPN, RED, DNS, DHCP, regole, NAT, WAF e autenticazione con i test preparati.
• Controllare lo stato di pattern e hotfix.
• Verificare la sincronizzazione Sophos Fusion, oltre a monitoring, syslog e SIEM.
• Registrare nel change risultato, orari, scostamenti ed eventuali attività successive.

Se una singola funzione non opera correttamente, utilizzare prima Log Viewer, Policy Test, Packet Capture e i service log pertinenti. Vedere Testare una regola firewall con Log Viewer, Policy Test e Packet Capture e Troubleshooting Sophos Firewall: servizi e log.

FAQ