Sophos Firewall Log Viewer correct gebruiken

In SFOS 22 is Log Viewer vaak het snelste startpunt bij een storing: Welke firewallregel verwerkte het verkeer, welke NAT-regel was betrokken, welke gebruiker werd herkend en welke securitymodule blokkeerde? Voor het juiste antwoord moeten module, tijdvak, filters en moment van de logregel bij elkaar passen.

Log Viewer toont gelogde gebeurtenissen. Het is geen Packet Capture en geen volledige verbindingsgeschiedenis. Een ontbrekende regel bewijst daarom noch een drop, noch dat het pakket de firewall heeft bereikt.

Noteer voor een betrouwbare analyse altijd Source, Destination, service, exact testtijdstip en verwachte richting. Genereer daarna precies één nieuwe testflow en zoek die in de relevante modules.

Een test in zeven stappen beoordelen

1. Controleer Log firewall traffic in de betrokken firewallregel of Log connections in de SSL/TLS-regel.
2. Controleer onder System services > Log settings of het vereiste logtype bij Local reporting is ingeschakeld.
3. Open rechtsboven in WebAdmin Log viewer (SFOS 22) of Logs and policy test (SFOS 23) en kies daarna de passende logmodule.
4. Stel het tijdfilter in en beperk via Add filter eerst op Source-IP, Destination-IP en service.
5. Genereer een nieuwe, korte testflow en noteer de exacte tijd.
6. Controleer in Detailed view Rule ID, NAT ID, action, interfaces, gebruiker en modulespecifieke velden.
7. Als de regel en het waargenomen gedrag niet overeenkomen, correleer dezelfde test dan met Packet Capture voordat een regel wordt gewijzigd.

Deze volgorde scheidt drie vaak vermengde vragen: Is er überhaupt een log gemaakt? Welke policy heeft beslist? En zijn de pakketten werkelijk binnengekomen en weer uitgegaan?

Event Logs registreren naast verkeer ook authenticatie, systeemgebeurtenissen en configuratiewijzigingen en worden standaard lokaal opgeslagen. Troubleshooting Logs zijn gedetailleerde servicelogs die via WebAdmin of de CLI worden geraadpleegd. De servicelogprocedure legt toegang en debugregistratie uit. Debug gebruikt extra schijfruimte en moet na het verzamelen van de benodigde gegevens worden uitgeschakeld; het is geen schakelaar voor ontbrekende Event Logs.

Voor centrale verzending moet de firewall geregistreerd zijn voor Sophos Central Firewall Management. Schakel daarna Central-services en Send reports and logs to Sophos Central in en selecteer de vereiste logtypen onder System services > Log settings. De beoordeelde SFOS 22-documentatie noemt het doel Sophos Fusion, de SFOS 23-documentatie Sophos Central; volg de genoemde UI-velden. De Central Reporting-procedure behandelt inrichting en ontvangstcontrole.

Logregels correct lezen

Waarom logregels niet altijd direct verschijnen

Log Viewer werkt de weergave automatisch bij. Een firewallsessie wordt echter normaal pas gelogd wanneer de firewall een Destroy-event ontvangt en de verbinding sluit. Bij een lange sessie kan de regel dus later verschijnen dan het eerste verzoek.

Eindigt een verbinding zonder dat de firewall een Destroy-event ontvangt, bijvoorbeeld bij het wegvallen van de internetverbinding, dan kan de verwachte sessielog volledig ontbreken. SSL/TLS-verbindingen worden na een geslaagde handshake en bij het sluiten gelogd. Voor een korte test is een bewust afgesloten verbinding daarom beter dan een permanent open browser-, streaming- of HTTP/2-sessie.

Een browserrefresh maakt niet noodzakelijk een nieuwe verbinding. Afhankelijk van de toepassing zijn een privévenster, een opnieuw gestart clientproces of een korte opdracht zoals deze geschikt voor een reproduceerbare test:

curl -I https://example.com/

Voer de opdracht uit op de testclient, niet in de shell van de firewall. example.com is een gereserveerd voorbeelddomein en kan door een bekende, toegestane service worden vervangen.

De juiste module kiezen

Een datastroom kan meerdere logmodules raken. De module Firewall kan bijvoorbeeld tonen dat een LAN-to-WAN-regel de verbinding toestaat, terwijl Web filter, Application filter, IPS of SSL/TLS inspection dezelfde flow later blokkeert of anders behandelt.

Eén groene firewallregel is daarom niet voldoende bij web- of securityproblemen. Correleer de modules voor dezelfde testflow aan de hand van de testperiode en adressen:

• Firewall: Regelbeslissing, NAT, interfaces, poorten en basisstatus van de verbinding.
• Web filter: URL-, categorie- en Web Policy-beslissingen.
• SSL/TLS inspection: Certificaat-, handshake- en decryptionbeslissingen.
• Application filter: Herkende toepassing en actie van Application Control.
• IPS: Signatuur- of anomaliegebeurtenissen.
• VPN: Opbouw en status van de betreffende VPN-component.
• Authentication: Herkende gebruiker en geslaagde of mislukte aanmelding.
• System: Systeemgebeurtenissen en door administrators geïnitieerde gebeurtenissen.
• SD-WAN: Gebruik van SD-WAN-profiel, SLA en route.

Welke logtypen lokaal verschijnen, wordt onder System services > Log settings bij Local reporting ingesteld. Deze Event Logs zijn niet hetzelfde als On-box Reports. Central reporting en syslog zijn afzonderlijke doelen en moeten apart worden ingeschakeld. Voor Web Policy-events moet bovendien Log firewall traffic in de gekoppelde firewallregel zijn ingeschakeld. Wireless-logs zijn niet beschikbaar in Log Viewer; stuur ze naar Sophos Fusion (voorheen Sophos Central) of een syslogserver.

Grens van de Web Proxy: De SFOS 22/23-documentatie over loggedrag beschrijft dit proxypad voor HTTP/HTTPS op poort 80 en 443: een overeenkomende Drop-regel geeft binnenkomende pakketten door aan de Web Proxy, die de gebruiker een blokkeerpagina stuurt; zonder overeenkomende Web Exception toont de Firewall-log Allowed en de Web filter-log Blocked. Web Exceptions blijven gelden en kunnen requests ondanks Drop toestaan. Het gedocumenteerde Reject-pad beëindigt de flow vóór verwerking door de proxy. Controleer firewallregel, Web Policy en Web Exceptions samen; dit is een gedocumenteerd scenario, geen universele garantie op een blokkeerpagina voor elke build of inspectiemodus.

Onopgelost documentatieconflict: De SFOS 22/23-hulp bij het regelformulier beschrijft authenticatie van onbekende webgebruikers als Use web authentication for unknown users is ingeschakeld, staat overeenkomende Web Exceptions toe en beschrijft anders een HTML-blokkeerpagina. De handleiding voor logging van verworpen verkeer beschrijft daarentegen stilzwijgend verwerpen en koppelt de webblokkeerpagina aan die authenticatieoptie. Leid hieruit niet af dat alleen deze optie de reactie bepaalt. Vraag voordat u voor webblokkering op Drop vertrouwt om schriftelijke verduidelijking van Sophos voor de exacte versie, build en het verwerkingspad, of voer expliciet geautoriseerde, geïsoleerde verificatie uit. Leg de huidige regel en instellingen vast voor rollback; controleer HTTP en HTTPS apart, bekende/onbekende gebruikers, authenticatie aan/uit en overeenkomende uitzonderingen aanwezig/afwezig. Correleer nieuwe flows met Rule ID, logs, Packet Capture en browserresultaten. Noch een blokkeerpagina noch een timeout bewijst op zichzelf blokkering. Draai bij onverwachte toegang of onduidelijke resultaten testwijzigingen terug en escaleer; rol niet uit naar productie.

Op andere poorten dan 80 en 443 verwerpt een overeenkomende Drop-regel pakketten rechtstreeks; de Firewall-log toont dropped. Bij Reject toont de Firewall-log rejected, zowel op 80/443 als op andere poorten. Deze waarnemingen vereisen Log firewall traffic in de overeenkomende regel. Een Web Exception kan bijvoorbeeld Windows-updates van Microsoft ondanks een Drop-regel toestaan; dat is geen reden om de regel zonder onderzoek te verruimen.

Allow-regel en ontbrekende heartbeat

Een ander geval dan Drop ontstaat wanneer de firewallregel die daadwerkelijk overeenkomt Action Allow heeft, Block clients with no Heartbeat is ingeschakeld en het endpoint geen heartbeat stuurt. Voor de hier beschreven logwaarnemingen moet Log firewall traffic in die regel zijn ingeschakeld. Controleer vóór het zoeken ook de benodigde logtypen onder System services > Log settings > Local reporting; alleen een extern logdoel inschakelen is niet voldoende voor de lokale weergave.

• Andere poorten dan 80 en 443: De firewall verwerpt de pakketten van dit endpoint. De Firewall-log toont dropped.
• Poorten 80 en 443 in het gedocumenteerde Web Proxy-pad: De firewall accepteert de binnenkomende pakketten en geeft ze door aan de Web Proxy. Omdat het endpoint geen heartbeat stuurt, besluit het heartbeat-systeem te blokkeren; de proxy stuurt de gebruiker een blokkeerpagina. De Firewall-log toont allowed, een andere Firewall-log toont Heartbeat blocked en de Web filter-log toont blocked. Heartbeat blocked hoort hier dus ook bij de Firewall-module, niet bij een afzonderlijke heartbeat-logmodule.

Allowed alleen bewijst geen geslaagde toegang. Correleer vóór een regelwijziging de vermeldingen van dezelfde testflow: controleer testperiode, source, destination, poorten en overeenkomende regel samen. Zoek naar de afzonderlijke Heartbeat blocked-vermelding en de Web filter-vermelding met blocked. Een vaste gebeurtenisvolgorde, identieke tijdstempels of een universeel aantal logregels is niet vereist; ontbreken verwachte vermeldingen, controleer dan eerst logging, lokale doelen en filters en gebruik zo nodig Packet Capture.

Deze uitleg geldt voor precies deze regeloptie, een endpoint zonder heartbeat en het beschreven proxypad. Het is geen algemene uitspraak over alle Allow-regels, rode of anderszins ongezonde endpoints of andere inspectiemodi. Schakel heartbeat-handhaving niet uit als algemene oplossing; stel eerst de regelmatch en de oorzaak van de ontbrekende heartbeat vast.

Standard view en Detailed view onderscheiden

Standard view is geschikt voor snel lezen. Kolommen kunnen worden toegevoegd of verwijderd en een klik op een waarde kan die direct als filter gebruiken. Voor technische acceptatie is Detailed view belangrijker, omdat die onderliggende veldnamen en extra waarden toont.

Een belangrijk NAT-detail: Als een andere vertaalde Source-adres dan het standaard MASQ-adres wordt gebruikt, kan Standard view toch het MASQ-adres als uitgaand adres tonen. De werkelijk vertaalde Source staat in Detailed view in src_trans_ip.

In Standard view toont ook het aanwijzen van een module-icoon met de muis extra details. De kopieerfunctie plaatst loginformatie op het klembord. De viewer opent in een nieuw schermvullend browservenster; verschijnt het niet, controleer dan eerst de popupblokkering van de browser.

Typische velden voor een firewalltest zijn:

• Source- en Destination-IP plus Source- en Destination-poort
• In interface en Out interface
• Firewall Rule ID en NAT Rule ID
• Action of status
• Gebruikersnaam, als een identiteit is herkend
• Vertaalde Source en Destination
• Log component en Log subtype

Een veldnaam of ID verklaart de oorzaak niet automatisch. Vergelijk Rule ID met de huidige regelbasis, NAT ID met de betreffende NAT-regel en een securitypolicy-ID met de bijbehorende module.

Als onder Diagnostics > Packet capture tegelijkertijd een Packet Capture actief is, kan Open PCAP bij de passende logvermelding de bijbehorende pakketinformatie openen. Zo wordt de vastgelegde beslissing aan de pakketdetails gekoppeld, maar dit vervangt geen nauw afgebakend capturefilter: source, destination, poort en testtijd moeten nog steeds bij de onderzochte flow passen.

De juiste flow isoleren

Filters instellen tot alleen de juiste flow overblijft

Log Viewer biedt vier filterniveaus:

1. Module: beperkt de weergave tot Firewall, Web, IPS, VPN of een ander gebied.
2. Time / Timer filter: beperkt gebeurtenissen tot de testperiode; klik op Timer filter en kies een tijdoptie.
3. Add filter: combineert een specifiek veld, een voorwaarde en een waarde.
4. Free text search: zoekt bijvoorbeeld naar poorten, IP-adressen, gebruikers of regelnamen en werkt ook met geanonimiseerde informatie.

Begin voor een normale verbindingstest met Source-IP, Destination-IP en Destination-poort. Verfijn daarna met Rule ID, gebruiker of action. Reset verwijdert alle filters. Dit is belangrijk, omdat een oud tijd- of veldfilter eenvoudig de indruk kan wekken dat de viewer geen nieuwe gebeurtenissen ontvangt.

Het aantal beschikbare regels hangt af van schijfgrootte en lokale bewaartermijn. Log Viewer is daarom geen vervanging voor langdurige, manipulatiebestendige opslag. Daarvoor passen Central Firewall Reporting of Syslog naar een SIEM sturen.

Het lokale Event Log-quotum hangt af van het appliancemodel: voor grotere modellen noemt Sophos maximaal 15 procent van de hele /var-partitie of 50 procent van de vrije ruimte daarin, afhankelijk van welke waarde lager is. Dit is geen gegarandeerde bewaartermijn en geen quotum voor elk model. De opslaganalyse onderscheidt Event Logs, rapporten en Troubleshooting Logs; verwijder bestanden niet op goed geluk.

Pause, Refresh en CSV-export correct gebruiken

Pause stopt de automatische vernieuwing van de weergave. Dat is handig om een regel rustig te lezen of te kopiëren. Het stopt de logging op de firewall niet. Refresh laadt de weergave handmatig opnieuw en Export downloadt de momenteel beschikbare logs als CSV.

Documenteer vóór een export de module, het tijdvak en de filters. De CSV kan interne IP-adressen, gebruikersnamen, URL’s en communicatierelaties bevatten en hoort daarom in een beschermd support- of analyseproces.

Wanneer Data anonymization actief is, worden identificerende waarden zoals gebruikersnaam, IP-, MAC- en e-mailadres beschermd weergegeven. Sophos adviseert minimaal twee Authorizers: als de aangemelde administrator er zelf een is, moet minstens één andere bevoegde persoon de deanonimisering goedkeuren. Een screenshot of export mag toch alleen de regels bevatten die voor de case nodig zijn.

Om identiteiten via de deanonimiseringsfunctie te tonen, moet je bevoegd zijn en je authenticatiegegevens invoeren. Een regel kopiëren vervangt deze autorisatie niet.

Log suppression en Log occurrence begrijpen

Onder System services > Log settings kan de firewall opeenvolgende identieke firewallevents onderdrukken. Dit bespaart opslag en verwerking. Onderdrukking geldt niet alleen lokaal, maar ook voor Sophos Fusion en geconfigureerde syslogdoelen.

In Log Viewer toont Log occurrence hoe vaak een samengevat event optrad. Eén regel kan dus veel herhalingen vertegenwoordigen. Die mag niet automatisch als één pakket of één verbinding worden geteld.

Controleer vóór een wijziging van Log suppression of het huidige logvolume echt een probleem veroorzaakt. Voor een korte diagnose volstaat meestal het bewust lezen van Log occurrence. Een globale wijziging beïnvloedt ook externe logdoelen en hoort niet alleen voor een screenshot te worden uitgevoerd.

Bevindingen veilig interpreteren

Invalid traffic correct interpreteren

Invalid traffic betekent dat conntrack een pakket niet aan een actuele verbinding kon koppelen. Dit kan optreden bij een asymmetrisch pad, een verlopen sessie, onverwachte TCP-flags of extra RST- en FIN-pakketten. Het is niet automatisch een aanval of een firewallfout.

Als tegelijk een verbindingsprobleem bestaat, leg dan beide richtingen vast met Packet Capture. Source, Destination, TCP-flags, interfaces en tijdstippen moeten bij dezelfde flow horen. Een hogere Tcp Connection Establishment Idle Timeout kan het aantal van deze logs verminderen, maar verhelpt de onderliggende pad- of sessieoorzaak niet. Wijzig de waarde niet op goed geluk.

Invalid traffic-logging is standaard ingeschakeld. Conntrack volgt TCP-sessies en bepaalde UDP- en ICMP-sessies; initiërende pakketten zoals TCP SYN of een ICMP Echo Request leggen de koppeling met de verbinding vast. TCP-flags betekenen het volgende:

• SYN: vraagt om synchronisatie.
• SYN-ACK: bevestigt die en spreekt verbindingsparameters af.
• ACK: bevestigt de afspraak; gegevensoverdracht kan beginnen.
• PSH: vraagt om onmiddellijke gegevensaflevering.
• FIN: vraagt om een ordelijk einde; beide kanten bevestigen de afsluiting.
• RST: beëindigt de verbinding zonder op antwoord te wachten, bijvoorbeeld na een onverwacht pakket.

Extra RST- en FIN-pakketten kunnen worden verworpen en als Invalid traffic gelogd. Koppel een afzonderlijke vermelding aan het werkelijke verbindingsprobleem in plaats van die als een aparte aanval te behandelen.

De alleen-lezen opdracht show advanced-firewall in de Device Console toont de huidige globale waarde; Sophos documenteert 10800 seconden, oftewel drie uur, als standaard. Een wijziging beïnvloedt alle overeenkomstige TCP-sessies op de firewall. Breng daarom eerst de betrokken toepassing, de werkelijke inactiviteitsduur en de Invalid traffic-gebeurtenis eenduidig met elkaar in verband. Een hogere timeout is alleen een gemotiveerde operationele aanpassing en geen oplossing voor asymmetrische routing of pakketverlies.

De volledige dropanalyse met Reason, Rule ID en de bijzondere Firewall ID 0 staat in Verworpen pakketten op Sophos Firewall analyseren.

De bron noemt het veld Tcp Connection Establishment Idle Timeout, maar beschrijft conntrack-vermeldingen die na inactiviteit verlopen en gebruikt de setter tcp-est-idle-timeout. Die naamgeving is dubbelzinnig; ze bewijst geen aparte handshake-timeout. Controleer de werkelijke uitvoer en CLI-hulp van je eigen build.

De CLI-referentie voor SFOS 22/23 koppelt tcp-est-idle-timeout expliciet aan reeds tot stand gebrachte TCP-verbindingen en staat 2700 tot 432000 seconden toe. De afwijkende veldnaam wordt daarom niet gebruikt als advies om een timeout voor het opbouwen van verbindingen te wijzigen.

Alleen als een bevestigd idle-timeoutgeval een globale aanpassing rechtvaardigt, kies je 4. Device Console in de CLI, leg je de bestaande waarde vast met show advanced-firewall en plan je een onderhoudsvenster. Het gedocumenteerde voorbeeld verhoogt de waarde naar zes uur; dit is geen algemeen aanbevolen waarde:

set advanced-firewall tcp-est-idle-timeout 21600
show advanced-firewall

Controleer de nieuwe waarde en test dezelfde toepassing opnieuw over de relevante inactieve periode. Minder Invalid traffic-vermeldingen bewijzen op zichzelf geen herstel. Gebruik voor terugdraaien dezelfde setter met het eerder vastgelegde aantal seconden en controleer opnieuw met show advanced-firewall; 10800 past alleen als dat de oorspronkelijke waarde was. Is de CLI-uitvoer onduidelijk of blijft het probleem bestaan, stop dan met aanpassen en onderzoek het pakketpad of schakel support in. Deze procedure is aan de documentatie getoetst, niet op een firewall getest.

Regels vanuit Log Viewer alleen gecontroleerd wijzigen

Afhankelijk van het event kan Log Viewer rechtstreeks Web Policies, NAT-, firewall- of SSL/TLS-regels openen. Een klik op een Web Policy, NAT-regel of firewallregel biedt een link naar de editor in WebAdmin. Dat is handig, maar verkort de technische controle niet. Controleer vóór bewerking Rule ID, naam, positie, zones, objecten, service, gebruikersmatch en bestaande sessies; leg ook de huidige waarden van de te wijzigen velden vast, zodat ze kunnen worden hersteld.

Voor een SSL/TLS-uitzondering selecteer je SSL/TLS inspection, scroll je naar Manage, kies je Exclude, controleer je de optie in het dialoogvenster en bevestig je pas daarna met Exclude. Domain en Subdomain worden toegevoegd aan de URL-groep Local TLS exclusion list, zichtbaar onder Categories and websites in SSL/TLS-regels. Web category komt in Exclusions by website or category, zichtbaar op de lijstpagina met SSL/TLS-regels. Voor Other properties selecteer je de SSL/TLS-regel en passende objecten, zoals gebruikersnamen of IP-adressen. Controleer doelobject en reikwijdte vóór bevestiging; een domeinuitsluiting is niet gelijk aan een uitzondering voor slechts één gebruiker. Log Viewer biedt Exclude niet aan voor 19004 (toegestaan verkeer) of 19005 (geblokkeerd door een Web Policy).

Een klik op een IPS Signature ID kan Disable signature for this IPS policy aanbieden. Dit wijzigt de actieve IPS Policy en niet alleen de weergave. Documenteer eerst de betrokken regel, policy, signature, invloed op de bescherming en reikwijdte van de uitzondering en test daarna exact de bevestigde flow opnieuw.

Een brede Allow-regel, globale webuitzondering of uitgeschakelde TLS inspection kan het symptoom verbergen en tegelijk een nieuw securitylek maken. Beperk wijzigingen tot de bevestigde flow, test ze in een onderhoudsvenster en valideer daarna een nieuwe flow opnieuw in Log Viewer en zo nodig Packet Capture. Mislukt de test of blijkt de uitzondering te ruim, herstel dan de eerder vastgelegde toestand in het gekoppelde regel- of policyobject en test opnieuw met een nieuwe flow.

Als logs ontbreken of op het andere HA-knooppunt staan

Als verwachte logs ontbreken

Controleer een lege zoekopdracht in deze volgorde:

1. Controleer Pause, module, tijdvak en filters en gebruik daarna Reset en Refresh.
2. Controleer rule logging en Local reporting voor het benodigde logtype.
3. Maak een nieuwe, bewust afgesloten verbinding met een bekend tijdstip.
4. Bevestig met Packet Capture dat het verkeer de firewall bereikt en welke Rule ID het verwerkt.
5. Controleer andere modules op gebeurtenissen van dezelfde flow.
6. Onderzoek pas het viewer- of loggingservicepad als de volledige lokale weergave geen nieuwe gebeurtenissen ontvangt.

De versiespecifieke diagnose voor een volledig stilstaande viewer staat in Log Viewer toont geen nieuwe logs. Een servicerestart of ingreep in de lokale logdatabase hoort niet bij normale bediening.

Log Viewer in HA-omgevingen

Elke HA-node bewaart alleen de logs en rapporten van verkeer dat hij zelf heeft verwerkt. Vooral in active-active of na een failover kan de verwachte regel daarom op de andere node staan. Documenteer tijdstip, noderol en Connection served by samen.

Central Firewall Reporting of syslog kunnen een centrale weergave bieden. Ze vervangen de nodegerichte controle niet bij onderzoek naar een specifieke HA-rolwisseling, lokale servicefout of het datapad op het moment van het event.