Sophos Firewall im Failsafe-Modus: sicher vorgehen

Wenn eine Sophos Firewall Failsafe meldet, sollte man den Zustand als Recovery-Fall behandeln. Die öffentlich zugängliche SFOS-22-Dokumentation beschreibt keinen allgemeinen Diagnosebefehl, der aus jeder Failsafe-Situation zuverlässig die Ursache ermittelt. Deshalb verwendet dieses Runbook bewusst weder show failure-reason noch einen erfundenen Ersatz.

Zuerst wird die sichtbare Meldung unverändert gesichert, danach werden Plattform, HA-Rolle, Firmware-Build und letzter Change eingeordnet. Solange die Ursache nicht eindeutig belegt ist, werden keine Datenbanken, Signaturen, Regeln oder Systemdateien manuell verändert.

⚠️ Vor einem Neustart dokumentieren: Ein Neustart kann die sichtbare Fehlersituation verändern. Fotografiere die vollständige Konsole einschliesslich der ersten Bootmeldungen und notiere Zeitpunkt, Modell, Seriennummer, vollständige SFOS-Version mit Build sowie bei HA den betroffenen Node. Reset to Factory Defaults, Remove Firewall Rules und manuelle Datenbank- oder Dateisystemeingriffe sind keine sichere Erstdiagnose.

Failsafe-Meldung sicher erfassen

1. Verwende den verfügbaren direkten Konsolenzugang: bei Hardware lokal oder seriell, bei einer VM die Hypervisor-Konsole. Dieser Weg bleibt auch dann nutzbar, wenn WebAdmin oder das Netzwerk nicht erreichbar sind.
2. Fotografiere die Meldung wortgetreu zusammen mit den unmittelbar davor sichtbaren Bootzeilen. Keine Beispielausgabe aus dem Internet als eigene Meldung übernehmen.
3. Notiere Plattform und Modell, Seriennummer, vollständigen SFOS-Build, Zeitpunkt und letzte bekannte funktionierende Zeit.
4. Erfasse die letzten Änderungen, insbesondere Firmware-Upgrade, Rollback, Restore, Regel- oder Objektänderungen, VM-Ressourcen, virtuelle Disks, vNICs und Storage-Ereignisse.
5. Bei HA: betroffenen Node, Rolle, Peer-Status und letzten Rollenwechsel dokumentieren. Beide Nodes weder gleichzeitig neu starten noch HA auf Verdacht deaktivieren.

Ein nicht erreichbares WebAdmin allein beweist keinen Failsafe-Zustand. Wenn die Firewall normal startet und Traffic weiterläuft, aber nur die Oberfläche hängt, passt zuerst die gezielte Prüfung beziehungsweise der Neustart der WebAdmin GUI. Eine ausdrücklich angezeigte Failsafe-Meldung wird dagegen als Start- oder Recovery-Problem behandelt.

Belegte Ursachen eingrenzen

Sophos dokumentiert für SFOS 22 mehrere konkrete, aber nicht abschliessende Auslöser. In den Release Notes zu SFOS 22.0 MR2 Build 546 stehen unter anderem ein Failsafe-Zustand durch eine volle Konfigurationspartition (NC-181331), ein nicht gestarteter Logging-Daemon auf dem Primary HA-Node (NC-180110), Failsafe des ursprünglichen Primary-Geräts nach dem Upgrade auf 22.0 GA (NC-177441) und Failed to start Red server service (NC-178906). Diese Einträge belegen bekannte behobene Fehler, sind aber keine allgemeine Reparaturmatrix.

Passen der beobachtete Zustand, die Plattform beziehungsweise HA-Rolle und der Versionsverlauf genau zu einem Release-Note-Eintrag, werden Issue-ID und installierter Build im Support Case genannt. Eine teilweise Übereinstimmung beweist weder dieselbe Ursache noch, dass ein unkoordinierter Firmwarewechsel die Firewall wiederherstellt. Nur für NC-178906 nennt Sophos die zitierte Meldung wörtlich. Startet die Firewall normal und ist lediglich ein RED-Tunnel offline, passt stattdessen die RED-Fehlerbehebung.

Software-Appliance

Für eine auf eigener Hardware installierte SFOS-22-Software-Appliance nennt Sophos unter anderem folgende, für den laufenden Betrieb relevante Mindestanforderungen und weist ausdrücklich darauf hin, dass die Firewall bei Unterschreitung in den Failsafe-Modus wechselt:

• x86-64-CPU und Legacy BIOS
• mindestens 4 GB RAM
• mindestens 32 GB HDD oder SSD; 64 GB werden empfohlen
• 2 Netzwerkkarten

Der aktuelle Istzustand wird vor jeder Änderung dokumentiert. Bei einer bestätigten Abweichung klärt man mit Sophos Support, ob eine unterstützte Ressourcenanpassung genügt oder ein kontrolliertes Reimage nötig ist. Disk- und Boot-Mode-Änderungen werden nicht improvisiert. Die ausführliche Einordnung von Hardware-, virtuellen und Software-Appliances steht unter Plattformunterschiede und Ressourcenanforderungen.

Virtuelle und Hardware-Appliance

Bei einer VM werden vorhandene und verbundene vNICs, virtuelle Disks, CPU, RAM, Disk-Controller und letzte Hypervisor-Änderungen erfasst. Cloud- und Hypervisor-Plattformen haben eigene unterstützte Vorgaben; die Werte der Software-Appliance werden nicht pauschal auf jede virtuelle Bereitstellung übertragen.

Bei Hardware gehören wiederkehrende Bootfehler, Stromereignisse, I/O- oder SSD-Hinweise, Temperatur und Lüfter in den Support Case. Ein einmal erfolgreicher Neustart schliesst einen Defekt nicht aus. Für die Vorbereitung helfen die vorhandenen Prüfungen für Temperatur und Lüfter, SSD-Zustand und RMA.

Logs und Backup sichern

Wenn Advanced Shell noch erreichbar ist, sind sysinit.log, syslog.log und bei einem Datenbankhinweis postgres.log relevante offizielle Troubleshooting-Logs. Bei der dokumentierten RED-Meldung gehört zusätzlich red.log zum Fall. Dieses Runbook gibt bewusst keine Shell-Befehle zum Kopieren, Löschen oder Reparieren vor: Zugriffsweg und verfügbare Werkzeuge können im Recovery-Zustand abweichen.

Wenn WebAdmin wieder verfügbar ist, wird ein Troubleshooting-Archiv beziehungsweise CTR erstellt. Der Ablauf steht in Sophos Firewall Logs für Support sichern. Logs und Archive können vertrauliche Netzwerk-, Benutzer- und Konfigurationsdaten enthalten und werden nur geschützt an berechtigte Empfänger übertragen.

Vor einem Restore oder Reimage müssen ein passendes Backup, das Backup-Passwort und der zugehörige Secure Storage Master Key verfügbar sein. Die Abhängigkeiten erklärt Sophos Firewall Backup und Restore.

fsck-on-nextboot nur mit Sophos Support

system fsck-on-nextboot ist kein allgemeiner Gesundheitscheck. Sophos warnt, den Befehl nur auf Empfehlung von Sophos Support zu verwenden. Er ist für Mount-Fehler von /sig, /conf oder /var vorgesehen; bei nicht gesunder Hardware oder SSD kann die Prüfung das Dateisystem beschädigen.

Die dokumentierte Device-Console-Syntax lautet:

system fsck-on-nextboot [on | off | show]

on erzwingt die Prüfung aller Partitionen beim nächsten Gerätestart, off hebt sie vor diesem Start auf und show zeigt die aktuelle Konfiguration; Standard ist off. SFOS kann die Prüfung in Failsafe automatisch vormerken, wenn die Konfigurations-, Report- oder Signaturdatenbank nicht startet, eine Migration nicht angewendet werden kann oder der Deployment Mode fehlt.

Nicht allein wegen eines angezeigten on neu starten. Supportempfehlung, stabiler Konsolenzugang, Stromversorgung, Backup, mögliche I/O-Fehler und bei HA der Zustand des Peers gehören zuerst in denselben Wartungsplan. Sophos nennt keine feste Laufzeit und keine Erfolgsgarantie.

Sicheren Recovery-Pfad wählen

• Eindeutig unterschrittene Software-Anforderung: Istzustand sichern und den von Sophos Support bestätigten Anpassungs- oder Reimage-Pfad in einem Wartungsfenster ausführen. Den nächsten Start über die Konsole beobachten.
• Meldung passt zu einem bekannten Release-Note-Problem: Vollständigen Build und Issue-ID sichern. Sophos Support soll den Recovery-, Upgrade- oder Rollback-Pfad für diesen Zustand bestätigen.
• HA-Fall: Den noch arbeitenden Peer schützen. Keine gleichzeitigen Neustarts und keine ungeplante Rollen- oder Clusteränderung. Die Grundlagen stehen unter Sophos Firewall High Availability.
• Storage-, Datenbank-, Regel-, NPU-, I/O- oder unbekannter Fehler: Keine Dateien oder Konfigurationsteile auf Verdacht entfernen. Mit Konsole, Logs und Zeitleiste an Sophos Support eskalieren.
• Reimage: Nur verwenden, wenn Sophos Support oder ein dokumentierter Recovery-Plan diesen Weg begründet und alle Restore-Voraussetzungen vorliegen. Der kontrollierte Ablauf steht unter Sophos Firewall OS neu installieren.

Nach einer Massnahme zählen nicht nur WebAdmin und ein erfolgreicher Login. Geprüft werden normaler Konsolenstart, HA-Status, Interfaces, Routing sowie die benötigten Internet- und VPN-Verbindungen. Kehrt die Meldung zurück, werden Zeitpunkt und unveränderte Ausgabe ergänzt, statt weitere spontane Änderungen vorzunehmen.

An Sophos Support eskalieren

Ein Failsafe-Fall wird eskaliert, sobald die Ursache nicht eindeutig auf eine dokumentierte und gefahrlos korrigierbare Ressourcenabweichung begrenzt ist. Der Sophos Support Case sollte mindestens enthalten:

• Foto oder Kopie der vollständigen Failsafe- und Bootmeldungen
• Modell, Seriennummer, Plattform und vollständiger SFOS-Build
• Zeitpunkt, letzte funktionierende Zeit und Change-Zeitleiste
• bei HA: Node, Rolle, Peer-Status und letzter Rollenwechsel
• relevante Logs oder CTR sowie Hinweise auf Storage, I/O, NPU oder Stromereignisse
• verfügbares Backup und Status von Passwort und SSMK, ohne Geheimnisse im Tickettext offenzulegen
• bereits durchgeführte Neustarts oder Änderungen und deren Ergebnis

Ist WebAdmin erreichbar und Sophos fordert Fernzugriff an, lässt sich zeitlich begrenzter Support access unter Diagnostics > Support access einschalten. Die erzeugte Access ID wird nur über den vereinbarten Supportkanal geteilt; der Zugriff kann jederzeit wieder ausgeschaltet werden.