Sophos Firewall Log Viewer visar inga nya loggar

Om Log Viewer inte visar några nya händelser på SFOS 22 bör en tjänst inte startas om enbart på grund av en misstanke. Först måste det fastställas om bara en förväntad post saknas eller om den lokala loggvisningen har stannat helt. För normal användning, filter och fälttolkning gäller först Använd Sophos Firewall Log Viewer på rätt sätt. Den säkra snabbproceduren för en stillastående viewer är:

Kontrollera Pause, modul, tidsintervall och aktiva filter i Log Viewer och kör sedan Reset och Refresh.
Kontrollera Log firewall traffic i den berörda brandväggsregeln och verifiera under System services > Log settings loggtypen Firewall för Local reporting.
Skapa en kort anslutning från en känd testklient och notera tidpunkten.
Under Diagnostics > Packet capture > Configure, ställ in ett snävt BPF-filter, aktivera infångning och kontrollera om trafiken når brandväggen och vilket Rule ID som bearbetas.
Stäng av infångningen efter testet. Spara SFOS-version, fullständig build och tidpunkten för den senast synliga loggposten endast om även andra förväntade händelser uteblir.
Använd inte en Garner- eller databasworkaround från en äldre version på SFOS 22. Kontrollera den aktuella underhållsversionen och lämna diagnosuppgifterna till Sophos Support om alla lokala loggar har stannat.
Den bevarade Garner-workarounden nedan gäller endast SFOS 21.5.1 MR1 Build 261 och exakt den dokumenterade felbilden.

På så sätt förblir felsökningen spårbar: ett felaktigt filter eller en regel som inte loggar förväxlas inte med ett fel i loggningsdatabasen.

Varför en enskild loggpost kan saknas

Log Viewer uppdateras normalt automatiskt. Den visar dock endast händelser som den valda modulen sparar lokalt och som inte döljs av den aktuella vyn.

Vanliga orsaker utan ett tekniskt fel i Viewer är:

Pause är aktiverat: nya händelser visas först när vyn återupptas eller uppdateras manuellt.
Modul, tidsintervall eller filter stämmer inte: Reset tar bort alla filter; därefter väljs rätt modul på nytt.
Rule Logging är avstängt: brandväggssessioner visas endast när Log firewall traffic är aktiverat i regeln som faktiskt matchar.
Local reporting är avstängt: under System services > Log settings måste den nödvändiga loggtypen vara vald i kolumnen Local reporting.
Anslutningen är fortfarande öppen: brandväggssessioner loggas normalt vid händelsen Destroy, när anslutningen avslutas. En post kan därför visas senare än den första anslutningen.
Sessionen avslutas utan en Destroy-händelse: om exempelvis internetanslutningen bryts kan sessionen stängas utan att någon loggpost skapas. Posten är då inte bara fördröjd, utan skapas aldrig.
Trafiken når inte brandväggen: en saknad loggpost bevisar inte att brandväggen har kastat paketet. Klienten, en överordnad router, DNS eller en annan väg kan ha stoppat anslutningen tidigare.
Firewall Log suppression slår samman upprepningar: undertryckta efterföljande brandväggshändelser kan sammanföras i Log occurrence i stället för att visas som många enskilda rader.

Om Log Viewer fortsätter att visa nya system- eller brandväggshändelser från andra tester fungerar visningen i princip. Orsaken ligger då troligare i Rule Logging, modulvalet, filter, sessionens slut eller den faktiska paketvägen. För denna avgränsning är Kontrollera brandväggsregel med Log Viewer, Policy Tester och Packet Capture en lämpligare procedur.

Skapa ett kontrollerat testflöde

Ett reproducerbart test är mer tillförlitligt än att vänta på slumpmässig användartrafik. I följande exempel har testklienten den anpassningsbara IP-adressen 10.20.30.25. På klienten – inte i brandväggens skal – skapas en kort HTTPS-anslutning:

curl -I https://example.com/

example.com är en reserverad exempeldomän. En egen känd och tillåten HTTPS-tjänst kan också användas för testet. Det viktiga är att processen avslutar anslutningen igen och att tidpunkt, klient-IP och mål är kända.

Kontrollera därefter i denna ordning:

Kontrollera under Rules and policies > Firewall rules att Log firewall traffic är aktiverat i den förväntade regeln.
I Log Viewer, kör Reset, välj modulen Firewall och ett lämpligt tidsintervall och filtrera efter 10.20.30.25.
Vänta några sekunder och uppdatera manuellt en gång, eftersom brandväggshändelsen kan visas först när sessionen avslutas.
Om posten saknas, öppna Diagnostics > Packet capture, klicka på Configure, ange det snäva filtret host 10.20.30.25 under Enter BPF string och spara. Ersätt IP-adressen med testklientens faktiska adress.
Aktivera Packet capture, upprepa testet en gång och stäng sedan av infångningen. Då begränsas den till den kända klienten och ett kort tidsfönster.

Observationen avgör nästa steg:

Packet Capture ser ingen testtrafik: sök orsaken före brandväggen eller på klienten.
Packet Capture ser ett annat Rule ID: kontrollera regeln som faktiskt matchar och dess loggning.
Andra nya händelser visas i Log Viewer: Viewer har inte stannat helt; fortsätt kontrollera filter, loggtyp och den specifika regeln.
Packet Capture bekräftar flödet, Rule Logging och Local reporting stämmer, men alla nya händelser uteblir: kontrollera build och den lokala loggbearbetningen.

Packet Capture visar paketflödet men reparerar inte loggvisningen. Om bufferten är full och Wrap capture buffer once full inte är valt avbryter SFOS infångningen automatiskt; Clear frigör bufferten för ett nytt test. Hantering och statusvärden förklaras i Packet Capture i Sophos Firewall WebAdmin.

Klassificera felet på SFOS 22

Sophos Known Issues List begränsar NC-175936 till SFOS 21.5.1 MR1 Build 261 och anger uttryckligen att problemet är löst i version 22. Den tillhörande Garner-omstarten är därför inte en reparationsväg för SFOS 22.

Versionsinformationen för SFOS 22 listar fler ändringar i Logging Framework. SFOS 22.0 GA Build 411 åtgärdade NC-169237, där databaskorruption gjorde att Log Viewer förlorade händelser. SFOS 22.0 MR1 Build 490 åtgärdade NC-152553, en misslyckad återställningsmekanism för active.db. Den senaste versionen som anges där, SFOS 22.0 MR2 Build 546, förbättrar Log Viewer-prestanda med NC-181520.

Dessa poster bekräftar åtgärdade fel, men identifierar inte orsaken till ett aktuellt avbrott. På SFOS 22 ska exakt version och build dokumenteras och en stödd uppgraderingsväg till aktuell underhållsversion kontrolleras. Ändra inte databasfiler och starta inte om en loggningstjänst från skalet om händelser fortfarande saknas.

Kontrollera `NC-175936` på SFOS 21.5.1 MR1 Build 261

Sophos dokumenterar felet NC-175936 för SFOS 21.5.1 MR1 Build 261: filen /tmp/eventlogs/active.db kan saknas, vilket gör att Log Viewer inte längre visar nya data. Enligt Sophos fortsätter brandväggen att behandla trafik och upprätthålla säkerhetsfunktionerna. Detta uttalande beskriver det kända felet och är inte en allmän hälsokontroll för en brandvägg utan loggar.

Sophos anger också uttryckligen att problemet är löst i version 22. Därför ska följande äldre workaround inte användas på SFOS 22 eller på en annan build enbart på grund av ett liknande symtom.

Förkontroller som endast läser data i Advanced Shell

Notera först fullständig build, tidpunkt, senast synliga händelse och, vid HA, den berörda noden. Om WebAdmin fortfarande fungerar sparas garner.log och om möjligt en Consolidated Troubleshooting Report före ändringen.

Anslut sedan via den dokumenterade SSH-åtkomsten till Sophos Firewall och öppna Advanced Shell. Följande kommandon läser endast lagringsstatus, fil och logg:

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

df -kh /tmp visar om det finns ledigt utrymme i filsystemet. ls -l bekräftar om active.db finns; om filen saknas kan skalet, beroende på build, visa ett meddelande som No such file or directory. Kontrollera garner.log efter fel vid den dokumenterade testtidpunkten. Fler tjänstnamn och loggfiler sorteras i Tilldela tjänstloggar korrekt i Sophos Firewall.

Om /tmp är fullt, filen finns, build avviker eller symtomet inte är entydigt ska följande omstart inte genomföras. Filer under /tmp/eventlogs får inte tas bort, kopieras eller skapas manuellt.

Starta om Garner kontrollerat en gång

⚠️ Tillståndsändrande kommando: denna workaround gäller endast för den belagda felbilden på SFOS 21.5.1 MR1 Build 261. Spara först loggar och systemstatus. Kör inte kommandot okontrollerat på båda noderna i ett HA-kluster. Starta inte om Garner upprepade gånger och reparera eller radera aldrig active.db manuellt.

För NC-175936 anger Sophos exakt detta kommando i Advanced Shell:

service garner:restart -ds nosync

Kommandot har hämtats till den här artikeln från den aktuella Sophos Known Issues List, men har inte labbtestats på en appliance. En tjänsteomstart kan inte återställas; om filen fortfarande saknas eller händelserna inte visas ska ingreppet avslutas och det sparade utgångsläget lämnas till Sophos Support. Efter den enda omstarten kontrolleras filen och de senaste Garner-meddelandena på nytt med kommandon som endast läser data:

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

Kör därefter Reset och Refresh i Log Viewer och upprepa samma korta testflöde. Åtgärden är inte framgångsrik förrän en ny händelse med rätt tidsstämpel visas. Att active.db finns bevisar inte i sig att hela loggvägen fungerar igen.

Om SFOS 22 fortfarande inte visar nya händelser

Om Packet Capture visar det kontrollerade testflödet på SFOS 22, Rule Logging och Local reporting stämmer och nya händelser ändå saknas i alla moduler ska först en stödd uppdateringsväg för SFOS-firmware till aktuell underhållsversion planeras. Om problemet kvarstår på aktuell build ska inga ingrepp i databas eller tjänster göras.

För ett supportärende sparas minst följande:

appliancemodell, SFOS-version och fullständig build;
vid HA den berörda noden och dess roll;
senast synliga tidsstämpel i Log Viewer och tidpunkt för testflödet;
modul, filter, Rule ID, Source, Destination och Service för testet;
status för Log firewall traffic och Local reporting;
resultat från Packet Capture;
för den exakt matchande felbilden i 21.5.1 MR1, utdata från df -kh /tmp och ls -l /tmp/eventlogs/active.db;
garner.log, vid behov fwlog.log och iview.log samt om möjligt en CTR före ytterligare ändringar;
information om huruvida Garner startades om en gång och vad som ändrades därefter.

På så sätt kan Sophos skilja mellan visnings-, databas-, lagrings-, tjänste- och versionsspecifika fel utan att upprepade reparationsförsök döljer den ursprungliga orsaken.