Hitta rätt tjänsteloggar i Sophos Firewall

I Sophos Firewall finns tre viktiga nivåer för felsökning: händelseloggar i Log Viewer, diagnostikverktyg i WebAdmin samt tjänste- och loggfiler på brandväggen. Log Viewer passar bra för snabba frågor som ”tilläts eller blockerades anslutningen?”. Filerna under /log är viktigare när en tjänst inte startar, en VPN-tunnel är instabil, webbfiltret fungerar oväntat eller supporten behöver detaljerade uppgifter.

Den här artikeln ordnar de viktigaste tjänsterna och loggfilerna efter typiska administratörsproblem. Den hjälper också när ett tekniskt tjänstnamn visas på instrumentpanelen, i Advanced Shell eller i ett supportärende och det inte omedelbart framgår vilken brandväggsfunktion som ligger bakom. Namn som zebra, warren, awed, garner eller strongswan är inte självförklarande i det dagliga arbetet.

Val av verktyg och krav

Innan du söker i loggfilerna bör du avgöra vilket verktyg som snabbast ger svaret. Många fall kan redan avgränsas med Log Viewer eller Packet Capture. Skalet blir användbart först när själva tjänsten behöver kontrolleras eller supporten behöver detaljerade loggdata.

Vilket felsökningsverktyg är lämpligt?

Alla brandväggsproblem behöver inte börja i ett skal. Ofta går det snabbare att börja med ett annat verktyg:

• Anslutning tillåten eller blockerad? Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.
• Visar hela Log Viewer inga nya händelser? Kontrollera filter, loggning och den buildspecifika Garner-lösningen.
• Startade hela brandväggen oväntat om? Klassificera först omstarten som reboot av appliance-enheten, HA-failover eller tjänsteavbrott och spara därefter sysinit.log, syslog.log och CTR.
• Paketen kommer fram, men det är oklart om de skickas vidare? Använd Sophos Firewall Packet Capture i WebAdmin.
• Behöver paketinsamlingen köras längre, sparas som PCAP eller analyseras i Wireshark? Sophos Firewall tcpdump: samla in paket via CLI.
• Misstänks en konfigurationsändring vara orsaken? Kontrollera granskningsloggarna i Sophos Firewall.
• Har en ändring från Sophos Fusion (tidigare Sophos Central) fastnat? Kontrollera brandväggens uppgiftskö i Sophos Fusion.
• Rapporter eller historik behövs i Sophos Fusion? Aktivera och använd Sophos Firewall Central Reporting.
• Loggar måste skickas till SIEM, SOC eller en loggserver på lång sikt? Skicka Sophos Firewall-syslog till SIEM.
• Trafikflöden, bandbreddstoppar eller kommunikationsmönster är i fokus? Konfigurera sFlow-övervakning på Sophos Firewall.
• Körs inte en tjänst eller behöver supporten loggar? Den här artikeln.
• Spara lokala loggar för Sophos Support eller Avanet? Spara Sophos Firewall-loggar för support och analys.
• Förbered ett supportärende? Öppna ett Sophos-supportärende: förberedelse och portal.

Ordningen är viktig. Log Viewer visar ofta snabbast vilken regel eller modul som fattade beslutet. Packet Capture visar paketflödet i WebAdmin. tcpdump är användbart när det behövs en längre insamling, en PCAP-fil eller ett mycket exakt CLI-filter. Tjänsteloggar och debugloggning hjälper när en viss tjänst är problemet eller när data behöver samlas in för Sophos Support.

Vid rena frågor om nåbarhet kompletterar Diagnostics > Tools loggsökningen med Ping, Traceroute samt DNS- och ruttuppslagningar. Ping kontrollerar nåbarheten, Traceroute vägen och en uppslagning namnupplösningen respektive rutten. De grundläggande diagnostikkommandona hjälper dig att välja verktyg; ett lyckat test från brandväggen ersätter inte ett test från den berörda klienten.

Snabbt insteg baserat på symtom

Om det är oklart vilken logg som är relevant är det bäst att börja med symtomet i stället för tjänstnamnet.

• En enskild anslutning fungerar inte: Kontrollera först Log Viewer med källa, destination, tjänst och tid. Använd sedan Packet Capture, firewall_rule.log och nat_rule.log.
• VPN-tunneln är nere eller instabil: Kontrollera VPN-status, peer-IP, tid och Log Viewer. Kontrollera sedan strongswan.log, charon.log, sslvpn.log och diagnostikdata för IPsec.
• WebAdmin, User Portal eller SSH kan inte nås: Kontrollera Device Access, Local Service ACL och den berörda zonen. Använd sedan apache.log, tomcat.log, sshd.log och Packet Capture på målporten.
• Webbfilter, TLS Inspection eller IPS blockerar oväntat: Kontrollera modulen i Log Viewer och policy-ID. Jämför sedan ips.log, awarrenhttp.log och Packet Capture.
• En Sophos Fusion-uppgift hänger sig: Jämför Central Task Queue med den lokala statusen. Kontrollera sedan centralmanagement.log, sophos-central.log och fwcm-api-executor.log.
• HA beter sig olika per nod: Bestäm aktiv nod, hjälpnod och påverkad trafikväg. Logga sedan in direkt på den berörda noden och kontrollera HA-loggarna.
• Lokala rapporter saknas eller lagringsutrymmet är fullt: Kontrollera rapportinställningar, lagringsutrymme och Central Reporting. Använd sedan reportdb.log, garner.log och analys av lagringsutrymme.

Detta arbetssätt undviker en vanlig fälla: att söka i en tjänstelogg innan regelmatchning, Device Access, NAT eller routing först har verifierats.

Log Viewer eller loggfil?

Log Viewer öppnas uppe till höger i WebAdmin-konsolen. Den uppdateras automatiskt, kan filtreras efter modul, tid, fältvärden och fritext samt exportera loggposter som CSV.

För att skydda användarnamn samt IP-, MAC- och e-postadresser i den dagliga loggvyn kan Data Anonymization för lokala loggar och rapporter användas. Effekten i Log viewer bevisar inte automatiskt att filer under /log, CTR, Remote Syslog eller Central anonymiserar samma identiteter; varje utdataväg kontrolleras separat.

Felsökningsloggarna finns i katalogen /log. Den officiellt dokumenterade vägen går via CLI: logga in, välj 5 Device Management och sedan 3 Advanced Shell. SSH är vanligtvis smidigare för längre sessioner med tail, grep eller less. Säker förberedelse beskrivs i Anslut till Sophos Firewall via SSH.

Före längre skalsessioner bör det vara tydligt vilket administrationsnätverk anslutningen upprättas från, om SSH-fingeravtrycket har verifierats och om Advanced Shell verkligen behövs. För många inledande kontroller räcker Log Viewer eller Packet Capture i WebAdmin.

Som en tumregel hjälper denna ordning:

1. Ett enskilt trafikflöde påverkas: filtrera Log Viewer efter källa, destination, tjänst och tid.
2. Log Viewer visar inget beslut: starta Packet Capture med ett snävt filter.
3. Packet Capture visar Incoming, men inget tydligt beslut: kontrollera Rule ID, NAT ID, Firewall ID 0, returvägen och lämplig loggfil.
4. En viss tjänst verkar instabil: följ lämplig fil under /log med tail -f.
5. Ett fel är sporadiskt eller kräver support: förbered tidsfönster, filter, loggarkiv och vid behov tcpdump.
6. Normala loggar räcker inte: aktivera debugloggning endast för den berörda tjänsten och under en kort tid.

På så sätt hålls analysen avgränsad. Samla först in synliga observationer, gå sedan vidare till paketflödet och först därefter till tjänsteloggar eller debugloggning. Det minskar risken för att omfattande debugloggning aktiveras för tidigt eller att fel loggfil analyseras.

Läsa loggfiler i Advanced Shell

Innan du undersöker /log bör testfallet dokumenteras så noggrant som möjligt: lokal tid, berörd käll-IP, destinations-IP, port, användare, modul och förväntat beteende. Dessa uppgifter avgör om logganalysen blir användbar eller bara leder till en lång sökning bland gamla poster.

1. Logga in i CLI, välj 5 Device Management och sedan 3 Advanced Shell.
2. Byt till loggkatalogen.

cd /log

Användbara kommandon:

tail -f firewall_rule.log
tail -f nat_rule.log
grep -i error ips.log
less strongswan.log
service -S | grep ips

De viktigaste kommandona från Advanced Shell:

• Följ i realtid: tail -f /log/<logfilename>.log, till exempel tail -f /log/ips.log.
• Läs en statisk loggfil: less /log/<logfilename>.log, till exempel less /log/ips.log.
• Sök efter ett begrepp: grep <keyword> /log/<logfilename>.log, till exempel grep error /log/ips.log.
• Läs tjänstens status: använd service -S eller begränsa till ett namn, till exempel service -S | grep ips. Kontrollen ändrar inte tjänsten.

För ett snävt livefilter kan du lägga till datum eller klientadress:

tail -f /log/ips.log | grep 2026-10-10
tail -f /log/ips.log | grep 192.0.2.10
less /log/ips.log | grep error

Datumet och 192.0.2.10 är exempelvärden: ersätt dem med datumet som visas i loggen respektive den berörda klientens IP-adress. tail -f visar bara de sista befintliga raderna och nytillkomna poster, inte automatiskt hela dagens historik. För redan sparade poster använder du exempelvis grep 2026-10-10 /log/ips.log. Om filtret inte ger några träffar ska du först kontrollera tidsformat, tidszon, IP-adress och loggfil innan du misstänker att loggning saknas. I less /log/ips.log går Shift+G till filens slut, Enter en rad framåt och q avslutar visningen; Ctrl+C avslutar en pågående insamling med tail -f. Pipelinen med less ger filtrerad textutmatning och inte en interaktiv less-vy. Dessa kommandon läser loggar men ändrar varken regler eller debugläget.

För support eller efterföljande analys bör inte bara enskilda loggrader kopieras. Ett bättre underlag är ett tydligt tidsintervall, det reproducerade testet, relevanta skärmbilder från Log Viewer eller Packet Capture och vid behov ett komplett loggarkiv. Lokala loggar roteras; därför bör viktiga data sparas medan händelsen fortfarande omfattas av den tillgängliga perioden. Förfarandet beskrivs i Spara Sophos Firewall-loggar för extern analys.

Ladda ned felsökningsloggar i WebAdmin

Alla loggsamlingar behöver inte sättas samman manuellt i Advanced Shell. WebAdmin samlar filerna under Diagnostics > Tools.

I praktiken finns det två sätt:

• Enskilda loggfiler: Öppna Diagnostics > Tools > Troubleshooting logs, välj de berörda loggfilerna och ladda ned dem som en komprimerad fil.
• Konsoliderad felsökningsrapport (CTR): Använd Diagnostics > Tools > Consolidated troubleshooting report när supporten behöver alla loggar samt systemtillstånd, processer och resursdata i ett paket.

Detta är praktiskt när ett tydligt avgränsat loggpaket räcker. CTR passar bättre när Sophos Support behöver en bred ögonblicksbild av systemet. Ange en tydlig orsak, exempelvis ärendenummer, tidsperiod eller felmönster. Rapporten laddas ned krypterad; filnamnet innehåller också brandväggens serienummer och hör därför inte hemma i offentliga bilagor.

Som standard innehåller en CTR 10 000 rader per service subsystem log. I Device Console kan värdet bara anges mellan 250 och 10 000 och därmed bara minskas från standardvärdet. Default subsystem logs innehåller samtliga rader. Gränsen gäller bara CTR; fullständiga enskilda filer finns fortfarande via Troubleshooting logs eller Advanced Shell.

Viktigt: Ett nedladdat loggpaket ersätter inte kontextuppgifter. Supporten behöver fortfarande tid med tidszon, berörda IP-adresser, användare, tunnelnamn, regel-ID, NAT-ID och en kort beskrivning av exakt vad som reproducerades.

För HA-kluster måste man också tänka på att loggar och rapporter inte automatiskt synkroniseras mellan Primary och Auxiliary. Varje nod innehåller loggarna för trafiken och tjänsterna som den själv har bearbetat. Vid nodspecifika fel måste därför den berörda noden kontrolleras.

Förstå loggrotation och flyktiga data

Troubleshooting Logs skapas först i minnet och kopieras sedan av brandväggen till filsystemet. Om brandväggen slutar svara kan poster som ännu inte har kopierats gå förlorade. En oväntad omstart eller låsning är därför inget skäl att skjuta upp bevissäkringen; spara först tillgänglig CTR, loggar och tidsdata.

Varje delsystem har egna storleks- och lagringsgränser beroende på hur kritiskt det är och vilken appliance-modell som används. När den aktiva filen når sin gräns komprimerar SFOS den som .gz och fortsätter skriva under det ursprungliga filnamnet. Om även rotationerna når delsystemets gräns raderas den äldsta komprimerade filen först. Antalet rotationer och den tillgängliga historiken är därför inte samma för alla tjänster.

Byt inte namn på och radera inte loggfiler eller .gz-rotationer manuellt. Följ Hantera lagringsutrymme och rapporter kontrollerat för lagringsanalys, export och dokumenterade purge-kommandon.

Advanced Shell eller Device Console?

I Sophos Firewall finns det två olika konsolområden som ofta förväxlas:

• Device Console: Sophos CLI för brandväggsspecifika kommandon, till exempel routingprioritet, IPsec-rutter eller systemalternativ.
• Advanced Shell: Linux-liknande skal för filsystem, loggfiler och skrivskyddade kommandon som tail, grep, less och service -S.

Alla kommandon fungerar inte i båda områdena. /log, tail -f, grep och service -S hör till Advanced Shell. De dokumenterade kommandona system diagnostics ... för CTR-gränser, loggrensning och undersystemsdebug hör till Device Console.

Denna skillnad är viktig eftersom många fel helt enkelt uppstår när ett korrekt kommando anges på fel plats.

Loggningen måste vara aktiv

All förväntad information visas inte automatiskt.

• Log firewall traffic måste vara aktivt i brandväggsreglerna.
• Loggning måste aktiveras i SSL/TLS inspektionsregler.
• Under System services > Log settings måste det definieras vilka loggtyper som skickas lokalt, till Sophos Fusion eller till syslog.

För långtidslagring är en syslog-server eller Sophos Central Firewall Reporting lämpligt. Hur man ansluter externa loggservrar eller ett SIEM beskrivs i Skicka Sophos Firewall-syslog till SIEM. För Sophos Fusion är Aktivera Central Firewall Reporting rätt procedur.

Aktivera debugloggning endast målinriktat

Debugloggning genererar betydligt mer data, tar lagringsutrymme och kan fånga konfidentiellt innehåll. Därför är den inget lämpligt första steg. Fastställ först normal logg, tidsfönster och reproducerbart test; använd debugloggning endast för det berörda undersystemet och bara så länge det behövs.

Sophos dokumenterar två olika metoder. Advanced Shell-formen service <service>:debug -ds nosync växlar status och har inget separat argument on eller off. För ett tjänsteundersystem som stöds bör Sophos dokumenterade, uttryckliga Device Console-kommandon användas: system diagnostics subsystems <subsystem> debug on, reproducera problemet och samla in data och kör sedan system diagnostics subsystems <subsystem> debug off. För Packet Capture-debuggning är undersystemsnamnet till exempel Pktcapd. Debuggning är avstängd som standard, men kontrollera före ändringen att ingen annan administratör eller Sophos Support redan samlar in data. Dokumentera ändringen och verifiera efter insamlingen att debug är avstängd.

Hantera CSC-systemkontrollerns debug som en separat växling

SFOS 22 dokumenterar ett separat Device Console-kommando för systemkontrollern (CSC):

system diagnostics subsystems CSC debug

Till skillnad från syntaxen för tjänsteundersystem ovan har kommandot inget argument on eller off: varje körning växlar CSC-debuggningens status. Använd det som en kontrollerad ändring, inte som en statusfråga:

1. Förkontroll: Bekräfta med andra administratörer och Sophos Support att CSC-debuggning inte redan är aktiv eller ingår i en pågående insamling. Dokumentera brandvägg eller HA-nod, tid, orsak och planerat insamlingsfönster. Spara en referenskopia av den relevanta CSC-loggen före ändringen. Kör inte växlingen enbart för att ta reda på status.
2. Aktivera och reproducera: Kör kommandot exakt en gång i Device Console. Reproducera endast det avgränsade problemet och notera testtiden med tidszon.
3. Bevara bevis: Ladda före rollback ned den relevanta enskilda felsökningsloggen, eller generera CTR och ladda ned den färdigställda CTR-filen. Begränsa åtkomsten till den krypterade CTR-filen och loggarkiv eftersom de kan innehålla konfidentiella data; rensa eller skriv inte över bevis som behövs i ärendet.
4. Inaktivera / rollback: Gå tillbaka till Device Console och kör samma kommando exakt en gång. Denna andra planerade körning stänger av CSC-debuggning igen.
5. Verifiera: Gör ett kort kontrollerat test och bekräfta i de nyskrivna CSC-loggraderna att utdata på debugnivå har upphört och att loggen åter växer i normal takt. Dokumentera tid och resultat för rollback. Om startstatus eller efterkontroll är tvetydig ska växlingen inte köras upprepade gånger; stoppa och samordna status med Sophos Support.

⚠️ WAF-debugloggning och reverseproxy.log: Sophos åtgärdade i SFOS 22.0 MR2 Build 546 felet NC-177457, där ett lösenord var synligt i reverseproxy.log när WAF-debugloggning var aktiverad. Sophos anger varken när den berörda versionsperioden började eller vilken typ av lösenord det var. Redan skapade WAF-debugloggar, felsökningsarkiv och CTR-filer från äldre eller okända builds bör därför behandlas som om de potentiellt innehåller inloggningsuppgifter.

Om en inloggningsuppgift i klartext hittas: begränsa åtkomsten, dokumentera incidenten och byt den berörda inloggningsuppgiften. Ta inte bort loggar urskillningslöst innan kraven för support, forensik och lagring har klarlagts.

Debugloggning och grundläggande CLI-kommandon beskrivs mer utförligt i artikeln CLI-felsökning i Sophos Firewall: viktiga kommandon. För omstart av enskilda tjänster är även Starta om tjänster i Sophos Firewall på ett säkert sätt användbar.

Typiska fel vid sökning i loggar

Många logganalyser tar lång tid, inte för att data saknas utan för att man börjar för tidigt med fel verktyg.

• Aktivera debugloggning direkt: Kontrollera först Log Viewer, lämplig loggfil och ett reproducerbart test.
• Sök endast efter felmeddelanden: Avgränsa även källa, destination, användare, Rule ID, NAT Rule ID och tid.
• Ignorera Packet Capture: Om det är oklart om paket överhuvudtaget anländer eller skickas vidare, använd Packet Capture tidigt.
• Tolka Central Reporting som live-debuggning: Använd Central Reporting för historik och rapporter och lokala loggar för detaljerad analys.
• Spara supportloggar först flera dagar senare: Spara loggar, tid och reproduktionssteg medan händelsen fortfarande går att spåra.
• Lämna debugloggning aktiv efter testet: Inaktivera debugloggningen igen och kontrollera lagringsutrymmet.

Ett bra felsökningsfall innehåller alltid tre delar: ett exakt test, rätt loggkälla och en dokumenterad tidpunkt. Utan denna grund går det att se många loggrader, men inte nödvändigtvis orsaken.

Loggfiler efter funktionsområde

Följande listor är avsedda som en referensguide. Det är bäst att först välja det berörda funktionsområdet och sedan kontrollera lämplig loggfil med ett smalt tidsfönster.

De primära kopplingarna tar hänsyn till SFOS 22.0 och 23.0; OAuth-SSO-filerna skiljer sig mellan dessa versioner enligt uppgifterna nedan. På äldre installationer eller i gamla supportarkiv kan även de tidigare använda namnen app-feedback.log, sig_update.log, sessiontbl.log, webproxy.log, fqdndebug.log, ipsec_Test_Connect.log, redis, hotspot.log, awarrenmta_debug.log, smbnetfs.log, snireport.log, confdbstatus.log och crreportdb.log förekomma. Sophos listar dem inte i de SFOS-22/23-logglistor som ligger till grund för denna artikel; därför bör du inte förutsätta att de finns i en aktuell build.

De allmänna system- och konfigurationsloggarna kontrolleras utöver respektive modul. En fil kan användas av flera funktioner: avgörande är dess betydelse för den aktuella felbilden, inte bara tjänstnamnet.

System, hantering och bastjänster

• Systemstart: sysinit.log; kontrollera denna först vid problem med start och Failsafe.
• Systemmeddelanden på kärnnivå: syslog.log; kontrollera även tid, omstart och gränssnittshändelser. Jämför också system- och administratörsutlösta händelser i Log Viewer.
• Apache-webbserver för WebAdmin och User Portal: apache.log, apache_access.log och error_log.log; kontrollera även Device Access och Local Service ACL.
• Applikationen för WebAdmin och User Portal: webbapplikationsservern Jetty, loggfil tomcat.log; kontrollera även GUI-fel, hög belastning och tjänststatus. Filnamnet är inte namnet på den aktuella webbapplikationsservern.
• SSH: sshd.log; kontrollera även Device Access, källnät och inloggning med publik nyckel.
• GUI-/CLI-fel: error_log.log; kontrollera även den senaste ändringen, webbläsaren och administratörsåtgärden.
• Konfigurationsändringar: applog.log, csc.log; kontrollera även Audit Trail och Config Studio.
• Konfigurationsdatabas: postgres.log; kontrollera även lagringsutrymme, säkerhetskopiering/återställning och supportärendet.
• Kommunikationskanal mellan vissa komponenter och deras tjänster: garner.log; kontrollera även respektive pluginposter vid Central Management och Reporting.
• API: apiparser.log; kontrollera även validation.log, API-ACL, token och Central Task Queue.
• Validering: validation.log, validationError.log; kontrollera även felaktiga objekt eller importer.
• Licensiering: licensing.log; kontrollera även licensstatus, Central Sync och specialfallet Air Gap.
• Systemuppdateringar: u2d.log; kontrollera även mönsterstatus, DNS/HTTPS och lagringsutrymme.

Vid administrationsproblem bör inte bara WebAdmin-loggen kontrolleras. Ofta avgör Device Access, en Local Service ACL Exception Rule eller ett felaktigt källnätverk om WebAdmin, SSH, User Portal, VPN Portal, DNS eller SNMP kan nås. För denna del är Säkra åtkomsten till Sophos Firewall: konfigurera Device Access korrekt den bästa utgångspunkten.

Brandvägg, NAT och Packet Capture

• Matchning av brandväggsregler: firewall_rule.log; kontrollera även modulen Firewall i Log Viewer.
• Anslutningsrelaterade brandväggsloggar: fwlog.log; om de skapas beror på brandväggsregelns loggning och Log settings. Använd även Packet Capture.
• NAT-regler: nat_rule.log; kontrollera även NAT Rule ID i Log Viewer.
• DNAT med Link Load Balancing: kontrollera även dgd.log när val av gateway eller länk är inblandat.
• Packet Capture i WebAdmin: pktcapd.log; kontrollera även Diagnostics > Packet capture.
• Bandbreddshantering / QoS: bwm.log; kontrollera även Traffic Shaping Policy.
• Virtual Host / äldre serverpublicering: vhost.log; kontrollera även NAT och WAF.
• Web Server Protection / WAF: reverseproxy.log; vissa WAF-konfigurationsdetaljer finns även i firewall_rule.log. Kontrollera WAF-regeln, Hosted address och backendens nåbarhet.

NAT handlar inte bara om nat_rule.log: NAT-inställningen för en Site-to-Site-IPsec-anslutning kontrolleras i charon.log, och ett NAT-kommando som körts via CLI i applog.log. På så sätt går det att skilja en tunnelkonfiguration från en vanlig NAT-regel.

Vid DNAT-problem ska brandväggsregeln och NAT-regeln alltid kontrolleras tillsammans. NAT översätter endast adresser; det tillåter inte trafiken. Mer information: Förstå NAT i Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Sophos Firewall använder bland annat IP tables, ARP-tabellen, IPset och conntrack för brandväggsanslutningar. IMQ används för QoS eller bandbreddshantering. Den här informationen är användbar när loggmeddelanden eller supportutdata innehåller tekniska termer från Linux-nätverkssökvägen.

IPS, Application Control och TLS Inspection

• Intrusion Prevention: Tjänst ips, loggfil ips.log.
• Application Control: Tjänst ips / Application Filter, loggfil ips.log.
• DPI och TLS Inspection: DPI Engine, loggfil ips.log.
• Antivirus i nätverkssökvägen: Tjänst avd, loggfil avd.log.
• Zero-Day Protection / Sandbox: Sandbox-tjänst, loggfil sandboxd.log.
• Active Threat Response / X-Ops Threat Feeds: ATR i nätverksvägen; börja med Log Viewer och kontrollera beroende på modul även ips.log.
• MDR Threat Feeds: ATR-/MDR-feedstatus, loggfil atr.log; driftguiden korrelerar Audit ID, Task Queue och lokalt trafikbevis.
• Signaturuppdateringar: Signaturuppdatering, loggfil sig_upgrade.log.
• Signaturmigrering: Signaturmigrering, loggfil sigmigration.log.

appcached.log innehåller även den tillfälliga cachen för kategoriserade applikationer innan de sparas i databasen; dess användning för Application Based Routing anges längre ned. För MDR- och tredjepartsbaserade Threat Feeds visar atr.log licens- och konfigurationsstatus; loggen bevisar inte ensam ett trafikbeslut. För IP-adress-IoC:er kontrolleras även firewall_rule.log. För domän- eller URL-IoC:er behöver brandväggs-, DNS-, SSL/TLS-inspektions- och webbproxyloggar granskas tillsammans: firewall_rule.log, dnsd.log, ips.log, httplogd.log och, beroende på bearbetningsväg, awarrenhttp.log. De berörda modulerna tillämpar Active Threat Response beroende på IoC-typen.

Många moderna skyddsfunktioner kan bara analysera tillräckligt med detaljer när HTTPS-trafiken dekrypteras. Om TLS Inspection inte används ger webbfiltret, Application Control, IPS och skanning efter skadlig kod mindre information, beroende på trafiken.

Om det är oklart om IPS är aktivt, vilken policy som tillämpas eller varför en signatur blockerar, börja med Konfigurera och testa IPS i Sophos Firewall på ett säkert sätt. Därefter kan ips.log, Log Viewer och Packet Capture korreleras mer målinriktat.

Vid problem med programidentifiering, programfiltrering eller oväntade blockeringar i Application Control bör du börja med Konfigurera och testa Application Control i Sophos Firewall.

För Zero-Day Protection bör du även kontrollera om Web Protection, TLS Inspection, filtyp, filstorlek, policy och åtgärd stämmer överens. Den relevanta driftguiden är Förstå och använda Zero-Day Protection i Sophos Firewall. För Threat Feeds finns Konfigurera och använda Threat Feeds säkert i Sophos Firewall. Mer om TLS Inspection: Inför TLS Inspection stegvis i Sophos Firewall.

Webb, proxy, WAF och webbfilter

• HTTP och HTTPS via webbproxyn: tjänst awarrenhttp, loggfil awarrenhttp.log.
• Åtkomst till HTTPS-proxyn: åtkomstlogg för awarrenhttp, loggfil awarrenhttp_access.log. För SFOS 22/23 gäller följande: enskilda webbproxyförfrågningar visas här endast när awarrenhttp körs med debug aktiverat; följ insamlingsförfarandet nedan.
• Webbkategorisering / renommé: tjänst nSXLd, loggfil nSXLd.log.
• Kategoriuppdateringar (SFOS 22/23): loggfil catUpdateLog – observera stora och små bokstäver, utan filändelsen .log.
• FTP via HTTP-proxyn: tjänst skein, loggfil skein.log.
• FTP-proxy: tjänst ftpproxy, loggfil ftpproxy.log.
• Web Application Firewall: omvänd proxy, loggfil reverseproxy.log.

För denna insamling av åtkomstloggen ska du först fastställa berörd brandväggs-/HA-nod, testfall, tid och ett kort insamlingsfönster, kontrollera diskutrymmet och bekräfta med andra administratörer eller supporten att debug är avstängd. Använd inte växlingskommandot för att fråga efter status. Kör sedan service awarrenhttp:debug -ds nosync exakt en gång i Advanced Shell, reproducera det avgränsade problemet och spara awarrenhttp_access.log skyddat. Kör därefter samma kommando exakt en gång för att stänga av debug igen. Kontrollera med ett kort, kontrollerat test att inga nya debugposter skapas och att den vanliga loggen åter växer i normal takt; dokumentera återställningen och kontrollen av diskutrymmet. Om utgångsläget eller efterkontrollen är oklart ska du inte fortsätta växla, utan reda ut det med supporten. Denna metod gäller här för awarrenhttp i SFOS 22/23, inte generellt för alla tjänster eller versioner.

Vid misstänkt proxyloop kan block_proxy_loop tillsammans med kortvarigt aktiverad awarrenhttp-debug ge Duplicate Via header values, proxy loop. Kontrollera HTTP-proxyinställningar säkert beskriver förutsättningen, den globala effekten och säker återställning. Debug är bara aktiv under det reproducerbara testet och stängs sedan av.

Om webbtrafik verkar vara blockerad i Log Viewer kan orsaken ligga i flera moduler: webbpolicy, SSL/TLS inspektion, Application Control, IPS eller WAF. Välj därför alltid den specifika modulen i Log Viewer och kontrollera även lämplig loggfil.

Sophos blockerar alltid webbplatser i kategorin highly objectionable criminal activity och döljer domännamnet i loggar och rapporter. Detta är inte en standardåtgärd som kan väljas fritt. Om en post inom detta område verkar avsiktligt anonymiserad kan det alltså vara avsiktligt.

För webbkategorier, URL-grupper, webbpolicyer och omedelbara varningar finns Använd webbkategorier och omedelbara varningar i Sophos Firewall.

VPN

• IPsec från SFOS v17+: Tjänster strongswan, charon; loggfiler strongswan.log, charon.log.
• Anslutningsspecifik IPsec-logg: enskild IPsec-anslutning, loggfil /log/ipsec_conn/ipsec_<connectionname>.log.
• IPsec i äldre versioner: IPsec-tjänst, loggfil ipsec.log.
• IPsec-övervakning: IPsec Monitor, loggfil ipsec_monitor.log.
• XFRM / ruttbaserad VPN: Tjänst xfrmi, loggfil xfrmi.log.
• SSL VPN: SSL VPN / OpenVPN, loggfil sslvpn.log.
• SSL VPN-status: OpenVPN-status, loggfil openvpn-status*.log.
• VPN Portal: Loggfil vpnportal.log.
• L2TP: Tjänst l2tpd, loggfil l2tpd.log. L2TP-fjärråtkomst på Sophos Firewall beskriver konfiguration och diagnostik.
• PPTP: PPTP VPN, loggfil pptpvpn.log.
• VPN-certifikat: VPN-certifikattjänster, loggfil vpncertificate.log.
• Klientlös SSL VPN: Klientlös åtkomst, loggfil clientless_access.log.

Sophos Firewall använder strongSwan för IPsec VPN och OpenVPN för SSL VPN. Vid IPsec-problem är tid, peer-IP, proposal, lokala och fjärranslutna undernät, NAT-T, routing och brandväggsregler avgörande.

Dessa implementationer gäller för både Site-to-Site och Remote Access. /log/ipsec_conn/ipsec_<connectionname>.log innehåller framför allt de anslutningsspecifika WebAdmin-åtgärderna för att aktivera, inaktivera och ansluta tunneln; <connectionname> ersätts med det faktiska anslutningsnamnet. Vid VPN-användarautentisering ska även access_server.log kontrolleras, och vid portalproblem vpnportal.log. Vid problem med Sophos Connect-klienten ingår även klientens tekniska supportrapport i insamlingen av felsökningsunderlag: enbart brandväggsloggar visar inte klientens fullständiga tillstånd. Felsökningsflödet för IPsec hjälper dig att sammanföra resultaten från klienten och brandväggen.

Vid IPsec-problem är artikeln Felsök IPsec i Sophos Firewall den bästa steg-för-steg-guiden. För ruttbaserad VPN och manuella IPsec-rutter hjälper Skapa en IPsec-rutt i Sophos Firewall.

Autentisering, User Portal och SSO

• Användarautentisering, auktorisering och accounting: Access Server / AAA, loggfil access_server.log.
• NTLM / NASM: tjänst nasm, loggfil nasm.log.
• Chromebook SSO: Chromebook SSO-backend, loggfil chromebook-sso-backend.log.
• Chromebook-SSO-flöde: csd.log; skilj denna från backendloggen.
• OAuth SSO Captive Portal (SFOS 22): loggfil oauth_sso_captive.log.
• OAuth SSO WebAdmin (SFOS 22): loggfil oauth_sso_webadmin.log.
• OAuth SSO VPN (SFOS 22): loggfil oauth_sso_vpn.log.
• OAuth SSO (SFOS 23): oauth_sso_svc.log för SSO-inloggningar till WebAdmin, Captive Portal, VPN Portal, IPsec VPN och SSL VPN.
• RADIUS SSO: koppling mellan användare och IP-adress via accounting i access_server.log. Konfiguration och verifiering förklaras i RADIUS SSO med accounting.
• STAS: STAS-/Access Server-kontext, beroende på tjänstkontext samt access_server.log.

För användarregler ska man alltid först kontrollera om användaren är känd. Om Match known users är aktivt och autentiseringen inte fungerar kommer regeln inte att matcha. För klassiska webbläsarinloggningar kombinerar Konfigurera och testa Sophos Firewall Captive Portal Device Access, användarregeln, Live users, Log Viewer och access_server.log till en fullständig kontrollprocess.

Om det fortfarande är oklart om tjänstevalet, identiteten, Main Group, kvoten eller först den efterföljande trafikvägen misslyckas samlar Felsök autentiseringsfel på Sophos Firewall systematiskt dessa lager i ett gemensamt diagnostikflöde.

När Captive Portal används med Microsoft Entra ID SSO hjälper Konfigurera Microsoft Entra ID SSO för Captive Portal i Sophos Firewall till att kontrollera oauth_sso_captive.log (SFOS 22; i SFOS 23: oauth_sso_svc.log), Device Access, grupper och den efterföljande regelmatchningen.

DNS, DHCP och nätverk

• DNS-tjänst: tjänst dnsd, loggfil dnsd.log.
• Wildcard-FQDN-tjänst / DNS Grabber: tjänst dnsgrabber, loggfil dnsgrabber.log.
• DNS Entity / övriga DNS-komponenter: tjänster entity, eacd; loggfiler entity.log, eacd.log.
• DHCP IPv4: tjänst dhcpd, loggfil dhcpd.log.
• DHCP IPv6: loggfil dhcpd6.log.
• Fysiska och virtuella gränssnitt: tjänst networkd, loggfil networkd.log.
• FQDN-värdar: tjänst fqdnd, loggfil fqdnd.log.
• Dead Gateway Detection och WAN-/gatewayhantering: tjänst dgd, loggfil dgd.log; kontrollera även länkfailover, VPN-failover och DNAT.
• Dynamisk DNS: Dynamic DNS-klient, loggfil ddc.log.
• NTP-klient: loggfil ntpclient.log.
• IPv6 Router Advertisement: tjänst radvd, loggfil radvd.log.

DNS- och DHCP-problem ser ofta ut som brandväggsproblem. Kontrollera därför först IP-adressen, gatewayen, DNS-servern och om klienterna ska använda brandväggen som DNS- eller DHCP-server.

Om interna domäner inte löses korrekt är Konfigurera DNS Request Routes i Sophos Firewall vanligtvis relevant. För särskilda DHCP-alternativ finns den separata artikeln Konfigurera DHCP-alternativ i Sophos Firewall.

Mobil WAN

• WWAN / USB-modem: Kontrollera anslutning och borttagning av USB-enheter i modemd.log.
• Modemnätverkskonfiguration: Kontrollera modemrelaterade gränssnitt och IP-konfiguration i networkd.log.
• USB, modem och PPP: Kontrollera syslogmeddelanden för USB, modem och Point-to-Point-protokoll i syslog.log.

Vid problem med mobilt WAN bör du även kontrollera om modemet identifieras, om PIN/SIM/APN är korrekta och om brandväggen skapar en lämplig gateway.

Routing

• Statiska unicast-rutter: loggfil staticd.log. Konfiguration och kontroll förklaras i Konfigurera en statisk rutt på Sophos Firewall.
• Installation av statiska IPv4-unicast-rutter: tjänst zebra, loggfil zebra.log.
• Applikationsbaserad routning: tjänst appcached, loggfil appcached.log.
• Multicastroutning: loggfil mrouting.log.
• BGP och BGP-IPv6: tjänst bgpd, loggfil bgpd.log. Konfiguration och verifiering förklaras i Konfigurera BGP på Sophos Firewall; zebra.log hjälper även till att kontrollera om en inlärd dynamisk IPv4- eller IPv6-rutt har installerats i kärnan.
• OSPFv2 och OSPFv3: tjänster ospfd och ospf6d, loggfiler ospfd.log och ospf6d.log. zebra.log visar även om den dynamiska rutten har införts i systemet. Konfiguration och verifiering förklaras i Konfigurera OSPF på Sophos Firewall.
• RIP: tjänst ripd, loggfil ripd.log. Konfiguration och verifiering förklaras i Konfigurera RIPv2 på Sophos Firewall; zebra.log visar även om en inlärd rutt har installerats i routningsstacken.
• PIM-SM: tjänst pimd, loggfil pimd.log. Konfiguration och verifiering förklaras i Konfigurera PIM-SM på Sophos Firewall.

Vid routingproblem ska även Routing > SD-WAN routes, gateways och Packet Capture kontrolleras. Policytestaren ersätter inte ett verkligt routingtest.

För statiska och dynamiska rutter ger csc.log även opcode-information och uppgifter om tjänsteomstarter. I HA-sammanhang kompletterar du med ha.log, msync.log och applog.log. För SD-WAN-rutter kontrollerar du utöver appcached.log även applog.log, csc.log och dgd.log; om IPsec är inblandat används även IPsec-loggarna.

Mer information: Justera routingprioriteten på Sophos Firewall.

GUI, CLI och systemåtkomst

För WebAdmin, SSH, API och lokala administrationstjänster finns grundlistan ovan under System, hantering och bastjänster. Om WebAdmin eller SSH inte är tillgängliga ska inte bara apache.log, tomcat.log eller sshd.log kontrolleras. Lokal åtkomst styrs via Administration > Device access och Local Service ACL.

Mer information: Anslut till Sophos Firewall via SSH.

Sophos Fusion, Security Heartbeat och central hantering

• Sophos Central Management: Central Management, loggfiler centralmanagement.log, sophos-central.log.
• CSC och hjälptjänster: tjänster csc, cschelper, csd; loggfiler csc.log, cschelper.log, csd.log. cschelper.log gäller systemgenererade e-postmeddelanden och autentiseringsverktyg, csd.log Chromebook-SSO-flödet.
• Security Heartbeat och Synchronized Security: heartbeatd.log innehåller endpointstatus och applikationsinformation som skickats till brandväggen; hbtrust.log innehåller kommunikationen med Central. Tjänsterna heter heartbeatd och hbtrust; kontrollera även csc.log och applog.log.
• Synchronized Application Control: kontrollera data till SophosLabs i sac-feedback.log.
• Optimering av SAC-databasen (SFOS 22/23): sac-vacuum.log loggar den veckovisa optimeringen av Synchronized Application Control-databasen; sac-feedback.log är fortsatt den separata loggen för data till SophosLabs.
• Central-händelser, anslutning och konfigurationsöverföring: fwcm-eventd.log visar skickad zon-/gränssnittsinformation för dynamiska objekt, fwcm-heartbeatd.log anslutningen och fwcm-updaterd.log överförd konfiguration. Tjänsterna heter fwcm-eventd, fwcm-heartbeatd och fwcm-updaterd; alla tre är inte Heartbeat-tjänster.
• Central API Executor: tjänst fwcm-api-executor, loggfil fwcm-api-executor.log.
• Active Threat Response: ATR-kontext; kontrollera utifrån version och modul.

Vid problem med Sophos Fusion ska du först kontrollera om brandväggen är registrerad, om Central-tjänsterna är aktiva och om utgående DNS/HTTPS fungerar. Om en ändring från Sophos Fusion inte når brandväggen bör brandväggens uppgiftskö i Sophos Fusion jämföras med de lokala loggarna. Grön status i Sophos Fusion bevisar inte i sig att en viss policy har bearbetats lokalt.

För registrering och åtkomsttoken är sophos-central.log relevant, och för aktiverad hantering och rapportering centralmanagement.log. Registrering och avregistrering stäms även av mot applog.log, och firmwareuppgraderingar mot csc.log. hbtrust.log visar kommunikationen; i garner.log hör SCM-pluginposter till Central Management och CR-pluginposter till Central Reporting. fwcm-api-executor.log innehåller även MDR-analyser som överförts till brandväggen. I SFOS 22 kallas plattformen Sophos Fusion (tidigare Sophos Central), medan SFOS 23 använder Sophos Central; befintliga tjänst- och filnamn förblir oförändrade.

Hög tillgänglighet

• HA-status och konfiguration: HA-applikationslogg, loggfil applog.log.
• Identifiering av HA-peer i QuickHA: tjänst ha_pair, loggfil ha_pair.log.
• SSH-tunnel mellan HA-enheter via den dedikerade länken: tjänst ha_tunnel, loggfil ha_tunnel.log.
• Conntrack-synkronisering: tjänst ctsyncd, loggfil ctsyncd.log.
• Msync: tjänst msync, loggfil msync.log.
• Etablering av HA och statusändringar: ha.log.
• Filsynkronisering av utvalda tjänster till Auxiliary-enheten: filesync.log.

HA-loggar och rapporter synkroniseras inte mellan enheterna. Varje nod lagrar endast data för trafik som den själv har bearbetat. Kontrollera därför Log Viewer och Diagnostics > Tools > Troubleshooting logs på varje berörd enhet. För att hämta felsökningsloggar från Auxiliary-enheten loggar du in direkt i dess CLI via IP-adressen eller FQDN för administrationsgränssnittet. Sophos Central Firewall Reporting kan kombinera rapporter från båda enheterna, men ersätter inte nodlokala felsökningsfiler.

Mail och anti-spam

• Antivirus: AV-tjänst, loggfil avd.log.
• Antivirusuppdateringar: Up2Date AV, loggfil up2date_av.log.
• Antispam: tjänst sasi, loggfil sasi.log.
• Sandbox: tjänst sandboxd, loggfil sandboxd.log.
• SMTP MTA: tjänst smtpd, loggfil smtpd_main.log.
• SMTP-fel i MTA-läge: smtpd_error.log för fel vid e-postskanning, smtpd_panic.log för interna fel och smtpd_reject.log för avvisade e-postmeddelanden; tjänsten är smtpd.
• Äldre SMTP/S-proxy: tjänster awarrensmtp, awarrenmta; loggfiler awarrensmtp.log, awarrenmta.log. Konfiguration och end-to-end-test förklaras i Mail Protection i Legacy Mode.
• POP-/IMAP-proxy: tjänst warren, loggfil warren.log. Konfiguration och end-to-end-test förklaras i Skanna POP3 och IMAP på Sophos Firewall.

Vid e-postproblem ska du alltid kontrollera att MTA-läge, brandväggsregel, DNS, certifikat och leverantörsbegränsningar fungerar tillsammans. Förfarandet för meddelandeflöde, spool, karantän och relä beskrivs i Konfigurera Mail Protection i MTA-läge i Sophos Firewall.

Sophos Firewall använder Avira och Sophos Antivirus. Anti-spam-tjänsten startar endast om en policy för inkommande eller utgående spam finns. Detta beroende är viktigt om sasi.log förblir tom eller anti-spam-tjänsten inte körs.

Trådlöst, RED, hotspot och andra tjänster

• Wireless Controller och AP-/APX-kommunikation med brandväggen: tjänst awed, loggfil awed.log.
• Trådlösa klienter: kommunikation mellan klient och AP/APX i wc_remote.log.
• LocalWifi-SSID: tjänst hostapd, loggfil hostapd.log; förväxla inte denna med hotspot-händelser.
• Hotspot-händelser: tjänst hotspotd, loggfil hotspotd.log.
• RED: red.log registrerar alla konfigurerade RED-enheter, inklusive Site-to-Site RED och SD-RED. red-<serial ID of RED>.log hör till respektive SD-RED-enhet, och red-<RED ID>.log till respektive Site-to-Site-RED-konfiguration. Du hittar RED ID under Network > Interfaces genom att öppna den aktuella Site-to-Site RED. Platshållarna ersätts med dess faktiska serienummer respektive RED ID.
• SNMP: tjänst snmpd, loggfil snmpd.log.
• Syslog-tjänst: loggfil syslog.log.
• Licensiering: licensieringstjänst, loggfil licensing.log.
• Systemuppdateringar: tjänst u2d, loggfil u2d.log.
• VMware Tools: tjänst vmtool, loggfil vmtool.log.

Vid problem med licensiering, Air-Gap eller mönster är licensing.log och u2d.log de första tekniska utgångspunkterna. Den operativa processen med licensfil, 180-dagarsfönster och manuella mönsteruppdateringar beskrivs i Hantera Air-Gap-licensiering och mönsteruppdateringar i Sophos Firewall.

Databas och rapportering

• Konfigurationsdatabas: Config DB, loggfil postgres.log.
• Postgres: tjänst postgres, loggfil postgres.log.
• Signaturdatabas: tjänst sigdb, loggfil sigdb.log.
• Rapportdatabas: ny rapportdatabas från SFOS 21.0, loggfil reportdb.log.
• Migreringsdatabas: rapportmigrering, loggfil reportmigration.log.
• Konfigurationsmigrering (SFOS 22/23): loggfil migration.log; förväxla inte denna med reportmigration.log för rapportmigrering.
• Garner: tjänst garner, loggfil garner.log.
• Loggvisualisering i WebAdmin: tjänst iview, loggfil iview.log.

Om rapporter saknas eller är långsamma, eller om det finns problem med lagringsutrymmet, är rapport- och databasloggarna relevanta. Kontrollera även om rapporterna lagras lokalt eller skickas till Sophos Fusion.

Ytterligare loggfiler för SFOS 22/23

Följande filer behövs mer sällan vid den dagliga trafikfelsökningen, men ingår i kopplingarna för SFOS 22/23. De grupperas efter funktion så att ett filnamn inte för snabbt leder till en slutsats om orsaken:

• Granskning, FIPS och supportåtkomst: configuration-audit.log loggar konfigurationsändring, administratör och tidpunkt; fips.log start i FIPS-läge; uma.log Support Access.
• Loggpipeline och lokalt dataunderhåll: syslog-ng.log visar undertryckning av på varandra följande poster för samma händelse; reportdb_v9.log hör till den gamla rapportdatabasen. dbcleanup.log gäller databasrensning vid omstart av brandväggen, readobject.log intern objektläsning, fstrim.log trimning av filsystemet och logrotate.log rotation till .gz-filer.
• ATR, NDR Essentials och FastPath: atr-service.log visar start och stopp av ATR-tjänsten. ndr.log omfattar NDR-licens, konfiguration och agentstart; ndr_agent.log tjänststart och metadatabearbetning. vfpdf.log visar metadata som FastPath skickar till NDR Essentials, endast på XGS 88/88w, 108/108w, 118/118w och 128/128w. setup_vf_dpdk.log loggar FastPath-minnesinitieringen och gäller uttryckligen inte dessa fyra modellserier.
• TLS och SSL VPN: httplogd.log visar icke-dekrypterade HTTPS-anslutningar i DPI-vägen. peruser_cert_sslvpn.log loggar användarspecifikt genererade SSL-VPN-certifikat; openvpn-status0.log, openvpn-status1.log och ytterligare numrerade filer visar aktiva SSL-VPN-anslutningar per process.
• Nätverk och HA: dhcprelay.log hör till DHCP Relay. ha.log visar om etableringen av HA lyckats eller misslyckats samt statusändringar; filesync.log visar filsynkroniseringen av utvalda tjänster till Auxiliary-enheten.
• Central, driftsättning och ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log och fwcm-updaterd.log omfattar zon-/gränssnittsinformation, anslutning och konfigurationsöverföring. fwcm-frpcd.log gäller Fast Reverse Proxy när flera brandväggar öppnas samtidigt i Central. ssod.log innehåller firmwareuppgraderingsinformation som skickats till Central samt brandväggssäkerhetskopior som skapats där. För True/Controlled Zero Touch kontrollerar du zt.log och fwcm-heartbeatd.log; för Zero Touch via USB zerotouch.log, inte fwcm-heartbeatd.log. ztna-connector.log innehåller kundkonto-/connector-ID:n, connectorstatus, ZTNA-tunnlar, anropade applikationer och konfigurationsuppdateringar.
• Säkerhetskopiering, firmware, Air Gap och certifikat: interfacemapping.log loggar gränssnittsmappningen vid återställning, legacyconversion.log säkerhetskopior utan Secure Storage Master Key och fwmgmt.log installation och hantering av firmware. u2d_airgap.log gäller Air-Gap-uppdateringar, cps_messages.log hotfixfel och letsencrypt.log tillsammans med applog.log Let’s Encrypt-certifikat.
• API, återställning och certifikathantering: apiparser.log gäller API-översättningen mellan JSON och XML, validation.log och validationError.log API-valideringen. För säkerhetskopiering/återställning ska även applog.log och postgres.log kontrolleras. vpncertificate.log omfattar inte bara VPN-certifikat utan även CA:er, CSR:er och CRL:er.
• Hårdvara och systemtillstånd: npu-startup.log visar NPU-start, npu_syslog.log NPU-sysloggar och xgs-host.log värddrivrutiner vid start. xgs-npu-fw.log gäller NPU-kompatibilitetskontroll, uppgradering och återställning, xgs-npu-serial.log NPU-serieporten och xgs-pport-wait.log skapandet av fysiska gränssnitt vid start. xgs-healthmond.log omfattar CPU-belastning, temperatur, fläkthastighet och NPU-hanteringsport. raid.log visar mjukvaru-RAID och lcd.log hårdvarudisplayen. På hårdvarubaserade, virtuella, molnbaserade och mjukvarubaserade brandväggar registrerar system-monitor/cpu_trigger.log respektive system-monitor/memory_trigger.log systemtillståndet vid hög CPU- respektive minnesbelastning; båda listas för SFOS 22/23.
• FastPath-sysloggar: npu_syslog.log gäller NPU-baserad FastPath och gäller inte XGS 88/88w, 108/108w, 118/118w och 128/128w. syslog.log visar värdkommunikation med NPU-baserad FastPath samt Virtual FastPath. För VMware ska du utöver VMware Tools-loggen vmtool.log även kontrollera syslog.log.
• Moln- och plattformstjänster: iaasd.log loggar konfigurationsprovisionering och licenskontroll i Azure, waagent.log provisionering på operativsystemnivå och hälsoövervakning genom Azure-provisioneringsagenten; vmtool.log hör till VMware Tools.

Att en fil finns bevisar inte ett fel i den modulen. Korrelera först händelsetid, berörd nod, plattform, tjänststatus och ett reproducerbart symptom; sök först därefter med ett snävt filter i rätt fil.

Analysflöde

1. Skriv ner problemet exakt: tid med tidszon, klient, destination, port, användare, åtgärd.
2. Bestäm om det handlar om trafik, tjänststatus, konfigurationsändring eller central synkronisering.
3. Filtrera i Log Viewer efter käll-IP, destinations-IP, modul och tid.
4. Kontrollera att brandväggens Rule ID, NAT Rule ID, användare, gateway och policy-ID visas.
5. Använd Packet Capture om paketflöde, returväg eller NAT-vy är otydlig.
6. Kontrollera lämplig loggfil med tail -f, less eller grep.
7. Återskapa problemet och dokumentera den exakta testtiden.
8. Aktivera vid behov debugloggning endast för den berörda tjänsten och under en kort tid.
9. Inaktivera debugloggningen igen och kontrollera lagringsutrymmet.
10. Spara loggarna medan reproduktionen av felet fortfarande är aktuell.

För supportärenden bör du även dokumentera alla felmeddelanden, reproduktionssteg och redan utförda felsökningssteg. Det är just dessa uppgifter som avsevärt påskyndar hanteringen. Lämpligt förfarande finns i Öppna ett Sophos-supportärende: förberedelse och portal.

FAQ