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 stored centrally or at least reviewed regularly?
• 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 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.

MFA, roles and login security

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.

The practical setup is in Enable MFA for Sophos Firewall WebAdmin, VPN Portal and Remote Access. For WAF scenarios with user login, Secure Sophos Firewall WAF with MFA fits.

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, maintenance window, release notes review, HA planning and rollback criteria. 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.

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.

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 are a very useful addition when services are reachable through WAF, DNAT, VPN Portal or other public access paths. They can block known malicious IPs, domains or URLs earlier, before they reach the actual application or rule.

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.

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.

Logging, alerts and SIEM

Firewall rules without logging are often worthless for troubleshooting and incident response. For longer retention, the local Log Viewer usually isn’t enough. Depending on the environment, Sophos Central Reporting, Syslog, SIEM, MDR, XDR or NDR are useful.

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.

Compact hardening checklist

For a first review, use this order:

1. Check WAN access to WebAdmin, SSH, User Portal and VPN Portal.
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.
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, Syslog, alerts and regular reviews as an operating process.

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