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. A group cannot remain empty. To move a rule across a group boundary, first use Detach to remove it from the group, or move the entire group. You must therefore check the actual Rule position after adding, cloning or automatically creating rules.

If you manage rules through the API, SFOS 22 imposes several fixed limits. A Rule name can contain no more than 60 characters and must not contain a comma. For Rule groups, the API allows 150 characters in the name, 255 characters in the description and no more than 200 rule references. These limits apply to the API. The current WebAdmin help does not specify a character limit for the Description. It should nevertheless remain concise so that it is readable in the rule table.

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

A fully documented DNAT rule could look like this:

DNAT - Synology HTTPS
---
OWNER: NETOPS
LAST REVIEW: 2027-01-31
SOURCE: PARTNER_NETS
DESTINATION: WAN_Public_IP
SERVICE: TCP 5555 -> TCP 443
COMMENT: Access to Synology DSM only from defined partner networks
DOC: CHG-1842

This format also shows the Source, Destination and Service outside WebAdmin. If someone changes the rule, however, the Description must be updated as well. Otherwise, the two will conflict. We therefore recommend the compact template. If Configuration Audit reliably records changes, the Description only needs the purpose, owner, ticket and review. The detailed example can 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:

PREFIX_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 and DROP identify the action, DNAT identifies the firewall rule associated with a published service, and TEMP identifies temporary access. Here, DNAT does not refer to the NAT rule itself. 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 snapshot. Depending on the view, the current Sophos help states 12 or 24 hours without matching traffic. 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, activation status, Source, Destination, Services, Action and security profiles. If necessary, check the hosts and services in use through Object Usage; its counter shows configuration dependencies, not traffic for a rule.
3. Before selecting More options > Reset data transfer count, record the timestamp and current counter value in the change. Reset the counter only if the subsequent observation period also covers infrequent connections.
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 during an agreed window and monitor them. If expected traffic fails, re-enable the rule immediately, check its position and repeat the test with the expected Rule ID.
8. Document the decision, test and decommissioning in the change.

Do not delete the disabled rule until the agreed observation period has passed without disruption and the owner has approved its removal. A counter reading of zero is not proof if the observation period was too short. Nor is a missing log entry sufficient evidence. Log firewall traffic may have been disabled, a connection may have ended without a logged Destroy event, or the log destinations may not have been 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 show who actually changed it. In SFOS 22, Configuration Audit records the previous and new state along with the timestamp, administrator and source IP. Check its status in the Device Console with system configuration-audit show, not in the Advanced Shell. 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