Vai al contenuto
Avanet

Creare o ripristinare un backup di Sophos Firewall

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.

Il video mostra backup e restore su Sophos Firewall e integra le indicazioni pratiche di recovery dell'articolo.

Percorso di recovery e requisiti

Scegliere il percorso di recovery adatto

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

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 pubblica di SFOS 22 si contraddice sul Factory Reset: la pagina specifica del reset afferma che l’SSMK non viene cancellato, mentre la pagina generale del firmware ne indica la rimozione. Per questo motivo la chiave deve essere salvata esternamente prima di ogni reset e il suo stato verificato dopo, senza fare affidamento sulla sua disponibilità. Un reimage rimuove chiaramente l’SSMK corrente; secondo Sophos, Boot with factory default configuration nella vista Firmware lo conserva. Un rollback del firmware attiva lo stato di configurazione della partizione precedente. La cronologia delle chiavi conservata resta necessaria per ciascuno di questi percorsi.

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.

Prima del reset, salvare esternamente un backup corrente, la relativa password e il precedente SSMK. 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 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
Creare un backup della configurazione SFOS
Sophos Firewall Backup & Restore: creare un backup manuale e configurare backup pianificati

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.

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 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

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 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 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.

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 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 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 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.

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 Central. Registrare nuovamente entrambi i firewall in Sophos Central 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