Set up and safely test Sophos Firewall IPS

Intrusion Prevention System (IPS) checks traffic for known attack patterns, exploits and suspicious protocol characteristics. For IPS to provide actual protection, it must be enabled globally and an appropriate IPS policy must be assigned to the firewall rule processing the traffic.

Do not apply the strictest policy indiscriminately to every rule. A policy suited to the traffic path, a pilot deployment and reliable logs prevent unnecessary outages without carelessly reducing protection.

Enable IPS and assign it to a firewall rule

Requirements

Before configuring IPS, make sure the following requirements are met:

• an active Network Protection subscription or trial licence
• available IPS signatures and working pattern updates
• a known firewall rule that actually processes the traffic to be inspected
• enabled rule logging and a process for handling false positives

IPS Protection is disabled by default. On an online firewall, IPS signatures are updated only when the licence is valid and IPS is enabled. Licensed air-gapped firewalls are the documented exception: they can receive IPS signatures through the designated update process even while IPS is disabled. See Air-gap licensing and pattern updates for details.

If Network Protection expires, the IPS switch may still appear enabled even though the firewall no longer enforces IPS protection. When IPS is disabled manually, online signatures are no longer updated, and policies and custom signatures can no longer be configured. After 30 days, the firewall deletes the IPS signatures and rules.

When a trial licence expires, IPS is disabled automatically. During the following 30 days, it does not enforce protection, download signatures or allow policy configuration; after that, signatures and rules are deleted. Export the configuration or create a backup beforehand if it must be retained.

Enable IPS globally

1. Open Protect > Intrusion prevention > IPS policies. Depending on the view, the shortened path is Intrusion prevention > IPS policies.
2. Enable IPS Protection.
3. Check the licence status and pattern updates.
4. Wait until the signatures are available.
5. Review the existing default policies.
6. If a custom policy is needed, use Add to clone a suitable default policy.

After enabling IPS, do not check only the switch. A current pattern version and an initial log match provide much better evidence that the protection chain is actually working.

Enabling or disabling Firewall Acceleration or PKI Acceleration restarts IPS or the DPI engine. Make these changes during a maintenance window, not in the middle of active troubleshooting.

Enable IPS in the firewall rule

1. Open Rules and policies > Firewall rules.
2. Edit the rule that actually matches the traffic.
3. Under Other security features, enable Detect and prevent exploits (IPS).
4. Select an IPS policy suited to the traffic.
5. Enable rule logging, save the rule and test it with real traffic.

Global enablement alone is not enough. If the traffic first matches another rule without an IPS policy, a later rule will not protect it. In that case, see Sophos Firewall rule not matching: check the causes.

For published servers, this means that DNAT, a tightly scoped firewall rule, an IPS policy, logging and patch management must work together. For internal segments, also verify that the traffic crosses the firewall and matches the expected rule at all.

Choose the right IPS policy

Choose the policy according to source, destination and application:

• Clients to the internet: Use a client or LAN-to-WAN policy and coordinate it with Web Protection, Application Control and, where appropriate, TLS Inspection. Include browsers, update services and line-of-business applications in the pilot; for suspicious downloads, Zero-Day Protection complements signature inspection.
• Internet to a server through DNAT: Scope a server or web server policy tightly to the target system and published ports. Protection applies to the services actually offered, not indiscriminately to every server technology. Publish a server through DNAT explains the NAT and rule context; known malicious IP addresses, domains and URLs can additionally be blocked with Threat Feeds.
• Site-to-site or remote access VPN: Select the policy according to the source and destination systems. Test production applications, MTU/MSS, latency and throughput across the actual VPN path.
• VoIP: Test SIP/RTP with a specific policy and rollback plan. An aggressive client or server policy can disrupt signalling or media flow.
• Management, backup and infrastructure networks: Protect them restrictively without interrupting required administration, monitoring or backup connections. Tightly scoped rules are usually more valuable here than an especially broad signature selection.

At segment boundaries such as client-to-server or VPN-to-server traffic, IPS also impedes lateral movement after a compromise. However, it only complements well-designed firewall rules. Separate spoof and DoS settings handle basic spoofing and flooding patterns.

Create a custom policy from a template

Use Add to clone a default policy and then adjust it deliberately. This is easier to understand than an arbitrary signature collection and preserves a sensible baseline. The name should indicate the purpose and traffic path, for example IPS-Pilot-LAN or IPS-DNAT-Webserver.

Policy rules are evaluated from top to bottom. A broad rule for all server signatures can therefore override a more specific rule for a single SID below it. Place specific changes above more general rules, then confirm with a matching log entry that the expected action is being applied.

Filter and assess signatures

Signatures can be filtered by Category, Severity, Platform and Target. Custom IPS signatures are also possible, but should be used only for a clearly described detection case and reviewed later. The following details are essential for logs, tickets and exceptions:

• SID: unique signature ID
• Category: technical area, such as DNS, browser or malware
• Severity: severity level
• Platform: affected platform, such as Windows or Linux
• Target: client or server signature
• Recommended action: action recommended by Sophos

Sophos maps Critical to CVSS 9 to 10, Major to 7 to less than 9, Moderate to 4 to less than 7 and Minor to 1 to less than 4 or parent signatures. Warning marks suspicious traffic as an alert. Severity alone is not decisive, however: a Major signature on an exposed server must be assessed differently from a Warning match in a test network. Always consider the target system, accessibility, patch status and action actually taken.

Understand IPS actions

A policy rule can override the action recommended by Sophos:

• Recommended: a sensible starting point for production rules; applies the relevant Sophos recommendation
• Allow packet: logs the match but allows the packet; useful for a pilot, but does not prevent the detected attack
• Drop packet: discards only the affected packet; the application may continue or respond with errors
• Drop session: terminates the entire session after a match; a stronger intervention for a confirmed attack risk
• Reset: actively resets the TCP session; the user or application sees a hard interruption
• Disable: disables the signature; protection for this specific detection is lost
• Bypass session: stops inspecting the rest of the session; traffic may enter FastPath or offload and therefore bypass more inspection than intended

Packet actions apply to each packet. Session actions inspect until the first match and then affect the entire connection. Any deviation from Recommended therefore needs a note containing the signature, policy, firewall rule, reason, owner and review date.

PQC patterns from SFOS 22.0 MR2

SFOS 22.0 MR2 detects pure and hybrid ML-KEM negotiations, including ML-KEM-512, -768 and -1024, and X25519 with ML-KEM-768. The new PQC patterns have a default action of Disabled because PQC is not automatically suspicious. To evaluate them, first test a dedicated pilot policy with Allow packet and logging, and use Drop session or Reset only after analysing the results. See Sophos Firewall v22 MR2: PQC control for background.

Roll out and test in a controlled manner

1. Choose a pilot rule: Start with a known client test network or a single DNAT rule. The expected traffic and responsible person must be clear before testing.
2. Test real applications: Check login, file transfer, updates, APIs and long-running sessions. A brief ping does not prove that the application remains stable under IPS.
3. Assess matches: In Log viewer, check the source, destination, service, firewall rule, signature, SID, severity, action and time. The tools below provide the technical context.
4. Expand gradually: Add more rules only after stable tests. VoIP, ERP, industrial protocols, VPN and legacy applications require a test window and rollback plan.

For analysis, use Services and logs, combine Log Viewer and Packet Capture, and inspect dropped packets.

The tools answer different questions:

• ips.log: deeper information about IPS, DPI and Application Control decisions
• Packet Capture: packet flow, direction, Firewall Rule ID, NAT ID and IPS Policy ID
• Rule test: which firewall rule actually processes the traffic
• Syslog or Central Reporting: longer retention and correlation

When multiple protection modules are active, compare the timestamp across firewall, IPS, web, Application Control and SSL/TLS Inspection logs. A firewall rule may allow traffic that a downstream module then blocks.

Compare performance

IPS resource usage varies according to the appliance model, traffic, signatures, TLS Inspection, Application Control, VPN and packet size. Capture the following values under comparable load before and after enabling IPS:

• CPU and memory load
• throughput on the affected interfaces
• latency and retransmissions for critical applications
• IPS/DPI and Syslog volume
• user and application reports

Briefly disabling IPS does not prove that it caused the problem. Reproducible comparisons require properly interpreted firewall performance data and a controlled iPerf test.

Handle false positives and exceptions

If legitimate traffic is blocked, do not react by disabling IPS globally. A match may be a false positive, an unexpected application or a real exploit attempt. First collect:

• signature ID and signature name
• source, destination, service and matching firewall rule
• time, frequency and affected application
• patch status of the target system
• relevant log extract or Packet Capture

Ask specific questions: Does the problem occur only with one host or port? Is it reproducible? Does it disappear after a patch? Does the same SID repeatedly target the same destination? Only these facts justify changing the policy.

Then scope the change as tightly as possible:

• adjust a single signature instead of an entire category
• use a custom IPS policy only on the affected firewall rule
• check the order of the policy rules
• narrow the source, destination and service in the firewall rule
• document the reason, owner and review date
• verify after the change that only the expected traffic is affected

A temporary exception is usually better than permanent disablement. Review it after an application, firmware or system update. If many signatures disrupt the same application, a dedicated policy or better segmentation is cleaner than a large global exception.

Troubleshooting and operations

IPS does not take effect

Check in this order:

1. Is Network Protection or the trial licence valid?
2. Is IPS Protection enabled globally?
3. Are the IPS patterns current? In an HA cluster, they are updated on the Primary and automatically synchronised to the Auxiliary.
4. Does the traffic match the expected firewall rule with an IPS policy and logging?
5. Does a broad policy rule override a specific rule?
6. Does the policy contain unjustified actions such as Allow packet, Disable or Bypass session?
7. Is the policy appropriate for client, server, VPN or VoIP traffic?
8. Has real traffic been used to verify that Log Viewer and ips.log show corresponding events?

Exceptions without an owner or review date are considered open and belong in the next operational review.

IPS service is DEAD

On SFOS 22.0 GA and later, required web policy configuration data can be missing in rare cases. The web policy service then fails to start, IPS cannot initialise its policy and remains DEAD; pattern updates fail as well. In an HA cluster, each node can be affected independently.

In the CLI, select 5 Device Management > 3 Advanced Shell to enter the required shell. This read-only command lists all service rows containing ips in the name:

service -S | grep -i ips

Only the row whose first service name is exactly ips is relevant; ipsec-monitor is not. In an HA cluster, check each affected node separately.

If the service is DEAD, record the SFOS version, time, node, complete status output, ips.log and sig_upgrade.log, then contact Sophos Support and reference NC-181971. The command alone does not prove that this issue is present. Sophos still does not publish a fixed version and provides the workaround only through Support. Repeated restart attempts or undocumented repair commands are not a sound solution.

FAQ