Sophos Firewall i Failsafe-läge: agera säkert

När Sophos Firewall rapporterar failsafe ska situationen behandlas som en recoveryincident. Den offentliga dokumentationen för SFOS 22 beskriver inget allmänt diagnoskommando som tillförlitligt identifierar orsaken i varje Failsafe-tillstånd. Denna runbook använder därför medvetet varken show failure-reason eller en påhittad ersättning.

Spara först det visade meddelandet oförändrat och bedöm sedan plattform, HA-roll, firmware-Build och den senaste ändringen. Ändra inte databaser, signaturer, regler eller systemfiler manuellt så länge orsaken inte är bevisad.

⚠️ Dokumentera före omstart: En omstart kan förändra det synliga felet. Fotografera hela konsolen, inklusive de första bootmeddelandena, och notera tidpunkt, modell, serienummer, fullständig SFOS-version med Build och vid HA berörd Node. Reset to Factory Defaults, Remove Firewall Rules och manuella databas- eller filsystemsändringar är ingen säker första diagnos.

Spara Failsafe-meddelandet säkert

Använd tillgänglig direktkonsol: lokal eller seriell för hårdvara, hypervisorkonsolen för en VM. Denna väg kan användas när WebAdmin eller nätverket inte går att nå.
Fotografera meddelandet ordagrant tillsammans med bootraderna omedelbart ovanför. Ersätt inte det verkliga meddelandet med exempelutdata från internet.
Notera plattform och modell, serienummer, fullständigt SFOS-Build, feltidpunkt och senast kända fungerande tidpunkt.
Registrera aktuella ändringar, särskilt firmware-upgrade, rollback, restore, regler eller objekt, VM-resurser, virtuella diskar, vNICs och lagringshändelser.
Notera vid HA berörd Node, roll, peerstatus och senaste rollbyte. Starta inte om båda Nodes samtidigt och avaktivera inte HA på måfå.

Enbart ett WebAdmin som inte kan nås bevisar inget Failsafe-tillstånd. Om brandväggen startar normalt och trafiken fortsätter, men bara gränssnittet inte svarar, passar först en riktad kontroll eller omstart av WebAdmin GUI. Ett uttryckligen visat Failsafe-meddelande hanteras däremot som ett start- eller recoveryproblem.

Avgränsa dokumenterade orsaker

Sophos dokumenterar flera specifika men inte uttömmande orsaker för SFOS 22. Release Notes för SFOS 22.0 MR2 Build 546 anger Failsafe på grund av en full konfigurationspartition (NC-181331), en logging daemon som inte startade på Primary HA-enheten (NC-180110), Failsafe på den ursprungliga Primary-enheten efter upgrade till 22.0 GA (NC-177441) och Failed to start Red server service (NC-178906). Dessa poster bekräftar kända åtgärdade fel, inte en allmän reparationsmatris.

Om det observerade tillståndet, plattformen eller HA-rollen och versionshistoriken exakt motsvarar en post i Release Notes ska Issue ID och installerat Build tas med i supportärendet. En delvis överensstämmelse bevisar varken samma orsak eller att en okoordinerad firmwareändring återställer brandväggen. Sophos citerar det visade meddelandet ordagrant endast för NC-178906. Om brandväggen startar normalt och bara en RED-tunnel är offline ska RED-felsökningen användas i stället.

Software appliance

För en SFOS 22 software appliance installerad på egen hårdvara anger Sophos bland annat följande minimikrav som är relevanta för det körande systemet och säger uttryckligen att brandväggen går över i fail-safe om kraven inte uppfylls:

x86-64-CPU och Legacy BIOS
minst 4 GB RAM
minst 32 GB HDD eller SSD; 64 GB rekommenderas
2 nätverkskort

Dokumentera det aktuella tillståndet före ändringar. Vid en bekräftad avvikelse ska Sophos Support avgöra om en supportad resursjustering räcker eller om en kontrollerad reimage krävs. Improvisera inte ändringar av disk eller startläge. Plattformsskillnader och resurskrav beskriver hardware, virtual och software appliances mer ingående.

Virtual och hardware appliance

För en VM registreras befintliga och anslutna vNICs, virtuella diskar, CPU, RAM, diskkontroller och aktuella hypervisorändringar. Cloud- och hypervisorplattformar har egna krav som stöds; tillämpa inte automatiskt software appliance-värdena på varje virtuell driftsättning.

Ta för hårdvara med återkommande bootfel, strömhändelser, I/O- eller SSD-indikationer, temperatur och fläktar i supportärendet. En lyckad omstart utesluter inte en defekt. Kontrollerna av temperatur och fläktar, SSD-status och RMA-förberedelse hjälper till att förbereda ärendet.

Spara loggar och backup

Om Advanced Shell fortfarande kan nås är sysinit.log, syslog.log och vid en databasindikation postgres.log relevanta officiella troubleshootingloggar. Ta även med red.log för det dokumenterade RED-meddelandet. Denna runbook anger medvetet inga shellkommandon för kopiering, borttagning eller reparation: åtkomstvägen och tillgängliga verktyg kan skilja sig i ett recoveryläge.

När WebAdmin blir tillgängligt igen skapas ett Troubleshooting-arkiv eller CTR. Proceduren beskrivs i Spara Sophos Firewall-loggar för support. Loggar och arkiv kan innehålla konfidentiella nätverks-, användar- och konfigurationsdata och ska endast överföras skyddat till behöriga mottagare.

Före restore eller reimage måste lämplig backup, dess lösenord och tillhörande Secure Storage Master Key finnas. Backup och restore av Sophos Firewall förklarar dessa beroenden.

Använd `fsck-on-nextboot` endast med Sophos Support

system fsck-on-nextboot är ingen allmän hälsokontroll. Sophos varnar för att det endast får användas på rekommendation av Sophos Support. Det är avsett för mountfel på /sig, /conf eller /var; om hårdvaran eller SSD-enheten inte är frisk kan kontrollen skada filsystemet.

Den dokumenterade syntaxen för Device Console är:

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

on framtvingar kontroll av alla partitioner vid nästa omstart, off avbryter den före omstarten och show visar aktuell konfiguration; standardvärdet är off. SFOS kan automatiskt schemalägga kontrollen i Failsafe om konfigurations-, rapport- eller signaturdatabasen inte startar, en migrering inte kan tillämpas eller deployment mode inte kan hittas.

Starta inte om enbart för att on visas. Ta först med supportrekommendationen, stabil konsolåtkomst, strömförsörjning, backup, möjliga I/O-fel och vid HA peerstatus i samma underhållsplan. Sophos anger ingen fast tid och ingen garanti för framgång.

Välj en säker recoveryväg

Software-krav tydligt under minimum: Spara aktuellt tillstånd och utför den justering eller reimage som Sophos Support har bekräftat under ett underhållsfönster. Observera nästa start via konsolen.
Meddelandet motsvarar ett känt problem i Release Notes: Spara fullständigt Build och Issue ID. Låt Sophos Support bekräfta recovery-, upgrade- eller rollbackvägen för tillståndet.
HA-incident: Skydda den peer som fortfarande fungerar. Inga samtidiga omstarter eller oplanerade roll- eller klusterändringar. Se High Availability i Sophos Firewall.
Lagrings-, databas-, regel-, NPU-, I/O- eller okänt fel: Ta inte bort filer eller konfiguration på misstanke. Eskalera till Sophos Support med konsol, loggar och tidslinje.
Reimage: Använd endast om Sophos Support eller en dokumenterad recoveryplan motiverar det och alla restorekrav är uppfyllda. Se Installera om Sophos Firewall OS.

Kontrollera efter varje åtgärd inte bara WebAdmin och inloggning. Verifiera normal konsolstart, HA-status, interface, routing och nödvändiga internet- och VPN-anslutningar. Om meddelandet återkommer läggs tidpunkt och oförändrade utdata till i stället för fler spontana ändringar.

Eskalera till Sophos Support

Eskalera en Failsafe-incident så snart orsaken inte kan begränsas till en dokumenterad resursavvikelse som kan korrigeras säkert. Ett Sophos Support-ärende ska minst innehålla:

foto eller kopia av samtliga Failsafe- och bootmeddelanden
modell, serienummer, plattform och fullständigt SFOS-Build
feltidpunkt, senaste fungerande tidpunkt och ändringstidslinje
vid HA: Node, roll, peerstatus och senaste rollbyte
relevanta loggar eller CTR samt lagrings-, I/O-, NPU- eller strömindikationer
tillgänglig backup och status för lösenord och SSMK, utan att hemligheter avslöjas i ärendetexten
redan utförda omstarter eller ändringar och deras resultat

Om WebAdmin är tillgängligt och Sophos begär fjärråtkomst kan tidsbegränsad Support access aktiveras under Diagnostics > Support access. Dela genererat Access ID endast via avtalad supportkanal; åtkomsten kan stängas av när som helst.