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 Fusion è bloccato: Verificare la Task Queue di Sophos Fusion 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.

La guida SFOS 22/23 si contraddice sul Factory Reset: la pagina specifica e Device Management > Reset to factory defaults descrivono la conservazione dell’SSMK; Control center e la sezione generale Firmware ne descrivono la rimozione. Anche Boot with factory default configuration è descritto espressamente come capace di conservare la chiave. Non è una garanzia per un metodo e un build specifici. Prima di ogni reset salvare esternamente backup, password e SSMK correnti e precedenti, poi verificare lo stato della chiave. Se il recupero dipende dalla sua conservazione, chiarire metodo e build con Sophos Support prima del reset; non eseguire un reset per scoprirlo. Preparare un Factory Reset in sicurezza spiega i singoli percorsi. Secondo la guida Firmware, un reimage rimuove l’SSMK corrente. Il rollback attiva la configurazione della partizione precedente; anche qui resta necessaria la cronologia delle chiavi.

Prima di creare un nuovo backup manuale o pianificato deve essere configurato un SSMK. In una nuova installazione si crea nel Setup Assistant. Se un firewall senza SSMK è stato aggiornato a SFOS 20.0, la chiave si crea in Control center con l’account admin predefinito. Gli altri amministratori vedono l’avviso, ma non possono creare la chiave con i propri account.

L’SSMK viene sincronizzato tra entrambi i dispositivi HA sia in active-active sia in active-passive. Disattivando HA su uno dei dispositivi, la chiave rimane su entrambi; anche un dispositivo standalone conserva il proprio SSMK. In active-passive la chiave può essere impostata o reimpostata solo tramite il Primary. Una modifica HA non sostituisce quindi la conservazione esterna della cronologia delle chiavi.

Reimpostare l’SSMK solo come modifica break-glass pianificata

Il Secure Storage Master Key può essere reimpostato tramite CLI solo con il Super Administrator predefinito admin. L’opzione di menu compare solo dopo la creazione di un SSMK. Un altro amministratore non può eseguire questa modifica.

⚠️ Il nuovo SSMK non può decifrare i vecchi backup creati con la chiave precedente. Un reset non sostituisce quindi né la cronologia delle chiavi conservata né il vecchio SSMK. Questa operazione non è un test privo di rischi.

Un SSMK perso non è recuperabile: il reset crea una nuova chiave, ma non recupera quella persa. Prima del reset salvare esternamente un backup corrente e la password; salvare anche l’SSMK precedente se ancora disponibile. Se manca, documentare che il backup non può essere ripristinato senza la chiave originale. La nuova chiave permette solo un nuovo backup dopo il reset, non il recupero tramite il vecchio file. Passare quindi a 2. System Configuration > 5. Reset secure storage master key:

1. Inserire la password dell’admin predefinito.
2. Inserire il nuovo SSMK.
3. Reinserire la nuova chiave per confermarla.

La nuova chiave deve contenere almeno 12 caratteri, tra cui almeno una lettera maiuscola, una minuscola, una cifra e uno dei caratteri speciali supportati da SFOS:

! # $ % & ( ) * + , - . / : ; < = > ? @ [ ] ^ _ ` { | } ~

Salvarla immediatamente con firewall, numero di serie e data di attivazione nel sistema di recovery protetto, mai in un ticket, uno screenshot o la cronologia della shell.

Dopo il reset, creare immediatamente un nuovo backup manuale e salvarlo esternamente. Verificare inoltre i backup pianificati, le credenziali memorizzate, le VPN, i certificati, la connessione Central e l’accesso di gestione. Conservare i backup precedenti insieme al rispettivo SSMK; la nuova chiave non li rende ripristinabili.

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 Fusion (in precedenza 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.

In Download è possibile scegliere Download encrypted backup oppure Encrypt backup with a different password before you download. La seconda password vale solo per la copia scaricata; non modifica la Encryption password memorizzata per i backup successivi. Il file e la password effettivamente utilizzata devono quindi essere associati in modo univoco al pacchetto di recovery.

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.

Salvare le impostazioni del backup

Prima del primo backup, configurare l’SSMK come descritto sopra e salvare esternamente gli eventuali backup esistenti necessari. In Backup & Firmware > Backup & Restore, salvare le impostazioni della destinazione prevista:

1. Scegliere la destinazione in Backup mode: Local salva sul firewall; FTP ed Email salvano anche localmente e inviano il file alla destinazione scelta. Per FTP, inserire l’indirizzo IPv4 o IPv6 del server, nome utente, password e FTP path. Per Email, indicare l’indirizzo e-mail del destinatario autorizzato. Server, account, directory e destinatario devono corrispondere all’archivio protetto della propria organizzazione.
2. Impostare in Backup prefix un identificativo univoco del firewall e scegliere la frequenza desiderata in Frequency. La sezione sui backup automatici spiega i limiti dei caratteri e la conservazione.
3. Impostare Encryption password, oppure modificare una password esistente con Change encryption password. Associare la password al relativo backup nell’archivio di recovery protetto; i file precedenti richiedono ancora la loro password originale.
4. Fare clic su Apply per salvare le impostazioni prima di creare il backup configurato o utilizzare la pianificazione.
5. Ricontrollare modalità, destinazione e frequenza salvate. Al backup successivo verificare poi l’invio o il salvataggio locale, il recupero e la decifratura. In caso di errore, controllare prima l’indirizzo di destinazione, il percorso FTP, i permessi o il destinatario; una pianificazione salvata non dimostra da sola che un backup sia riuscito.

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.
• SFOS 22 limita Backup prefix a 32 caratteri e non accetta, tra gli altri, /, \, :, *, ?, ", <, >, |, ~, `, .. o lettere UTF-8 non inglesi. Il nome utente FTP non può contenere \; gli unici caratteri speciali supportati nel nome utente e nella password FTP sono @, / e $. Il nome host nell’oggetto di un backup inviato via e-mail è limitato a 25 caratteri.
• 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 Fusion

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 Fusion e abilitato per i backup della configurazione. Connettere Sophos Firewall a Sophos Fusion descrive la configurazione della connessione. L’opzione Send configuration backup to Sophos Central richiede Use Sophos Central management. Un Super admin del tenant Sophos Fusion interessato completa l’approvazione; i permessi locali WebAdmin o la registrazione OTP non la sostituiscono.

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 Sophos Fusion l’autorizzazione del servizio in sospeso. Un Super admin del tenant Sophos Fusion interessato completa l’approvazione; i permessi locali WebAdmin o la registrazione OTP non la sostituiscono.

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.

Se Sophos Support richiede un backup protetto da SSMK per un caso specifico, per leggere il file servono la password di cifratura effettivamente utilizzata e l’SSMK corrispondente di quel momento. Confermare prima lo scopo del caso e il destinatario autorizzato tramite il flusso di supporto esistente. Solo dopo fornire entrambi i segreti attraverso un canale protetto concordato per trasferirli, separato dal file di backup. Non inserirli mai nel testo del ticket, in screenshot o in normali allegati. Non è un’indicazione generale a condividere credenziali amministrative.

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.

L’SSMK inserito durante il restore serve solo ad aprire il backup. Non sostituisce l’SSMK proprio del firewall di destinazione. Dopo i test di accettazione, creare un nuovo backup dello stato di destinazione e associarlo nel pacchetto di recovery all’SSMK del target e alla password del backup effettivamente utilizzata. Un restore riuscito non significa che le chiavi di origine e destinazione siano identiche; per questo non serve reimpostare l’SSMK.

Cosa non risolve automaticamente un restore

Ad eccezione della password dell’account admin predefinito, SFOS ripristina la configurazione, inclusi i token MFA di tutti gli utenti, gli utenti VPN, RED, le configurazioni VPN site-to-site e remote access e Sophos Connect. Anche ApplianceCertificate, Default CA, SecurityAppliance_SSL_CA e le pre-shared key provengono dal backup. Non appena routing e interfacce tornano attivi, queste relazioni di trust e i tunnel possono tornare operativi. Un restore di laboratorio deve quindi rimanere isolato fino alla verifica di VPN, RED, certificati, Central e reti di destinazione.

• 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.
• I valori personalizzati di data e ora sotto Administration > Time non sono inclusi nel backup. Vengono ripristinati solo il fuso orario e i server NTP; i valori temporali manuali devono essere riconfigurati e verificati dopo il restore.
• I valori dipendenti dal modello o dall’istanza possono tornare ai valori predefiniti se non sono adatti al target. Sophos indica come esempio il numero di istanze IPS: Se viene modificato per il modello di destinazione durante il restore, il target applica il proprio default invece del valore del backup.
• Sophos Fusion 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 e XGS Appliance, 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.

Per destinazioni con SFOS 20.0 MR2 o successivo valgono anche questi limiti di formato. Desktop indica le appliance da tavolo, 1US e 1UL i modelli rack 1U più piccoli e più grandi rispettivamente, e 2U i modelli rack 2U; verificare il formato del modello specifico in Compatibility Check. Conta la direzione origine → destinazione:

• Desktop → Desktop, 1US/1UL, 2U o virtuale: consentita in linea di principio dalla matrice.
• 1US → Desktop: consentita solo su XGS 126/126w, XGS 136/136w, XGS 128/128w o XGS 138. 1US → 1US/1UL, 2U o virtuale è consentita in linea di principio.
• 1UL o 2U → Desktop: non consentita. 1UL o 2U → 1US/1UL, 2U o virtuale è consentita in linea di principio.
• Virtuale → Desktop, 1US/1UL, 2U o virtuale: consentita in linea di principio.

Una direzione consentita dalla matrice non autorizza ogni configurazione. Restano da verificare la versione SFOS, la coppia specifica di modelli, i limiti Wireless e bridge e i moduli delle porte. In particolare, i backup Desktop di XG o Gen.1 XGS ripristinati su Gen.2 XGS restano soggetti alle restrizioni Wireless descritte sotto. Un target con meno porte o l’Assistant non rende supportata una coppia di modelli vietata.

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, una XGS Appliance, virtuale o Cloud con SFOS 19.5 MR4 o versioni successive.
• Il target esegue SFOS 20.0 MR2 o versioni successive.
• Il target è una XGS Appliance, 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.

L’Assistant mostra solo porte fisiche per il mapping. Mostra insieme i modelli di origine e destinazione, i dettagli delle interfacce e i mapping disponibili. Passando il puntatore su un’interfaccia di origine, SFOS ne mostra indirizzo IP, subnet mask, tipo di assegnazione IP e link mode. Prima del mapping, questi valori vanno confrontati con il piano delle porte e il cablaggio; un nome di porta simile da solo non è un criterio sufficiente.

Per impostazione predefinita, SFOS mappa le porte equivalenti. Se la porta corrispondente non esiste sul dispositivo di destinazione, seleziona la porta disponibile successiva. Questa automazione è solo una proposta e va verificata; con Don’t map. Creates Pseudo port, la configurazione viene invece conservata intenzionalmente su una pseudo-port non funzionante.

Interfacce di origine non associate: durante il restore, SFOS non le mappa su porte di destinazione e non crea pseudo-port per esse. Fanno eccezione le interfacce non associate con configurazione VLAN. Considerare questa eccezione nel piano delle porte; è distinta dalle regole descritte sotto per eliminare pseudo-port già esistenti.

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. Configurare le interfacce breakout spiega creazione, riavvio e verifica.
• Management-Port: viene mappata per default sulla porta di management del target; se manca, la configurazione resta su una Pseudo-Port. Nel ripristino su XGS Appliances, firewall virtuali o Cloud, l’Assistant può anche mapparla su un’altra porta. Annotare prima IP di management, porta WebAdmin, credenziali e cablaggio di quella porta, preparare un accesso locale alternativo e verificare l’accesso dopo il riavvio. Una Pseudo-Port di management non offre accesso funzionante.
• 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.

Una pseudo-port ha lo stato Not available e normalmente il nome hardware Pseudo<port number>. Per i backup da SFOS 19.5 MR3 o precedenti può comparire il nome originale della porta, ma l’interfaccia resta non funzionante. Per il breakout, la destinazione deve avere configurato almeno lo stesso numero di breakout ports del backup. Vengono mappate solo le root ports; una porta fisica di origine può essere mappata su una breakout root port supportata.

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

Un backup che contiene una configurazione HA può essere ripristinato anche su un dispositivo standalone, ma in questo caso SFOS ripristina solo il resto della configurazione, non HA. Per mantenere HA, configurare prima il nuovo cluster e ripristinare il backup sul Primary corrente, oppure eseguire prima il restore e configurare HA in seguito. Non è possibile ripristinare un backup sull’Auxiliary.

In un cluster active-passive o active-active esistente, il Primary corrente si riavvia dopo il restore senza failover. Il restore causa quindi un’interruzione in entrambe le modalità HA. Se il backup contiene una configurazione HA, dopo il riavvio il Primary sincronizza l’Auxiliary. Il restore su un cluster HA annulla inoltre la registrazione di entrambi i firewall in Sophos Fusion. Registrare nuovamente entrambi i firewall in Sophos Fusion e, se il Primary era utilizzato come gateway Sophos ZTNA, aggiungerlo nuovamente come gateway. Se sul Primary corrente viene ripristinato un backup privo di configurazione HA, HA viene disattivato e deve essere riconfigurato. Controllare quindi in modo mirato ruoli, versione firmware, Dedicated HA-Link e monitored port.

Sophos distingue tre gruppi Wireless per questo restore: Gen.2 comprende XGS 88w, 108w, 118w e 128w; Gen.1 comprende XGS 87w, 107w, 116w, 126w e 136w; la serie XG comprende XG 86w, 106w, 115w, 125w e 135w. L’appartenenza a uno di questi gruppi determina la direzione di restore supportata; un nome di modello simile non è sufficiente.

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 un’XGS Appliance è utile anche il confronto tra XG e XGS Appliance.

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.

Secondo Sophos, un messaggio di errore dettagliato in WebAdmin è garantito solo per un percorso di restore più ristretto: Il backup proviene da un’appliance compatibile con SFOS 19.5 MR4 o successivo, la destinazione esegue SFOS 20.0 MR2 o successivo ed è un XGS 88/88w, 108/108w, 118/118w, 128/128w o 138. Su altre destinazioni, l’assenza di un messaggio nell’interfaccia non significa che non si sia verificato un errore. Vanno quindi registrati l’orario, le versioni di origine e destinazione, i modelli e l’azione di restore esatta, correlando poi questi dati con i log o un caso di supporto. Le revisioni hardware Rev.1, Rev.2 e Rev.3 seguono le stesse regole di compatibilità, ma la coppia di modelli concreta deve comunque essere verificata in Compatibility Check.

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