Sophos Firewall-firmwareuppdatering: förberedelser och bästa praxis

En firmwareuppdatering av Sophos Firewall bör godkännas först när uppgraderingsväg, backup, åtkomst, systemstatus, HA och återställningsväg är klarlagda. Genomför en firmwareuppdatering av Sophos Firewall beskriver installationen i WebAdmin eller via Sophos Fusion (tidigare Sophos Central).

⚠️ Före varje uppdatering: En aktuell backup, den Secure Storage Master Key som hör till backupen och en konkret rollbackplan måste finnas. För SFOS 22 eller senare ska även uppgraderingskontrollen för SFOS 22 genomföras.

Godkännande i tio punkter

En firmwareändring är redo när alla tio punkter kan besvaras med ja:

1. Aktuell version, målversion och uppgraderingsväg som stöds är dokumenterade.
2. Release notes och known issues har kontrollerats för plattformen och konfigurationen som används.
3. Licens och supporträttighet tillåter installationen.
4. En aktuell backup, backupens lösenord och rätt Secure Storage Master Key finns.
5. Ledigt lagringsutrymme, systemstatus och, för berörda XGS Appliance-modeller, SSD-firmware uppfyller kraven.
6. HA-status, roller och synkronisering är felfria; båda noderna uppfyller kraven.
7. Underhållsfönster, ansvariga, senaste tidpunkt för att avbryta och rollbackkriterier är fastställda.
8. Lokal eller alternativ administrationsåtkomst är förberedd.
9. Tester för WAN, VPN, DNS, NAT, WAF, autentisering och centrala applikationer är definierade.
10. Övervakning, kommunikation och ändringsdokumentation är förberedda.

Om någon punkt saknas bör uppdateringen inte startas under tidspress. Att flytta ett underhållsfönster är billigare än en oplanerad reimage eller insats på plats.

Kontrollera version, plattform och behörighet

En fast driftprocess kontrollerar minst en gång per månad i Sophos Fusion eller under Backup & Firmware > Firmware om en uppdatering finns tillgänglig. Nya release notes och annonserade maintenance releases följs också aktivt. Varje MR ska ingå i uppdateringsplaneringen, eftersom även en ren maintenance release kan innehålla viktiga säkerhetskorrigeringar. Installation, tester och rollback genomförs fortfarande kontrollerat i ett underhållsfönster.

Release notes och uppgraderingsväg

Jämför före ändringen aktuell SFOS-version, målversion och uppgraderingsväg som stöds i release notes. Kontrollera också kända problem för plattform, HA, VPN, routing, autentisering och de funktioner som faktiskt används.

Sophos Firewall kan visa en varning för en migreringsväg som inte stöds. Om bytet ändå bekräftas kan brandväggen starta med Factory Configuration och förlora den befintliga konfigurationen. Automatisk rollback skyddar inte vid en uppgraderingsväg som inte stöds. Använd endast en godkänd väg; vid ett inkompatibelt versionsbyte är reimage följt av restore rätt metod.

⚠️ Plattformsgräns: SFOS 21.0 GA och senare versioner stöder inte hårdvaruappliances i XG- och SG-serien. För dessa enheter måste en migrering till XGS Appliance planeras före uppgraderingen.

Uppgraderingskontrollen för SFOS 22 dokumenterar vilka källversioner som stöder direkt uppgradering och hur blockerarna ska tolkas för SFOS 22.0 MR2 Build 546. Matrisen gäller just den builden och är inte en universell uppgraderingsväg för SFOS 22; för varje annan målbuild måste de källversioner som stöds och tillämpliga blockerare kontrolleras i aktuella release notes omedelbart före ändringen.

Två blockerare för SFOS 22 måste uttryckligen uteslutas:

• SFOS 22.0 MR1 och senare: Kvarvarande äldre konfiguration för Remote Access IPsec blockerar uppgraderingen. Lös den enligt Sophos aktuella migreringsanvisningar; att bara inaktivera den räcker inte.
• SFOS 22.0 MR2 och senare: Äldre VLAN-taggning som konfigurerats via CLI på bridge-gränssnitt blockerar uppgraderingen. Identifiera berörda bridges och lös konfigurationen enligt release notes före uppgraderingen.

Den separata kontrollen omfattar övriga SFOS 22-frågor, däribland lagring, gränssnittsnamn, STAS, SSD-firmware och plattformsstöd. För andra målversioner gäller respektive aktuella release notes.

⚠️ Före den första uppgraderingen till SFOS 21 eller senare: Sök efter de reserverade Let’s Encrypt-CA-namnen under Certificates > Certificate authorities. En befintlig post med exakt samma namn kan avbryta migreringen på grund av NC-146082. Ta inte bort CA:n utan kontroll; säkra och kontrollera först backup, privat nyckel, beroende certifikat och tjänster.

Licens och support

Från SFOS 19.0 MR1 tillåts tre kostnadsfria byten till GA-, MR- eller EAP-versioner utan Enhanced Support eller Enhanced Plus Support. Därefter kan firmware fortfarande laddas ned men inte installeras; Install är inaktiverat.

Pattern Updates, hotfixes, reimage, Mandatory Firmware Upgrades och Assistant Firmware Upgrades är undantagna från denna supportregel. Kontrollera ändå före underhållsfönstret att:

• Administration > Licensing visar förväntad licens och supporträttighet.
• Sophos Fusion visar rätt brandvägg och serienummer.
• Målversion och nedladdning är tillgängliga.
• Supportåtkomst, kontaktpersoner och eskaleringsväg är kända.

Om extern åtkomst krävs för ändringen ska den testas i förväg. För Avanet, se Konfigurera supportåtkomst till Sophos Firewall.

Kontrollera automatiska hotfixar separat

Hotfixar är varken en firmwareplats eller en Pattern Update. SFOS 22 söker efter tillgängliga hotfixar var 30:e minut och installerar dem automatiskt som standard. Sophos rekommenderar att inställningen inte ändras. Läs statusen i Device Console före och efter en firmwareändring:

system hotfix show

För SFOS 22 beskriver Sophos att redan installerade hotfixar finns kvar även efter en firmwareuppgradering. Den versionsspecifika listan i SFOS 23 bedöms däremot på nytt efter varje versionsbyte, som förklaras i följande avsnitt. Om kontrollen visar att automatisk installation är avstängd ska det först fastställas vem som stängde av den och varför. Aktivera den igen om det inte finns ett dokumenterat undantag:

system hotfix enable

system hotfix disable stänger endast av den automatiska installationen och är inte ett generellt troubleshootingsteg. En aktiverad status bevisar inte heller att en viss hotfix redan har installerats eller att nedladdningsvägen fungerar. Vid ett konkret fel ska även build, tid, internetåtkomst, loggar och Sophos felreferens kontrolleras.

SFOS 23: verifiera tillämpade säkerhetsuppdateringar

I SFOS 23 visar Backup & firmware > Hotfix: Security updates vilka hotfix-säkerhetsuppdateringar som har tillämpats sedan bytet till den SFOS-version som körs för närvarande. Hotfixar korrigerar det körande systemet utan en firmwareuppgradering och ska inte förväxlas med listan över tillgängliga firmware-images. Automatisk installation av hotfixar måste vara aktiverad; den är aktiverad som standard. system hotfix show kontrollerar denna inställning, men verifierar inte att en viss säkerhetskorrigering har tillämpats.

För ändringsdokumentationen före och efter firmwarebytet:

1. Dokumentera aktiv SFOS-version inklusive build och tidpunkt för kontrollen och öppna sidan Hotfix: Security updates.
2. Sortera posterna efter tillämpningsdatum och dokumentera de uppdateringar som hör till problemet som undersöks. Kolumnen Advisory hänvisar till motsvarande säkerhetsmeddelande för offentligt beskrivna sårbarheter. Interna korrigeringar kan visas utan CVE-ID och utan Advisory-länk.
3. Vid HA ska båda enheterna ingå i efterkontrollen: aktuell Primary tar emot hotfixen, synkroniserar med Auxiliary och där tillämpas hotfixen också. En lyckad kontroll på en enhet ersätter inte verifieringen för klustret.

En sårbarhet kan visas flera gånger eftersom flera hotfixar kan behövas för att åtgärda den fullständigt. En enskild matchande post är därför inte ett generellt bevis på fullständigt skydd. För en konkret säkerhetskorrigering måste kraven i motsvarande säkerhetsmeddelande jämföras med den build som körs och de uppdateringar som faktiskt har tillämpats.

Aviseringar och loggar: Aktivera alternativet Email för Security updates i avsnittet Firmware under System services > Notification list. SNMP-aviseringar är inte tillgängliga för dessa uppdateringar. Hotfix-säkerhetsuppdateringar visas även i Log viewer; deras Audit Logs skapas och vidarebefordras till Sophos Fusion för Central Firewall Reporting. Dessa uppgifter om aviseringar och loggar gäller hotfix-säkerhetsuppdateringar, inte generellt alla hotfix-korrigeringar. Ett uteblivet e-postmeddelande bevisar därför inte i sig vare sig att uppdateringen lyckats eller misslyckats.

Efter ett versionsbyte: SFOS installerar först den nya firmwaren och tillämpar därefter de hotfixar som är tillgängliga för denna version. Den tidigare hotfix-listan tas bort och ersätts av listan för den nya versionen; den är inte ett versionsöverskridande arkiv. Samma korrigering kan visas igen eftersom den har tillämpats separat på den nya versionen. Om tidigare korrigeringar redan ingår i den nya firmwaren kan de saknas som separata hotfix-poster.

En tom lista betyder endast att inga hotfix-säkerhetsuppdateringar ännu har tillämpats och visats för den aktuella versionen. Den bevisar varken avsaknad av skydd, fullständigt skydd eller fungerande automatisk installation. Vid oklarheter ska aktiv version och build, CLI-inställning, säkerhetsmeddelande, release notes och loggar kontrolleras tillsammans; stäng inte av automatisk installation i förebyggande syfte och dra inte slutsatsen att rollback behövs enbart utifrån en tom sida.

Förbered backup, recovery och dokumentation

Backup, SSMK och firmwareplatser

Ladda ned en aktuell konfigurationsbackup före uppdateringen och kontrollera vilken Secure Storage Master Key som hör till den. Dokumentera även backupens lösenord, administratörsåtkomst, aktiv firmwareversion och målversion i ändringen.

Sophos Firewall behåller högst två firmwareversioner: en aktiv och en inaktiv. Varje partition har ett eget konfigurationsläge. En rollback aktiverar därför inte bara föregående firmware utan även dess konfiguration. Ändringar som gjorts efter uppgraderingen kan gå förlorade när man går tillbaka.

Automatisk rollback är tillgänglig från SFOS 20.0 vid vissa fel under konfigurationsmigrering. Det är en säkerhetsfunktion men ersätter varken backup eller orsaksanalys och är inte tillgänglig för en uppgraderingsväg som inte stöds.

Hela processen beskrivs i Skapa eller återställ en backup av Sophos Firewall. Om ett normalt versionsbyte inte är möjligt, se Installera om Sophos Firewall OS med ett USB-minne.

Fastställ rollbackkriterier i förväg

Fastställ före start hur länge ett fel ska analyseras och när recovery ska inledas. En rollback är lämplig om WAN, HA, centrala VPN-tunnlar eller produktionskritiska publiceringar inte kan stabiliseras inom avtalad tid. För en enskild regel, ett objekt eller en extern tjänst är riktad troubleshooting ofta bättre.

För en normal Maintenance Release räcker backup, skärmbild av firmwaresidan, underhållsfönster och testresultat som dokumentation. Vid större ändringar hjälper Sophos Firewall Config Studio till att jämföra konfigurationer, och Audit Trail registrerar ändringar under underhållsfönstret.

Kontrollera systemstatus, lagring och HA

Lagring och SSD

Kontrollera i WebAdmin före en större uppgradering att:

• Control center inte visar några olösta kritiska varningar.
• Backup & Firmware > Firmware visar de förväntade firmwareplatserna.
• Diagnostics > Log viewer inte innehåller återkommande system- eller migreringsfel.
• Relevanta tjänster är stabila.
• Firewall Health Check inte innehåller öppna punkter som påverkar ändringen.

Öppna Device Management > Advanced Shell efter SSH-inloggningen och kontrollera ledigt lagringsutrymme:

df -kh

Om en partition nästan är full ska filer, loggar eller reports inte raderas blint i Advanced Shell. Fastställ först orsaken och använd den dokumenterade rensningsmetoden. Se Kontrollera lagring på Sophos Firewall och hantera reports.

SFOS 22 kan kräva extra lagringsutrymme. På vissa XGS Appliance-modeller måste även SSD-firmware uppdateras först; WebAdmin visar ett meddelande när detta krävs. I ett HA-kluster bedöms varje nod separat. Om en appliance inte uppfyller kraven kan den blockera hela uppgraderingen.

För äldre appliances eller problem med I/O, databas eller reports ska även SSD-hälsan kontrolleras med SMART. Utan ett konkret fynd är manuella ändringar i databaser eller filsystem inte en meningsfull förberedelse.

Sophos nämner en omstart före uppgraderingen endast som ett valfritt sätt att rensa minnescachen. Det är inget krav och orsakar ett extra avbrott. Starta därför endast om i underhållsfönstret, efter att relevanta loggar har sparats och återställningsvägen för hanteringsåtkomst har bekräftats. Om brandväggen uppvisar oförklarad instabilitet ska uppgraderingen stoppas; en omstart får inte ersätta orsaksanalysen eller bara få systemet att tillfälligt verka friskt.

HA-kluster

HA behöver inte inaktiveras för en normal firmwareuppdatering. Före godkännandet måste båda appliances dock vara anslutna, synkroniserade och tydligt identifierbara som Primary respektive Auxiliary. Även en HA-uppdatering kräver ett underhållsfönster eftersom failover kort kan avbryta enskilda sessioner, VPN-tunnlar eller ping.

Dokumentera före start:

• Roller, HA-status och synkronisering.
• HA-länkens status.
• Firmware-, lagrings- och SSD-krav för båda noderna.
• Alternativ administrationsåtkomst.
• Förväntad failover och möjliga korta avbrott.

Auxiliary-appliancen får inte uppdateras separat. Genomförandeartikeln beskriver den exakta ordningen med uppdatering av Auxiliary, failover och uppdatering av tidigare Primary. Fler HA-scenarier finns i Sophos Firewall HA-kluster: varianter och underhåll.

Pattern Updates installeras på Primary och synkroniseras sedan till Auxiliary. Hotfixes och deras status måste hanteras separat och kontrolleras på båda enheterna efter underhållsfönstret.

Planera underhållsfönster, Central och tester

Underhållsfönster och åtkomst

Ett underhållsfönster omfattar mer än själva installationstiden:

• Starttid, senaste tidpunkt för att avbryta och rollbackbeslut.
• Ansvariga för brandvägg, nätverk, servrar, applikationer och support.
• Lokal kontakt, out-of-band-åtkomst eller en andra administrationsväg.
• Kommunikationsväg om WAN eller Remote Access slutar fungera.
• Underhållsläge för övervakning och larm.
• Testordning för de viktigaste affärsprocesserna.

För fjärrplatser ska man inte enbart förlita sig på Sophos Fusion eller den befintliga VPN-anslutningen. Om just den vägen slutar fungera under uppdateringen måste en definierad åtkomst- eller eskaleringsväg finnas kvar.

Schemalägg firmware via Sophos Fusion

Firmwareuppgraderingar som hanteras via Central förbereds och övervakas under My Products > Firewall Management > Firewalls. Task Queue gäller gruppolicyer och MDR/API-konfigurationsuppgifter och visar inte firmwareuppgraderingar.

Via Central kan endast målversioner installeras som har nått fasen Available to all i releaseprocessen. Schemalagda uppdateringar startar enligt tidszonen som är inställd på brandväggen, inte enligt administratörens webbläsartid. För internationella platser ska tidszon, lokalt underhållsfönster och målversion dokumenteras i ändringen.

Under uppgraderingen roterar en statusikon bredvid brandväggen och försvinner när den är klar. Därefter måste den aktiva firmwareversionen ändå kontrolleras lokalt. Vid en automatisk rollback visar Central ett motsvarande meddelande bredvid firmwareversionen.

Konfigurera återkommande underhållsuppdateringar

Med Recurring Firmware Upgrade går det att ange ett återkommande underhållsfönster för Sophos Fusion-kontot. Planen gäller alla brandväggar i kontot; när lämplig firmware finns tillgänglig uppdateras de enheter som uppfyller kraven enligt planen. Funktionen måste aktiveras medvetet och garanterar inte att varje brandvägg får en ny version vid varje tillfälle. Backup, uppgraderingsväg, supporträttighet och övriga godkännandepunkter i artikeln är fortfarande förutsättningar.

1. Öppna Recurring Firmware Upgrade under My Products > Firewall Management > Firewalls och aktivera Schedule maintenance updates.
2. Välj Weekly (Default) för ett veckoschema och ange veckodag och tid. För Monthly väljer man först 1st, 2nd, 3rd, 4th eller Last som vecka i månaden och därefter veckodag och tid. Det är inte ett valfritt kalenderdatum.
3. Välj lämpliga pilotbrandväggar under Staging firewalls. Flera enheter kan väljas; nästa avsnitt förklarar valet och dess begränsningar.
4. Aktivera Schedule major version updates först efter ett uttryckligt beslut att automatisera byten till nya huvudversioner. Utan detta alternativ omfattar planen endast underhållsuppdateringar inom den nuvarande huvudversionen. Med alternativet gäller samma schema och stagingprocess även för huvudversioner som uppfyller kraven. Nya funktioner och arkitekturändringar kräver fortfarande en separat kompatibilitetskontroll.
5. Kontrollera inställningarna med Review och korrigera dem vid behov. Först Confirm bekräftar planen.
6. Öppna sedan ikonen Scheduled bredvid varje berörd brandvägg och kontrollera den faktiskt schemalagda tiden. Dokumentera målversion, plats, brandväggens tidszon och lokalt underhållsfönster i ändringen.

Ett möjligt månadsfönster är Monthly, 2nd, söndag, 02:00. Exemplet betyder den andra söndagen i månaden klockan 02:00 i respektive brandväggs tidszon. Det är ingen rekommendation för alla platser: fönstret måste passa verksamhetens öppettider, backupkörningen, ansvariga personers tillgänglighet och de efterföljande testerna. Platser i olika tidszoner startar inte samtidigt. Kontrollera därför varje brandväggs tidszon och de visade tiderna före bekräftelsen.

För HA-par schemalägger Sophos Fusion uppgraderingsuppgiften på Primary. Auxiliary uppdateras automatiskt genom den befintliga HA-uppgraderingsprocessen och får ingen separat manuell uppgift. HA-kontrollerna och de möjliga avbrotten i avsnittet HA-kluster gäller även vid återkommande schemaläggning. Varken starttiden eller en statusikon som visar att uppgraderingen lyckats garanterar en fast sluttid eller avbrottsfri drift; underhållsfönstret måste också rymma validering och vid behov rollback.

Staging är en teknisk kontroll, inte ett godkännande av applikationerna

Stagingbrandväggar får firmwaren först. Om tjänsten bedömer uppgraderingen som lyckad uppdateras övriga brandväggar enligt schemat. Om en staginguppgradering misslyckas stoppas utrullningen och de berörda brandväggarna återgår till tidigare firmware. Orsaken måste åtgärdas innan schemat återupptas. Den befintliga planen för backup och återställning behövs fortfarande: tjänstens mekanism innebär inte en garanterad återställningsväg för varje tänkbart fel.

Lämpliga pilotenheter representerar de funktioner och plattformar som används, och ett fel på dem måste kunna hanteras. En plats med enbart internetåtkomst testar exempelvis inte automatiskt andra platsers WAF- eller VPN-konfiguration. Om inga stagingbrandväggar har valts uppdateras alla brandväggar som uppfyller kraven direkt enligt schemat; det saknas då ett föregående pilotsteg.

⚠️ Inget manuellt godkännandesteg: Lyckad staging enligt tjänsten bevisar inte att DNS, VPN, publicerade tjänster eller verksamhetsapplikationer fungerar. Funktionstesterna som beskrivs nedan krävs fortfarande. Något manuellt godkännandesteg mellan lyckad staging och den övriga utrullningen är inte belagt här för detta förfarande. Om piloten först måste godkännas utifrån verksamhetens krav får man inte förlita sig på att tjänsten väntar; aktivera automatisk schemaläggning först när den valda proceduren uppfyller detta krav.

Ändra eller hoppa över enskilda tillfällen, eller justera staging

Utan en återkommande plan konfigurerar man en enskild uppdatering via den blå pilikonen bredvid brandväggen och Schedule upgrade: välj målversion, ange Immediately eller At, välj datum och tid för At och bekräfta med Schedule upgrade. När en återkommande plan finns använder man i stället följande åtgärder för enskilda brandväggar. De ändrar inte den återkommande planen för övriga brandväggar.

• Override schedule: Öppna ikonen Schedule bredvid brandväggen och välj Override schedule. I fönstret Firmware upgrades väljer man målversion och Immediately eller At. Ange datum och tid för At via kalenderikonen och bekräfta med Override schedule. Immediately startar uppgiften utan en senare schemalagd tid och får därför bara användas i ett redan godkänt underhållsfönster. Kontrollera den valda versionen via ikonen Release notes; när man håller pekaren över ikonen Clock visas datum, tid och lokal brandväggstid för den aktuella planen. Kontrollera den visade schemaläggningen igen efter ändringen.
• Skip occurrence: Öppna ikonen Schedule och välj Skip occurrence om endast nästa planerade uppdatering för denna brandvägg ska hoppas över. Uppgiften flyttas till nästa återkommande tillfälle. För ett veckoschema på fredagar innebär det följande fredag, inte ett permanent undantag. Kontrollera den nya tiden och jämför den på nytt med underhållsfönstret.
• Remove from upgrade staging: Via ikonen Schedule öppnar man Remove from upgrade staging. I fönstret Recurring Firmware Upgrade Schedule avmarkerar man den berörda brandväggen under Staging firewalls och väljer sedan Review och Confirm. Detta tar bort pilotrollen, inte deltagandet i den allmänna firmwareplaneringen. Kontrollera därefter de återstående stagingvalen och brandväggens schemalagda tid. Om enheten ska bli pilot igen väljer man den på nytt i den återkommande planens stagingval och bekräftar planen med Review och Confirm.

Om en målversion saknas kontrollerar man först fasen Available to all i stället för att kringgå begränsningen med en oplanerad lokal uppladdning. Om tiderna inte stämmer med ändringen jämför man först brandväggens tidszon och den lokala tid som visas av Clock. Efter ett stagingfel kontrollerar man aktiv firmware, rollbackmeddelande och loggar, utreder orsaken och genomför de verkliga funktionstesterna innan fler uppdateringar godkänns. En schemaändring eller borttagning från staging ångrar inte en firmwareuppdatering som redan har genomförts; då gäller de rollback- och återställningsprocedurer som beskrivs ovan.

Verkliga funktionstester

Enbart ping bevisar inte att brandväggen fungerar korrekt efter uppdateringen. Definiera konkreta tester i förväg med source, destination och förväntat resultat:

• Internetåtkomst och DNS-upplösning.
• DHCP, VLAN, WAN-uplinks och SD-WAN-rutter.
• Site-to-Site VPN, Remote Access VPN och RED.
• Brandväggsregler, NAT och publicerade tjänster.
• WAF, Web Protection och TLS Inspection.
• LDAP, RADIUS, Microsoft Entra ID och annan central autentisering.
• E-postflöde och verksamhetskritiska applikationer.
• Syslog, SIEM och övervakning.

Validera efter uppdateringen

Kontrollera efter omstarten först den aktiva versionen och den förväntade inaktiva platsen under Backup & Firmware > Firmware. Därefter:

• Kontrollera Control center efter nya varningar eller en automatisk rollback.
• Verifiera gränssnitt, WAN, SD-WAN, HA-roller och synkronisering.
• Validera VPN, RED, DNS, DHCP, regler, NAT, WAF och autentisering med de förberedda testerna.
• Kontrollera status för patterns och hotfixes.
• Verifiera Sophos Fusion-synkronisering samt övervakning, syslog och SIEM.
• Dokumentera resultat, tider, avvikelser och eventuella uppföljningsåtgärder i ändringen.

Om en enskild funktion slutar fungera ska Log Viewer, Policy Test, Packet Capture och relevanta serviceloggar användas först. Se Testa en brandväggsregel med Log Viewer, Policy Test och Packet Capture och Troubleshooting för Sophos Firewall: tjänster och loggar.

FAQ