Controleer Sophos Firewall vóór SFOS 22-upgrade

SFOS 22 brengt belangrijke architectuurwijzigingen naar de Sophos Firewall. Voor beheerders is het daarom niet alleen interessant welke nieuwe functies na de update beschikbaar zijn. Belangrijker is eerst de vraag of de eigen firewall probleemloos naar SFOS 22 kan worden bijgewerkt.

Deze handleiding dient als pre-upgrade-check. Het artikel vervangt niet de algemene handleiding voor de Sophos Firewall Firmware Update, maar vult deze aan met de punten die bij SFOS 22 bijzonder snel tot problemen kunnen leiden: ondersteund platform, interface-namen, opslagruimte, back-up, HA-status, Legacy Remote Access IPsec, policy-based IPsec, NAT en rollback-plan.

Videohandleiding

Kort gezegd: de upgrade mag pas worden gestart wanneer platform, upgradepad, back-up, opslagruimte, HA-status, VPN-afhankelijkheden en een terugvalroute schriftelijk zijn opgehelderd. Als een van deze punten onduidelijk blijft, is het onderhoudsvenster meestal te vroeg gepland.

Vóór het onderhoudsvenster moeten vooral deze onderdelen duidelijk zijn:

• Platform: XGS, virtueel, software of Cloud Deployment in plaats van XG-/SG-hardware.
• Firmwarepad: uitgangsversie en direct upgradepad controleren aan de hand van de Release Notes.
• Configuratie: back-up, Secure Storage Master Key en toegang buiten het normale VPN-pad veiligstellen.
• Netwerk: interface-namen, policy-based IPsec, NAT en kritieke testflows documenteren.
• Operatie: HA-status, STAS, Central Management, logs en rollback-beslissing voorbereiden.

Wanneer deze check zinvol is

De check moet worden uitgevoerd vóór elke geplande upgrade naar SFOS 22 of hoger. Het is vooral belangrijk als een van de volgende situaties van toepassing is:

• de firewall draait nog op XG- of SG-hardware
• het apparaat is al over meerdere grote releases bijgewerkt
• er zijn veel VLAN’s, aliassen, bridges, LAG’s, RED- of XFRM-interfaces
• het betreft een kleine desktop-appliance, virtuele firewall of software-appliance
• de firewall draait in een HA-cluster
• Remote Access IPsec VPN wordt of werd in het verleden gebruikt
• er zijn nog UTM9 SSL VPN-tunnels of oude RED 15-, RED 15w- of RED 50-apparaten aanwezig
• policy-based Site-to-Site IPsec, speciale SNAT-regels of VPN-NAT-regels zijn in gebruik
• bridges met handmatig via CLI ingestelde VLAN tags of VLAN-verkeer naar de firewall zelf zijn in gebruik
• STAS of andere gebruikersgebaseerde authenticatie stuurt productieve firewallregels aan
• de firewall wordt beheerd via Sophos Central of moet daarover worden bijgewerkt

Als de firewall al in het dagelijks gebruik instabiel is, diensten regelmatig opnieuw moeten worden gestart of partities sterk gevuld zijn, moet de upgrade niet als reparatiepoging worden gezien. In dit geval eerst de huidige toestand stabiliseren en de oorzaak achterhalen.

1. Controleer platform en upgradepad

SFOS 22.0 en nieuwere versies ondersteunen geen XG- en SG-hardware-appliances meer. Wie nog dergelijke apparaten gebruikt, moet eerst de migratie naar XGS, virtuele firewall, software-appliance of cloudimplementatie plannen. Voor de beslissing tussen oude en nieuwe hardwaregeneraties helpt het artikel Wat is het verschil tussen een XG en XGS Firewall?.

Op ondersteunde platforms moet daarnaast worden gecontroleerd vanaf welke versie wordt bijgewerkt. De SFOS 22 Release Notes tonen welke versies direct naar SFOS 22 kunnen worden gemigreerd. Als een niet-ondersteund pad wordt gekozen, kan de firewall na bevestiging met fabrieksconfiguratie starten. Precies dit risico moet vóór een onderhoudsvenster worden uitgesloten.

Praktische stappen:

1. Noteer de huidige firmwareversie onder Backup & Firmware > Firmware.
2. Documenteer model, serienummer en platformtype.
3. Controleer in de officiële Sophos Release Notes of het directe upgradepad wordt ondersteund.
4. Behandel bij XG- of SG-hardware geen SFOS-22-planning meer als normale update, maar als migratieproject.

Bij migraties naar XGS, virtuele of cloud-appliances is backup/restore vaak onderdeel van het project. Back-ups uit ondersteunde bronversies kunnen naar andere platformen worden gemigreerd; bij nieuwere back-ups ondersteunt Sophos het restoreproces met een assistent voor interface-mapping. Dit vervangt geen migratieplanning, maar is belangrijk zodat XG/SG-vervanging niet wordt verward met een in-place upgrade.

2. Controleer interface-namen vóór de upgrade

Een gemakkelijk over het hoofd te zien upgradepunt betreft de namen van interfaces. Fysieke of logische interfaces kunnen in de WebAdmin-weergave onder Network > Interfaces niet zichtbaar of niet uitklapbaar zijn als een interface-naam, hardware-naam of branch-naam eindigt met tien of meer cijfers.

Dit is ongemakkelijk, omdat het verkeer verder kan worden verwerkt, maar de administratie in WebAdmin plotseling lijkt alsof interfaces ontbreken. Vooral bij migraties, geautomatiseerde naamgevingsschema’s, geïmporteerde configuraties of VLAN-namen met locatie-, klant- of inventarisnummers moet men dit punt vóór de upgrade controleren.

Kritische voorbeelden:

• VLAN_1234567890: eindigt met tien cijfers.
• Branch_1000000001: branch-naam kan de weergave verstoren.
• PortA_2026010101: bedoeld als beschrijvend, maar risicovol cijferblok aan het einde.

Praktische stappen:

1. Open Network > Interfaces.
2. Controleer fysieke interfaces, VLAN’s, aliassen, bridges, LAG’s, RED-interfaces en XFRM-interfaces.
3. Zoek naar namen die eindigen met tien of meer cijfers.
4. Wijzig getroffen namen vóór de upgrade naar een kortere of duidelijk gescheiden schrijfwijze.
5. Controleer na de wijziging of firewallregels, NAT-regels, SD-WAN-routes, DHCP, VPN en documentatie nog begrijpelijk zijn.

Beter zijn namen waarbij cijfers niet als lange blok aan het einde staan. In plaats van VLAN_1234567890 is bijvoorbeeld VLAN-1234567890-Client of een vaknaam zoals Client-VLAN-100 leesbaarder en operationeel robuuster.

Als na een upgrade interfaces in de WebAdmin-weergave ontbreken, moet men niet meteen aannemen dat de netwerkconfiguratie verloren is. Controleer eerst of het gedrag overeenkomt met de interface-naamproblematiek, of verkeer nog steeds loopt en of de getroffen namen moeten worden aangepast. Voor de algemene interfaceplanning past Sophos Firewall Zonen en Interfaces configureren.

3. Controleer legacy-afhankelijkheden

Bij een upgrade van oudere SFOS-versies richting versie 22 worden de opmerkingen uit SFOS 21.5 gemakkelijk over het hoofd gezien. Dat is riskant, omdat sommige beperkingen al gelden vanaf 21.5 GA en dus ook invloed hebben op het upgradepad naar SFOS 22.

Voor het onderhoudsvenster moeten deze legacy-afhankelijkheden worden uitgesloten of bewust worden gemigreerd:

• UTM9 SSL VPN: Firewalls vanaf 21.5 GA bouwen geen SSL VPN-tunnels meer op naar UTM9 OS. Zulke verbindingen moeten worden gemigreerd naar SFOS 20.0 MR1 of nieuwer, Site-to-Site IPsec of RED.
• RED 15, RED 15w en RED 50: Deze legacy RED-apparaten worden vanaf 21.5 GA niet meer ondersteund. Als locaties er nog van afhankelijk zijn, hoort de vervanging vóór de firewall-upgrade plaats te vinden.
• Legacy Remote Access IPsec: Vanaf SFOS 22.0 MR1 blokkeert deze oude Remote Access IPsec-configuratie de upgrade. Dit punt wordt hieronder apart gecontroleerd.

Deze afhankelijkheden zijn niet alleen “oude apparaten in de inventaris”. Ze bepalen of filialen, externe gebruikers of tijdelijke verbindingen na de upgrade nog bereikbaar zijn. Voor RED- of UTM9-afhankelijkheden moet vóór het SFOS 22-venster een apart migratieplan bestaan.

4. Controleer opslagruimte en firmware-waarschuwingen

SFOS 22 vereist extra opslagruimte voor nieuwe functies en architectuurwijzigingen. De meeste appliances voldoen aan de vereisten, maar sommige desktop-, virtuele en software-implementaties kunnen een handmatige controle of correctie nodig hebben. Als de firewall op de Control Center- of Firmware-pagina een melding over opslagvereisten toont, mag deze niet worden genegeerd.

Bij virtuele en softwarematige firewalls moet men bijzonder zorgvuldig controleren of de beschikbare virtuele disk en de root- of Primary-partitie passen bij de geplande SFOS-22-upgrade. Sophos beschrijft hiervoor aparte aanwijzingen over de SFOS-22-opslagvereiste en het uitbreiden van virtuele disks in de supportartikelen KBA-000010091 en KBA-000043681. Deze links zijn zinvol als daadwerkelijk een virtuele disk moet worden aangepast; de wijziging moet echter niet spontaan in het firmwarevenster worden geïmproviseerd.

Via SSH kan de vullingsgraad van de partities grof worden gecontroleerd:

df -kh

De uitvoer vervangt geen Sophos-compatibiliteitscontrole, maar helpt bij de inschatting of /, /var, /content of andere partities opvallend vol zijn. Als een partitie erg krap is, moet niet zomaar blind worden bijgewerkt. Eerst nagaan welke gegevens daar liggen, of logs of oude bestanden kunnen worden opgeschoond en of er een Sophos-waarschuwing voor het betreffende apparaat bestaat.

Belangrijk is ook de tijdsplanning: als de firewall tijdens de upgrade partities moet aanpassen, kan de update langer duren dan een normaal onderhoudsrelease. Het onderhoudsvenster moet daarom niet te krap worden gepland.

Als een virtuele disk moet worden uitgebreid, moeten vooraf back-up, Secure Storage Master Key, hypervisor-snapshotstrategie, datastore-capaciteit en terugvalroute duidelijk zijn. Na de aanpassing moeten de partities opnieuw worden gecontroleerd en pas daarna mag de SFOS-22-upgradepoging worden herhaald. Voor algemene opslaganalyse past Sophos Firewall opslagruimte controleren en rapporten beheren.

5. Back-up en herstel voorbereiden

Voor de upgrade is een verse back-up nodig. Dat klinkt banaal, maar is bij grote releases cruciaal. De back-up moet niet alleen worden gemaakt, maar ook vindbaar, ontsleutelbaar en aan een specifiek apparaat toewijsbaar zijn. Het artikel Sophos Firewall Back-up maken of herstellen legt de belangrijkste punten uit rond back-up, herstel en Secure Storage Master Key.

Voor SFOS 22 moeten ten minste deze punten zijn afgehandeld:

• maak een actuele configuratieback-up en sla deze extern op
• documenteer de Secure Storage Master Key als versleutelde back-ups worden gebruikt
• controleer lokale en onderhoudsnetwerktoegang voor de beheerder
• controleer licentiestatus en Sophos Central-toegang
• houd het huidige firmware-image en doel-firmware bij de hand
• definieer een rollback-beslissing: wanneer wordt gewacht, wanneer wordt teruggerold

Bij kritieke locaties moet ook duidelijk zijn wie ter plaatse toegang heeft tot het apparaat en hoe men indien nodig een herinstallatie zou uitvoeren. De herinstallatie is een andere procedure dan een normale firmware-update. Daarvoor is de aparte handleiding Sophos Firewall OS opnieuw installeren.

6. Go/No-Go vóór het onderhoudsvenster vaststellen

Een SFOS-22-upgrade moet niet pas tijdens het onderhoudsvenster worden beslist. Van tevoren moet duidelijk zijn onder welke voorwaarden wordt gestart, gewacht, afgebroken of teruggerold. Dit vermindert hectische beslissingen als de firewall langer nodig heeft, een HA-node niet synchroniseert of een kritieke dienst na de herstart niet werkt.

Zinvolle Go/No-Go-punten:

• Platform ondersteunt SFOS 22: Go als model en upgradepad gecontroleerd zijn. No-Go bij XG-/SG-hardware of onduidelijk upgradepad.
• Back-up en SSMK: Go als back-up extern opgeslagen is en herstelgegevens beschikbaar zijn. No-Go als back-up ontbreekt, niet vindbaar is of de Secure Storage Master Key ontbreekt.
• Remote Access IPsec: Go als legacy-configuratie uitgesloten of gemigreerd is. No-Go als legacy-configuratie aanwezig of onduidelijk is.
• Legacy-locaties: Go als UTM9 SSL VPN en oude RED-apparaten zijn uitgesloten of vervangen. No-Go als een vestiging er nog productief van afhankelijk is.
• Site-to-Site IPsec: Go als policy-based IPsec, NAT en testverkeer gedocumenteerd zijn. No-Go als Traffic Selectors, SNAT of tegenpartij onduidelijk zijn.
• Bridge VLANs: Go als bridge-VLAN-verkeer naar de firewall zelf is gecontroleerd of netjes via VLAN-interfaces is gemodelleerd. No-Go als AD, DNS, Device Access of STAS via onduidelijke bridge-CLI-VLAN-tags loopt.
• HA-status: Go als het cluster stabiel en gesynchroniseerd is. No-Go bij degraded, onsynchrone of onduidelijke HA-status.
• Toegang: Go als lokale beheerderstoegang en onderhoudsnetwerk gecontroleerd zijn. No-Go als toegang alleen afhangt van een onzekere externe route.
• Rollback: Go als beslissingspunt en verantwoordelijken gedefinieerd zijn. No-Go als niemand bindend beslist over wachten of terugrollen.

Voor verspreide locaties moet bovendien duidelijk zijn wie tijdens het onderhoudsvenster bereikbaar is: technische contactpersoon, locatiecontact, persoon met fysieke toegang en beslisser voor rollback. Als de upgrade op afstand wordt uitgevoerd, moet men bovendien controleren of er een alternatieve toegang is, voor het geval VPN, WAN of Central Management tijdelijk niet werkt.

Een terugvalplan is geen zwakte van de wijziging. Het voorkomt dat bij een storing tegelijkertijd firmware, routing, VPN, HA en switching worden gewijzigd. Als na de upgrade een kritieke dienst uitvalt, moet eerst het gedefinieerde validatieplan worden afgewerkt. Pas daarna wordt beslist of een rollback, een herstel, een herinstallatie of een gerichte probleemoplossing zinvoller is.

7. HA-cluster goed voorbereiden

Bij HA-clusters mag niet alleen de actieve firewall worden bekeken. Beide nodes moeten worden ondersteund, dezelfde zinvolle uitgangstoestand hebben en goed synchroniseren. Een upgrade op een al aangetast HA-cluster verhoogt het risico op onnodige uitval.

Vóór het onderhoudsvenster controleren:

• System services > High availability toont een gezonde HA-status.
• Beide apparaten zijn hetzelfde model of een ondersteunde HA-combinatie.
• Firmwarestatus, licentiestatus en abonnement zijn plausibel.
• HA-link, gemonitorde poorten en aangesloten switchpoorten zijn stabiel.
• Het is gedocumenteerd welk apparaat vóór de upgrade actief was.

Voor de algemene HA-planning en de bijzonderheden van Active-Passive, Active-Active, licentieverlening en onderhoud past het artikel Sophos Firewall HA-cluster varianten.

8. Zoek naar Legacy Remote Access IPsec

Vanaf SFOS 22.0 MR1 wordt Legacy Remote Access IPsec VPN niet meer ondersteund. Firewalls met deze legacy-configuratie kunnen niet worden bijgewerkt naar SFOS 22.0 MR1 of nieuwer. Dit is een typische upgrade-blokker, omdat Remote Access IPsec in oudere omgevingen vaak eenmaal is ingesteld en daarna lange tijd niet meer is aangeraakt.

Vóór de upgrade moet men daarom controleren of er oude Remote-Access-IPsec-configuraties aanwezig zijn. Zo ja, dan moet eerst worden gemigreerd naar de huidige Remote-Access-IPsec-configuratie, SSL VPN, ZTNA of een ander passend Remote-Access-ontwerp. De concrete procedure staat in Legacy Remote Access IPsec vóór SFOS 22 MR1 migreren. Voor algemeen IPsec-probleemoplossing helpt daarnaast Sophos Firewall IPsec VPN Troubleshooting.

Praktische stappen:

1. Open in WebAdmin het gedeelte Remote access VPN.
2. Controleer of er een Legacy-Remote-Access-IPsec-configuratie aanwezig is.
3. Documenteer getroffen gebruikers, profielen, pools, authenticatie en verspreide Sophos-Connect-configuraties.
4. Plan een vervangende configuratie en test deze met enkele testgebruikers.
5. Verwijder pas na succesvolle migratie de legacy-configuratie en controleer de firmware-upgrade opnieuw.

Als Sophos Connect wordt gebruikt, moeten ook de bestaande handleidingen voor de Sophos Connect Firewall-configuratie, de Windows-installatie en de macOS-installatie worden meegenomen.

9. Controleer policy-based IPsec en NAT

SFOS 22.0 GA en nieuwere versies veranderen het gedrag van policy-based Site-to-Site IPsec VPN. Daarnaast is in de SFOS-22-release-opmerkingen een opgelost probleem gedocumenteerd waarbij policy-based IPsec-verkeer kon mislukken als de standaard-SNAT-regel was geconfigureerd met een statisch IP-adres in plaats van MASQ.

Dit is geen reden om elke IPsec-setup vooraf om te bouwen. Het is echter een goede reden om policy-based IPsec vóór en na de upgrade bewust te testen. Dit is vooral belangrijk als de firewall meerdere VPN’s, overlappende netwerken, specifieke SNAT-regels, een aangepaste standaard-SNAT-regel of partnernetwerken met vaste bron-IP-verwachtingen gebruikt.

Vóór de upgrade controleren:

1. Identificeer policy-based Site-to-Site-tunnels.
2. Documenteer lokale en externe netwerken of Traffic Selectors.
3. Controleer NAT-regels voor VPN-verkeer, vooral standaard-SNAT, MASQ, specifieke SNAT-regels en regelvolgorde.
4. Definieer per belangrijke tunnel een testgeval met bron, bestemming, service en verwachte richting.
5. Documenteer tegenpartij en retourweg, zodat een post-upgrade-test niet alleen “Ping werkt niet” betekent.

Na de upgrade moet men deze tests niet vermengen met brede verzamelchecks. Beter is een gerichte test per tunnel: Log Viewer, Packet Capture, Firewall Rule ID, NAT Rule ID en byte-teller in ipsec statusall vergelijken. Als de tunnel groen is, maar geen gebruiksverkeer stroomt, past Sophos Firewall IPsec VPN Troubleshooting. Voor de NAT-inzicht helpt NAT op Sophos Firewall begrijpen.

10. Bridge VLANs en verkeer naar de firewall controleren

Een andere SFOS 22-special case betreft bridge-interfaces met VLAN-tags die vroeger via de CLI zijn gezet. In SFOS 22.0 GA en SFOS 22.0 MR1 is een Known Issue gedocumenteerd: VLAN-tagged verkeer dat van de firewall zelf komt of naar de firewall zelf gaat, kan via zulke bridgeconfiguraties niet correct worden verwerkt. Normaal transitverkeer door de bridge kan tegelijk blijven werken.

Dat is verraderlijk, omdat precies de verkeerde zaken kunnen uitvallen: Active Directory, DNS, Device Access, STAS, LDAP, RADIUS of beheerstoegang. Het lijkt dan snel op een authenticatie-, DNS- of regelprobleem, terwijl de oorzaak in het bridge/VLAN-model zit.

Praktische controle:

1. Bridges en VLAN-gebruik onder Network > Interfaces documenteren.
2. Nagaan of VLAN-tags vroeger via CLI op een bridge-interface zijn gezet.
3. Bepalen of AD, DNS, RADIUS, LDAP, STAS, Device Access of beheerverkeer deze VLAN-paden gebruikt.
4. Als de special case past, vóór de upgrade VLAN-interfaces plannen met de bridge-interface als parent.
5. Na de upgrade gericht verkeer van en naar de firewall testen, niet alleen client-naar-serververkeer door de bridge.

De special case wordt uitgebreider beschreven in Sophos Firewall Bridge VLANs vóór SFOS 22 controleren. Voor normale planning van zones, interfaces, VLAN’s en bridges blijft Sophos Firewall zones en interfaces configureren het betere startpunt.

11. Controleer STAS en gebruikersgebaseerde regels

Als STAS actief is, moet het vóór SFOS 22.0 MR1 of nieuwer niet alleen als “werkt in het dagelijks leven” worden afgevinkt. In de lijst met bekende problemen is een probleem gedocumenteerd waarbij de optie Restrict client traffic during identity probe een upgrade naar SFOS 22.0 MR1 kan blokkeren of na de upgrade kan leiden tot herhaalde Identity Probes met kortstondige verkeersonderbrekingen.

Dit betreft vooral omgevingen waarin STAS niet alleen voor rapportage, maar voor productieve gebruikersgebaseerde firewallregels wordt gebruikt. Als de gebruikers-IP-toewijzing kort uitvalt, lijkt dit in de praktijk snel op een regel-, DNS- of applicatieprobleem.

Vóór de upgrade controleren:

1. Open Authentication > STAS.
2. Controleer STAS-status en gebruikte collectors.
3. Controleer of Restrict client traffic during identity probe actief is.
4. Identificeer gebruikersgebaseerde regels die afhankelijk zijn van STAS.
5. Meld een testgebruiker aan en controleer Live Users en Log Viewer.

Als deze optie actief is of al korte onderbrekingen opvallen, moet dit punt vóór het onderhoudsvenster worden opgehelderd. De gedetailleerde procedure staat in STAS op Sophos Firewall instellen.

12. Na de upgrade gericht valideren

Na de herstart is de upgrade niet automatisch voltooid. Pas als de belangrijkste bedrijfsfuncties zijn gecontroleerd, is het onderhoudsvenster netjes afgesloten.

Minimaal controleren:

• juiste firmwareversie is actief
• Network > Interfaces toont fysieke en logische interfaces plausibel aan
• internettoegang en centrale firewallregels werken
• Site-to-Site VPN en Remote Access VPN werken
• policy-based IPsec-tests tonen de verwachte bron-IP en passende NAT-regel
• HA-status is weer gesynchroniseerd
• STAS, AD SSO of andere gebruikerskoppeling werkt, indien productief gebruikt
• Sophos Central Management en Reporting verzenden gegevens
• Log Viewer toont geen nieuwe kritieke fouten
• belangrijke diensten zoals DNS, DHCP, Web Protection, IPS en authenticatie werken zoals verwacht

Als VPN, routing of regels niet zoals verwacht werken, niet meteen op meerdere plaatsen tegelijk wijzigen. Eerst met Log Viewer, Packet Capture en de betrokken service-logs afbakenen. Policy Test is nuttig, maar moet bij SFOS 22.0 GA en SFOS 22.0 MR1 voorzichtig worden gelezen: Sophos documenteert daar een Known Issue waarbij de tool geblokkeerd of verkeerd gematcht verkeer kan tonen, terwijl productieverkeer correct loopt. In dat geval zijn echte testpakketten, Log Viewer, Packet Capture, Rule ID en NAT Rule ID belangrijker dan één Policy Test-resultaat.

Voor gestructureerde troubleshooting zijn Firewallregel testen met Log Viewer, Policy Test en Packet Capture en Sophos Firewall troubleshooting: services en logs nuttige aanvullingen.

13. Bewijs en bedrijfsdocumentatie veiligstellen

Een upgrade is pas netjes afgerond als het resultaat navolgbaar is gedocumenteerd. Dit helpt bij latere storingen, audits, supportgevallen en bij het volgende onderhoudsvenster. Direct na de upgrade moet men daarom niet alleen “werkt weer” noteren, maar concrete bewijzen veiligstellen.

Zinvolle bewijzen:

• Screenshot van Backup & Firmware > Firmware: toont doelversie, actieve firmware en eventuele beschikbare images.
• Screenshot van System services > High availability: toont HA-rol, synchronisatie en clusterstatus na de upgrade.
• Export of screenshot van relevante auditlogs: toont welke wijzigingen in het onderhoudsvenster zijn aangebracht.
• Central- of Syslog-controle: toont of logs en rapporten na de upgrade blijven binnenkomen.
• Lijst met openstaande nazorg: voorkomt dat tijdelijke workarounds permanent worden vergeten.

Als wijzigingen aan regels, interfaces, hosts of services zijn aangebracht, moet men bovendien de Audit Trail Logs controleren. Bij omgevingen met langere logbewaring hoort ook een controle van Central Firewall Reporting of Syslog bij de afsluiting.

Bij meerdere firewalls is het bovendien belangrijk dat back-ups eenduidig kunnen worden toegewezen. In nieuwere SFOS-versies bevatten back-up-e-mails meer identificatiegegevens zoals hostnaam, firmwareversie, serienummer en model. Toch moet men intern nog steeds een eenvoudige upgrade-notitie bijhouden: firewall, locatie, oude versie, nieuwe versie, tijdvenster, verantwoordelijke persoon, testresultaat en openstaande punten.

Als na de upgrade opslag-, hardware- of SSD-waarschuwingen opvallen, moet dit niet in het firmware-ticket ondergaan. Voor deze controle past SSD-gezondheidstoestand op Sophos Firewall controleren.

Checklist voor het onderhoudsvenster

Vóór de upgrade

• Platform en upgradepad gecontroleerd
• Release Notes en bekende waarschuwingen gelezen
• Interface-namen met tien of meer afsluitende cijfers uitgesloten
• Opslagruimte en firmware-waarschuwingen gecontroleerd
• UTM9 SSL VPN-tunnels en oude RED-apparaten uitgesloten of gemigreerd
• Back-up gemaakt en extern opgeslagen
• Secure Storage Master Key beschikbaar
• Go/No-Go-beslissing, terugvalroute en verantwoordelijken vastgesteld
• HA-status gedocumenteerd
• Policy-based IPsec, VPN-NAT en testverkeer gedocumenteerd, indien gebruikt
• STAS en gebruikersgebaseerde regels gecontroleerd, indien gebruikt
• Bridge VLANs en verkeer naar de firewall zelf gecontroleerd als bridges worden gebruikt
• Legacy Remote Access IPsec uitgesloten of gemigreerd
• Rollback-plan gedefinieerd

Tijdens de upgrade

• Statusmeldingen gedocumenteerd
• Geen parallelle wijzigingen aan routing, VPN of switching uitvoeren
• Bij HA-clusters failover en synchronisatie observeren
• Beslissingspunt voor wachten, foutenanalyse of rollback naleven
• Bij onverwachte meldingen niet blind bevestigen, maar oorzaak onderzoeken

Na de upgrade

• Firmwareversie en licentiestatus controleren
• VPN, routing, DNS, DHCP en centrale firewallregels testen
• Policy-based IPsec met gedefinieerde bron-/bestemmingstest controleren, indien gebruikt
• Bridge-VLAN-verkeer naar AD, DNS, Device Access, STAS of beheer testen, indien relevant
• STAS, AD SSO en gebruikersgebaseerde regels met testgebruiker controleren
• HA-synchronisatie en Sophos Central-verbinding controleren
• Log Viewer en relevante service-logs controleren
• Firmware-, HA- en auditbewijzen veiligstellen
• Resultaat en openstaande punten in het bedrijfsjournaal documenteren

FAQ