Sophos Firewall Firmware Update: Vorbereitung und Best Practices

Ein Sophos Firewall Firmware Update sollte erst freigegeben werden, wenn Upgrade-Pfad, Backup, Zugriff, Systemzustand, HA und Rückweg geklärt sind. Die eigentliche Installation im WebAdmin oder über Sophos Fusion (ehemals Sophos Central) beschreibt Sophos Firewall Firmware Update durchführen.

⚠️ Vor jedem Update: Ein aktuelles Backup, der zum Backup gehörende Secure Storage Master Key und ein konkreter Rollback-Plan müssen verfügbar sein. Für SFOS 22 oder neuer zusätzlich den SFOS 22 Upgrade-Check durchführen.

Freigabe in zehn Punkten

Ein Firmware-Change ist bereit, wenn alle zehn Punkte mit Ja beantwortet werden können:

1. Aktuelle Version, Zielversion und unterstützter Upgrade-Pfad sind dokumentiert.
2. Release Notes und Known Issues wurden für die eigene Plattform und Konfiguration geprüft.
3. Lizenz und Support-Berechtigung erlauben die Installation.
4. Ein frisches Backup, Backup-Passwort und passender Secure Storage Master Key sind verfügbar.
5. Freier Speicherplatz, Systemzustand und bei betroffenen XGS Appliance-Modellen die SSD-Firmware passen.
6. HA-Status, Rollen und Synchronisation sind fehlerfrei; beide Nodes erfüllen die Voraussetzungen.
7. Wartungsfenster, Verantwortliche, Abbruchzeitpunkt und Rollback-Kriterien sind festgelegt.
8. Ein lokaler oder alternativer Managementzugriff ist vorbereitet.
9. Tests für WAN, VPN, DNS, NAT, WAF, Authentifizierung und zentrale Applikationen sind definiert.
10. Monitoring, Kommunikation und Change-Nachweis sind vorbereitet.

Fehlt einer dieser Punkte, sollte das Update nicht aus Zeitdruck gestartet werden. Ein verschobenes Wartungsfenster ist günstiger als ein ungeplanter Reimage- oder Vor-Ort-Einsatz.

Version, Plattform und Berechtigung prüfen

Ein fester Betriebsprozess prüft mindestens einmal pro Monat in Sophos Fusion oder unter Backup & Firmware > Firmware, ob ein Update bereitsteht. Zusätzlich werden neue Release Notes und angekündigte Maintenance Releases aktiv verfolgt. Jedes MR gehört in die Updateplanung, weil auch ein reines Maintenance Release wichtige Sicherheitskorrekturen enthalten kann. Installation, Test und Rollback erfolgen trotzdem kontrolliert im Wartungsfenster.

Release Notes und Upgrade-Pfad

Vor dem Change zuerst die aktuelle SFOS-Version, die Zielversion und den unterstützten Pfad in den Release Notes abgleichen. Zusätzlich die bekannten Probleme für Plattform, HA, VPN, Routing, Authentifizierung und die tatsächlich eingesetzten Funktionen prüfen.

Bei einem nicht freigegebenen Migrationspfad kann Sophos Firewall eine Warnung anzeigen. Wird der Wechsel trotzdem bestätigt, kann die Firewall mit Factory Configuration starten und die bestehende Konfiguration verlieren. Ein automatischer Rollback schützt bei einem nicht unterstützten Upgrade-Pfad nicht. Deshalb nur einen freigegebenen Pfad verwenden; für einen inkompatiblen Versionswechsel ist ein Reimage mit anschliessendem Restore der saubere Weg.

⚠️ Plattformgrenze: SFOS 21.0 GA und neuere Versionen unterstützen XG- und SG-Hardware-Appliances nicht mehr. Vor dem Upgrade muss bei diesen Geräten eine Migration auf XGS Appliance geplant werden.

Der SFOS-22-Upgrade-Check dokumentiert die direkten Ausgangsversionen und die Einordnung der Blocker für SFOS 22.0 MR2 Build 546. Diese Matrix gilt nur für diesen Build und ist kein allgemeingültiger SFOS-22-Pfad; bei jedem anderen Ziel-Build müssen die unterstützten Ausgangsversionen und zutreffenden Blocker unmittelbar vor dem Change anhand der aktuellen Release Notes geprüft werden.

Zwei harte SFOS-22-Blocker müssen ausdrücklich ausgeschlossen werden:

• SFOS 22.0 MR1 und neuer: Verbliebene Legacy-Konfiguration für Remote Access IPsec blockiert das Upgrade. Die alte Konfiguration vorab nach dem aktuellen Migrationshinweis von Sophos bereinigen; ein nur deaktivierter Altbestand genügt nicht als Freigabe.
• SFOS 22.0 MR2 und neuer: Legacy-VLAN-Tagging, das per CLI auf Bridge-Interfaces konfiguriert wurde, blockiert das Upgrade. Betroffene Bridges vorab identifizieren und die Legacy-Konfiguration nach den Release Notes auflösen.

Der separate Upgrade-Check deckt weitere SFOS-22-Themen wie Speicherbedarf, Interface-Namen, STAS, SSD-Firmware und Plattformunterstützung ab. Für andere Zielversionen sind deren jeweils aktuellen Release Notes massgebend.

⚠️ Vor dem ersten Upgrade auf SFOS 21 oder neuer: Unter Certificates > Certificate authorities nach den reservierten Let’s-Encrypt-CA-Namen suchen. Ein bereits konfigurierter Eintrag mit exakt demselben Namen kann die Migration durch NC-146082 abbrechen. Die CA nicht blind löschen, sondern zuerst Backup, Private Key und abhängige Zertifikate sowie Dienste sichern und prüfen.

Lizenz und Support

Seit SFOS 19.0 MR1 sind ohne Enhanced Support oder Enhanced Plus Support drei kostenlose Wechsel auf GA-, MR- oder EAP-Versionen möglich. Danach kann die Firmware weiterhin heruntergeladen, aber nicht installiert werden; Install ist deaktiviert.

Pattern Updates, Hotfixes, Reimage sowie Mandatory und Assistant Firmware Upgrades sind von dieser Supportregel ausgenommen. Vor dem Wartungsfenster sollte trotzdem geprüft werden:

• Administration > Licensing zeigt die erwartete Lizenz und Support-Berechtigung.
• Sophos Fusion führt die richtige Firewall und Seriennummer.
• Zielversion und Download sind verfügbar.
• Supportzugang, Ansprechpartner und Eskalationsweg sind bekannt.

Wenn für den Change ein externer Zugriff benötigt wird, muss dieser vorher getestet sein. Für Avanet passt Support-Zugriff auf Sophos Firewall einrichten.

Automatische Hotfixes getrennt prüfen

Hotfixes sind weder ein Firmware-Slot noch ein Pattern Update. SFOS 22 prüft alle 30 Minuten auf verfügbare Hotfixes und installiert sie standardmässig automatisch. Sophos empfiehlt, diese Einstellung nicht zu ändern. Vor und nach einem Firmware-Change wird der Status in der Device Console gelesen:

system hotfix show

Für SFOS 22 beschreibt Sophos, dass bereits installierte Hotfixes auch nach einem Firmware-Upgrade erhalten bleiben. Die versionsbezogene Liste in SFOS 23 wird dagegen nach jedem Versionswechsel neu bewertet, wie im folgenden Abschnitt erklärt. Zeigt die Kontrolle eine deaktivierte Automatik, wird zuerst geklärt, wer sie aus welchem Grund ausgeschaltet hat. Ohne dokumentierte Ausnahme wird sie wieder aktiviert:

system hotfix enable

system hotfix disable schaltet nur die automatische Installation aus und ist kein allgemeiner Troubleshooting-Schritt. Auch ein aktivierter Status beweist nicht, dass ein bestimmter Hotfix bereits angewendet wurde oder der Downloadpfad funktioniert. Für einen konkreten Fehler werden deshalb zusätzlich Build, Zeitpunkt, Internetzugang, Logs und die von Sophos genannte Fehlerreferenz geprüft.

SFOS 23: angewendete Sicherheitsupdates nachweisen

In SFOS 23 zeigt Backup & firmware > Hotfix: Security updates, welche Hotfix-Sicherheitsupdates seit dem Wechsel auf die aktuell laufende SFOS-Version angewendet wurden. Hotfixes korrigieren das laufende System ohne Firmware-Upgrade und sind nicht mit der Liste verfügbarer Firmware-Images zu verwechseln. Die Hotfix-Automatik muss aktiviert sein; sie ist standardmässig eingeschaltet. system hotfix show prüft diese Einstellung, nicht den Nachweis einer bestimmten Sicherheitskorrektur.

Für den Change-Nachweis vor und nach dem Firmwarewechsel:

1. Aktive SFOS-Version samt Build und Prüfzeitpunkt dokumentieren und die Seite Hotfix: Security updates öffnen.
2. Die Einträge nach Anwendungsdatum sortieren und die zum untersuchten Problem gehörenden Updates festhalten. Die Spalte Advisory verweist bei öffentlich beschriebenen Schwachstellen auf den zugehörigen Sicherheitshinweis. Interne Korrekturen können ohne CVE-ID und ohne Advisory-Link erscheinen.
3. Bei HA beide Geräte in die Nachkontrolle einbeziehen: Der aktuelle Primary erhält den Hotfix, synchronisiert mit dem Auxiliary und dort wird der Hotfix ebenfalls angewendet. Eine erfolgreiche Prüfung auf einem Gerät ersetzt nicht den Nachweis für den Cluster.

Eine Schwachstelle kann mehrfach erscheinen, weil mehrere Hotfixes nötig sein können, um sie vollständig zu beheben. Ein einzelner passender Eintrag ist deshalb kein pauschaler Nachweis vollständigen Schutzes. Für eine konkrete Sicherheitskorrektur müssen die Anforderungen des zugehörigen Sicherheitshinweises mit dem laufenden Build und den tatsächlich angewendeten Updates abgeglichen werden.

Benachrichtigungen und Logs: Unter System services > Notification list im Bereich Firmware bei Security updates die Option Email aktivieren. Für diese Updates stehen keine SNMP-Benachrichtigungen zur Verfügung. Hotfix-Sicherheitsupdates erscheinen auch im Log viewer; ihre Audit Logs werden erzeugt und an Sophos Fusion für Central Firewall Reporting weitergeleitet. Diese Benachrichtigungs- und Logaussagen gelten für Hotfix-Sicherheitsupdates, nicht pauschal für jede Hotfix-Korrektur. Ein fehlendes E-Mail allein belegt daher weder Erfolg noch Fehlschlag.

Nach einem Versionswechsel: SFOS installiert zuerst die neue Firmware und wendet anschliessend die für diese Version verfügbaren Hotfixes an. Die vorherige Hotfix-Liste wird entfernt und durch die Liste der neuen Version ersetzt; sie ist kein versionsübergreifendes Archiv. Dieselbe Korrektur kann erneut erscheinen, weil sie unabhängig auf die neue Version angewendet wurde. Sind frühere Korrekturen bereits in der neuen Firmware enthalten, können sie als separate Hotfix-Einträge fehlen.

Eine leere Liste bedeutet nur, dass für die aktuelle Version noch keine Hotfix-Sicherheitsupdates angewendet und angezeigt wurden. Sie beweist weder fehlenden Schutz noch vollständige Absicherung oder eine funktionierende Automatik. Bei Unklarheit aktive Version und Build, CLI-Einstellung, Sicherheitshinweis, Release Notes und Logs gemeinsam prüfen; aus einer leeren Seite nicht vorsorglich die Automatik abschalten oder einen Rollback ableiten.

Backup, Recovery und Nachweis vorbereiten

Backup, SSMK und Firmware-Slots

Vor dem Update ein frisches Konfigurationsbackup herunterladen und prüfen, welcher Secure Storage Master Key zum Backup gehört. Zusätzlich Backup-Passwort, Admin-Zugang, aktive Firmwareversion und Zielversion im Change festhalten.

Sophos Firewall hält höchstens zwei Firmwarestände: eine aktive und eine inaktive Version. Beide Partitionen besitzen ihren eigenen Konfigurationsstand. Ein Rollback aktiviert daher nicht nur die vorherige Firmware, sondern auch deren Konfiguration. Änderungen, die nach dem Upgrade vorgenommen wurden, können beim Zurückwechseln verloren gehen.

Ein automatischer Rollback ist ab SFOS 20.0 bei bestimmten Fehlern der Konfigurationsmigration verfügbar. Er ist eine Sicherheitsfunktion, ersetzt aber weder Backup noch Ursachenanalyse und steht bei einem nicht unterstützten Upgrade-Pfad nicht zur Verfügung.

Der vollständige Backup- und Restore-Ablauf steht in Sophos Firewall Backup erstellen oder wiederherstellen. Wenn ein normaler Versionswechsel nicht möglich ist, hilft Sophos Firewall OS mit USB-Stick neu installieren.

Rollback-Kriterien vorab festlegen

Vor dem Start definieren, wie lange ein Fehler analysiert wird und wann der Rückweg beginnt. Ein Rollback ist sinnvoll, wenn WAN, HA, zentrale VPNs oder produktionskritische Veröffentlichungen im vereinbarten Zeitfenster nicht stabilisiert werden können. Bei einer einzelnen Regel, einem Objekt oder einem externen Dienst ist gezieltes Troubleshooting oft besser.

Für den Nachweis reichen bei einem normalen Maintenance Release Backup, Screenshot der Firmwareseite, Zeitfenster und Testergebnis. Bei grösseren Changes helfen Sophos Firewall Config Studio für Konfigurationsvergleiche und der Audit Trail für Änderungen während des Wartungsfensters.

Systemzustand, Speicher und HA prüfen

Speicherplatz und SSD

Vor einem grösseren Upgrade im WebAdmin kontrollieren:

• Control center zeigt keine ungeklärten kritischen Warnungen.
• Backup & Firmware > Firmware zeigt die erwarteten Firmware-Slots.
• Diagnostics > Log viewer enthält keine wiederkehrenden System- oder Migrationsfehler.
• Relevante Dienste laufen stabil.
• Der Firewall Health Check enthält keine offenen Punkte, die den Change beeinflussen.

Nach der SSH-Anmeldung unter Device Management > Advanced Shell den freien Speicherplatz prüfen:

df -kh

Ist eine Partition fast voll, nicht blind Dateien, Logs oder Reports in der Advanced Shell löschen. Zuerst die Ursache bestimmen und den dokumentierten Bereinigungsweg verwenden. Der praktische Ablauf steht in Sophos Firewall Speicherplatz prüfen und Reports verwalten.

Für SFOS 22 kann zusätzlicher Speicherplatz nötig sein. Bei bestimmten XGS Appliance-Modellen muss ausserdem zuerst die SSD-Firmware aktualisiert werden; eine Meldung im WebAdmin weist darauf hin. In einem HA-Cluster wird jeder Node separat bewertet. Wenn eine Appliance die Anforderungen nicht erfüllt, kann dies das gesamte Upgrade blockieren.

Bei älteren Appliances oder I/O-, Datenbank- und Reportproblemen zusätzlich die SSD-Gesundheit per SMART prüfen. Ohne konkreten Befund sind manuelle Änderungen an Datenbanken oder Dateisystemen kein sinnvoller Vorbereitungsschritt.

Sophos nennt einen Neustart vor dem Upgrade nur als optionale Möglichkeit, den Memory Cache zu leeren. Er ist keine Voraussetzung und erzeugt einen zusätzlichen Unterbruch. Deshalb nur im Wartungsfenster, nach Sicherung relevanter Logs und mit bestätigtem Management-Rückweg neu starten. Zeigt die Firewall ungeklärte Instabilität, wird das Upgrade gestoppt; ein Neustart darf die Ursachenanalyse nicht ersetzen oder das System nur vorübergehend gesund erscheinen lassen.

HA-Cluster

HA muss für ein normales Firmware-Update nicht deaktiviert werden. Vor der Freigabe müssen aber beide Appliances verbunden, synchron und eindeutig als Primary beziehungsweise Auxiliary erkennbar sein. Auch ein HA-Update braucht ein Wartungsfenster, weil beim Failover einzelne Sessions, VPN-Tunnel oder Pings kurz unterbrochen werden können.

Vor dem Start dokumentieren:

• Rollen, HA-Status und Synchronisation.
• Zustand des HA-Links.
• Firmware-, Speicher- und SSD-Voraussetzungen beider Nodes.
• alternativen Managementzugriff.
• erwarteten Failover und mögliche kurze Unterbrüche.

Die Auxiliary Appliance darf nicht separat aktualisiert werden. Den genauen Ablauf mit Auxiliary-Update, Failover und Update des bisherigen Primary erklärt der Durchführungsartikel. Weitere HA-Sonderfälle stehen in Sophos Firewall HA-Cluster: Varianten und Wartung.

Pattern Updates werden auf dem Primary aktualisiert und danach zum Auxiliary synchronisiert. Hotfixes und ihr Status müssen davon getrennt betrachtet und nach dem Wartungsfenster auf beiden Geräten kontrolliert werden.

Wartungsfenster, Central und Tests planen

Wartungsfenster und Zugriff

Ein Wartungsfenster enthält mehr als den Installationszeitpunkt:

• Startzeit, spätesten Abbruchzeitpunkt und Rollback-Entscheid.
• verantwortliche Personen für Firewall, Netzwerk, Server, Applikationen und Support.
• lokaler Kontakt, Out-of-Band-Zugang oder zweiter Managementpfad.
• Kommunikationsweg, falls WAN oder Remote Access ausfällt.
• Wartungsmodus für Monitoring und Alarmierung.
• Testreihenfolge für die wichtigsten Geschäftsprozesse.

Bei entfernten Standorten nicht nur auf Sophos Fusion oder die bestehende VPN-Verbindung vertrauen. Fällt genau dieser Pfad während des Updates aus, muss weiterhin ein definierter Zugriff oder Eskalationsweg bestehen.

Firmware über Sophos Fusion planen

Central-geplante Firmware-Upgrades werden unter My Products > Firewall Management > Firewalls vorbereitet und überwacht. Die Task Queue gehört zu Gruppenrichtlinien sowie MDR-/API-Konfigurationsaufträgen und zeigt keine Firmware-Upgrades.

Über Central können nur Zielversionen installiert werden, die im Release-Prozess die Phase Available to all erreicht haben. Geplante Updates starten nach der auf der Firewall eingestellten Zeitzone, nicht nach der Browserzeit des Admins. Bei internationalen Standorten gehören Zeitzone, lokales Wartungsfenster und Zielversion deshalb in den Change.

Während des Upgrades dreht sich neben der Firewall ein Statussymbol; nach Abschluss verschwindet es. Danach bleibt die lokale Prüfung der aktiven Firmwareversion Pflicht. Bei einem automatischen Rollback zeigt Central neben der Firmwareversion eine entsprechende Meldung.

Wiederkehrende Maintenance-Updates einrichten

Mit Recurring Firmware Upgrade lässt sich für das Sophos-Fusion-Konto ein wiederkehrendes Wartungsfenster festlegen. Der Plan gilt für alle Firewalls im Konto; sobald geeignete Firmware verfügbar ist, werden die berechtigten Geräte nach diesem Plan aktualisiert. Die Funktion ist eine bewusste Aktivierung, nicht die Zusage, dass jede Firewall bei jedem Termin eine neue Version erhält. Backup, Upgrade-Pfad, Support-Berechtigung und die übrigen Freigabepunkte dieses Artikels bleiben Voraussetzung.

1. Unter My Products > Firewall Management > Firewalls Recurring Firmware Upgrade öffnen und Schedule maintenance updates aktivieren.
2. Weekly (Default) für einen wöchentlichen Rhythmus wählen und Wochentag sowie Uhrzeit festlegen. Für Monthly zuerst 1st, 2nd, 3rd, 4th oder Last als Woche im Monat wählen, danach Wochentag und Uhrzeit. Das ist kein frei gewählter Kalendertag.
3. Unter Staging firewalls geeignete Pilot-Firewalls auswählen. Mehrere Geräte sind möglich; die Auswahl und ihre Grenzen werden im nächsten Abschnitt erklärt.
4. Schedule major version updates nur nach einer ausdrücklichen Entscheidung für automatische Hauptversionswechsel aktivieren. Ohne diese Option bleibt der Plan bei Maintenance-Updates innerhalb der aktuellen Hauptversion. Mit der Option gelten derselbe Zeitplan und derselbe Staging-Prozess auch für geeignete Major-Versionen. Neue Funktionen und Architekturänderungen benötigen trotzdem eine gesonderte Kompatibilitätsprüfung.
5. Mit Review die Einstellungen prüfen und bei Bedarf korrigieren. Erst Confirm bestätigt den Plan.
6. Anschliessend neben jeder betroffenen Firewall das Symbol Scheduled öffnen und den tatsächlich geplanten Termin kontrollieren. Zielversion, Standort, Firewall-Zeitzone und lokales Wartungsfenster im Change festhalten.

Ein mögliches Monatsfenster ist Monthly, 2nd, Sonntag, 02:00 Uhr. Das Beispiel bedeutet den zweiten Sonntag des Monats um 02:00 Uhr in der Zeitzone der jeweiligen Firewall. Es ist keine Empfehlung für alle Standorte: Das Fenster muss zu Betriebszeiten, Backup-Lauf, erreichbaren Verantwortlichen und den anschliessenden Tests passen. Bei unterschiedlichen Zeitzonen starten die Standorte nicht gleichzeitig. Vor der Bestätigung deshalb die Zeitzone jeder Firewall und die angezeigten Termine prüfen.

Für HA-Paare plant Sophos Fusion den Upgrade-Auftrag auf dem Primary. Der Auxiliary wird automatisch im bestehenden HA-Upgrade-Prozess aktualisiert und erhält keinen separaten manuellen Auftrag. Die HA-Prüfungen und möglichen Unterbrüche aus dem Abschnitt HA-Cluster gelten auch bei wiederkehrender Planung. Weder der Starttermin noch ein erfolgreiches Statussymbol garantieren eine feste Abschlusszeit oder unterbrechungsfreien Betrieb; das Wartungsfenster muss auch Abnahme und gegebenenfalls Rollback aufnehmen.

Staging ist eine technische Schranke, keine Anwendungsabnahme

Staging-Firewalls erhalten die Firmware zuerst. Erkennt der Dienst das Upgrade als erfolgreich, werden die übrigen Firewalls gemäss Zeitplan aktualisiert. Bei einem fehlgeschlagenen Staging-Upgrade stoppt der Rollout; die betroffenen Firewalls kehren zur vorherigen Firmware zurück. Die Ursache muss behoben werden, bevor der Zeitplan fortgesetzt wird. Der vorhandene Backup- und Recovery-Plan bleibt nötig: Aus dieser Dienstmechanik darf man keinen garantierten Rückweg für jeden denkbaren Fehler ableiten.

Als Pilot eignen sich Geräte, die die eingesetzten Funktionen und Plattformen sinnvoll vertreten und deren Ausfall beherrschbar ist. Ein reiner Internetstandort prüft beispielsweise nicht automatisch die WAF- oder VPN-Konfiguration anderer Standorte. Ohne ausgewählte Staging-Firewalls werden alle geeigneten Firewalls direkt nach Zeitplan aktualisiert; damit fehlt die vorgeschaltete Pilotstufe.

⚠️ Kein manuelles Abnahme-Gate: Der Staging-Erfolg des Dienstes beweist nicht, dass DNS, VPN, veröffentlichte Dienste oder Geschäftsapplikationen funktionieren. Die unten beschriebenen Funktionstests bleiben erforderlich. Der Ablauf bietet keine hier belegte manuelle Freigabe zwischen erfolgreichem Staging und dem übrigen Rollout. Wenn erst eine fachliche Pilotabnahme erfolgen muss, darf man nicht darauf vertrauen, dass der Dienst bis dahin wartet; die automatische Planung erst aktivieren, wenn das gewählte Verfahren diese Anforderung erfüllt.

Einzeltermine ändern, überspringen oder Staging anpassen

Ohne wiederkehrenden Plan wird ein Einzelupdate über das blaue Pfeilsymbol neben der Firewall und Schedule upgrade eingerichtet: Zielversion wählen, Immediately oder At festlegen, bei At Datum und Uhrzeit auswählen und mit Schedule upgrade bestätigen. Sobald ein wiederkehrender Plan besteht, verwendet man für einzelne Firewalls stattdessen die folgenden Aktionen. Sie ändern nicht den wiederkehrenden Plan der anderen Firewalls.

• Override schedule: Das Schedule-Symbol neben der Firewall öffnen und Override schedule wählen. Im Fenster Firmware upgrades die Zielversion und Immediately oder At auswählen. Bei At über das Kalendersymbol Datum und Uhrzeit festlegen; mit Override schedule bestätigen. Immediately startet den Auftrag ohne späteren Termin und gehört deshalb nur in ein bereits freigegebenes Wartungsfenster. Über das Symbol Release notes die gewählte Version prüfen; beim Überfahren des Clock-Symbols werden Datum, Uhrzeit und lokale Firewall-Zeit des aktuellen Plans angezeigt. Nach der Änderung die Terminanzeige erneut kontrollieren.
• Skip occurrence: Das Schedule-Symbol öffnen und Skip occurrence wählen, wenn nur das nächste geplante Update für diese Firewall ausfallen soll. Der Auftrag verschiebt sich auf die nächste Wiederholung. Bei einem wöchentlichen Freitagstermin bedeutet das den folgenden Freitag, nicht eine dauerhafte Ausnahme. Den neuen Termin kontrollieren und erneut mit dem Wartungsfenster abgleichen.
• Remove from upgrade staging: Über das Schedule-Symbol Remove from upgrade staging öffnen. Im Fenster Recurring Firmware Upgrade Schedule die betreffende Firewall unter Staging firewalls abwählen, dann Review und Confirm ausführen. Das entfernt ihre Pilotrolle, nicht ihre Teilnahme an der allgemeinen Firmwareplanung. Danach die verbleibende Staging-Auswahl und den Termin der Firewall prüfen. Soll das Gerät wieder Pilot werden, es in der Staging-Auswahl des wiederkehrenden Plans erneut auswählen und den Plan mit Review und Confirm bestätigen.

Eine fehlende Zielversion zuerst gegen die Phase Available to all prüfen, nicht durch einen spontanen lokalen Upload umgehen. Stimmen Termine nicht mit dem Change überein, zunächst die Firewall-Zeitzone und die über Clock angezeigte lokale Zeit abgleichen. Nach einem Staging-Fehler aktive Firmware, Rollback-Meldung und Logs prüfen, die Ursache klären und die echten Funktionstests durchführen, bevor weitere Updates freigegeben werden. Eine Terminänderung oder das Entfernen aus Staging macht ein bereits ausgeführtes Firmware-Update nicht rückgängig; dafür gelten die oben beschriebenen Rollback- und Recovery-Verfahren.

Echte Funktionstests

Ein Ping allein beweist nicht, dass die Firewall nach dem Update korrekt arbeitet. Vorher konkrete Tests mit Quelle, Ziel und erwartetem Ergebnis festlegen:

• Internetzugriff und DNS-Auflösung.
• DHCP, VLANs, WAN-Uplinks und SD-WAN-Routen.
• Site-to-Site VPN, Remote Access VPN und RED.
• Firewallregeln, NAT und veröffentlichte Dienste.
• WAF, Web Protection und TLS Inspection.
• LDAP, RADIUS, Microsoft Entra ID und andere zentrale Authentifizierung.
• Mailfluss und geschäftskritische Applikationen.
• Syslog, SIEM und Monitoring.

Nach dem Update abnehmen

Nach dem Neustart zuerst unter Backup & Firmware > Firmware die aktive Version und den erwarteten inaktiven Slot prüfen. Danach:

• Control center auf neue Warnungen oder automatischen Rollback kontrollieren.
• Interfaces, WAN, SD-WAN, HA-Rollen und Synchronisation prüfen.
• VPNs, RED, DNS, DHCP, Regeln, NAT, WAF und Authentifizierung mit den vorbereiteten Tests abnehmen.
• Pattern- und Hotfix-Status kontrollieren.
• Sophos-Central-Synchronisation sowie Monitoring, Syslog und SIEM prüfen.
• Ergebnis, Zeitpunkte, Abweichungen und allfällige Folgearbeiten im Change festhalten.

Wenn eine einzelne Funktion ausfällt, zuerst Log Viewer, Policy Test, Packet Capture und zuständige Service-Logs verwenden. Dafür passen Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture und Sophos Firewall Troubleshooting: Services und Logs.

FAQ