Review Sophos Firewall Configuration Changes with Audit Trail

Starting with SFOS 22, Configuration Audit shows who changed a supported configuration, when the change occurred, and the before-and-after values. It is the right place to start when a firewall rule, host object, or interface looks different than expected after a change.

The quickest workflow is to check the status in the Device Console, download configuration-audit.log or search it in the Advanced Shell, correlate the change with the ticket and time window, and test the technical effect separately.

⚠️ The Audit Trail shows a logged change. It does not automatically prove that the change was approved, technically correct, or successfully tested, and it replaces neither a backup nor change documentation.

Review Configuration Audit in Four Steps

1. Check the Status in the Device Console

Configuration Audit is enabled by default. Run the commands in the Device Console, not in the Advanced Shell.

system configuration-audit show

If the function is disabled:

system configuration-audit enable

Disabling it is technically possible, but in production environments this should only be done for a documented reason and a limited period:

system configuration-audit disable

⚠️ Do not disable Audit Logging as a first measure simply because the file appears large or difficult to read. Especially after an incident, these entries may provide the decisive evidence of a change.

2. Download the Log File in WebAdmin

The file is named configuration-audit.log. In WebAdmin, it is available under:

Diagnostics > Tools > Troubleshooting logs

For a targeted analysis, select and download the individual file. A Consolidated troubleshooting report (CTR) is useful when Sophos Support also needs system status and additional logs. However, certain service subsystem logs in the CTR may be restricted by the configured line limit.

3. Search the Log File in the Advanced Shell

After signing in through SSH, select 5. Device Management, followed by 3. Advanced Shell. For example, search for an object name as follows:

grep -i 'LAN_to_WAN' /log/configuration-audit.log

Replace LAN_to_WAN with the actual rule, host, or interface name. New entries can be followed live with:

tail -f /log/configuration-audit.log

Stop the live output with Ctrl+C. For a static, page-by-page view, use less /log/configuration-audit.log. The XML output can be long. For a support case, save only the relevant excerpt together with its timestamp.

4. Review the Change and Its Effect Separately

The Audit Trail first answers: What was changed? A functional test must then show whether the change had the expected effect. For traffic issues, also use Log Viewer, Policy Test, and Packet Capture. The process is described in Test a Firewall Rule with Log Viewer, Policy Test, and Packet Capture.

What configuration-audit Records

configuration-audit.log records supported changes made through WebAdmin and the CLI in XML format. An entry may contain:

• configuration before and after the change
• timestamp
• administrator identity and source IP address
• console or access method used

The current scope covers firewall rules, IP Hosts or Hosts and services, and network interfaces in particular. For interfaces, Sophos lists physical, virtual, wireless, and Cellular WAN interfaces. Not every configuration page provides the same level of detail. A complete Audit Trail scope must not be assumed for NAT, routing, VPN, or other functions.

A description or ticket explains why an object is supposed to exist. The Audit Trail shows what was actually changed on a supported object. Both are needed for complete evidence.

What the Audit Trail Does Not Replace

• Traffic analysis: Log Viewer and Packet Capture remain essential for allowed or dropped connections.
• Backup and rollback: Major changes still require a current backup and a recovery path.
• Complete change management: Approval, responsibility, testing, and acceptance belong in the ticket or maintenance log.
• Configuration comparison: Sophos Firewall Config Studio compares complete configuration exports, but it does not read configuration-audit.log.

Evaluate a Change Reliably

Find and Document the Change

An efficient review process:

1. Establish the time of the issue or change, including the time zone.
2. Identify the affected object, such as the rule name, host, interface, or VLAN.
3. Search configuration-audit.log by object name, administrator, IP address, or time window.
4. Compare the old and new values.
5. Correlate the change with the ticket, maintenance window, and responsible administrator.
6. Save the relevant XML excerpt together with the time window and object name.

For a firewall rule, the source, destination, service, rule position, or enabled security features may have changed. The actual modification must be read from the entry. This list does not guarantee that every subfield is displayed identically in every build.

The following information is particularly useful for Sophos Support:

• exact time, including the time zone
• affected object and expected state
• actual symptoms
• administrator or Central user involved
• relevant before-and-after value
• ticket number and functional test performed

The complete XML file may contain internal IP addresses, object names, and administrator data. Store exports with access protection and check them for unnecessary customer data before sharing. For more guidance, see Collect Sophos Firewall Logs for Support and Analysis.

Test the Technical Effect

After a change to a rule, host, or interface, do not stop after finding the log entry:

1. Review the current configuration in WebAdmin.
2. Generate defined test traffic.
3. Check the rule ID, NAT, route, and return path in the appropriate tool.
4. For HA, also check the role status and synchronization.
5. Document the result and any deviations in the change record.

For changes involving NAT, routing, or VPN, configuration-audit.log may show only the supported objects involved. Validate the function itself through its current configuration, event and service logs, and Packet Capture if necessary.

Interpret Changes Made Through Sophos Central

Starting with SFOS 22.0 MR1, the Central user identity is logged when an individual firewall is changed through Sophos Central. Sophos confirms this information in the Firewall Log Viewer and in Sophos Central Logs and Reports. This does not automatically mean that the Central identity appears in configuration-audit.log in every case.

The Central Audit Logs are available under:

Reports > General logs > Audit Logs

The view shows 7 days by default and can display activities from up to 90 days. Search supports IP address and Modified by. The following rules apply to exports:

• CSV/PDF of current view: Includes the filters currently applied.
• CSV/PDF of past 90 days: Exports the past 90 days. The search filter applies, but the selected date range does not.

For longer retention, create the exports regularly and archive them securely. Central Firewall Reporting does not extend the 90-day limit of the general Central Audit Logs.

When the Task Queue Helps

The Task Queue is not general evidence for every Central change. The correct review path depends on the task:

• Individual firewall opened directly: Review Central Audit Logs and Firewall Log Viewer. For supported objects, also review configuration-audit.log.
• Firewall group policy: Review the status in the Sophos Central Firewall Management Task Queue. If the group policy push does not arrive locally, also inspect fwcm-updaterd.log.
• MDR Settings or MDR IOCs from the Firewall Configuration API: Use Firewall Task Queue and, if necessary, fwcm-api-executor.log.

Named Central users provide reliable attribution. Appropriate roles and MFA protect administrative access. The roles are explained in Sophos Central Administrative Roles for Firewall Management.

Consider HA and Retention

Sophos documents that Audit Logs are only generated when a device is Active. The implications depend on the HA mode:

• In Active-Passive mode, the appliance that was active at the time of the change is normally relevant.
• In Active-Active mode, the Auxiliary appliance can also be active and hold relevant node-local logs.
• After a failover, required time windows may be spread across different devices.

Logs and reports are not synchronized between HA nodes. For a complete analysis, document the HA mode, role changes, and time window, and download the Troubleshooting Logs separately from the relevant appliances. Cluster configuration management and synchronization are described in Set Up Sophos Firewall High Availability.

There is also no documented fixed local retention period of 7, 30, or 90 days for configuration-audit.log. Troubleshooting Logs rotate depending on the component, model, and allocated storage. Older rotations may be compressed and later deleted. For audit or compliance evidence, export the required files in time.

Operational Checklist

• Regularly check system configuration-audit show and keep Audit Logging enabled.
• Use named administrator accounts, appropriate roles, and MFA for administrative access.
• Document changes with the ticket, time window, object, and expected test.
• Prepare a backup and rollback plan before major changes.
• Search configuration-audit.log by time window, object, and administrator.
• Compare before-and-after values with the approved change.
• Validate the technical effect with Log Viewer and real test traffic.
• For Central, use Audit Logs, Log Viewer, or the appropriate queue depending on the task.
• For HA, consider the relevant nodes and the time of the failover.
• Export required audit data securely before it rotates.

FAQ