Sophos Firewall Skapa eller återställ säkerhetskopia

En Sophos Firewall backup är mer än bara en nödfil. Det är grunden för firmwareuppdateringar, hårdvarubyten, XG till XGS-migreringar, reimage, HA arbete och rena återställningsprocesser. Om säkerhetskopiering, Secure Storage Master Key och återställningskompatibilitet inte är förberedd, förvandlas en planerad förändring snabbt till ett onödigt långt avbrott.

Artikeln förklarar hur man skapar och återställer Sophos Firewall säkerhetskopior, vilken ytterligare information som bör dokumenteras och vilka kontroller som är viktiga innan man återställer till annan hårdvara eller plattformar.

⚠️ Viktigt: En säkerhetskopia är bara till hjälp om den kan hittas, dekrypteras och är kompatibel med målmiljön. Innan firmwareupdateringar, reimages, HA ändringar eller migrering, bör du noggrant kontrollera säkerhetskopieringsfilen, säkerhetskopieringslosenordet, Secure Storage Master Key, målversionen, hanteringsåtkomst och återställningsprocessen.

Videoinstruktioner

Vilken återhämtningsväg är lämplig?

Säkerhetskopiering och återställning är ofta bara en del av problemet. Beroende på situationen är en annan process vettig:

• Schemalägg firmwareuppdatering: Sophos Firewall Firmware Update: Förberedelser och bästa praxis.
• Firmware-Image im WebAdmin installieren: Sophos Firewall Firmware Update durchführen.
• Central uppdatering eller grupprincip hänger sig: Sophos CentralKontrollera Firewall Management Task Queue.
• Firewall OS komplett neu installieren: Sophos Firewall OS neu installieren: Reimage mit USB-Stick.
• Hårdvarudefekt, upprepat fel eller RMA: Öppna en Sophos-supportbiljett: förberedelse och portal.
• Återställ eller bygg om HA kluster: Sophos Firewall HA klustervarianter.

In practice, these processes overlap. En säkerhetskopia krävs nästan alltid innan en reimage. Innan ett supportärende är serienummer, firmwareversion, loggar och tidigare steg viktiga. Efter en centralt styrd uppdatering kan uppgiftskön förklara varför en ändring ännu inte har nått brandväggen.

Varför enbart en säkerhetskopia inte räcker

En nedladdad säkerhetskopia minskar risken, men löser inte automatiskt alla återställningsproblem. I praktiken behöver du också:

• en säker lagringsplats utanför brandväggen
• en tydlig tilldelning till brandvägg, serienummer, plats och SFOS version
• lämplig Secure Storage Master Key (SSMK)
• säkerhetskopieringslösenordet om säkerhetskopian var krypterad
• dokumenterad WAN, VLAN, HA, VPN och licensinformation
• en testad återställningsplan för maskinvarubyte, reimage eller migrering

Speciellt före en firmware-uppdatering, en reimage via USB-minne eller en SFOS 22 uppgraderingskontroll, bör säkerhetskopian inte bara skapas utan också kontrolleras professionellt.

Före den första säkerhetskopieringen: Kontrollera Secure Storage Master Key

Innan manuella eller planerade säkerhetskopieringar används produktivt bör Secure Storage Master Key (SSMK) ställas in och dokumenteras säkert. Utan denna nyckel kan en återställning på en ny apparat eller i vissa återställningsscenarier misslyckas.

Detta är särskilt relevant om:

• en ersättningsbrandvägg förbereds
• a migration to another model is planned
• Konfiguration av två hårdvara, virtuella appliance och moln ändrades
• Säkerhetskopieringar lagras utanför brandväggen

SSMK hör hemma i en lösenordshanterare eller en annan säker återställningsprocedur. Det borde inte vara känt för bara en person. Om nyckeln endast söks i en nödsituation är värdefull återhämtningstid redan förlorad.

Viktigt: Äldre säkerhetskopior förblir bundna till SSMK de skapades med. Om nyckeln senare ändras eller återställs, kommer den nya nyckeln inte att räcka för dessa gamla säkerhetskopior. Därför bör tidigare versioner av SSMK också dokumenteras med datum, giltighetsperiod och påverkad brandvägg. En SSMK ändring är inte en tillfällig rensning, utan en återställningsrelevant ändring.

Schemalagda säkerhetskopieringar utan SSMK set är också ett specialfall. Sophos Firewall kan fortsätta att producera sådana säkerhetskopior enligt det återställda schemat, men det extra SSMK-skyddet saknas. Dessutom bör säkerhetskopieringsfrekvensen endast betraktas som hanterbar när SSMK är inställd. För produktiva brandväggar är det därför meningsfullt: ställ in SSMK, skapa sedan en ny manuell säkerhetskopia och utvärdera först sedan planerade säkerhetskopior som en pålitlig återställningsväg.

Skapa backup: manuell och automatisk

Sökvägen WebAdmin är:

Backup & Firmware > Backup & Restore

Manuell säkerhetskopiering före ändringar

För en omedelbar säkerhetskopiering, använd Backup Now. Säkerhetskopieringen bör då inte bara finnas kvar i webbläsarens nedladdningsmapp, utan bör lagras medvetet.

En manuell säkerhetskopia ska alltid skapas innan detta arbete:

• Firmwareuppdatering eller snabbkorrigering med risk för omstart eller beteendeförändring
• Gränssnitt, VLAN, routing, SD-WAN eller VPN konvertering
• HA inställning, HA rullbyte eller HA underhåll
• större NAT, WAF eller brandväggsregeländring
• Reimage, fabriksåterställning eller maskinvarubyte
• Migrera från XG till XGS, hårdvara till virtuell eller virtuell till moln

Efter nedladdningen bör du åtminstone dokumentera datum, brandväggsnamn, serienummer, SFOS-version och syftet med säkerhetskopieringen. För större ändringar kommer en jämförelse med Sophos Firewall Config Studio att hjälpa senare för att kunna förstå konfigurationsskillnader före och efter ändringen.

Ställ in automatiska säkerhetskopieringar

För att säkerställa att säkerhetskopior inte glöms bort bör en automatisk säkerhetskopiering ställas in. Under Frequency kan du definiera dagliga, veckovisa eller månatliga säkerhetskopior.

De automatiskt genererade säkerhetskopiorna kan sparas lokalt på brandväggen, på en FTP-server eller via e-post. Lagringsplatsen är mindre viktig än processen runt den:

• Alla som lagrar säkerhetskopior via e-post eller på en extern server bör kontrollera kryptering och åtkomstskydd.
• Lokala säkerhetskopior på brandväggen hjälper inte om enheten behöver bytas ut eller installeras om helt.
• På själva brandväggen är endast den senaste lokala säkerhetskopian relevant. Om du måste behålla äldre versioner bör du medvetet ladda ner dem eller spara dem externt.
• När det kommer till FTP- eller e-postsäkerhetskopior är det inte bara inställningarna som ska kontrolleras. Leverans, hämtning, behörigheter och upptäckbarhet måste också testas.
• Centrala säkerhetskopior är bekväma, men bör inte vara den enda kända återställningsvägen.
• Automatiska säkerhetskopieringar ersätter inte manuella säkerhetskopior omedelbart före riskfyllda ändringar.
• Gamla säkerhetskopior bör hanteras med lagringstid, åtkomst och raderingsprocess. Vid FTP-säkerhetskopior och Backup prefix bör komplexa specialtecken inte användas utan test. Sophos har begränsningar för prefix, användarnamn och lösenord. Efter konfigurationen är det inte den sparade inställningen som räknas, utan ett verkligt test av backup, nedladdning och restore.

Om brandväggen är ansluten till Sophos Central kan central lagring av säkerhetskopior av konfigurationer också vara vettigt. Den centrala anslutningen beskrivs i artikeln Anslut Sophos Firewall till Sophos Central.

Organisera centrala säkerhetskopior på rätt sätt

Sophos Central kan schemalägga säkerhetskopior av brandväggskonfiguration, skapa dem omedelbart, ladda ner dem och göra dem tillgängliga för senare återställning. Den centrala vägen är på:

My Products > Firewall Management > Backup

Centrala säkerhetskopior är användbara eftersom de inte finns på själva brandväggen och flyter in i kontot Health Check. Ändå behöver denna säkerhetskopieringsväg medveten operation:

• Den globala backupfrekvensen i Sophos Central börjar som Never. Vid manuell konfiguration via Schedule Backup kan UI:t visa ett annat föreslaget värde. När en brandvägg automatiskt läggs till som den första i backupschemat sätter Sophos Central frekvensen en gång till Monthly, med start den första dagen i månaden. Om en brandvägg trots aktiverad Send configuration backup to Sophos Central inte visas i schemat, använd Schedule Backup > Add new firewall; alternativt ta bort markeringen, Apply, markera igen, Apply och kör sedan accept-services i Sophos Central.
• Schemalagda centrala säkerhetskopieringar körs klockan 8:00 i tidszonen i Sophos Central-regionen. Denna tid kan inte justeras.
• Sophos Central försöker skapa backupen upp till fem gånger. Om det fortfarande misslyckas därefter skapas en alert och ett e-postmeddelande skickas till Central-administratören.
• Central sparar de fem senaste säkerhetskopiorna. En säkerhetskopia kan också lagras permanent tills den ersätts eller tas bort.
• När den laddas ner från Central krypteras säkerhetskopian om med ett nytt lösenord. Detta lösenord ingår då också i återställningsprocessen.
• När en brandvägg tas bort från Sophos Central Management tar Sophos också bort sina centrala säkerhetskopior. Innan du byter konton, hyresgästrensning eller RMA bör du ladda ner nödvändiga säkerhetskopior i förväg.
• För HA-kluster ingår primär och extra i säkerhetskopieringsschemat, men säkerhetskopian skapas av den primära.

Central Backup är därför en bra ytterligare återställningsväg, men ingen anledning att försumma lokal återställning, SSMK, administratörsåtkomst och webbplatsdokumentation.

Lagra säkerhetskopia säkert

Brandväggssäkerhetskopior innehåller känslig information om nätverksstruktur, objekt, regler, tjänster, VPNs, certifikat och delvis skyddade kontodata. Därför bör de behandlas som känsliga infrastrukturfiler.

Dessa regler är vettiga för drift:

• Förvara inte säkerhetskopior okrypterade i allmänna teammappar.
• Begränsa åtkomst till säkerhetskopior av brandväggar till administratörer och återställningshanterare.
• Dokumentera säkerhetskopieringslösenordet och SSMK separat men så att de kan hittas.
• Använd en tydlig namnkonvention per webbplats eller brandvägg.
• Efter administratörsavgångar, kontrollera om säkerhetskopieringslagringen och lösenordshanteraren fortfarande fungerar.
• Dokumentåterställningsrelevant information som WAN åtkomstdata, PPPoE, statisk leverantörsdata eller HA porttilldelning separat.

En säkerhetskopia är inte en ersättning för driftdokumentation. Speciellt med HA kluster, flera WAN upplänkar eller komplexa VPN-miljöer, bör det också dokumenteras vilka gränssnitt, leverantörsdata och beroenden som måste kontrolleras först efter en återställning.

Förbered återställningspaket per brandvägg

I en nödsituation slösar du inte bort det mesta av din tid på att ladda upp säkerhetskopian, utan snarare på att söka efter ytterligare information. För produktiva brandväggar bör det därför finnas ett litet återställningspaket för varje plats eller klient.

Detta paket inkluderar:

• Senast kontrollerad säkerhetskopia: Grund för återställning, migrering eller ombild.
• Säkerhetskopieringslösenord och Secure Storage Master Key: Nödvändigt för krypterade säkerhetskopior och skyddad data.
• Serienummer, modell och SFOS version: Viktigt för support, licensiering och kompatibilitetskontroll.
• WAN data och leverantörsinformation: Nödvändigt om internetåtkomst eller central anslutning saknas efter återställningen.
• Gränssnitt och porttilldelning: Avgörande för XG till XGS-migreringar, Flexi-portar, VLAN-trunkar och HA.
• Admin och Break Glass Access: Tillåter lokal åtkomst om VPN, Central eller SSO ännu inte fungerar.
• Licens och central mappning: Förhindrar förväxling med ersättningshårdvara, virtuella brandväggar eller molninstanser.
• Kritiska tjänster och acceptanstester: Efter återställningen visar det snabbt om VPN, NAT, WAF, DNS, DHCP och loggning fungerar igen.

Det här paketet ska inte lämnas som en oskyddad textfil bredvid säkerhetskopian. En kombination av lösenordshanterare, intern verksamhetsdokumentation och tydligt ansvar är bättre. Minst två auktoriserade personer bör veta var denna information finns och hur man kommer åt den i en nödsituation.

Återställningspaketet bör kontrolleras efter byte av personal, flytt, byte av leverantör, HA byte eller större migrering. En formellt aktuell backup är till liten hjälp om den dokumenterade WAN IP-adressen, porttilldelningen eller centraltilldelningen inte längre är korrekt.

Förbered återställning

Inför en återställning bör det först klargöras vilket mål som eftersträvas. En återställning till samma apparat efter en felaktig konfiguration ska bedömas på ett annat sätt än en återställning efter en reimage, hårdvarubyte eller plattformsbyte.

Förberedelser:

• Finns det en ny säkerhetskopia av det nuvarande tillståndet?
• Är säkerhetskopian tydligt tilldelad rätt brandvägg?
• Är säkerhetskopieringslösenord och SSMK tillgängliga?
• Matchar SFOS-versionen av målsystemet säkerhetskopian?
• Delas återställningssökvägen för källversionen, målversionen och målplattformen?
• Är återställning till identisk hårdvara, annan modell, virtuell apparat eller moln?
• Kommer Backup-Restore Assistant att visas eller kommer det att finnas automatisk gränssnittsmappning?
• Är HA inblandad eller återställs en HA säkerhetskopia till en enda enhet?
• Finns det lokal hanteringsåtkomst om WAN, VPN eller Central inte fungerar direkt efter återställningen?
• Är det känt vilken WebAdmin IP som kommer att bli aktiv efter återställningen?
• Dokumenteras tidszonen, NTP-servern och eventuella manuella datum/tidsinställningar?

⚠️ En återställning skriver över den aktuella konfigurationen. På en produktiv brandvägg bör du om möjligt skapa en ny säkerhetskopia av det aktuella tillståndet innan du återställer, även om den aktuella konfigurationen är felaktig. Om migreringsvägar inte stöds kan brandväggen starta med fabrikskonfiguration efter bekräftelse. Denna varning ska inte behandlas och bekräftas som ett normalt återställningsmeddelande.

Vad en återställning inte löser automatiskt

En återställning återställer konfigurationen, men ersätter inte en fullständig funktionskontroll. Efter omstarten gäller hanterings-IP, gränssnittskonfiguration, Device Access, certifikat, rutter och tjänster från den återställda konfigurationen igen. Detta innebär att WebAdmin plötsligt kan vara tillgänglig under en annan IP än under den initiala konfigurationen av ersättningsbrandväggen.

Dessutom bör du medvetet kontrollera dessa punkter:

• Manuella datum- och tidsvärden återställs inte helt till driftsstatus. Tidszon, NTP och aktuell tid bör kontrolleras efter återställningen.
• Lösenordet för standardkontot admin ersätts inte av säkerhetskopian under återställningen. Målbrandväggen behåller det befintliga standardlösenordet för administratören.
• Loggar, rapporter och extern övervakningsdata ersätter inte en konfigurationsbackup och bör säkerhetskopieras separat eller lagras centralt.
• Certifikat, VPNs, central anslutning, syslog-mål och aviseringar kan tekniskt sett finnas efter en återställning, men fortfarande inte fungera korrekt på grund av tid, DNS, routing eller ändrad målplattform.
• En återställning till annan hårdvara löser inte automatiskt port- och gränssnittsskillnader. Kartläggningen måste matcha kablage och zonmodell.
• Modellberoende inställningar kan återgå till standardvärden vid återställning till en annan plattform om de inte passar på målenheten. Detta gäller till exempel hårdvaru- eller instansspecifik prestanda och portalternativ.
• Sophos Central-registreringen behålls endast vid återställning till samma brandvägg. Återställning till annan hårdvara eller HA avregistrerar brandväggen från Sophos Central. Efter återställningen måste den registreras igen, och Security Heartbeat, Sophos ZTNA, Central Management, Central Backup, Central Reporting och Task Queue måste var för sig kontrolleras och vid behov konfigureras om. Vid gruppolicyer hör även gruppmedlemskapet till denna uppföljande kontroll.

Planera ett återställningstest utan produktionsrisk

Ett återställningstest är användbart, men bör inte utföras lätt på en produktiv brandvägg. Syftet är inte att regelbundet skriva över produktiva apparater, utan snarare att verifierbart kontrollera om de viktigaste återställningskraven fungerar.

Beroende på miljön kan ett säkert återställningstest se ut så här:

• Hämta säkerhetskopia från schemalagd lagring.
• Kontrollera filnamn, datum, brandväggsnamn, serienummer och SFOS version.
• Kontrollera säkerhetskopieringslösenordet och SSMK i lösenordshanteraren.
• Kör backup-restore-kompatibilitetskontroll för den planerade målmodellen.
• Dokumentera gränssnittsmappning och portavvikelser före en migrering.
• Kontrollera den planerade målversionen mot de sökvägar för uppgradering och backup som stöds.
• Testa i ett laboratorium eller en ersättningsbrandvägg om säkerhetskopieringen är allmänt accepterad.
• Efter en teståterställning, lämna inga produktiva VPNs, WAN-åtkomster eller centrala anslutningar aktiva okontrollerade.

Om det inte finns någon laboratorie- eller ersättningsbrandvägg är minst ett organisatoriskt test möjligt: hitta säkerhetskopia, kontrollera åtkomst, bekräfta lösenord/SSMK, utvärdera målplattformen med kompatibilitetskontrollen och kör igenom processen i återställningsrunbooken. Detta ersätter inte en riktig återställning, men det förhindrar många klassiska nödproblem.

För kritiska platser bör det också vara tydligt hur brandväggen blir tillgänglig igen efter ett nytt avbildnings- eller maskinvarubyte: lokal åtkomst, hanteringsport, WAN-data, licensstatus, Sophos Central-tilldelning och kontaktperson på plats. Denna information hör inte bara hemma i säkerhetskopian, utan också i separat driftdokumentation.

Återställ säkerhetskopia

Återställningen sker även på:

Backup & Firmware > Backup & Restore

Grundläggande process:

1. Nå målbrandväggen via WebAdmin.
2. Spara aktuell status om det fortfarande är möjligt.
3. I Restore configuration, välj backupfilen via Choose file.
4. Ange Encryption password eller SSMK om det behövs.
5. Starta Upload and Restore.
6. Vänta på omstart och återställning.
7. Öppna WebAdmin via hanterings-IP från den återställda konfigurationen.
8. Kontrollera tidszon, NTP och aktuell tid.
9. Kontrollera sedan nätverk, tjänster, VPN, HA och central anslutning.

Under en återställning ersätter den importerade konfigurationen den aktuella konfigurationen, tar bort den lokalt lagrade säkerhetskopian på brandväggen och startar om brandväggen. Därför bör säkerhetskopian som används förbli tillgänglig externt innan återställningen. Om den enda kopian finns på målbrandväggen är återställningsprocessen onödigt ömtålig.

Om en ny eller ersatt Sophos Firewall distribueras kan säkerhetskopian importeras efter första åtkomst till enheten. Den initiala IP-adressen och initiala åtkomsten beror på respektive modell och distributionstyp. För hårdvaruapparater är lokal initial åtkomst vanlig via standardhanterings-IP eller installationsguiden.

Så snart brandväggen är tillgänglig och installationsguiden har slutförts kan återställningen utföras enligt beskrivningen ovan.

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

Speciellt när du migrerar mellan XG och XGS eller mellan hårdvara, virtuell apparat och moln bör du kontrollera om säkerhetskopian är kompatibel innan du återställer. Sophos erbjuder en offentlig Backup-restore-kompatibilitetskontroll för detta ändamål.

Dessutom måste målversionen vara korrekt. Sophos skiljer mellan delade uppgraderings- och säkerhetskopieringsvägar och icke-delade migreringar. Om en brandvägg varnar innan du startar om att den planerade migreringen inte stöds, bör du inte bara bekräfta det. Efter en bekräftad, outgiven migrering kan brandväggen starta med fabrikskonfiguration, vilket gör att den aktuella konfigurationen går förlorad.

För en produktiv återställning betyder detta:

• notera först källversionen, målversionen, målmodellen och plattformen
• Uppdatera målbrandväggen till en SFOS-version som stöds innan du återställer
• Kör backup-restore-kompatibilitetskontroll för den specifika kombinationen
• Ta varningar i dialogrutan för återställning eller uppgradering på allvar och dokumentera dem
• Om du är osäker, kontrollera först efter utbytesmaskinvara eller i en testmiljö

Backup-Restore Assistant och automatisk gränssnittsmappning

Om Backup-Restore Assistant visas beror på konkreta versions- och plattforms villkor, inte bara på en ”nyare” backup:

• Backupen kommer från en appliance (XG, SG med SFOS, XGS, virtual eller cloud) som körde SFOS 19.5 MR4 eller senare.
• Restore görs på SFOS 20.0 MR2 eller senare.
• Restore görs till en XGS-serie, virtual eller cloud appliance.
• Vid restore till XG- eller SG-serie visas inte Assistant.

Assistant hjälper till att mappa gränssnitt när en backup från XG, SG med SFOS eller XGS återställs till en XGS-serie, virtuell appliance eller cloud firewall. Detta är särskilt viktigt om målbrandväggen har färre portar, andra portnamn, wireless-varianter eller Flexi-Port-moduler.

För backuper från SFOS 19.5 MR3 eller äldre, och vid varje restore till XG/SG, saknas Assistant. Då mappar brandväggen gränssnitt automatiskt. Det är snabbare men mer riskabelt eftersom mappningen inte bekräftas medvetet i assistenten. Efter en sådan restore måste gränssnitt, zoner, gateways, VLANs, HA-link, SD-WAN-rutter, NAT-regler och VPNs kontrolleras särskilt noggrant.

De viktigaste specialfallen vid gränssnittsmappning:

Pseudo-portar visar att ett operativt portbeslut fortfarande är öppet. Efter restore bör de kontrolleras, flyttas till en aktiv port eller tas bort rent. För att ta bort en pseudo-port öppnar man den under Network > Interfaces, sätter zone till None och startar om brandväggen. Obundna pseudo-portar med VLAN-konfiguration tas inte bort automatiskt och kräver extra städning.

Ytterligare punkter att klargöra efter restore:

Om porttilldelningen är annorlunda måste du vanligtvis kontrollera eller omarbeta en gränssnittsmapping efter återställningen. Innan XG till XGS-migreringar är artikeln Vad är skillnaden mellan en XG- och XGS-brandvägg? också relevant.

Efter större återställnings- eller migreringsarbete kan en jämförelse av konfigurationerna hjälpa. Sophos Firewall Use Config Studio visar hur man jämför säkerhetskopior före och efter en ändring och specifikt letar efter oväntade skillnader.

Moln och virtuella brandväggar

När det gäller virtuella brandväggar eller molnbrandväggar bör du inte bara lita på säkerhetskopior av hypervisor, ögonblicksbilder eller molnleverantörer. Sophos stöder brandväggens inbyggda säkerhetskopiering och återställningsmekanism för säkerhetskopiering av brandväggskonfiguration. Plattformsbackuper kan vara användbara som ytterligare infrastrukturskydd, men ersätter inte den konfigurationsbackup som stöds.

I praktiken betyder det att VM-snapshot, cloud image eller marketplace-mekanism kan hjälpa till att återställa instansen. För en ren SFOS-konfiguration, migrering eller supportanalys behövs ändå en giltig Sophos Firewall-backup med rätt SSMK, backup-lösenord, målversion och dokumenterad gränssnittsmappning.

Kontrollera efter återställningen

Efter återställningen bör du inte bara kontrollera om WebAdmin kan nås. Brandväggen kan vara tillgänglig och fortfarande behandla viktiga tjänster felaktigt.

Kontrollera omedelbart efter återställningen:

• WebAdmin-IP, tillåtna hanteringsnätverk och Device Access.
• Gränssnitt, zoner, VLANs, broar, LAGs och Alias Interfaces.
• WAN upplänkar, PPPoE, statisk leverantörsdata och standardgateway.
• SD-WAN rutter, statiska rutter och dynamisk routing.
• Brandväggsregler, NAT regler, WAF regler och regelordning.
• IPsec, SSL VPN, Sophos Connect, RED och fjärråtkomst.
• Certifikat, CA certifikat, WebAdmin certifikat och TLS Inspection.
• DNS, DHCP, NTP, tidszon och autentiseringsserver.
• HA status om ett kluster används.
• Licensstatus, mönsteruppdateringar, Hotfixes och Sophos Central synkronisering.
• Loggning, syslog-mål, central brandväggsrapportering och lokala rapporter.

Beroende på problemet hjälper Log Viewer, Policy Test och Packet Capture, Packet Capture i WebAdmin och Tjänster och loggar för den tekniska kontrollen.

Acceptanstest efter en återställning

En återställning är inte klar förrän nyckelfunktionerna har bekräftats med verklig testning. En tillgänglig WebAdmin bevisar bara att brandväggen kan användas. Det bevisar inte att routing, NAT, VPN, WAF, autentisering eller loggning fungerar korrekt igen.

Det bör därför finnas en kort acceptansmatris för produktiva brandväggar. This matrix does not have to be complicated, but should specify for each location which test must be carried out after a restore and who documents the result.

Användbara obligatoriska prov är:

• Hantering: Öppna WebAdmin från hanteringsnätverket och testa den andra administratörsåtkomsten. Det förväntas att åtkomst endast fungerar från tillåtna nätverk.
• Internetåtkomst: Testa klienten i LAN eller klient VLAN anrop definierade externa mål. Korrekt brandväggsregel, NAT-regel och WAN-rutt måste träda i kraft.
• DNS och DHCP: Klienten får adress och löser interna och externa namn. DHCP område, DNS server och DNS Request Routes måste matcha.
• Site-to-Site VPN: En definierad värd per webbplats nås i båda riktningarna. Regler för tunnlar, routing och brandvägg måste matcha.
• Fjärråtkomst: Testanvändaren ställer in SSL VPN, IPsec eller Sophos Connect. Inloggning, MFA, profil, DNS och interna mål måste fungera.
• WAF eller DNAT: Publicerad tjänst testas externt. Certifikat, regel, backend och loggning måste passa.
• Autentisering: Verifiera AD, LDAP, RADIUS, STAS eller Entra SSO med testanvändaren. Användaren ska kännas igen och träffa den förväntade regeln.
• Loggning: Kontrollera Log Viewer, Syslog, Central Reporting eller SIEM. Återställnings- och testtrafik ska vara tydligt synlig.
• HA: Kontrollera klusterstatus, roller och synkronisering. Primär och Auxiliär bör vara i det förväntade tillståndet.

En definierad stopppunkt är viktig. If basic tests such as WAN, DNS, Remote Access or HA do not work after a restore, corrections should not be made in many places in parallel. Det är bättre att ha ett smalt felfall med tid, testkälla, mål, påverkad regel och loggutdrag. Detta gör det tydligt om problemet kommer från säkerhetskopieringen, gränssnittskartläggningen, målhårdvaran eller en efterföljande förändring.

Typiska misstag

• Säkerhetskopiering lagras endast lokalt på brandväggen: Den kan inte nås i händelse av ett hårdvarufel eller reimage. Säkerhetskopior bör lagras externt och skyddas.
• SSMK inte dokumenterad: Återställning av skyddad data kan misslyckas eller ta betydligt längre tid. SSMK hör hemma i återställningsprocessen.
• Gamla SSMK kan inte längre hittas efter nyckelbyte: Äldre säkerhetskopior kan inte längre dekrypteras. Tidigare SSMK-versioner bör förbli dokumenterade med tidsperiod och brandväggsreferens.
• Säkerhetskopiering utan version eller enhetsreferens: Fel fil har importerats. Brandväggsnamn, serienummer, SFOS version och datum är en del av säkerhetskopian.
• Ingen faktisk säkerhetskopiering före återställning: Sökvägen tillbaka till nuvarande tillstånd saknas. En ny säkerhetskopia bör skapas innan en produktiv återställning.
• Återställd WebAdmin IP okänd: Efter återställningen visas brandväggen offline även om den körs på en annan IP. Förplanera hanterings-IP från backup och lokal åtkomst.
• Tid och NTP kontrolleras inte efter återställning: VPN, certifikat, autentisering eller central anslutning kan fungera felaktigt. Kontrollera tidszon, NTP och aktuell tid direkt efter återställningen.
• Odelad återställningssökväg bekräftad: Brandväggen startar med fabrikskonfiguration eller så misslyckas återställningen otydligt. Målversion, källversion och kompatibilitetskontroll måste kontrolleras före återställningen.
• Portmappning inte markerad: Gränssnitt landar felaktigt efter migrering. Kompatibilitetskontroll och gränssnittskartläggning bör förberedas.
• Automatisk gränssnittsmappning användes utan kontroll: WAN, VLAN, VPN eller HA länkar är på fel portar. Efter återställningen, jämför varje gränssnitt med kabel- och zonmodellen.
• HA sammanhang ignoreras: Klustret startar inte rent eller så blir fel roll aktiv. HA roller, firmwareversion och återställningssekvens måste planeras.
• Endast WebAdmin markerad: VPN, NAT, WAF eller DNS problem förblir oupptäckta. Efter återställningen behövs riktiga servicetester.

Checklista för verksamheten

Regelbundet:

• Aktivera automatiska säkerhetskopieringar eller definiera en central säkerhetskopieringsprocess.
• Kontrollera säkerhetskopieringslagring, åtkomst och lagring.
• Kontrollera SSMK och säkerhetskopieringslösenord i lösenordshanteraren.
• Håll återställningspaketet uppdaterat per plats eller brandvägg.
• Kontrollera åtminstone slumpmässigt om säkerhetskopior kan hittas och tilldelas.

Innan större förändringar:

• Skapa manuell backup och spara externt.
• Dokumentera brandväggens namn, serienummer, SFOS version och ändra syfte.
• SSMK, kontrollera säkerhetskopieringslösenord och administratörsåtkomst.
• Ställ in en återställnings- eller återställningsplan.
• Kontrollera kompatibilitetskontroll och gränssnittsmappning för migrering.
• Godkänn inte varningar om återställnings- eller migreringsvägar som inte stöds förrän en alternativ plan finns på plats.

Efter en återställning:

• Kontrollera WebAdmin-IP, hanteringsnätverk och Device Access.
• Testa gränssnitt, routing, NAT, VPN, WAF, autentisering och central.
• Kontrollera tidszon, NTP och aktuell tid.
• Processacceptansmatris med riktiga testkällor, testmål och förväntade loggar.
• Kontrollera HA status och roller.
• Kontrollera loggar och övervakning.
• För målversioner från SFOS 22.0 MR1, kontrollera igen om en återställning eller import har återfört gamla Legacy Remote Access IPsec-konfigurationer.
• Skapa en ny säkerhetskopia av det återställda måltillståndet.
• Dokumentera avvikelser och jämför dem med Config Studio vid behov.

FAQ