Send Sophos Firewall Syslog securely to SIEM

With Syslog, a Sophos Firewall can send events to an external log server, a SIEM or a security platform. This is particularly important if logs are to be retained for longer periods of time, searched centrally, correlated with other systems, or used for audits and incident response.

The local Log viewer is good for quick analysis directly on the firewall. Central Firewall Reporting is convenient when using Sophos Central as a reporting platform. Syslog, on the other hand, is the better choice if you have your own SIEM, a SOC, a managed detection process or a cross-manufacturer log architecture.

Which logging article fits?

Logging on Sophos Firewall consists of several levels. Depending on the question, Syslog is not always the best way to start:

• Analyze single connection, Rule ID or web/IPS decision live: Sophos Firewall Rule testing with Log Viewer, Policy tester and Packet Capture.
• Assign local log files and services: Sophos Firewall Troubleshooting: Services and Logs.
• Back up logs for support or external analysis: Sophos Firewall Back up logs for support and analysis.
• Track configuration changes and admin actions: Sophos Firewall Check Audit Trail Logs.
• Use Sophos Central-based reports across multiple firewalls: Sophos Firewall Activate and operate Central Reporting.
• Send logs long-term to SIEM, SOC or log server: This article.
• Analyze traffic flows instead of individual firewall events: Configure sFlow Monitoring on Sophos Firewall.
• Check hardware and interface status via monitoring: Sophos Firewall Setup SNMP Hardware Monitoring.

This keeps the evaluation clean: The Log Viewer answers the current package or policy case, local logs help with deeper module diagnostics, central reporting is convenient for Sophos evaluations, and Syslog provides the external long-term and SIEM layer.

When Syslog makes sense

Syslog is not only worthwhile for large environments. Even with a few firewalls, a central log server can help to retain events longer and independently of the appliance.

Typical use cases:

• Central log storage for weeks, months or years
• Correlation with endpoint, server, identity, proxy, cloud or switch logs
• SIEM use cases for attacks, port scans, VPN logins, WAF events or threat feed hits
• external evaluation by SOC, MDR or internal security teams
• Traceability after firmware updates, failover, restore or hardware replacement
• Forensics when local firewall logs are no longer sufficient

Local logs remain important for acute troubleshooting cases. Which local log file belongs to which firewall module can be found in Sophos Firewall Troubleshooting: Services and Logs. If you want to back up logs for support or external analysis, Sophos Firewall Back up logs for support and analysis fits.

Syslog, Central Reporting or Local Logs?

The three paths answer different questions. In practice, several of them are often used in parallel.

• Log viewer: fast live analysis on the firewall, but no long-term central architecture.
• Local log files: detailed analysis via Advanced Shell or a support case, but dependent on the state and storage of the firewall.
• Central Firewall Reporting: Sophos Central reports and a simple overview across multiple firewalls, but tied to Sophos Central, licence and storage limits.
• Syslog / SIEM: own retention, correlation, detection and audit. This requires parsers, operations, monitoring and clear use cases.

Syslog therefore does not replace the Log Viewer. It complements it. The Log Viewer quickly shows which rule or module made the decision. Syslog ensures that this information remains available externally later.

Requirements

Before configuration, these points should be clarified:

• Syslog server or SIEM is reachable.
• Target IP or FQDN is stable and documented.
• Port and transport are fixed, often UDP 514 or TLS on its own port.
• Firewall can route and reach Syslog server.
• There is a suitable parser or at least a raw data storage in the target system.
• NTP works on firewall and target platform.
• Retention period and data protection requirements are defined.
• It is clear which log types are really needed.

For external or cloud-based SIEM destinations, special attention should be paid to transport encryption, source IP, routing, DNS, and certificate verification. Some SIEM or MDR vendors deliberately expect unencrypted Syslog to a local collector or sensor that then forwards the data. Then the unencrypted route should be short, internally segmented and documented.

Clarify data protection, storage and responsibility

Syslog is not just a technical redirect. Firewall logs can contain internal IP addresses, usernames, target systems, URLs, categories, VPN logins, admin events and security hits. Therefore, before the productive connection, it should be clear who is allowed to see this data and how long it will be stored.

Clarify before rollout:

• Storage: How long must operational, audit or incident response logs remain available?
• Access: Which people or teams can see raw logs, search queries, and dashboards?
• Data protection: Do logs contain personal information, user IDs, source IP addresses, or URLs?
• Multi-client capability: Are locations, customers, tenants or HA clusters clearly separated in the SIEM?
• Cost: Are log volumes, EPS, storage or search queries billed by the SIEM provider?
• Alerting: Who responds to alarms and in what time frame?
• Deletion: How are old logs removed after the retention period has expired?

This responsibility should not be left open, especially with MSP, SOC or MDR models. A SIEM without a clear owner produces data, but no reliable response.

Plan rollout in phases

For productive firewalls, a small pilot is better than sending all log types to all destinations immediately. This allows parsers, field names, noise and costs to be controlled before the SIEM is planned as a reliable source.

A sensible process:1. First, a pilot firewall is selected. 2. Host name, time source, firmware version and log format are documented. 3. The Syslog destination is configured with secure transport. 4. It starts with a few log types, for example firewall, events and VPN. 5. Defined test events are generated and checked in the target system. 6. Parser, fields, timestamp, timezone and device_name are validated. 7. Log volume and noise are observed over a few days. 8. Additional log types such as IPS, Web, WAF, Active threat response or System health are then added. 9. Only after a successful pilot will it be rolled out to other firewalls.

If you have multiple firewalls, you shouldn’t just check whether data is arriving. What is important is whether each event is assigned to the correct location, device, HA node, customer or tenant.

The pilot should contain at least one normal operational event, one security event and one error event. Otherwise the transport seems healthy, but the later important fields are only missing in an emergency.

Add Syslog server

The configuration takes place in the Sophos Firewall web interface.

1. Open System services > Log settings.
2. Select Add.
3. Assign a unique name, for example siem-primary or syslog-soc.
4. Enter IP address/domain of the Syslog server.
5. Set Port to match the target system.
6. Choose Facility consciously.
7. Set Severity level.
8. Select Format.
9. Optionally enable Secure log transmission if the destination supports TLS.
10. Save.

Sophos Firewall can configure multiple external Syslog servers. The current documentation provides for up to five Syslog servers. Nevertheless, you shouldn’t connect every goal at random, but rather determine the purpose behind each goal.

If you have multiple targets, you should consciously separate the log selection for each target. A local log server might need all firewall and VPN logs, while a MDR collector only expects security-relevant log types. If all targets blindly receive the same data, costs, privacy risk, and parser noise increase.

Important settings

Facility

The facility helps the Syslog server to distinguish log sources or categories. In simple environments, a default value is often sufficient. In larger environments it can make sense to separate firewalls or location groups using different LOCAL0 to LOCAL7 values.

Importantly, SIEM rules, parsers and documentation use the same logic. If each firewall happens to use a different facility, the evaluation becomes unnecessarily difficult.

Severity level

The severity determines the severity at which logs are sent. For security and troubleshooting purposes, a threshold that is too high is dangerous because important information or notice events may be missed. However, for very loud environments, a threshold that is too low can generate an unnecessary amount of noise.

It usually makes sense to have a pilot with a wider selection of logs, then a conscious reduction based on real hits and SIEM use cases.

The threshold is a minimum severity. For example, if Error is selected, the firewall also sends more critical messages such as Critical, Alert and Emergency, but no normal information events. For many SIEM use cases, Information and Notice events are important because VPN logins, rule events or system states may otherwise be missing.

format

According to current documentation, Sophos Firewall offers two formats:

• Standard syslog protocol
• Device standard format (legacy)

For new integrations, you should first check which format the target system or the existing parser expects. If a SIEM already has a Sophos firewall parser, its expectation takes precedence. A format change after the go-live can break dashboards, search queries and detection rules.

Secure log transmission

When Secure log transmission is active, logs are sent encrypted to the Syslog server. To do this, the target system must accept TLS on the configured port, deliver a suitable server certificate and use a certificate chain that the firewall trusts. Before going live, you should not only check the firewall, but also check the certificate name, trust chain, port, parser and renewal process of the Syslog target.

UDP can technically be sufficient for internal laboratories. However, unencrypted Syslog over insecure networks is not a good basis for productive SIEM or SOC connections because log data can contain internal IP addresses, users, destinations, URLs or security events.

With TLS, the name of the Syslog destination is important. Without LINCE compliance mode enabled, Sophos Firewall checks the certificate Common Name against the Syslog server domain; in this standard case, the Subject Alternative Name is not used as a replacement. With LINCE enabled, either Common Name or Subject Alternative Name can match. If an IP address is entered in the firewall but the certificate only contains a DNS name, or if a certificate only matches via SAN, the connection may fail depending on the mode. For productive TLS Syslog destinations, plan a stable FQDN, a matching server certificate and a documented certificate renewal process.

At the same time, the target system must really understand the chosen procedure. Some SIEM integrations require a local collector and do not directly support the Secure log transmission firewall. Then the better solution is often: Firewall sends internally to the collector, the collector further encrypts to the cloud or SOC platform. This architecture should be included in the operating document, otherwise it will later be incorrectly assumed that all sections of the route are encrypted.

Select log types

After adding the Syslog server, the work is not finished. You have to specify under System services > Log settings which log types are sent to this destination.

Important: A firewall rule only creates meaningful traffic logs if Log firewall traffic is activated in the rule. For SSL/TLS Inspection, Log connections must also be active in the matching inspection rule. The log selection under Log settings then determines whether these logs are sent locally, to Sophos Central or to Syslog servers.

Typical log types for a SIEM:

• Firewall: allowed and rejected connections, rule matching, DoS events.
• IPS: Attacks detected or blocked.
• Web/Content filtering: Web Traffic, Categories, Web Policy Events.
• SSL/TLS inspection: TLS inspection decisions and errors.
• Web server protection: WAF events for published services.
• Authentication / Events: Admin, user and system events.
• VPN: Remote Access and Site-to-Site VPN Events.
• Active threat response: Hits from MDR Threat Feeds, NDR Essentials, Sophos X-Ops and Third-Party Threat Feeds.
• System health: CPU, memory, users, interfaces and partitions.

If DoS or spoof events are to be evaluated, the technical hardening itself should also be checked. The procedure is described in Check Sophos Firewall Spoof Protection and DoS settings.

If Third-Party Threat Feeds, NDR and Active Threat Response or WAF are used, the SIEM should specifically evaluate these events. Just sending logs is not enough. It requires clear search queries, alarms, responsibilities and tuning against false alarms.

Check parser fields deliberately

Sophos Syslog events contain different fields depending on the log type. For parsers and dashboards, log_id, log_type, log_component, log_subtype, severity, status, device_name, device_model, device_serial_id, fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, user_name and timestamps are especially relevant.

log_id is more than a random number. It consists of log type, component, subtype, severity and message ID. This helps when a SIEM should build stable detection rules, dashboards or normalizations instead of only searching free text.

For acceptance, do not only check whether raw data arrives. The decisive point is whether fields really arrive as separate fields in the SIEM. If fw_rule_id or nat_rule_id only remains inside raw text, later searches and alerts often work worse than expected.

An anonymized firewall event in raw format can look like this:

date=2026-07-01 time=14:23:11 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" device_name="SFOS-XGS" device_serial_id="C00000000000000" 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" dst_port="443" user_name="AVANET\\test.user"

The example does not replace the official field reference. It shows which information should be visible as separate fields during the parser test.

Typical starting set for SIEM pilot

For a pilot, a small, deliberate starting set is better than full activation without evaluation.

• Start: Firewall, Events, VPN. Check noise floor, rule events, admin and VPN visibility.
• Security: IPS, Web, Web server protection, Active threat response. Validate security use cases and parser fields.
• Operation: System health, DHCP, DNS, Authentication. Add operational and identity context.
• Fine tuning: additional modules as required. only activate if there is a search, alarm or audit purpose.

After each phase, it should be checked whether the SIEM recognizes the fields correctly and whether someone is actually using the new events. Unchecked log types are not added value, just additional volume.

Important visibility traps

In Syslog projects, many gaps do not arise in the transport, but beforehand: the firewall does not generate the expected event at all, the log type is not sent to the Syslog server or the SIEM interprets the fields incorrectly.

Rule and module logging

Firewall rules and SSL/TLS inspection rules must generate logging themselves. Under System services > Log settings you can choose whether these logs are sent locally, in Sophos Central or to Syslog server. If a firewall rule does not have Log firewall traffic, the Syslog server cannot display a complete firewall traffic history.

For web policy events, it is also relevant whether the associated firewall rule generates traffic logging. Otherwise, you may see fewer web or content filtering events in the SIEM than expected.

Log suppression

Sophos Firewall can suppress several identical consecutive log entries. This saves memory and processing, but can be confusing in SIEM use cases when counting values, frequency or burst behavior need to be evaluated. The function works on Log Viewer, Sophos Central and external Syslog servers.

Before a productive SIEM rollout, you should therefore determine:

• Which firewall events can be suppressed?
• Which detection rules do each individual connection need?
• Does the SIEM work with counted values ​​or only with individual events?
• How is it documented that log suppression is active?

Active Threat Response

Active Threat Response logs are particularly useful when using Threat Feeds, NDR Essentials or external feeds. Sophos differentiates between different match types, for example target hits for outgoing traffic and source hits for incoming traffic.

Important: Remote Source Match for incoming traffic is not automatically activated. If WAF or DNAT traffic is to be monitored against threat feeds, this visibility must be consciously checked. Otherwise, the incoming hits that a SOC often expects will be missing.

Wireless logs

Wireless logs are not automatically visible in the local Log Viewer. Access point and SSID logs should be sent specifically to Sophos Central or Syslog and examined separately in the target system if wireless events are relevant to operations, support, or compliance.

Multi-firewall environments

In environments with multiple firewalls, each event must be uniquely assigned to an appliance. Hostname, serial number, model and other fields are relevant for this. Depending on the log type, fields such as device_name, device_model and device_serial_id can appear in Syslog events. The SIEM should not only store these fields, but also make them usable for filters, dashboards and alarms.

Practical recommendations:

• Set firewall hostname cleanly.
• Consider location or role in hostname.
• Define a uniform facility or tagging strategy.
• In the SIEM check whether events can be filtered by firewall, location and cluster.
• Clearly distinguish between HA clusters and standalone firewalls.

This assignment is particularly important after a hardware replacement or restore. Otherwise, events in the SIEM look like new or duplicate systems.

For HA clusters, it should also be tested how events appear after a failover. What matters is whether operations and SOC continue to recognize the same location or whether a different host name, serial number or new asset suddenly appears in the SIEM.

Test configuration

After saving, the connection should be deliberately tested. A green target system alone does not prove that the right logs with the right fields arrive.

Test points:

1. Open System services > Log settings on the firewall.
2. Make sure the Syslog server is visible.
3. For a safe log type, activate Syslog as a test.
4. Trigger a defined action, for example a logged firewall rule or test access.
5. Check in the target system whether the event arrives.
6. Check fields such as time, hostname, device_name, source, destination, Rule ID, action and log type.
7. Check the time stamp and time zone in the SIEM.
8. For firewall events, check whether fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, status and log_occurrence are separately searchable.

For rule testing, Test firewall rule with Log Viewer, Policy Test and Packet Capture is useful. If no events occur at all, the cause is often not the Syslog transport, but rather deactivated logging as a rule or the wrong log type.

Meaningful test events

A good acceptance test creates not just any log, but exactly the events that will be searched for later.

• Logged test rule allows a connection: Source, Destination, Service, Action, Rule ID and Firewall clearly visible.
• Defined drop rule hits: Drop event appears with correct direction and time.
• VPN user connects and disconnects: User, tunnel type, time and firewall are detected.
• Web Policy or IPS Test Event: Log type, category or signature is correctly resolved by the parser.
• ATR or threat feed test if available: Hit appears in the expected use case and does not generate a false alarm.

Operations and monitoring

A Syslog connection is not a one-time catch. The operation must be monitored and checked regularly.

At least these points should be documented:

• Who is the owner of the log platform?
• Which firewalls send logs?
• Which log types are sent?
• What retention period applies?
• Which parsers, dashboards and alarms are attached to it?
• How do you recognize that logs are no longer arriving?
• How are format changes checked after firmware updates?
• How are certificate expirations, collector updates and parser changes monitored?
• Who evaluates false positives and adjusts SIEM rules?

After firmware updates, random checks should be made to see whether important events are still being parsed correctly. This is especially true for productive SIEM rules that rely on specific field names, log types or formats.

Detect Silent Log Failure

A Syslog connection can partially fail technically without anyone seeing an error immediately. The collector may still be running, but one log type is missing. Or raw data arrives, but after a parser update it is no longer split into the expected fields.

Operations should therefore have a simple outage indicator:

• Per firewall: define the expected minimum number of events per period, for example firewall or system events.
• Per important log type: check whether Firewall, VPN, Web, IPS or Active threat response still regularly deliver events.
• Per parser: monitor whether central fields such as device_name, Source, Destination, Action and Rule ID are still populated.
• Per collector: detect whether a local collector no longer accepts or forwards data.
• After changes: use firmware updates, parser updates, certificate changes, firewall restores and HA failovers as triggers for a new acceptance test.

Good SIEM operations therefore alert not only on suspicious events, but also on missing events. If a production firewall suddenly stops delivering logs, that is itself an operational event.

Troubleshooting

No logs arrive in the SIEM

First check IP address, port, routing and firewall rules between Sophos Firewall and Syslog server. Then check whether the correct log type is activated for the Syslog server under System services > Log settings.

If the Syslog server is accessible via a VPN tunnel or a separate management network, also check the route, SD-WAN policy, source NAT and counter firewall. From the Sophos Firewall perspective, Syslog is normal outbound traffic; it must actually reach the collector.

Only certain events are missing

Then the module or rule logging is often not active. For firewall rules, Log firewall traffic must be set. For web or SSL/TLS events, the appropriate policy or inspection rule logging must also be generated.

Logs arrive but are parsed incorrectly

Check format, parser version and firmware version. If switching between Standard syslog protocol and Device standard format (legacy), the SIEM parser must match it.

TLS-Syslog does not connect

Check FQDN, certificate, common name, subject alternative name, LINCE mode, certificate chain and port. In most environments without LINCE, the Common Name must match the configured domain; a name that only matches in the SAN is not sufficient. If the firewall expects a DNS name, but the Syslog server was only entered via IP address, the certificate check can also fail. Additionally check whether the target system really accepts TLS on the configured port.

If a SIEM provider does not directly support Secure log transmission, one should not try to rescue the parser with random formats. It is better to have a supported local collector, a different transport design or a clear decision as to which internal route remains unencrypted.

Timestamps are incorrect

Check NTP on the firewall, time zone in SIEM and parser logic. Incorrect times make correlation with endpoint, server or identity logs unreliable.

Too many logs or too much noise

Don’t deactivate everything immediately. First check which log types are really needed, which rules log unnecessarily and whether log suppression makes sense. Then reduce specifically.

Checklist

• Syslog server or SIEM is reachable.

• Transport, port and encryption are fixed.

• For TLS: FQDN, certificate, trust chain and renewal are checked.

• Format matches SIEM parser.

• Facility strategy is documented.

• Relevant log types are activated under System services > Log settings.

• Important firewall rules have Log firewall traffic active.

• SSL/TLS inspection rules generate their own logs if necessary.

• Log suppression is consciously evaluated and documented.

• Active threat response match types match the SIEM use cases.

• Data protection, access and retention period have been clarified.

• Pilot firewall, test events and SIEM parser have been validated.

• Test events arrive in the target system.

• Fields such as Hostname, device_name, Source, Destination, Action and Rule ID are recognized correctly.

• Important parser fields such as log_id, log_type, log_component, fw_rule_id, nat_rule_id, src_ip, dst_ip, user_name, severity and status are separately searchable.

• HA, restore or hardware replacement scenario is included in the SIEM mapping model if required.

• Timestamp and time zone are correct.

• Monitoring detects when no more logs are arriving.

• The parser function is checked after firmware updates.

• Monitoring detects when important log types or parser fields silently fail.

FAQ