Sophos Firewall Hardening: Best Practices for secure configuration

Sophos Firewall hardening means deliberately reducing unnecessary attack surface around the firewall itself and the services published through it. It is not one magic setting, but a repeatable operating process: limit management access, enforce MFA, keep firmware current, review rules, enable protection features and evaluate logs.

This article is the central entry point. It does not replace the detailed guides, but puts the most important best practices in order and links to the matching Avanet KB articles.

What to check first

The order matters in hardening. A perfectly tuned IPS policy helps little if WebAdmin is reachable worldwide from WAN or an old VPN portal is exposed without MFA.

The most important immediate checks:

• Is WebAdmin reachable from the WAN zone?
• Is SSH allowed only from trusted management networks?
• Is MFA active for admins, VPN Portal and Remote Access?
• Are firmware, hotfixes and pattern updates current?
• Are there DNAT, WAF or VPN accesses that are no longer needed?
• Do published services have IPS, WAF, threat feeds, logging and clear ownership?
• Are security-relevant logs retained independently of the firewall and monitored, with a defined owner and retention period?
• Is there a current, tested backup including the Secure Storage Master Key?

Secure management access

The most important hardening area is access to the firewall itself. WebAdmin, SSH, User Portal, VPN Portal, Captive Portal and local services aren’t normal firewall rules, but local services of the firewall. They must be deliberately restricted through Device Access and Local Service ACL.

Device Access and Local Service ACL

Under Administration > Device access, you define per zone which local services are reachable. For the WAN zone, only what is really needed should be active. Admin access and SSH should normally not be broadly exposed to the internet.

If remote administration is required, these variants are cleaner:

• Management through Sophos Fusion (formerly Sophos Central).
• Access through a dedicated management network.
• Access through VPN or ZTNA.
• Narrow Local Service ACL Exception Rules for fixed admin source IP addresses.

The concrete implementation is described in Secure Sophos Firewall access: configure Device Access correctly. If SSH is required, Connect Sophos Firewall via SSH also helps.

Avoid locking yourself out when creating a WAN exception. First sign in to and test an independent recovery path through the console, management LAN, admin VPN, or Sophos Fusion. Then click Add under Administration > Device access > Local service ACL exception rule. An adaptable example is WAN-Admin-203.0.113.10 with Rule position Top, IP version IPv4, Source zone WAN, the fixed public admin IP as Source network / host, the firewall’s WAN interface as Destination host, Services HTTPS and SSH only if needed, and Action Accept. 203.0.113.10 is a documentation address and must be replaced with the actual fixed admin IP. Also keep the existing session open, test access in a second session from that source, and only then remove the broader WAN permission for HTTPS or SSH in Local service ACL. If the test fails, leave the zone permission unchanged and correct the exception through the tested recovery path.

MFA, roles and login security

VPN Portal is not just for downloads: VPN clients and changed configurations are distributed through VPN Portal. SSO also needs the required WAN reachability on an ongoing basis: Microsoft Entra ID SSO in SFOS 22 and OpenID Connect SSO in SFOS 23. Do not close a still-required SSO path after downloads. Keep User Portal disabled on WAN and access it remotely through VPN. Protect VPN Portal access with appropriate, narrowly scoped ACLs, a valid certificate and brute-force monitoring. For OIDC, enforce MFA in the IdP, not through additional firewall OTP. The local OTP steps below apply to traditional authentication, not OIDC. Setup is covered in Entra VPN SSO and Google Workspace OIDC. After ACL or authentication changes, test a fresh sign-in and the actual VPN tunnel from the intended external network; if they fail, check ACLs, the certificate and redirect mapping rather than opening WAN access broadly.

MFA should be mandatory for administrators and remote access users. Local admin accounts, VPN Portal, User Portal and Remote Access VPN are particularly critical. MFA is only one part of login hardening, though. Named admin accounts, clear roles, strong password policies, limited login attempts and short session timeouts are just as important.

In SFOS 22, user configuration is under Authentication > Multi-factor authentication (MFA). Under One-time password (OTP), select All users or Specific users and groups, turn on Generate OTP token with next sign-in for app-based tokens, and select every service actually used under Require MFA for. Protect the built-in admin account separately under Administration > Device access > MFA for default admin. Before enforcing MFA, at least one named administrator account should have registered its token; verify issuance under Issued tokens. Then test a new sign-in while keeping an existing admin session open as a recovery path.

The practical setup is in Enable MFA for Sophos Firewall WebAdmin, VPN Portal and Remote Access. Set up Sophos Firewall administrators and profiles securely explains how personal local accounts, device access profiles, login sources, and offboarding work together. For WAF scenarios with user login, Secure Sophos Firewall WAF with MFA fits.

Check Remote Access VPN authorisation

Grant VPN access only to the users and groups that need it, and only to the required resources. Do not select the default fallback group Open group for this purpose. Users without a matching group assignment may land there, for example during AD synchronisation. Review members regularly and assign them to the correct groups. This default group is neither a fallback firewall rule nor the deliberately restricted IdP fallback group in the linked SSO guide. Provider-specific mapping remains covered there. For acceptance, test an allowed user, a fallback/unassigned user and a denied resource: only the intended access must work. If an unexpected test succeeds, correct group mapping and VPN/firewall permissions and repeat the test.

Firmware, hotfixes and recovery

A firewall is an edge system. Delayed updates are therefore not a minor cosmetic issue, but a real attack window. At the same time, updates shouldn’t be done blindly because remote sites, HA clusters, VPNs and productive NAT rules can be affected.

Make updates plannable

Firmware updates should be prepared with backup, a maintenance window, release notes review, HA planning, and rollback criteria. Check available maintenance releases regularly and deploy them promptly after approval. In current SFOS 22 versions, the WebAdmin page Backup & Firmware > Firmware no longer shows a separate hotfix section. The hotfix function still exists: Sophos installs hotfixes automatically by default and recommends not changing this setting. If the status must be checked, use system hotfix show in the Device Console. Hotfixes do not replace a regular update process. The process is described in Sophos Firewall firmware update: preparation and best practices.

The page retains no more than two firmware versions. A rollback boots the previous version with its corresponding earlier configuration; changes made since the version switch are lost. From SFOS 19.0 MR1, moving firmware requires Enhanced Support or Enhanced Plus after three free upgrades; hotfixes don’t require this support subscription. Therefore, verify the expected firmware, management reachability, VPNs, and critical publications before making further configuration changes after the update.

For larger version jumps, also check upgrade path, license, platform and known limitations. Check Sophos Firewall before SFOS 22 upgrade fits here.

Check backup and restore

Hardening doesn’t stop at prevention. A hardened firewall must also be recoverable. This includes a current backup, the backup password, the Secure Storage Master Key, a documented access path after restore and an acceptance test.

The details are in Create or restore Sophos Firewall backup. A complete recovery package is mandatory especially before firmware updates, migrations, reimage and hardware replacement.

A special compliance migration is FIPS 140-3 mode on Sophos Firewall: Enabling it performs a factory reset and requires a fully planned rebuild with FIPS-compliant VPN and certificate settings.

Reduce attack surface in the rule set

Many risks don’t come from exotic attacks, but from overly broad rules, old exceptions and published services nobody really owns anymore.

NAT, WAF and published services

Every service published through DNAT or WAF is a deliberately opened entry point. That may be necessary, but it must be planned narrowly: source, destination, service, NAT order, firewall rule, IPS/WAF policy, logging, test and owner belong together.

For published servers, Publish a server with DNAT on Sophos Firewall and Understand NAT on Sophos Firewall help. When web servers are published, Sophos Firewall WAF: publish web servers securely is the better baseline.

Firewall rules and segmentation

Rules with Any for source, destination or service aren’t automatically wrong, but they always need an explanation. For hardening, these questions matter most:

• Is the rule still needed?
• Is logging enabled?
• Is there a clearer source or destination?
• Is the rule positioned correctly before broader rules?
• Are admin, server, client, IoT, guest and backup networks separated cleanly?

The basics are in Understand and configure Sophos Firewall rules securely. To check a concrete rule, Test Sophos Firewall rules cleanly fits.

Enable protection features deliberately

Protection features only help when they match the rule, traffic and operating process. Blindly enabled features create false positives, performance issues or support cases. Disabled features, on the other hand, leave unnecessary attack surface open.

IPS, Spoof Protection and DoS

IPS should be used on incoming untrusted traffic and on relevant internal transitions. Matching IPS policies, logging, a false-positive process and a performance view are important. The implementation is in Set up and safely test Sophos Firewall IPS.

Spoof Protection and DoS Settings reduce implausible sources and simple flooding patterns. They must be tested carefully, especially with VoIP, VPN, high packet load or special routing designs. The matching article is Check Sophos Firewall Spoof Protection and DoS Settings.

Threat feeds for WAF and DNAT

Threat feeds supplement protection only for an established module and traffic path. From SFOS 22, matching the source IPv4 of incoming forwarded DNAT/WAF traffic against MDR, NDR and Third-Party Threat Feeds is documented. For local services such as VPN Portal, the established additional safeguard is source-IPv4 matching with supported Third-Party Feeds; this path does not pass through a transit firewall rule. Domain/URL indicators instead concern appropriate outgoing destination matching, not the source IP of an incoming sign-in. The DNS/IPS/Application Classification or web/TLS inspection path must be appropriate; complete HTTPS URL paths require decryption. IPv6 sources are not covered by this feed protection.

Unresolved X-Ops boundary: The ATR prose and SVG traffic matrix disagree about certain X-Ops match directions, particularly destination matching and local-source matching for outgoing traffic. Do not transfer MDR, NDR or Third-Party Feed claims to Sophos X-Ops, including for DNAT/WAF or local portals. Until authoritative clarification, do not rely on disputed feed effects: restrictive ACLs, firewall/WAF rules, patching and MFA remain independently necessary. Verify the module, direction, logs and actual effect only through authorised, controlled tests. MDR Threat Feeds and the NDR guide linked below provide further context for this boundary.

Monitor detects and logs matches but does not block; Block must be configured for the verified path. A feed match alone establishes neither blocking nor complete logging. Check the relevant ATR/firewall/WAF log together with the actual connection; allowlisting, false-positive handling and ownership remain necessary. The examples below apply only within these module/path boundaries.

Threat feeds are especially valuable for:

• public web servers behind WAF or DNAT,
• RDP, SSH or admin access that hasn’t yet been fully replaced by ZTNA,
• VPN and portal access with lots of internet noise,
• environments where country blocking alone is too coarse,
• customers who want to use curated third-party feeds in addition to Sophos X-Ops.

Operations matter: feed quality, action Monitor or Block, allowlist, false positives, logging and ownership must be clear. The configuration is described in Set up and safely operate Sophos Firewall Threat Feeds. For curated feeds, Cybora can be a useful component, especially when published services should be protected consistently against known bad sources.

Web, DNS, TLS and Zero-Day Protection

Web Protection, DNS Protection, TLS Inspection and Zero-Day Protection increase visibility and blocking power, but need clean planning. TLS Inspection shouldn’t start as an all-or-nothing project. DNS Protection must match the DNS paths used. Zero-Day Protection only helps when the relevant file types and policies are integrated sensibly.

Matching detailed articles are Create Sophos Firewall Web Protection with web policies, Set up Sophos DNS Protection with Sophos Firewall, Introduce Sophos Firewall TLS Inspection correctly and Understand and operate Sophos Firewall Zero-Day Protection.

Detection, logging and review

Hardening isn’t a one-time project task. Rules, users, portals, NAT exceptions and firmware versions change. Regular reviews and logs that don’t have to be searched for only after an incident are therefore required.

Health Check as a starting point

The Sophos Firewall Health Check is a good starting point because it makes risky configurations visible. Findings shouldn’t be applied blindly, but evaluated by risk, operational impact and local architecture.

In SFOS 22, open the Firewall health check widget in the Control Center or go to Monitor & analyze > Firewall health check. Data updates whenever a monitored configuration changes. Importantly, a finding can be manually marked compliant without fixing its cause. Validation must therefore confirm that the policy requirement is met, not merely that the displayed status has changed.

Good times for a Health Check:

• after initial setup,
• after migrations,
• before and after firmware upgrades,
• after larger rule changes,
• before audits,
• quarterly during operations.

Evaluate telemetry and Sophos Assistant separately

Under Administration > Admin and user settings, Sophos Adaptive Learning controls which usage and threat data the firewall sends to Sophos. This includes unclassified applications and data about IPS alerts, detected viruses, spam, and Active Threat Response findings. Baseline configuration and usage reporting is also enabled by default: The device periodically sends configuration, feature, error, and resource-usage data over HTTPS. Sophos states that it doesn’t collect user-specific or personalized information. Even so, document the decision consciously according to privacy requirements and the operating model instead of treating the option as a protection feature for local traffic.

Turn on Sophos Assistant, by contrast, only affects help text, smart tips, and configuration guides in WebAdmin. After changing the setting, sign out and sign back in. Turning off the assistant doesn’t reduce the network attack surface or automatically stop telemetry; evaluate the two settings separately.

Logging, alerts and SIEM

Firewall rules without logging are often worthless for troubleshooting and incident response. The documented baseline is central reporting in Sophos Fusion (formerly Sophos Central) plus a selected SIEM solution. Define event classes, recipients, an accountable owner, retention period and monitoring with a response path. Explicitly document any architectural exception: it must provide an equivalent path retained independently of the firewall and monitored; not every architecture needs duplicate destinations. Regular local Log Viewer review alone is insufficient. MDR, XDR and NDR are not interchangeable log archives. Use an authorised, harmless test event to check delivery to each intended destination, retrieval from the stored log and the monitoring/alert path. If delivery fails, correct event selection, connectivity and recipients and repeat the test. Also check retention and permissions at the destination.

Also select the required system events for email or SNMP under System services > Notification list. First configure the mail destination under Administration > Notification settings, or the SNMP agent and community or user under Administration > SNMP. After Save, a safe, controlled event should reach the intended recipient; if it does not, first check the destination, connectivity, and selected event class.

The technical Syslog setup is described in Send Sophos Firewall Syslog securely to SIEM. For central reports, Enable and operate Sophos Firewall Central Reporting fits. If NDR and Active Threat Response are relevant, Operate Sophos Firewall NDR and Active Threat Response helps.

Validate changes and roll back safely

Apply hardening in small, traceable steps. Before each group of changes, record the current value, owner, and intended recovery path. Then change only one area, such as Device Access, a firewall rule, or a threat-feed action. Test both the expected allowed path and a deliberately disallowed path, and inspect the relevant logs. Only then continue to the next area.

For rollback, restore only the most recently changed setting to its recorded starting value. For Device Access changes, keep both the existing admin session and a previously tested independent management path available. Do not delete the previous rule before its narrower replacement has passed validation. Start threat feeds with Monitor, review matches and possible false positives, and switch to Block only afterwards; if blocking causes problems, return to Monitor and add only verified exclusions. A full backup restore is not a convenient undo button, but the recovery path for larger failures.

Compact hardening checklist

For a first review, use this order:

1. Restrict WAN access to WebAdmin and SSH, keep User Portal disabled, and preserve and test required VPN Portal reachability for downloads and SSO.
2. Enable MFA for admins and Remote Access.
3. Clean up local admin accounts, roles and password policies.
4. Check firmware, hotfixes, pattern updates and support status.
5. Document backup, SSMK, restore path and recovery test.
6. Review DNAT, WAF and VPN publications for necessity; limit VPN groups/resources, do not authorise Open group, and test allowed and denied access.
7. Clean up rules with Any, missing logging or unclear ownership.
8. Enable IPS, Spoof Protection, DoS Settings and threat feeds deliberately.
9. Introduce web, DNS, TLS and Zero-Day policies in phases.
10. Establish Health Check, independently retained and monitored logs, delivery tests, alerts and regular reviews with an owner and retention period.

Common mistakes

WAN access remains open for convenience

WebAdmin or SSH access is opened for a support case and then forgotten. Exactly these temporary exceptions should be documented with expiry date, owner and follow-up check.

Threat feeds are enabled without an operating concept

Threat feeds are strong, but not maintenance-free. Without monitoring, allowlist and false-positive process, a legitimate partner, provider or cloud service can be blocked. Therefore, test first with Monitor or limited scope, then switch cleanly to Block.

Logging is missing on critical rules

If a public DNAT rule, WAF rule or VPN rule doesn’t log, there is too little visibility during an incident. At minimum, security-relevant entry points, admin access, deny rules and critical segment transitions should be traceable.

Health Check is treated as a one-time task

A good score after setup is not a permanent state. New rules, new VPN users, temporary exceptions and firmware changes can change the situation. Hardening needs a review rhythm.

FAQ