Send Sophos Firewall Syslog 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 when logs need to be retained for longer periods, centrally searched, correlated with other systems, or used for audits and incident response.

The local Log viewer is useful 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 when there is a dedicated SIEM, a SOC, a managed detection process, or a cross-vendor log architecture.

Which Logging Article Fits?

Logging on Sophos Firewall consists of several layers. Depending on the question, Syslog is not always the best starting point:

This keeps the evaluation clean: The Log Viewer answers the current packet 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 is Useful

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

Typical use cases:

• Central log retention over 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

For acute troubleshooting cases, local logs remain important. Which local log file belongs to which firewall module is detailed in Sophos Firewall Troubleshooting: Services and Logs. If logs need to be secured for support or external analysis, Secure Sophos Firewall Logs for Support and Analysis is suitable.

Syslog, Central Reporting, or Local Logs?

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

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

Prerequisites

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 defined, often UDP 514 or TLS on a custom port.
• Firewall can route and reach the Syslog server.
• A suitable parser or at least a raw data repository exists in the target system.
• Retention period and data protection requirements are defined.
• It is clear which log types are really needed.

For external or cloud-based SIEM targets, special attention should be paid to transport encryption, source IP, routing, DNS, and certificate verification.

Clarify Data Protection, Retention, and Responsibility

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

Before rollout, clarify:

Especially in MSP, SOC, or MDR models, this responsibility should not remain open. A SIEM without clear ownership generates data but no reliable response.

Plan Rollout in Phases

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

A sensible procedure:

1. First, select a pilot firewall.
2. Document hostname, time source, firmware version, and log format.
3. Configure the Syslog target with secure transport.
4. Start with a few log types, such as firewall, events, and VPN.
5. Generate defined test events and check them in the target system.
6. Validate parsers, fields, timestamps, time zone, and device_name.
7. Observe log volume and noise over several days.
8. Then add more log types like IPS, web, WAF, active threat response, or system health.
9. Only after a successful pilot, roll out to additional firewalls.

With multiple firewalls, it is important not only to check if data arrives. It is crucial whether each event is assigned to the correct location, device, HA node, customer, or tenant.

Add Syslog Server

Configuration is done in the Sophos Firewall web interface.

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

Sophos Firewall can configure multiple external Syslog servers. The current documentation provides for up to five Syslog servers. However, you should not randomly connect every target but determine the purpose behind each target.

Important Settings

Facility

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

It is important that SIEM rules, parsers, and documentation use the same logic. If each firewall randomly uses a different facility, evaluation becomes unnecessarily difficult.

Severity Level

The severity determines from which level of severity logs are sent. For security and troubleshooting purposes, a too high threshold is dangerous because important information or notice events may be missing. For very noisy environments, a too low threshold can generate unnecessary noise.

A pilot with a broader log selection is usually sensible, followed by a conscious reduction based on actual hits and SIEM use cases.

Format

According to current documentation, Sophos Firewall offers two formats:

• Standard syslog protocol
• Device standard format (legacy)

For new integrations, it should first be checked which format the target system or existing parser expects. If a SIEM already has a Sophos Firewall parser, its expectation is decisive. A format change after going 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. For 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. Therefore, before going live, not only should the checkbox be set in the firewall, but also the certificate name, trust chain, port, parser, and renewal process of the Syslog target should be checked.

For internal labs, UDP may be technically sufficient. For productive SIEM or SOC connections, unencrypted Syslog over insecure networks is not a good foundation, as log data can contain internal IP addresses, users, targets, URLs, or security events.

With TLS, the name of the Syslog target is important. Depending on the mode, Sophos checks the Common Name or the Subject Alternative Name of the certificate against the domain of the Syslog server. If an IP address is entered in the firewall, but the certificate only contains a DNS name, the connection may fail. Therefore, for productive TLS Syslog targets, a stable FQDN, a suitable server certificate, and a documented certificate renewal should be planned.

Select Log Types

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

Important: A firewall rule only generates meaningful traffic logs if Log firewall traffic is enabled in the rule. For SSL/TLS Inspection, logging must also be active in the appropriate inspection rule. The log selection under Log settings then determines where these logs are sent.

Typical log types for a SIEM:

If DoS or spoof events are to be evaluated, the technical hardening itself should also be checked. The procedure is detailed 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, alerts, responsibilities, and tuning against false alarms.

Important Visibility Pitfalls

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

Rule and Module Logging

Firewall rules and SSL/TLS inspection rules must generate logging themselves. Under System services > Log settings, you then choose whether these logs are sent locally, to Sophos Central, or to Syslog servers. 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 multiple identical consecutive log entries. This saves storage and processing but can confuse SIEM use cases if count values, frequency, or burst behaviour are to be evaluated. The function affects Log Viewer, Sophos Central, and external Syslog servers.

Before a productive SIEM rollout, it should therefore be determined:

• Which firewall events may be suppressed?
• Which detection rules need every single connection?
• Is the SIEM working with count values or just individual events?
• How is it documented that log suppression is active?

Active Threat Response

Active threat response logs are particularly useful when threat feeds, NDR Essentials, or external feeds are used. Sophos distinguishes between different match types, such as target hits for outgoing traffic and source hits for incoming traffic.

Important: Remote source match for incoming traffic is not automatically active. If WAF or DNAT traffic is to be monitored against threat feeds, this visibility must be consciously checked. Otherwise, exactly the incoming hits that a SOC often expects may be missing.

Wireless Logs

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

Multi-Firewall Environments

In environments with multiple firewalls, each event must be clearly assignable to an appliance. For this, hostname, serial number, model, and other fields are relevant. The SFOS Syslog guide describes fields such as device_name, device_model, and device_serial_id.

Practical recommendations:

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

Especially after a hardware replacement or restore, this assignment is important. Otherwise, events in the SIEM may appear as new or duplicate systems.

Test Configuration

After saving, the connection should be consciously tested. A green target system alone does not prove that the correct logs with the correct fields are arriving.

Test points:

1. Open System services > Log settings on the firewall.
2. Ensure the Syslog server is visible.
3. Temporarily enable Syslog for a harmless log type.
4. Trigger a defined action, such as a logged firewall rule or a test access.
5. Check in the target system if the event arrives.
6. Check fields like time, hostname, device_name, source, destination, Rule ID, action, and log type.
7. Check timestamp and time zone in the SIEM.

For rule tests, Test Firewall Rule with Log Viewer, Policy Test, and Packet Capture is helpful. If no events are generated, the cause is often not the Syslog transport but disabled logging in the rule or the wrong log type.

Operation and Monitoring

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

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 alerts are linked to it?
• How is it detected if no logs are arriving?
• How are format changes checked after firmware updates?
• Who evaluates false alarms and adjusts SIEM rules?

After firmware updates, it should be checked randomly whether important events are still parsed correctly. This is especially true for productive SIEM rules that rely on specific field names, log types, or formats.

Troubleshooting

No Logs Arrive in SIEM

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

Only Certain Events Are Missing

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

Logs Arrive but Are Parsed Incorrectly

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

TLS Syslog Does Not Connect

Check FQDN, certificate, Common Name, Subject Alternative Name, certificate chain, and port. If the firewall expects a DNS name, but the Syslog server is only entered by IP address, the certificate check may fail. Additionally, check if the target system really accepts TLS on the configured port.

Timestamps Are Incorrect

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

Too Many Logs or Too Much Noise

Do not immediately disable everything. First, check which log types are really needed, which rules log unnecessarily much, and whether log suppression is sensible. Then reduce selectively.

Checklist

• Syslog server or SIEM is reachable.
• Transport, port, and encryption are defined.
• Format matches the SIEM parser.
• Facility strategy is documented.
• Relevant log types are enabled under System services > Log settings.
• Important firewall rules have Log firewall traffic active.
• SSL/TLS inspection rules generate their own logs if needed.
• Log suppression is consciously evaluated and documented.
• Active threat response match types fit the SIEM use cases.
• Data protection, access, and retention period are clarified.
• Pilot firewall, test events, and SIEM parser have been validated.
• Test events arrive in the target system.
• Fields like hostname, device_name, source, destination, action, and Rule ID are correctly recognized.
• Timestamps and time zone are correct.
• Monitoring detects if no logs are arriving.
• Parser function is checked after firmware updates.

FAQ