Naar de inhoud
Avanet

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 Fusion (voorheen 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, de verwachte logindeling en een geschikte parser vaststaan. De firewall heeft een route naar de collector nodig en beide systemen een correct werkende tijdbron. SFOS gebruikt voor Syslog normaal UDP 514. Dit scherm heeft geen afzonderlijke transportkeuze: Secure log transmission schakelt TLS-versleutelde overdracht in of uit. In het officiële TLS-voorbeeld van Sophos voor syslog-ng wordt poort 6514 gebruikt; poort en listener moeten altijd overeenkomen met de eigen collector.

  1. Open System services > Log settings.
  2. Selecteer Add.
  3. Voer een eenduidige naam in, zoals siem-primary.
  4. Voer de collector in onder IP address/domain.
  5. Selecteer Port, Facility, Severity level en Format passend bij het doelsysteem.
  6. Activeer Secure log transmission als de TLS-collector is voorbereid.
  7. Sla de configuratie op.
  8. 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: De opties omvatten DAEMON, KERNEL, USER en LOCAL0 tot en met LOCAL7. Zo kunnen LOCAL1 en LOCAL2 bijvoorbeeld aan twee firewalls worden toegewezen. Houd de toewijzing gelijk in de collector en de beheerdocumentatie.
  • Severity level: De selectie is de minimale ernst. Error verstuurt ook Critical, Alert en Emergency, maar geen Information- of Notice-gebeurtenissen. Debug omvat alle niveaus. Een te hoge minimumwaarde kan aanmeldingen en normale operationele gebeurtenissen verbergen.
  • 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:

  1. Het servercertificaat van de collector en de certificaatketen moeten door de firewall worden vertrouwd.
  2. 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.
  3. 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.
  4. 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.

Controleer vóór het inschakelen van LINCE voor dit doel de certificeringsgrens, toegestane algoritmen en SSH-herstart van LINCE-modus. De modus is niet alleen een syslogschakelaar en mag niet zonder onafhankelijke beheerstoegang worden ingeschakeld.

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:

  1. De betreffende regel of functie moet de gebeurtenis genereren. Voor firewallregels is daarvoor Log firewall traffic vereist en voor SSL/TLS-inspectieregels Log connections.
  2. 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.

ATR-reikwijdte: Schakel logging van externe bronnen alleen in voor aantoonbaar ondersteunde combinaties van module en verkeerspad. De ATR-tekst en SVG-verkeersmatrix van Sophos spreken elkaar tegen over X-Ops-matchrichtingen; dit conflict blijft onopgelost. Uitspraken over MDR, NDR of feeds van derden bewijzen geen gelijkwaardige X-Ops-ondersteuning. Houd beperkende firewall-, DNAT/WAF- en Device Access-controles onafhankelijk van het betwiste feedgedrag. Betwiste gevallen vereisen geautoriseerde, gecontroleerde verificatie van de module, matchrichting, logs en daadwerkelijke werking, plus betrouwbare verduidelijking; tot die tijd mag de bescherming niet van dat gedrag afhangen. NDR en Active Threat Response biedt de veilige context.

Veelvoorkomende valkuilen voor zichtbaarheid

  • Log Suppression: SFOS kan identieke opeenvolgende firewallgebeurtenissen samenvoegen. Dit is van invloed op Log Viewer, Sophos Fusion 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 op ondersteunde module-/verkeerspaden. Houd ook bij onderzoek naar ontbrekende matchtypen rekening met de ATR-reikwijdte hierboven; de optie inschakelen bewijst geen ondersteuning voor betwiste X-Ops-richtingen.
  • Wireless: Logs van access points en SSID’s zijn niet beschikbaar in de lokale Log Viewer. Ze moeten gericht naar Sophos Fusion 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.
  • Webproxy: Bij webverkeer op poort 80 of 443 kan het Firewall-log Allowed tonen terwijl Web Filter hetzelfde verzoek blokkeert. Correleer beide gebeurtenissen om de daadwerkelijk toegepaste beleidsbeslissing vast te stellen.

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. Configureer de parser voor de eerste acceptatie alleen met de kernvelden hieronder; maak aanvullende logtypespecifieke velden pas verplicht nadat een echte testgebeurtenis ze heeft bevestigd.

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 twaalf tekens hebben vaste posities: teken 1 en 2 vormen de Log Type ID, 3 en 4 de Component ID, 5 en 6 de Subtype ID, teken 7 de Priority ID en teken 8 tot en met 12 de Message ID. 010101600001 wordt dus gelezen als 01 / 01 / 01 / 6 / 00001. Een parser moet voorloopnullen en vaste veldbreedtes behouden; controleer daarnaast ook log_type, log_component, log_subtype en severity.

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. Vanaf SFOS 22.0 identificeert device_name de hostnaam van de firewall die het log heeft geproduceerd. Controleer na een upgrade of de parser dit veld verwerkt en niet uitsluitend device_serial_id of de Syslog-header als assetsleutel blijft gebruiken.

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:

  1. Documenteer een pilotfirewall en de uitgangssituatie: servernaam, doel, poort, TLS, Facility, Severity, Format en alle logtypen die in de kolom van de server zijn ingeschakeld.
  2. Stuur aanvankelijk Firewall en Events naar het doel.
  3. Genereer verkeer dat overeenkomt met een gelogde testregel met een gedefinieerde bron, bestemming en service.
  4. Controleer in het SIEM het apparaat, de tijd, het logtype, de actie, de Rule ID, de bron en de bestemming.
  5. Genereer een gedefinieerde drop en een VPN-aanmelding en -afmelding.
  6. Test ten minste één beveiligingsgebeurtenis uit IPS, Content filtering of Active threat response, mits de module in productie wordt gebruikt.
  7. 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.

Een wijziging terugdraaien zonder gegevensonderbreking

Wijzig de indeling, minimale Severity en logselectie niet tegelijk. Als een van de vijf serverplaatsen vrij is, voegt u voor een parser- of collectormigratie een tweede doel toe en laat u beide eerst parallel werken. Zo kunt u ruwe gegevens, gevulde velden, tijdstempels en volume vergelijken zonder het werkende doel te wijzigen.

Schakel de logtypen in de kolom van het oude doel pas na acceptatie uit. Bewaar de serververmelding gedurende een afgesproken observatieperiode. Ontbreken er gebeurtenissen, mislukt de parsing of is het volume onverwacht, schakel daar dan precies de eerder gedocumenteerde logtypen weer in en draai de selectie bij het nieuwe doel terug. Is er geen serverplaats vrij, leg dan vóór elke afzonderlijke wijziging de huidige waarden vast en herstel ze volledig bij een fout; verwijder de vermelding niet en wijzig de parser niet tegelijk.

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.

Stel eerst vast of de module en het verkeerspad worden ondersteund. Pas de ATR-reikwijdte hierboven toe: ontbrekende logs lossen het X-Ops-conflict niet op en betwiste richtingen zijn geen reden om zomaar extra matchtypen in te schakelen.

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.