Sophos Firewall Service-Logs correct toewijzen

Bij de Sophos Firewall zijn er drie belangrijke niveaus voor troubleshooting: Event Logs 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 services en logbestanden naar typische admin-problemen. Het helpt ook wanneer in het dashboard, in de Advanced Shell of in een ondersteuningsgeval 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

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 welk 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 down 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, webproxy.log, awarrenhttp.log en Packet Capture vergelijken.
• Sophos Central 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 verschillend per node: actieve node, Auxiliary Node en getroffen traffic-pad bepalen. Daarna direct op de getroffen node aanmelden en HA-logs controleren.
• Lokale rapporten ontbreken of opslag loopt vol: rapportinstellingen, opslagruimte en Central Reporting controleren. Daarna reportdb.log, garner.log en opslaganalyse gebruiken.

Deze blik voorkomt een typische valkuil: men zoekt in een service-logbestand, terwijl eerst rule matching, Device Access, NAT of routing bewezen moet worden.

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.

Probleemoplossingslogs bevinden zich op de firewall in de map /log. Toegang verkrijgt men via de WebAdmin-console of via SSH. Voor korte controles werkt Device Management > Advanced Shell in de browser, maar in de praktijk is SSH meestal prettiger, stabieler en beter voor langere tail, grep of less sessies. Hoe men SSH veilig voorbereidt, staat in de handleiding 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:

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. Verbinden via SSH of in de WebAdmin-console Device Management > Advanced Shell openen.
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:

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 per tar uit de Advanced Shell te worden gebouwd. Voor supportcases is er in WebAdmin daarnaast Diagnostics > Tools > Log file details of de Troubleshooting-logselectie. Daar kunnen logbestanden per module worden geselecteerd en gedownload.

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 beheerder geen langere shellsessie wil openen of wanneer alleen een duidelijk afgebakend logpakket nodig is. De CTR is beter wanneer Sophos Support een brede systeemsnapshot nodig heeft. Geef bij het maken van een CTR een korte en duidelijke reden op, bijvoorbeeld ticketnummer, tijdvenster of symptoom. Het rapport wordt versleuteld gedownload en bevat bij service-subsystemlogs standaard maar een beperkt aantal logregels. Volledige afzonderlijke logbestanden zijn betrouwbaarder beschikbaar via Troubleshooting logs of direct uit /log.

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. Elke node bevat de logs voor het verkeer en de diensten die hij zelf heeft verwerkt. Bij node-specifieke fouten moet daarom de betrokken node worden gecontroleerd.

Advanced Shell of Device Console?

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

Niet elk commando werkt in beide gebieden. Als een artikel uitdrukkelijk Device Console vermeldt, moet het commando daar worden uitgevoerd. Als het gaat om /log, tail -f, grep, service -S of Debug-Logging, wordt meestal de Advanced Shell bedoeld.

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 Central 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 Central is Central Firewall Reporting activeren de juiste procedure.

Debug alleen gericht activeren

Debug-Logging is zeer nuttig, maar genereert veel gegevens en kan opslagruimte verbruiken. Debug moet alleen voor de relevante dienst worden geactiveerd. Daarna reproduceert men het probleem en deactiveert Debug weer.

Voorbeeld:

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

De exacte syntaxis hangt af van de dienst. Als de getroffen dienst onduidelijk is, moet eerst het passende normale logbestand worden gecontroleerd.

Sophos onderscheidt hierbij twee bedieningspaden. In de Advanced Shell worden servicecommando’s zoals service ips:debug -ds nosync gebruikt. In de Device Console bestaan daarnaast de commando’s system diagnostics subsystems <subsystem> debug on en system diagnostics subsystems <subsystem> debug off voor ondersteunde subsystemen. Deze varianten mogen niet worden gemengd: eerst vaststellen in welke console wordt gewerkt, daarna het passende commando gebruiken.

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.

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.

System, Management en basisdiensten

• Systeemmeldingen: syslog.log; daarnaast tijd, reboot en interface-events controleren.
• WebAdmin Webserver: apache.log, apache_access.log; daarnaast Device Access en Local Service ACL controleren.
• WebAdmin applicatie: tomcat.log; daarnaast GUI-fouten, hoge load en servicestatus controleren.
• SSH: sshd.log; daarnaast Device Access, Source-netwerk en Public-Key-login controleren.
• GUI/CLI-fouten: error_log.log; daarnaast actuele wijziging, browser en adminactie controleren.
• Configuratiewijzigingen: applog.log, csc.log; daarnaast Audit Trail en Config Studio controleren.
• Configuratiedatabase: postgres.log; daarnaast opslagruimte, backup/restore en supportcase controleren.
• Communicatie tussen componenten: garner.log; daarnaast reporting, Central Reporting en logverwerking controleren.
• API: apiparser.log, app-feedback.log; daarnaast 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, sig_update.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

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

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

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 het 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

Sophos Firewall gebruikt strongSwan voor IPsec VPN en OpenVPN voor SSL VPN. Bij IPsec-problemen zijn tijd, peer-IP, voorstel, lokale/remote 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

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.

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, Device Access, groepen en later regel-matching.

DNS, DHCP en Netwerk

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

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 passend 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 basistabel verder boven onder System, Management 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 Central, Heartbeat en Central Management

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

High Availability

HA-logs bevinden zich op het apparaat waarop ze zijn gegenereerd. Voor ruwe logs van het Auxiliary-apparaat moet men zich direct op dit apparaat verbinden, bijvoorbeeld via de Admin-poort per SSH. Voor geconsolideerde rapporten is Sophos Central Firewall Reporting praktischer.

Mail en Anti-Spam

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

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

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 Central worden verzonden.

Analyseverloop

1. Probleem nauwkeurig noteren: tijd met tijdzone, client, doel, poort, gebruiker, actie.
2. Beslissen of het om traffic, dienststatus, 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 ondersteuningsgevallen moet men bovendien alle foutmeldingen, reproductiestappen en reeds uitgevoerde probleemoplossingsstappen documenteren. Precies deze informatie versnelt ondersteuningsgevallen aanzienlijk. De juiste procedure staat in Sophos Supportticket openen: Voorbereiding en Portal.

FAQ