Sophos Firewall Spoof Protection and DoS Settings check

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.

The typical menu path, depending on the SFOS version, is in the range:

Intrusion prevention > DoS & spoof protection

If the interface is labeled slightly differently in a newer version, you should look for DoS, spoof protection or intrusion prevention. What is important is not the exact click path, but rather that the function is consciously planned, tested and later logged.

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; they do not automatically bypass CLI policies evaluated beforehand.

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.

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.

Spoof Protection activate 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. Start with a clear zone or interface, for example WAN or a cleanly separated client zone.
3. Save activation.
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.

The expectation is important: an enabled IP-MAC pair filter without maintained Trusted MAC or IP-MAC entries does not automatically protect anything. If no matching entries exist, traffic is not blocked but allowed. Protection only starts with 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.

DoS Settings plan

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?
• Which events should only be logged and which should really be blocked?
• 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.

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. This example documented by Sophos limits SYN traffic from the example address 198.51.100.50 to 1000 pps per source:

system dos-config add dos-policy policy-name TestSYN SYN-Flood 1000 pps per-src
system dos-config add dos-rule rule-name TestRuleSYN srcip 198.51.100.50 dos-policy TestSYN

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

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.

CLI rules and policies are evaluated before the DoS and spoof settings in WebAdmin. Within the WebAdmin settings, the firewall first checks the DoS bypass rules and then the remaining DoS Settings. A bypass rule in WebAdmin therefore does not automatically override a matching CLI policy.

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.

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 Central, check whether Central Firewall Reporting makes the desired events visible.

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.

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