Hoppa till innehållet
Avanet

Sophos Firewall Service Logs: rätt loggfil

Sophos Firewall har tre viktiga nivåer för felsökning: Event Logs i Log viewer, diagnosverktyg i WebAdmin och tjänst- respektive loggfiler på brandväggen. Log Viewer är idealisk 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, webbfilter oväntat aktiveras eller supporten behöver detaljerade data.

Denna artikel kategoriserar de viktigaste tjänsterna och loggfilerna efter typiska adminproblem. Den hjälper även när ett tekniskt tjänstnamn dyker upp i instrumentpanelen, i Advanced Shell eller i ett supportärende och det inte omedelbart är klart vilken brandväggsfunktion som ligger bakom. Namn som zebra, warren, awed, garner eller strongswan är inte självförklarande i vardagen.

Val av verktyg och förutsättningar

Vilket felsökningsverktyg passar?

Inte varje brandväggsproblem börjar med en Shell. Ofta är ett annat verktyg snabbare först:

Ordningen är viktig. Log Viewer visar ofta snabbare vilken regel eller vilket modul som fattade beslutet. Packet Capture bevisar paketflödet i WebAdmin. tcpdump är användbart när en längre inspelning, en PCAP-fil eller ett mycket exakt CLI-filter behövs. Tjänstloggar och Debug hjälper när en specifik tjänst själv är problemet eller när data måste samlas in för Sophos Support.

Snabb start efter symptom

Om det inte är klart vilken logg som är relevant hjälper det att starta efter symptom i stället för efter tjänstnamn.

  • En enskild anslutning fungerar inte: Kontrollera först Log Viewer med Source, Destination, Service och tid. Använd därefter Packet Capture, firewall_rule.log och nat_rule.log.
  • VPN-tunnel är down eller instabil: Kontrollera VPN-status, Peer-IP, tid och Log Viewer. Titta därefter på strongswan.log, charon.log, sslvpn.log och IPsec-diagnosdata.
  • WebAdmin, User Portal eller SSH är inte åtkomligt: Kontrollera Device Access, Local Service ACL och berörd zon. Använd därefter apache.log, tomcat.log, sshd.log och Packet Capture på målporten.
  • Webfilter, TLS Inspection eller IPS blockerar oväntat: Kontrollera Log-Viewer-modul och Policy-ID. Jämför därefter ips.log, webproxy.log, awarrenhttp.log och Packet Capture.
  • Sophos Central-uppgift fastnar: Jämför Central Task Queue med lokal status. Kontrollera därefter centralmanagement.log, sophos-central.log och fwcm-api-executor.log.
  • HA beter sig olika per Node: Bestäm aktiv Node, Auxiliary Node och berörd trafikväg. Logga därefter in direkt på berörd Node och kontrollera HA-loggar.
  • Lokala rapporter saknas eller lagringen blir full: Kontrollera rapportinställningar, lagringsutrymme och Central Reporting. Använd därefter reportdb.log, garner.log och lagringsanalys.

Denna vy förhindrar en vanlig fälla: man söker i en tjänstloggfil trots att regelmatchning, Device Access, NAT eller routing först borde bevisas.

Log Viewer eller loggfil?

Man öppnar Log viewer i WebAdmin-konsolen uppe till höger. Den uppdateras automatiskt, kan filtreras efter modul, tid, fältvärden och fri text och kan exportera loggar som CSV.

Felsökningsloggar finns på brandväggen i katalogen /log. Åtkomst får man via WebAdmin-konsolen eller via SSH. För korta kontroller fungerar Device Management > Advanced Shell i webbläsaren, men i praktiken är SSH oftast bekvämare, stabilare och bättre för längre tail, grep eller less sessioner. Hur man förbereder SSH säkert finns i guiden Anslut till Sophos Firewall via SSH.

Innan längre Shell-sessioner bör det vara klart från vilket adminnät man ansluter, om SSH-fingeravtrycket har kontrollerats och om Advanced Shell verkligen behövs. För många första kontroller räcker Log Viewer eller Packet Capture i WebAdmin.

Som tumregel hjälper denna ordning:

  1. Enskilt trafikflöde påverkas: Filtrera Log Viewer efter Source, Destination, Service och tid.
  2. Log Viewer visar inget beslut: Starta Packet Capture med snäv filter.
  3. Packet Capture visar Incoming, men inget klart beslut: Kontrollera Rule ID, NAT ID, Firewall ID 0, returväg och lämplig loggfil.
  4. En specifik tjänst verkar instabil: Observera lämplig fil under /log med tail -f.
  5. Ett fel är sporadiskt eller behöver support: Förbered tidsfönster, filter, loggarkiv och vid behov tcpdump.
  6. Normala loggar räcker inte: Aktivera Debug endast för den berörda tjänsten och endast kortvarigt.

Detta håller analysen tillräckligt liten. Man samlar först den synliga observationen, byter sedan till paketflödet och först därefter till tjänstloggar eller Debug. Detta minskar risken för att aktivera breda Debug-loggar för tidigt eller utvärdera en felaktig loggfil.

Läsa loggfiler i Advanced Shell

Innan man söker i /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 gör skillnaden mellan en användbar logganalys och en lång sökning genom gamla poster.

  1. Anslut via SSH eller öppna Device Management > Advanced Shell i WebAdmin-konsolen.
  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:

  • Läsa live: tail -f /log/<logfilename>.log, till exempel tail -f /log/ips.log.
  • Läsa statisk loggfil: less /log/<logfilename>.log, till exempel less /log/ips.log.
  • Söka efter begrepp: grep <keyword> /log/<logfilename>.log, till exempel grep error /log/ips.log.
  • Styra tjänst eller aktivera Debug: service <service>:<start/restart/stop/debug> -ds nosync, till exempel service ips:debug -ds nosync.

För support eller en senare analys bör man inte bara kopiera enskilda loggrader. Bättre är ett tydligt tidsintervall, det reproducerade testet, relevanta skärmdumpar från Log Viewer eller Packet Capture och vid behov ett komplett loggarkiv. Lokala loggar roterar; därför bör viktiga data säkras så länge händelsen fortfarande finns inom den berörda tidsperioden. Proceduren finns i Säkra Sophos Firewall-loggar för extern analys.

Ladda ner felsökningsloggar i WebAdmin

Inte varje logginsamling behöver byggas manuellt med tar från Advanced Shell. För supportfall finns dessutom området Diagnostics > Tools > Log file details respektive valet av Troubleshooting Logs i WebAdmin. Där kan loggfiler väljas efter modul och laddas ner.

I praktiken finns två vägar:

  • Enskilda loggfiler: öppna Diagnostics > Tools > Troubleshooting logs, välj berörda loggfiler och ladda ner dem som komprimerad fil.
  • Consolidated Troubleshooting Report (CTR): använd Diagnostics > Tools > Consolidated troubleshooting report när support behöver alla loggar plus systemstatus, processer och resursdata i ett paket.

Det är praktiskt när en administratör inte vill öppna en längre Shell-session eller när bara ett tydligt avgränsat loggpaket behövs. CTR är bättre när Sophos Support behöver en bred systemsnapshot. När en CTR skapas bör en kort och tydlig orsak anges, till exempel ärendenummer, tidsfönster eller symtom. Rapporten laddas ner krypterat och innehåller för service-subsystemloggar normalt bara ett begränsat antal loggrader. Fullständiga enskilda loggfiler fås mer tillförlitligt via Troubleshooting logs eller direkt från /log.

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

Vid HA-kluster måste man dessutom tänka på detta: loggar och rapporter synkroniseras inte bara mellan Primary och Auxiliary. Varje nod innehåller loggarna för den trafik och de tjänster som den själv har behandlat. Vid nodspecifika fel måste därför den berörda noden kontrolleras.

Advanced Shell eller Device Console?

På 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-nära Shell för filsystem, loggfiler, tail, grep, less, service -S, tjänstomstarter och Debug-kommandon.

Inte varje kommando fungerar i båda områdena. Om en artikel uttryckligen nämner Device Console bör kommandot utföras där. Om det handlar om /log, tail -f, grep, service -S eller Debug-loggning avses i regel Advanced Shell.

Denna åtskillnad är viktig eftersom många fel bara uppstår genom att ett korrekt kommando anges på fel plats.

Loggning måste vara aktiv

Inte varje förväntad information visas automatiskt.

  • I brandväggsregler måste Log firewall traffic vara aktiv.
  • I SSL/TLS-inspektionsregler måste loggning vara aktiverad.
  • Under System services > Log settings måste det definieras vilka loggtyper som skickas lokalt, till Sophos Central eller till Syslog.

För långsiktig lagring är en Syslog-server eller Sophos Central Firewall Reporting lämplig. Hur man ansluter externa loggservrar eller ett SIEM finns i Skicka Sophos Firewall Syslog till SIEM. För Sophos Central är Aktivera Central Firewall Reporting den lämpliga proceduren.

Aktivera Debug endast målmedvetet

Debug-loggning är mycket hjälpsam, men genererar mycket data och kan förbruka lagringsutrymme. Debug bör endast aktiveras för den relevanta tjänsten. Därefter reproducerar man problemet och inaktiverar Debug igen.

Exempel:

service ips:debug -ds nosync
service ips:debug -ds nosync off

Den exakta syntaxen beror på tjänsten. Om den berörda tjänsten är oklar bör först den lämpliga normala loggfilen kontrolleras.

Sophos skiljer här mellan två arbetssätt. I Advanced Shell används tjänstekommandon som service ips:debug -ds nosync. I Device Console finns dessutom kommandona system diagnostics subsystems <subsystem> debug on och system diagnostics subsystems <subsystem> debug off för stödda subsystem. Dessa varianter bör inte blandas: klargör först vilken konsol som används och välj sedan rätt kommando.

Ämnet Debug-loggning och grundläggande CLI-kommandon beskrivs mer utförligt i artikeln Sophos Firewall CLI Troubleshooting: viktiga kommandon. För omstart av enskilda tjänster hjälper dessutom Starta om Sophos Firewall-tjänster säkert.

Vanliga fel vid loggsökning

Många logganalyser tar inte lång tid på grund av brist på data, utan för att man söker för tidigt i fel verktyg.

  • Aktivera Debug direkt: Kontrollera först Log Viewer, lämplig loggfil och reproducerbart test.
  • Söka endast efter felmeddelanden: Begränsa dessutom Source, Destination, User, Rule ID, NAT Rule ID och tid.
  • Ignorera Packet Capture: Om det är oklart om paket ens kommer fram eller går vidare, använd Packet Capture tidigt.
  • Förstå Central Reporting som live-debug: Använd Central Reporting för historik och rapporter, lokala loggar för detaljanalyser.
  • Säkra supportloggar först dagar senare: Säkra loggar, tid och reproduktionssteg medan händelsen fortfarande är spårbar.
  • Låta Debug vara aktiv efter testet: Inaktivera Debug igen och kontrollera lagringsutrymme.

En bra felsökningsfall har därför alltid tre saker: ett snävt test, rätt loggkälla och en dokumenterad tid. Utan denna grund ser man visserligen många loggrader, men inte nödvändigtvis orsaken.

Loggfiler efter funktionsområde

Följande listor är tänkta som uppslagsverk. Välj helst först berört funktionsområde och kontrollera sedan rätt loggfil med ett snävt tidsfönster.

System, Management och bastjänster

  • Systemmeddelanden: syslog.log; kontrollera dessutom tid, reboot och Interface-Events.
  • WebAdmin Webserver: apache.log, apache_access.log; kontrollera dessutom Device Access och Local Service ACL.
  • WebAdmin applikation: tomcat.log; kontrollera dessutom GUI-fel, hög last och tjänststatus.
  • SSH: sshd.log; kontrollera dessutom Device Access, Source-nät och Public-Key-login.
  • GUI/CLI fel: error_log.log; kontrollera dessutom aktuell ändring, webbläsare och adminåtgärd.
  • Konfigurationsändringar: applog.log, csc.log; kontrollera dessutom Audit Trail och Config Studio.
  • Konfigurationsdatabas: postgres.log; kontrollera dessutom lagring, backup/restore och supportärende.
  • Kommunikation mellan komponenter: garner.log; kontrollera dessutom reporting, Central Reporting och loggbehandling.
  • API: apiparser.log, app-feedback.log; kontrollera dessutom API-ACL, token och Central Task Queue.
  • Validering: validation.log, validationError.log; kontrollera dessutom felaktiga objekt eller importer.
  • Licensing: licensing.log; kontrollera dessutom licensstatus, Central Sync och Air-Gap-specialfall.
  • System Updates: u2d.log, sig_update.log; kontrollera dessutom mönsterstatus, DNS/HTTPS och lagringsutrymme.

Vid Management-problem bör man inte bara kontrollera WebAdmin-loggfilen. Mycket ofta avgör Device Access, en Local Service ACL Exception Rule eller fel Source-nät om WebAdmin, SSH, User Portal, VPN Portal, DNS eller SNMP är åtkomliga. För den delen är Säkra åtkomst till Sophos Firewall: Konfigurera Device Access korrekt den bättre starten.

Brandvägg, NAT och Packet Capture

  • Brandväggsregelmatchning: firewall_rule.log; kontrollera dessutom Log Viewer-modul Firewall.
  • Allmän brandväggsbehandling: fwlog.log; använd dessutom Packet Capture.
  • NAT-regler: nat_rule.log; kontrollera dessutom NAT Rule ID i Log Viewer.
  • DNAT med Link Load Balancing: kontrollera dessutom dgd.log när gateway- eller link-val är inblandat.
  • Packet Capture i WebAdmin: pktcapd.log; kontrollera dessutom Diagnostics > Packet capture.
  • Bandwidth Management / QoS: bwm.log; kontrollera dessutom Traffic Shaping Policy.
  • Virtual Host / äldre serverpublicering: vhost.log; kontrollera dessutom NAT och WAF.
  • Web Server Protection / WAF: reverseproxy.log; kontrollera dessutom WAF-regel, Hosted address och backend-tillgänglighet.

Vid DNAT-problem kontrollera alltid brandväggsregel och NAT-regel tillsammans. NAT översätter bara, men tillåter ingen trafik. Mer om detta: Förstå NAT på Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Sophos Firewall använder bland annat IP tables, ARP table, IPset och conntrack för brandväggsanslutningar. För QoS respektive Bandwidth Management används IMQ. Denna information är användbar när man ser loggmeddelanden eller supportutskrifter med tekniska termer från Linux-nätverksvägen.

IPS, Application Control och TLS Inspection

  • Intrusion Prevention: Service ips, Loggfil ips.log.
  • Application Control: Service ips / Application Filter, Loggfil ips.log.
  • DPI och TLS Inspection: DPI Engine, Loggfil ips.log.
  • Antivirus i nätverksvägen: Service avd, Loggfil avd.log.
  • Signaturuppdateringar: Signature Updater, Loggfiler sig_upgrade.log, sig_update.log.
  • Signaturmigrering: Signature Migration, Loggfil sigmigration.log.

Många moderna skyddsfunktioner ser först tillräckligt med detaljer när HTTPS avkrypteras. Om TLS Inspection inte aktiveras är webbfilter, Application Control, IPS och Malware Scan beroende på trafik mindre meningsfulla.

Om det är oklart om IPS överhuvudtaget är aktiv, vilken policy som gäller eller varför en signatur blockeras, hjälper först Ställ in och testa Sophos Firewall IPS säkert. Därefter kan man mer målmedvetet kombinera ips.log, Log Viewer och Packet Capture.

Om det handlar om applikationsigenkänning, Application Filter eller oväntade App-Control-blockeringar, passar först Ställ in och testa Sophos Firewall Application Control.

För Zero-Day Protection, nedladdningsanalys och Sandstorm/Sandboxing måste avd.log, sandboxd.log och relevanta Web- eller Firewall-loggar passa ihop. Den passande driftsartikeln är Förstå och driva Sophos Firewall Zero-Day Protection. För Threat Feeds passar Konfigurera och driva Sophos Firewall Threat Feeds säkert. Mer om TLS Inspection: Rulla ut TLS Inspection på Sophos Firewall steg för steg.

Webb, Proxy, WAF och Webfilter

  • HTTPS Proxy: Service awarrenhttp, Loggfil awarrenhttp.log.
  • HTTPS Proxy Access: awarrenhttp Access Log, Loggfil awarrenhttp_access.log.
  • Web Proxy: Loggfil webproxy.log.
  • Web Categorization / Reputation: Service nSXLd, Loggfil nSXLd.log.
  • Legacy HTTP/FTP Proxy: Service skein, Loggfil skein.log.
  • FTP Proxy: Service ftpproxy, Loggfil ftpproxy.log.
  • Web Application Firewall: Reverse Proxy, Loggfil reverseproxy.log.

Om webbtrafik i Log Viewer visas som blockerad kan orsaken ligga i flera moduler: Web Policy, SSL/TLS-inspektion, Application Control, IPS eller WAF. Därför välj alltid den specifika modulen i Log Viewer och kontrollera dessutom den lämpliga loggfilen.

Sophos blockerar webbplatser i kategorin highly objectionable criminal activity som standard och döljer domännamnet i loggar och rapporter. Om en post i detta område medvetet verkar anonymiserad kan detta alltså vara avsiktligt.

För webbkategorier, URL-grupper, Web Policies och Instant Alerts passar Använd Sophos Firewall Web-kategorier och Instant Alerts.

VPN

  • IPsec från SFOS v17+: Services strongswan, charon; Loggfiler strongswan.log, charon.log.
  • IPsec anslutningsspecifikt: enskild IPsec Connection, Loggfil strongswan-<connection>.log.
  • IPsec äldre versioner: IPsec Service, Loggfil ipsec.log.
  • IPsec Test Connection: IPsec Test, Loggfil ipsec_Test_Connect.log.
  • IPsec Monitoring: IPsec Monitor, Loggfil ipsec_monitor.log.
  • XFRM / route-based VPN: Service 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: Service l2tpd, Loggfil l2tpd.log.
  • PPTP: PPTP VPN, Loggfil pptpvpn.log.
  • VPN Certifikat: VPN Certificate Services, Loggfiler vpncertificate.log, wc_remote.log.
  • Clientless SSL VPN: Clientless Access, 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, Local/Remote Subnets, NAT-T, routing och brandväggsregler avgörande.

För IPsec-problem är artikeln Sophos Firewall IPsec Troubleshooting den bättre steg-för-steg-guiden. Om det handlar om route-based VPN och manuella IPsec-rutter hjälper Skapa IPsec Route på Sophos Firewall.

Autentisering, User Portal och SSO

  • Användarautentisering: Access Server / AAA, Loggfil access_server.log.
  • NTLM / NASM: Service 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.
  • STAS: STAS / Access Server-kontext, beroende på tjänstkontext och access_server.log.

Vid användarregler kontrollera alltid först om användaren överhuvudtaget är känd. Om Match known users är aktiv och autentiseringen inte fungerar, matchar inte regeln.

Om Captive Portal används med Microsoft Entra ID SSO hjälper Ställ in Microsoft Entra ID SSO för Sophos Firewall Captive Portal vid avstämning av oauth_sso_captive.log, Device Access, grupper och senare regelmatchning.

DNS, DHCP och nätverk

  • DNS Service: Service dnsd, Loggfil dnsd.log.
  • DNS Grabber: Service dnsgrabber, Loggfil dnsgrabber.log.
  • DNS Entity / andra DNS-komponenter: Services entity, eacd; Loggfiler entity.log, eacd.log.
  • DHCP IPv4: Service dhcpd, Loggfil dhcpd.log.
  • DHCP IPv6: Loggfil dhcp6.log.
  • Nätverkstjänst: Service networkd, Loggfil networkd.log.
  • FQDN Hosts: Service fqdnd, Loggfiler fqdnd.log, fqdndebug.log.
  • Dead Gateway Detection: Service dgd, Loggfil dgd.log.
  • Dynamic DNS: Dynamic DNS Client, Loggfil ddc.log.
  • NTP Client: Loggfil ntpclient.log.
  • IPv6 Router Advertisement: Service radvd, Loggfil radvd.log.

DNS- och DHCP-problem verkar ofta som brandväggsproblem. Därför bör man först kontrollera IP-adress, gateway, DNS-server och frågan om klienter ska använda brandväggen som DNS- eller DHCP-server.

Om interna domäner inte löses korrekt är oftast Konfigurera DNS request routes på Sophos Firewall relevant. För DHCP-specialalternativ finns den egna artikeln Konfigurera Sophos Firewall DHCP Options.

Cellular WAN

  • WWAN / USB-modem: Kontrollera anslutning och borttagning av USB-enheter i mdev.log.
  • Modemnätverkskonfiguration: Kontrollera modemrelaterade interfaces och IP-konfiguration i networkd.log.
  • USB, modem och PPP: Kontrollera Syslog-meddelanden om USB, modem och Point-to-Point Protocol i syslog.log.

Vid Cellular-WAN-problem bör man dessutom kontrollera om modemet känns igen, om PIN/SIM/APN är korrekta och om brandväggen skapar en lämplig gateway.

Routing

  • Static Routing: Service zebra, Loggfil zebra.log.
  • Application Based Routing: Service appcached, Loggfil appcached.log.
  • Redis App Cache: Redis, Log redis.
  • Multicast Routing: Loggfil mrouting.log.
  • BGP: Service bgpd, Loggfil bgpd.log.
  • OSPF: Service ospfd, Loggfil ospfd.log.
  • RIP: Service ripd, Loggfil ripd.log.
  • PIM-SM: Service pimd, Loggfil pimd.log.

Vid routingproblem kontrollera dessutom Routing > SD-WAN routes, gateways och Packet Capture. Policy testern ersätter inte ett riktigt routingtest.

Mer om detta: Anpassa routingprioritet på Sophos Firewall.

GUI, CLI och systemåtkomst

För WebAdmin, SSH, API och lokala Management-tjänster finns bastabellen längre upp under System, Management och bastjänster. Om WebAdmin eller SSH inte är tillgängligt, kontrollera inte bara apache.log, tomcat.log eller sshd.log. Lokal åtkomst styrs via Administration > Device access och Local Service ACL.

Mer om detta: Upprätta SSH-anslutning till Sophos Firewall.

Sophos Central, Heartbeat och Central Management

  • Sophos Central Management: Central Management, Loggfiler centralmanagement.log, sophos-central.log.
  • CSC: Services csc, cschelper, csd; Loggfiler csc.log, cschelper.log, csd.log.
  • Security Heartbeat: Services heartbeatd, hbtrust; Loggfiler heartbeatd.log, hbtrust.log.
  • Heartbeat till Central: Services fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; kontrollera respektive tjänstloggar.
  • Central API Executor: Service fwcm-api-executor, Loggfil fwcm-api-executor.log.
  • Active Threat Response: ATR-kontext; kontrollera beroende på version och modul.

Vid Central-problem kontrollera först om brandväggen är registrerad, Central Services är aktiva och om DNS/HTTPS utgående fungerar. Om en ändring från Central inte kommer fram lokalt bör man jämföra Sophos Central Firewall Management Task Queue med de lokala loggarna. En grön Central-status bevisar inte ensam att en konkret policy har behandlats lokalt.

High Availability

  • HA Status och konfiguration: HA Application Log, Loggfil applog.log.
  • HA Pair Service: Service ha_pair, Loggfil ha_pair.log.
  • HA Tunnel: Service ha_tunnel, Loggfil ha_tunnel.log.
  • Conntrack Sync: Service ctsyncd, Loggfil ctsyncd.log.
  • Msync: Service msync, Loggfil msync.log.

HA-loggar finns på den enhet där de skapades. För råloggar från Auxiliary-enheten måste man ansluta direkt till denna enhet, till exempel via dess admin-port via SSH. För konsoliderade rapporter är Sophos Central Firewall Reporting mer praktiskt.

Mail och Anti-Spam

  • Antivirus: AV Service, Loggfil av.log.
  • Antivirusuppdateringar: Up2Date AV, Loggfil up2date_av.log.
  • Anti-Spam: Service sasi, Loggfil sasi.log.
  • Sandbox: Service sandboxd, Loggfiler sandboxd.log, sessiontbl.log.
  • SMTP MTA: Service smtpd, Loggfil smtpd_main.log.
  • SMTP fel: smtpd Error/Panic/Reject, Loggfiler smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
  • Legacy SMTP/S Proxy: Services awarrensmtp, awarrenmta; Loggfiler awarrensmtp.log, awarrenmta.log, awarrenmta_debug.log.
  • POP/IMAP Proxy: Service warren, Loggfil warren.log.

Vid mailproblem kontrollera alltid om MTA Mode, brandväggsregel, DNS, certifikat och leverantörsrestriktioner passar ihop. Proceduren för mailflöde, spool, karantän och relay beskrivs i Ställ in Sophos Firewall Mail Protection i MTA Mode.

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

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

  • Wireless Controller: Service awed, Loggfil awed.log.
  • Wi-Fi Authentication: Service wifiauth, Loggfil wifiauth.log.
  • Hotspot: Services hostapd, hotspot, hotspotd; Loggfiler hostapd.log, hotspot.log, hotspotd.log.
  • RED: RED Service, Loggfil red.log.
  • SNMP: Service snmpd, Loggfil snmpd.log.
  • Syslog Service: Loggfil syslog.log.
  • Licensing: Licensing Service, Loggfil licensing.log.
  • System Updates: Service u2d, Loggfil u2d.log.
  • VMware Tools: Service vmtool, Loggfil vmtool.log.
  • SMB-Filesystem: Services smbnetfs, snireport; Loggfiler smbnetfs.log, snireport.log.

Vid licens-, Air-Gap- eller mönsterproblem är licensing.log och u2d.log de första tekniska kontaktpunkterna. För driften med licensfil, 180-dagarsfönster och manuella mönsteruppdateringar passar Driva Sophos Firewall Air-Gap-licensiering och mönsteruppdateringar.

Databas och rapportering

  • Configuration database: Config DB, Loggfiler confdbstatus.log, crreportdb.log.
  • Postgres: Service postgres, Loggfil postgres.log.
  • Signature database: Service sigdb, Loggfil sigdb.log.
  • Report database: Report DB, Loggfil reportdb.log.
  • Migration database: Report Migration, Loggfiler sac-feedback.log, reportmigration.log.
  • Garner: Service garner, Loggfil garner.log.
  • iView: Service iview, Loggfil iview.log.

Om rapporter saknas, är långsamma eller om lagringsproblem uppstår är rapporterings- och databasloggar relevanta. Dessutom bör man kontrollera om rapporter lagras lokalt eller skickas till Sophos Central.

Analysflöde

  1. Notera problemet exakt: tid med tidszon, klient, mål, port, användare, åtgärd.
  2. Avgör om det handlar om trafik, tjänststatus, konfigurationsändring eller Central-synkronisering.
  3. Filtrera i Log Viewer efter Source IP, Destination IP, modul och tid.
  4. Kontrollera synlighet av Firewall Rule ID, NAT Rule ID, User, Gateway och Policy IDs.
  5. Använd Packet Capture om paketflöde, returväg eller NAT-vy är oklar.
  6. Kontrollera lämplig loggfil med tail -f, less eller grep.
  7. Reproducera problemet och dokumentera exakt testtidpunkt.
  8. Aktivera Debug endast för berörd tjänst och endast kort om nödvändigt.
  9. Inaktivera Debug igen och kontrollera lagringsutrymme.
  10. Säkra loggar medan felet nyligen reproducerades.

För supportärenden bör man dessutom dokumentera alla felmeddelanden, reproduktionssteg och redan utförda felsökningssteg. Just denna information påskyndar supportärenden avsevärt. Den lämpliga proceduren finns i Öppna ett Sophos Supportärende: Förberedelse och portal.

FAQ

Vilken loggfil är viktigast på 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, för IPS och Application Control ofta ips.log. Log Viewer är dock fortfarande den bästa första ingången för enskilda anslutningar.

Vad är CTR i Sophos Firewall-loggar?

CTR står i många Sophos-sammanhang för Consolidated Troubleshooting Report. För administratörer är det viktigt: Ett CTR- eller Troubleshooting-loggpaket hjälper supporten, men ersätter inte en tydlig felbeskrivning med tid, berörda IP-adresser, användare, tunnelnamn, regel-ID och reproduktionssteg.

När behöver man Advanced Shell?

Advanced Shell är användbar när lokala loggfiler måste kontrolleras med tail, grep eller less, en tjänststatus kontrolleras eller Sophos Support behöver detaljerade loggdata. För många första kontroller räcker Log Viewer, Policy Test och Packet Capture i WebAdmin.

Bör man låta Debug-loggning vara aktiv permanent?

Nej. Debug genererar mycket data och kan förbruka lagringsutrymme. Debug bör endast användas för den berörda tjänsten, för ett kort reproducerbart test och med efterföljande inaktivering.

Varför ser man inga förväntade brandväggshändelser i Log Viewer?

Ofta är Log firewall traffic inte aktiv i den berörda regeln, fel tidsperiod eller filter är valt, eller trafiken når inte 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 detaljanalyser direkt på brandväggen. Central Reporting är lämplig för Sophos-Central-rapporter och historik. Syslog är bättre för egna SIEM-, SOC- eller långsiktig lagring.