Naar de inhoud
Avanet

Sophos Firewall-servicelogs correct toewijzen

Bij Sophos Firewall zijn er drie belangrijke niveaus voor troubleshooting: gebeurtenislogs in de Log Viewer, diagnosehulpmiddelen in WebAdmin en dienst- of logbestanden op de firewall. De Log Viewer is ideaal voor snelle vragen zoals “werd de verbinding toegestaan of geblokkeerd?”. De bestanden onder /log zijn belangrijker wanneer een dienst niet start, een VPN-tunnel instabiel is, webfilters onverwacht ingrijpen of wanneer support gedetailleerde gegevens nodig heeft.

Dit artikel ordent de belangrijkste diensten en logbestanden naar typische beheerproblemen. Het helpt ook wanneer in het dashboard, in de Advanced Shell of in een supportcase een technische dienstnaam opduikt en het niet meteen duidelijk is welke firewallfunctie daarachter zit. Namen zoals zebra, warren, awed, garner of strongswan zijn in het dagelijks gebruik niet vanzelfsprekend.

Hulpmiddelkeuze en vereisten

Voordat men in logbestanden zoekt, moet duidelijk zijn welk hulpmiddel het snelst antwoord geeft. Veel gevallen kunnen al met Log Viewer of Packet Capture worden afgebakend. De shell wordt pas echt nuttig wanneer een dienst zelf moet worden gecontroleerd of support gedetailleerde loggegevens nodig heeft.

Welk probleemoplossingshulpmiddel past?

Niet elk firewallprobleem begint met een shell. Vaak is een ander hulpmiddel sneller:

De volgorde is belangrijk. De Log Viewer toont vaak sneller welke regel of welke module heeft beslist. Packet Capture bewijst de pakketstroom in WebAdmin. tcpdump is nuttig wanneer een langere opname, een PCAP-bestand of een zeer nauwkeurige CLI-filter nodig is. Servicelogs en Debug helpen wanneer een specifieke dienst zelf het probleem is of wanneer gegevens voor Sophos Support moeten worden verzameld.

Snelle start per symptoom

Als niet duidelijk is welk log relevant is, helpt een start op basis van symptoom in plaats van dienstnaam.

  • Afzonderlijke verbinding werkt niet: eerst Log Viewer met Source, Destination, Service en tijd controleren. Daarna Packet Capture, firewall_rule.log en nat_rule.log gebruiken.
  • VPN-tunnel is niet actief of instabiel: VPN-status, peer-IP, tijd en Log Viewer controleren. Daarna strongswan.log, charon.log, sslvpn.log en IPsec-diagnosegegevens bekijken.
  • WebAdmin, User Portal of SSH is niet bereikbaar: Device Access, Local Service ACL en getroffen zone controleren. Daarna apache.log, tomcat.log, sshd.log en Packet Capture op de doelpoort gebruiken.
  • Webfilter, TLS Inspection of IPS blokkeert onverwacht: Log-Viewer-module en Policy ID controleren. Daarna ips.log, awarrenhttp.log en Packet Capture vergelijken.
  • Sophos Fusion taak blijft hangen: Central Task Queue en lokale status vergelijken. Daarna centralmanagement.log, sophos-central.log en fwcm-api-executor.log controleren.
  • HA gedraagt zich per knooppunt verschillend: actief knooppunt, Auxiliary-knooppunt en getroffen verkeerspad bepalen. Daarna direct op het getroffen knooppunt aanmelden en de HA-logs controleren.
  • Lokale rapporten ontbreken of opslag loopt vol: rapportinstellingen, opslagruimte en Central Reporting controleren. Daarna reportdb.log, garner.log en opslaganalyse gebruiken.

Dit overzicht voorkomt een typische valkuil: men zoekt in een servicelogbestand, terwijl eerst regeltoewijzing, Device Access, NAT of routering moet worden aangetoond.

Log Viewer of Logbestand?

De Log viewer opent men in de WebAdmin-console rechtsboven. Hij wordt automatisch bijgewerkt, kan worden gefilterd op module, tijd, veldwaarden en vrije tekst en kan logs als CSV exporteren.

Om gebruikersnamen en IP-, MAC- en e-mailadressen in de dagelijkse logweergave te beschermen, kan Data Anonymization voor lokale logs en rapporten worden gebruikt. De werking in Log viewer bewijst niet automatisch dat bestanden onder /log, CTR, Remote Syslog of Central dezelfde identiteiten anonimiseren; elk uitvoerpad wordt afzonderlijk gecontroleerd.

Probleemoplossingslogs staan in de map /log. De officieel gedocumenteerde route loopt via de CLI: aanmelden, 5 Device Management kiezen en daarna 3 Advanced Shell. Voor langere sessies met tail, grep of less is SSH meestal prettiger. De veilige voorbereiding staat in Sophos Firewall per SSH verbinden.

Voor langere shell-sessies moet duidelijk zijn vanuit welk admin-netwerk men verbinding maakt, of de SSH-fingerprint is gecontroleerd en of de Advanced Shell echt nodig is. Voor veel eerste controles volstaat de Log Viewer of Packet Capture in WebAdmin.

Als vuistregel helpt deze volgorde:

  1. Een afzonderlijke verkeersstroom is getroffen: Log Viewer filteren op Source, Destination, Service en tijd.
  2. Log Viewer toont geen beslissing: Packet Capture met een nauw filter starten.
  3. Packet Capture toont Incoming, maar geen duidelijke beslissing: Rule ID, NAT ID, Firewall ID 0, retourpad en passend logbestand controleren.
  4. Een specifieke dienst lijkt instabiel: het passende bestand onder /log met tail -f volgen.
  5. Een fout is sporadisch of vereist support: tijdvenster, filter, logarchief en eventueel tcpdump voorbereiden.
  6. Normale logs volstaan niet: Debug alleen voor de getroffen dienst en slechts kort activeren.

Hiermee blijft de analyse klein genoeg. Men verzamelt eerst de zichtbare bevinding, schakelt dan over naar de pakketstroom en pas daarna naar dienstlogs of Debug. Dit vermindert het risico om te vroeg brede Debug-logs te activeren of een verkeerd logbestand te evalueren.

Logbestanden in de Advanced Shell lezen

Voordat men in /log zoekt, moet de testcase zo nauwkeurig mogelijk worden gedocumenteerd: lokale tijd, getroffen bron-IP, bestemming-IP, poort, gebruiker, module en verwacht gedrag. Deze gegevens maken het verschil tussen een bruikbare loganalyse en een lange zoektocht door oude vermeldingen.

  1. Aanmelden bij de CLI, 5 Device Management kiezen en daarna 3 Advanced Shell.
  2. Naar de logmap gaan.
cd /log

Nuttige commando’s:

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

De belangrijkste commando’s uit de Advanced Shell:

  • Live volgen: tail -f /log/<logfilename>.log, bijvoorbeeld tail -f /log/ips.log.
  • Statisch logbestand lezen: less /log/<logfilename>.log, bijvoorbeeld less /log/ips.log.
  • Naar een term zoeken: grep <keyword> /log/<logfilename>.log, bijvoorbeeld grep error /log/ips.log.
  • Dienststatus lezen: service -S gebruiken of op een naam beperken, bijvoorbeeld service -S | grep ips. Deze controle wijzigt de dienst niet.

Voor ondersteuning of een latere analyse moet men niet alleen afzonderlijke logregels kopiëren. Beter zijn een duidelijk tijdsbereik, de gereproduceerde test, relevante screenshots uit Log Viewer of Packet Capture en indien nodig een volledig logarchief. Lokale logs roteren; daarom moeten belangrijke gegevens worden beveiligd zolang de gebeurtenis nog in de getroffen periode aanwezig is. De procedure staat in Sophos Firewall Logs voor externe analyse beveiligen.

Troubleshooting-logs in WebAdmin downloaden

Niet elke logverzameling hoeft handmatig in Advanced Shell te worden samengesteld. WebAdmin verzamelt de bestanden onder Diagnostics > Tools.

In de praktijk zijn er twee routes:

  • Afzonderlijke logbestanden: Diagnostics > Tools > Troubleshooting logs openen, betrokken logbestanden selecteren en als gecomprimeerd bestand downloaden.
  • Consolidated Troubleshooting Report (CTR): Diagnostics > Tools > Consolidated troubleshooting report gebruiken wanneer support alle logs plus systeemstatus, processen en resourcegegevens in één pakket nodig heeft.

Dat is praktisch wanneer een duidelijk afgebakend logpakket volstaat. De CTR past beter wanneer Sophos Support een brede systeemsnapshot nodig heeft. Geef een heldere reden op, zoals ticketnummer, tijdvenster of symptoom. Het rapport wordt versleuteld gedownload; de bestandsnaam bevat ook het serienummer van de firewall en hoort daarom niet in openbare bijlagen.

Een CTR bevat standaard 10.000 regels per service subsystem log. In Device Console kan de waarde alleen tussen 250 en 10.000 worden ingesteld en dus alleen ten opzichte van de standaard worden verlaagd. Default subsystem logs bevatten alle regels. Deze limiet geldt uitsluitend voor de CTR; volledige afzonderlijke bestanden blijven beschikbaar via Troubleshooting logs of Advanced Shell.

Belangrijk: een gedownload logpakket vervangt de contextgegevens niet. Support heeft nog steeds tijd met tijdzone, getroffen IP’s, gebruiker, tunnelnaam, Rule ID, NAT ID en een korte beschrijving nodig van wat precies is gereproduceerd.

Bij HA-clusters moet men bovendien rekening houden met het volgende: logs en rapporten worden niet simpelweg tussen Primary en Auxiliary gesynchroniseerd. Elk knooppunt bevat de logs voor het verkeer en de diensten die het zelf heeft verwerkt. Bij knooppuntspecifieke fouten moet daarom het betrokken knooppunt worden gecontroleerd.

Logrotatie en vluchtige gegevens begrijpen

Troubleshooting Logs worden eerst in het werkgeheugen gemaakt en daarna door de firewall naar het bestandssysteem gekopieerd. Als de firewall niet meer reageert, kunnen vermeldingen verloren gaan die nog niet zijn gekopieerd. Een onverwachte herstart of vastloper is daarom geen reden om de bewijsvastlegging uit te stellen; sla eerst de beschikbare CTR-, log- en tijdgegevens op.

Elk subsysteem heeft afhankelijk van kritikaliteit en appliancemodel eigen limieten voor bestandsgrootte en opslag. Wanneer het actieve bestand de limiet bereikt, comprimeert SFOS het als .gz en schrijft verder onder de oorspronkelijke bestandsnaam. Als ook de rotaties de subsysteemlimiet bereiken, wordt het oudste gecomprimeerde bestand eerst verwijderd. Het aantal rotaties en de beschikbare historie zijn daarom niet voor alle diensten gelijk.

Hernoem of verwijder logbestanden en .gz-rotaties niet handmatig. Volg voor opslaganalyse, export en de gedocumenteerde purge-commando’s de procedure Opslagruimte en rapporten gecontroleerd beheren.

Advanced Shell of Device Console?

Bij Sophos Firewall zijn er twee verschillende consolegebieden die vaak worden verward:

  • Device Console: Sophos CLI voor firewall-specifieke commando’s, bijvoorbeeld routeringsprioriteit, IPsec-routes of systeemopties.
  • Advanced Shell: Linux-achtige shell voor bestandssysteem, logbestanden en alleen-lezencommando’s zoals tail, grep, less en service -S.

Niet elk commando werkt in beide gebieden. /log, tail -f, grep en service -S horen bij Advanced Shell. De gedocumenteerde system diagnostics ...-commando’s voor CTR-limieten, logverwijdering en subsysteemdebug horen bij Device Console.

Dit onderscheid is belangrijk, omdat veel fouten alleen ontstaan doordat een correct commando op de verkeerde plaats wordt ingevoerd.

Logging moet actief zijn

Niet elke verwachte informatie verschijnt automatisch.

  • In Firewallregels moet Log firewall traffic actief zijn.
  • In SSL/TLS-inspectieregels moet logging geactiveerd zijn.
  • Onder System services > Log settings moet worden gedefinieerd welke logtypen lokaal, naar Sophos Fusion of naar Syslog worden verzonden.

Voor langdurige opslag is een Syslog-server of Sophos Central Firewall Reporting zinvol. Hoe men externe logservers of een SIEM kan aansluiten, staat in Sophos Firewall Syslog naar SIEM verzenden. Voor Sophos Fusion is Central Firewall Reporting activeren de juiste procedure.

Debug alleen gericht activeren

Debug-Logging genereert veel meer gegevens, neemt opslagruimte in en kan vertrouwelijke inhoud vastleggen. Het is daarom geen verstandige eerste stap. Bepaal eerst normaal logbestand, tijdvenster en reproduceerbare test; gebruik Debug alleen voor het getroffen subsysteem en zo kort mogelijk.

Sophos documenteert twee verschillende methoden. De Advanced-Shell-vorm service <service>:debug -ds nosync wisselt de status en kent geen afzonderlijk argument on of off. Gebruik voor een ondersteund servicesubsysteem bij voorkeur de expliciete Device Console-commando’s die Sophos documenteert: system diagnostics subsystems <subsystem> debug on, reproduceer het probleem en verzamel de gegevens, en voer daarna system diagnostics subsystems <subsystem> debug off uit. Voor Packet Capture-debug is de subsysteemnaam bijvoorbeeld Pktcapd. Debug staat standaard uit, maar controleer vóór een wijziging of een andere beheerder of Sophos Support niet al gegevens verzamelt. Leg de wijziging vast en controleer na afloop dat Debug uitstaat.

Behandel CSC-systeemcontrollerdebug als een afzonderlijke schakelaar

SFOS 22 documenteert voor de systeemcontroller (CSC) een afzonderlijk Device Console-commando:

system diagnostics subsystems CSC debug

Anders dan de bovenstaande syntax voor servicesubsystemen heeft dit commando geen argument on of off: elke uitvoering schakelt CSC-debug om. Gebruik het als gecontroleerde wijziging, niet als statusvraag:

  1. Voorcontrole: Bevestig met andere beheerders en Sophos Support dat CSC-debug niet al actief is of deel uitmaakt van een lopende gegevensverzameling. Leg firewall of HA-node, tijd, reden en gepland verzamelvenster vast. Bewaar vóór de wijziging een referentiekopie van het relevante CSC-log. Voer de schakelaar niet uit om alleen de status te achterhalen.
  2. Activeren en reproduceren: Voer het commando in Device Console exact één keer uit. Reproduceer alleen het afgebakende probleem en noteer de testtijd met tijdzone.
  3. Bewijs bewaren: Download vóór de rollback het relevante afzonderlijke troubleshooting-log, of genereer de CTR en download het voltooide CTR-bestand. Beperk toegang tot de versleutelde CTR en elk logarchief omdat deze vertrouwelijke gegevens kunnen bevatten; wis of overschrijf geen bewijs dat voor de case nodig is.
  4. Deactiveren / rollback: Ga terug naar Device Console en voer hetzelfde commando exact één keer uit. Deze tweede geplande uitvoering schakelt CSC-debug weer uit.
  5. Verifiëren: Voer een korte gecontroleerde test uit en bevestig in de nieuw geschreven CSC-logregels dat uitvoer op debugniveau is gestopt en het log weer normaal groeit. Leg tijd en resultaat van de rollback vast. Als de beginstatus of nacontrole onduidelijk is, voer de schakelaar dan niet herhaaldelijk uit; stop en stem de status af met Sophos Support.

⚠️ WAF-Debug en reverseproxy.log: Sophos heeft met SFOS 22.0 MR2 Build 546 fout NC-177457 opgelost, waarbij bij ingeschakelde WAF-Debug een wachtwoord zichtbaar was in reverseproxy.log. Sophos noemt noch het begin van het getroffen versiebereik, noch het soort wachtwoord. Reeds aangemaakte WAF-Debug-logs, troubleshooting-archieven en CTR-bestanden uit oudere of onbekende builds moeten daarom worden behandeld alsof ze mogelijk inloggegevens bevatten.

Als inloggegevens in platte tekst worden gevonden: toegang beperken, het incident documenteren en de betreffende inloggegevens wijzigen. Logs niet zonder onderscheid verwijderen voordat vereisten voor support, forensisch onderzoek en bewaartermijnen zijn opgehelderd.

Het onderwerp Debug-Logging en basis CLI-commando’s wordt uitgebreider beschreven in het artikel Sophos Firewall CLI Troubleshooting: belangrijke commando’s. Voor het herstarten van afzonderlijke diensten helpt daarnaast Sophos Firewall Services veilig herstarten.

Typische fouten bij het zoeken naar logs

Veel loganalyses duren niet lang vanwege ontbrekende gegevens, maar omdat te vroeg in het verkeerde hulpmiddel wordt gezocht.

  • Direct Debug activeren: eerst Log Viewer, passend logbestand en een reproduceerbare test controleren.
  • Alleen naar foutmeldingen zoeken: daarnaast Source, Destination, User, Rule ID, NAT Rule ID en tijd beperken.
  • Packet Capture negeren: als onduidelijk is of pakketten aankomen of doorgaan, vroeg Packet Capture gebruiken.
  • Central Reporting als live-debug beschouwen: Central Reporting voor geschiedenis en rapporten gebruiken, lokale logs voor detailanalyse.
  • Support-logs pas dagen later veiligstellen: logs, tijd en reproductiestappen veiligstellen zolang de gebeurtenis nog te traceren is.
  • Debug na de test laten draaien: Debug weer deactiveren en opslagruimte controleren.

Een goed probleemoplossingsgeval heeft daarom altijd drie dingen: een nauwe test, de passende logbron en een gedocumenteerde tijd. Zonder deze basis ziet men wel veel logregels, maar niet noodzakelijk de oorzaak.

Logbestanden per functiegebied

De volgende lijsten zijn bedoeld als naslagwerk. Kies bij voorkeur eerst het getroffen functiegebied en controleer daarna het passende logbestand met een nauw tijdvenster.

De primaire toewijzingen volgen de actuele SFOS 22.0-documentatie. Op oudere installaties of in oude supportarchieven kunnen daarnaast de eerder gebruikte namen 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 en crreportdb.log voorkomen. Sophos vermeldt ze niet meer in de actuele SFOS 22.0-loglijst; daarom mag men ze op een actuele build niet als aanwezig veronderstellen.

Systeem, beheer en basisdiensten

  • Systeemstart: sysinit.log; eerst controleren bij opstart- en Failsafe-problemen.
  • Systeemmeldingen: syslog.log; daarnaast tijd, herstarts en interfacegebeurtenissen controleren.
  • Webserver van WebAdmin: apache.log, apache_access.log; daarnaast Device Access en Local Service ACL controleren.
  • WebAdmin-applicatie: tomcat.log; daarnaast GUI-fouten, hoge belasting en servicestatus controleren.
  • SSH: sshd.log; daarnaast Device Access, bronnetwerk en aanmelding met een openbare sleutel controleren.
  • GUI/CLI-fouten: error_log.log; daarnaast recente wijzigingen, browser en beheerdersacties controleren.
  • Configuratiewijzigingen: applog.log, csc.log; daarnaast Audit Trail en Config Studio controleren.
  • Configuratiedatabase: postgres.log; daarnaast opslagruimte, backup/restore en supportcase controleren.
  • Communicatiekanaal tussen bepaalde componenten en hun services: garner.log; bij Central Management en reporting ook de bijbehorende pluginvermeldingen controleren.
  • API: apiparser.log; daarnaast validation.log, API-ACL, token en Central Task Queue controleren.
  • Validatie: validation.log, validationError.log; daarnaast foutieve objecten of imports controleren.
  • Licensing: licensing.log; daarnaast licentiestatus, Central Sync en Air-Gap-special case controleren.
  • System Updates: u2d.log; daarnaast patternstatus, DNS/HTTPS en opslagruimte controleren.

Bij managementproblemen moet niet alleen het WebAdmin-logbestand worden gecontroleerd. Zeer vaak bepaalt Device Access, een Local Service ACL Exception Rule of een verkeerd bronnetwerk of WebAdmin, SSH, User Portal, VPN Portal, DNS of SNMP bereikbaar zijn. Voor dit deel is Sophos Firewall-toegang beveiligen: Device Access correct configureren de betere start.

Firewall, NAT en Packet Capture

  • Toewijzing van firewallregels: context Firewall Rule Engine, logbestand firewall_rule.log; daarnaast de Log Viewer-module Firewall controleren.
  • Algemene firewallverwerking: context Firewall Log / kernelpad, logbestand fwlog.log; daarnaast Packet Capture gebruiken.
  • NAT-regels: context NAT Rule Engine, logbestand nat_rule.log; daarnaast NAT Rule ID in Log Viewer controleren.
  • DNAT met Link Load Balancing: context gateway-/linkmonitoring, logbestand dgd.log; daarnaast de gateway- of linkkeuze controleren.
  • Packet Capture in WebAdmin: logbestand pktcapd.log; daarnaast Diagnostics > Packet capture controleren.
  • Bandwidth Management / QoS: logbestand bwm.log; daarnaast de Traffic Shaping Policy controleren.
  • Virtual Host / oudere serverpublicatie: logbestand vhost.log; daarnaast NAT en WAF controleren.
  • Web Server Protection / WAF: context Reverse Proxy, logbestand reverseproxy.log; daarnaast WAF-regel, Hosted address en backendbereikbaarheid controleren.

Bij DNAT-problemen altijd Firewallregel en NAT-regel samen controleren. NAT vertaalt alleen, maar staat geen verkeer toe. Meer hierover: NAT op Sophos Firewall begrijpen: SNAT, DNAT, MASQ, PAT.

Sophos Firewall gebruikt voor firewallverbindingen onder andere IP tables, ARP table, IPset en conntrack. Voor QoS of Bandwidth Management wordt IMQ gebruikt. Deze informatie is nuttig wanneer men logmeldingen of ondersteuningsuitvoer met technische termen uit het Linux-netwerkpad ziet.

IPS, Application Control en TLS Inspection

  • Intrusion Prevention: service ips, logbestand ips.log.
  • Application Control: service ips / Application Filter, logbestand ips.log.
  • DPI en TLS Inspection: context DPI Engine, logbestand ips.log.
  • Antivirus in het netwerkpad: service avd, logbestand avd.log.
  • Zero-Day Protection / Sandbox: context Sandbox Service, logbestand sandboxd.log.
  • Active Threat Response / X-Ops Threat Feeds: ATR in het netwerkpad; eerst Log Viewer en afhankelijk van de module ook ips.log controleren.
  • MDR Threat Feeds: context ATR / MDR-feedstatus, logbestand atr.log; de beheerhandleiding correleert Audit ID, Task Queue en lokaal verkeersbewijs.
  • Signatuur-updates: context Signature Updater, logbestand sig_upgrade.log.
  • Signatuurmigratie: context Signature Migration, logbestand sigmigration.log.

Veel moderne beschermingsfuncties zien pas voldoende details wanneer HTTPS wordt ontsleuteld. Als TLS Inspection niet werkt, zijn webfilters, Application Control, IPS en Malware Scan afhankelijk van het verkeer minder informatief.

Als onduidelijk is of IPS actief is, welk beleid van toepassing is of waarom een signatuur blokkeert, helpt eerst Sophos Firewall IPS instellen en veilig testen. Daarna kan men ips.log, Log Viewer en Packet Capture gerichter samenvoegen.

Als het gaat om applicatieherkenning, Application Filter of onverwachte App-Control-blokkeringen, past eerst Sophos Firewall Application Control instellen en testen.

Voor Zero-Day Protection moet men daarnaast controleren of Web Protection, TLS Inspection, bestandstype, bestandsgrootte, policy en actie samenpassen. Het passende operationele artikel is Sophos Firewall Zero-Day Protection begrijpen en beheren. Voor Threat Feeds past Sophos Firewall Threat Feeds instellen en veilig beheren. Meer over TLS Inspection: TLS Inspection op Sophos Firewall stapsgewijs uitrollen.

Web, Proxy, WAF en Webfilter

  • HTTPS Proxy: service awarrenhttp, logbestand awarrenhttp.log.
  • HTTPS Proxy Access: context awarrenhttp Access Log, logbestand awarrenhttp_access.log. In SFOS 22/23 verschijnen afzonderlijke webproxyverzoeken hier alleen wanneer awarrenhttp met ingeschakelde debug draait; volg de onderstaande verzamelprocedure.
  • Web Categorization / Reputation: service nSXLd, logbestand nSXLd.log.
  • Categorie-updates (SFOS 22/23): logbestand catUpdateLog – behoud de exacte hoofdletters en kleine letters, zonder .log-achtervoegsel.
  • Legacy HTTP/FTP Proxy: service skein, logbestand skein.log.
  • FTP Proxy: service ftpproxy, logbestand ftpproxy.log.
  • Web Application Firewall: context Reverse Proxy, logbestand reverseproxy.log.

Bepaal voor deze verzameling van toegangslogs eerst de betrokken firewall-/HA-node, het testgeval, de tijd en een kort verzamelvenster, controleer de schijfruimte en bevestig met andere beheerders of support dat debug uitstaat. Gebruik het omschakelcommando niet als statusopvraag. Voer daarna service awarrenhttp:debug -ds nosync precies eenmaal uit in de Advanced Shell, reproduceer het afgebakende probleem en bewaar awarrenhttp_access.log beveiligd. Voer vervolgens hetzelfde commando precies eenmaal uit om debug weer uit te schakelen. Controleer met een korte, gecontroleerde test dat er geen nieuwe debugregels verschijnen en dat het normale log weer met de gebruikelijke snelheid groeit; documenteer de rollback en de schijfruimtecontrole. Als de beginstatus of de nacontrole onduidelijk is, blijf dan niet omschakelen, maar verduidelijk dit met support. Deze methode geldt hier voor awarrenhttp in SFOS 22/23, niet algemeen voor alle diensten of releases.

Bij een vermoedelijke proxylus kan block_proxy_loop samen met kort ingeschakelde awarrenhttp-debug de melding Duplicate Via header values, proxy loop opleveren. HTTP-proxy-instellingen veilig controleren beschrijft voorwaarde, globale werking en veilige rollback. Laat debug alleen voor de reproduceerbare test actief en schakel het daarna uit.

Als webverkeer in de Log Viewer als geblokkeerd verschijnt, kan de oorzaak in meerdere modules liggen: Web Policy, SSL/TLS-inspectie, Application Control, IPS of WAF. Daarom altijd de specifieke module in de Log Viewer selecteren en daarnaast het passende logbestand controleren.

Sophos blokkeert websites van de categorie highly objectionable criminal activity standaard en verbergt de domeinnaam in logs en rapporten. Als een vermelding in dit gebied bewust geanonimiseerd lijkt, kan dit dus opzettelijk zijn.

Voor webcategorieën, URL-groepen, Web Policies en Instant Alerts past Sophos Firewall Web-categorieën en Instant Alerts gebruiken.

VPN

  • IPsec vanaf SFOS v17+: services strongswan, charon; logbestanden strongswan.log, charon.log.
  • IPsec verbindingsspecifiek: afzonderlijke IPsec Connection, logbestand /log/ipsec_conn/ipsec_<connectionname>.log.
  • IPsec oudere versies: context IPsec Service, logbestand ipsec.log.
  • IPsec Monitoring: context IPsec Monitor, logbestand ipsec_monitor.log.
  • XFRM / route-based VPN: service xfrmi, logbestand xfrmi.log.
  • SSL VPN: context SSL VPN / OpenVPN, logbestand sslvpn.log.
  • SSL VPN Status: context OpenVPN Status, logbestand openvpn-status*.log.
  • VPN Portal: context VPN Portal, logbestand vpnportal.log.
  • L2TP: service l2tpd, logbestand l2tpd.log. L2TP Remote Access op Sophos Firewall beschrijft configuratie en diagnose.
  • PPTP: context PPTP VPN, logbestand pptpvpn.log.
  • VPN-certificaten: context VPN Certificate Services, logbestand vpncertificate.log.
  • Clientless SSL VPN: context Clientless Access, logbestand clientless_access.log.

Sophos Firewall gebruikt strongSwan voor IPsec VPN en OpenVPN voor SSL VPN. Bij IPsec-problemen zijn tijd, peer-IP, Proposal, lokale en externe subnetten, NAT-T, routering en firewallregels cruciaal.

Voor IPsec-problemen is het artikel Sophos Firewall IPsec Troubleshooting de betere stapsgewijze handleiding. Als het gaat om route-based VPN en handmatige IPsec-routes, helpt IPsec Route op Sophos Firewall maken.

Authenticatie, User Portal en SSO

  • Gebruikersauthenticatie: context Access Server / AAA, logbestand access_server.log.
  • NTLM / NASM: service nasm, logbestand nasm.log.
  • Chromebook SSO: context Chromebook SSO Backend, logbestand chromebook-sso-backend.log.
  • OAuth SSO Captive Portal (SFOS 22): context OAuth SSO Captive Portal, logbestand oauth_sso_captive.log.
  • OAuth SSO WebAdmin (SFOS 22): context OAuth SSO WebAdmin, logbestand oauth_sso_webadmin.log.
  • OAuth SSO VPN (SFOS 22): context OAuth SSO VPN, logbestand oauth_sso_vpn.log.
  • OAuth SSO (SFOS 23): oauth_sso_svc.log voor SSO-aanmeldingen bij WebAdmin, Captive Portal, VPN Portal, IPsec VPN en SSL VPN.
  • RADIUS SSO: Gebruiker-IP-koppeling via accounting in access_server.log. RADIUS SSO met accounting legt configuratie en validatie uit.
  • STAS: context STAS / Access Server; afhankelijk van de dienstcontext ook access_server.log controleren.

Bij gebruikersregels altijd eerst controleren of de gebruiker bekend is. Als Match known users actief is en de authenticatie niet werkt, matcht de regel niet. Voor klassieke browseraanmeldingen combineert Sophos Firewall Captive Portal instellen en testen Device Access, de gebruikersregel, Live users, Log Viewer en access_server.log tot één volledige controleprocedure.

Als nog onduidelijk is of de serviceselectie, identiteit, hoofdgroep, quota of pas het verdere verkeerstraject mislukt, brengt Authenticatiefouten op Sophos Firewall systematisch oplossen deze lagen samen in één diagnoseprocedure.

Als Captive Portal met Microsoft Entra ID SSO wordt gebruikt, helpt Microsoft Entra ID SSO voor Sophos Firewall Captive Portal instellen bij het afstemmen van oauth_sso_captive.log (SFOS 22; in SFOS 23: oauth_sso_svc.log), Device Access, groepen en de latere regeltoewijzing.

DNS, DHCP en Netwerk

  • DNS Service: service dnsd, logbestand dnsd.log.
  • DNS Grabber: service dnsgrabber, logbestand dnsgrabber.log.
  • DNS Entity / andere DNS-componenten: services entity, eacd; logbestanden entity.log, eacd.log.
  • DHCP IPv4: service dhcpd, logbestand dhcpd.log.
  • DHCP IPv6: context DHCPv6, logbestand dhcpd6.log.
  • Netwerkdienst: service networkd, logbestand networkd.log.
  • FQDN Hosts: service fqdnd, logbestand fqdnd.log.
  • Dead Gateway Detection: service dgd, logbestand dgd.log.
  • Dynamic DNS: context Dynamic DNS Client, logbestand ddc.log.
  • NTP Client: context NTP Client, logbestand ntpclient.log.
  • IPv6 Router Advertisement: service radvd, logbestand radvd.log.

DNS- en DHCP-problemen lijken vaak op firewallproblemen. Daarom moeten eerst IP-adres, gateway, DNS-server en de vraag worden gecontroleerd of clients de firewall als DNS- of DHCP-server moeten gebruiken.

Als interne domeinen niet correct worden opgelost, is meestal DNS request routes op Sophos Firewall configureren relevant. Voor DHCP-speciale opties is er het eigen artikel Sophos Firewall DHCP Options configureren.

Cellular WAN

  • WWAN / USB-modem: in- en uitpluggen van USB-apparaten in modemd.log controleren.
  • Modem-netwerkconfiguratie: modemgerelateerde interfaces en IP-configuratie in networkd.log controleren.
  • USB, modem en PPP: Syslog-meldingen over USB, modem en Point-to-Point Protocol in syslog.log controleren.

Bij problemen met Cellular WAN moet men daarnaast controleren of het modem wordt herkend, of PIN/SIM/APN correct zijn en of de firewall een passende gateway aanmaakt.

Routing

Bij routeringsproblemen daarnaast Routing > SD-WAN routes, Gateways en Packet Capture controleren. De Policy tester vervangt geen echte routeringstest.

Meer hierover: Routing-prioriteit op Sophos Firewall aanpassen.

GUI, CLI en Systeemtoegang

Voor WebAdmin, SSH, API en lokale managementdiensten staat de basislijst verder boven onder Systeem, beheer en basisdiensten. Als WebAdmin of SSH niet bereikbaar is, niet alleen apache.log, tomcat.log of sshd.log controleren. Lokale toegang wordt beheerd via Administration > Device access en Local Service ACL.

Meer hierover: SSH-verbinding met de Sophos Firewall maken.

Sophos Fusion, Heartbeat en Central Management

  • Sophos Central Management: context Central Management, logbestanden centralmanagement.log, sophos-central.log.
  • CSC: services csc, cschelper, csd; logbestanden csc.log, cschelper.log, csd.log.
  • Security Heartbeat: services heartbeatd, hbtrust; logbestanden heartbeatd.log, hbtrust.log.
  • Synchronized Application Control: gegevens die naar SophosLabs worden gestuurd in sac-feedback.log controleren.
  • SAC-databaseoptimalisatie (SFOS 22/23): sac-vacuum.log registreert de wekelijkse optimalisatie van de Synchronized Application Control-database; sac-feedback.log blijft het afzonderlijke log voor gegevens die naar SophosLabs worden gestuurd.
  • Heartbeat naar Central: services fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; de respectieve servicelogs controleren.
  • Central API Executor: service fwcm-api-executor, logbestand fwcm-api-executor.log.
  • Active Threat Response: context ATR; afhankelijk van versie en module controleren.

Bij problemen met Sophos Fusion eerst controleren of de firewall geregistreerd is, Central Services actief zijn en of DNS/HTTPS uitgaand werkt. Als een wijziging uit Sophos Fusion lokaal niet aankomt, moet men de Sophos Fusion Firewall Task Queue met de lokale logs vergelijken. Alleen een groene Sophos Fusion-status bewijst niet dat een concrete policy lokaal is verwerkt.

High Availability

  • HA-status en configuratie: context HA Application Log, logbestand applog.log.
  • HA Pair Service: service ha_pair, logbestand ha_pair.log.
  • HA Tunnel: service ha_tunnel, logbestand ha_tunnel.log.
  • Conntrack Sync: service ctsyncd, logbestand ctsyncd.log.
  • Msync: service msync, logbestand msync.log.
  • HA-opbouw en statuswijzigingen: ha.log.
  • Bestandssynchronisatie van geselecteerde diensten naar het Auxiliary-apparaat: filesync.log.

HA-logs en rapporten worden niet tussen de apparaten gesynchroniseerd. Elk knooppunt bewaart alleen gegevens voor verkeer dat het zelf heeft verwerkt. Controleer daarom Log Viewer en Diagnostics > Tools > Troubleshooting logs op elk betrokken apparaat. Voor troubleshooting-logs van het Auxiliary-apparaat meldt men zich rechtstreeks bij de CLI aan via het IP-adres of de FQDN van de beheerinterface. Sophos Central Firewall Reporting kan rapporten van beide apparaten combineren, maar vervangt geen knooppuntlokale troubleshooting-bestanden.

Mail en Anti-Spam

  • Antivirus: context AV Service, logbestand avd.log.
  • Antivirus Updates: context Up2Date AV, logbestand up2date_av.log.
  • Anti-Spam: service sasi, logbestand sasi.log.
  • Sandbox: service sandboxd, logbestand sandboxd.log.
  • SMTP MTA: service smtpd, logbestand smtpd_main.log.
  • SMTP-fouten: context smtpd Error/Panic/Reject, logbestanden smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
  • Legacy SMTP/S Proxy: services awarrensmtp, awarrenmta; logbestanden awarrensmtp.log, awarrenmta.log. Mail Protection in Legacy mode legt configuratie en end-to-endtest uit.
  • POP/IMAP Proxy: service warren, logbestand warren.log. POP3 en IMAP scannen op Sophos Firewall legt configuratie en end-to-endtest uit.

Bij mailproblemen altijd controleren of MTA Mode, Firewallregel, DNS, certificaten en providerbeperkingen overeenkomen. De procedure voor mailflow, spool, quarantaine en relay is beschreven in Sophos Firewall Mail Protection in MTA Mode instellen.

Sophos Firewall gebruikt Avira en Sophos Antivirus. De Anti-Spam-dienst start alleen als er een inkomend of uitgaand spambeleid aanwezig is. Deze afhankelijkheid is belangrijk als sasi.log leeg blijft of de Anti-Spam-service niet draait.

Draadloos, RED, Hotspot en andere diensten

  • Wireless Controller: service awed, logbestand awed.log.
  • Wireless Clients: communicatie tussen client en AP/APX in wc_remote.log controleren.
  • Hotspot: services hostapd, hotspotd; logbestanden hostapd.log, hotspotd.log.
  • RED: context RED Service, logbestand red.log. Afhankelijk van RED-type en -instantie kunnen ook red-<serial ID of RED>.log en red-<RED ID>.log verschijnen.
  • SNMP: service snmpd, logbestand snmpd.log.
  • Syslog Service: context Syslog, logbestand syslog.log.
  • Licensing: context Licensing Service, logbestand licensing.log.
  • Systeemupdates: service u2d, logbestand u2d.log.
  • VMware Tools: service vmtool, logbestand vmtool.log.

Bij licentie-, Air-Gap- of patroonproblemen zijn licensing.log en u2d.log de eerste technische aanspreekpunten. Voor de operationele procedure met licentiebestand, 180-dagenvenster en handmatige patroonupdates past Sophos Firewall Air-Gap-licentieverlening en patroonupdates beheren.

Database en Rapportage

  • Configuratiedatabase: context Config DB, logbestand postgres.log.
  • Postgres: service postgres, logbestand postgres.log.
  • Signatuurdatabase: service sigdb, logbestand sigdb.log.
  • Rapportagedatabase: context Report DB, logbestand reportdb.log.
  • Migratiedatabase: context Report Migration, logbestand reportmigration.log.
  • Configuratiemigratie (SFOS 22/23): logbestand migration.log; niet verwarren met reportmigration.log voor rapportmigratie.
  • Garner: service garner, logbestand garner.log.
  • iView: service iview, logbestand iview.log.

Als rapporten ontbreken, traag zijn of er opslagproblemen optreden, zijn rapportage- en databaselogs relevant. Daarnaast moet men controleren of rapporten lokaal worden opgeslagen of naar Sophos Fusion worden verzonden.

Andere actuele SFOS 22-logbestanden

De volgende bestanden zijn minder vaak nodig bij dagelijks verkeerstroubleshooting, maar behoren tot de actuele SFOS 22-toewijzing. Ze zijn per functie gegroepeerd, zodat uit een bestandsnaam niet te snel een oorzaak wordt afgeleid:

  • Audit, FIPS en supporttoegang: configuration-audit.log registreert de configuratiewijziging, beheerder en tijd; fips.log de start in FIPS-modus; uma.log de Support Access.
  • Logpipeline en lokaal gegevensonderhoud: syslog-ng.log toont de onderdrukking van opeenvolgende gebeurtenissen; reportdb_v9.log hoort bij de oude rapportdatabase. dbcleanup.log, readobject.log, fstrim.log en logrotate.log betreffen databaseopschoning, interne objectlezing, bestandssysteem-trimming en logrotatie.
  • ATR, NDR en FastPath: atr-service.log toont het starten en stoppen van de ATR-service. ndr.log en ndr_agent.log behandelen NDR-licentie, configuratie, agentstart en metadataverwerking; vfpdf.log geldt voor NDR-metadata op XGS 88/88w, 108/108w, 118/118w en 128/128w. setup_vf_dpdk.log registreert de FastPath-geheugeninitialisatie en geldt juist niet voor deze vier modelreeksen.
  • TLS en SSL VPN: httplogd.log toont niet-ontsleutelde HTTPS-verbindingen in het DPI-pad. peruser_cert_sslvpn.log registreert per gebruiker gegenereerde SSL VPN-certificaten; openvpn-status0.log, openvpn-status1.log en andere genummerde bestanden tonen actieve SSL VPN-verbindingen per proces.
  • Netwerk en HA: dhcprelay.log hoort bij DHCP Relay. ha.log toont succes of fout bij de HA-opbouw en statuswijzigingen; filesync.log de bestandssynchronisatie van geselecteerde diensten naar het Auxiliary-apparaat.
  • Central, implementatie en ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log, fwcm-updaterd.log en fwcm-frpcd.log behandelen naar Central verzonden zone- en interfacegegevens, verbinding, overgedragen configuratie en Fast Reverse Proxy. ssod.log bevat firmware- en Central-backupinformatie, zt.log en zerotouch.log Zero Touch-varianten, ztna-connector.log de lokale ZTNA Connector.
  • Backup, firmware, Air Gap en certificaten: interfacemapping.log registreert de interfacetoewijzing bij herstel, legacyconversion.log back-ups zonder Secure Storage Master Key en fwmgmt.log firmware-installatie en -beheer. u2d_airgap.log geldt voor Air Gap-updates, cps_messages.log voor hotfixfouten en letsencrypt.log samen met applog.log voor Let’s Encrypt-certificaten.
  • Hardware en systeemstatus: npu-startup.log, npu_syslog.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-npu-serial.log en xgs-pport-wait.log behandelen NPU-start, -communicatie, -firmware, seriële poort, gezondheid en het maken van fysieke interfaces. raid.log toont software-RAID, lcd.log het hardwaredisplay. system-monitor/cpu_trigger.log legt de systeemstatus bij hoge CPU-belasting vast; system-monitor/memory_trigger.log geldt in SFOS 22 voor hoge geheugenbelasting.
  • Cloud- en platformdiensten: iaasd.log registreert provisioning en licentiecontrole in Azure, waagent.log de Azure-agent en diens Health Monitoring; vmtool.log hoort bij VMware Tools.

De aanwezigheid van een bestand bewijst geen fout in die module. Breng eerst gebeurtenistijd, betrokken node, platform, dienststatus en een reproduceerbaar symptoom samen; zoek pas daarna met een beperkt filter in het juiste bestand.

Analyseverloop

  1. Probleem nauwkeurig noteren: tijd met tijdzone, client, doel, poort, gebruiker, actie.
  2. Beslissen of het om verkeer, dienststatus, een configuratiewijziging of Central-synchronisatie gaat.
  3. In de Log Viewer filteren op Source IP, Destination IP, module en tijd.
  4. Zichtbaarheid van Firewall Rule ID, NAT Rule ID, gebruiker, gateway en Policy IDs controleren.
  5. Packet Capture gebruiken als pakketstroom, retourweg of NAT-zicht onduidelijk is.
  6. Passend logbestand met tail -f, less of grep controleren.
  7. Probleem reproduceren en het exacte testtijdstip documenteren.
  8. Indien nodig Debug alleen voor de getroffen dienst en slechts kort activeren.
  9. Debug weer deactiveren en opslagruimte controleren.
  10. Logs veiligstellen zolang de fout vers is gereproduceerd.

Voor supportcases moet men bovendien alle foutmeldingen, reproductiestappen en reeds uitgevoerde probleemoplossingsstappen documenteren. Precies deze informatie versnelt de afhandeling aanzienlijk. De juiste procedure staat in Sophos-supportticket openen: voorbereiding en portal.

FAQ

Welk logbestand is bij Sophos Firewall het belangrijkst?

Dat hangt van het probleem af. Voor firewallregels is firewall_rule.log belangrijk, voor NAT nat_rule.log, voor IPsec strongswan.log, voor SSL VPN sslvpn.log, voor IPS en Application Control vaak ips.log. De Log Viewer blijft echter de beste eerste ingang voor afzonderlijke verbindingen.

Wat is CTR bij Sophos Firewall Logs?

CTR staat in veel Sophos-contexten voor Consolidated Troubleshooting Report. Voor beheerders is belangrijk: een CTR- of troubleshooting-logpakket helpt support, maar vervangt geen zuivere foutbeschrijving met tijd, getroffen IP’s, gebruiker, tunnelnaam, Rule ID en reproductiestappen.

Wanneer heeft men de Advanced Shell nodig?

De Advanced Shell is nuttig wanneer lokale logbestanden met tail, grep of less moeten worden gecontroleerd, een dienststatus wordt gecontroleerd of Sophos Support gedetailleerde loggegevens nodig heeft. Voor veel eerste controles volstaan Log Viewer, Policy Test en Packet Capture in WebAdmin.

Moet men Debug-Logging permanent actief laten?

Nee. Debug genereert veel gegevens en kan opslagruimte verbruiken. Debug moet alleen voor de getroffen dienst, voor een korte reproduceerbare test en met daaropvolgende deactivering worden gebruikt.

Waarom ziet men in de Log Viewer geen verwachte firewallgebeurtenissen?

Vaak is Log firewall traffic in de getroffen regel niet actief, is de verkeerde periode of het verkeerde filter gekozen, of bereikt het verkeer de firewall niet. Als de pakketstroom onduidelijk is, moet men Log Viewer en Packet Capture samen gebruiken.

Zijn lokale logs beter dan Central Reporting of Syslog?

Het zijn verschillende hulpmiddelen. Lokale logs helpen bij detailanalyse direct op de firewall. Central Reporting is geschikt voor Sophos-Central-rapporten en geschiedenis. Syslog is beter voor eigen SIEM-, SOC- of langetermijnopslag.