Sophos Firewall Log Viewer toont geen nieuwe logs

Als de Log Viewer op SFOS 22 geen nieuwe events toont, moet men niet op basis van alleen een vermoeden een dienst opnieuw starten. Eerst moet duidelijk zijn of alleen een verwachte logregel ontbreekt of dat de lokale logweergave volledig stilstaat. Voor normale bediening, filters en veldinterpretatie geldt eerst Sophos Firewall Log Viewer correct gebruiken. De veilige snelle aanpak voor een stilstaande viewer is:

1. In Log Viewer Pause, module, periode en ingestelde filters controleren en daarna Reset en Refresh uitvoeren.
2. In de betrokken firewallregel Log firewall traffic en onder System services > Log settings het logtype Firewall bij Local reporting controleren.
3. Vanaf een bekende testclient een korte verbinding maken en het tijdstip noteren.
4. Onder Diagnostics > Packet capture > Configure een nauw BPF-filter instellen, de capture inschakelen en controleren of het verkeer de firewall bereikt en welke Rule ID wordt verwerkt.
5. De capture na de test weer uitschakelen. Alleen wanneer ook andere verwachte events uitblijven, de SFOS-versie, volledige build en het laatst zichtbare logtijdstip vastleggen.
6. Op SFOS 22 geen Garner- of databaseworkaround uit een oudere versie gebruiken. Controleer de actuele maintenance release en geef de diagnosegegevens aan Sophos Support als alle lokale logs stilstaan.
7. De hieronder behouden Garner-workaround hoort uitsluitend bij SFOS 21.5.1 MR1 Build 261 en het exact gedocumenteerde foutbeeld.

Zo blijft de foutanalyse traceerbaar: een verkeerd filter of een regel die niet logt, wordt niet verward met een fout in de loggingdatabase.

Waarom één logregel kan ontbreken

De Log Viewer wordt normaal automatisch bijgewerkt. Hij toont echter alleen events die de geselecteerde module lokaal opslaat en die niet door de huidige weergave worden verborgen.

Veelvoorkomende oorzaken zonder een technisch defect van de Viewer zijn:

• Pause is actief: nieuwe events worden pas zichtbaar nadat de weergave is hervat of handmatig is vernieuwd.
• Module, periode of filters kloppen niet: Reset verwijdert alle filters; daarna wordt de inhoudelijk juiste module opnieuw geselecteerd.
• Rule Logging is uitgeschakeld: firewallsessies verschijnen alleen wanneer Log firewall traffic actief is in de regel die daadwerkelijk matcht.
• Local reporting is uitgeschakeld: onder System services > Log settings moet het benodigde logtype in de kolom Local reporting geselecteerd zijn.
• De verbinding is nog open: firewallsessies worden normaal bij het Destroy-event gelogd, wanneer de verbinding eindigt. Een logregel kan daarom later verschijnen dan de eerste verbindingsopbouw.
• De sessie eindigt zonder Destroy-event: als bijvoorbeeld de internetverbinding wegvalt, kan de sessie worden gesloten zonder dat er een logregel ontstaat. De regel is dan niet alleen vertraagd, maar wordt helemaal niet aangemaakt.
• Het verkeer bereikt de firewall niet: een ontbrekende logregel bewijst niet dat de firewall het pakket heeft verworpen. De client, een upstreamrouter, DNS of een ander pad kan de verbinding al eerder verhinderen.
• Firewall Log suppression voegt herhalingen samen: onderdrukte opeenvolgende firewall-events kunnen onder Log occurrence worden samengevoegd in plaats van als veel afzonderlijke regels te verschijnen.

Als de Log Viewer bij andere tests nog steeds nieuwe systeem- of firewall-events toont, werkt de weergave in principe. De oorzaak ligt dan eerder bij Rule Logging, de gekozen module, filters, het einde van de sessie of het daadwerkelijke pakketpad. Voor deze afbakening is Firewallregel controleren met Log Viewer, Policy Tester en Packet Capture de geschiktere procedure.

Een gecontroleerde teststroom genereren

Een reproduceerbare test is betrouwbaarder dan wachten op willekeurig gebruikersverkeer. In het volgende voorbeeld heeft de testclient het aanpasbare IP-adres 10.20.30.25. Op de client – niet in de shell van de firewall – wordt een korte HTTPS-verbinding opgezet:

curl -I https://example.com/

example.com is een gereserveerd voorbeelddomein. Voor de test kan ook een eigen bekende en toegestane HTTPS-dienst worden gebruikt. Belangrijk is dat het proces de verbinding weer beëindigt en dat tijdstip, client-IP en bestemming bekend zijn.

Daarna wordt in deze volgorde gecontroleerd:

1. Onder Rules and policies > Firewall rules controleren of bij de verwachte regel Log firewall traffic is ingeschakeld.
2. In Log Viewer Reset uitvoeren, de module Firewall en een passende periode selecteren en filteren op 10.20.30.25.
3. Enkele seconden wachten en eenmaal handmatig vernieuwen, omdat het firewall-event mogelijk pas na het einde van de sessie verschijnt.
4. Ontbreekt de logregel, open dan Diagnostics > Packet capture, klik op Configure, voer bij Enter BPF string het nauwe filter host 10.20.30.25 in en sla het op. Vervang het IP-adres door het echte adres van de testclient.
5. Schakel Packet capture in, herhaal de test eenmaal en schakel de capture daarna weer uit. Zo blijft de opname beperkt tot de bekende client en een kort tijdvenster.

De waarneming bepaalt de volgende stap:

• Packet Capture ziet geen testverkeer: de oorzaak vóór de firewall of op de client zoeken.
• Packet Capture ziet een andere Rule ID: de regel die daadwerkelijk matcht en de logging daarvan controleren.
• Andere nieuwe Log Viewer-events verschijnen: de Viewer staat niet volledig stil; filters, logtype en de concrete regel verder onderzoeken.
• Packet Capture bevestigt de flow, Rule Logging en Local reporting kloppen, maar alle nieuwe events blijven uit: build en lokale logverwerking controleren.

Packet Capture toont de pakketstroom, maar herstelt de logweergave niet. Als de buffer vol is en Wrap capture buffer once full niet is geselecteerd, stopt SFOS de capture automatisch; Clear maakt de buffer vrij voor een nieuwe test. De bediening en statuswaarden worden uitgelegd in Packet Capture in Sophos Firewall WebAdmin.

De storing op SFOS 22 indelen

De Sophos Known Issues List beperkt NC-175936 tot SFOS 21.5.1 MR1 Build 261 en vermeldt expliciet dat het probleem in versie 22 is opgelost. De bijbehorende Garner-herstart is daarom geen herstelprocedure voor SFOS 22.

De release notes van SFOS 22 noemen verdere wijzigingen in het Logging Framework. SFOS 22.0 GA Build 411 verhielp NC-169237, waarbij databasecorruptie tot verloren Log Viewer-events leidde. SFOS 22.0 MR1 Build 490 verhielp met NC-152553 een mislukt herstelmechanisme voor active.db. De nieuwste daar genoemde versie, SFOS 22.0 MR2 Build 546, verbetert met NC-181520 de prestaties van Log Viewer.

Deze vermeldingen bevestigen opgeloste fouten, maar bepalen niet de oorzaak van een actuele storing. Leg op SFOS 22 de exacte versie en build vast, controleer een ondersteund upgradepad naar de actuele maintenance release en wijzig geen databasebestanden of loggingdienst vanuit de shell als events blijven ontbreken.

NC-175936 controleren op SFOS 21.5.1 MR1 Build 261

Sophos documenteert voor SFOS 21.5.1 MR1 Build 261 de fout NC-175936: het bestand /tmp/eventlogs/active.db kan ontbreken, waardoor de Log Viewer geen nieuwe gegevens meer toont. Volgens Sophos blijft de firewall daarbij verkeer verwerken en blijven de beveiligingsfuncties actief. Deze uitspraak beschrijft de bekende fout en is geen algemene gezondheidscontrole voor een firewall zonder logs.

Sophos vermeldt ook expliciet dat dit probleem in versie 22 is opgelost. Gebruik de volgende legacy-workaround daarom niet op SFOS 22 en evenmin op een andere build op basis van alleen een vergelijkbaar symptoom.

Alleen-lezen pre-checks in de Advanced Shell

Eerst worden de volledige build, het tijdstip, het laatst zichtbare event en bij HA de betrokken node genoteerd. Als WebAdmin nog werkt, worden garner.log en bij voorkeur een Consolidated Troubleshooting Report vóór de wijziging veiliggesteld.

Daarna maakt men verbinding via de gedocumenteerde SSH-toegang tot Sophos Firewall en opent men de Advanced Shell. De volgende opdrachten lezen alleen de opslagstatus, het bestand en het log:

df -kh /tmp
ls -l /tmp/eventlogs/active.db
tail -n 200 /log/garner.log

df -kh /tmp toont of er nog vrije ruimte op het bestandssysteem beschikbaar is. ls -l bevestigt of active.db bestaat; als het bestand ontbreekt, kan de shell afhankelijk van de build een melding zoals No such file or directory tonen. garner.log wordt gecontroleerd op fouten rond het gedocumenteerde testtijdstip. Andere dienstnamen en logbestanden worden ingedeeld in Sophos Firewall-servicelogs correct toewijzen.

Als /tmp vol is, het bestand bestaat, de build afwijkt of het symptoom niet eenduidig is, wordt de volgende herstart niet uitgevoerd. Bestanden onder /tmp/eventlogs worden niet verwijderd, gekopieerd of handmatig aangemaakt.

Garner eenmaal gecontroleerd opnieuw starten

⚠️ Opdracht die de toestand wijzigt: deze workaround geldt alleen voor het aangetoonde foutbeeld op SFOS 21.5.1 MR1 Build 261. Stel vooraf logs en systeemstatus veilig. Voer de opdracht in een HA-cluster niet ongecontroleerd op beide nodes uit. Start Garner niet herhaaldelijk opnieuw en herstel of verwijder active.db nooit handmatig.

Sophos noemt voor NC-175936 in de Advanced Shell exact deze opdracht:

service garner:restart -ds nosync

De opdracht is voor dit artikel overgenomen uit de huidige Sophos Known Issues List, maar niet in een lab op een appliance getest. Een herstart van een dienst kan niet worden teruggedraaid; blijft het bestand ontbreken of verschijnen events nog steeds niet, stop dan hier en geef de vastgelegde uitgangssituatie aan Sophos Support. Na de eenmalige herstart worden het bestand en de laatste Garner-meldingen opnieuw alleen-lezen gecontroleerd:

ls -l /tmp/eventlogs/active.db
tail -n 50 /log/garner.log

Voer daarna in Log Viewer Reset en Refresh uit en herhaal dezelfde korte teststroom. De maatregel is pas succesvol wanneer een nieuw event met de juiste tijdstempel verschijnt. Alleen het bestaan van active.db bewijst nog niet dat het volledige logpad weer werkt.

Als SFOS 22 nog steeds geen nieuwe events toont

Als Packet Capture op SFOS 22 de gecontroleerde teststroom toont, Rule Logging en Local reporting kloppen en nieuwe events toch in alle modules ontbreken, plan dan eerst een ondersteund SFOS-firmware-updatepad naar de actuele maintenance release. Blijft het probleem op de actuele build bestaan, voer dan geen database- of service-ingrepen uit.

Voor een supportcase worden minimaal de volgende gegevens veiliggesteld:

• appliancemodel, SFOS-versie en volledige build;
• bij HA de betrokken node en de rol daarvan;
• laatst zichtbare tijdstempel in Log Viewer en tijdstip van de teststroom;
• module, filters, Rule ID, Source, Destination en Service van de test;
• status van Log firewall traffic en Local reporting;
• resultaat van Packet Capture;
• bij het exact passende 21.5.1 MR1-foutbeeld de uitvoer van df -kh /tmp en ls -l /tmp/eventlogs/active.db;
• garner.log, indien nodig fwlog.log en iview.log, en waar mogelijk een CTR vóór verdere wijzigingen;
• informatie of de Garner-herstart eenmaal is uitgevoerd en wat daarna veranderde.

Zo kan Sophos onderscheid maken tussen weergave-, database-, opslag-, service- en versiespecifieke fouten zonder dat herhaalde herstelpogingen de oorspronkelijke oorzaak verhullen.