Creare o ripristinare un backup di Sophos Firewall

Un backup di Sophos Firewall è la base per aggiornamenti firmware, sostituzioni hardware, reimage, operazioni HA e migrazioni. Il file da solo, tuttavia, non basta: per un restore affidabile servono anche la password del backup, il Secure Storage Master Key (SSMK) corretto, una versione target compatibile e un accesso management funzionante.

⚠️ Importante: Prima di un cambiamento rischioso, il file di backup, la password, l’SSMK, la versione target, l’IP di management e la procedura di restore devono essere reperibili e verificati. Un backup presente solo localmente sul firewall o privo della relativa chiave non costituisce una via di ritorno affidabile.

Percorso di recovery e requisiti

Scegliere il percorso di recovery adatto

Un restore non è la prima misura corretta per ogni problema:

• Pianificare un aggiornamento firmware: Aggiornamento firmware di Sophos Firewall: preparazione e best practice.
• Installare il firmware in WebAdmin: Eseguire un aggiornamento firmware di Sophos Firewall.
• Un task Central è bloccato: Verificare la Task Queue di Sophos Central Firewall Management.
• Reinstallare completamente SFOS: Reinstallare Sophos Firewall OS tramite chiavetta USB.
• Guasto hardware o RMA: Aprire un ticket di supporto Sophos.
• Ripristinare un cluster HA: Varianti di cluster HA di Sophos Firewall.

Prima di un reimage è quasi sempre necessario un backup da ripristinare. Un firmware rollback, invece, non sostituisce un backup, perché lo slot del firmware e lo stato di configurazione salvato rappresentano percorsi di recovery distinti.

Password del backup e Secure Storage Master Key

I backup attuali di Sophos Firewall sono cifrati con una password. Se il backup è stato creato dopo aver configurato l’SSMK, il restore richiede la password del backup e anche l’SSMK valido in quel momento.

L’SSMK protegge informazioni sensibili come password, secret e chiavi. Viene configurato dall’account admin predefinito e deve essere conservato in un password manager o in un altro processo di recovery protetto. Almeno due persone autorizzate devono sapere dove si trova.

Se l’SSMK viene modificato in seguito, i backup precedenti restano associati alla vecchia chiave. Per questo motivo, le versioni attuali e precedenti dell’SSMK devono essere conservate indicando il relativo periodo e firewall.

I backup legacy senza SSMK possono essere ripristinati senza Master Key. Se si ripristina un backup pianificato senza SSMK, la pianificazione salvata continua a funzionare, ma la frequenza può essere modificata solo dopo aver configurato un SSMK. Subito dopo è necessario creare un nuovo backup manuale.

Pacchetto di recovery per firewall

Oltre al backup, per ogni sede o tenant deve essere disponibile un pacchetto di recovery protetto:

• ultimo backup verificato con data e finalità
• password del backup e SSMK attuale e precedenti
• nome del firewall, numero di serie, modello e versione di SFOS
• credenziali WAN, informazioni del provider e Default Gateway
• assegnazione di interfacce, VLAN, LAG, bridge e porte HA
• accesso amministratore locale e break-glass
• assegnazione della licenza e di Sophos Central
• servizi critici con test di accettazione concreti

Backup e credenziali non devono essere conservati insieme senza protezione. Il pacchetto di recovery deve essere aggiornato dopo modifiche al personale, al provider, alle porte, ad HA o alla sede.

Creare e gestire i backup in sicurezza

Backup manuale prima delle modifiche

Backup & Firmware > Backup & Restore

Backup Now crea immediatamente un backup. Successivamente, il file deve essere salvato esternamente e documentato almeno con nome del firewall, numero di serie, versione di SFOS, data e finalità della modifica.

Un backup manuale è particolarmente importante prima di:

• modifiche a firmware, interfacce, VLAN, routing, SD-WAN o VPN
• configurazione HA, cambi di ruolo o manutenzione del cluster
• modifiche importanti alle regole NAT, WAF o firewall
• reimage, Factory Reset, sostituzione hardware o migrazione della piattaforma

Per modifiche più estese, Sophos Firewall Config Studio può inoltre evidenziare le differenze di configurazione. Un confronto di Entities.xml, tuttavia, non sostituisce un backup da ripristinare.

Se occorre trasferire o modificare solo una parte di configurazione chiaramente delimitata, esportare e importare selettivamente la configurazione descrive il flusso WebAdmin separato. Anche questo import non sostituisce il percorso di recovery completo.

Backup automatici

In Frequency si possono configurare backup giornalieri, settimanali o mensili. A seconda della configurazione, le destinazioni disponibili sono l’archiviazione locale, FTP e l’e-mail.

Aspetti importanti per l’operatività:

• Un backup locale non è utile se l’appliance si guasta o viene reinstallata.
• Sul firewall rimane solo l’ultimo backup locale; le versioni precedenti necessarie devono essere salvate esternamente.
• I backup FTP ed e-mail si considerano funzionanti solo dopo un test effettivo di consegna, recupero e decifratura.
• Non utilizzare caratteri speciali in Backup prefix, nel nome utente FTP o nella password senza averli verificati.
• I backup automatici non sostituiscono un backup manuale recente subito prima di un cambiamento rischioso.
• Il periodo di conservazione, l’accesso e il processo di eliminazione devono essere adeguati ai requisiti di protezione della configurazione.

I backup del firewall contengono informazioni riservate su reti, regole, VPN, certificati e dati degli account. L’accesso deve essere limitato agli amministratori e ai responsabili del recovery; password e SSMK restano separati, ma devono essere reperibili in caso di emergenza.

Backup di Sophos Central

Sophos documenta attualmente due percorsi di navigazione in Central, a seconda della vista e della pagina della guida:

Global Settings > Products and Services > Firewall
My Products > Firewall Management > Backup

Il firewall deve essere connesso a Sophos Central e abilitato per i backup della configurazione. Connettere Sophos Firewall a Sophos Central descrive la configurazione della connessione.

Verificare sempre esplicitamente la pianificazione, senza presupporre un valore predefinito. Se il primo firewall viene aggiunto automaticamente a una pianificazione vuota impostata su Never, Central può modificarla una sola volta in Monthly e nel primo giorno del mese. Le pianificazioni esistenti non vengono modificate.

Altre proprietà fisse:

• I backup vengono eseguiti alle 08:00 nel fuso orario della regione Central; l’orario non è modificabile.
• Central tenta la creazione fino a cinque volte, poi genera un alert e un’e-mail all’amministratore.
• Vengono conservati i cinque backup più recenti; inoltre, è possibile archiviare in modo permanente esattamente un backup.
• Al momento del download, il backup viene nuovamente cifrato con una nuova password.
• Se il firewall viene rimosso da Central Management, Sophos elimina i relativi backup Central. Prima di cambiare account, effettuare un RMA o ripulire il tenant, scaricare i file necessari.
• In HA, Primary e Auxiliary vengono aggiunti alla pianificazione, ma il backup viene creato dal Primary.

Se un firewall registrato non compare nella pianificazione, aggiungerlo in Schedule Backup. Se Send configuration backup to Sophos Central è già attivo, deselezionare la casella, applicare, selezionarla nuovamente, applicare ancora e infine accettare in Central l’autorizzazione del servizio in sospeso.

Central è una valida destinazione di archiviazione aggiuntiva, ma non sostituisce l’SSMK, l’accesso locale, i dati WAN e una copia del backup accessibile in modo indipendente.

Preparare ed eseguire un restore

Preparazione e test di restore sicuro

Prima del restore, verificare quanto segue:

• sono disponibili il file di backup corretto, la password e l’SSMK valido in quel momento
• versione di origine, versione target, modello e piattaforma sono compatibili
• un backup dello stato attuale della configurazione è salvato esternamente
• sono noti l’IP di management contenuto nel backup e l’accesso locale
• i dati WAN, NTP, DNS, della licenza e di Central sono documentati
• la destinazione HA e la sequenza di restore sono definite
• il mapping delle interfacce e le diverse assegnazioni delle porte sono stati preparati

⚠️ Attenzione: Un restore sovrascrive la configurazione attuale e riavvia il firewall. Un avviso relativo a un percorso di migrazione non supportato non deve essere confermato automaticamente; il firewall potrebbe successivamente avviarsi con la configurazione di fabbrica.

Un test di restore effettivo deve essere eseguito su un firewall di laboratorio o sostitutivo adeguato. Prima del test, disattivare o isolare le connessioni WAN, VPN e Central di produzione per evitare conflitti di indirizzi, tunnel o registrazioni duplicate.

Se non è disponibile un dispositivo di test, si può eseguire almeno una prova organizzativa: recuperare il backup dall’archivio previsto, verificarne l’assegnazione, confermare password e SSMK, valutare la piattaforma target e simulare nel runbook l’accesso management e i test di accettazione. Questo non sostituisce un vero restore, ma elimina molti problemi tipici delle emergenze.

Ripristinare un backup

Backup & Firmware > Backup & Restore

1. Accedere al firewall target tramite WebAdmin.
2. Salvare lo stato attuale, se ancora possibile.
3. In Restore configuration, selezionare il file di backup con Choose file.
4. Inserire Encryption password e, per un backup protetto da SSMK, anche l’SSMK valido in quel momento.
5. Avviare Upload and Restore.
6. Attendere il riavvio e il ripristino.
7. Aprire WebAdmin tramite l’IP di management contenuto nel backup.
8. Verificare il fuso orario, NTP e l’ora corrente.
9. Validare rete, servizi, VPN, HA e la connessione a Central.

Il restore elimina il backup archiviato localmente sul firewall target. Il file utilizzato deve quindi rimanere disponibile esternamente. Su una nuova appliance, completare prima il setup wizard e poi ripristinare il backup.

Cosa non risolve automaticamente un restore

• La password dell’account admin predefinito non viene ripristinata dal backup; il firewall target conserva la password esistente. Se è stata persa, l’articolo separato sulla recovery della password spiega la recovery seriale per le appliance fisiche e i limiti dei firewall virtuali e cloud.
• Dopo il riavvio, l’IP di management, Device Access, le route e i servizi provengono nuovamente dal backup.
• Fuso orario, NTP e ora devono essere verificati come stato operativo corrente.
• I valori dipendenti dal modello o dall’istanza possono tornare ai valori predefiniti se non sono adatti al target.
• Sophos Central rimane registrato solo se il restore viene eseguito sullo stesso firewall. Un firewall diverso o un cluster HA deve essere registrato nuovamente; in seguito verificare Security Heartbeat, ZTNA, Central Management, Backup, Reporting, Task Queue e l’assegnazione ai gruppi.
• Log, report e dati di monitoraggio esterni non fanno parte di un rollback completo della configurazione.

Durante una migrazione alla modalità FIPS 140-3, anche lo stato del backup è determinante: Un backup con FIPS disattivato ripristina lo stato senza FIPS ed è quindi un percorso di ritorno, non un trasferimento invariato alla modalità FIPS.

Restore su altro hardware e altre piattaforme

Compatibilità e versioni di SFOS

Prima di una migrazione, annotare la versione di origine, la versione target, il modello target e la piattaforma. Il Backup-restore compatibility check fa ora parte di Sophos Firewall Config Studio. Aprire Backup-restore compatibility e verificare la compatibilità dei modelli XG/XGS, dei moduli Flexi Port e dei transceiver utilizzati. Lo strumento è valido per SFOS 20.0 MR2 e versioni successive; considerare inoltre le informazioni sugli upgrade nelle release notes attuali e le indicazioni in SFOS 22 Upgrade Check.

Per SFOS 22 si applicano limiti rigidi:

• SFOS 22.0 GA e versioni successive non supportano hardware XG o SG.
• I backup con legacy CLI VLAN tagging su interfacce bridge non possono essere ripristinati su SFOS 22.0 GA o versioni successive. La procedura di pulizia è descritta in Verificare le Bridge VLAN prima di SFOS 22.
• Legacy Remote Access IPsec blocca l’upgrade a SFOS 22.0 MR1 e versioni successive. Durante il restore o l’import su queste versioni, la vecchia configurazione non viene migrata; è necessario passare prima al metodo supportato. La procedura è descritta in Migrare Legacy Remote Access IPsec.

Backup-Restore Assistant e mapping delle interfacce

L’Assistant viene visualizzato solo se sono soddisfatte tutte le condizioni:

• Il backup proviene da XG, SG con SFOS, XGS, virtuale o Cloud con SFOS 19.5 MR4 o versioni successive.
• Il target esegue SFOS 20.0 MR2 o versioni successive.
• Il target è un’appliance XGS, virtuale o Cloud.

L’Assistant non compare su target XG o SG né con backup di SFOS 19.5 MR3 o versioni precedenti. In questi casi il firewall esegue automaticamente il mapping; successivamente occorre controllare con particolare attenzione interfacce, zone, gateway, VLAN, HA-Link, SD-WAN, NAT e VPN.

L’Assistant può essere utilizzato anche sulla stessa appliance compatibile per spostare VLAN o configurazioni delle interfacce su un’altra porta fisica.

Interfacce fisiche e logiche

• Porta fisica: eseguire deliberatamente il mapping su una porta target oppure non mapparla; verificare cablaggio, zona e funzione WAN/LAN.
• VLAN o alias: segue l’interfaccia parent mappata; la parent port deve essere corretta dal punto di vista operativo.
• LAG o bridge: viene ricreato dalle porte fisiche mappate; controllare il numero di member e la configurazione dello switch.
• RED o Cellular: viene migrata la configurazione associata; testare in modo mirato la connessione dopo il restore.

Pseudo-port, breakout, management e HA

• Pseudo-port: conserva la configurazione ma non gestisce traffico. Spostare routing, NAT, VLAN e regole su una porta attiva.
• Breakout Root Port: è possibile mappare solo le root port, non i singoli member. Il target richiede un numero e una combinazione di porte supportati.
• Management-Port: viene mappata su una Management-Port disponibile oppure conservata come Pseudo-Port. Pianificare in anticipo la rete di management e l’accesso locale.
• Dedicated HA-Link: il tipo di porta deve rimanere invariato; l’Assistant non può modificare la porta HA-Link. Per LAG deve coincidere il numero di member, per VLAN il VLAN ID e per le monitored port lo stato target.

Prima di eliminare una Pseudo-Port, spostare tutte le route e le configurazioni NAT, firewall e VLAN dipendenti. Quindi, in Network > Interfaces, impostare la zona su None e riavviare il firewall durante una finestra di manutenzione. Infine verificare che la porta sia stata rimossa; le Pseudo-Port non associate con una configurazione VLAN non vengono eliminate automaticamente.

Il Backup-Restore Assistant riassegna le interfacce, ma non rende compatibile una configurazione Wireless o bridge non supportata sul target. Queste dipendenze devono essere corrette sull’origine prima di creare il backup di migrazione oppure ripianificate per il target.

Target HA, Wireless, virtuali e Cloud

Per conservare la configurazione HA, un backup HA può essere ripristinato solo su un cluster HA. È possibile configurare prima il nuovo cluster e ripristinare il backup sul Primary, oppure eseguire prima il restore e configurare HA successivamente. In seguito, verificare ruoli, versione firmware, Dedicated HA-Link e monitored port.

Le migrazioni Wireless hanno limiti aggiuntivi:

• Per Wireless-to-Non-Wireless, è necessario rimuovere le Wireless Networks prima del backup.
• I backup dei modelli Gen.2 XGS Wireless non possono essere ripristinati su modelli XG o Gen.1 XGS Wireless.
• Per la migrazione di modelli Wireless meno recenti a Gen.2 XGS si applicano ulteriori limiti per SSID, WPA, bridge mode e bande radio.

LocalWiFi e configurazioni bridge durante la migrazione

Al restore di un backup da XG Wireless o Gen.1 XGS Wireless su un modello Gen.2 XGS W si applicano i seguenti requisiti e limitazioni:

• A LocalWiFi0 e LocalWiFi1 sono assegnati solo SSID con almeno WPA2.
• La cifratura non utilizza né TKIP né TKIP/AES.
• Nessuna interfaccia Wireless è membro di un bridge fisico.
• LocalWiFi0 e LocalWiFi1 utilizzano complessivamente al massimo otto SSID univoci.
• Se entrambe le radio utilizzano la stessa banda di frequenza, vengono ripristinate solo le impostazioni di LocalWiFi0.

La differenza tra i bridge è determinante. Per una Wireless Network di tipo Bridge to AP LAN, i modelli Gen.1 XGS 87w, 107w, 116w, 126w e 136w collegano la WLAN locale alla LAN tramite un bridge fisico. I modelli Gen.2 XGS 88w, 108w, 118w e 128w non supportano questo design; su questi modelli si utilizza Bridge to Ethernet con esattamente una porta Ethernet e la zona LAN in Wireless > Access points > LocalWiFi > Advanced settings. Configurare la WLAN direttamente su Sophos Firewall descrive la configurazione su Gen.2.

Se il backup Gen.1 contiene ancora un bridge fisico con l’interfaccia di una Wireless Network di tipo Bridge to AP LAN, il restore su Gen.2 non riesce. Sophos elenca questo comportamento come Known Issue NC-135094. Se OSPF, OSPFv3, RIP, SPX Portal Setting o Quarantine fanno riferimento a questa interfaccia, il restore viene completato, ma la configurazione dipendente non funziona su Gen.2.

Prima di creare il backup di migrazione, verificare in Network > Interfaces se un’interfaccia Wireless fa parte di un bridge e documentare tutte le impostazioni dipendenti. Non eliminare un bridge di produzione senza preparazione: migrare prima l’indirizzo IP, la zona, DHCP, le porte collegate e le dipendenze di routing a un design compatibile con Gen.2 durante una finestra di manutenzione. Creare quindi un nuovo backup. Configurare Bridge to Ethernet sul target e testare in modo mirato gli SSID, il Security mode, le bande di frequenza, DHCP e i servizi che in precedenza dipendevano dall’interfaccia.

Prima di una migrazione da XG a XGS è utile anche il confronto tra XG e XGS.

Per i firewall virtuali e Cloud, il processo integrato di backup e restore di Sophos è l’unico percorso di recovery SFOS supportato. Sophos non supporta snapshot dell’hypervisor, immagini Cloud o backup di terze parti per questo scopo, poiché possono causare problemi di integrità dei dati o configurazioni non supportate.

Validare dopo il restore

Controllo tecnico

Subito dopo il restore, verificare:

• IP di WebAdmin, reti di management consentite e Device Access
• interfacce, zone, VLAN, bridge, LAG e interfacce alias
• WAN, PPPoE, Default Gateway, route statiche e route SD-WAN
• regole firewall, NAT e WAF, incluso il relativo ordine
• IPsec, SSL VPN, Sophos Connect, RED e Remote Access
• certificati, TLS Inspection, DNS, DHCP, NTP e Authentication Server
• stato HA, ruoli e sincronizzazione
• stato della licenza, Pattern Updates, Hotfixes e sincronizzazione con Central
• Log Viewer, Syslog, Central Reporting e reporting locale

A seconda dell’errore, possono essere utili Log Viewer, Policy Test e Packet Capture, Packet Capture in WebAdmin e la panoramica Services and Logs. Sophos non indica un percorso dei log SSH universale e affidabile per gli errori generali di restore; qui non viene quindi suggerito alcun comando shell.

Test di accettazione

Un WebAdmin raggiungibile non dimostra che il traffico di produzione funzioni. Per ogni sede devono essere documentati origine concreta, target, regola prevista e voce di log prevista per questi test:

• Management: accesso dalla rete di management e secondo login amministratore.
• Internet: un client di test raggiunge un target esterno definito attraverso la regola, il NAT e la route WAN corretti.
• DNS e DHCP: un client riceve un indirizzo e risolve nomi interni ed esterni.
• Site-to-Site VPN: gli host definiti sono raggiungibili in entrambe le direzioni.
• Remote Access: un utente di test verifica login, MFA, profilo, DNS e un target interno.
• WAF o DNAT: un test esterno conferma certificato, regola, backend e logging.
• Autenticazione: AD, LDAP, RADIUS, STAS o Entra SSO riconosce correttamente un utente di test.
• Logging: il traffico di test è visibile in Log Viewer, Syslog, Central Reporting o SIEM.
• HA: ruoli, stato del cluster e sincronizzazione corrispondono al piano.

Se WAN, DNS, Remote Access o HA non funzionano, non modificare contemporaneamente più aree. Circoscrivere l’errore con orario, origine del test, target, regola ed estratto del log, quindi ripetere il test dopo ogni correzione.

Troubleshooting e operatività

Errori tipici

• Il backup si trova solo sul firewall: non è disponibile in caso di guasto o reimage; salvarlo esternamente e in modo protetto.
• L’SSMK manca: i dati protetti non possono essere ripristinati; documentare le chiavi attuali e precedenti.
• File senza riferimento al dispositivo o alla versione: viene selezionato il backup sbagliato; annotare nome del firewall, numero di serie, versione e data.
• Nessun backup dello stato attuale prima del restore: manca una via di ritorno allo stato precedente.
• IP di management ripristinato sconosciuto: il firewall sembra offline; documentare prima l’indirizzo e l’accesso locale.
• Orario o NTP errati: VPN, certificati, autenticazione e Central possono non funzionare.
• Confermato un percorso di restore non supportato: il restore non riesce o il target si avvia con la configurazione di fabbrica.
• Mapping delle interfacce non verificato: WAN, VLAN, VPN o HA-Link finiscono sulle porte sbagliate.
• Limiti Wireless ignorati: il backup è incompatibile o la configurazione wireless non funziona come previsto.
• Contesto HA ignorato: la configurazione o i ruoli del cluster vanno persi oppure si avviano in modo errato.
• Central è l’unica copia: rimuovendo il firewall da Central vengono eliminati anche i relativi backup.
• Verificato solo WebAdmin: i malfunzionamenti di routing, NAT, VPN, WAF, DNS o logging non vengono rilevati.

Ciclo operativo

Regolarmente:

• verificare backup automatici, consegna, recupero e conservazione
• controllare archiviazione dei backup, autorizzazioni e SSMK attuali e precedenti
• mantenere aggiornati il pacchetto di recovery e i test di accettazione
• verificare a campione file, password, SSMK e compatibilità del target

Prima di modifiche importanti:

• creare un backup manuale, salvarlo esternamente ed etichettarlo in modo univoco
• definire accesso management, procedura di restore e criteri di interruzione
• per le migrazioni, verificare compatibilità, versione di SFOS e mapping delle interfacce

Dopo un restore:

• documentare completamente il controllo tecnico e i test di accettazione
• correggere le deviazioni e, se necessario, confrontarle con Config Studio
• creare un nuovo backup dello stato target verificato e aggiornare il pacchetto di recovery