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: certain traffic is excluded from DoS inspection. broad exceptions weaken the actual protection.

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.

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 thresholds:

• Packet rate: number of packets a host may send or receive per minute before traffic is discarded.
• Burst rate: short-term spike above the Packet Rate that is allowed without immediately being treated as a persistent flood.

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.

One special case: according to Sophos, IP flood configuration is not available in the web interface, but only through the CLI. Such settings should not be changed casually, but with a change record, documentation and rollback plan.

Use DoS bypass rules narrowly only

DoS bypass rules are useful when a clearly known data stream is otherwise reliably hit incorrectly. 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: Sophos Firewall first checks whether a DoS bypass rule matches and only applies DoS Protection to the remaining traffic. A bypass rule that is too broad can therefore make even the best DoS configuration 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 NAT are affected: DoS threshold counts traffic from the perspective of a shared source. check 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: bypass is checked before DoS Protection and can bypass inspection completely. Keep source, destination, protocol and ports narrow.
• 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