Hoppa till innehållet
Avanet

Sophos Firewall Skapa eller återställ säkerhetskopia

Sophos Firewall

En säkerhetskopia av Sophos Firewall är grunden för firmwareuppdateringar, hårdvarubyten, reimage, HA-arbeten och migreringar. Filen räcker dock inte ensam: en tillförlitlig återställning kräver även säkerhetskopians lösenord, rätt Secure Storage Master Key (SSMK), en kompatibel målversion och fungerande hanteringsåtkomst.

⚠️ Viktigt: Före en riskfylld ändring måste säkerhetskopieringsfilen, lösenordet, SSMK, målversionen, hanterings-IP-adressen och återställningsvägen vara tillgängliga och verifierade. En säkerhetskopia som endast finns lokalt på brandväggen eller vars nyckel saknas är ingen tillförlitlig återgångsväg.

Videon visar hur man skapar och återställer säkerhetskopior på Sophos Firewall och kompletterar de praktiska återställningsråden i artikeln.

Återställningsväg och krav

Välj rätt återställningsväg

En återställning är inte rätt första åtgärd för alla problem:

Före en reimage behövs nästan alltid en säkerhetskopia för återställning. En firmware-rollback ersätter däremot inte en säkerhetskopia, eftersom firmwareplatsen och det sparade konfigurationsläget är separata återställningsvägar.

Lösenord för säkerhetskopian och Secure Storage Master Key

Aktuella säkerhetskopior av Sophos Firewall krypteras med ett lösenord. Om säkerhetskopian skapades efter att SSMK hade konfigurerats kräver återställningen säkerhetskopians lösenord och det SSMK som gällde vid den tidpunkten.

SSMK skyddar känslig information som lösenord, secrets och nycklar. Det konfigureras av standardkontot admin och ska förvaras i en lösenordshanterare eller i en annan skyddad återställningsprocess. Minst två behöriga personer bör veta var det finns.

Om SSMK ändras senare förblir äldre säkerhetskopior kopplade till den tidigare nyckeln. Därför måste aktuella och tidigare SSMK-versioner sparas tillsammans med giltighetsperiod och brandväggstillhörighet.

Legacy backups utan SSMK kan återställas utan master key. Om en schemalagd säkerhetskopia utan SSMK återställs fortsätter det sparade schemat att köras, men frekvensen kan inte ändras förrän ett SSMK har konfigurerats. Skapa omedelbart därefter en ny manuell säkerhetskopia.

Återställningspaket per brandvägg

För varje plats eller tenant bör det utöver säkerhetskopian finnas ett skyddat återställningspaket:

  • senast verifierade säkerhetskopia med datum och syfte
  • säkerhetskopians lösenord samt aktuella och tidigare SSMK
  • brandväggens namn, serienummer, modell och SFOS-version
  • WAN-inloggningsuppgifter, operatörsinformation och default gateway
  • tilldelning av gränssnitt, VLAN, LAG, bridge och HA-portar
  • lokal administratörs- och break-glass-åtkomst
  • licens- och Sophos Central-tilldelning
  • kritiska tjänster med konkreta acceptanstester

Förvara inte säkerhetskopian och åtkomstuppgifterna oskyddade tillsammans. Uppdatera återställningspaketet efter ändringar av personal, operatör, portar, HA eller plats.

Skapa och hantera säkerhetskopior säkert

Manuell säkerhetskopia före ändringar

Backup & Firmware > Backup & Restore
Skapa en säkerhetskopia av SFOS-konfigurationen
Sophos Firewall Backup & Restore: skapa en manuell säkerhetskopia och konfigurera schemalagda säkerhetskopior

Backup Now skapar omedelbart en säkerhetskopia. Spara sedan filen externt och dokumentera åtminstone brandväggens namn, serienummer, SFOS-version, datum och ändringens syfte.

En manuell säkerhetskopia är särskilt viktig före:

  • ändringar av firmware, gränssnitt, VLAN, routing, SD-WAN eller VPN
  • HA-konfiguration, rollbyte eller klusterunderhåll
  • större ändringar av NAT-, WAF- eller brandväggsregler
  • reimage, factory reset, hårdvarubyte eller plattformsmigrering

Vid större ändringar kan Sophos Firewall Config Studio dessutom visa konfigurationsskillnader. En jämförelse av Entities.xml ersätter dock inte en säkerhetskopia för återställning.

Om endast en tydligt avgränsad konfigurationsdel ska överföras eller ändras beskriver selektiv export och import av konfiguration det separata WebAdmin-arbetsflödet. Inte heller denna import ersätter den fullständiga återställningsvägen.

Automatiska säkerhetskopior

Under Frequency går det att konfigurera dagliga, veckovisa eller månatliga säkerhetskopior. Beroende på konfigurationen finns lokal lagring, FTP och e-post som mål.

Viktiga driftpunkter:

  • En lokal säkerhetskopia hjälper inte om appliance-enheten går sönder eller installeras om.
  • Endast den senaste lokala säkerhetskopian finns kvar på brandväggen; äldre versioner som behövs måste lagras externt.
  • FTP- och e-postkopior räknas som fungerande först efter ett verkligt test av leverans, hämtning och dekryptering.
  • Använd inte specialtecken i Backup prefix, FTP-användarnamn eller lösenord utan att testa dem.
  • Automatiska säkerhetskopior ersätter inte en ny manuell säkerhetskopia omedelbart före en riskfylld ändring.
  • Lagringstid, åtkomst och raderingsprocess måste motsvara konfigurationens skyddsbehov.

Brandväggssäkerhetskopior innehåller konfidentiell information om nätverk, regler, VPN, certifikat och kontouppgifter. Åtkomsten bör begränsas till administratörer och återställningsansvariga; lösenordet och SSMK ska hållas åtskilda men vara möjliga att hitta i en nödsituation.

Säkerhetskopior i Sophos Central

Sophos dokumenterar för närvarande två navigeringsvägar i Central, beroende på vy och hjälpsida:

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

Brandväggen måste vara ansluten till Sophos Central och godkänd för konfigurationskopior. Anslut Sophos Firewall till Sophos Central beskriver hur anslutningen konfigureras.

Kontrollera alltid schemat uttryckligen i stället för att anta ett standardvärde. När den första brandväggen läggs till automatiskt i ett tomt schema inställt på Never kan Central en gång ändra det till Monthly och månadens första dag. Befintliga scheman ändras inte.

Andra fasta egenskaper:

  • Säkerhetskopior körs klockan 08:00 i Central-regionens tidszon; tiden kan inte ändras.
  • Central försöker skapa säkerhetskopian upp till fem gånger och genererar därefter ett alert och ett e-postmeddelande till administratören.
  • De fem senaste säkerhetskopiorna behålls; exakt en ytterligare säkerhetskopia kan sparas permanent.
  • Vid nedladdning krypteras säkerhetskopian på nytt med ett nytt tilldelat lösenord.
  • Om brandväggen tas bort från Central Management raderas dess säkerhetskopior i Central. Hämta nödvändiga filer före ett kontobyte, RMA eller en rensning av tenant.
  • Vid HA läggs Primary och Auxiliary till i schemat, men säkerhetskopian skapas av Primary.

Om en registrerad brandvägg inte visas i schemat ska den läggas till under Schedule Backup. Om Send configuration backup to Sophos Central redan är aktiverat, avmarkera kryssrutan, tillämpa, markera den igen, tillämpa på nytt och godkänn därefter det väntande tjänstegodkännandet i Central.

Central är en bra extra lagringsplats, men ersätter inte SSMK, lokal åtkomst, WAN-uppgifter och en oberoende åtkomlig kopia av säkerhetskopian.

Förbered och genomför en återställning

Förberedelse och säkert återställningstest

Bekräfta före återställningen att:

  • rätt säkerhetskopieringsfil, lösenord och dåvarande SSMK finns tillgängliga
  • källversion, målversion, modell och plattform är kompatibla
  • en säkerhetskopia av den aktuella konfigurationen har sparats externt
  • hanterings-IP-adressen från säkerhetskopian och den lokala åtkomsten är kända
  • WAN-, NTP-, DNS-, licens- och Central-uppgifter är dokumenterade
  • HA-mål och återställningsordning är fastställda
  • gränssnittsmappning och avvikande porttilldelningar är förberedda

⚠️ Observera: En återställning skriver över den aktuella konfigurationen och startar om brandväggen. En varning om en migreringsväg som inte stöds får inte bekräftas rutinmässigt; brandväggen kan därefter starta med factory configuration.

Genomför ett verkligt återställningstest på en lämplig laboratorie- eller ersättningsbrandvägg. Inaktivera eller isolera produktionsanslutningar för WAN, VPN och Central före testet för att undvika adresskonflikter, tunnlar eller dubbla registreringar.

Utan en testenhet är åtminstone ett organisatoriskt test möjligt: hämta säkerhetskopian från den avsedda lagringen, kontrollera tilldelningen, bekräfta lösenord och SSMK, bedöm målplattformen och gå igenom hanteringsåtkomst och acceptanstester i runbook. Det ersätter inte en verklig återställning men undanröjer många vanliga problem i nödsituationer.

Återställ en säkerhetskopia

Backup & Firmware > Backup & Restore
  1. Öppna målbrandväggen via WebAdmin.
  2. Spara det aktuella tillståndet om det fortfarande är möjligt.
  3. Välj säkerhetskopieringsfilen under Restore configuration med Choose file.
  4. Ange Encryption password och, för en SSMK-skyddad säkerhetskopia, även det SSMK som gällde vid den tidpunkten.
  5. Starta Upload and Restore.
  6. Vänta på omstart och återställning.
  7. Öppna WebAdmin via hanterings-IP-adressen från säkerhetskopian.
  8. Kontrollera tidszon, NTP och aktuell tid.
  9. Validera nätverk, tjänster, VPN, HA och Central-anslutning.

Återställningen raderar säkerhetskopian som lagras lokalt på målbrandväggen. Filen som används måste därför fortsätta att vara tillgänglig externt. På en ny appliance ska setup wizard först slutföras och säkerhetskopian därefter återställas.

Det som en återställning inte löser automatiskt

  • Lösenordet för standardkontot admin återställs inte från säkerhetskopian; målbrandväggen behåller sitt befintliga lösenord. Om det har gått förlorat återställs det separat via den seriella konsolen på en fysisk appliance. För virtuella brandväggar och cloud-brandväggar måste plattformskonsolen och den återställningsväg som stöds kontrolleras.
  • Efter omstarten kommer hanterings-IP, Device Access, routes och tjänster åter från säkerhetskopian.
  • Tidszon, NTP och tid måste kontrolleras som aktuellt drifttillstånd.
  • Modell- eller instansberoende värden kan återgå till defaults om de inte passar målet.
  • Sophos Central förblir bara registrerat vid återställning till samma brandvägg. En annan brandvägg eller ett HA-kluster måste registreras på nytt; kontrollera därefter Security Heartbeat, ZTNA, Central Management, Backup, Reporting, Task Queue och grupptilldelning.
  • Logs, reports och externa övervakningsdata ingår inte i en fullständig rollback av konfigurationen.

Vid en migrering till FIPS 140-3-läge är även backupens status avgörande: En backup med avstängt FIPS återställer tillståndet utan FIPS och är därför en returväg, inte en oförändrad överföring till FIPS-läge.

Återställ till annan hårdvara och andra plattformar

Kompatibilitet och SFOS-versioner

Anteckna källversion, målversion, målmodell och plattform före en migrering. Backup-restore compatibility check ingår nu i Sophos Firewall Config Studio. Öppna Backup-restore compatibility där och kontrollera kompatibiliteten för XG/XGS-modellerna samt de Flexi Port-moduler och transceivrar som används. Verktyget gäller för SFOS 20.0 MR2 och senare; ta dessutom hänsyn till uppgraderingsinformationen i aktuella release notes och SFOS 22 Upgrade Check.

För SFOS 22 gäller fasta begränsningar:

  • SFOS 22.0 GA och senare stöder inte XG- eller SG-hårdvara.
  • Säkerhetskopior med legacy CLI VLAN tagging på bridge interfaces kan inte återställas till SFOS 22.0 GA eller senare. Kontrollera Bridge VLAN före SFOS 22 beskriver rensningen.
  • Legacy Remote Access IPsec blockerar uppgraderingar till SFOS 22.0 MR1 och senare. Vid återställning eller import till dessa versioner migreras inte den gamla konfigurationen; byt först till den metod som stöds. Se Migrera Legacy Remote Access IPsec.

Backup-Restore Assistant och gränssnittsmappning

Assistant visas endast när alla villkor är uppfyllda:

  • Säkerhetskopian kommer från XG, SG med SFOS, XGS, virtual eller cloud med SFOS 19.5 MR4 eller senare.
  • Målet kör SFOS 20.0 MR2 eller senare.
  • Målet är en XGS-, virtual- eller cloud-appliance.

Assistant visas inte på XG- eller SG-mål eller för säkerhetskopior från SFOS 19.5 MR3 eller tidigare. Brandväggen mappar då automatiskt; kontrollera därefter gränssnitt, zones, gateways, VLAN, HA link, SD-WAN, NAT och VPN särskilt noggrant.

Assistant kan även användas på samma kompatibla appliance för att flytta VLAN eller gränssnittskonfigurationer till en annan fysisk port.

Fysiska och logiska gränssnitt

  • Fysisk port: mappa medvetet till en målport eller lämna omappad; kontrollera kablage, zone och WAN-/LAN-funktion.
  • VLAN eller alias: följer det mappade parent interface; parent port måste vara driftsmässigt korrekt.
  • LAG eller bridge: återskapas från de mappade fysiska portarna; kontrollera antal members och switchkonfiguration.
  • RED eller Cellular: tillhörande konfiguration migreras; testa anslutningen specifikt efter återställningen.

Pseudo ports, breakout, management och HA

  • Pseudo port: behåller konfigurationen men behandlar ingen trafik. Flytta routing, NAT, VLAN och regler till en aktiv port.
  • Breakout root port: endast root ports, inte enskilda members, kan mappas. Målet behöver ett antal och en kombination av portar som stöds.
  • Management port: mappas till en tillgänglig management port eller behålls som pseudo port. Planera hanteringsnätverket och den lokala åtkomsten i förväg.
  • Dedicated HA link: porttypen måste förbli densamma; Assistant kan inte ändra porten för HA link. För LAG måste antalet members stämma, för VLAN måste VLAN ID stämma och för monitored ports måste målstatusen stämma.

Innan en pseudo port tas bort ska alla beroende routes samt NAT-, brandväggs- och VLAN-konfigurationer flyttas. Ställ därefter in zone på None under Network > Interfaces och starta om brandväggen under ett underhållsfönster. Kontrollera sedan att porten har tagits bort; obundna pseudo ports med VLAN-konfiguration raderas inte automatiskt.

Backup-Restore Assistant mappar om gränssnitt, men kan inte göra en Wireless- eller bridgekonfiguration som målet inte stöder kompatibel. Sådana beroenden måste åtgärdas på källan före migreringssäkerhetskopian eller planeras om för målet.

Mål med HA, Wireless, virtual och cloud

För att behålla HA-konfigurationen får en HA-säkerhetskopia endast återställas till ett HA-kluster. Konfigurera antingen det nya klustret först och återställ säkerhetskopian på Primary, eller återställ först och konfigurera HA därefter. Kontrollera sedan roller, firmwareversion, Dedicated HA link och monitored ports.

Wireless-migreringar har ytterligare begränsningar:

  • För Wireless-to-Non-Wireless ska Wireless Networks tas bort innan säkerhetskopian skapas.
  • Säkerhetskopior från Gen.2 XGS Wireless-modeller kan inte återställas till XG- eller Gen.1 XGS Wireless-modeller.
  • Vid byte från äldre Wireless-modeller till Gen.2 XGS gäller ytterligare begränsningar för SSID, WPA, bridge mode och radio bands.

LocalWiFi- och bridgekonfigurationer vid migrering

För återställning av en säkerhetskopia från XG Wireless eller Gen.1 XGS Wireless till en Gen.2 XGS W-modell gäller följande krav och begränsningar:

  • Endast SSID med minst WPA2 är tilldelade till LocalWiFi0 och LocalWiFi1.
  • Krypteringen använder varken TKIP eller TKIP/AES.
  • Inget Wireless-gränssnitt ingår i en fysisk bridge.
  • LocalWiFi0 och LocalWiFi1 använder tillsammans högst åtta unika SSID.
  • Om båda radioenheterna använder samma frekvensband återställs endast inställningarna för LocalWiFi0.

Skillnaden mellan dessa bridges är avgörande. För ett Wireless Network av typen Bridge to AP LAN ansluter Gen.1-modellerna XGS 87w, 107w, 116w, 126w och 136w det lokala trådlösa nätverket till LAN via en fysisk bridge. Gen.2-modellerna XGS 88w, 108w, 118w och 128w stöder inte denna design; där används Bridge to Ethernet under Wireless > Access points > LocalWiFi > Advanced settings med exakt en Ethernet-port och zone LAN. Konfigurationen på Gen.2 beskrivs i Konfigurera Wi-Fi direkt på Sophos Firewall.

Om Gen.1-säkerhetskopian fortfarande innehåller en fysisk bridge med gränssnittet för ett Wireless Network av typen Bridge to AP LAN misslyckas återställningen till Gen.2. Sophos anger detta beteende som Known Issue NC-135094. Om OSPF, OSPFv3, RIP, SPX Portal Setting eller Quarantine refererar till detta gränssnitt slutförs återställningen, men den beroende konfigurationen fungerar inte på Gen.2.

Kontrollera därför före migreringssäkerhetskopian under Network > Interfaces om ett Wireless-gränssnitt ingår i en bridge och dokumentera alla beroende inställningar. Ta inte bort en bridge i produktion utan förberedelser: flytta först IP-adress, zone, DHCP, anslutna portar och routingberoenden till en Gen.2-kompatibel design under ett underhållsfönster. Skapa därefter en ny säkerhetskopia. Konfigurera Bridge to Ethernet på nytt på målet och testa sedan specifikt SSID, säkerhetsläge, frekvensband, DHCP och de tjänster som tidigare var beroende av konfigurationen.

Före en migrering från XG till XGS är även jämförelsen mellan XG och XGS till hjälp.

För virtual- och cloud-brandväggar är Sophos integrerade backup-and-restore-process den enda SFOS-återställningsväg som stöds. Sophos stöder inte hypervisor snapshots, cloud images eller säkerhetskopior från tredje part för detta ändamål; de kan orsaka problem med dataintegritet eller konfigurationer som inte stöds.

Validera efter återställningen

Teknisk kontroll

Kontrollera direkt efter återställningen:

  • WebAdmin-IP, tillåtna hanteringsnätverk och Device Access
  • gränssnitt, zones, VLAN, bridges, LAG och alias interfaces
  • WAN, PPPoE, default gateway, statiska routes och SD-WAN-routes
  • brandväggs-, NAT- och WAF-regler inklusive ordning
  • IPsec, SSL VPN, Sophos Connect, RED och Remote Access
  • certifikat, TLS Inspection, DNS, DHCP, NTP och Authentication Server
  • HA-status, roller och synkronisering
  • licensstatus, Pattern Updates, Hotfixes och Central-synkronisering
  • Log Viewer, Syslog, Central Reporting och lokal reporting

Beroende på problemet kan Log Viewer, Policy Test och Packet Capture, Packet Capture i WebAdmin och översikten Services och Logs vara till hjälp. Sophos anger ingen tillförlitlig universell SSH-loggsökväg för allmänna återställningsfel; därför rekommenderas inget shell-kommando här.

Acceptanstester

Ett åtkomligt WebAdmin bevisar inte att produktionstrafiken fungerar. För varje plats ska konkret källa, mål, förväntad regel och förväntad loggpost dokumenteras för följande tester:

  • Hantering: åtkomst från hanteringsnätverket och inloggning med en andra administratör.
  • Internet: en testklient når ett definierat externt mål via rätt regel, NAT och WAN-route.
  • DNS och DHCP: en klient får en adress och kan slå upp interna och externa namn.
  • Site-to-Site VPN: definierade hosts kan nås i båda riktningarna.
  • Remote Access: en testanvändare verifierar login, MFA, profil, DNS och ett internt mål.
  • WAF eller DNAT: ett externt test bekräftar certifikat, regel, backend och logging.
  • Autentisering: AD, LDAP, RADIUS, STAS eller Entra SSO identifierar en testanvändare korrekt.
  • Logging: testtrafik syns i Log Viewer, Syslog, Central Reporting eller SIEM.
  • HA: roller, klusterstatus och synkronisering motsvarar planen.

Om WAN, DNS, Remote Access eller HA inte fungerar ska flera områden inte ändras samtidigt. Avgränsa felet med tid, testkälla, mål, regel och loggutdrag och testa igen efter varje korrigering.

Troubleshooting och drift

Typiska fel

  • Säkerhetskopian finns endast på brandväggen: den är inte åtkomlig efter fel eller reimage; lagra den externt och säkert.
  • SSMK saknas: skyddade data kan inte återställas; dokumentera aktuella och tidigare nycklar.
  • Filen saknar enhets- eller versionsreferens: fel säkerhetskopia väljs; registrera brandväggens namn, serienummer, version och datum.
  • Ingen säkerhetskopia av aktuellt tillstånd före återställning: det finns ingen väg tillbaka till föregående tillstånd.
  • Återställd hanterings-IP är okänd: brandväggen verkar vara offline; dokumentera adress och lokal åtkomst i förväg.
  • Tid eller NTP är fel: VPN, certifikat, autentisering och Central kan sluta fungera.
  • Återställningsväg som inte stöds har bekräftats: återställningen misslyckas eller målet startar med factory configuration.
  • Gränssnittsmappningen har inte kontrollerats: WAN, VLAN, VPN eller HA link hamnar på fel portar.
  • Wireless-begränsningar har ignorerats: säkerhetskopian är inkompatibel eller den trådlösa konfigurationen fungerar inte som väntat.
  • HA-sammanhanget har ignorerats: klusterkonfiguration eller roller försvinner eller startar felaktigt.
  • Central är den enda kopian: när brandväggen tas bort från Central raderas dessa säkerhetskopior.
  • Endast WebAdmin har kontrollerats: fel i routing, NAT, VPN, WAF, DNS eller logging förblir oupptäckta.

Driftrutin

Regelbundet:

  • kontrollera automatiska säkerhetskopior, leverans, hämtning och lagringstid
  • kontrollera lagringsplats, behörigheter samt aktuella och tidigare SSMK
  • håll återställningspaketet och acceptanstesterna aktuella
  • kontrollera regelbundet fil, lösenord, SSMK och målkompatibilitet

Före större ändringar:

  • skapa en manuell säkerhetskopia, lagra den externt och märk den entydigt
  • fastställ hanteringsåtkomst, återställningsväg och avbrottskriterier
  • kontrollera kompatibilitet, SFOS-version och gränssnittsmappning vid migreringar

Efter en återställning:

  • dokumentera tekniska kontroller och acceptanstester fullständigt
  • korrigera avvikelser och jämför med Config Studio vid behov
  • skapa en ny säkerhetskopia av det verifierade måltillståndet och uppdatera återställningspaketet