Sophos Firewall Syslog naar SIEM verzenden

Met Syslog kan een Sophos Firewall gebeurtenissen naar een externe logserver, een SIEM of een beveiligingsplatform sturen. Dit is vooral belangrijk wanneer logs langer moeten worden bewaard, centraal doorzocht, gecorreleerd met andere systemen of gebruikt voor audits en incident response.

De lokale Log viewer is handig voor snelle analyse direct op de firewall. Central Firewall Reporting is handig wanneer Sophos Central als rapportageplatform wordt gebruikt. Syslog is daarentegen de betere keuze wanneer er een eigen SIEM, een SOC, een Managed Detection-proces of een leverancieronafhankelijke logarchitectuur aanwezig is.

Welke logging-artikel past?

Logging op Sophos Firewall bestaat uit meerdere lagen. Afhankelijk van de vraag is Syslog niet altijd de beste start:

Taak	Passend artikel
Individuele verbinding, Rule ID of web-/IPS-beslissing live analyseren	Sophos Firewall-regel testen met Log Viewer, Policy tester en Packet Capture
Lokale logbestanden en diensten toewijzen	Sophos Firewall Troubleshooting: Services en Logs
Logs voor ondersteuning of externe analyse veiligstellen	Sophos Firewall Logs voor ondersteuning en analyse veiligstellen
Configuratiewijzigingen en beheeracties volgen	Sophos Firewall Audit Trail Logs controleren
Sophos-Central-gebaseerde rapporten over meerdere firewalls gebruiken	Sophos Firewall Central Reporting activeren en beheren
Logs op lange termijn naar SIEM, SOC of logserver sturen	Dit artikel
Traffic-flows in plaats van individuele firewall-events analyseren	sFlow Monitoring op Sophos Firewall configureren
Hardware- en interface-status via monitoring controleren	Sophos Firewall SNMP Hardware Monitoring instellen

Zo blijft de evaluatie helder: de Log Viewer beantwoordt de huidige pakket- of beleidskwestie, lokale logs helpen bij diepere module-diagnose, Central Reporting is handig voor Sophos-evaluaties, en Syslog levert de externe lange termijn- en SIEM-laag.

Wanneer Syslog zinvol is

Syslog is niet alleen de moeite waard voor grote omgevingen. Zelfs bij enkele firewalls kan een centrale logserver helpen om gebeurtenissen langer en onafhankelijk van het apparaat te bewaren.

Typische gebruikssituaties:

centrale logopslag over weken, maanden of jaren
correlatie met endpoint-, server-, identiteit-, proxy-, cloud- of switch-logs
SIEM-use cases voor aanvallen, portscans, VPN-aanmeldingen, WAF-events of Threat-Feed-treffers
externe evaluatie door SOC, MDR of interne beveiligingsteams
traceerbaarheid na firmware-updates, failover, herstel of hardwarevervanging
forensisch onderzoek wanneer lokale firewall-logs niet meer voldoende zijn

Voor acute troubleshooting-gevallen blijven lokale logs echter belangrijk. Welke lokale logbestand bij welk firewall-module hoort, staat in Sophos Firewall Troubleshooting: Services en Logs. Als logs voor ondersteuning of een externe analyse moeten worden veiliggesteld, past Sophos Firewall Logs voor ondersteuning en analyse veiligstellen.

Syslog, Central Reporting of lokale logs?

De drie methoden beantwoorden verschillende vragen. In de praktijk worden vaak meerdere van deze methoden parallel gebruikt.

Doel	Sterkte	Beperking
Log viewer	snelle live-analyse op de firewall	geen langdurige centrale architectuur
Lokale logbestanden	detailanalyse via Advanced Shell of supportcase	afhankelijk van de status en opslag van de firewall
Central Firewall Reporting	Sophos Central-rapporten, eenvoudig overzicht over meerdere firewalls	gebonden aan Sophos Central, licentie en opslaglimieten
Syslog / SIEM	eigen opslag, correlatie, detectie en audit	vereist parser, beheer, monitoring en duidelijke use cases

Syslog vervangt dus niet de Log Viewer. Het vult deze aan. De Log Viewer toont snel welke regel of welk module heeft beslist. Syslog zorgt ervoor dat deze informatie later nog extern beschikbaar is.

Vereisten

Voor de configuratie moeten deze punten duidelijk zijn:

Syslog-server of SIEM is bereikbaar.
Doel-IP of FQDN is stabiel en gedocumenteerd.
Poort en transport zijn vastgesteld, vaak UDP 514 of TLS op een eigen poort.
Firewall kan de Syslog-server routeren en bereiken.
In het doelsysteem bestaat een passende parser of op zijn minst een ruwe gegevensopslag.
Bewaartermijn en privacyvereisten zijn gedefinieerd.
Het is duidelijk welke logtypen echt nodig zijn.

Bij externe of cloudgebaseerde SIEM-doelen moet men vooral letten op transportversleuteling, bron-IP, routing, DNS en certificaatcontrole.

Privacy, bewaring en verantwoordelijkheid verduidelijken

Syslog is niet alleen een technische doorsturing. Firewall-logs kunnen interne IP-adressen, gebruikersnamen, doelsystemen, URL’s, categorieën, VPN-aanmeldingen, beheerdersevents en beveiligingstreffers bevatten. Daarom moet voor de productieve koppeling duidelijk zijn wie deze gegevens mag zien en hoe lang ze worden opgeslagen.

Voor de uitrol verduidelijken:

Punt	Praktische vraag
Bewaring	Hoe lang moeten logs beschikbaar blijven voor operatie, audit of incident response?
Toegang	Welke personen of teams mogen ruwe logs, zoekopdrachten en dashboards zien?
Privacy	Bevatten logs persoonsgegevens, gebruikers-ID’s, bron-IP-adressen of URL’s?
Multitenancy	Zijn locaties, klanten, tenants of HA-clusters in het SIEM duidelijk gescheiden?
Kosten	Worden logvolume, EPS, opslag of zoekopdrachten bij de SIEM-aanbieder in rekening gebracht?
Alarmen	Wie reageert op alarmen en binnen welk tijdsbestek?
Verwijdering	Hoe worden oude logs na afloop van de bewaartermijn verwijderd?

Vooral bij MSP-, SOC- of MDR-modellen moet deze verantwoordelijkheid niet open blijven. Een SIEM zonder duidelijke eigenaar genereert weliswaar gegevens, maar geen betrouwbare reactie.

Rollout in fasen plannen

Voor productieve firewalls is een kleine pilot beter dan meteen alle logtypen naar alle doelen te sturen. Zo kunnen parser, veldnamen, ruis en kosten worden gecontroleerd voordat het SIEM als betrouwbare bron wordt ingepland.

Een zinvolle volgorde:

Eerst wordt een pilot-firewall geselecteerd.
Hostnaam, tijdbron, firmwareversie en logformaat worden gedocumenteerd.
Het Syslog-doel wordt met veilige transport geconfigureerd.
De start gebeurt met enkele logtypen, bijvoorbeeld firewall, events en VPN.
Gedefinieerde testgebeurtenissen worden gegenereerd en in het doelsysteem gecontroleerd.
Parser, velden, tijdstempels, tijdzone en device_name worden gevalideerd.
Logvolume en ruis worden enkele dagen geobserveerd.
Daarna worden verdere logtypen zoals IPS, Web, WAF, Active threat response of systeemgezondheid toegevoegd.
Pas na een succesvolle pilot wordt uitgerold naar andere firewalls.

Bij meerdere firewalls moet men niet alleen controleren of gegevens aankomen. Belangrijk is of elk event aan de juiste locatie, apparaat, HA-node, klant of tenant wordt toegewezen.

Syslog-server toevoegen

De configuratie gebeurt in de Sophos Firewall webinterface.

System services > Log settings openen.
Add selecteren.
Een unieke naam geven, bijvoorbeeld siem-primary of syslog-soc.
IP address/domain van de Syslog-server invoeren.
Port passend aan het doelsysteem instellen.
Facility bewust kiezen.
Severity level vaststellen.
Format selecteren.
Optioneel Secure log transmission activeren als het doel TLS ondersteunt.
Opslaan.

Sophos Firewall kan meerdere externe Syslog-servers configureren. In de huidige documentatie zijn tot vijf Syslog-servers voorzien. Toch moet men niet willekeurig elk doel koppelen, maar per doel vaststellen welk doel erachter zit.

Belangrijke instellingen

Facility

De Facility helpt de Syslog-server om logbronnen of categorieën te onderscheiden. In eenvoudige omgevingen volstaat vaak een standaardwaarde. In grotere omgevingen kan het zinvol zijn om firewalls of locatiegroepen te scheiden via verschillende LOCAL0 tot LOCAL7 waarden.

Belangrijk is dat SIEM-regels, parsers en documentatie dezelfde logica gebruiken. Als elke firewall willekeurig een andere Facility gebruikt, wordt de evaluatie onnodig moeilijk.

Severity level

De Severity bepaalt vanaf welke ernst logs worden verzonden. Voor beveiligings- en troubleshooting-doeleinden is een te hoge drempel gevaarlijk, omdat dan belangrijke informatie- of notice-gebeurtenissen kunnen ontbreken. Voor zeer luidruchtige omgevingen kan een te lage drempel daarentegen onnodig veel ruis veroorzaken.

Meestal is een pilot met een bredere logselectie zinvol, gevolgd door een bewuste reductie op basis van echte treffers en SIEM-use cases.

Format

Sophos Firewall biedt volgens de huidige documentatie twee formaten:

Standard syslog protocol
Device standard format (legacy)

Voor nieuwe integraties moet eerst worden gecontroleerd welk formaat het doelsysteem of de bestaande parser verwacht. Als een SIEM al een Sophos Firewall-parser heeft, is de verwachting daarvan bepalend. Een formaatwijziging na de productiestart kan dashboards, zoekopdrachten en detectieregels breken.

Secure log transmission

Als Secure log transmission actief is, worden logs versleuteld naar de Syslog-server verzonden. Hiervoor moet het doelsysteem TLS op de geconfigureerde poort accepteren, een passend servercertificaat leveren en een certificaatketen gebruiken die de firewall vertrouwt. Voor de go-live moet daarom niet alleen het vinkje in de firewall worden gezet, maar ook de certificaatnaam, trust chain, poort, parser en vernieuwingsproces van het Syslog-doel worden gecontroleerd.

Voor interne laboratoria kan UDP technisch voldoende zijn. Voor productieve SIEM- of SOC-koppelingen is ongecodeerd Syslog over onveilige netwerken echter geen goede basis, omdat loggegevens interne IP-adressen, gebruikers, doelen, URL’s of beveiligingsevents kunnen bevatten.

Bij TLS is de naam van het Syslog-doel belangrijk. Sophos controleert afhankelijk van de modus de Common Name of de Subject Alternative Name van het certificaat tegen de domein van de Syslog-server. Als in de firewall een IP-adres wordt ingevoerd, maar het certificaat alleen een DNS-naam bevat, kan de verbinding mislukken. Daarom moet men voor productieve TLS-Syslog-doelen een stabiele FQDN, een passend servercertificaat en een gedocumenteerde certificaatverlenging plannen.

Logtypen selecteren

Na het toevoegen van de Syslog-server is het werk nog niet klaar. Men moet onder System services > Log settings vaststellen welke logtypen naar dit doel worden verzonden.

Belangrijk: Een firewall-regel genereert alleen dan zinvolle verkeerslogs als in de regel Log firewall traffic is geactiveerd. Voor SSL/TLS Inspection moet ook logging in de passende Inspection Rule actief zijn. De logselectie onder Log settings bepaalt daarna waarheen deze logs worden verzonden.

Typische logtypen voor een SIEM:

Logtype	Waarom het nuttig is
Firewall	toegestane en geweigerde verbindingen, regel-matching, DoS-gebeurtenissen
IPS	gedetecteerde of geblokkeerde aanvallen
Web / Content filtering	webtoegang, categorieën, web-policy-gebeurtenissen
SSL/TLS inspection	TLS-inspectiebeslissingen en fouten
Web server protection	WAF-gebeurtenissen voor gepubliceerde diensten
Authentication / Events	beheerder-, gebruiker- en systeemgebeurtenissen
VPN	Remote Access en Site-to-Site VPN-gebeurtenissen
Active threat response	treffers door MDR Threat Feeds, NDR Essentials, Sophos X-Ops en Third-Party Threat Feeds
System health	CPU, geheugen, gebruikers, interfaces en partities

Als DoS- of Spoof-gebeurtenissen geëvalueerd moeten worden, moet de technische hardening zelf ook worden gecontroleerd. De procedure staat in Sophos Firewall Spoof Protection en DoS Settings controleren.

Als Third-Party Threat Feeds, NDR en Active Threat Response of WAF worden gebruikt, moet het SIEM deze gebeurtenissen gericht evalueren. Alleen logs verzenden is niet genoeg. Het vereist duidelijke zoekopdrachten, alarmen, verantwoordelijkheden en tuning tegen valse alarmen.

Belangrijke zichtbaarheidsvalkuilen

Bij Syslog-projecten ontstaan veel hiaten niet in het transport, maar eerder: de firewall genereert het verwachte event niet, het logtype wordt niet naar de Syslog-server verzonden of het SIEM interpreteert de velden verkeerd.

Regel- en module-logging

Firewall-regels en SSL/TLS-inspectieregels moeten zelf logging genereren. Onder System services > Log settings kiest men daarna of deze logs lokaal, in Sophos Central of naar Syslog-servers worden verzonden. Als een firewall-regel geen Log firewall traffic heeft, kan de Syslog-server geen volledige firewall-verkeersgeschiedenis tonen.

Voor web-policy-gebeurtenissen is het ook relevant of de bijbehorende firewall-regel verkeerslogging genereert. Anders ziet men in het SIEM mogelijk minder web- of content-filtering-gebeurtenissen dan verwacht.

Log Suppression

Sophos Firewall kan meerdere gelijke opeenvolgende logvermeldingen onderdrukken. Dit bespaart opslag en verwerking, maar kan bij SIEM-use cases verwarrend zijn als telwaarden, frequentie of burst-gedrag moeten worden geëvalueerd. De functie werkt op Log Viewer, Sophos Central en externe Syslog-servers.

Voor een productieve SIEM-uitrol moet men daarom vaststellen:

Welke firewall-gebeurtenissen mogen worden onderdrukt?
Welke detectieregels hebben elke afzonderlijke verbinding nodig?
Wordt in het SIEM met telwaarden of alleen met afzonderlijke events gewerkt?
Hoe wordt gedocumenteerd dat Log Suppression actief is?

Active Threat Response

Active-Threat-Response-logs zijn bijzonder nuttig wanneer Threat Feeds, NDR Essentials of externe feeds worden ingezet. Sophos onderscheidt daarbij verschillende match-typen, bijvoorbeeld doeltreffers bij uitgaand verkeer en bron-treffers bij inkomend verkeer.

Belangrijk: Remote Source Match voor inkomend verkeer is niet automatisch actief. Als WAF- of DNAT-verkeer tegen Threat Feeds moet worden bewaakt, moet deze zichtbaarheid bewust worden gecontroleerd. Anders ontbreken precies de inkomende treffers die een SOC vaak verwacht.

Wireless-logs

Wireless-logs zijn niet automatisch zichtbaar in de lokale Log Viewer. Access Point- en SSID-logs moeten gericht naar Sophos Central of Syslog worden verzonden en in het doelsysteem apart worden gecontroleerd als draadloze gebeurtenissen relevant zijn voor operatie, ondersteuning of compliance.

Multi-Firewall-omgevingen

In omgevingen met meerdere firewalls moet elk event eenduidig aan een apparaat kunnen worden toegewezen. Hiervoor zijn hostnaam, serienummer, model en andere velden relevant. De SFOS-Syslog-gids beschrijft onder andere velden zoals device_name, device_model en device_serial_id.

Praktische aanbevelingen:

Firewall-hostnaam correct instellen.
Locatie of rol in de hostnaam overwegen.
Eenduidige Facility- of tagging-strategie definiëren.
In het SIEM controleren of events kunnen worden gefilterd op firewall, locatie en cluster.
HA-clusters en standalone firewalls duidelijk onderscheiden.

Vooral na een hardwarevervanging of herstel is deze toewijzing belangrijk. Anders lijken events in het SIEM op nieuwe of dubbele systemen.

Configuratie testen

Na het opslaan moet de koppeling bewust worden getest. Een groen doelsysteem alleen bewijst nog niet dat de juiste logs met de juiste velden aankomen.

Testpunten:

Op de firewall System services > Log settings openen.
Zorgen dat de Syslog-server zichtbaar is.
Voor een ongevaarlijk logtype testmatig Syslog activeren.
Een gedefinieerde actie uitvoeren, bijvoorbeeld een gelogde firewall-regel of een testtoegang.
In het doelsysteem controleren of het event aankomt.
Velden zoals tijd, hostnaam, device_name, bron, bestemming, Rule ID, actie en logtype controleren.
Tijdstempels en tijdzone in het SIEM controleren.

Voor regeltests is Firewall-regel testen met Log Viewer, Policy Test en Packet Capture nuttig. Als er helemaal geen events ontstaan, ligt de oorzaak vaak niet bij de Syslog-transport, maar bij uitgeschakelde logging in de regel of bij het verkeerde logtype.

Beheer en monitoring

Een Syslog-koppeling is geen eenmalige instelling. Het beheer moet worden bewaakt en regelmatig worden gecontroleerd.

Minstens deze punten moeten gedocumenteerd zijn:

Wie is eigenaar van het logplatform?
Welke firewalls sturen logs?
Welke logtypen worden verzonden?
Welke bewaartermijn geldt?
Welke parsers, dashboards en alarmen hangen eraan?
Hoe herkent men dat er geen logs meer aankomen?
Hoe worden formaatwijzigingen na firmware-updates gecontroleerd?
Wie beoordeelt valse alarmen en past SIEM-regels aan?

Na firmware-updates moet steekproefsgewijs worden gecontroleerd of belangrijke events nog correct worden geparsed. Dit geldt vooral voor productieve SIEM-regels die afhankelijk zijn van bepaalde veldnamen, logtypen of formaten.

Problemen oplossen

Geen logs komen in het SIEM aan

Eerst IP-adres, poort, routing en firewall-regels tussen Sophos Firewall en Syslog-server controleren. Daarna controleren of onder System services > Log settings het juiste logtype voor de Syslog-server is geactiveerd.

Alleen bepaalde events ontbreken

Dan is vaak het module- of regel-logging niet actief. Bij firewall-regels moet Log firewall traffic zijn ingesteld. Bij web- of SSL/TLS-gebeurtenissen moet bovendien de juiste policy of inspectieregel logging genereren.

Logs komen aan, maar worden verkeerd geparsed

Formaat, parser-versie en firmwareversie controleren. Als er is gewisseld tussen Standard syslog protocol en Device standard format (legacy), moet de SIEM-parser daarop aansluiten.

TLS-Syslog verbindt niet

FQDN, certificaat, Common Name, Subject Alternative Name, certificaatketen en poort controleren. Als de firewall een DNS-naam verwacht, maar de Syslog-server alleen via IP-adres is ingevoerd, kan de certificaatcontrole mislukken. Daarnaast controleren of het doelsysteem echt TLS op de geconfigureerde poort accepteert.

Tijdstempels kloppen niet

NTP op de firewall, tijdzone in het SIEM en parser-logica controleren. Verkeerde tijden maken correlatie met endpoint-, server- of identiteit-logs onbetrouwbaar.

Te veel logs of te veel ruis

Niet meteen alles uitschakelen. Eerst controleren welke logtypen echt nodig zijn, welke regels onnodig veel loggen en of logonderdrukking zinvol is. Daarna gericht verminderen.

Checklist

Syslog-server of SIEM is bereikbaar.
Transport, poort en versleuteling zijn vastgesteld.
Formaat past bij de SIEM-parser.
Facility-strategie is gedocumenteerd.
Relevante logtypen zijn onder System services > Log settings geactiveerd.
Belangrijke firewall-regels hebben Log firewall traffic actief.
SSL/TLS-inspectieregels genereren indien nodig eigen logs.
Logonderdrukking is bewust geëvalueerd en gedocumenteerd.
Active-Threat-Response-match-typen passen bij de SIEM-use cases.
Privacy, toegang en bewaartermijn zijn verduidelijkt.
Pilot-firewall, testevents en SIEM-parser zijn gevalideerd.
Testevents komen in het doelsysteem aan.
Velden zoals hostnaam, device_name, bron, bestemming, actie en Rule ID worden correct herkend.
Tijdstempels en tijdzone kloppen.
Monitoring herkent wanneer er geen logs meer aankomen.
Na firmware-updates wordt de parser-functie gecontroleerd.

FAQ

Hoeveel Syslog-servers ondersteunt Sophos Firewall?

SFOS ondersteunt momenteel tot vijf externe Syslog-servers. In de praktijk moet men echter alleen de doelen configureren die echt nodig en bewaakt worden.

Is UDP 514 voldoende voor Sophos Firewall Syslog?

UDP 514 is de klassieke Syslog-standaard en werkt in veel interne netwerken. Voor productieve SIEM- of SOC-koppelingen moet men controleren of TLS met Secure log transmission mogelijk is, vooral als logs over onveilige of gedeelde netwerken worden getransporteerd.

Waarom ziet men in het SIEM geen firewall-regel-events?

Vaak is in de betreffende firewall-regel Log firewall traffic niet geactiveerd of wordt het logtype Firewall niet naar de Syslog-server verzonden. Beide moeten overeenkomen.

Is Syslog beter dan Central Firewall Reporting?

Het heeft een ander doel. Central Firewall Reporting is handig voor Sophos Central-rapporten. Syslog is sterker wanneer eigen opslag, SIEM-correlatie, SOC-processen of leverancieronafhankelijke evaluatie nodig zijn.

Welke logs moet men naar een SIEM sturen?

Minstens Firewall, Events, VPN, IPS, Web, Web server protection, Active threat response en System health moeten worden geëvalueerd. De concrete selectie hangt af van architectuur, privacy, SIEM-kosten, use cases en operationeel model.

Waarom ontbreken ondanks Syslog enkele web- of firewall-gebeurtenissen?

Vaak wordt het juiste logtype wel naar Syslog verzonden, maar genereert de betreffende firewall-regel of inspectieregel zelf geen logs. Daarnaast kunnen logonderdrukking, parserfilters of een niet-geactiveerde match-type bij Active Threat Response de zichtbaarheid verminderen.