Sophos Firewall i Failsafe-läge: kontrollera orsaken

När en Sophos Firewall startar i Failsafe-läge har SFOS identifierat ett kritiskt fel och inte gått över till normal drift. Paketbearbetning, interface och managementåtkomst kan sluta fungera helt eller delvis beroende på orsaken. Det går därför inte att dra slutsatsen att brandväggen fortfarande ger ett tillförlitligt skydd bara för att en managementport går att nå.

Det viktigaste första steget är inte en Factory Reset eller reimage, utan att spara den orsak som SFOS har identifierat:

1. Anslut via den lokala konsolen, seriekonsolen eller hypervisorkonsolen.
2. Öppna Device Console i Failsafe-menyn.
3. Kör följande skrivskyddade kommando:

show failure-reason

Konsolen kan därefter exempelvis se ut så här:

failsafe> show failure-reason
Unable to apply Firewall Framework

failsafe> är bara prompten och ska inte skrivas in. Det exakta meddelandet kan vara annorlunda. Det viktiga är att fotografera eller kopiera oförändrade utdata och de första synliga konsolraderna. Om SSH fortfarande fungerar i feltillståndet går Device Console även att nå den vägen. Vid ett fel är den lokala konsolen, seriekonsolen eller hypervisorkonsolen fortfarande den mer robusta vägen.

⚠️ Spara före en omstart: En Reboot kan förändra den synliga felsituationen eller tillfälligt undanröja den. Dokumentera först minst felmeddelandet, SFOS-versionen med Build, appliancens roll och tidpunkten. Reset to Factory Defaults, Remove Firewall Rules och manuella ingrepp i databasen eller filsystemet är ingen diagnos och kan förstöra viktig konfiguration eller bevismaterial.

Vad Failsafe-läget innebär

Failsafe är ett skydds- och recoveryläge. SFOS startar det när en komponent som krävs för säker brandväggsdrift inte startar korrekt. Kända meddelanden och verkliga felfall gäller exempelvis konfigurationsdatabasen, firewall framework, regelverket, logging- eller nätverkstjänsten, signaturdatabasen eller, på en XGS-modell med motsvarande utrustning, Network Processing Unit (NPU). Detta är ingen fullständig reparationsmatris; den konkreta konsolutmatningen är fortfarande avgörande.

Enbart ett WebAdmin som inte går att nå bevisar ännu inte ett Failsafe-läge. Om trafiken fortsätter och bara gränssnittet har hängt sig passar först en riktad kontroll eller omstart av WebAdmin GUI. Ett verkligt Failsafe identifieras i konsolen. Om managementåtkomst eller enskilda interface fortfarande fungerar beror på orsaken och är inget bevis på att systemet är felfritt.

Denna skillnad är viktig: om en enda tjänst har slutat fungera kan en riktad omstart av tjänsten vara lämplig. I Failsafe-läget saknas däremot en kritisk startförutsättning. Att starta om flera tjänster på måfå döljer då snarare orsaken än åtgärdar den.

Kontrollera Failsafe-orsaken med show failure-reason

show failure-reason hör hemma i Device Console, inte i Advanced Shell. Kommandot ändrar ingen konfiguration. Det visar den felklass som SFOS identifierade vid starten.

Utdata är en utgångspunkt och ännu ingen fullständig reparationsanvisning. Följande grupper av meddelanden hjälper vid klassificeringen:

• Configuration database: Brandväggen kunde inte starta konfigurationsdatabasen korrekt. Spara felmeddelandet, Build, den senaste ändringen och tillgänglig backup före manuella reparationer. Ta inte bort eller ändra databasfiler.
• Firewall framework eller firewall rules: SFOS kunde inte tillämpa grunden för paketbearbetning eller regelverket. De senaste ändringarna av regler, objekt, restore eller firmware är relevanta. Att ta bort alla brandväggsregler generellt skulle innebära dataförlust, inte en korrekt första diagnos.
• Logging daemon: En kritisk loggingtjänst startade inte. Kontrollera utöver felmeddelandet även lagringsstatus, Build och loggar. Töm inte Reports eller loggar utan att först spara nödvändiga data.
• Network daemon: Nätverkskomponenter kunde inte starta korrekt. För virtuella appliances ska befintliga vNICs, adapterordningen och hypervisorändringar ingå i kontrollen.
• Signature database: En nödvändig signaturdatabas kunde inte läsas in. Patternstatus, lagring och det tidsmässiga sambandet med uppdateringar är relevanta. Ta inte bort signaturfiler manuellt.
• NPU: På en XGS-modell med NPU kan redan den första konsolraden visa Network processing unit error. Även om show failure-reason därefter inte ger användbara utdata ska hela konsolen sparas och ett support- eller hårdvaruärende förberedas.

Den exakta formuleringen av ett meddelande kan variera mellan SFOS-versioner. För supporten är oförändrade utdata därför mer värdefulla än en egen sammanfattning som Firewall startar inte.

Kontrollera plattformen och den senaste ändringen

Nästa steg beror på om hårdvara, en virtuell appliance eller software appliance, eller ett HA-kluster är berört. Samma felmeddelande får inte automatiskt leda till samma åtgärd.

Virtuell brandvägg och software appliance

En virtuell brandvägg kan gå över till Failsafe redan på grund av olämpliga resurser. För lokalt körda SFOS 22-appliances på VMware, Hyper-V, KVM och Citrix anger Sophos för närvarande minst:

• 1 vCPU
• 4 GB vRAM
• 2 vNICs
• 32 GB Primary Disk
• 80 GB Report Disk

Dessutom får konfigurerade vCPU och vRAM inte överskrida den köpta licensen. Minimivärdena är bara tekniska startgränser och ingen produktionsdimensionering för IPS, TLS Inspection eller hög throughput.

Auxiliary Disk i VM-avbildningarna är denna separata Report Disk. Den är inte valfri och ersätter inte Primary Disk. För AWS och Azure gäller i stället de cloud-instanstyper som stöds och plattformsspecifika storlekar.

Kontrollera i hypervisorn att båda diskarna och alla avsedda vNICs fortfarande finns, är anslutna och tilldelade i förväntad ordning. En senare ändring av CPU, RAM, diskkontroller eller virtuellt nätverk hör också hemma i incidentens tidslinje. Plattformsskillnader och resurskrav beskrivs mer ingående i en separat artikel.

För en SFOS 22-software appliance är x86-64, Legacy BIOS, minst 4 GB RAM och två nätverkskort oomtvistade. Två aktuella Sophos-sidor motsäger dock varandra om disken: den allmänna plattformsöversikten anger minst 10 GB, medan den nyare specifika sidan för software appliance anger minst 32 GB och rekommenderar 64 GB. Det finns därmed ingen enhetligt publicerad Sophos-gräns. För nya installationer rekommenderar Avanet konservativt minst 32 GB och om möjligt 64 GB. Det följer den mer specifika produktsidan och undviker ett system som redan är trångt vid starten.

Ändra inte resurser godtyckligt flera gånger under ett oklart recoveryförsök. Dokumentera först det aktuella tillståndet och genomför sedan en planerad korrigering med ett definierat starttest.

Hardware appliance och NPU

På en fysisk XGS beaktas även strömhändelser, temperatur, fläktar, SSD- eller I/O-fel och de första startmeddelandena. Ett NPU-fel på en XGS-modell med motsvarande utrustning är ingen anledning att prova odokumenterade reset- eller servicekommandon. Om meddelandet återkommer eller själva diagnosen misslyckas är nästa steg ett supportärende med möjlig RMA-förberedelse.

En enda lyckad omstart bevisar ännu inte att ett hårdvaruproblem är löst. Vid upprepade avbrott hjälper även befintliga kontroller av temperatur och fläktar samt SSD-status.

Failsafe i ett HA-kluster

Vid HA fastställs först vilken Node som är berörd och om peeren hanterar produktionstrafiken stabilt. Dokumentera Primary eller Auxiliary, klusterstatus, senaste rollbyte och samma tidpunkt på båda appliances.

Starta inte om båda Nodes samtidigt och avaktivera inte HA på måfå. En okoordinerad ändring kan äventyra den väg som fortfarande fungerar, ändra rollfördelningen eller tvinga fram en ny konfiguration. Artikeln Konfigurera High Availability i Sophos Firewall förklarar roller, synkronisering och Node-specifika loggar. Den konkreta Failsafe-orsaken ska ändå sparas på berörd Node.

Efter firmwareuppdatering eller restore

Om Failsafe inträffar direkt efter en upgrade, rollback eller restore är ursprungsversion, målversion och fullständigt Buildnummer viktiga. I SFOS 22 har Sophos med MR2 Build 546 åtgärdat flera konkreta Failsafe-orsaker, däribland fel efter upgrade till GA, en Logging Daemon som inte startade, en full konfigurationspartition och vissa felaktiga tjänsteobjekt. Översikten över SFOS 22 MR2 anger åtgärdade Issue IDs.

Det betyder inte att varje Failsafe-händelse löses med en uppdatering. Kontrollera först om felmeddelandet och aktuellt Build över huvud taget motsvarar en känd korrigering. Ett firmwarebyte kräver fortfarande backup, underhållsfönster, HA-plan och returväg. Använd förberedelserna för en firmwareuppdatering och SFOS 22 Upgrade Check.

Failed to start Red server service

Om brandväggen visar exakt detta meddelande i Failsafe-läge motsvarar felbilden NC-178906. Sophos har åtgärdat detta Failsafe-fel med SFOS 22.0 MR2 Build 546. På ett äldre Build kontrolleras en planerad recovery- och uppgraderingsväg till Build 546 eller senare efter att bevisen har sparats. Om meddelandet uppstår med Build 546 eller senare bevisar inte enbart Issue ID orsaken. Då öppnas ett Support Case med de sparade loggarna.

Före en omstart eller ett firmwarebyte sparas fullständigt Build, tidpunkt, berörd HA-Node samt sysinit.log, red.log och syslog.log vid tidpunkten för felet. RED-interface, RED Firmware Pattern eller RED-konfigurationen tas inte bort på misstanke och RED-tjänsten startas inte om upprepade gånger. Om brandväggen startar normalt och endast en RED-tunnel förblir offline passar i stället RED-felsökningen.

Spara bevis före recovery eller omstart

För en tillförlitlig analys ska följande om möjligt samlas in före den första åtgärd som ändrar tillståndet:

• fullständiga utdata från show failure-reason och de första synliga startraderna
• modell, serienummer och hardware-, virtual- eller softwareplattform
• exakt SFOS-version inklusive MR och Build
• tidpunkt för avbrottet och senast kända fungerande tidpunkt
• senaste ändringar av firmware, restore, regler, objekt, interface, VM-resurser eller lagring
• vid HA: berörd Node, roll, peerstatus och tidpunkt för senaste failover
• tillgänglig aktuell backup och tillhörande Secure Storage Master Key
• för VM: vCPU, vRAM, vNICs, Primary Disk, Report Disk och licensgräns
• återkommande symptom som Reboots och I/O-, NPU-, temperatur- eller lagringsfel

Om Advanced Shell fortfarande går att nå kan även lämpliga loggutdrag sparas. Dessa exempel läser bara de senaste 200 raderna och ändrar inte systemet:

tail -n 200 /log/sysinit.log
tail -n 200 /log/syslog.log
tail -n 200 /log/postgres.log

sysinit.log är den centrala loggen för systemstarten, syslog.log innehåller kernel- och systemhändelser och postgres.log hjälper vid konfigurationsdatabasen. Beroende på show failure-reason används samma skrivskyddade tail-kommando på lämplig detaljlogg, exempelvis:

tail -n 200 /log/networkd.log
tail -n 200 /log/sigdb.log
tail -n 200 /log/npu-startup.log

networkd.log hör till fysiska och virtuella interface, sigdb.log till signaturdatabasen och npu-startup.log endast till hårdvarumodeller med NPU. Alla filer finns inte på alla plattformar. Ytterligare tilldelning finns i Sophos Firewall-tjänster och loggfiler. Loggutdrag kan innehålla konfidentiella uppgifter och ska överföras skyddat.

När WebAdmin går att nå igen bör även ett CTR- eller Troubleshooting-arkiv sparas. Proceduren beskrivs i Spara Sophos Firewall-loggar för support.

Välj ett säkert nästa steg

Efter att bevisen har sparats går det att välja recoveryväg på ett bättre underlag:

1. Tydlig resursavvikelse för VM eller software appliance: Dokumentera det aktuella tillståndet, kontrollera licensgränser och aktuella minimivärden, stäng av VM kontrollerat, korrigera exakt den bekräftade avvikelsen och observera nästa start.
2. Lagrings- eller loggingmeddelande: Kontrollera partitionen och berörd datatyp i skrivskyddat läge. Ta inte bort filer med rm. Anvisningen Kontrollera lagring och Reports säkert visar avsedda diagnos- och rensningsmetoder.
3. Fel direkt efter en firmwareändring: Jämför Build med kända problem och välj först därefter kontrollerat mellan aktuellt Maintenance Release, rollback eller support.
4. NPU-, I/O- eller återkommande hårdvarumeddelande: Förbered ett supportärende och vid behov en RMA. En tillfälligt lyckad Reboot utesluter inte en defekt.
5. Databas-, framework-, regel- eller okänt startfel: Spara utdata och loggar och öppna ett Sophos Support-ärende med hela felbilden. Ta inte bort databasfiler, regelverk eller signaturer manuellt.
6. Reimage som recovery: Använd endast när skada på operativsystemet, supporten eller den dokumenterade recoveryplanen motiverar denna väg. Backup, lösenord och SSMK måste finnas tillgängliga först. Hela proceduren finns under Installera om Sophos Firewall OS.

Kontrollera inte bara WebAdmin efter varje åtgärd. Avgörande är en normal konsolstart, korrekt HA-status, interface- och routingtillstånd, internet- och VPN-anslutningar samt om samma felmeddelande återkommer. Om orsaken förblir oklar eller återkommer ska den inte döljas av ytterligare spontana ändringar.