Send Sophos Firewall Syslog securely to a SIEM

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 Fusion (formerly 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, expected log format, and a suitable parser. The firewall needs a route to the collector, and both systems need a working time source. SFOS normally uses UDP 514 for Syslog. There is no separate transport selector in this form: Secure log transmission turns TLS-encrypted transmission on or off. Sophos uses port 6514 in its official TLS syslog-ng example; the port and listener must always match your collector.

Open System services > Log settings.
Select Add.
Enter a unique name such as siem-primary.
Enter the collector under IP address/domain.
Select Port, Facility, Severity level, and Format to match the destination system.
Enable Secure log transmission if the TLS collector is prepared.
Save the configuration.
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: The choices include DAEMON, KERNEL, USER, and LOCAL0 to LOCAL7. For example, you can assign LOCAL1 and LOCAL2 to two firewalls. Keep the assignment consistent in the collector and operations documentation.
Severity level: The selection is the minimum severity. Error also sends Critical, Alert, and Emergency, but no Information or Notice events. Debug includes every severity. Setting the minimum too high can hide sign-ins and routine operational events.
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.

Facilities identify a log’s origin: DAEMON means processes running as services, KERNEL means kernel processes, and USER means processes started by signed-in users. LOCAL0 through LOCAL7 are for custom assignments. For severity, Alert is more severe than Critical and requires immediate action. Standard syslog protocol was previously called Central Reporting Format; Central Reporting uses only this format. In Device standard format (legacy), the number of data fields varies by module.

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:

The collector’s server certificate and its certificate chain must be trusted by the firewall.
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.
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.
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.

Before enabling LINCE for this purpose, review the certification boundary, permitted algorithms, and SSH restart of LINCE mode. The mode isn’t merely a syslog switch and must not be enabled without independent administrative access.

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.

Prepare a TLS collector with syslog-ng

This example requires a Linux collector running syslog-ng, enabled TLS support, and a server certificate issued by an external CA. The firewall is the sending client. ExternalCertificate.pem is the server certificate, ExternalPrivateKey.key its private key, and ExternalCA.pem the issuing CA. These are example filenames; adapt paths and certificates to your collector. Keep the private key protected on the collector; the firewall CA’s private key is not required.

Check the existing CA under Certificates > Certificate authorities > Default. Its name cannot be changed. Country name, State, and Locality name describe the country, region, and city; Organization name and Organization unit name identify the owner and department. Common name contains a name or FQDN, and Email address a contact. Private key password allows an existing CA password to be changed. Key type offers RSA or Elliptic curve: select Key length for RSA or Curve name for Elliptic curve; Secure hash sets the hash algorithm. Key length is the RSA key size in bits; larger keys provide more security margin but require more processing. Example CA identity values are Example AG, IT Security, and fw01.example.com; replace them with your environment’s owner, department, and approved naming convention. These CA attributes are not the collector’s server certificate and do not replace its matching FQDN.

Protect the existing CA: Do not change or regenerate the Default CA solely for Syslog. Plan any necessary CA change with a backup, maintenance window, and checks of dependent services; renewing the Default CA explains the consequences. Updating its settings with Save automatically regenerates the Default CA and changes the trust anchor. Save only approved attribute changes in the planned maintenance window. Then use the download button to download the tar.gz archive and extract the public CA certificate Default.pem.

On the collector, place Default.pem and ExternalCA.pem in /etc/syslog-ng/ca.d/. Place ExternalCertificate.pem and ExternalPrivateKey.key in /etc/syslog-ng/cert.d/. Check directories and existing files first; do not overwrite certificates without planning. Only the responsible service and authorized administrators should be able to read the private key.

Run the following commands on the Linux collector, not in the SFOS Device Console. The first reads the certificate. The second creates a symlink in the CA directory and requires write access there:

cd /etc/syslog-ng/ca.d/
openssl x509 -noout -hash -in Default.pem

Use the actual returned hash, not blindly 52412b66. For the example output 52412b66, the command is:

ln -s Default.pem 52412b66.0

If a .0 entry already exists, check its target instead of overwriting it. Recheck the hash and mapping after a certificate change.

This syslog-ng.conf example shows a TLS listener and two local outputs. @version: 3.15 is the documented example’s version declaration, not a recommendation to install an obsolete release. Check syntax, modules, and the declaration against the installed syslog-ng version before use. Integrate this into the existing collector configuration rather than replacing its other sources and destinations.

@version: 3.15
@include "scl.conf"
source s_src {
    network(ip(0.0.0.0) port(6514)
        transport("tls")
        tls( key-file("/etc/syslog-ng/cert.d/ExternalPrivateKey.key")
             cert-file("/etc/syslog-ng/cert.d/ExternalCertificate.pem")
             ca-dir("/etc/syslog-ng/ca.d")
             peer_verify(required-trusted))
    ); };
destination d_local {
    file("/var/log/messages");
    file("/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3));
};
log { source(s_src);
    destination(d_local);
};

0.0.0.0 binds all IPv4 addresses on the collector. Prefer the intended receiving address for production and restrict TCP 6514 to the sending firewalls through the host firewall. Port 6514 must match the SFOS entry. key-file and cert-file specify the server identity, and ca-dir the two CA certificates; do not disable peer_verify(required-trusted) to work around errors. The file destinations provide raw logs and an additional key-value output with millisecond precision; adapt paths, permissions, rotation, and storage capacity to your operation.

Before starting, check the collector configuration with the installed version’s validation function. Start the service or apply changes in a controlled, approved window; revert to the backed-up configuration if problems occur. Then configure the collector, port 6514, and Secure log transmission under System services > Log settings > Add on SFOS and click Save. Select the required modules in the server’s column. Success means a TLS connection without trust errors, a deliberately generated firewall event in the configured output files, and correctly parsed SIEM fields. Validate log receipt on the intended appliance and collector before rollout.

Define log types and visibility

The destination is enabled in two stages:

The relevant rule or function must generate the event. Firewall rules require Log firewall traffic, while SSL/TLS inspection rules require Log connections.
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.

ATR scope: Enable remote-source logging only for established supported combinations of module and traffic path. Sophos’s ATR prose and SVG traffic matrix disagree about X-Ops match directions; this conflict remains unresolved. Statements about MDR, NDR, or third-party feeds do not establish equivalent X-Ops support. Keep restrictive firewall, DNAT/WAF, and Device Access controls independent of disputed feed behavior. Disputed cases require authorised, controlled verification of module, match direction, logs, and actual effect, plus reliable clarification; until then, protection must not depend on the disputed behavior. NDR and Active Threat Response provides the safe context.

XML API: Keep collector settings, log selection, and suppression separate

Anyone managing Syslog through the XML API must treat these three layers separately. The add/update examples for SFOS 22.0 and SFOS 23.0 distinguish between:

Collector settings: Destination address, port, TLS, facility, severity, and format determine the recipient and transmission. Creating or selecting a collector does not automatically enable all logs.
Dispatch by group and submodule: Within LogSettings, SendLogs represents the group level; individual submodules can override this selection. The example explicitly warns not to specify SendLogs when all submodules are listed. Do not therefore conflate these forms into blanket enablement. For PolicyRules, the example comment identifies Disable as the default; this does not imply automatic enablement of all rule events. Logging in the respective rule is also required.
Suppression: The example lists Log_suppress separately from dispatch. Aggregating repeated events is not the same as selecting their recipient or a severity filter.

The parameter table lists Name twice and describes the second row as the suppression status; it also literally gives uiui as the default. This is not a reliable basis for an operational default or for silently renaming the field. Do not derive a complete suppression payload from this; first clarify ambiguous API fields using the help for the specific build or Sophos Support. Before and after an approved change, generate the same representative events and compare raw logs at the collector, parser fields in the SIEM, and the expected log types and log_occurrence. An existing connection alone does not prove that the correct logs are selected.

Common visibility pitfalls

Log Suppression: SFOS can aggregate identical consecutive firewall events. This affects Log Viewer, Sophos Fusion, 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, corresponding source matches are missing on supported module/traffic paths. Apply the ATR scope above when investigating missing match types too; selecting the option does not prove support for disputed X-Ops directions.
Wireless: Access point and SSID logs are not available in the local Log Viewer. They must be sent specifically to Sophos Fusion 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.
Web proxy: For web traffic on ports 80 or 443, the firewall log can show Allowed while Web Filter blocks the same request. Correlate the firewall and Web Filter events to determine the effective policy decision.

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. The following list is a use-case-dependent checklist, not a universal mandatory schema. Define required fields separately for each enabled log type using its version-matched schema and a representative real event. Rule and NAT fields apply only to the corresponding confirmed event types; evaluate connection and user fields and log_occurrence only when supplied. Missing fields that do not apply to the event type must not cause valid events to be dropped or classified as parser failures.

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 twelve characters have fixed positions: characters 1 and 2 form the Log Type ID, 3 and 4 the Component ID, 5 and 6 the Subtype ID, character 7 the Priority ID, and characters 8 through 12 the Message ID. Therefore, 010101600001 is read as 01 / 01 / 01 / 6 / 00001. A parser must preserve leading zeros and fixed field widths; also evaluate log_type, log_component, log_subtype, and severity as a cross-check.

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.

In the documented example 010101600001, the first 01 means Security policy, the second 01 Firewall rule, the third 01 Allowed, 6 Information, and 00001 Firewall traffic allowed. Fixed-position IDs and output text fields serve different purposes; do not derive the text fields from a numeric ID without verification. Other Message IDs require a syslog reference catalog matching your SFOS version; the breakdown above does not explain every event type.

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. In SFOS 22.0, device_name identifies the hostname of the firewall that produced the log. After upgrading, verify that the parser ingests this field instead of continuing to rely only on device_serial_id or the Syslog header as its asset key.

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:

Document a pilot firewall and the starting state: server name, destination, port, TLS, facility, severity, format, and every log type enabled in that server’s column.
Initially send Firewall and Events to the destination.
Trigger a logged test rule with a defined source, destination, and service.
In the SIEM, verify the device, time, log type, action, Rule ID, source, and destination.
Generate a defined drop and a VPN login and logout.
Test at least one security event from IPS, Content filtering, or Active threat response, provided the module is used in production.
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.

Roll back a change without creating a data gap

Do not change the format, minimum severity, and log selection at the same time. If one of the five server slots is free, add a second destination for a parser or collector migration and run both in parallel first. This lets you compare raw data, populated fields, timestamps, and volume without touching the working destination.

Only after acceptance should you clear the log types in the old destination’s column. Keep its server entry for an agreed observation period. If events are missing, parsing fails, or volume is unexpected, re-enable exactly the previously documented log types there and undo the selection on the new destination. If no server slot is free, record the current values before each individual change and restore them in full if it fails; do not delete the entry or change the parser at the same time.

API deletion is not the same as disabling the log column: The delete tables for SFOS 22.0 and SFOS 23.0 list only Name as non-mandatory, but describe it as the suppression status and show no target selector. This contradictory table establishes neither safe target selection when the name is omitted nor equivalence between deleting a collector and disabling its log types. Keep the working collector during migration. Before an API deletion, the unambiguous, approved identity of the entry to be removed and the deletion syntax must be clarified using the API help for the specific build or with Sophos Support; do not guess a selector.

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.

First establish whether the module and traffic path are supported. Apply the ATR scope above: missing logs do not resolve the X-Ops conflict, and disputed directions are not a reason to simply enable additional match types.

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.