Sophos Firewall Syslog veilig naar een SIEM sturen

Met Syslog verstuurt een Sophos Firewall gebeurtenissen naar een externe logserver, SIEM of SOC. Om de integratie echt bruikbaar te maken, moeten vier zaken op elkaar aansluiten: transport, logselectie, indeling en parser. Dit artikel begint daarom direct met de configuratie en laat vervolgens zien hoe ontbrekende of verkeerd geïnterpreteerde logs worden herkend.

De lokale Log viewer blijft belangrijk voor live-analyse. Central Firewall Reporting is geschikt voor rapporten in Sophos Central; Syslog is de juiste keuze voor eigen opslag, correlatie tussen verschillende leveranciers en SIEM-detectie.

De Syslog-server configureren

Vooraf moeten het doel-IP-adres of de FQDN, de poort, het transport, de verwachte logindeling en een geschikte parser vaststaan. De firewall heeft een route naar de collector nodig en beide systemen een correct werkende tijdbron. UDP 514 is gebruikelijk; bij TLS wordt vaak TCP 6514 gebruikt, maar de configuratie van de collector is bepalend.

Open System services > Log settings.
Selecteer Add.
Voer een eenduidige naam in, zoals siem-primary.
Voer de collector in onder IP address/domain.
Selecteer Port, Facility, Severity level en Format passend bij het doelsysteem.
Activeer Secure log transmission als de TLS-collector is voorbereid.
Sla de configuratie op.
Activeer onder Log settings de gewenste logtypen in de kolom van deze Syslog-server.

SFOS ondersteunt maximaal vijf externe Syslog-servers. Meerdere doelen zijn nuttig als ze verschillende taken hebben, zoals een lokaal archief en een MDR-collector. Alle logs zonder onderscheid naar elk doel sturen verhoogt daarentegen het volume, de kosten en het privacyrisico.

Facility, Severity en indeling

Facility: LOCAL0 tot en met LOCAL7 kunnen firewalls of locatiegroepen onderscheiden. De toewijzing moet in de collector en de documentatie identiek zijn.
Severity level: De selectie is de minimale ernst. Error verstuurt ook Critical, Alert en Emergency, maar geen Information- of Notice-gebeurtenissen. Hierdoor kunnen aanmeldingen en normale operationele gebeurtenissen ontbreken.
Format: De beschikbare opties zijn Standard syslog protocol en Device standard format (legacy). Doorslaggevend is welke indeling de SIEM-parser verwacht. Een latere wijziging kan zoekopdrachten, dashboards en detectieregels verstoren.

Secure log transmission

TLS is zinvol voor productieverbindingen via onbetrouwbare of gedeelde netwerken, omdat logs interne adressen, gebruikersnamen, URL’s en beveiligingsgebeurtenissen kunnen bevatten. Alleen het selectievakje inschakelen is echter niet voldoende: de collector moet TLS op de geselecteerde poort accepteren en beide kanten moeten de certificaten kunnen valideren.

Voor de door Sophos gedocumenteerde Secure Syslog-verbinding geldt:

Het servercertificaat van de collector en de certificaatketen moeten door de firewall worden vertrouwd.
De geconfigureerde FQDN moet met het certificaat overeenkomen. Zonder LINCE controleert SFOS de Common Name; met LINCE mag de Common Name of Subject Alternative Name overeenkomen.
Download onder Certificates > Certificate authorities de Sophos-CA Default. De collector moet het geëxtraheerde Default.pem vertrouwen, omdat Sophos deze CA voor zijn kant van de verbinding gebruikt.
Activeer pas daarna Secure log transmission met de voorbereide TLS-poort.

In het officiële syslog-ng-voorbeeld staan Default.pem en de externe CA in de CA-directory van de collector; peer_verify(required-trusted) dwingt de certificaatvalidatie af. Andere collectorproducten hebben daarvoor hun eigen truststores. Een FQDN die alleen in de SAN staat, werkt niet zonder LINCE, en een ingevoerd IP-adres komt niet overeen met een certificaat dat uitsluitend DNS-namen bevat.

Als een cloud-SIEM deze methode niet rechtstreeks ondersteunt, kan de firewall de logs intern naar een lokale collector sturen, die ze vervolgens versleuteld doorstuurt. Een onversleuteld traject moet kort, gesegmenteerd en gedocumenteerd zijn.

Logtypen en zichtbaarheid vastleggen

Het doel wordt in twee stappen geactiveerd:

De betreffende regel of functie moet de gebeurtenis genereren. Voor firewallregels is daarvoor Log firewall traffic vereist en voor SSL/TLS-inspectieregels Log connections.
Onder System services > Log settings moet het bijbehorende logtype in de kolom van de Syslog-server zijn geselecteerd.

Als een van beide stappen ontbreekt, kan de collector de gebeurtenis niet ontvangen. Voor een pilot volstaat aanvankelijk een bewust kleine set:

Firewall en Events: Regelgebeurtenissen, activiteiten van beheerders en gebruikers en gebeurtenissen voor authenticatie, VPN, DHCP en DNS.
IPS, Content filtering, Web server protection en Zero-day protection: Beveiligings- en beleidsbeslissingen.
Active threat response: Treffers van MDR, NDR Essentials, Sophos X-Ops en Third-Party Threat Feeds.
System health, Wireless, Heartbeat en SD-WAN: Aanvullende operationele status wanneer deze modules worden gebruikt.

Voeg pas meer modules toe als er een zoek-, alarmerings- of auditdoel bestaat. Wie DoS-gebeurtenissen analyseert, moet ook de configuratie voor spoofing- en DoS-bescherming controleren. Voor Third-Party Threat Feeds en NDR en Active Threat Response zijn naast het logtransport concrete zoekopdrachten en alarmen nodig.

Veelvoorkomende valkuilen voor zichtbaarheid

Log Suppression: SFOS kan identieke opeenvolgende firewallgebeurtenissen samenvoegen. Dit is van invloed op Log Viewer, Sophos Central en Syslog. Parsers en detecties moeten daarom ook rekening houden met log_occurrence.
Active Threat Response: Remote Source Match voor inkomend DNAT- of WAF-verkeer is niet standaard actief. Zonder deze selectie ontbreken de bijbehorende brontreffers.
Wireless: Logs van access points en SSID’s zijn niet beschikbaar in de lokale Log Viewer. Ze moeten gericht naar Sophos Central of Syslog worden gestuurd en daar worden gecontroleerd.
Content filtering en SSL/TLS: Het geselecteerde logtype vervangt de logging in de bijbehorende firewall- of inspectieregel niet.

Indeling en parser controleren

Een parsertest mag niet alleen aantonen dat er willekeurige tekst binnenkomt. De belangrijkste waarden moeten als afzonderlijke velden doorzoekbaar zijn. Dit ingekorte, geanonimiseerde voorbeeld komt overeen met het Standard syslog protocol voor een firewallregelgebeurtenis:

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

De legacy-indeling gebruikt daarentegen onder andere device, date, time, timezone, device_id en priority. Velden zoals status, user_name, nat_rule_id of log_occurrence hangen daarnaast af van het logtype en de gebeurtenis. Ze mogen niet als verplicht worden beschouwd voor elke gebeurtenis in de standaardindeling.

Afhankelijk van de use case zijn voor de acceptatie vooral de volgende velden belangrijk:

Identiteit: device_name, device_model, device_serial_id
Classificatie: log_id, log_type, log_component, log_subtype, severity
Beleid: fw_rule_id, fw_rule_name, nat_rule_id
Verbinding: src_ip, dst_ip, poorten, protocol en gebruiker
Tijd en frequentie: timestamp, tijdzone en log_occurrence

log_id bevat het logtype, de component, het subtype, de Severity en de Message ID. Daardoor zijn detectieregels stabieler dan zoekopdrachten in platte tekst. Welke velden een specifieke module levert, moet desondanks aan de hand van een echte gebeurtenis van dat logtype worden gecontroleerd.

De Syslog-module Events is niet hetzelfde als configuration-audit.log. Waarden van vóór en na de wijziging zijn daar alleen beschikbaar voor ondersteunde sleutelobjecten, zoals firewallregels, interfaces en IP-hosts, niet voor elke configuratiewijziging. De reikwijdte en analyse worden behandeld in het artikel over Audit Trail-logs.

Meerdere firewalls en HA

In een omgeving met meerdere appliances moet elke gebeurtenis eenduidig aan een firewall, locatie, klant en HA-cluster kunnen worden gekoppeld. De hostnaam, het serienummer, het model en de Facility moeten daarom worden gedocumenteerd en in het SIEM filterbaar zijn.

Na een HA-failover, herstelbewerking of hardwarevervanging moet worden gecontroleerd of gebeurtenissen nog aan de bestaande asset worden gekoppeld of als een nieuw of dubbel systeem verschijnen. Hetzelfde geldt na een wijziging van de hostnaam of de Syslog-indeling.

De integratie met echte gebeurtenissen testen

Een groene collectorstatus bewijst niet dat de juiste logs zijn geselecteerd of dat de parser werkt. Voor de acceptatie:

Documenteer een pilotfirewall en de geconfigureerde indeling.
Stuur aanvankelijk Firewall en Events naar het doel.
Genereer verkeer dat overeenkomt met een gelogde testregel met een gedefinieerde bron, bestemming en service.
Controleer in het SIEM het apparaat, de tijd, het logtype, de actie, de Rule ID, de bron en de bestemming.
Genereer een gedefinieerde drop en een VPN-aanmelding en -afmelding.
Test ten minste één beveiligingsgebeurtenis uit IPS, Content filtering of Active threat response, mits de module in productie wordt gebruikt.
Activeer daarna stapsgewijs meer logtypen en observeer het volume en het parserresultaat.

Bij het testen van regels helpt de handleiding voor Log Viewer, Policy Test en Packet Capture. Een negatieve test is ook belangrijk: blokkeer bewust een verwachte verbinding; deze moet als drop met de juiste regel verschijnen.

Bij HA- of migratieprojecten hoort een failover-, herstel- of hardwarevervangingstest bij de acceptatie. Het SOC moet daarna nog steeds kunnen herkennen welk apparaat en welke locatie de gebeurtenis heeft gegenereerd.

Beheer, bewaring en uitval

Een Syslog-integratie heeft een eigenaar, een vastgelegde bewaartermijn en een reactie op alarmen nodig. Daarnaast moet vaststaan wie foutpositieven beoordeelt en detectieregels aanpast. Firewalllogs kunnen persoonsgegevens, interne adressen, gebruikersnamen, URL’s en VPN-activiteit bevatten. Toegangsrechten, verwijdertermijnen, tenantscheiding en SIEM-kosten moeten daarom vóór een brede uitrol worden vastgelegd.

Het beheer moet niet alleen aanvallen, maar ook ontbrekende gegevens herkennen:

Bewaak per firewall een verwacht minimaal activiteitsniveau.
Controleer belangrijke logtypen zoals Firewall, Events, IPS of Active threat response afzonderlijk op actualiteit.
Bewaak centrale parservelden op lege of plotseling hernoemde waarden.
Stel alarmen in voor het verlopen van certificaten en de status van de collector.
Genereer na firmware-, parser- en certificaatupdates opnieuw testgebeurtenissen.

Ook de bewaking zelf moet worden getest: als gegevens van een verwacht logtype of een firewall bewust uitblijven, moet het vastgelegde uitvalalarm afgaan.

Ruwe gegevens zonder geparste velden gelden eveneens als uitval. Een parserupdate kan het transport intact laten, terwijl dashboards en detectieregels geen treffers meer opleveren.

Syslog vervangt noch lokale servicelogs, noch een probleemoplossingsarchief voor support. Voor NetFlow-v5-records uit gericht gelogde firewallregels past NetFlow; voor interfacesamples en verkeerspatronen sFlow. Hardware- en interfacestatus kunnen daarnaast via SNMP worden bewaakt.

Fouten gericht isoleren

Er komen geen logs binnen: Controleer het doel, de poort, het transport, de routing en de externe firewall. Controleer daarna of het gewenste logtype in de Syslog-kolom is geactiveerd. Als de collector zich achter een VPN of managementnetwerk bevindt, moet ook rekening worden gehouden met de route, het SD-WAN-beleid en Source NAT.

Alleen bepaalde gebeurtenissen ontbreken: Controleer eerst de logging in de betreffende firewall- of inspectieregel en daarna het logtype onder Log settings. Controleer bij ATR ook het vereiste matchtype.

Ruwe logs komen binnen, maar velden ontbreken: Vergelijk de ingestelde indeling, de parserversie en de firmwareversie. Standaard- en legacy-velden mogen niet in hetzelfde parserprofiel worden verwacht.

TLS maakt geen verbinding: Controleer de TLS-poort en de serverservice en vervolgens de certificaatketen, FQDN, Common Name, SAN en LINCE-modus. De collector moet daarnaast de Sophos-CA Default.pem vertrouwen. Controleer bij certificaatwijzigingen beide truststores en het vernieuwingsproces.

Tijdstempels kloppen niet: Controleer NTP op de firewall en de collector, de tijdzone van het SIEM en de parsernormalisatie. Onjuiste tijden verhinderen een betrouwbare correlatie met endpoint-, server- en identiteitslogs.

Te veel logs of te veel ruis: Schakel niet zonder onderscheid alles uit. Evalueer eerst ongebruikte logtypen, regels die onnodig veel logs genereren, SIEM-use-cases en log_occurrence; beperk daarna de selectie gericht.