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?
• Have management access and published services been checked separately for IPv4 and IPv6?
• 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.

Check both address families

Restricted IPv4 reachability does not prove an equally restricted IPv6 path. For dual-stack, record WAN addresses, A and AAAA responses, routing, Device Access, Local Service ACL and published services for both address families. The IPv4 exception above does not replace this second check. IPv6 remains subject to the feature limits of the deployed SFOS version; IPv6 planning and acceptance covers the existing verification paths.

From an approved external source, check the management and application services actually offered over each available address family, then test an explicitly disallowed path. Allowed connections must reach the intended service; disallowed connections must remain blocked. Check the associated logs and return path separately. Do not accept a ping or a successful IPv4 test alone as evidence. Without a suitable IPv6 test path, IPv6 acceptance remains open and is not replaced by a broader rule.

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.

Keep CAPTCHA enabled by default, especially on login pages reachable from WAN or untrusted networks. It replaces neither MFA nor Block login; an incorrect CAPTCHA does not count as a failed login for that block. Change and restore CAPTCHA selectively describes a justified, approved VPN exception for WebAdmin or User Portal. Record the scope, target and starting value first, check access and MFA, then verify with show and a fresh login over the intended VPN path. Rollback restores the exact recorded value; deliberately returning to the enabled default uses enable. Global disabling is neither hardening nor a workaround for the SFOS 22.0 GA limitation described there. These exception commands do not affect VPN Portal or SPX Portal.

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.

Do not publish internal RDP services or administrative access directly to the internet. VPN or ZTNA is the preferred path for remote access to internal systems and remote administration. Threat feeds do not justify public exposure. IoT devices without a cloud-proxy design that require direct inbound NAT access need planned isolation, replacement or retirement, not permanent WAN exposure. A cloud proxy is not a blanket assurance of security either. Before an approved shutdown, clarify dependencies, operational effects and required service continuity with the owner.

For a concrete review, inventory one existing RDP publication and one IoT NAT mapping: destination host, service, allowed sources, firewall/NAT Rule IDs, owner and actual remote access need. Plan migration to VPN/ZTNA or approved retirement. An unavoidable existing publication remains only an explicitly documented, narrowly scoped temporary exception with a suitable IPS policy, current patches, logging, owner and expiry date; it is not equivalent to VPN/ZTNA. After migration, test fresh permitted connections and deliberately disallowed external access: the required service must work over the intended path and unwanted public reachability must be removed. If it fails, check rules, NAT, routing and the replacement path first rather than reopening WAN broadly.

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.

DMZ rather than the main LAN: Internet-facing servers belong in a separate segment and DMZ zone. Check the actual assignment under Network > Zones and Network > Interfaces; a VLAN or zone name alone does not enforce isolation. In Rules and policies > Firewall rules, deny DMZ-to-LAN by default, with only explicitly required, narrowly defined exceptions. An adaptable direction example allows WAN-to-DMZ web server access only for HTTPS and management-network-to-DMZ access only for the approved admin service, but no general DMZ access to the client LAN. Replace hosts and services with your own approved objects. Plan zones and interfaces, section Define traffic directions before creating rules, explains the model. Test permitted application access and denied DMZ-to-LAN connections using fresh flows, the expected Rule ID and Packet Capture where needed. For unexpected access, first check order, zones, objects and broader allowances. Before introducing production web-blocking rules, observe the unresolved HTTP/HTTPS Drop qualification under Action and logging in the rules article; no universal web block is promised here.

Internet access only for authenticated LAN users: Enable Match known users in the intended client rule and select authorised users/groups after establishing reliable user-to-traffic mapping. The Match known users section explains authentication and prerequisites. Servers, IoT and other traffic without user sign-in need separate, narrowly scoped rules; IP mapping alone is not authentication. No broad fallback rule should allow the same user traffic without identity checks. Test an allowed user and an unknown/unauthorised user, checking that user, group, Rule ID and actual access match the intended result. If they differ, check mapping, order and fallback rather than removing user matching.

Configure Security Heartbeat deliberately: Management registration alone does not isolate compromised endpoints. Synchronized Security Heartbeat explains the prerequisites: Network Protection, a managed licensed Sophos Endpoint, the same cloud-management account and enabled Heartbeat. Set Minimum source HB permitted and, where appropriate for internal destinations, Minimum destination HB permitted in the affected rules; do not use destination Heartbeat for WAN destinations. Green allows only Green, Yellow allows Green or Yellow, and No restriction also allows Red and devices without Heartbeat. Deliberately check the separate Block clients with no heartbeat and Block request to destination with no heartbeat options: devices that have never sent Heartbeat are blocked only when both are enabled. Devices without Sophos Endpoint and Web Exceptions that skip Policy checks prevent a blanket isolation guarantee. Plan an approved pilot with defined health-status/no-heartbeat cases, fresh connections and logs; do not create a production infection as a test. If the expected restriction is absent, check the rule match, prerequisites, status and exceptions and revert the last change selectively.

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,
• explicitly approved, time-limited RDP, SSH or admin migration exceptions while moving to VPN/ZTNA; only as additional protection within the established module/path, not a recommendation for public exposure,
• 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. How to use the assistant, check sources and understand the limits of guided workflows is explained in Use Sophos Assistant safely.

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. For dual-stack, perform this acceptance separately for IPv4 and IPv6; record Device Access, published services, and allowed and denied test paths.
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