Check Sophos Firewall Spoof Protection and DoS Settings

Spoof Protection and DoS Settings are among the classic hardening functions of a Sophos Firewall. The features reduce simple, noisy or obviously incorrect packets before they become unnecessary noise in logs, rules or published services. At the same time, these settings are not a magical protection against every kind of attack.

The article classifies the functions as careful basic hardening: first understand the network design and return paths, then activate, test and check the logs. The distinction is particularly important: These functions complement clean firewall rules, IPS, Threat Feeds, WAF and logging. They are not a replacement for these building blocks.

Briefly explained

Spoof Protection checks whether packets with a plausible source address arrive on the expected interface. For example, if a packet with an internal source address appears from the direction of the Internet, this is suspicious in most designs. DoS Settings, on the other hand, respond to certain flooding or connection attack patterns, for example noticeable amounts of SYN, UDP or ICMP traffic.

In SFOS 22, the WebAdmin path is:

Intrusion prevention > DoS & spoof protection

The settings on this page affect packet processing. Before selecting Apply or Save, record the existing values and define a rollback path.

What the functions do

• Spoof Protection: Discard packets with implausible source IP, reduce simple spoofing attempts, make incorrectly routed packets visible. does not replace clean zone, interface and Routing planning.
• DoS Settings: limit simple flooding patterns, make loud attacks or misconfigurations noticeable earlier. does not replace provider DDoS protection, no WAF and no cleanly dimensioned upstream design.

In practice, these functions are particularly interesting as basic hardening. The benefit is to reduce obvious nonsense. In real volumetric DDoS attacks, the Internet connection is often already at capacity before the firewall can respond meaningfully. Then you need protection from the provider, upstream scrubbing or another architecture.

Do not mix protection types

The same screen contains several mechanisms that answer different operational questions.

• Enable spoof prevention: Spoof Prevention is activated for selected zones. misunderstood zones or return paths can affect legitimate traffic.
• Trusted MAC and IP-MAC pairs: known MAC addresses or IP-MAC combinations are treated as trusted. mobile devices, DHCP changes or virtualisation can create maintenance effort.
• DoS settings: thresholds and flags for SYN, UDP, TCP or ICMP/ICMPv6 flooding are set. values that are too strict disrupt legitimate load peaks, scans, monitoring or VoIP.
• DoS bypass rule: excludes specific traffic from the DoS Settings in WebAdmin. Broad exceptions weaken this protection. For interaction with CLI policies, see the version qualification in the CLI section.

This distinction matters because an error after activation is not automatically a firewall rule problem. Sometimes the DoS threshold is too aggressive, sometimes an IP-MAC binding no longer fits, and sometimes Spoof Protection points to a real routing or VLAN problem.

When Spoof Protection makes sense

Spoof Protection fits particularly well with clearly segmented networks in which source networks, interfaces and routes are clearly planned. The clearer the network structure, the easier it is to assess whether a source address on an interface is plausible.

Useful applications:

• Internet WAN on which no internal RFC1918 sources should appear.
• DMZ or server zones with clear source and destination networks.
• Client, guest or IoT zones in which no external internal networks should appear as sources.
• Locations where routing, VLANs and zones are clearly documented.
• Environments in which packet drops must later be traceable with Packet Capture and logs.

Things get more difficult with asymmetrical routing, complex transit networks, temporary migration paths, incorrectly documented VLANs or multiple firewalls in the same data path. A legitimate data stream can look like spoofing, although the routing design or the return path is actually unclean.

Check before activation

Spoof Protection and DoS Settings should not be activated blindly in a production environment. It should be clear beforehand which networks and services are affected.

Important checkpoints:

1. Document zones, interfaces, VLANs, bridges and LAGs.
2. Check static routes, SD-WAN routes, VPN routes and asymmetric paths.
3. Identify published services via DNAT or WAF.
4. Note critical services such as VoIP, monitoring, backup, scans, VPN and site connections.
5. Prepare logging and central evaluation if events need to be traceable later.
6. Set maintenance window or pilot area for first activation.
7. Check existing DoS bypass rules, Trusted MAC entries and IP-MAC bindings.
8. Record the current spoof inspection type and zones, Restrict unknown IP on trusted MAC, every Apply flag, packet and burst rates, exceptions and bindings. These are the prior values for rollback.

If normal firewall rules are difficult to understand, the rule and routing status should be cleaned up first. For individual test connections, Test firewall rule with Log Viewer, Policy Test and Packet Capture is a better start.

Activate Spoof Protection carefully

A step-by-step approach makes sense for Spoof Protection. You should secure the clearest areas first, not every special zone immediately.

Practical process:

1. Save the current configuration or at least document the affected settings.
2. Under Intrusion prevention > DoS & spoof protection, select Enable spoof prevention, the required inspection type, and initially only well-documented zones.
3. Select Apply.
4. Run planned test connections: Internet access, VPN, published services, central servers, monitoring.
5. Check Log Viewer and Packet Capture for unexpected drops.
6. Do not immediately deal with conspicuous legitimate drops with broad exceptions, but first check routing, source IP and interface.

A common mistake is to treat Spoof Protection as a pure security hook. In reality, the function tests an assumption about the network design. If this assumption is not correct, Spoof Protection does not necessarily have to be wrong. Often an interface, a route, a VLAN or a return route is not built as expected.

Understanding IP, MAC and IP-MAC pairs correctly

Sophos distinguishes between several inspection types. IP spoofing discards traffic when the source IP does not match the routing table or a directly connected subnet. MAC filter works with trusted MAC addresses; at least one Trusted MAC Address must be maintained for this. The MAC filter is not applied to DHCP packets. IP-MAC pair filter checks whether the incoming combination of IP address and MAC address matches a known pair.

This is useful in static, clearly controlled networks, but can quickly create maintenance effort in dynamic environments. DHCP, Wi-Fi roaming, virtual machines, hypervisors, clusters, NAC, docking stations or device replacement can create legitimate MAC/IP changes. For such networks, first observe and only bind where the operational reality is stable enough.

For guidance on inspecting the local neighbor table and deliberately creating a static IP, MAC and interface binding, see Check the ARP and NDP neighbor cache.

Set expectations correctly: if no Trusted MAC is configured, the enabled IP-MAC pair filter allows all traffic through this check. An empty Trusted MAC list is not the same as a packet that mismatches a configured IP-MAC binding. With entries present, filtering depends on the bindings and Restrict unknown IP on trusted MAC; a missing matching pair does not always mean a block regardless of that option. Protection requires maintained and tested bindings.

The Restrict unknown IP on trusted MAC option is particularly strict: packets from a Trusted MAC without a matching IP binding can be discarded when the IP is unknown from the firewall’s perspective. This is a security gain in controlled networks, but a stumbling block with DHCP, migrations and temporary IP changes.

Create a single trusted MAC entry under Intrusion prevention > DoS & spoof protection in the Spoof protection trusted MAC section with Add. After entering the MAC address, select Static and specify one or more comma-separated IPv4 or IPv6 addresses, or select DHCP to bind leased addresses automatically. After Save, test one matching and one deliberately mismatched IP-MAC case; a visible entry alone does not confirm that the filter is enforced.

SFOS 23 documents search and filter options in the Trusted MAC list to find an entry for maintenance. This list view does not change packet filtering, nor does this imply that SFOS 22 lacks such controls.

Import trusted MACs in a controlled manner

Multiple trusted MACs can be imported under Intrusion prevention > DoS & spoof protection from a .csv or .txt file. The first row must contain exactly MAC Address,IP Association,IP Address. Valid IP Association values are Static, DHCP, DHCPv6, and None. With Static, specify up to 16 comma-separated IP addresses per MAC; leave the IP field empty for the other three associations.

The firewall discards invalid MAC addresses, associations, or IP addresses during import. It also discards IP values entered with DHCP, DHCPv6, or None. Import only a few pilot rows first, then review the visible bindings and test one allowed and one deliberately incorrect IP-MAC case. A successful upload does not yet prove that the intended filter logic is effective.

Plan DoS Settings

DoS Settings should fit the environment. It rarely makes sense to adopt values ​​from another example without checking. A site with a few users, VoIP and a small WAN behaves differently than a data center, a school network or a site with regular scans and monitoring.

Before adapting, answer these questions:

• Which public services are exposed?
• Are there legitimate load peaks, scans, monitoring or health checks?
• Are VoIP, VPN, WAF, DNAT or large file transfers used?
• For which protocols should the Apply flag be enabled so that the firewall actually drops and logs threshold violations?
• Who checks the logs after activation?

DoS Settings can help limit simple flooding patterns. However, thresholds that are too strict can also affect legitimate traffic. Particular care should be taken with VoIP, monitoring systems, backup jobs, vulnerability scans and heavily used published services.

The screen is not only about classic floods. It also includes flags such as Dropped source routed packets, Disable ICMP/ICMPv6 redirect packet and ARP hardening. These options are useful baseline hardening because they can reduce manipulation of routing or ARP behaviour. Still, test them after activation, especially in networks with downstream routers, older segments or unusual Layer 2 designs.

Two terms matter for the thresholds in WebAdmin:

• Packet rate: number of packets a host may send or receive per minute before traffic is discarded.
• Burst rate: number of packets initially allowed without checking the Packet Rate. After that, occasional short bursts above the Packet Rate can be tolerated, but not frequent or sustained exceedances.

The Apply flag decides whether the configured limit is actually applied for the respective protocol. If values are too high, they do little. If they are too low, they block legitimate bursts. Values should therefore be aligned with the site’s own traffic, published services and known maintenance windows.

For a defensible baseline, first record normal peaks and planned exceptional loads. Then choose each protocol’s value using the measured legitimate peak and the protected service’s capacity. Sophos doesn’t provide one universal production value. After each change, run one defined load test and compare Traffic dropped. This counter accumulates since the last firewall restart, so record the test time and starting value as well.

Read the DoS status correctly

Under Intrusion prevention > DoS attacks, SFOS shows in real time which source or destination is being rate-limited and how many packets have been dropped. After detection, the limit initially applies for ten seconds. If the attack continues, the firewall resets this counter on a rolling ten-second basis and keeps limiting traffic. When the attack stops, the data disappears after 30 seconds. An empty status therefore does not prove that no DoS event occurred earlier; use the logged events for retrospective analysis.

Use DDoS signatures only on supported models

Sophos provides DDoS signatures only on XGS 5500 and higher-capacity firewalls. On a supported model, follow this procedure:

1. Under Intrusion prevention > IPS policies > Add, create a dedicated IPS Policy with a unique name of your choice and save it with Save.
2. Select Edit for this saved policy, then Add, and enter a unique rule name.
3. Choose Select all, enter ddos in Smart filter and press Enter to apply it. Deliberately set Action to Drop packet.
4. Use Save to save the rule first, then use the second Save to save the enclosing policy.
5. Under Rules and policies > Firewall rules, assign the policy to the firewall rule that actually handles the intended traffic; verify assignment and protection separately as described in the IPS pilot procedure. The policy has no effect without this assignment.

These signatures complement the local DoS thresholds, but they do not replace upstream DDoS protection. If the internet circuit is already saturated, the firewall cannot resolve the bottleneck behind the WAN connection. Verify the model, license, rule match, and a controlled test separately.

CLI rules with system dos-config

The Device Console can be used to create custom DoS policies and matching rules. This is required for IP Flood, among other things, because this type cannot be configured in WebAdmin. The units differ: WebAdmin uses packets per minute, while system dos-config uses packets per second (pps).

After the SSH login, select 4. Device Console from the main menu. Enter the commands at the console> prompt, not in the Advanced Shell.

First create the policy with the attack type, threshold and counting method. Then define the traffic to which it applies in the rule. The documented SYN example uses policy TestSYN and rule TestRuleSYN for source 198.51.100.50 at 1000 pps per source.

Check the target version’s help before creating anything: The published SFOS 22 and SFOS 23 help uses rule_name for add dos-rule in the syntax and options blocks, but rule-name in the examples. The spellings are not confirmed to be interchangeable. First open the help for system dos-config in the Device Console of the installed version and check the accepted add token and parameters. If this remains unclear, do not create a rule; clarify it with Sophos Support. The complete add-rule command is deliberately withheld here as a copy-and-paste template. Create the policy below only after this preflight too; a policy alone does not bind the example traffic. This example is not presented as successfully tested.

system dos-config add dos-policy policy-name TestSYN SYN-Flood 1000 pps per-src

1000 pps is a syntax example, not a recommendation for a production network. At minimum, the following parts must be deliberately adapted for a custom rule:

• SYN-Flood: alternatively UDP-Flood, ICMP-Flood or IP-Flood, which is only available here
• per-src: threshold per source; alternatively per-dst per destination or global for all matching traffic
• the conditions actually required for source, destination, zone, interface and protocol
• the threshold based on a measured baseline and the capacity of the protected service

The global counting mode does not apply to the counters under Intrusion prevention > DoS attacks. These UI counters therefore do not prove a globally aggregated CLI limit. Check the configuration with show, and assess enforcement separately using a clearly scoped, time-bounded test flow and its logs.

The CLI limits and match fields are more narrowly defined than the short example rule suggests:

system dos-config flush dos-rules removes all CLI DoS rules and isn’t a rollback for a single test. Before such a global action, record the existing rules individually with show and secure the configuration. For a normal rollback, delete the named rule specifically. The published help describes flush for rules, not as deletion of the associated policies.

After creating them, first verify that the names, type, threshold and rule condition are correct:

system dos-config show dos-policies policy-name TestSYN
system dos-config show dos-rules rule-name TestRuleSYN

For rollback, delete the rule first and then the policy that is no longer used:

system dos-config delete dos-rule rule-name TestRuleSYN
system dos-config delete dos-policy policy-name TestSYN

The CLI syntax is documented in the Sophos Firewall Command Line Help. It should nevertheless first be used with a controlled test flow. CLI DoS rules support IPv4 only. With an active IP-Flood policy, the Applied column under Intrusion prevention > DoS attacks still shows No; Sophos describes this as expected behaviour.

This IPv4 limitation applies to CLI DoS rules, not to the native DoS settings under Intrusion prevention > DoS & spoof protection in WebAdmin: the DoS settings there protect both IPv4 and IPv6 traffic when the appropriate protocol flags and thresholds are configured.

SFOS 22 documents CLI rules and policies being evaluated before the DoS and spoof settings in WebAdmin; in that order, a WebAdmin bypass rule does not automatically override a matching CLI policy. The reviewed SFOS 23 CLI help does not specify this cross-layer order. That is not evidence of a runtime change: confirm the interaction for the installed version before relying on it. Within WebAdmin, both versions still document DoS bypass rules first, followed by DoS Settings for the remaining traffic.

Use DoS bypass rules narrowly only

DoS bypass rules are useful when a well-understood traffic flow would otherwise be incorrectly affected by the WebAdmin DoS Settings. Typical examples are monitoring, health checks or a tightly defined service between known IP addresses. The exception should then be as precise as possible: specific source, specific destination, matching protocol and narrow port range.

Broad bypass rules with large networks, any logic or blanket port ranges are dangerous. Such exceptions make DoS inspection blind exactly where it may later be needed. If a broad exception seems necessary, first check whether the thresholds, architecture or test case were assessed incorrectly.

Order matters for the WebAdmin settings: Sophos Firewall first checks whether a DoS bypass rule matches and only applies the DoS Settings there to the remaining traffic. A bypass rule that is too broad can therefore render this protection ineffective. For bypass rules, consciously set source, destination, protocol, source port and destination port instead of using * out of convenience.

Create an exception under Intrusion prevention > DoS & spoof protection in DoS bypass rule with Add. SFOS 22 requires IP version, source and destination IP, Protocol, source port and destination port; * means any address or port. For an HTTPS health check from 198.51.100.20 to 203.0.113.10, a suitable configuration is source 198.51.100.20, destination 203.0.113.10, protocol TCP, source port *, and destination port 443. Replace both documentation addresses with the real endpoints. The source port is variable only because clients normally use a dynamic source port. After Save, test this flow and a different flow; only the defined health check should bypass WebAdmin DoS protection.

Check the change and failover in HA

In an HA cluster, Sophos states that the primary synchronizes firewall configuration, including rules, policies, settings, and CLI commands, to the auxiliary. Make DoS and spoof changes on the current primary. Then check for healthy HA status under System services > High availability and recheck the WebAdmin entries and CLI rules. In active-active mode, include both processing paths in the load test. In active-passive mode, include a controlled failover in the maintenance window if operational policy permits it. Don’t create a second, divergent configuration on the auxiliary.

Note for SFOS 22.0 MR2

The SFOS 22.0 MR2 Build 546 release notes list resolved issue NC-180226: WebAdmin previously showed no error when a duplicate MAC address was added under Spoof protection trusted MAC. On older 22.0 builds, the absence of an error dialog therefore doesn’t prove that an entry is unique. Review the list and actual binding, or update to a corrected build.

What these settings don’t solve

Spoof Protection and DoS Settings are important building blocks, but they don’t solve every security problem.

• Server is attacked via permitted HTTP requests: Check WAF rule and web server protection.
• Known malicious source IP attacks: Threat Feeds or Check country/IP blocking.
• Exploit attempt against a service: Activate IPS-Policy according to the rule.
• Internet line is full due to DDoS: Include provider, scrubbing or upstream DDoS protection.
• Firewall rule allows too much: Clean up rules, NAT and object model.
• Drops are incomprehensible: Improve logging, Packet Capture, syslog or central reporting.

The article Publish server with DNAT on Sophos Firewall is also relevant for publicly accessible servers. It’s about NAT, firewall rules and typical publishing errors.

Logs and follow-up check

After activation you should not only check whether normal internet access still works. What is important is whether the firewall clearly shows expected and unexpected events.

Check:

1. Log Viewer filter for firewall and relevant security events.
2. Trigger test traffic with clear source IP, destination IP and service.
3. Use Packet Capture for unclear drops.
4. For longer storage, plan syslog to SIEM or log server.
5. When running Sophos Fusion (formerly Sophos Central), check whether Central Firewall Reporting makes the desired events visible.

SFOS logs traffic dropped by these protection functions. For a DoS test, first record the time, source, destination, protocol, and counters. During the test, Intrusion prevention > DoS attacks shows the source or destination and dropped data in real time. Because status disappears 30 seconds after the attack stops and Traffic dropped accumulates since the last restart, only a bounded before-and-after comparison is meaningful. The CLI global counting mode does not apply to these UI counters, so even this comparison cannot validate global aggregation. For a global CLI policy, keep the show configuration check separate from checks of the defined test flow and its drops/logs. Packet Capture additionally shows the ingress interface and packet addresses, but a capture alone doesn’t prove which protection mechanism dropped the flow.

If a packet is dropped but the reason is not clear, the systematic drop analysis in Sophos Firewall drops packets: check causes helps. It also describes why Log Viewer and Packet Capture answer different questions.

Troubleshooting after activation

After a change, symptoms should not be interpreted prematurely as an attack. The fastest analysis is usually a small table with expectation, observation and next test.

• A single network loses access: source network arrives on a different interface than expected. compare route, VLAN, SD-WAN route and Packet Capture.
• Many clients behind upstream NAT are affected: If the traffic has already been NATed before reaching the Sophos Firewall, it sees several clients as one shared source. Check the threshold, NAT path and legitimate load peak.
• VoIP, monitoring or scanner creates drops: regular packet rates look like flooding. narrow test window, Log Viewer and, if needed, precise bypass rule.
• Devices stop working after DHCP change: IP-MAC binding or Trusted MAC logic no longer fits. check lease, MAC address and binding.
• Only return traffic is missing: asymmetric path or wrong gateway. check forward and return path separately with Packet Capture.
• ARP or ICMP change creates side effects: ARP hardening, source-routed packets or ICMP redirect can hit unusual network designs. Check downstream routers, Layer 2 segments and routing path.

Roll back safely

If legitimate traffic is affected and the cause can’t be established within the maintenance window, don’t improvise with a broad exception. Restore the previously recorded packet and burst rates, Apply flags, spoof inspection type, zones, and Restrict unknown IP on trusted MAC; remove only the newly created bypass or Trusted MAC entries. Select Apply or Save, then repeat the same test flow. For a CLI policy, use the rollback shown above: delete only the named rule first, then its now-unused dedicated policy. flush dos-rules isn’t part of this rollback.

Typical errors

• Spoof Protection activate without routing understanding: legitimate traffic can be blocked. Check zones, interfaces, routes and return paths beforehand.
• Apply DoS thresholds without checking: VoIP, monitoring, scans or published services can be disrupted. Plan baseline and test phase.
• Confuse Packet Rate and Burst Rate: persistent packet rate and short-term spike are different controls. Both must fit the service.
• Solve every anomaly with a broad exception: Hardening becomes ineffective and confusing. Limit the cause and closely document exceptions.
• Set DoS bypass rule too broadly: In WebAdmin, the bypass is checked before the DoS Settings there and can completely bypass this control. Keep source, destination, protocol and ports narrow; also check separate CLI policies.
• Leave IP-MAC pair filter empty: without maintained entries there is no effective binding. Always test with a known client after activation.
• Sell DoS Settings as DDoS protection: false expectations for bandwidth attacks. Plan provider and upstream protection separately.
• Do not check logs: Incorrect blocks or attacks remain invisible. Define Log Viewer, central reporting or syslog as operating point.
• Interpret spoofing drops as a pure attack: Routing or VLAN errors are overlooked. Compare source IP, interface, route and Packet Capture.

Operational Checklist

Before Activation:

• zones, interfaces and routing understood.
• Critical services and test cases defined.
• Packet Rate, Burst Rate and enabled flags technically assessed.
• Backup or change documentation available.
• Logging and evaluation prepared.
• Pilot area or maintenance window set.

After activation:

• Internet, VPN, WAF, DNAT, VoIP and monitoring tested.
• Log Viewer checked for unexpected drops.
• Packet Capture used for at least one clear test case when drops occur.
• Exceptions are only made narrowly and with reasons.
• DoS bypass rules checked for source, destination, protocol and ports.
• Result recorded in the operating documentation.

Regularly:

• Check DoS and spoof events.
• Check exceptions for necessity.
• Test again after network modifications, VPN changes or new VLANs. Correlate
• logs with IPS, threat feed, WAF and firewall rule events.

FAQ