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 and SFOS 23, 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: discards packets with an implausible source IP, reduces basic spoofing attempts and makes incorrectly routed packets more visible. However, the feature is no substitute for sound zone, interface and routing design.
• DoS Settings: limit basic flooding patterns and make noisy attacks or misconfigurations noticeable sooner. However, the feature is no substitute for provider-level DDoS protection, a WAF or a properly sized 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 source addresses from other internal networks should not appear.
• 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 packet drops.
6. Do not immediately work around unexpected drops of legitimate traffic with broad exceptions; check routing, Source-IP and interface first.

A common mistake is to treat Spoof Protection as merely a security checkbox. In reality, the feature checks an assumption about the network design. If that assumption is incorrect, Spoof Protection is not necessarily at fault. Often, an interface, route, VLAN or return path is not configured as expected.

Understanding IP, MAC and IP-MAC pairs correctly

Sophos distinguishes between several types of check. IP spoofing discards traffic if the source IP does not match the routing table or the packet does not originate from a directly connected subnet. MAC filter discards packets whose MAC address is not listed as a Trusted MAC; at least one Trusted MAC Address must be configured 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.

Example with a core switch: the switch handles inter-VLAN routing and uses Sophos Firewall as its default gateway. A client in VLAN 1 with 10.10.10.5 sends an internet request that arrives at the firewall’s LAN interface. The fact that the switch knows the VLANs does not make their subnets directly connected to the firewall. Before activation, check the route for 10.10.10.5 and the directly connected subnets on the firewall. If the documented IP spoofing conditions are not met, the request may be discarded despite the legitimate client address. A WAN access test alone does not replace this check of the internal path.

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: when IP-MAC pair filter is enabled in the selected zones and this option is selected, Sophos describes packets from a Trusted MAC without an IP binding being discarded if the IP is unknown. Here, ‘unknown’ means that there is no matching entry in the routing table or that the packet does not originate from a directly connected subnet. This improves security in controlled networks but can cause problems with DHCP, migrations and temporary IP changes.

When the option is not selected, the general help for SFOS 22 and SFOS 23 states that a Trusted MAC with any IP and a Trusted MAC without an IP binding are allowed. By contrast, the separate Add instructions state categorically that, where a binding exists, only a matching IP-MAC pair is accepted. These statements must not be combined into an unconditional guarantee that traffic will be blocked. Check the type of check, zone, binding and checkbox together, and test the required permitted and non-matching cases on the installed build; if the effect is unclear, clarify it with Sophos Support before production use.

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 as a .csv or .txt file under Intrusion prevention > DoS & spoof protection. In the Spoof protection trusted MAC section, select Import, select the file using Browse, and upload it using Upload file. The MAC address and IP Association must be specified on each line. The first line must contain exactly MAC Address,IP Association,IP Address. The permitted IP Association values are Static, DHCP, DHCPv6 and None. For Static, a maximum of 16 comma-separated IP addresses can be specified per MAC; for the other three associations, the IP field remains empty.

The following format example shows static IPv4 and IPv6 bindings and the three associations without an IP field:

MAC Address,IP Association,IP Address
02:00:00:00:00:01,Static,192.0.2.10,192.0.2.11
02:00:00:00:00:02,Static,2001:db8::10,2001:db8::11
02:00:00:00:00:03,DHCP
02:00:00:00:00:04,DHCPv6
02:00:00:00:00:05,None

The MAC and IP addresses are fictional placeholders, not devices to allow. Replace each line with the actual device MAC and the deliberately chosen association. Static is suitable for known fixed addresses, while DHCP and DHCPv6 are suitable for automatic lease binding; None contains no IP binding and is therefore no substitute for a static pair check.

The firewall discards the entire entry during import if it contains an invalid MAC address, an invalid IP Association or an invalid IP address. This must be distinguished from IP values entered despite an association of DHCP, DHCPv6 or None: these IP values are discarded; this does not automatically mean that the entire MAC entry is removed. Therefore, first import a few pilot lines, then check the visible bindings and test both a permitted and a deliberately incorrect IP-MAC case. A successful upload does not yet prove that the intended filtering logic is taking effect.

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 flood types involve different kinds of load: SYN flood creates many half-open TCP connections; the server responds with SYN-ACK but receives no final response. TCP flood refers to a high TCP packet rate in general. UDP flood can place a load on the target host through port checks and ICMP responses for unused ports. ICMP/ICMPv6 flood involves many Echo Requests and can consume bandwidth. In a DDoS attack, the load is distributed across multiple devices; a single source threshold therefore does not address the same issue as a destination threshold.

The following flags are also relevant on this screen:

• Dropped source routed packets: discards packets whose route is specified by the sender. This restricts this method of routing manipulation.
• Disable ICMP/ICMPv6 redirect packet: does not accept ICMP or ICMPv6 redirects. Downstream routers can also legitimately send such messages to indicate a better or active route; the option therefore changes a routing assumption, not just attack detection.
• ARP hardening: allows ARP Replies only if the source IP and destination IP are in the same subnet. Sophos describes this as protection against ARP Flood and ARP Poisoning.

These options provide useful baseline hardening because they can reduce manipulation of routing or ARP behaviour. Nevertheless, they should be tested 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 a threshold is being applied to and how many packets have been discarded. Click the attack type to open the details; the status link from DoS & spoof protection also leads to this view. After detection, the limit initially applies for ten seconds. If the attack has ended by then, the limit is lifted. If it continues, the firewall resets this counter on a rolling basis every ten seconds and continues to apply the limit. A new attack from the same source or to the same destination resets the counter again and reactivates the limit. When the attack ends, the data disappears after 30 seconds. An empty status view therefore does not prove that no DoS event occurred previously; logged events are needed for retrospective review.

The WebAdmin limits apply per source or destination, not as an overall total for all hosts. A purely illustrative example with Burst rate 100: the first 100 packets are initially allowed without checking the Packet rate; the rate is then compared. Below the configured rate, traffic is accepted; above it, traffic may be discarded. 100 is not a recommended production value.

Do not equate the example sequence with the status timer: the general SFOS 22 and SFOS 23 help calls this sequence an ARP flood attempt and describes further discarded packets and logs if the next packet from the same source arrives within 30 seconds. It describes traffic being allowed if the previous packet arrived longer ago, but explicitly does not describe automatic addition to the Allow List solely after 30 seconds without traffic. By contrast, the separate DoS status help describes the rolling ten-second limit explained above. These are not reliable universal release or waiting times for every flood type. Do not infer that traffic will be allowed based on a timer alone: assess the attack type, live status, logs and a clearly scoped legitimate test flow together; clarify unexplained behaviour with Sophos Support.

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.

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.

An exception is created under Intrusion prevention > DoS & spoof protection in the DoS bypass rule section using Add. SFOS 22 and SFOS 23 require IP version, source and destination IP, Protocol, Source Port and Destination Port; * represents any address or any port. For an HTTPS health check from 198.51.100.20 to 203.0.113.10, a suitable configuration would be: IP version IPv4, Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * and Destination Port 443. Both documentation addresses must be replaced with the real endpoints. The Source Port remains variable only because clients normally use a dynamic source port. After Save, test this exact flow and a different flow; only the defined health check must be able to 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.

XML automation: preserve identity and parent fields

Before automating these settings, check the saved configuration and the object-specific API help on the installed build. The mappings below describe the SFOS 22/SFOS 23 API fields; confirm the installed build’s request representation before writing. Use the XML API safely explains explicit write operations, access protection and separate checks of transport, XML response and the saved object.

Bypass rule: old and new match, not a name

DoSBypassRules has no documented Name identity. Its match consists of IPFamily (IPv4 or IPv6), SourceIPNetmask, DestinationIPNetmask and Protocol (TCP, UDP, ICMP or AllProtocol), with SourcePort and DestinationPort added for TCP/UDP. Ports are single values from 1 to 65535 or *; this reference does not establish a port-range payload. For add/edit, the table lists * for both addresses and TCP for the protocol as defaults. Do not adopt these broad defaults as the intended exception; deliberately specify the complete match.

For an update, DoSBypassRules/OldConfiguration contains the previous combination of the same fields; direct children of DoSBypassRules contain the desired new match. OldConfiguration belongs to update identity, not creation or deletion. The delete reference names the match fields, not a name. Identify the actual saved combination before deleting it. The add/edit sample explicitly marks ports as TCP/UDP-only, whereas the parameter lists, including delete, label both ports mandatory without qualification. This does not yield a reliably executable delete payload for ICMP/AllProtocol: clarify the object-specific help and build rather than sending invented port values.

Trusted MAC: MAC key and separate address families

For TrustedMAC, MACAddress is the identity; on update, TrustedMAC/OldConfiguration/MACAddress holds the old key while TrustedMAC/MACAddress contains the desired MAC address. Delete names only MACAddress, not Name or OldConfiguration. Save the specific entry and its bindings before update or delete, then check the list again.

TrustedMAC/IPV4Association and TrustedMAC/IPV6Association are independent associations using Static, DHCP or None; the API table lists Static as the default for each. Their CSV address fields are named exactly IPV4Address and IPV6Address. File import also uses DHCPv6: do not transfer that value to IPV6Association without verification. The sample value and description for AssociateIP disagree; no permissible write value is inferred here. The qualification above concerning actual IP-MAC filtering also remains necessary for API-managed entries.

File import is a separate Upload_TrustedMAC operation with Upload_TrustedMAC/TrustedMACListFile for .csv or .txt. The sample names the file passed through multipart, but establishes neither a particular multipart part name nor its binding to this XML field. Do not derive a ready-to-use upload request from the sample; clarify the build-specific upload contract first, then check the imported bindings.

Do not flatten Spoof Prevention or DoS Settings

The duplicate name is intentional in the sample structure: SpoofPrevention is the root and SpoofPrevention/SpoofPrevention the switch. SpoofPrevention/RestrictUnknownIPOnTrustedMAC is a separate switch. The three check types have separate zone lists: SpoofPrevention/IPSpoofing/EnableOnZone/Zone, SpoofPrevention/MACFilter/EnableOnZone/Zone and SpoofPrevention/IPMACFilter/EnableOnZone/Zone. The sample shows Enable/Disable, the parameter table instead says on/off, and the disable note is ambiguous. Neither these statements nor omitted or empty zone lists establish a confirmed clearing or disabling syntax. Clarify values and rollback on the installed build before writing.

Under DoSSettings, SYNFlood, UDPFlood, TCPFlood and ICMPFlood each have their own Source and Destination parents. Source contains PacketRatePerSource, BurstRatePerSource and ApplyFlag; Destination contains PacketRatePerDestination, BurstRatePerDestination and ApplyFlag. For example, DoSSettings/UDPFlood/Destination/ApplyFlag belongs only to the UDP destination limit. The table permits packet rates of 1–600000 and burst rates of 1–10000; its default of 1 and the sample numbers are not a production baseline. The additional flags are located at DoSSettings/DroppedSourceRoutedPackets/Destination/ApplyFlag, DoSSettings/DisableICMPRedirectPacket/Destination/ApplyFlag and DoSSettings/DisableARPFlooding/Destination/ApplyFlag. Do not collapse repeated table labels into one global PacketRate, BurstRate or ApplyFlag; preserve saved values with their parent paths.

Read response codes with the operation and saved state

The reference lists the following operation-specific codes, not universal HTTP results:

• Add DOS ByPass Rules: 200, 400, 401, 403, 409, 500; Edit DOS ByPass Rules: 200, 400, 401, 403, 404, 500. In particular, do not confuse add-409 with edit-404.
• Configure Spoof Prevention and Configuration DOS Settings: each 200, 400, 401, 403, 404, 500.
• Upload Trusted MAC List: 200, 400, 401, 403, 404, 409, 500.
• Delete DOS ByPass Rule and Delete Trusted MAC: only 200, 500 on these pages.
• Add Trusted MAC and Update Trusted MAC: each 200 with Operation Successful. and 500 with Operation Fail..

For the other operations listed, the messages in the complete sources remain JavaScript symbols, not resolved response text:

After each change, compare the response with the actual saved zones, rates, bindings or bypass combination. On an error or unclear response, read the current state again before retrying; neither blindly create the entry again nor infer filtering effectiveness from 200 alone. Then check a matching and a non-matching test flow separately as described above.

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 being attacked through permitted HTTP requests: Check the WAF rule and Webserver Protection.
• Known malicious source IP is attacking: Check Threat Feeds or country/IP blocking.
• Exploit attempt against a service: Enable an IPS policy appropriate for the rule.
• Internet connection is saturated by DDoS: Involve the provider, scrubbing or upstream DDoS protection.
• Firewall rule permits too much: Clean up the ruleset, NAT and object model.
• Packet drops cannot be traced: 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. Filter Log Viewer for firewall and relevant security events.
2. Generate test traffic with a clearly defined source IP, destination IP and service.
3. Use Packet Capture if the reason for discarded packets is unclear.
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: The source network may arrive 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 may look like flooding. Use a narrowly defined test window, review Log Viewer and, if necessary, assess a precise bypass rule.
• Devices stop working after DHCP change: The IP-MAC binding or Trusted MAC logic might no longer fit. Check lease, MAC address and binding.
• Only return traffic is missing: An asymmetric path or wrong gateway is likely. 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

• Enabling Spoof Protection without understanding the routing: Legitimate traffic may be blocked. Check zones, interfaces, routes and return paths beforehand.
• Applying DoS thresholds without checking them: VoIP, monitoring, scans or published services may be disrupted. Plan for a baseline and a test phase.
• Confusing Packet Rate and Burst Rate: The sustained packet rate and a short-term spike are different controls. Both must suit the service.
• Addressing every anomaly with a broad exception: Hardening becomes ineffective and difficult to manage. Narrow down the cause, keep exceptions narrowly scoped and document them.
• Setting a DoS bypass rule too broadly: In WebAdmin, the bypass is checked before the DoS Settings configured there and can bypass this control entirely. Keep Source, Destination, protocol and ports narrowly scoped; also check separate CLI policies.
• Leaving the IP-MAC-Pair filter empty: Without maintained entries, there is no effective binding. Always check with a known test client after enabling it.
• Presenting DoS Settings as DDoS protection: This creates false expectations for bandwidth attacks. Plan provider and upstream protection separately.
• Not checking logs: Incorrect blocking or attacks remain invisible. Make Log Viewer, Central Reporting or Syslog part of routine operations.
• Interpreting spoofing-related packet drops solely as an 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 analysis prepared.
• Pilot scope or maintenance window defined.

After activation:

• Internet, VPN, WAF, DNAT, VoIP and monitoring tested.
• Log Viewer checked for unexpectedly discarded packets.
• Packet Capture used for at least one clear test case if packets are being discarded.
• Exceptions narrowly scoped and justified.
• DoS bypass rules checked for source, destination, protocol and ports.
• Results recorded in the operational documentation.

Regularly:

• Review DoS and spoofing events.
• Check whether exceptions are still necessary.
• Retest after network redesigns, VPN changes or new VLANs.
• Correlate logs with IPS, threat feed, WAF and firewall rule events.

FAQ