Skip to content
Avanet

Send Sophos Firewall Syslog securely to a SIEM

Sophos Firewall

With Syslog, a Sophos Firewall sends events to an external log server, SIEM, or SOC. For the integration to be useful, four elements must align: transport, log selection, format, and parser. This article therefore starts directly with the configuration and then shows how to identify missing or incorrectly interpreted logs.

The local Log viewer remains important for live analysis. Central Firewall Reporting is suitable for reports in Sophos Central; Syslog is the right choice for self-managed retention, cross-vendor correlation, and SIEM detection.

Configure the Syslog server

Beforehand, define the destination IP address or FQDN, port, transport, expected log format, and a suitable parser. The firewall needs a route to the collector, and both systems need a working time source. UDP 514 is common; TCP 6514 is often used for TLS, but the collector configuration is authoritative.

  1. Open System services > Log settings.
  2. Select Add.
  3. Enter a unique name such as siem-primary.
  4. Enter the collector under IP address/domain.
  5. Select Port, Facility, Severity level, and Format to match the destination system.
  6. Enable Secure log transmission if the TLS collector is prepared.
  7. Save the configuration.
  8. Under Log settings, enable the required log types in the column for this Syslog server.

SFOS supports up to five external Syslog servers. Multiple destinations are useful when they serve different purposes, such as a local archive and an MDR collector. Sending every log blindly to every destination, however, increases volume, cost, and data-protection risk.

Facility, severity, and format

  • Facility: LOCAL0 to LOCAL7 can distinguish firewalls or site groups. The assignment must be identical in the collector and the documentation.
  • Severity level: The selection is the minimum severity. Error also sends Critical, Alert, and Emergency, but no Information or Notice events. This can cause login and normal operational events to be missing.
  • Format: The available options are Standard syslog protocol and Device standard format (legacy). What matters is the format expected by the SIEM parser. Changing it later can break searches, dashboards, and detection rules.

Secure log transmission

TLS is appropriate for production connections over untrusted or shared networks because logs can contain internal addresses, user names, URLs, and security events. Selecting the checkbox alone is not enough: the collector must accept TLS on the selected port, and both sides must be able to validate the certificates.

The following applies to the Secure Syslog connection documented by Sophos:

  1. The collector’s server certificate and its certificate chain must be trusted by the firewall.
  2. The configured FQDN must match the certificate. Without LINCE, SFOS checks the Common Name; with LINCE, either the Common Name or Subject Alternative Name can match.
  3. Download the Sophos CA Default under Certificates > Certificate authorities. The collector must trust the extracted Default.pem because Sophos uses this CA for its side of the connection.
  4. Only then enable Secure log transmission with the prepared TLS port.

In the official syslog-ng example, Default.pem and the external CA are stored in the collector’s CA directory; peer_verify(required-trusted) enforces certificate validation. Other collector products use their own trust stores. An FQDN that appears only in the SAN does not work without LINCE, and a configured IP address does not match a DNS-only certificate.

If a cloud SIEM does not directly support this method, the firewall can send logs internally to a local collector, which then forwards them over an encrypted connection. Any unencrypted segment should be short, segmented, and documented.

Define log types and visibility

The destination is enabled in two stages:

  1. The relevant rule or function must generate the event. Firewall rules require Log firewall traffic, while SSL/TLS inspection rules require Log connections.
  2. Under System services > Log settings, select the corresponding log type in the Syslog server’s column.

If either stage is missing, the collector cannot receive the event. A deliberately small set is sufficient for a pilot:

  • Firewall and Events: Rule events, administrator and user activity, and authentication, VPN, DHCP, and DNS events.
  • IPS, Content filtering, Web server protection, and Zero-day protection: Security and policy decisions.
  • Active threat response: Matches from MDR, NDR Essentials, Sophos X-Ops, and Third-Party Threat Feeds.
  • System health, Wireless, Heartbeat, and SD-WAN: Additional operational status when these modules are used.

Only add further modules when there is a search, alerting, or audit purpose. Anyone evaluating DoS events should also check the spoofing and DoS configuration. Third-Party Threat Feeds and NDR and Active Threat Response require specific search queries and alerts in addition to log transport.

Common visibility pitfalls

  • Log Suppression: SFOS can aggregate identical consecutive firewall events. This affects Log Viewer, Sophos Central, and Syslog. Parsers and detections must therefore also account for log_occurrence.
  • Active Threat Response: Remote Source Match for incoming DNAT or WAF traffic is not enabled by default. Without this selection, the corresponding source matches are missing.
  • Wireless: Access point and SSID logs are not available in the local Log Viewer. They must be sent specifically to Sophos Central or Syslog and checked there.
  • Content filtering and SSL/TLS: Selecting the log type does not replace logging in the associated firewall or inspection rule.

Check the format and parser

A parser test must show more than the arrival of arbitrary text. The key values must be searchable as separate fields. This shortened, anonymized example matches the Standard syslog protocol for a firewall rule event:

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"

By contrast, the legacy format uses fields including device, date, time, timezone, device_id, and priority. Fields such as status, user_name, nat_rule_id, or log_occurrence also depend on the log type and event. They must not be treated as mandatory for every standard-format event.

Depending on the use case, the following fields are particularly important for acceptance:

  • Identity: device_name, device_model, device_serial_id
  • Classification: log_id, log_type, log_component, log_subtype, severity
  • Policy: fw_rule_id, fw_rule_name, nat_rule_id
  • Connection: src_ip, dst_ip, ports, protocol, and user
  • Time and frequency: timestamp, time zone, and log_occurrence

log_id contains the log type, component, subtype, severity, and message ID. This makes detection rules more stable than plain-text searches. The fields supplied by a specific module must nevertheless be verified using a real event from that log type.

The Syslog module Events is not the same as configuration-audit.log. Before-and-after values are available there only for supported key objects such as firewall rules, interfaces, and IP hosts, not for every configuration change. The scope and analysis are covered in the article about Audit Trail logs.

Multiple firewalls and HA

In an environment with multiple appliances, every event must be clearly attributable to a firewall, site, customer, and HA cluster. The hostname, serial number, model, and facility should therefore be documented and filterable in the SIEM.

After an HA failover, restore, or hardware replacement, check whether events are still assigned to the existing asset or appear as a new or duplicate system. The same applies after changing the hostname or Syslog format.

Test the integration with real events

A green collector status proves neither that the correct logs are selected nor that the parser works. For acceptance:

  1. Document a pilot firewall and the configured format.
  2. Initially send Firewall and Events to the destination.
  3. Trigger a logged test rule with a defined source, destination, and service.
  4. In the SIEM, verify the device, time, log type, action, Rule ID, source, and destination.
  5. Generate a defined drop and a VPN login and logout.
  6. Test at least one security event from IPS, Content filtering, or Active threat response, provided the module is used in production.
  7. Then enable additional log types gradually and monitor the volume and parser result.

For rule testing, see the guide to Log Viewer, Policy Test, and Packet Capture. A negative test is also important: deliberately block an expected connection and verify that it appears as a drop with the correct rule.

For HA or migration projects, acceptance includes a failover, restore, or hardware replacement test. Afterward, the SOC must still be able to identify the device and site that generated the event.

Operations, retention, and outages

A Syslog integration needs an owner, defined retention, and a response to alerts. It must also be clear who assesses false positives and adjusts detection rules. Firewall logs can contain personal data, internal addresses, user names, URLs, and VPN activity. Access rights, deletion periods, tenant separation, and SIEM costs should therefore be clarified before a broad rollout.

Operations must detect missing data as well as attacks:

  • Monitor an expected minimum level of activity for each firewall.
  • Check important log types such as Firewall, Events, IPS, or Active threat response separately for freshness.
  • Monitor central parser fields for empty or suddenly renamed values.
  • Alert on certificate expiry and collector status.
  • Generate new test events after firmware, parser, and certificate updates.

The monitoring itself must also be tested: if data from an expected log type or firewall is deliberately interrupted, the defined outage alert must trigger.

Raw data without parsed fields is also an outage. A parser update can leave the transport intact while dashboards and detection rules no longer return any matches.

Syslog replaces neither local service logs nor a troubleshooting archive for support. NetFlow is suitable for v5 records from specifically logged firewall rules, while sFlow is suitable for interface samples and traffic patterns. Hardware and interface status can additionally be monitored using SNMP.

Isolate errors systematically

No logs arrive: Check the destination, port, transport, routing, and remote firewall. Then verify that the required log type is enabled in the Syslog column. If the collector is behind a VPN or management network, also consider the route, SD-WAN policy, and source NAT.

Only certain events are missing: First check logging in the affected firewall or inspection rule, then the log type under Log settings. For ATR, also check the required match type.

Raw logs arrive, but fields are missing: Compare the configured format, parser version, and firmware version. Standard and legacy fields must not be expected in the same parser profile.

TLS does not connect: Check the TLS port and server service, followed by the certificate chain, FQDN, Common Name, SAN, and LINCE mode. The collector must also trust the Sophos CA Default.pem. When certificates are changed, check both trust stores and the renewal process.

Timestamps are incorrect: Check NTP on the firewall and collector, the SIEM time zone, and parser normalization. Incorrect times prevent reliable correlation with endpoint, server, and identity logs.

Too many logs or too much noise: Do not simply disable everything. First evaluate unused log types, unnecessarily noisy rules, SIEM use cases, and log_occurrence; then reduce the selection selectively.