Sophos Firewall Log Viewer visar inga nya loggar

Om Log Viewer inte visar några nya händelser bör en tjänst inte startas om direkt. 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 loggtypen Firewall under Local reporting i System services > Log settings.
Skapa en kort anslutning från en känd testklient och notera tidpunkten.
Använd Packet capture för att kontrollera om trafiken når brandväggen och vilket Rule ID som bearbetas.
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 Garner-workaround endast på SFOS 21.5 MR1 Build 261 och bara för felbilden som beskrivs nedan.

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.
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.
Kör Reset i Log Viewer, 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, använd ett snävt filter som host 10.20.30.25 under Diagnostics > Packet capture och upprepa samma test.

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. Hantering och statusvärden förklaras i Packet Capture i Sophos Firewall WebAdmin.

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

Sophos dokumenterar felet NC-175936 för SFOS 21.5 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.

Den aktuella Sophos Known Issues List anger inget entydigt fält med fixversion för 21.5 MR2. Därför används följande workaround inte på andra builds 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 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. 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.

Andra builds och återkommande avbrott

Sophos har åtgärdat andra, men inte identiska, fel kring Log Viewer-databasen. SFOS 22.0 MR1 Build 490 innehåller med NC-152553 en fix för en misslyckad återställningsmekanism för active.db; NC-169237, som gäller förlorade Log Viewer-händelser på grund av databaskorruption, är listad för SFOS 21.5 MR2 Build 323 och SFOS 22.0 GA Build 411. Dessa Issue ID:n bevisar varken en fix för NC-175936 eller automatiskt orsaken till ett aktuellt avbrott.

På en äldre build planeras först en stödd uppdateringsväg för SFOS-firmware. På en aktuell build eller efter en misslyckad omstart av Garner ska inga ytterligare ingrepp i databas eller tjänster provas.

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