Sophos Firewall in Failsafe-modus: oorzaak controleren

Wanneer een Sophos Firewall in de Failsafe-modus start, heeft SFOS een kritieke fout vastgesteld en is de normale werking niet gestart. Pakketverwerking, interfaces en managementtoegang kunnen afhankelijk van de oorzaak volledig of gedeeltelijk uitvallen. Uit een nog bereikbare managementpoort mag daarom niet worden geconcludeerd dat de firewall nog steeds betrouwbaar beschermt.

De belangrijkste eerste stap is geen Factory Reset of reimage, maar het bewaren van de oorzaak die SFOS heeft vastgesteld:

1. Maak verbinding via de lokale console, seriële console of hypervisorconsole.
2. Open Device Console in het Failsafe-menu.
3. Voer de volgende alleen-lezen opdracht uit:

show failure-reason

De console kan er daarna bijvoorbeeld zo uitzien:

failsafe> show failure-reason
Unable to apply Firewall Framework

failsafe> is alleen de prompt en wordt niet mee ingevoerd. De exacte melding kan anders luiden. Belangrijk is dat de ongewijzigde uitvoer en de eerste zichtbare consoleregels worden gefotografeerd of gekopieerd. Als SSH in de fouttoestand nog werkt, is de Device Console ook langs deze weg bereikbaar; bij een storing blijft de lokale, seriële of hypervisorconsole de robuustere route.

⚠️ Bewaar gegevens vóór een herstart: Een Reboot kan de zichtbare foutsituatie veranderen of tijdelijk verhelpen. Documenteer vooraf minimaal de foutmelding, SFOS-versie met Build, appliancerol en het tijdstip. Reset to Factory Defaults, Remove Firewall Rules en handmatige ingrepen in de database of het bestandssysteem zijn geen diagnose en kunnen belangrijke configuratie of bewijsmateriaal vernietigen.

Wat de Failsafe-modus betekent

Failsafe is een beschermings- en hersteltoestand. SFOS start deze wanneer een component die nodig is voor een veilige firewallwerking niet correct opstart. Bekende meldingen en werkelijke foutgevallen hebben bijvoorbeeld betrekking op de configuratiedatabase, het firewallframework, de regelset, de logging- of netwerkservice, de handtekeningendatabase of, bij een passend uitgerust XGS-model, de Network Processing Unit (NPU). Dit is geen volledige reparatiematrix; de concrete console-uitvoer blijft bepalend.

Alleen een onbereikbaar WebAdmin bewijst nog geen Failsafe-toestand. Als het verkeer blijft doorlopen en alleen de interface vastloopt, past eerst de gerichte controle of herstart van de WebAdmin GUI. Een echte Failsafe is herkenbaar op de console. Of daarnaast managementtoegang of afzonderlijke interfaces nog werken, hangt af van de oorzaak en is geen bewijs van een gezonde toestand.

Dit onderscheid is belangrijk: bij één uitgevallen service kan een gerichte herstart van die service zinvol zijn. In de Failsafe-modus ontbreekt daarentegen een kritieke startvoorwaarde. Meerdere services op goed geluk opnieuw starten verhult dan eerder de oorzaak dan dat het probleem wordt opgelost.

De oorzaak van Failsafe controleren met show failure-reason

show failure-reason hoort in de Device Console, niet in de Advanced Shell. De opdracht wijzigt geen configuratie. Ze toont de foutklasse die SFOS tijdens het opstarten heeft vastgesteld.

De uitvoer is een beginpunt en nog geen volledige reparatie-instructie. De volgende meldingsgroepen helpen bij de classificatie:

• Configuration database: De firewall kon de configuratiedatabase niet correct starten. Bewaar vóór handmatige reparaties de foutmelding, Build, laatste wijziging en beschikbare back-up. Verwijder of wijzig geen databasebestanden.
• Firewall framework of firewall rules: SFOS kon de basis voor pakketverwerking of de regelset niet toepassen. Relevante informatie bestaat uit de laatste wijzigingen aan regels, objecten, restores of firmware. Alle firewallregels algemeen verwijderen is gegevensverlies en geen correcte eerste diagnose.
• Logging daemon: Een kritieke loggingservice is niet gestart. Controleer naast de foutmelding ook de opslagstatus, Build en logs. Wis Reports of logs niet blind voordat de benodigde gegevens zijn bewaard.
• Network daemon: Netwerkcomponenten konden niet correct starten. Bij virtuele appliances moeten de aanwezige vNICs, adaptervolgorde en hypervisorwijzigingen worden gecontroleerd.
• Signature database: Een noodzakelijke handtekeningendatabase kon niet worden geladen. Patternstatus, opslag en het tijdsverband met updates zijn relevant; verwijder handtekeningenbestanden niet handmatig.
• NPU: Bij een XGS-model met NPU kan al in de eerste consoleregel Network processing unit error staan. Ook als show failure-reason daarna geen bruikbare uitvoer geeft, wordt de volledige console bewaard en wordt een support- of hardwarecase voorbereid.

De exacte schrijfwijze van een melding kan per SFOS-versie verschillen. Voor support is de ongewijzigde uitvoer daarom waardevoller dan een zelfgeschreven samenvatting zoals Firewall start niet.

Platform en laatste wijziging controleren

De volgende stap hangt ervan af of hardware, een virtuele of software-appliance, of een HA-cluster is getroffen. Dezelfde foutmelding mag niet automatisch tot dezelfde maatregel leiden.

Virtuele firewall en software-appliance

Een virtuele firewall kan door ongeschikte resources al naar Failsafe gaan. Voor lokaal uitgevoerde SFOS 22-appliances onder VMware, Hyper-V, KVM en Citrix noemt Sophos momenteel minimaal:

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

Bovendien mogen de geconfigureerde vCPU en vRAM de gekochte licentie niet overschrijden. De minimumwaarden zijn alleen technische startgrenzen en geen productiesizing voor IPS, TLS Inspection of een hoge doorvoer.

De Auxiliary Disk uit de VM-images is deze afzonderlijke Report Disk. Deze is niet optioneel en vervangt de Primary Disk niet. Voor AWS en Azure gelden in plaats daarvan de ondersteunde cloudinstancetypen en platformspecifieke groottes.

Controleer in de hypervisor of beide disks en alle geplande vNICs nog aanwezig en verbonden zijn en in de verwachte volgorde zijn toegewezen. Ook een latere wijziging aan CPU, RAM, diskcontroller of virtueel netwerk hoort in de incidenttijdlijn. De platformverschillen en resourcevereisten worden uitgebreider uitgelegd in een apart artikel.

Voor een SFOS 22-software-appliance zijn x86-64, Legacy BIOS, minimaal 4 GB RAM en twee netwerkkaarten onbetwist. Voor de disk spreken twee actuele Sophos-pagina’s elkaar echter tegen: het algemene platformoverzicht noemt minimaal 10 GB, de nieuwere specifieke pagina voor de software-appliance minimaal 32 GB en beveelt 64 GB aan. Er bestaat dus geen uniforme gepubliceerde Sophos-limiet. Voor nieuwe installaties adviseert Avanet conservatief minimaal 32 GB en zo mogelijk 64 GB; daarmee volgt men de specifiekere productpagina en wordt voorkomen dat het systeem bij de start al krap bemeten is.

Wijzig resources niet willekeurig en meermaals tijdens een onduidelijke herstelpoging. Documenteer eerst de huidige toestand en voer daarna een geplande correctie met een gedefinieerde starttest uit.

Hardware-appliance en NPU

Bij een fysieke XGS worden daarnaast stroomgebeurtenissen, temperatuur, ventilatoren, SSD- of I/O-fouten en de eerste opstartmeldingen meegenomen. Een NPU-fout op een XGS-model dat met een NPU is uitgerust, is geen reden om ongedocumenteerde reset- of serviceopdrachten uit te proberen. Als de melding terugkeert of de diagnose zelf mislukt, is een supportcase met mogelijke RMA-voorbereiding de juiste vervolgstap.

Eén geslaagde herstart bewijst nog niet dat een hardwareprobleem is opgelost. Bij herhaalde uitval helpen ook de bestaande controles voor temperatuur en ventilatoren en de SSD-status.

Failsafe in een HA-cluster

Bij HA wordt eerst vastgesteld welke Node is getroffen en of de peer het productieverkeer stabiel verwerkt. Documenteer Primary of Auxiliary, clusterstatus, laatste rolwisseling en hetzelfde tijdstip op beide appliances.

Start beide Nodes niet tegelijk opnieuw en schakel HA niet op goed geluk uit. Een ongecoördineerde wijziging kan het nog werkende pad in gevaar brengen, de rolverdeling veranderen of een nieuwe opbouw afdwingen. Het artikel High Availability op Sophos Firewall instellen behandelt rollen, synchronisatie en Node-specifieke logs; de concrete Failsafe-oorzaak wordt desondanks op de getroffen Node bewaard.

Na een firmware-update of restore

Als Failsafe direct na een upgrade, rollback of restore optreedt, zijn de bronversie, doelversie en volledige Buildnummer belangrijk. In SFOS 22 heeft Sophos met MR2 Build 546 verschillende specifieke Failsafe-oorzaken opgelost, waaronder fouten na de upgrade naar GA, een logging daemon die niet startte, een volle configuratiepartitie en bepaalde defecte serviceobjecten. Het overzicht van SFOS 22 MR2 vermeldt de opgeloste Issue IDs.

Dit betekent niet dat elke Failsafe-gebeurtenis met een update wordt opgelost. Controleer eerst of de foutmelding en gebruikte Build überhaupt bij een bekende oplossing passen. Een firmwarewijziging vereist nog steeds een back-up, onderhoudsvenster, HA-plan en terugweg. Gebruik daarvoor de voorbereiding van een firmware-update en de SFOS 22 Upgrade Check.

Failed to start Red server service

Als de firewall in Failsafe-modus exact deze melding toont, past het foutbeeld bij NC-178906. Sophos heeft deze Failsafe-fout opgelost met SFOS 22.0 MR2 Build 546. Op een oudere Build wordt na het veiligstellen van het bewijsmateriaal een gecontroleerd recovery- en upgradepad naar Build 546 of nieuwer onderzocht. Als de melding bij Build 546 of nieuwer optreedt, bewijst alleen de Issue ID de oorzaak niet; open dan met de veiliggestelde logs een Support Case.

Stel vóór een herstart of firmwarewijziging de volledige Build, het tijdstip, de getroffen HA-Node en sysinit.log, red.log en syslog.log op het moment van de fout veilig. Verwijder RED-interfaces, RED Firmware Pattern of de RED-configuratie niet op goed geluk en start de RED-service niet herhaaldelijk opnieuw. Als de firewall normaal start en alleen een RED-tunnel offline blijft, past in plaats daarvan RED-probleemoplossing.

Bewijsmateriaal bewaren vóór herstel of herstart

Verzamel zo mogelijk vóór de eerste maatregel die de toestand verandert:

• volledige uitvoer van show failure-reason en de eerste zichtbare opstartregels
• model, serienummer en hardware-, virtueel of softwareplatform
• exacte SFOS-versie inclusief MR en Build
• tijdstip van uitval en laatst bekende werkende tijd
• laatste wijzigingen aan firmware, restore, regels, objecten, interfaces, VM-resources of opslag
• bij HA: getroffen Node, rol, peerstatus en tijdstip van de laatste failover
• beschikbare actuele back-up en bijbehorende Secure Storage Master Key
• bij VM’s: vCPU, vRAM, vNICs, Primary Disk, Report Disk en licentielimiet
• terugkerende symptomen zoals Reboots, I/O-, NPU-, temperatuur- of opslagfouten

Als de Advanced Shell nog bereikbaar is, kunnen ook relevante logfragmenten worden bewaard. Deze voorbeelden lezen alleen de laatste 200 regels en wijzigen het systeem niet:

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

sysinit.log is de centrale log voor de systeemstart, syslog.log bevat kernel- en systeemgebeurtenissen en postgres.log helpt bij de configuratiedatabase. Afhankelijk van show failure-reason wordt dezelfde alleen-lezen tail-opdracht toegepast op de passende detaillog, bijvoorbeeld:

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

networkd.log hoort bij fysieke en virtuele interfaces, sigdb.log bij de handtekeningendatabase en npu-startup.log alleen bij hardwaremodellen met NPU. Niet elk bestand bestaat op elk platform. De verdere toewijzing staat in Sophos Firewall-services en logbestanden. Logfragmenten kunnen vertrouwelijke gegevens bevatten en worden beveiligd overgedragen.

Als WebAdmin weer bereikbaar is, moet ook een CTR- of Troubleshooting-archief worden bewaard. De werkwijze staat in Sophos Firewall-logs bewaren voor support.

Een veilige vervolgstap kiezen

Na het bewaren van het bewijsmateriaal kan het herstelpad beter worden gekozen:

1. Duidelijke resourceafwijking bij een VM of software-appliance: Documenteer de huidige toestand, controleer licentielimieten en actuele minimumwaarden, sluit de VM gecontroleerd af, corrigeer precies de bevestigde afwijking en observeer de volgende start.
2. Opslag- of loggingmelding: Controleer de partitie en het betrokken gegevenstype alleen-lezen. Verwijder geen bestanden met rm. De instructie Opslagruimte en Reports veilig controleren toont de voorziene diagnose- en opschoningsmethoden.
3. Fout direct na een firmwarewijziging: Vergelijk de Build met bekende problemen en kies pas daarna gecontroleerd tussen het actuele Maintenance Release, rollback of support.
4. NPU-, I/O- of terugkerende hardwaremelding: Bereid een supportcase en zo nodig een RMA voor. Een tijdelijk geslaagde Reboot sluit een defect niet uit.
5. Database-, framework-, regel- of onbekende opstartfout: Bewaar uitvoer en logs en open een Sophos Support Case met het volledige foutbeeld. Verwijder geen databasebestanden, regelsets of handtekeningen handmatig.
6. Reimage als herstel: Alleen gebruiken wanneer schade aan het besturingssysteem, support of het gedocumenteerde herstelplan deze route rechtvaardigt. Vooraf moeten back-up, wachtwoord en SSMK beschikbaar zijn. De volledige werkwijze staat onder Sophos Firewall OS opnieuw installeren.

Controleer na elke maatregel niet alleen WebAdmin. Van belang zijn een normale consolestart, correcte HA-status, toestand van interfaces en routing, internet- en VPN-verbindingen en het opnieuw optreden van dezelfde foutmelding. Als de oorzaak onduidelijk blijft of terugkeert, mag deze niet door verdere spontane wijzigingen worden verhuld.