Sophos Firewall Back-up maken of herstellen

Een Sophos Firewall-back-up is meer dan alleen een noodbestand. Het is de basis voor firmware-updates, hardwarevervangingen, XG naar XGS-migraties, reimage, HA-werk en schone herstelprocessen. Als er geen back-up, beveiligde opslagmastersleutel en herstelcompatibiliteit zijn voorbereid, verandert een geplande wijziging al snel in een onnodig lange uitval.

In het artikel wordt uitgelegd hoe u Sophos Firewall back-ups kunt maken en herstellen, welke aanvullende informatie moet worden gedocumenteerd en welke controles belangrijk zijn voordat u herstelt naar andere hardware of platforms.

⚠️ Belangrijk: Een back-up is alleen nuttig als deze vindbaar, decrypteerbaar en compatibel is met de doelomgeving. Voordat u firmware-updates, reimages, HA-wijzigingen of migraties uitvoert, moet u het back-upbestand, het back-upwachtwoord, de hoofdsleutel voor de beveiligde opslag, de doelversie, de beheertoegang en het herstelproces zorgvuldig controleren.

Video-instructies

Welk herstelpad is geschikt?

Back-up en herstel zijn vaak slechts een deel van het probleem. Afhankelijk van de situatie is een ander proces zinvol:

• Firmware-update plannen: Sophos Firewall Firmware-update: voorbereiding en beste praktijken.
• Firmware-image installeren in WebAdmin: Sophos Firewall Firmware-update uitvoeren.
• Centrale update of groepsbeleid loopt vast: Sophos Central Controleer takenwachtrij voor firewallbeheer.
• Firewall OS volledig opnieuw installeren: Sophos Firewall OS opnieuw installeren: Reimage met USB-stick.
• Hardwaredefect, herhaalde fout of RMA: Open een Sophos-supportticket: voorbereiding en portal.
• HA-cluster herstellen of opnieuw opbouwen: Sophos Firewall HA-clustervarianten.

In de praktijk overlappen deze processen elkaar. Er is bijna altijd een back-up vereist voordat u een reimage uitvoert. Vóór een ondersteuningsaanvraag zijn het serienummer, de firmwareversie, logboeken en voorgaande stappen belangrijk. Na een centraal aangestuurde update kan de takenwachtrij verklaren waarom een ​​wijziging de firewall nog niet heeft bereikt.

Waarom een back-up alleen niet genoeg is

Een gedownloade back-up vermindert het risico, maar lost niet automatisch elk herstelprobleem op. In de praktijk heb je ook nodig:

• een veilige opslaglocatie buiten de firewall
• een duidelijke toewijzing aan firewall, serienummer, locatie en SFOS-versie
• de juiste Secure Storage Master Key (SSMK)
• het back-upwachtwoord als de back-up gecodeerd was
• gedocumenteerde WAN-, VLAN-, HA-, VPN- en licentie-informatie
• een geverifieerd herstelplan voor hardwarevervanging, reimage of migratie

Vooral vóór een firmware-update, een reimage via USB-stick of een SFOS 22 upgrade check moet de back-up niet alleen worden gemaakt, maar ook professioneel worden gecontroleerd.

Vóór de eerste back-up: Controleer de Secure Storage Master Key

Voordat handmatige of geplande back-ups productief kunnen worden gebruikt, moet de Secure Storage Master Key (SSMK) worden ingesteld en veilig gedocumenteerd. Zonder deze sleutel kan een herstelbewerking op een nieuw apparaat of in bepaalde herstelscenario’s mislukken.

Dit is met name relevant als:

• er wordt een vervangende firewall voorbereid
• er is een migratie naar een ander model gepland
• Configuraties kunnen worden verplaatst tussen hardware, virtueel apparaat en cloud
• Back-ups worden buiten de firewall opgeslagen

De SSMK hoort thuis in een wachtwoordbeheerder of een andere beveiligde herstelprocedure. Het mag niet bij slechts één persoon bekend zijn. Als de sleutel alleen in geval van nood wordt gezocht, gaat er al waardevolle hersteltijd verloren.

Belangrijk: Oudere back-ups blijven gekoppeld aan de SSMK waarmee ze zijn gemaakt. Als de sleutel later wordt gewijzigd of gereset, is de nieuwe sleutel niet voldoende voor deze oude back-ups. Daarom moeten eerdere SSMK-versies ook worden gedocumenteerd met de datum, geldigheidsperiode en getroffen firewall. Een SSMK-wijziging is geen gewone opruiming, maar een herstelrelevante wijziging.

Geplande back-ups zonder SSMK-set zijn ook een speciaal geval. Sophos Firewall kan dergelijke back-ups blijven maken volgens het herstelde schema, maar de aanvullende SSMK-bescherming ontbreekt. Bovendien mag de back-upfrequentie pas als beheersbaar worden beschouwd zodra de SSMK is ingesteld. Voor productieve firewalls is het daarom zinvol: SSMK instellen, vervolgens een nieuwe handmatige back-up maken en pas daarna geplande back-ups evalueren als een betrouwbaar herstelpad.

Back-up maken: handmatig en automatisch

Het WebAdmin-pad is:

Backup & Firmware > Backup & Restore

Handmatige back-up vóór wijzigingen

Voor een directe back-up gebruikt u Backup Now. De back-up moet dan niet alleen in de downloadmap van de browser blijven, maar bewust worden bewaard.

Voordat u deze werkzaamheden uitvoert, moet er altijd een handmatige back-up worden gemaakt:

• Firmware-update of hotfix met risico op opnieuw opstarten of gedragsverandering
• Interface, VLAN, routing, SD-WAN of VPN-conversie
• HA-configuratie, HA-rolverandering of HA-onderhoud
• grote wijziging in de NAT-, WAF- of firewallregel
• Reimage, fabrieksreset of hardwarevervanging
• Migreer van XG naar XGS, hardware naar virtueel of virtueel naar cloud

Na het downloaden moet u in ieder geval de datum, firewallnaam, serienummer, SFOS-versie en doel van de back-up documenteren. Voor grotere wijzigingen zal een vergelijking met Sophos Firewall Config Studio later helpen om configuratieverschillen voor en na de wijziging te kunnen begrijpen.

Automatische back-ups instellen

Om ervoor te zorgen dat back-ups niet worden vergeten, moet een automatische back-up worden ingesteld. Onder Frequency kunt u dagelijkse, wekelijkse of maandelijkse back-ups definiëren.

De automatisch gegenereerde back-ups kunnen lokaal op de firewall, op een FTP-server of via e-mail worden opgeslagen. De opslaglocatie is minder belangrijk dan het proces eromheen:

• Iedereen die back-ups via e-mail of op een externe server opslaat, moet de codering en toegangsbeveiliging controleren.
• Lokale back-ups op de firewall helpen niet als het apparaat volledig vervangen of opnieuw geïnstalleerd moet worden.
• Op de firewall zelf blijft alleen de meest recente lokale back-up relevant. Als u oudere versies moet bewaren, moet u deze bewust downloaden of extern opslaan.
• Als het om FTP- of e-mailback-ups gaat, moeten niet alleen de instellingen worden gecontroleerd. Ook de levering, ophaling, toestemming en vindbaarheid moeten worden getest.
• Centrale back-ups zijn handig, maar mogen niet het enige bekende herstelpad zijn.
• Automatische back-ups vervangen niet de handmatige back-ups vlak vóór risicovolle wijzigingen.
• Oude back-ups moeten worden beheerd met bewaartermijn, toegang en verwijderingsproces. Gebruik bij FTP-back-ups en Backup prefix geen complexe speciale tekens zonder test. Sophos kent beperkingen voor prefix, gebruikersnaam en wachtwoord. Na de inrichting telt niet de opgeslagen instelling, maar een echte test met back-up, download en restore.

Als de firewall is aangesloten op Sophos Central, kan centrale opslag van configuratieback-ups ook zinvol zijn. De centrale verbinding wordt beschreven in het artikel Sophos Firewall verbinden met Sophos Central.

Organiseer centrale back-ups correct

Sophos Central kan back-ups van de firewallconfiguratie plannen, deze onmiddellijk maken, downloaden en beschikbaar maken voor later herstel. Het centrale pad bevindt zich op:

My Products > Firewall Management > Backup

Centrale back-ups zijn nuttig omdat ze niet op de firewall zelf staan en naar het account Health Check stromen. Niettemin vereist dit back-uppad een bewuste bediening:

• De globale back-upfrequentie in Sophos Central begint als Never. Bij handmatige configuratie via Schedule Backup kan de UI een andere voorgestelde waarde tonen. Wanneer een firewall automatisch als eerste aan het back-upschema wordt toegevoegd, zet Sophos Central de frequentie eenmalig op Monthly, startend op de eerste van de maand. Als een firewall ondanks een geactiveerde Send configuration backup to Sophos Central niet in het schema verschijnt, helpt Schedule Backup > Add new firewall; anders het vinkje uitzetten, Apply, opnieuw aanzetten, Apply en daarna in Sophos Central accept-services uitvoeren.
• Geplande centrale back-ups worden uitgevoerd om 08:00 uur in de tijdzone van de Sophos Central-regio. Deze tijd kan niet worden aangepast.
• Sophos Central probeert het maken van een back-up maximaal vijf keer. Als het daarna nog steeds mislukt, ontstaat een alert en wordt een e-mail naar de Central-beheerder gestuurd.
• Centraal bewaart de vijf meest recente back-ups. Een back-up kan ook permanent worden bewaard totdat deze wordt vervangen of verwijderd.
• Bij het downloaden vanuit Central wordt de back-up opnieuw gecodeerd met een nieuw wachtwoord. Dit wachtwoord wordt dan ook meegenomen in het herstelproces.
• Wanneer een firewall uit Sophos Central Beheer wordt verwijderd, verwijdert Sophos ook de bijbehorende centrale back-upbestanden. Voordat u accounts wijzigt, tenantopruiming of RMA uitvoert, moet u vooraf de vereiste back-ups downloaden.
• Bij HA-clusters zijn de primaire en secundaire clusters opgenomen in het back-upschema, maar wordt de back-up gemaakt door de primaire.

Central Backup is daarom een goed aanvullend herstelpad, maar geen reden om lokaal herstel, SSMK, beheerderstoegang en sitedocumentatie te verwaarlozen.

Back-up veilig opslaan

Firewall-back-ups bevatten gevoelige informatie over de netwerkstructuur, objecten, regels, services, VPN’s, certificaten en gedeeltelijk beschermde accountgegevens. Daarom moeten ze worden behandeld als gevoelige infrastructuurbestanden.

Deze regels zijn zinvol voor gebruik:

• Bewaar back-upbestanden niet onversleuteld in algemene teammappen.
• Beperk de toegang tot firewallback-ups tot beheerders en herstelmanagers.
• Documenteer het back-upwachtwoord en SSMK afzonderlijk, maar zodat ze kunnen worden gevonden.
• Gebruik een duidelijke naamgeving per locatie of firewall.
• Controleer na het vertrek van de beheerder of de back-upopslag en de toegang tot de wachtwoordbeheerder nog steeds werken.
• Documenteer herstelrelevante informatie zoals WAN-toegangsgegevens, PPPoE, statische providergegevens of HA-poorttoewijzing afzonderlijk.

Een back-up is geen vervanging voor operationele documentatie. Vooral bij HA-clusters, meerdere WAN-uplinks of complexe VPN-omgevingen moet ook worden gedocumenteerd welke interfaces, providergegevens en afhankelijkheden na een herstel eerst moeten worden gecontroleerd.

Herstelpakket per firewall voorbereiden

In een noodgeval verspilt u het grootste deel van uw tijd niet met het uploaden van het back-upbestand, maar met het zoeken naar aanvullende informatie. Voor productieve firewalls zou er daarom voor elke locatie of client een klein herstelpakket moeten zijn.

Dit pakket omvat:

• Laatst gecontroleerde back-up: Basis voor herstel, migratie of reimage.
• Back-upwachtwoord en hoofdsleutel voor beveiligde opslag: Noodzakelijk voor gecodeerde back-ups en beschermde gegevens.
• Serienummer, model en SFOS-versie: Belangrijk voor ondersteuning, licentie- en compatibiliteitscontrole.
• WAN-gegevens en providerinformatie: Noodzakelijk als internettoegang of centrale verbinding ontbreekt na het herstel.
• Interface- en poorttoewijzing: Cruciaal voor XG naar XGS-migraties, Flexi-poorten, VLAN-trunks en HA.
• Admin- en Break Glass-toegang: Maakt lokale toegang mogelijk als VPN, Centraal of SSO nog niet werken.
• Licentie en centrale mapping: Voorkomt verwarring met vervangende hardware, virtuele firewalls of cloudinstances.
• Kritische services en acceptatietests: Na het herstel wordt snel weergegeven of VPN, NAT, WAF, DNS, DHCP en loggen weer werken.

Dit pakket mag niet als onbeschermd tekstbestand naast de back-up worden achtergelaten. Een combinatie van wachtwoordmanager, interne operationele documentatie en duidelijke verantwoordelijkheid is beter. Ten minste twee bevoegde personen moeten weten waar deze informatie zich bevindt en hoe zij er in geval van nood toegang toe kunnen krijgen.

Na een personeelswisseling, verhuizing, verandering van provider, HA-wijziging of grote migratie moet het herstelpakket worden gecontroleerd. Een formeel actuele back-up heeft weinig zin als de gedocumenteerde WAN IP, poorttoewijzing of centrale toewijzing niet meer correct is.

Herstel voorbereiden

Vóór een herstel moet eerst duidelijk worden welk doel wordt nagestreefd. Een herstel naar hetzelfde apparaat na een verkeerde configuratie moet anders worden beoordeeld dan een herstel na een reimage, hardwarevervanging of platformwijziging.

Bereiding:

• Is er een nieuwe back-up van de huidige status?
• Is het back-upbestand duidelijk toegewezen aan de juiste firewall?
• Zijn back-upwachtwoord en SSMK beschikbaar?
• Komt de SFOS-versie van het doelsysteem overeen met de back-up?
• Wordt het herstelpad gedeeld voor de bronversie, doelversie en doelplatform?
• Gaat u herstellen naar identieke hardware, een ander model, virtueel apparaat of cloud?
• Zal de Backup-Restore Assistant verschijnen of zal er automatische interface mapping plaatsvinden?
• Is er sprake van HA of wordt een HA-back-up teruggezet naar één apparaat?
• Is er lokale beheertoegang als WAN, VPN of Centraal niet onmiddellijk na het herstel werken?
• Is bekend welk WebAdmin IP actief wordt na het herstel?
• Zijn de tijdzone, NTP-server en eventuele handmatige datum-/tijdinstellingen gedocumenteerd?

⚠️ Een herstel overschrijft de huidige configuratie. Op een productieve firewall moet u, indien mogelijk, een nieuwe back-up maken van de huidige status voordat u deze herstelt, zelfs als de huidige configuratie onjuist is. Als migratiepaden niet worden ondersteund, kan de firewall na bevestiging starten met de fabrieksconfiguratie. Deze waarschuwing mag niet worden behandeld en bevestigd als een normaal herstelbericht.

Wat een herstel niet automatisch oplost

Een herstel herstelt de configuratie, maar vervangt geen volledige operationele controle. Na de herstart gelden de beheer-IP, interfaceconfiguratie, Device Access, certificaten, routes en diensten uit de herstelde configuratie weer. Dit betekent dat WebAdmin plotseling toegankelijk kan zijn onder een ander IP-adres dan tijdens de initiële configuratie van de vervangende firewall.

Daarnaast moet je bewust op deze punten letten:

• Handmatige datum- en tijdwaarden worden niet volledig hersteld naar de operationele status. Tijdzone, NTP en huidige tijd moeten na het herstel worden gecontroleerd.
• Het wachtwoord van het standaard admin-account wordt tijdens het herstellen niet vervangen door de back-up. De doelfirewall behoudt het bestaande standaard beheerderswachtwoord.
• Logboeken, rapporten en externe monitoringgegevens zijn geen vervanging voor een configuratieback-up en moeten afzonderlijk worden geback-upt of centraal worden opgeslagen.
• Certificaten, VPN’s, centrale verbinding, syslog-doelen en meldingen kunnen na een herstel technisch aanwezig zijn, maar nog steeds niet correct functioneren vanwege de tijd, DNS, routing of een gewijzigd doelplatform.
• Een herstel naar andere hardware lost poort- en interfaceverschillen niet automatisch op. De mapping moet overeenkomen met het bekabeling- en zonemodel.
• Modelafhankelijke instellingen kunnen terugkeren naar de standaardwaarden bij herstel naar een ander platform als ze niet op het doelapparaat passen. Het gaat hierbij bijvoorbeeld om hardware- of instance-specifieke performance en poortmogelijkheden.
• De Sophos Central-registratie blijft alleen behouden bij herstel naar dezelfde firewall. Herstel naar andere hardware of HA meldt de firewall af bij Sophos Central. Na het herstel moet deze opnieuw worden geregistreerd, en moeten Security Heartbeat, Sophos ZTNA, Central Management, Central Backup, Central Reporting en de Task Queue elk afzonderlijk worden gecontroleerd en zo nodig opnieuw geconfigureerd. Bij groepsbeleid hoort ook de groepslidmaatschap bij deze nacontrole.

Plan een hersteltest zonder productierisico

Een hersteltest is nuttig, maar moet niet lichtvaardig worden uitgevoerd op een productieve firewall. Het doel is niet om productieve apparaten regelmatig te overschrijven, maar om aantoonbaar te controleren of de belangrijkste herstelvereisten werken.

Afhankelijk van de omgeving kan een veilige hersteltest er als volgt uitzien:

• Back-upbestand ophalen uit geplande opslag.
• Controleer de bestandsnaam, datum, firewallnaam, serienummer en SFOS-versie.
• Controleer het back-upwachtwoord en SSMK in de wachtwoordbeheerder.
• Voer een compatibiliteitscontrole voor back-up-herstel uit voor het geplande doelmodel.
• Documenteer interface mapping en poortafwijkingen vóór een migratie.
• Controleer de geplande doelversie aan de hand van de ondersteunde upgrade- en back-upherstelpaden.
• Test in een laboratorium of vervangende firewall of de backup algemeen geaccepteerd wordt.
• Laat geen productieve VPN’s, WAN-toegangen of centrale verbindingen ongecontroleerd actief na een testherstel.

Als er geen laboratorium- of vervangende firewall is, is er minimaal één organisatorische test mogelijk: back-up vinden, toegang controleren, wachtwoord/SSMK bevestigen, doelplatform evalueren met de compatibiliteitscontrole en het proces in het herstelrunbook doorlopen. Dit vervangt geen echt herstel, maar voorkomt wel veel klassieke noodproblemen.

Voor kritische locaties moet ook duidelijk zijn hoe de firewall na een reimage of hardwarevervanging weer toegankelijk wordt: lokale toegang, beheerpoort, WAN-data, licentiestatus, Sophos Central-toewijzing en contact op locatie. Deze informatie hoort niet alleen thuis in de back-up, maar ook in aparte operationele documentatie.

Back-up herstellen

Het herstel vindt tevens plaats op:

Backup & Firmware > Backup & Restore

Basisproces:

1. Bereik de doelfirewall via WebAdmin.
2. Bewaar de huidige status, indien nog mogelijk.
3. Selecteer in Restore configuration via Choose file het back-upbestand.
4. Voer indien nodig Encryption password of SSMK in.
5. Start Upload and Restore.
6. Wacht op opnieuw opstarten en herstel.
7. Open WebAdmin via het beheer-IP van de herstelde configuratie.
8. Controleer tijdzone, NTP en huidige tijd.
9. Controleer vervolgens netwerk, diensten, VPN, HA en centrale verbinding.

Tijdens een herstel vervangt de geïmporteerde configuratie de huidige configuratie, verwijdert de lokaal opgeslagen back-up op de firewall en start de firewall opnieuw. Daarom moet de gebruikte back-up vóór het herstel extern beschikbaar blijven. Als de enige kopie zich op de doelfirewall bevindt, is het herstelproces onnodig kwetsbaar.

Als een nieuwe of vervangen Sophos Firewall wordt geïmplementeerd, kan de back-up worden geïmporteerd na de eerste toegang tot het apparaat. Het initiële IP-adres en de initiële toegang zijn afhankelijk van het betreffende model en implementatietype. Voor hardwareapparaten is lokale initiële toegang gebruikelijk via het standaard beheer-IP of de installatiewizard.

Zodra de firewall toegankelijk is en de installatiewizard is voltooid, kan het herstel worden uitgevoerd zoals hierboven beschreven.

Herstel naar andere hardware of andere platforms

Vooral bij het migreren tussen XG en XGS of tussen hardware, virtueel apparaat en cloud, moet u controleren of de back-up compatibel is voordat u herstelt. Sophos biedt hiervoor een openbare Backup-restore compatibiliteitscontrole aan.

Bovendien moet de doelversie correct zijn. Sophos maakt onderscheid tussen gedeelde upgrade- en back-upherstelpaden en niet-gedeelde migraties. Als een firewall vóór het opnieuw opstarten waarschuwt dat de geplande migratie niet wordt ondersteund, moet u dit niet zomaar bevestigen. Na een bevestigde, nog niet vrijgegeven migratie start de firewall mogelijk met de fabrieksconfiguratie, waardoor de huidige configuratie verloren gaat.

Voor een productief herstel betekent dit:

• noteer eerst de bronversie, doelversie, doelmodel en platform
• Werk de doelfirewall bij naar een ondersteunde SFOS-versie voordat u deze herstelt
• Voer een compatibiliteitscontrole voor back-up en herstel uit voor de specifieke combinatie
• Neem waarschuwingen in de herstel- of upgradedialoog serieus en documenteer ze
• Als u het niet zeker weet, controleer dan eerst of er vervangende hardware is of in een testomgeving

Backup-Restore Assistant en automatische interfacemapping

Of de Backup-Restore Assistant verschijnt, hangt af van concrete versie- en platformvoorwaarden, niet alleen van een “nieuwere” back-up:

• De back-up komt van een appliance (XG, SG met SFOS, XGS, virtueel of cloud) waarop SFOS 19.5 MR4 of nieuwer draaide.
• De restore wordt uitgevoerd op SFOS 20.0 MR2 of nieuwer.
• De restore wordt uitgevoerd naar een XGS-serie, virtuele of cloud-appliance.
• Bij restore naar een XG- of SG-serie verschijnt de Assistant niet.

De Assistant helpt bij het toewijzen van interfaces wanneer een back-up van XG, SG met SFOS of XGS wordt hersteld naar een XGS-serie, virtuele appliance of cloudfirewall. Dit is vooral belangrijk als de doelfirewall minder poorten, andere poortnamen, wireless-varianten of Flexi-Port-modules heeft.

Bij back-ups uit SFOS 19.5 MR3 of ouder en bij elke restore naar XG/SG ontbreekt de Assistant. Dan wijst de firewall interfaces automatisch toe. Dat is sneller, maar risicovoller omdat de toewijzing niet bewust in de Assistant wordt bevestigd. Na zo’n restore moeten interfaces, zones, gateways, VLANs, HA-link, SD-WAN-routes, NAT-regels en VPNs bijzonder zorgvuldig worden gecontroleerd.

De belangrijkste bijzonderheden bij interfacemapping in één overzicht:

Pseudo-poorten geven aan dat er nog een operationele poortbeslissing openstaat. Na de restore moeten ze worden gecontroleerd, naar een actieve poort worden verplaatst of netjes worden verwijderd. Voor verwijderen open je de pseudo-poort onder Network > Interfaces, zet je de zone op None en herstart je de firewall. Ongebonden pseudo-poorten met VLAN-configuratie worden daarbij niet automatisch verwijderd en vragen extra opschoning.

Verdere punten om na de restore te verduidelijken:

Als de poorttoewijzing anders is, moet u na het herstel meestal een interfacetoewijzing controleren of herwerken. Vóór migraties van XG naar XGS is het artikel Wat is het verschil tussen een XG- en XGS-firewall? ook relevant.

Na grote herstel- of migratiewerkzaamheden kan een vergelijking van de configuraties helpen. Sophos Firewall Config Studio gebruiken laat zien hoe u back-ups voor en na een wijziging kunt vergelijken en specifiek kunt controleren op onverwachte verschillen.

Cloud- en virtuele firewalls

Als het gaat om virtuele of cloudfirewalls, moet u niet alleen vertrouwen op hypervisor-, snapshot- of cloudproviderback-ups. Sophos ondersteunt het ingebouwde back-up- en herstelmechanisme van de firewall voor back-ups van de firewallconfiguratie. Platformback-ups kunnen nuttig zijn als extra bescherming van de infrastructuur, maar vervangen niet de ondersteunde configuratieback-up.

In de praktijk betekent dit: VM-snapshot, cloudimage of marktplaatsmechanisme kunnen helpen bij het herstellen van de instance. Voor een schone SFOS-configuratie, migratie of ondersteuningsanalyse heeft u nog steeds een geldige Sophos firewall-back-up nodig met de juiste SSMK, back-upwachtwoord, doelversie en gedocumenteerde interface-toewijzing.

Controleer na herstel

Na het herstel moet u niet alleen controleren of WebAdmin toegankelijk is. De firewall kan toegankelijk zijn en toch belangrijke services verkeerd verwerken.

Controleer onmiddellijk na het herstel:

• WebAdmin IP, toegestane beheernetwerken en Device Access.
• Interfaces, zones, VLAN’s, bruggen, LAG’s en aliasinterfaces.
• WAN-uplinks, PPPoE, statische providergegevens en standaardgateway.
• SD-WAN-routes, statische routes en dynamische routering.
• Firewallregels, NAT-regels, WAF-regels en regelvolgorde.
• IPsec, SSL VPN, Sophos Connect, RED en toegang op afstand.
• Certificaten, CA-certificaten, WebAdmin-certificaat en TLS Inspection.
• DNS, DHCP, NTP, tijdzone en authenticatieserver.
• HA-status wanneer een cluster wordt gebruikt.
• Licentiestatus, patroonupdates, Hotfixes en Sophos Central synchronisatie.
• Logging, syslog-doelen, centrale firewallrapportage en lokale rapporten.

Afhankelijk van het probleem helpen Log Viewer, Policy Test en Packet Capture, Packet Capture in WebAdmin en Services en Logboeken bij de technische controle.

Acceptatietest na herstel

Een herstel is pas voltooid als de belangrijkste operationele functies zijn bevestigd door middel van echte tests. Een toegankelijke WebAdmin bewijst alleen dat de firewall kan worden bediend. Het bewijst niet dat routing, NAT, VPN, WAF, authenticatie of loggen weer correct werken.

Er zou daarom een korte acceptatiematrix moeten zijn voor productieve firewalls. Deze matrix hoeft niet ingewikkeld te zijn, maar moet per locatie specificeren welke test er na een herstel moet worden uitgevoerd en wie het resultaat documenteert.

Nuttige verplichte toetsen zijn:

• Beheer: Open WebAdmin vanuit het beheernetwerk en test de tweede beheerderstoegang. De verwachting is dat toegang alleen werkt vanaf toegestane netwerken.
• Internettoegang: Testclient in LAN of client-VLAN roept gedefinieerde externe doelen op. De juiste firewallregel, NAT-regel en WAN-route moeten effectief zijn.
• DNS en DHCP: Klant ontvangt adres en verwerkt interne en externe namen. DHCP-gebied, DNS-server en DNS-verzoekroutes moeten overeenkomen.
• Site-to-Site VPN: Een gedefinieerde host per site wordt in beide richtingen bereikt. Tunnels, routing en firewallregels moeten overeenkomen.
• Toegang op afstand: Testgebruiker stelt SSL VPN, IPsec of Sophos Connect in. Login, MFA, profiel, DNS en interne doelen moeten werken.
• WAF of DNAT: Gepubliceerde dienst wordt extern getest. Certificaat, regel, backend en logging moeten passen.
• Authenticatie: Controleer AD, LDAP, RADIUS, STAS of Entra SSO met testgebruiker. De gebruiker moet worden herkend en aan de verwachte regel voldoen.
• Loggen: Controleer Log Viewer, Syslog, Centrale Rapportage of SIEM. Herstel- en testverkeer moet duidelijk zichtbaar zijn.
• HA: Controleer clusterstatus, rollen en synchronisatie. Primaire en Auxiliaire instellingen moeten zich in de verwachte staat bevinden.

Een gedefinieerd stoppunt is belangrijk. Als basistests zoals WAN, DNS, Remote Access of HA na een herstel niet werken, mogen correcties niet op veel plaatsen parallel worden uitgevoerd. Het is beter om een ​​beperkt foutgeval te hebben met tijd, testbron, doel, betrokken regel en logfragment. Dit maakt duidelijk of het probleem voortkomt uit de back-up, de interface mapping, de doelhardware of een daaropvolgende wijziging.

Typische fouten

• Back-up wordt alleen lokaal op de firewall opgeslagen: Deze is niet toegankelijk in geval van een hardwaredefect of reimage. Back-ups moeten extern worden opgeslagen en beschermd.
• SSMK niet gedocumenteerd: Het herstellen van beveiligde gegevens kan mislukken of aanzienlijk langer duren. De SSMK hoort thuis in het herstelproces.
• Oude SSMK kan niet meer worden gevonden na sleutelwijziging: Oudere back-ups kunnen niet meer worden gedecodeerd. Eerdere SSMK-versies moeten gedocumenteerd blijven met tijdsperiode en firewallreferentie.
• Back-up zonder versie- of apparaatreferentie: Het verkeerde bestand is geïmporteerd. Firewallnaam, serienummer, SFOS-versie en datum maken deel uit van de back-updocumentatie.
• Geen daadwerkelijke back-up vóór herstel: Het pad terug naar de huidige status ontbreekt. Er moet een nieuwe back-up worden gemaakt vóór een productief herstel.
• Hersteld WebAdmin IP niet bekend: Na het herstel lijkt de firewall offline, ook al draait deze op een ander IP-adres. Beheer-IP vooraf plannen vanaf back-up en lokale toegang.
• Tijd en NTP niet gecontroleerd na herstel: VPN, certificaten, authenticatie of centrale verbinding gedragen zich mogelijk onjuist. Controleer de tijdzone, NTP en huidige tijd onmiddellijk na het herstel.
• Niet-gedeeld herstelpad bevestigd: De firewall start met de fabrieksconfiguratie of het herstel mislukt onduidelijk. Doelversie, bronversie en compatibiliteitscontrole moeten vóór het herstel worden gecontroleerd.
• Poorttoewijzing niet aangevinkt: Interfaces komen verkeerd terecht na migratie. Er moeten compatibiliteitscontroles en interface-mapping worden voorbereid.
• Automatische interfacetoewijzing overgenomen zonder controle: WAN, VLAN, VPN of HA-link staan op de verkeerde poorten. Vergelijk na het herstel elke interface met het bekabeling- en zonemodel.
• HA-context genegeerd: Het cluster start niet netjes of de verkeerde rol wordt actief. HA-rollen, firmwareniveau en herstelvolgorde moeten worden gepland.
• Alleen WebAdmin aangevinkt: VPN, NAT, WAF of DNS-problemen blijven onopgemerkt. Na het herstel zijn echte servicetests nodig.

Operationele checklist

Regelmatig:

• Activeer automatische back-ups of definieer een centraal back-upproces.
• Controleer back-upopslag, toegang en retentie.
• Controleer SSMK en back-upwachtwoord in de wachtwoordbeheerder.
• Houd het herstelpakket up-to-date per locatie of firewall.
• Controleer minimaal steekproefsgewijs of backups gevonden en toegewezen kunnen worden.

Vóór grote veranderingen:

• Handmatige back-up maken en extern opslaan.
• Documenteer de naam van de firewall, het serienummer, de SFOS-versie en het wijzigingsdoel.
• Controleer SSMK, back-upwachtwoord en beheerderstoegang.
• Stel een terugdraai- of herstelplan in.
• Controleer de compatibiliteitscontrole en interface-toewijzing voor migraties.
• Erken geen waarschuwingen over niet-ondersteunde herstel- of migratiepaden totdat er een alternatief plan is opgesteld.

Na een herstel:

• Controleer WebAdmin IP, beheernetwerken en Device Access.
• Testinterfaces, routing, NAT, VPN, WAF, authenticatie en centraal.
• Controleer tijdzone, NTP en huidige tijd.
• Procesacceptatiematrix met echte testbronnen, testdoelen en verwachte logs.
• Beheer HA-status en rollen.
• Controleer logboeken en monitoring.
• Controleer voor doelversies vanaf SFOS 22.0 MR1 opnieuw of een herstel- of importbewerking oude Legacy Remote Access IPsec-configuraties heeft teruggebracht.
• Maak een nieuwe back-up van de herstelde doelstatus.
• Documenteer afwijkingen en vergelijk deze eventueel met Config Studio.

Veelgestelde vragen