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:
Protect > 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
| Function | What it helps for | What it is not enough for |
|---|---|---|
| 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.
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:
- Document zones, interfaces, VLANs, bridges and LAGs.
- Check static routes, SD-WAN routes, VPN routes and asymmetric paths.
- Identify published services via DNAT or WAF.
- Note critical services such as VoIP, monitoring, backup, scans, VPN and site connections.
- Prepare logging and central evaluation if events need to be traceable later.
- Set maintenance window or pilot area for first activation.
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:
- Save the current configuration or at least document the affected settings.
- Start with a clear zone or interface, for example WAN or a cleanly separated client zone.
- Save activation.
- Run planned test connections: Internet access, VPN, published services, central servers, monitoring.
- Check Log Viewer and Packet Capture for unexpected drops.
- 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.
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.
What these settings don’t solve
Spoof Protection and DoS Settings are important building blocks, but they don’t solve every security problem.
| Problem | Better additional module |
|---|---|
| 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:
- Log Viewer filter for firewall and relevant security events.
- Trigger test traffic with clear source IP, destination IP and service.
- Use Packet Capture for unclear drops.
- For longer storage, plan syslog to SIEM or log server.
- 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.
Typical errors
| Error | Impact | Better approach |
|---|---|---|
| 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 |
| Solve every anomaly with a broad exception | Hardening becomes ineffective and confusing | Limit the cause and closely document exceptions |
| 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.
- 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.
- 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.