Document Sophos Firewall rules effectively

A firewall rule is not just a technical permission, but an operational decision: who can access what, through which service and for what reason? Without this context, old test, partner or migration rules often remain active for years because nobody can confidently assess their purpose.

The most important details should therefore be recorded directly in Rule name and Description. A ticket or wiki contains the details, while the rule itself provides the context needed for day-to-day operations. However, a description alone is not enough for reliable clean-up; the Rule ID, logging, usage data, owner confirmation and a controlled observation period are also required.

Understand and configure Sophos Firewall rules securely is the foundation article for the technical structure. This guide focuses on naming, documentation and review.

Where to enter the documentation

Go to Rules and policies > Firewall rules. First select IPv4 or IPv6, then edit an existing rule or create one via Add firewall rule > New firewall rule.

The following general settings are particularly relevant to the documentation:

• Rule name: a short, scannable name for the connection.
• Rule position: the rule’s position in the list, which is evaluated from top to bottom.
• Rule group: an organisational grouping for the rule.
• Description: the purpose, owner, ticket, review and any intentional exception.
• Log firewall traffic: generates logs and report data for matching connections.

Rule group makes the rule base easier to navigate, but does not change the evaluation logic. Sophos Firewall checks individual rules from top to bottom and stops at the first match. You must therefore check the actual Rule position after adding, cloning or automatically creating rules.

What belongs in the Description

Source, Destination, Services, Action and security profiles are already visible in the rule. The Description should not repeat these fields, but add the information that would otherwise be missing later.

A practical minimum standard consists of:

• Purpose: Which business or operational process requires this access?
• Owner: Which team is responsible for the application and the decision?
• Change or ticket: Where are the approval, test and technical details recorded?
• Review or expiry date: When will the rule be reviewed again or removed?
• Exception: Which intentional deviation or restriction does an administrator need to know about?

The creator and modification time do not need to be maintained manually if Configuration Audit and the change process reliably provide this information. A person’s name in the Description quickly becomes outdated; a permanent team or role is usually the better owner.

Compact template

For many rules, a single structured line is sufficient:

Purpose=ERP-access; Owner=APP-TEAM; Change=CHG-1842; Review=2027-01-31

For an intentional exception, add a short note:

Purpose=Partner-upload; Owner=INTEGRATION; Change=CHG-1910; Review=2027-01-31; Exception=defined partner networks only

Detailed practical example

For teams that use a more detailed convention, a documented DNAT rule could look like this:

DNAT - Synology HTTPS
---
AUTHOR: Patrizio
LAST MODIFIED: 24.06.2026 [PP]
SOURCE: WAN_CH, WAN_DE
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined countries
DOC: https://ticket/CHG-1842

AUTHOR and LAST MODIFIED are only useful if the team maintains them consistently. If Configuration Audit provides a reliable change record, purpose, owner, ticket and review are sufficient in the Description; the detailed example can then be kept in the change or runbook.

The Description is a signpost, not a complete CMDB. Long test logs, architecture decisions and rollback instructions belong in the linked ticket or runbook.

Name rules consistently

A good name can be understood in the rule list without opening the rule. The naming scheme does not need to be the same for every organisation, but it should remain consistent within an environment.

For example, the following has proved effective:

TYPE_SOURCE_DESTINATION_SERVICE

Examples:

• ALLOW_VLAN12_WAN_HTTPS
• ALLOW_VPNUSERS_SRVERP_HTTPS
• DNAT_WAN_SRVWEB01_HTTPS
• TEMP_PARTNER_SRVAPP_SFTP
• DROP_VLANIOT_INTERNAL_ANY

ALLOW, DNAT, TEMP and DROP make rules easier to scan. The source, destination and service show the direction. Abbreviations should be explained in an internal naming standard; otherwise, a compact name merely creates a new puzzle.

Avoid generic names such as Rule1, Test, Allow, Internet or Temp. Names that contain only a ticket number are equally unhelpful. Although CHG-1842 can be looked up, it explains neither the direction nor the service during an incident.

Temporary and published access

Temporary rules need a genuine expiry date and an owner. A prefix such as TEMP makes them easier to find, but does not replace a decommissioning process. Record the date both in the Description and in the ticket or change system so that a scheduled review does not depend solely on someone noticing it in the firewall.

For published servers, the firewall rule alone is not sufficient documentation. Record the DNAT rule, Firewall Rule ID, public service, internal target host and approval together in the ticket. In the firewall Description, a reference to the change and purpose is sufficient; NAT details should not be duplicated as a difficult-to-read second configuration in prose.

For the technical implementation, see Publish a server using DNAT on Sophos Firewall and Understand NAT on Sophos Firewall.

What does not belong in the Description

The rule description is visible to administrators and is not a secret store. Do not enter:

• passwords, API keys or tokens,
• private keys or preshared keys,
• personal data or confidential customer data without a compelling reason,
• complete access instructions for external users,
• long URLs containing session, token or confidential parameters.

An internal ticket identifier such as CHG-1842 is sufficient. Keep the actual link and sensitive details in the designated system with its own access controls.

Review existing rules in a controlled way

A missing Description indicates that a review is needed, but is not a reason to delete the rule immediately. The SFOS status Unused is also only a short-term signal: it means that the rule has not matched any traffic during the last 24 hours. Monthly jobs, emergency access or seasonal applications may still be legitimate.

Use the following controlled review process:

1. Flag rules with a missing Description, generic name, TEMP prefix or expired review date.
2. Record the Rule ID, position, Source, Destination, Services, Action and security profiles.
3. If necessary, select Reset data transfer count under More options and monitor the rule for a period that is representative of the application.
4. Under Reports > Dashboards > Traffic dashboard, check the data transferred for Allowed policies.
5. In Log viewer, search by Rule ID, source, destination and service.
6. Confirm the current business requirement with the owner and against the ticket.
7. Disable rules that are no longer required, monitor them for the agreed period and only then delete them.
8. Document the decision, test and decommissioning in the change.

A counter reading of zero is not proof if the observation period was too short. Equally, a missing log entry proves nothing if Log firewall traffic was previously disabled or if the local or external log destinations were not configured appropriately. System services > Log settings controls which firewall logs are stored locally, sent to Sophos Central or forwarded to syslog servers.

Trace changes and their effects

The Description explains why a rule is intended to exist. It does not prove who actually changed it. SFOS 22 can use Configuration Audit to record firewall rule changes, including the previous and new configuration, timestamp, administrator and source IP. Check its status with system configuration-audit show; the feature is enabled by default.

Three forms of evidence should work together in the operational process:

• Description and ticket: purpose, owner, approval and review.
• Configuration Audit: who changed which configuration and when.
• Log Viewer and Reports: which connections the rule actually processed.

Check Sophos Firewall Audit Trail logs explains Configuration Audit and its analysis in more detail. After each rule change, Test a firewall rule with Log Viewer, Policy Test and Packet Capture shows whether the expected Rule ID is actually applied.

Minimum standard for new rules

Before completing a change, a new rule should meet these requirements:

• a consistent Rule name,
• a deliberately checked Rule position and Rule group,
• Source, Destination and Services without an unnecessarily broad Any,
• a Description containing the purpose, owner, change and review,
• Log firewall traffic configured according to operational and data protection requirements,
• no secrets or personal details in the name or Description,
• a functional test confirming the expected Rule ID,
• an expiry and decommissioning process for temporary rules.

FAQ