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 Central-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 på brandväggen och kan nås via WebAdmin-konsolen eller SSH. För korta kontroller fungerar Device Management > Advanced Shell i webbläsaren, men i praktiken är SSH vanligtvis smidigare, stabilare och bättre lämpat för längre sessioner med tail, grep eller less. Säker förberedelse av SSH beskrivs i guiden 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. Anslut via SSH eller öppna Device Management > Advanced Shell i konsolen WebAdmin.
  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.
  • Styr en tjänst eller aktivera debugloggning: service <service>:<start/restart/stop/debug> -ds nosync, till exempel service ips:debug -ds nosync. start, restart och stop påverkar driften och ska användas i ett underhållsfönster eller enligt supportens anvisningar.

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 skapas manuellt med tar i Advanced Shell. För supportärenden finns även Diagnostics > Tools > Log file details eller valet av felsökningsloggar i WebAdmin. Där går det att välja och ladda ned loggfiler per modul.

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 om en administratör inte vill öppna en lång skalsession eller om det endast behövs ett tydligt avgränsat loggpaket. CTR passar bättre när Sophos Support behöver en bred ögonblicksbild av systemet. När en CTR skapas ska orsaken anges kort och begripligt, till exempel ärendenummer, tidsperiod eller felmönster. Rapporten laddas ned krypterad och innehåller som standard endast ett begränsat antal rader från tjänsteundersystemens loggar. Kompletta enskilda loggfiler hämtas tillförlitligare via Troubleshooting logs eller direkt från /log.

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.

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, tail, grep, less, service -S, omstart av tjänster och debugkommandon.

Alla kommandon fungerar inte i båda områdena. Om en artikel uttryckligen nämner Device Console ska kommandot köras där. När det gäller /log, tail -f, grep, service -S eller debugloggning avses vanligtvis Advanced Shell.

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 Central 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 Central är Aktivera Central Firewall Reporting rätt procedur.

Aktivera debugloggning endast målinriktat

Debugloggning är mycket användbar, men genererar stora datamängder och kan ta upp lagringsutrymme. Den bör endast aktiveras för den relevanta tjänsten. Reproducera sedan problemet och inaktivera debugloggningen igen. Debugloggar kan innehålla inloggningsuppgifter och annat konfidentiellt innehåll. Innan de laddas ned eller delas måste de granskas och överföras på ett säkert sätt.

IPS-exempel för Advanced Shell:

service ips:debug -ds nosync

Kommandot växlar tjänstens debugstatus och körs igen efter insamlingen för att inaktivera debugloggningen. Ett tillagt off är inte dokumenterat för detta Advanced Shell-kommando. Den exakta syntaxen beror på tjänsten. Om det är oklart vilken tjänst som berörs bör den motsvarande vanliga loggfilen kontrolleras först.

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

Sophos skiljer mellan två arbetssätt. Tjänstekommandon som service ips:debug -ds nosync används i Advanced Shell. I Device Console finns även kommandona system diagnostics subsystems <subsystem> debug on och system diagnostics subsystems <subsystem> debug off för undersystem som stöds. Dessa varianter ska inte blandas: fastställ först vilken konsol du arbetar i och använd sedan rätt kommando.

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.
  • Webbkategorisering/rykte: Tjänst nSXLd, loggfil nSXLd.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.

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.
  • 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: Loggfil oauth_sso_captive.log.
  • OAuth SSO WebAdmin: Loggfil oauth_sso_webadmin.log.
  • OAuth SSO VPN: Loggfil oauth_sso_vpn.log.
  • 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, 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-routerannons: 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 Central, Security Heartbeat och central hantering

  • Sophos Central-hantering: 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.
  • 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 Central 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 Central inte når brandväggen bör Sophos Central Firewall Management Task Queue jämföras med de lokala loggarna. Grön status i Central 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-loggar finns på den enhet där de skapades. För råloggar från Auxiliary måste du ansluta direkt till den enheten, till exempel via dess administrationsport med SSH. För konsoliderade rapporter är Sophos Central Firewall Reporting mer praktiskt.

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.
  • POP/IMAP-proxy: Tjänst warren, loggfil warren.log.

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.
  • Wi-Fi-autentisering: Tjänst wifiauth, loggfil wifiauth.log.
  • Hotspot: Tjänster hostapd, hotspotd; loggfiler hostapd.log, hotspotd.log.
  • RED: RED-tjänst, loggfil red.log.
  • 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.
  • 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 Central.

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 Central. Syslog passar bättre för ett eget SIEM eller SOC samt för långtidslagring.