Reviewing Sophos Firewall Audit Trail Logs

Audit Trail Logs help track configuration changes on the Sophos Firewall. This is important when a rule suddenly behaves differently after a change, an interface has been altered, a host object is missing, or during an audit, it is questioned who adjusted which setting and when.

Since Sophos Firewall v22, SFOS writes detailed entries in configuration-audit.log for this purpose. The logs not only show that something was changed but also the values before and after the change. With SFOS 22.0 MR1, traceability for changes via Sophos Central was improved, as the Sophos Central user identity is logged for single firewall changes.

Which Logging Article Fits?

Audit Trail Logs are only part of troubleshooting. Depending on the question, a different starting point might be quicker:

This separation prevents false expectations. The Audit Trail answers change questions. For packet flow, NAT, VPN, Web Protection, IPS, or service errors, you still need Log Viewer, Packet Capture, Service Logs, Central Reporting, or Syslog.

When Audit Trail Logs Help

Audit Logs are particularly useful when the question is not “why was traffic blocked?” but “who or what changed the configuration?”.

Typical cases:

• A firewall rule was changed, moved, or deleted.
• An IP Host, FQDN Host, or network object was adjusted.
• An interface or VLAN configuration looks different than documented.
• After a maintenance window, it is unclear which change caused a problem.
• An MSP or internal team needs to assign changes to multiple administrators.
• For compliance, NIS2, ISO 27001, or internal change processes, proof is required.

For normal traffic analysis, other tools remain more important. If you want to check which rule allowed or blocked a connection, Test firewall rule with Log Viewer, Policy Test, and Packet Capture is suitable. Audit Logs complement this analysis when a configuration change is suspected as the cause.

What configuration-audit Logs

configuration-audit records configuration changes made by administrators in WebAdmin or via the CLI. It captures, among other things:

• Configuration before the change.
• Configuration after the change.
• Timestamp.
• Administrator identity.
• IP address of the administrator.
• Console or access method used.

Entries are stored in configuration-audit.log and written in XML format. This makes them very detailed but not always easy to read. For a quick visual check, searching by object name, admin, IP address, or time window often suffices. For larger analyses, it may be useful to search the file externally or import it into a log analysis tool.

Current Functionality

The Audit Trail currently covers important configuration objects, particularly:

• IP Hosts.
• Firewall rules.
• Network interfaces, including physical, virtual, wireless, and Cellular WAN interfaces.
• From SFOS v22, Hosts and services are also supported areas.

This is already very helpful for many change analyses but not yet a complete change management system. Audit Trail Logs do not replace change documentation, tickets, or the four-eyes principle.

⚠️ Audit Logs prove that a change was logged. However, the logs do not automatically explain whether the change was technically correct, approved, or fully tested.

Check configuration-audit Status

Configuration is done in the Device Console, not in the Advanced Shell.

Check the status with:

system configuration-audit show

If the function is active, the firewall should report that Configuration Audit is enabled. If it is unclear whether you are working in the correct console, the distinction in Sophos Firewall Troubleshooting: Services and Logs helps.

Enable or Disable Audit Trail

Audit Logging is enabled by default. If it has been disabled, you can re-enable it in the Device Console:

system configuration-audit enable

Disabling is technically possible:

system configuration-audit disable

In productive environments, Audit Logging should normally remain active. If it is disabled for a specific reason, it should be documented and time-limited.

⚠️ Audit Logging should not be disabled as a first measure just because the file seems large or difficult to read. Especially in disruptions after changes, this data is often the crucial proof.

Download configuration-audit.log

The file is named:

configuration-audit.log

The download is done via the Troubleshooting Logs. The WebAdmin path is:

Diagnostics > Tools > Troubleshooting logs

There you can download individual log files or generate a Consolidated troubleshooting report (CTR). For targeted audit analysis, downloading the individual audit file is often more practical than a complete CTR.

If logs are to be collected for support or external analysis, Secure Sophos Firewall Logs for Support and Analysis is also suitable. For direct shell analyses, Connect to Sophos Firewall via SSH is relevant.

Evaluate Audit Trail

For a clean analysis, you should first narrow down the time period.

Practical procedure:

1. Determine the time of the problem or change.
2. Download configuration-audit.log.
3. Search for administrator, object name, rule name, interface, or IP address.
4. Compare the value before and after the change.
5. Match the change with ticket, maintenance window, or change documentation.
6. Additionally check Log Viewer and Packet Capture for traffic problems.

Audit Logs are particularly helpful for rule set problems. If a rule suddenly no longer applies, the Log Viewer only shows the current state. The Audit Trail can show whether the source, destination, service, security feature, rule position, or object content was changed shortly before.

Use Audit Trail Correctly in Support Cases

In support cases, the Audit Trail is strongest when combined with a specific time window and a reproducible symptom. A complete configuration-audit.log without context is difficult to evaluate. A short change protocol that provides the most important anchors is better.

If a change was triggered via Sophos Central, the Central Task Queue should also be checked. The Task Queue shows whether Central processed the order. The Audit Trail then shows what is traceable locally on the firewall.

Changes via Sophos Central

SFOS 22.0 MR1 improves traceability for configuration changes via Sophos Central. When a single firewall is configured via Sophos Central, the Sophos Central user identity appears in the audit context. This information is available in the firewall’s Log Viewer as well as in Sophos Central Logs and Reports.

This is important for environments with multiple administrators or MSP operations. A generic Central access is not sufficient for clean traceability. It should be clear:

• Which people have access to Sophos Central?
• Do admins work with their own user accounts instead of shared logins?
• Is MFA active in Sophos Central and on the firewall?
• Are Central Logs retained for a sufficient period?
• Is there a process to match changes from Central with tickets?

The connection between the firewall and Central is outlined in the article Connect Sophos Firewall with Sophos Central. For longer log retention, Enable Central Firewall Reporting is suitable.

Consider HA Clusters

In HA environments, according to documentation, Sophos generates Audit Logs only on the device that is currently active. Therefore, when analyzing after a failover, you must pay attention to the role change.

Important questions:

• Which firewall was active at the time of the change?
• Was there a failover shortly before or after?
• Are log files from both devices relevant?
• Was the change properly synchronized to the cluster?

For HA operation and log interpretation, Set up Sophos Firewall High Availability is suitable.

Validation After a Change

The Audit Trail shows that an object was changed. However, it must then be checked whether the change has the desired effect and does not cause side effects. Especially for firewall rules, interfaces, VPNs, and host objects, you should not stop at the Audit Log.

A sensible procedure after critical changes:

1. Find the change in the Audit Trail by time window and object name.
2. Compare before/after value with ticket or change documentation.
3. Check the affected firewall rule, NAT rule, route, or interface in WebAdmin.
4. Generate specific test traffic.
5. Cross-check with Log Viewer, Policy Test, and Packet Capture.
6. For Central changes, additionally check Task Queue and Central Logs.
7. For HA clusters, check role status and synchronization.

This turns the Audit Trail into reliable evidence rather than just a log finding. If the Audit Trail shows a change, but the test traffic still runs incorrectly, the cause often lies in rule order, NAT, routing, user assignment, security feature, or return path.

Limits and Common Pitfalls

Audit Log is Not a Backup

The Audit Trail shows changes but does not replace a configuration backup. Before major changes, a full backup and a rollback plan are still needed. This is described in the article Create or Restore Sophos Firewall Backup.

XML is Detailed but Not Pretty

The file is good for machines and precise comparisons, but cumbersome for quick readability. If you need to compare many changes, Sophos Firewall Config Studio or an external diff/log tool may be more useful.

Not Every Analysis Belongs in the Audit Trail

If a connection does not work, check the traffic first. Audit Logs are relevant when a change is suspected as the cause. For live troubleshooting, Log Viewer, Policy Test, Packet Capture, and Service Logs are often more direct.

Shared Admin Accounts Weaken the Evidence

If multiple people use the same admin account, the Audit Trail is less meaningful. Named Admins, roles, MFA, and clean Central users are therefore part of the operating model, not just a security extra.

Operational Checklist

• Check system configuration-audit show.
• Keep Audit Logging enabled.
• Use Named Admin Accounts instead of shared logins.
• Check MFA for WebAdmin, VPN Portal, and Remote Access.
• Document changes with ticket or maintenance window.
• Create a backup before major changes.
• After problems, search configuration-audit.log by time window and object name.
• Compare before/after values with the expected change.
• For rule, NAT, or VPN issues, supplement with Log Viewer and Packet Capture.
• For HA clusters, consider active node and failover timing.
• Match Central changes with Sophos Central Logs and Reports.

For MFA on the firewall, Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access is suitable. For management access, Properly Configure Device Access should also be checked.

FAQ