Sophos Firewall Log Viewer toont geen nieuwe logs

Als de Log Viewer geen nieuwe events toont, moet men niet meteen 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. Met Packet capture controleren of het verkeer de firewall bereikt en welke Rule ID wordt verwerkt.
5. Alleen wanneer ook andere verwachte events uitblijven, de SFOS-versie, volledige build en het laatst zichtbare logtijdstip vastleggen.
6. De Garner-workaround alleen gebruiken op SFOS 21.5 MR1 Build 261 en alleen bij het hieronder beschreven 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.
• 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, dan onder Diagnostics > Packet capture een nauw filter zoals host 10.20.30.25 gebruiken en dezelfde test herhalen.

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. De bediening en statuswaarden worden uitgelegd in Packet Capture in Sophos Firewall WebAdmin.

NC-175936 controleren op SFOS 21.5 MR1 Build 261

Sophos documenteert voor SFOS 21.5 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.

De huidige Sophos Known Issues List vermeldt voor 21.5 MR2 geen eenduidig veld met een fixversie. Daarom wordt de volgende workaround niet alleen op basis van een vergelijkbaar symptoom op andere builds gebruikt.

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 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. 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.

Andere builds en terugkerende uitval

Sophos heeft andere, maar niet identieke fouten rond de Log Viewer-database opgelost. SFOS 22.0 MR1 Build 490 bevat met NC-152553 een fix voor een mislukt herstelmechanisme van active.db; NC-169237 over verloren Log Viewer-events door databasecorruptie wordt vermeld voor SFOS 21.5 MR2 Build 323 en SFOS 22.0 GA Build 411. Deze issue-ID’s bewijzen geen fix voor NC-175936 en evenmin automatisch de oorzaak van een actuele storing.

Op een oudere build wordt eerst een ondersteund SFOS-firmware-updatepad gepland. Op een actuele build of na een mislukte Garner-herstart worden geen verdere database- of service-ingrepen geprobeerd.

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;
• 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 een weergave-, database-, opslag-, dienst- en versiespecifieke fout, zonder dat herhaalde herstelpogingen de oorspronkelijke oorzaak verhullen.