Skip to content
Avanet

Secure Sophos Firewall access: configure Device Access

Under Administration > Device access, Sophos Firewall defines from which zones local services on the firewall are reachable. These include HTTPS for WebAdmin Console, SSH for CLI access, Ping, DNS, User Portal, VPN Portal and other services.

This area is security-critical. Normal firewall rules control traffic through the firewall. Device access controls traffic to the firewall itself. If WebAdmin or SSH is reachable from an untrusted zone, it creates direct management access to the security appliance.

⚠️ WebAdmin, SSH and portals should only be reachable from trusted networks. In production environments, access should be restricted to a management network, a fixed admin IP, VPN or Sophos Central Firewall Management.

Sophos Firewall Device Access with Local Service ACL and ACL Exception Rules
Device Access controls which local Sophos Firewall services are reachable from which zones. ACL Exception Rules allow very targeted exceptions.

Why Device Access is not a firewall rule

A typical firewall rule allows or blocks connections between zones, for example LAN to WAN or VPN to Server. Device Access is different: It is about services that run directly on Sophos Firewall.

Examples:

  • An admin opens https://172.16.16.16:4444.
  • A client uses the firewall as DNS server.
  • A monitoring system pings the firewall.
  • A user opens User Portal or VPN Portal.
  • An admin connects to the firewall by SSH.

This traffic does not target a server behind the firewall. It targets the firewall itself. It is therefore controlled through the local service ACL.

This is also why Device Access is part of basic hardening for every Sophos Firewall. A clean LAN-to-WAN rule set does not automatically protect the firewall’s own management and portal services. These services must be checked and restricted separately.

Understand zone access

In the upper part of Administration > Device access, there is a table with zones and services. If a service is enabled for a zone, access to that local service is generally allowed from that zone.

The zone table is useful, but broad. It works for clear internal zones such as LAN, Management or VPN. As soon as a service should only be reachable from individual admin IPs, locations, countries or support destinations, Local service ACL exception rules are the better choice.

Typical examples:

ServiceWhen usefulWhat to watch
HTTPSWebAdmin access from the management networkDo not allow broadly from WAN
SSHCLI access for admins or supportAllow only specifically, preferably with public key
Ping/Ping6Monitoring and simple reachability checksDo not enable unnecessarily from untrusted zones
DNSClients use the firewall as DNS resolverEnable only for internal client zones
SSL VPNSSL VPN users connect to the firewallExpose externally only as much as needed and protect with MFA
User PortalUsers download VPN configurations or tokensExternally prefer VPN/ZTNA or tight restrictions
VPN PortalRemote Access VPN usersEnable only when required and protect with MFA
REDRED appliances connect to the firewallAllow only for real RED sites or defined sources
SMTP Relayinternal systems use the firewall as SMTP relayDo not expose as an open relay from untrusted zones
SNMPMonitoring queries firewall valuesAllow only from the monitoring system
Dynamic RoutingRouting protocols between routers and firewallEnable only in the intended network segments

For Custom Zones, reachability of local services can also be influenced through zone settings. Still, Device Access should always be checked deliberately because it is the central overview for local firewall services.

Which services can ACL Rules restrict?

Local Service ACL and ACL Exception Rules can control local firewall services very precisely. These services are especially relevant:

ServiceTypical risk if exposed too broadly
DNSThe firewall answers DNS requests from networks it should not serve.
Dynamic RoutingRouting protocols are reachable from the wrong segments.
HTTPSWebAdmin Console is reachable from too many sources.
Ping/Ping6The firewall becomes unnecessarily visible and easy to scan.
REDRED services are reachable from overly broad source ranges.
SMTP RelayMisconfigurations can encourage relay abuse.
SNMPMonitoring data can be queried from the wrong networks.
SSHDirect CLI access to the firewall is too open.
SSL VPNVPN login points are globally reachable and scanned.
User PortalPortal login and VPN downloads are unnecessarily exposed.
VPN PortalRemote access portal becomes a target for bots and brute-force attempts.

The more of these services are reachable from WAN, guest networks, IoT networks or loosely defined zones, the larger the attack surface becomes. The goal is not to disable everything, but to make each service reachable only where it is actually needed.

Define sources as tightly as possible

An ACL Rule does not have to allow Any. Sources can be defined very precisely, for example with:

  • individual admin IP addresses
  • management networks
  • IP ranges
  • IP lists
  • FQDN hosts
  • FQDN host groups
  • DNS hosts or DNS groups
  • Country objects or country groups
  • dedicated VPN or support networks

This makes access much easier to limit. Example: If an external support service only comes from a fixed FQDN or a defined IP range, the whole WAN zone should not get access to HTTPS or SSH. If a monitoring system needs SNMP, an entire server network should not be allowed to query SNMP on the firewall.

For global remote access scenarios, restriction is harder. Some companies cannot simply allow SSL VPN or VPN Portal from Switzerland, Germany or one single country because users work worldwide. In these cases, MFA, logging, restrictive portal settings and Threat Feeds should be used in addition.

Local Service ACL Exception Rule

If a service should not be enabled for an entire zone, use a Local service ACL exception rule. This defines very precisely who may access which local service.

Path:

  1. Open Administration.
  2. Select Device access.
  3. Scroll to Local service ACL exception rule.
  4. Click Add.

An ACL Exception Rule mainly consists of these fields:

FieldMeaning
Rule nameUnique name, for example admin-https-from-mgmt
Rule positionOrder of ACL rules
Source zoneZone from which access comes, for example WAN, LAN or VPN
Source Network / HostAllowed admin IP, management network, FQDN host or IP list
Destination hostFirewall IP or interface being accessed
ServicesLocal service, for example HTTPS, SSH, Ping or DNS
ActionAccept or Drop

For WebAdmin access from the internet, never use Any as source. Sophos intentionally prevents WebAdmin access from the WAN zone for all sources because this would be high risk. If WAN access is truly required, allow it only through specific source IP addresses, defined networks, FQDN objects or other narrow sources.

Order also matters. ACL Exception Rules are evaluated from top to bottom. A higher Drop rule can make a later Accept rule ineffective. Conversely, an overly broad Accept rule can override intended restrictions. The rule order should therefore be reviewed as carefully as firewall rules.

For many production environments, this approach is sensible:

  • Allow HTTPS/WebAdmin only from Management, admin VPN or a fixed admin IP.
  • Disable SSH by default and allow it only when needed through a targeted ACL.
  • Enable DNS only in zones where clients really use the firewall as DNS server.
  • Allow Ping for internal monitoring systems, but not broadly from WAN.
  • Enable User Portal, VPN Portal and SSL VPN only when required.
  • Allow RED only for locations or source ranges that actually host RED appliances.
  • Allow SNMP only from the monitoring system.
  • Allow SMTP Relay only for defined internal systems.
  • Enable Dynamic Routing only in routing segments where dynamic routing protocols are really used.
  • Check MFA for WebAdmin, VPN Portal and Remote Access.
  • Use Sophos Central Firewall Management if secure external management access is required.

Treat SSH with particular care

SSH is very useful for troubleshooting and support, but it should not stay broadly open. For SSH:

  • Only the admin user can log in by SSH.
  • Public-key authentication is preferred.
  • Access from WAN should only be allowed through fixed source IPs or VPN.
  • After an analysis, check whether SSH is still required.

More details are in Connect to Sophos Firewall by SSH.

Bots, brute force and Threat Feeds

In practice, overly open services are very often found by bots immediately. WebAdmin, User Portal, VPN Portal and SSL VPN are especially affected. Even if a service is protected by password and MFA, public logins create attack attempts, brute-force traffic, noisy logs and unnecessary load on the firewall.

This does not automatically mean that an attack is successful. But it shows that the service is part of the public attack surface. The fewer sources that can even reach the login, the better.

If a portal must be reachable worldwide, country filters or individual source IP addresses are often not enough. In these environments, we also recommend Third-Party Threat Feeds. Threat Feeds continuously provide the firewall with current Indicators of Compromise, for example malicious IP addresses, domains or URLs. Known scanners, botnets and attackers can then be blocked before they reach WebAdmin, VPN Portal, SSL VPN or other published services.

More details: Sophos Firewall Threat Feeds

Common mistakes

Checking a firewall rule instead of Device Access

If WebAdmin, SSH, DNS or Ping to the firewall is not reachable, a normal firewall rule does not help. The traffic does not pass through the firewall; it ends on the firewall itself. Check Administration > Device access.

Allowing WebAdmin from too many zones

WebAdmin should not be reachable from every internal zone. A guest network, IoT network or VoIP network normally does not need access to firewall management. Even internally, compromised clients should be considered possible. A separate management network or admin VPN reduces this risk significantly.

DNS not enabled for the client zone

If clients should use the firewall as DNS server, DNS must be allowed for the correct zone. Otherwise clients can reach the firewall IP but receive no DNS response. Conversely, DNS should not be allowed from zones where the firewall should not act as DNS resolver.

Confusing User Portal and VPN Portal

User Portal and VPN Portal are different services. Depending on the remote access design, check which portal is really needed. Often a portal is enabled because one user needed to download a configuration once, then it stays open for years. Such leftovers should be removed regularly.

Missing the Web Proxy special case

When Web Proxy is used, HTTP and HTTPS requests can appear internal from the proxy’s perspective. This can affect how access to WebAdmin, Captive Portal, VPN Portal or User Portal is controlled. In proxy environments, test carefully which access paths are really possible.

ACL rule too broad

An ACL Exception Rule with Source zone: Any, Source Network / Host: Any and Services: HTTPS, SSH is almost never a good idea. Such rules bypass the security benefit of ACL exceptions. A small, clear rule with a defined source and exactly the required services is better.

Drop rule in the wrong position

If a drop rule is above an accept rule, the intended access can still be blocked. With ACL Exception Rules, order is therefore as important as with firewall rules.

SSL VPN and VPN Portal left too open

Remote Access often has to be reachable from outside. Still, check whether all countries, networks and user groups really need access. If source restriction is not possible, MFA, logging and Threat Feeds become even more important.

Troubleshooting

If a local service is not reachable, use this order:

  1. Is the firewall destination IP correct?
  2. Does the client come from the expected zone?
  3. Is the service allowed for this zone under Administration > Device access?
  4. Is there a matching Local service ACL exception rule?
  5. Is a higher ACL rule with Drop matching?
  6. Is the service configured on another port?
  7. Is access seen differently because of VPN, proxy or NAT?
  8. Does Log Viewer show a hint?
  9. Can Packet Capture see the connection attempt on the interface?

For support access, it can be useful to create a targeted ACL Exception Rule and remove or disable it after the work is complete.

More information