Verifica della Sophos Firewall prima dell'aggiornamento a SFOS 22
SFOS 22 introduce importanti cambiamenti architetturali nella Sophos Firewall. Per gli amministratori non è solo interessante sapere quali nuove funzionalità saranno disponibili dopo l’aggiornamento. È più importante, innanzitutto, verificare se il proprio firewall può essere aggiornato correttamente a SFOS 22.
Questa guida serve come controllo pre-aggiornamento. L’articolo non sostituisce la guida generale all’aggiornamento del firmware di Sophos Firewall, ma la integra con i punti che possono causare problemi particolarmente rapidi con SFOS 22: piattaforma supportata, nomi delle interfacce, spazio di archiviazione, backup, stato HA, IPsec Remote Access legacy, IPsec basato su policy, NAT e piano di rollback.
Video guida
Quando è utile questo controllo
Il controllo dovrebbe essere effettuato prima di ogni aggiornamento pianificato a SFOS 22 o superiore. È particolarmente importante se si verifica una delle seguenti situazioni:
- il firewall è ancora su hardware XG o SG
- l’appliance è stata già aggiornata attraverso diversi major release
- ci sono molti VLAN, alias, bridge, LAG, interfacce RED o XFRM
- si tratta di una piccola appliance desktop, firewall virtuale o appliance software
- il firewall è in un cluster HA
- VPN IPsec Remote Access è utilizzato o è stato utilizzato in passato
- sono in uso IPsec site-to-site basato su policy, regole SNAT speciali o regole VPN-NAT
- STAS o altre autenticazioni basate su utente controllano regole firewall produttive
- il firewall è gestito tramite Sophos Central o si prevede di aggiornarlo tramite esso
Se il firewall è già instabile nella vita quotidiana, i servizi devono essere riavviati regolarmente o le partizioni sono fortemente riempite, l’aggiornamento non dovrebbe essere considerato come un tentativo di riparazione. In questo caso, stabilizzare prima lo stato attuale e chiarire la causa.
1. Verifica della piattaforma e del percorso di aggiornamento
SFOS 22.0 e versioni successive non supportano più le appliance hardware XG e SG. Chi ancora utilizza tali dispositivi deve prima pianificare la migrazione a XGS, firewall virtuale, appliance software o distribuzione cloud. Per la decisione tra vecchie e nuove generazioni hardware, l’articolo Qual è la differenza tra un firewall XG e XGS? può essere utile.
Sulle piattaforme supportate, dovrebbe essere verificato anche da quale versione si sta aggiornando. Le note di rilascio di SFOS 22 mostrano quali versioni possono essere migrate direttamente a SFOS 22. Se viene scelto un percorso non supportato, il firewall può avviarsi con la configurazione di fabbrica dopo la conferma. Questo rischio deve essere escluso prima di una finestra di manutenzione.
Procedura pratica:
- Annotare la versione firmware attuale sotto
Backup & Firmware > Firmware. - Documentare modello, numero di serie e tipo di piattaforma.
- Verificare nelle note di rilascio ufficiali di Sophos se il percorso di aggiornamento diretto è supportato.
- Per hardware XG o SG, non trattare più la pianificazione di SFOS 22 come un normale aggiornamento, ma come un progetto di migrazione.
2. Verifica dei nomi delle interfacce prima dell’aggiornamento
Un punto di aggiornamento facilmente trascurabile riguarda i nomi delle interfacce. Le interfacce fisiche o logiche potrebbero non essere visibili o espandibili nella vista WebAdmin sotto Network > Interfaces se un nome di interfaccia, nome hardware o nome branch termina con dieci o più cifre.
Questo è scomodo perché il traffico può continuare a essere elaborato, ma l’amministrazione in WebAdmin sembra improvvisamente come se mancassero delle interfacce. Particolarmente nelle migrazioni, schemi di nomi automatizzati, configurazioni importate o nomi VLAN con numeri di posizione, cliente o inventario, questo punto dovrebbe essere verificato prima dell’aggiornamento.
Esempi critici:
| Esempio | Rischio |
|---|---|
VLAN_1234567890 | termina con dieci cifre |
Branch_1000000001 | il nome del branch può disturbare la visualizzazione |
PortA_2026010101 | inteso come parlante, ma finale numerico rischioso |
Procedura pratica:
- Aprire Network > Interfaces.
- Verificare interfacce fisiche, VLAN, alias, bridge, LAG, interfacce RED e XFRM.
- Cercare nomi che terminano con dieci o più cifre.
- Modificare i nomi interessati in una scrittura più breve o chiaramente separata prima dell’aggiornamento.
- Dopo la modifica, verificare se le regole firewall, le regole NAT, le rotte SD-WAN, DHCP, VPN e la documentazione sono ancora comprensibili.
Sono migliori i nomi in cui i numeri non sono un blocco lungo alla fine. Ad esempio, invece di VLAN_1234567890, VLAN-1234567890-Client o un nome funzionale come Client-VLAN-100 è più leggibile e operativo.
Se dopo un aggiornamento le interfacce mancano nella vista WebAdmin, non si dovrebbe subito presumere che la configurazione di rete sia persa. Prima verificare se il comportamento corrisponde alla problematica dei nomi delle interfacce, se il traffico continua a scorrere e se i nomi interessati devono essere adattati. Per la pianificazione generale delle interfacce, si adatta Configurare zone e interfacce di Sophos Firewall.
3. Verifica dello spazio di archiviazione e degli avvisi firmware
SFOS 22 richiede spazio di archiviazione aggiuntivo per nuove funzionalità e cambiamenti architetturali. La maggior parte delle appliance soddisfa i requisiti, ma alcune distribuzioni desktop, virtuali e software potrebbero richiedere una verifica o correzione manuale. Se il firewall mostra un avviso sui requisiti di spazio di archiviazione nella pagina del Control Center o del firmware, non dovrebbe essere ignorato.
Tramite SSH è possibile verificare grossolanamente il riempimento delle partizioni:
df -kh
L’output non sostituisce una verifica di compatibilità Sophos, ma aiuta a valutare se /, /var, /content o altre partizioni sono insolitamente piene. Se una partizione è molto stretta, non si dovrebbe semplicemente aggiornare alla cieca. Prima chiarire quali dati si trovano lì, se è possibile pulire log o file vecchi e se esiste un avviso Sophos per l’appliance interessata.
È importante anche la pianificazione del tempo: se il firewall deve adattare le partizioni durante l’aggiornamento, l’update può richiedere più tempo di un normale rilascio di manutenzione. La finestra di manutenzione non dovrebbe quindi essere pianificata troppo stretta.
4. Preparare backup e ripristino
Prima dell’aggiornamento è necessario un backup fresco. Sembra banale, ma è cruciale per i major release. Il backup non solo deve essere creato, ma anche reperibile, decriptabile e associabile a un dispositivo specifico. L’articolo Creare o ripristinare un backup di Sophos Firewall spiega i punti principali su backup, ripristino e Secure Storage Master Key.
Prima di SFOS 22 dovrebbero essere completati almeno questi punti:
- creare un backup della configurazione attuale e salvarlo esternamente
- documentare il Secure Storage Master Key, se si utilizzano backup criptati
- verificare l’accesso admin locale e tramite la rete di manutenzione
- verificare lo stato della licenza e l’accesso a Sophos Central
- tenere a portata di mano l’immagine firmware attuale e quella di destinazione
- definire la decisione di rollback: quando si attende, quando si torna indietro
In siti critici dovrebbe essere chiaro anche chi ha accesso fisico all’appliance e come si eseguirebbe un reimage se necessario. La reinstallazione è una procedura diversa da un normale aggiornamento firmware. Per questo c’è la guida separata Reinstallare Sophos Firewall OS.
5. Stabilire Go/No-Go prima della finestra di manutenzione
Un aggiornamento a SFOS 22 non dovrebbe essere deciso solo durante la finestra di manutenzione. Prima deve essere chiaro in quali condizioni si inizia, si attende, si interrompe o si torna indietro. Questo riduce decisioni frenetiche se il firewall impiega più tempo, un nodo HA non si sincronizza o un servizio critico non funziona dopo il riavvio.
Punti Go/No-Go sensati:
| Domanda | Go | No-Go |
|---|---|---|
| La piattaforma supporta SFOS 22 | Modello e percorso di aggiornamento sono verificati | Hardware XG/SG o percorso di aggiornamento non chiaro |
| Backup e SSMK | Il backup è salvato esternamente e i dati di ripristino sono disponibili | Il backup manca, non è reperibile o manca il SSMK |
| IPsec Remote Access | La configurazione legacy è esclusa o migrata | La configurazione legacy è presente o non chiara |
| IPsec site-to-site | IPsec basato su policy, NAT e traffico di test sono documentati | Selettori di traffico, SNAT o controparte non sono chiari |
| Stato HA | Il cluster è stabile e sincronizzato | HA è degradato, non sincronizzato o non chiaro |
| Accesso | Accesso admin locale e rete di manutenzione sono verificati | L’accesso dipende solo da un percorso remoto non sicuro |
| Rollback | Punto decisionale e responsabili sono definiti | Nessuno decide in modo vincolante su attesa o rollback |
Per siti distribuiti dovrebbe essere inoltre chiaro chi è raggiungibile durante la finestra di manutenzione: persona di contatto tecnico, contatto del sito, persona con accesso fisico e decisore per il rollback. Se l’aggiornamento viene eseguito da remoto, si dovrebbe inoltre verificare se è disponibile un accesso alternativo nel caso in cui VPN, WAN o Central Management non funzionino temporaneamente.
Un piano di fallback non è una debolezza del cambiamento. Previene che durante un’interruzione vengano modificate contemporaneamente firmware, routing, VPN, HA e switching. Se dopo l’aggiornamento un servizio critico non funziona, si dovrebbe prima eseguire il piano di validazione definito. Solo dopo si decide se un rollback, un ripristino, un reimage o una risoluzione mirata del problema è più sensato.
6. Preparare correttamente il cluster HA
Nei cluster HA non si deve considerare solo il firewall attivo. Entrambi i nodi devono essere supportati, avere lo stesso stato di partenza sensato e sincronizzarsi correttamente. Un aggiornamento su un cluster HA già compromesso aumenta il rischio di interruzioni inutili.
Prima della finestra di manutenzione verificare:
System services > High availabilitymostra uno stato HA sano.- Entrambe le appliance sono dello stesso modello o una combinazione HA supportata.
- Versione firmware, stato della licenza e sottoscrizione sono plausibili.
- Link HA, porte monitorate e porte switch collegate sono stabili.
- È documentato quale dispositivo era attivo prima dell’aggiornamento.
Per la pianificazione generale dell’HA e le particolarità di Active-Passive, Active-Active, licenze e manutenzione si adatta l’articolo Varianti di cluster HA di Sophos Firewall.
7. Cercare IPsec Remote Access legacy
Da SFOS 22.0 MR1, VPN IPsec Remote Access legacy non è più supportato. I firewall con questa configurazione legacy non possono essere aggiornati a SFOS 22.0 MR1 o versioni successive. Questo è un tipico blocco per l’aggiornamento, poiché IPsec Remote Access è spesso stato configurato una volta in ambienti più vecchi e poi non più toccato per lungo tempo.
Prima dell’aggiornamento, quindi, si dovrebbe verificare se sono presenti vecchie configurazioni IPsec Remote Access. In caso affermativo, è necessario prima migrare alla configurazione IPsec Remote Access attuale, SSL VPN, ZTNA o un altro design di accesso remoto adatto. La procedura concreta è descritta in Migrare IPsec Remote Access legacy prima di SFOS 22 MR1. Per il troubleshooting generale dell’IPsec, aiuta anche Troubleshooting VPN IPsec di Sophos Firewall.
Procedura pratica:
- Aprire la sezione
Remote access VPNnel WebAdmin. - Controllare se è presente una configurazione IPsec Remote Access legacy.
- Documentare utenti interessati, profili, pool, autenticazione e configurazioni Sophos Connect distribuite.
- Pianificare la configurazione sostitutiva e testarla con pochi utenti di prova.
- Solo dopo una migrazione riuscita, rimuovere la configurazione legacy e verificare nuovamente l’aggiornamento del firmware.
Se si utilizza Sophos Connect, si dovrebbero includere anche le guide esistenti alla Configurazione del firewall Sophos Connect, all’installazione su Windows e all’installazione su macOS.
8. Verifica di IPsec basato su policy e NAT
SFOS 22.0 GA e versioni successive cambiano il comportamento di IPsec VPN site-to-site basato su policy. Inoltre, nelle note di rilascio di SFOS 22 è documentato un problema risolto in cui il traffico IPsec basato su policy poteva fallire se la regola SNAT predefinita era configurata con un indirizzo IP statico anziché MASQ.
Questo non è un motivo per ricostruire ogni configurazione IPsec in anticipo. È però un buon motivo per testare consapevolmente IPsec basato su policy prima e dopo l’aggiornamento. È particolarmente importante se il firewall utilizza più VPN, reti sovrapposte, regole SNAT specifiche, una regola SNAT predefinita adattata o reti partner con aspettative di IP di origine fisse.
Prima dell’aggiornamento verificare:
- Identificare i tunnel site-to-site basati su policy.
- Documentare le reti locali e remote o i selettori di traffico.
- Verificare le regole NAT sul traffico VPN, in particolare SNAT predefinito,
MASQ, regole SNAT specifiche e ordine delle regole. - Definire un caso di test per ogni tunnel importante con origine, destinazione, servizio e direzione prevista.
- Documentare la controparte e il percorso di ritorno, in modo che un test post-aggiornamento non si limiti a “Ping non funziona”.
Dopo l’aggiornamento, non si dovrebbero mescolare questi test con controlli ampi. È meglio un test mirato per tunnel: confrontare Log Viewer, Packet Capture, ID regola firewall, ID regola NAT e contatore byte in ipsec statusall. Se il tunnel è verde ma non scorre traffico utile, si adatta Troubleshooting VPN IPsec di Sophos Firewall. Per l’inquadramento NAT aiuta Comprendere il NAT su Sophos Firewall.
9. Verifica di STAS e regole basate su utente
Se STAS è attivo, non dovrebbe essere semplicemente “funziona nella vita quotidiana” prima di SFOS 22.0 MR1 o versioni successive. Nella lista dei problemi noti è documentato un problema in cui l’opzione Restrict client traffic during identity probe può bloccare un aggiornamento a SFOS 22.0 MR1 o causare ripetute identity probe con brevi interruzioni del traffico dopo l’aggiornamento.
Questo riguarda soprattutto gli ambienti in cui STAS non è utilizzato solo per il reporting, ma per regole firewall produttive basate su utente. Se l’associazione utente-IP si interrompe brevemente, sembra rapidamente un problema di regola, DNS o applicazione.
Prima dell’aggiornamento verificare:
- Aprire
Authentication > STAS. - Controllare lo stato di STAS e i collector utilizzati.
- Verificare se Restrict client traffic during identity probe è attivo.
- Identificare le regole basate su utente che dipendono da STAS.
- Registrare un utente di prova e verificare Live Users e Log Viewer.
Se questa opzione è attiva o si notano già brevi interruzioni, il punto dovrebbe essere chiarito prima della finestra di manutenzione. La procedura dettagliata è descritta in Configurare STAS su Sophos Firewall.
10. Validare miratamente dopo l’aggiornamento
Dopo il riavvio, l’aggiornamento non è automaticamente completato. Solo quando le principali funzioni operative sono state verificate, la finestra di manutenzione è conclusa correttamente.
Verificare almeno:
- la versione firmware corretta è attiva
- Network > Interfaces mostra interfacce fisiche e logiche plausibili
- l’accesso a Internet e le regole firewall centrali funzionano
- VPN site-to-site e VPN Remote Access funzionano
- i test IPsec basati su policy mostrano l’IP di origine previsto e la regola NAT appropriata
- lo stato HA è di nuovo sincronizzato
- STAS, AD SSO o altre associazioni utente funzionano, se utilizzate in produzione
- Sophos Central Management e Reporting inviano dati
- Log Viewer non mostra nuovi errori critici
- servizi importanti come DNS, DHCP, Web Protection, IPS e autenticazione funzionano come previsto
Se VPN, routing o regole non funzionano come previsto, non modificare subito più punti contemporaneamente. Prima restringere con Log Viewer, Policy Test, Packet Capture e i log dei servizi interessati. Per un troubleshooting strutturato, Testare le regole firewall con Log Viewer, Policy Test e Packet Capture e Troubleshooting di Sophos Firewall: Servizi e Log sono utili integrazioni.
11. Documentare prova e documentazione operativa
Un aggiornamento è completato correttamente solo quando il risultato è documentato in modo tracciabile. Questo aiuta in caso di interruzioni future, audit, casi di supporto e nella prossima finestra di manutenzione. Subito dopo l’aggiornamento, non si dovrebbe solo annotare “funziona di nuovo”, ma assicurarsi prove concrete.
Prove sensate:
| Prova | Perché è importante |
|---|---|
Screenshot di Backup & Firmware > Firmware | mostra la versione di destinazione, il firmware attivo e le eventuali immagini disponibili |
Screenshot di System services > High availability | mostra il ruolo HA, la sincronizzazione e lo stato del cluster dopo l’aggiornamento |
| Esportazione o screenshot dei log di audit rilevanti | mostra quali modifiche sono state apportate nella finestra di manutenzione |
| Controllo Central o Syslog | mostra se i log e i report arrivano ancora dopo l’aggiornamento |
| Elenco delle attività aperte | previene che workaround temporanei vengano dimenticati permanentemente |
Se sono state apportate modifiche a regole, interfacce, host o servizi, si dovrebbe inoltre verificare i Log di audit della configurazione. In ambienti con conservazione dei log più lunga, anche un controllo di Central Firewall Reporting o Syslog fa parte della conclusione.
In presenza di più firewall, è inoltre importante che i backup possano essere chiaramente associati. Nelle versioni SFOS più recenti, le email di backup contengono più dati di identificazione come nome host, versione firmware, numero di serie e modello. Tuttavia, si dovrebbe continuare a mantenere internamente una semplice nota di aggiornamento: firewall, posizione, vecchia versione, nuova versione, finestra temporale, persona responsabile, risultato del test e punti aperti.
Se dopo l’aggiornamento si notano avvisi su spazio di archiviazione, hardware o SSD, non dovrebbe essere trascurato nel ticket del firmware. Per questa verifica si adatta Verificare lo stato di salute dell’SSD su Sophos Firewall.
Checklist per la finestra di manutenzione
Prima dell’aggiornamento
- Verificato piattaforma e percorso di aggiornamento
- Letti note di rilascio e avvisi noti
- Esclusi nomi di interfacce con dieci o più cifre finali
- Verificato spazio di archiviazione e avvisi firmware
- Creato backup e salvato esternamente
- Secure Storage Master Key disponibile
- Stabilita decisione Go/No-Go, percorso di fallback e responsabili
- Documentato stato HA
- Documentato IPsec basato su policy, VPN-NAT e traffico di test, se utilizzati
- Verificato STAS e regole basate su utente, se utilizzati
- Escluso o migrato IPsec Remote Access legacy
- Definito piano di rollback
Durante l’aggiornamento
- Documentare i messaggi di stato
- Non effettuare modifiche parallele a routing, VPN o switching
- Osservare failover e sincronizzazione nei cluster HA
- Rispettare il punto decisionale per attesa, analisi degli errori o rollback
- Non confermare ciecamente messaggi inaspettati, ma verificare la causa
Dopo l’aggiornamento
- Verificare versione firmware e stato della licenza
- Testare VPN, routing, DNS, DHCP e regole firewall centrali
- Verificare IPsec basato su policy con test di origine/destinazione definito, se utilizzato
- Verificare STAS, AD SSO e regole basate su utente con utente di prova
- Verificare sincronizzazione HA e connessione Sophos Central
- Controllare Log Viewer e log dei servizi rilevanti
- Assicurare prove di firmware, HA e audit
- Documentare risultato e punti aperti nel diario operativo