Hoppa till innehållet
Avanet

Tilldela tjänstloggar korrekt i Sophos Firewall

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:

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.

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 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 följer den aktuella dokumentationen för SFOS 22.0. På äldre installationer eller i äldre 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 tar inte längre upp dem i den aktuella logglistan för SFOS 22.0, så man bör inte förutsätta att de finns i en aktuell build.

System, hantering och bastjänster

  • Systemstart: sysinit.log; kontrollera först vid start- och Failsafe-problem.
  • Systemmeddelanden: syslog.log; kontrollera även tid, omstarter och gränssnittshändelser.
  • WebAdmin-webbserver: apache.log, apache_access.log; kontrollera även Device Access och Local Service ACL.
  • WebAdmin-applikation: tomcat.log; kontrollera dessutom GUI-fel, hög belastning och tjänstestatus.
  • SSH: sshd.log; kontrollera även Device Access, källnätverket och autentisering med offentlig nyckel.
  • GUI-/CLI-fel: error_log.log; kontrollera även aktuella ändringar samt åtgärder i webbläsaren och av administratören.
  • Konfigurationsändringar: applog.log, csc.log; kontrollera även Audit Trail och Config Studio.
  • Konfigurationsdatabas: postgres.log; kontrollera även lagringsutrymme, säkerhetskopiering/återställning och uppgifterna i supportärendet.
  • Kommunikationskanal mellan vissa komponenter och deras tjänster: garner.log; för Central Management och rapportering ska även motsvarande pluginposter kontrolleras.
  • API: apiparser.log; kontrollera även validation.log, API-ACL, API-token och den centrala uppgiftskön.
  • Validering: validation.log, validationError.log; kontrollera dessutom 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

  • Brandväggsregelmatchning: firewall_rule.log; kontrollera även modulen Firewall i Log Viewer.
  • Allmän brandväggsbearbetning: fwlog.log; 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 om gateway- eller länkvalet berörs.
  • Packet Capture i WebAdmin: pktcapd.log; kontrollera även Diagnostics > Packet capture.
  • Bandbreddshantering/QoS: bwm.log; kontrollera även Traffic Shaping Policy.
  • Virtuell värd / äldre serverpublikation: vhost.log; kontrollera dessutom NAT och WAF.
  • Webbserverskydd/WAF: reverseproxy.log; kontrollera även WAF-regeln, Hosted address och backend-serverns tillgänglighet.

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

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

  • HTTPS-proxy: Tjänst awarrenhttp, loggfil awarrenhttp.log.
  • HTTPS-proxyåtkomst: åtkomstlogg för awarrenhttp, loggfil awarrenhttp_access.log. I SFOS 22/23 visas enskilda webbproxyförfrågningar här bara när awarrenhttp körs med debug aktiverad; följ insamlingsförfarandet nedan.
  • Webbkategorisering/rykte: Tjänst nSXLd, loggfil nSXLd.log.
  • Kategoriuppdateringar (SFOS 22/23): loggfil catUpdateLog – behåll exakt skiftläge, utan ändelsen .log.
  • Äldre HTTP/FTP-proxy: Tjänst skein, loggfil skein.log.
  • FTP-proxy: Tjänst ftpproxy, loggfil ftpproxy.log.
  • Webbapplikationsbrandvägg: 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 som standard webbplatser i kategorin highly objectionable criminal activity och döljer domännamnet i loggar och rapporter. Om en post inom detta område verkar vara avsiktligt anonymiserad kan det därför vara helt 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.

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: 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.
  • 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: Användar-IP-koppling via accounting i access_server.log. RADIUS SSO med accounting förklarar konfiguration och validering.
  • STAS: STAS / Access Server-kontext, beroende på tjänstkontext och 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.
  • DNS Grabber: Tjänst dnsgrabber, loggfil dnsgrabber.log.
  • DNS-entitet/andra DNS-komponenter: Tjänster entity, eacd; loggfiler entity.log, eacd.log.
  • DHCP IPv4: Tjänst dhcpd, loggfil dhcpd.log.
  • DHCP IPv6: Loggfil dhcpd6.log.
  • Nätverkstjänst: Tjänst networkd, loggfil networkd.log.
  • FQDN-värdar: Tjänst fqdnd, loggfil fqdnd.log.
  • Dead Gateway Detection: Tjänst dgd, loggfil dgd.log.
  • Dynamisk DNS: Dynamisk 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

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

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: Tjänster csc, cschelper, csd; loggfiler csc.log, cschelper.log, csd.log.
  • Security Heartbeat: Tjänster heartbeatd, hbtrust; loggfiler heartbeatd.log, hbtrust.log.
  • Synchronized Application Control: Kontrollera data som skickas till SophosLabs i sac-feedback.log.
  • Optimering av SAC-databasen (SFOS 22/23): sac-vacuum.log registrerar den veckovisa optimeringen av databasen för Synchronized Application Control; sac-feedback.log är fortsatt den separata loggen för data som skickas till SophosLabs.
  • Heartbeat till Central: Tjänster fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; kontrollera respektive tjänsteloggar.
  • Central API-exekverare: 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.

Hög tillgänglighet

  • HA-status och konfiguration: HA-applikationslogg, loggfil applog.log.
  • HA-partjänst: Tjänst ha_pair, loggfil ha_pair.log.
  • HA-tunnel: Tjänst ha_tunnel, loggfil ha_tunnel.log.
  • Conntrack Sync: Tjänst ctsyncd, loggfil ctsyncd.log.
  • Msync: Tjänst msync, loggfil msync.log.
  • HA-etablering och statusändringar: ha.log.
  • Filsynkronisering för 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.
  • Anti-Spam: Tjänst sasi, loggfil sasi.log.
  • Sandbox: Tjänst sandboxd, loggfil sandboxd.log.
  • SMTP MTA: Tjänst smtpd, loggfil smtpd_main.log.
  • SMTP-fel: smtpd-fel/panik/avvisning, loggfiler smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
  • Äldre SMTP/S-proxy: Tjänster awarrensmtp, awarrenmta; loggfiler awarrensmtp.log, awarrenmta.log. Mail Protection i Legacy mode förklarar konfiguration och end-to-end-test.
  • POP/IMAP-proxy: Tjänst warren, loggfil warren.log. Skanna POP3 och IMAP på Sophos Firewall förklarar konfiguration och end-to-end-test.

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

  • Trådlös styrenhet: Tjänst awed, loggfil awed.log.
  • Trådlösa klienter: Kontrollera kommunikationen mellan klienten och AP/APX i wc_remote.log.
  • Hotspot: Tjänster hostapd, hotspotd; loggfiler hostapd.log, hotspotd.log.
  • RED: RED-tjänst, loggfil red.log. Beroende på RED-typ och instans kan även red-<serial ID of RED>.log och red-<RED ID>.log förekomma.
  • SNMP: Tjänst snmpd, loggfil snmpd.log.
  • Syslog-tjänst: Loggfil syslog.log.
  • Licensiering: Licenstjänst, loggfil licensing.log.
  • Systemuppdateringar: Tjänst u2d, loggfil u2d.log.
  • VMware-verktyg: 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: Rapport DB, loggfil reportdb.log.
  • Migreringsdatabas: Rapportmigrering, loggfil reportmigration.log.
  • Konfigurationsmigrering (SFOS 22/23): loggfil migration.log; förväxla den inte med reportmigration.log för rapportmigrering.
  • Garner: Tjänst garner, loggfil garner.log.
  • iView: 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.

Andra aktuella SFOS 22-loggfiler

Följande filer behövs mer sällan i den dagliga trafikfelsökningen, men ingår i den aktuella SFOS 22-mappningen. De är grupperade efter funktion så att en orsak inte dras för snabbt enbart från ett filnamn:

  • Audit, FIPS och supportåtkomst: configuration-audit.log registrerar konfigurationsändringen, administratören och tiden; fips.log starten i FIPS-läge; uma.log Support Access.
  • Loggpipeline och lokalt dataunderhåll: syslog-ng.log visar undertryckning av efterföljande händelser; reportdb_v9.log tillhör den gamla rapportdatabasen. dbcleanup.log, readobject.log, fstrim.log och logrotate.log gäller databasrensning, intern objektläsning, trimning av filsystemet och loggrotation.
  • ATR, NDR och FastPath: atr-service.log visar start och stopp av ATR-tjänsten. ndr.log och ndr_agent.log omfattar NDR-licens, konfiguration, agentstart och metadatabearbetning; vfpdf.log gäller NDR-metadata på XGS 88/88w, 108/108w, 118/118w och 128/128w. setup_vf_dpdk.log registrerar FastPath-minnesinitiering och gäller inte just dessa fyra modellserier.
  • TLS och SSL VPN: httplogd.log visar HTTPS-anslutningar som inte dekrypterats i DPI-flödet. peruser_cert_sslvpn.log registrerar SSL VPN-certifikat som skapats per användare; openvpn-status0.log, openvpn-status1.log och andra numrerade filer visar aktiva SSL VPN-anslutningar per process.
  • Nätverk och HA: dhcprelay.log hör till DHCP Relay. ha.log visar lyckad eller misslyckad HA-etablering och statusändringar; filesync.log filsynkronisering för valda tjänster till Auxiliary-enheten.
  • Central, driftsättning och ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log, fwcm-updaterd.log och fwcm-frpcd.log omfattar zon- och gränssnittsinformation som skickas till Central, anslutningen, överförd konfiguration och Fast Reverse Proxy. ssod.log innehåller information om firmware och Central-säkerhetskopior, zt.log och zerotouch.log Zero Touch-varianter, ztna-connector.log den lokala ZTNA Connector.
  • Säkerhetskopiering, firmware, Air Gap och certifikat: interfacemapping.log registrerar gränssnittsmappning 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.
  • Maskinvara och systemstatus: npu-startup.log, npu_syslog.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-npu-serial.log och xgs-pport-wait.log omfattar NPU-start, -kommunikation, -firmware, serieport, hälsa och skapande av fysiska gränssnitt. raid.log visar programvaru-RAID, lcd.log hårdvarudisplayen. system-monitor/cpu_trigger.log registrerar systemstatus vid hög CPU-belastning; system-monitor/memory_trigger.log gäller i SFOS 22 vid hög minnesbelastning.
  • Moln- och plattformstjänster: iaasd.log registrerar provisionering och licenskontroll i Azure, waagent.log Azure-agenten och dess Health Monitoring; 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

Vilken loggfil är viktigast för Sophos Firewall?

Det beror på problemet. För brandväggsregler är firewall_rule.log viktig, för NAT nat_rule.log, för IPsec strongswan.log, för SSL VPN sslvpn.log och för IPS och Application Control ofta ips.log. Log Viewer är fortfarande den bästa utgångspunkten för enskilda anslutningar.

Vad är CTR i Sophos Firewall-loggar?

I många Sophos-sammanhang står CTR för Consolidated Troubleshooting Report. Det viktiga för administratörer är att en CTR eller ett felsökningsloggpaket hjälper supporten, men inte ersätter en tydlig felbeskrivning med tid, berörda IP-adresser, användare, tunnelnamn, regel-ID och reproduktionssteg.

När behövs Advanced Shell?

Advanced Shell behövs när lokala loggfiler måste kontrolleras med tail, grep eller less, en tjänsts status ska kontrolleras eller Sophos Support behöver detaljerade loggdata. För många inledande tester räcker Log Viewer, Policy Test och Packet Capture i WebAdmin.

Ska debugloggning lämnas permanent aktiverad?

Nej. Debugloggning genererar stora datamängder och kan ta upp lagringsutrymme. Den ska endast användas för den berörda tjänsten under ett kort, reproducerbart test och sedan inaktiveras.

Varför visas inte de förväntade brandväggshändelserna i Log Viewer?

Ofta är Log firewall traffic inte aktivt i den berörda regeln, fel tidsperiod eller filter har valts eller så når inte trafiken brandväggen. Om paketflödet är oklart bör man använda Log Viewer och Packet Capture tillsammans.

Är lokala loggar bättre än Central Reporting eller syslog?

Det är olika verktyg. Lokala loggar hjälper vid detaljerad analys direkt på brandväggen. Central Reporting lämpar sig för rapporter och historik i Sophos Fusion. Syslog passar bättre för ett eget SIEM eller SOC samt för långtidslagring.