Sophos Firewall Hardening Guide: Close the WAN Portals and Lock Down Admin

Sophos Firewall appliances have been targeted for more than five years by attackers who exploit internet-facing user and admin portals, then plant root-level backdoors that survive firmware updates. Sophos X-Ops documented this in its Pacific Rim report: activity from December 2018 to March 2024 by China-based groups against Sophos firewalls and the older Cyberoam line, using flaws such as CVE-2020-12271, CVE-2022-1040 and CVE-2022-3236. The CISA Known Exploited Vulnerabilities (KEV) catalogue lists seven Sophos entries across Sophos Firewall (SFOS), XG, SG UTM, Cyberoam and the Web Appliance. This guide covers Sophos Firewall specifically: how administrators and users authenticate, device access profiles, API and directory credentials, logging, and a hardening baseline built from Sophos's own guidance. It is for network and security engineers who run Sophos Firewall, on-box or through Sophos Central. For general edge device principles, see the Edge Device Security Guide; this page does not repeat them.

Key takeaways

• Nothing administrative on the WAN zone. Sophos's hardening guidance is to leave no Device Access items ticked for WAN unless absolutely necessary, and the CVE-2022-1040 workaround was exactly that: keep the User Portal and Webadmin off the WAN.
• Keep automatic hotfixes on. "Allow automatic installation of hotfixes" is the default, and Sophos used it to patch and clean devices during the Pacific Rim campaigns; attackers tried to switch it off.
• Change the default admin password and add MFA. The built-in admin account cannot be renamed or deleted, its default credentials are well known, and Sophos recommends MFA or OTP for administrators and users.
• Use device access profiles for least privilege. The built-in Audit admin, Crypto admin and Security admin profiles, or custom profiles with None, Read-only or Read-write per area, avoid giving everyone the Administrator profile.
• Assume an exposed, unpatched firewall may be compromised. Pacific Rim persistence included a replaced SSH daemon, an LD_PRELOAD rootkit and a firmware upgrade hook, so rebuilding or replacing is sometimes the only safe answer.

How identity and access work in Sophos Firewall

Sophos Firewall has two populations of identities. Administrators sign in to the web admin console, the CLI (SSH or console) and the API. Users authenticate to the User Portal, VPN portal, captive portal and VPN connections, and their identity is used in firewall rules.

External authentication servers supported are LDAP, Active Directory, RADIUS, TACACS+, eDirectory and Microsoft Entra ID. Users from external directories appear under Authentication > Users only after their first sign-in to a service. Sophos's best practice article suggests considering Entra ID single sign-on for webadmin access, which brings your identity provider's MFA and conditional access to the console.

Two device access details are easy to miss. Firewall rules cannot control access to local services: only the Local service ACL does. And Sophos warns that requests arriving through the web proxy are treated as internal, so users with proxy access in any zone can reach the web admin console and portals even if those services are off for their zone. If you run the web proxy, restrict which hosts can use it.

Admin roles and privileged access

• Default admin: change the password at first setup (it cannot be a common or dictionary word), store it in a vault as break-glass, and use named administrator accounts for daily work. A one-time password change is enforced when upgrading from 18.0 MR3 or earlier or 17.5 MR14; keep the previous password, as Sophos notes that downgrading may require it.
• MFA: enable MFA or OTP for administrators and portal users. Sophos warns that losing the authenticator can lock you out and that MFA can be skipped or reset through CLI commands, which makes console and SSH access itself a privileged path to protect.
• Sign-in security: under Admin and sign-in security settings, block repeated unsuccessful sign-in attempts and enforce CAPTCHA. Sophos added a login CAPTCHA against credential stuffing during Pacific Rim.
• SSH: use public key authentication and turn off SSH password logins where possible; Pacific Rim includes intrusions through weak SSH credentials.
• Central and partner access: if a managed service provider runs the firewall through Sophos Central, review which partner accounts have access and with what role, as part of your Privileged Access Management Guide process.

Integrations, API tokens and service accounts

A firewall holds credentials for several other systems, and an attacker with root on the appliance can read them.

• Directory bind accounts: the LDAP, Active Directory and eDirectory server definitions each hold a bind account. Give it read-only rights on the user and group OUs needed, use LDAPS, and rotate it after any suspected appliance compromise. See the LDAP Security Deep Dive Guide.
• RADIUS and TACACS+ shared secrets: long random secrets, unique per firewall, recorded in your secrets inventory.
• API administrators: API access is off by default. When you enable it, create a dedicated administrator with a custom profile limited to the areas the tool changes, allow API access only for that account, and limit source addresses to the automation host.
• VPN credentials: site-to-site pre-shared keys and certificates are machine credentials. Prefer certificates, give each tunnel its own key, and track expiry. The Post-Quantum Readiness for VPNs and IKEv2 Guide covers longer-term IPsec planning.
• Syslog and SNMP: SNMPv3 credentials and syslog TLS certificates belong in the same inventory. Notifications can be sent by email and SNMPv3 traps.
• Configuration backups: backups contain the configuration and its secrets. Encrypt them, store them off the device and restrict who can download them.

After a confirmed or suspected compromise, rotate every one of these, not just administrator passwords. The Service Account Security Guide covers inventory and rotation.

Known exploited vulnerabilities and patching

1. Keep automatic hotfixes on and alert if the setting changes; Sophos's CVE-2022-1040 advisory notes no action was needed where it was enabled.
2. Check firmware at least monthly under Backup & firmware > Firmware or in Sophos Central, and deploy every maintenance release, since each may carry security fixes.
3. Schedule and test: stage the upgrade on a lab or HA auxiliary unit, take an encrypted configuration backup, and schedule production updates in Sophos Central for a quiet window. HA pairs let you upgrade without an outage.
4. Retire end of life hardware: Pacific Rim shows unpatched and end of life devices being reused as operational relay boxes. See the Edge Device End of Life Replacement Playbook.
5. Roll back: keep the previous firmware image available on the appliance and the configuration backup, and document the downgrade password requirement before you start.

Logging and detection

Sophos Firewall sends logs to up to five syslog servers (normally UDP 514, with TLS available) and to Sophos Central reporting. Log categories include Firewall (enable "Log firewall traffic" on each rule you want), Events (configuration, authentication and system activity), System health and IPS.

Device-level implants are hard to see from the device's own logs, which an attacker with root can alter. Correlate with upstream network telemetry, and use the indicators Sophos published on GitHub for Pacific Rim when hunting historic activity. Persistence techniques Sophos described map to T1574.006 (dynamic linker hijacking via LD_PRELOAD), T1554 (compromised host software binary, the replaced SSH daemon) and T1542.003 (bootkit, found in early-stage form only). The Edge Device Compromise Investigation Playbook covers the investigation.

Metrics:

• Number of firewalls with any Device Access service enabled on WAN (target: zero, or a documented exception).
• Percentage of firewalls with automatic hotfixes on and on the latest maintenance release.
• Percentage of administrator accounts with MFA, and number of accounts on the Administrator profile.
• Percentage of firewalls sending Events and IPS logs to the SIEM.
• Number of end of life Sophos or Cyberoam devices still in service.

Hardening baseline

1. Device access: untick every WAN service under Administration > Device access; disable admin interfaces on LAN or restrict them to trusted admin IPs with ACL exception rules.
2. Remote management: use Sophos Central or ZTNA instead of WAN HTTPS or SSH.
3. Portals: User Portal off on WAN; use the hardened containerised VPN Portal only while users need to update VPN configuration; MFA on all portals.
4. Accounts: default admin password changed and vaulted, named admins on least-privilege profiles, MFA or OTP, sign-in lockout and CAPTCHA, SSH keys.
5. Updates: automatic hotfixes on, monthly firmware check, every maintenance release deployed.
6. Rules: audit NAT and firewall rules, remove WAN to LAN and remote access rules that are not needed, avoid ANY to ANY rules, and never publish RDP to the internet. Use the Firewall Rule Review Checklist.
7. Protection: IPS on rules for incoming untrusted traffic, spoof prevention and DoS flags under Intrusion Prevention > DoS & spoof protection, country blocking where you do no business, and Sophos X-Ops threat feeds set to log and drop under Active Threat Protection.
8. Logging: syslog over TLS to the SIEM, Central reporting, and notifications configured under System services.

Small vs large estates: a single firewall in a small business gets most of the value from steps 1, 4 and 5 plus Sophos Central management. Estates of many firewalls should manage policy centrally, use custom profiles for delegated teams, and test configuration drift on a schedule, as covered in the Firewall Management Guide.

Common misconfigurations

• WAN admin left on after initial setup: HTTPS or SSH admin enabled on WAN "temporarily" for a remote installer and never removed.
• User Portal on WAN: CVE-2020-12271, CVE-2022-1040 and CVE-2022-3236 all reached the User Portal or Webadmin; it does not need to be on the internet.
• Everyone on the Administrator profile: no separation between the people who change rules and those who read logs.
• Hotfixes disabled for change control reasons: removes the vendor's fastest route to patch and clean the device.
• End of life Cyberoam or XG hardware still in service: no fixes, and a known target for relay box use.
• Patching without hunting: a patch does not remove an implant that survives firmware upgrades; investigate devices that were exposed and behind before declaring them clean.

Framework mapping

Practitioner checklist

• Untick all WAN services under Device access and restrict admin access on LAN to admin hosts.
• Manage remotely through Sophos Central or ZTNA, not WAN HTTPS or SSH.
• Turn the User Portal off on WAN and enable the VPN Portal only when needed.
• Change and vault the default admin password; give named admins least-privilege profiles with MFA.
• Enable sign-in lockout and CAPTCHA; use SSH keys and disable SSH password logins where possible.
• Confirm automatic hotfixes are on and alert if they are turned off.
• Inventory and rotate bind accounts, RADIUS secrets, API accounts and VPN keys.
• Send Events, Firewall and IPS logs to the SIEM over TLS syslog.
• Replace end of life Sophos and Cyberoam hardware.
• Hunt for persistence on any firewall that was exposed and unpatched.

Standards and references

• Sophos: Sophos Firewall Hardening Best Practices
• Sophos: Best Practices for Securing Your Firewall
• Sophos: Sophos Firewall Device Access
• Sophos: Device Access Profiles
• Sophos: Log Settings
• Sophos: Security Advisory for CVE-2022-1040
• Sophos X-Ops: Pacific Rim Timeline
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Edge Device Security Guide · Edge Device Exploitation by Threat Actors Guide · Edge Device Compromise Investigation Playbook · Firewall Management Guide · ZTNA Guide