Configure and safely test Sophos Firewall IPS

The Intrusion Prevention System (IPS) inspects network traffic for known attack patterns, exploits, and suspicious protocol characteristics. For IPS to provide protection, it must be enabled globally. In addition, the firewall rule that handles the traffic flow must use an appropriate IPS policy.

The safe approach is straightforward: check the license and patterns, enable IPS, select a policy based on the system you need to protect, assign it to the correct firewall rule, and validate the data path with a small pilot group. Applying the strictest policy to every rule does not automatically provide the best protection. An unsuitable policy creates unnecessary detections, load, or disruptions and makes meaningful analysis more difficult.

Check prerequisites and license status

Before configuring IPS, you need:

• an active Network Protection subscription or trial license;
• available IPS signatures and working pattern updates;
• the firewall Rule ID of the rule that actually handles the intended traffic;
• rule logging to correlate the session, firewall rule, and IPS event;
• an assigned owner, defined tests, and a rollback path for false positives.

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

After a Network Protection subscription expires, the IPS switch may still appear to be enabled even though the firewall no longer enforces IPS protection. A trial license behaves differently: IPS is automatically disabled when the trial expires. When IPS is disabled, online signatures are no longer downloaded, and policies and custom signatures can no longer be configured. After IPS has remained disabled for 30 days, SFOS deletes the IPS signatures and rules. If you need to retain the configuration, create an export or backup beforehand.

Even when IPS is disabled, existing IPS policies can still be assigned to firewall rules. This assignment does not prove that inspection or protection is active. If the paid subscription has expired and IPS is disabled, or an expired trial licence has automatically disabled IPS, a Network Protection subscription must first be activated before IPS can be re-enabled. After activation, check the IPS switch and signatures again.

Even a valid subscription does not provide unlimited protection without license contact. Online firewalls normally synchronize their licenses every 24 hours. If synchronization fails for 90 consecutive days, SFOS disables the security subscriptions; for an air-gap license, this period is 180 days. Sign-ins and traffic may continue to work, but without the protection provided by the disabled subscriptions. License status must therefore be included in troubleshooting when IPS appears to be configured but is not taking effect.

Under Backup & firmware > Pattern updates, SFOS displays statuses including Ready to install, Downloading, Success, and Failed. Update pattern now starts an update of the standard pattern definitions. A successful entry for Application Signatures does not prove that IPS signatures were also downloaded: on online systems, IPS signatures still require a valid license and enabled IPS.

Enable IPS and define the data path

1. Open Intrusion prevention > IPS policies.
2. Enable IPS Protection.
3. Under Backup & firmware > Pattern updates, check the IPS pattern timestamp and status.
4. Document the previous IPS Protection state, the firewall Rule ID for the pilot traffic flow, the previous IPS policy, the Log firewall traffic setting, and any existing exceptions.

Enabling or disabling Firewall Acceleration or PKI Acceleration restarts IPS or the DPI engine. Such changes are not part of this activation procedure. If a reproducible issue involves a global engine setting, Safely check global IPS settings explains which changes take effect immediately, which require an Apply step or restart, and how to preserve the original value.

The system being protected determines the policy

Target identifies the side whose vulnerable software a signature is designed to protect. It is not simply equivalent to the Source Zone or Destination Zone. For example, the Target may be Client for a browser receiving a crafted response, or Server for a published web server receiving a malicious request.

Answer three questions when choosing a policy:

1. Which system is the protected target in this flow: the client or the server?
2. Which platforms, protocols, and services actually run on that system?
3. Does an existing policy cover this scope without including unrelated signature groups?

For a standard client internet path, begin with an appropriate client or LAN-to-WAN policy. For a DNAT-published service, choose a server or web server policy that matches the operating system and the ports actually being published. In VPN or segmentation traffic flows, the protected application likewise determines the policy, not merely the name of the source zone. Test MTU, MSS, latency, and throughput across the actual VPN connection.

VoIP requires a separate functional test for SIP signaling and RTP media, together with a prepared rollback to the previous policy. For management, backup, and infrastructure networks, narrowly scoped rules are generally more valuable than an especially broad signature selection. IPS can also impede lateral attacks at internal segment boundaries; spoofing and flooding thresholds, however, remain a separate responsibility of the spoofing and DoS settings.

A custom policy is appropriate when the data path needs tighter scoping, a single SID requires a documented exception, or an action must deliberately differ from Recommended. Under Intrusion prevention > IPS policies > Add, assign a unique name such as IPS-Pilot-LAN or IPS-DNAT-Webserver and clone a suitable existing policy as the starting point. First use Save to save the new or cloned policy; this does not yet create a new policy rule. Then adjust the rules in the copy; the built-in signatures themselves cannot be edited.

Filter signatures and order policy rules

When adding a rule, you can select individual signatures, custom signatures, or Select all. The Smart Filter accepts search terms and criteria such as Category, Severity, Platform, and Target; press Enter after entering the filter.

Open the rule editor separately from policy creation: under Intrusion prevention > IPS policies, select Edit for the required, already saved policy, then select Add and enter a unique rule name. Next, select the required signatures: Select individual signature for individual signatures or Custom signature for custom signatures. To search using Smart filter, first choose Select all, enter the search term and press Enter to apply it.

Categories help narrow the selection to what is technically relevant. The complete mapping below explains the labels visible in SFOS. Treat Category as a lookup aid, not a risk verdict; combine it with Platform and Target so the Smart Filter selects only signatures relevant to the protected workload.

Broad indicator categories should initially be used in a monitoring-only pilot. In particular, indicator-compromise may produce false positives, so the category alone does not justify a block or an exception.

After selecting the signatures, deliberately set the Action; the differences are explained in the section on severity and action. Use Save in the rule editor to save the rule. This is a separate step from initially saving the policy. In the DDoS workflow, the enclosing policy is then also saved with Save.

After saving the policy, start a new test session: confirm ips_policy_id or idp_policy_id and fw_rule_id; for a detection, also compare signature_id, classification, and log_subtype with the intended rule and action. The absence of a detection does not by itself prove that the filter or policy was applied.

Policy rules are evaluated from top to bottom. A broad rule covering all server signatures can therefore override a more specific rule for a single SID below it. Place specific exceptions or rules with different actions above the more general rule. A subsequent detection must show the expected policy, Rule ID, and action.

Custom IPS signatures are intended for a clearly defined detection scenario, not as a substitute for an unsuitable standard selection. Create and test custom IPS signatures describes the procedure, including syntax, a tightly scoped pilot policy, and positive and negative tests.

Evaluate severity and action separately

For logs, tickets, and exceptions, the important fields are SID, Category, Severity, Platform, Target, and Recommended action. Sophos assigns Critical to CVSS scores from 9 to 10, Major from 7 to less than 9, Moderate from 4 to less than 7, and Minor from 1 to less than 4 or to parent signatures. Warning identifies and alerts on a specific type of traffic. Severity alone does not determine risk: reachability, the target system, patch status, and the effective action must also be considered.

This CVSS mapping has exceptions: Sophos describes cases whose severity classification does not fit the stated formulas. This does not establish either a documented WebAdmin function for overriding severity or a procedure for reclassification; check the signature severity actually displayed.

A policy rule can override the recommended action:

• Recommended applies the action Sophos recommends for the relevant signature and is the usual starting point for production rules.
• Allow packet logs the detection but permits the packet. This is suitable for a pilot, but it does not prevent the detected attack.
• Drop packet drops only the affected packet. The application may continue to run or may return an error.
• Drop session terminates the entire session after a detection.
• Reset actively terminates a TCP session by sending a reset to the initiator.
• Disable disables that specific signature, removing the associated detection.
• Bypass session stops inspecting the remainder of the session. The traffic may consequently enter FastPath or offload and bypass more inspection than intended.

Packet actions apply to each packet. Session actions inspect traffic until the first detection and then act on the entire connection. Every deviation from Recommended should therefore include a justification that records the signature, policy, firewall rule, owner, and review date.

Select the IPS policy in the firewall rule

1. Open Rules and policies > Firewall rules.
2. Edit the rule whose Rule ID was verified in the pilot flow.
3. Under Other security features, select the chosen IPS policy for Detect and prevent exploits (IPS).
4. Enable Log firewall traffic, save the rule, and create a new session for the test.

Global activation alone is not sufficient. If the traffic first matches another rule without an IPS policy, a later rule cannot protect it. Troubleshoot a Sophos Firewall rule that does not match helps verify rule matching.

Firewall rules restrict which traffic is allowed in the first place. IPS detects attack patterns in the visible traffic flow. Web Protection controls web content and categories, Application Control classifies applications, TLS Inspection makes encrypted content visible when required, and Zero-Day Protection analyzes suspicious files. Threat Feeds, including maintained feeds from Cybora, additionally block known malicious IP addresses, domains, or URLs. These modules complement one another; none replaces a tightly scoped firewall rule, patch management, or the correct policy selection.

Validate a controlled pilot deployment

Before starting, define the test duration, owner, baseline, and abort criteria. The baseline includes the pattern timestamp, firewall Rule ID, previous and new IPS policies, known exceptions, CPU and memory usage, and at least one unchanged control connection. Tests involving VoIP, ERP, industrial protocols, VPNs, or legacy applications require a maintenance window.

1. Verify policy assignment: Create a new session and check the expected firewall Rule ID and IPS Policy ID in Packet Capture or the firewall log. This proves the assignment, but not a signature detection. The shared procedure for Log Viewer and Packet Capture can be applied directly to the test connection.
2. Test real workflows: Test sign-in, file transfers, updates, APIs, and long-running sessions. A ping is not an adequate substitute.
3. Evaluate events: For a detection, record the signature ID, signature name, policy, firewall rule, source, destination, ports, and effective action. Do not generate a real attack merely to test functionality. For a deterministic, harmless detection, use the controlled custom-signature pilot.
4. Compare the control connection: An allowed connection from the same scope must continue to show the expected rule and application. If packets disappear, a separate analysis of dropped packets helps isolate the cause.
5. Only then expand the deployment: Add more hosts or rules only when no unexplained blocks remain and the predefined load, latency, and application limits are being met.

Success does not require an attack signature to have been triggered. What matters is verified policy assignment, functioning test and control workflows, no unexplained blocks, and acceptable resource usage. If a critical business process fails, an unexplained block occurs, or an agreed performance threshold is exceeded, restore the documented baseline values for policy assignment and rule logging. Delete a dedicated pilot policy only after it is no longer assigned to any rule and its exceptions have been documented. If IPS was globally disabled before the pilot, restore that original state only after checking which other firewall rules would lose IPS protection as a result.

Interpret logs, Packet Capture, and reports correctly

The tools answer different questions:

• Firewall log: ips_policy_id shows which policy was attached to the flow. This is useful even without a signature detection.
• IPS event: log_type=IDP, signature_id, signature_msg, idp_policy_id, fw_rule_id, classification, and log_subtype connect the signature, policy, rule, and result. The detection_severity value in the log is not necessarily represented in the same way as the policy’s categorical severity.
• Packet Capture: shows information including the firewall Rule ID, NAT ID, and IPS Policy ID for the packet flow.
• ips.log: provides more detailed information about IPS, DPI, Application Control, and Active Threat Response decisions.
• sig_upgrade.log and sigmigration.log: show signature updates and migrations, respectively.
• Reports > Network & threats > Intrusion attacks: is suitable for retrospective analysis; Log Viewer remains better for individual recent events.

Sophos Firewall services and logs explains the purpose of additional log files and services. When multiple protection modules are active, compare the same timestamp across the firewall, IPS, web, Application Control, and SSL/TLS Inspection logs. A firewall rule can allow traffic that a downstream module subsequently blocks.

Test performance under comparable load

The resources required by IPS vary with the model, traffic, signatures, TLS Inspection, Application Control, VPN, and packet size. Before and after activation, measure CPU, memory, throughput, latency, retransmissions for critical applications, and IPS/DPI and syslog volume under comparable load.

Briefly disabling IPS does not establish causation. Reproducible comparisons require correctly interpreted firewall performance metrics and a controlled iPerf test.

Resolve false positives instead of simply allowing them

An IPS detection may be a false positive, an unexpected application, or a genuine exploit attempt. First, record the signature ID and name, source, destination, service, firewall rule, time, frequency, affected application, and patch status. Then make a decision:

1. Reproduce the legitimate workflow and confirm that this exact SID triggers on it.
2. Check the patch status, vendor guidance, and reachability of the protected system.
3. Assess the risk of allowing the detection. Do not create a permanent exception for an unclear or non-reproducible finding.
4. Choose the narrowest reversible measure: preferably patch the system or narrow the data path; otherwise, set one SID to Allow packet for a limited time in a policy used only for that path. Disable and Bypass session remove more protection and require stronger justification.
5. Retest the legitimate positive flow and a negative or control flow.
6. Document the exception, owner, and review date, and reassess it after an application, pattern, firmware, or system update.

If many signatures interfere with the same application, a dedicated, tightly scoped policy or better segmentation is cleaner than a collection of permanent global exceptions. Globally disabling IPS is not an appropriate rollback for a single SID.

Troubleshoot by symptom

No IPS events are visible

First, create a new session and check the firewall Rule ID and ips_policy_id in the firewall log or Packet Capture. If the Policy ID is missing, the flow is matching another rule or the selected rule has no IPS policy assigned. If the policy can be verified but there is no signature detection, that may be correct for harmless traffic. For reproducible verification, use a tightly scoped custom signature in an isolated pilot, not a real exploit.

An event is present, but traffic is not blocked

Check signature_id, the policy, and log_subtype in the IPS event. Then check the first matching policy rule and its effective action. Allow packet, Disable, or Bypass session can prevent an expected block; a broad rule higher in the list can override the specific rule. Test a new session after every change.

IPS signatures are missing or the pattern update fails

Check the license status, global IPS switch, and Backup & firmware > Pattern updates together. Failed or a recent Application Signatures timestamp does not prove that the IPS update succeeded. sig_upgrade.log shows the update path; for license issues, licensing.log provides additional context. In an HA cluster, the Primary updates the IPS patterns and automatically synchronizes them to the Auxiliary.

The IPS service shows DEAD

Under System services > Services, check and document the status of the IPS service. If Sophos Support also requests node-specific shell output, select 5 Device Management > 3 Advanced Shell to run this read-only check:

service -S | grep -i ips

The relevant line is the one whose first service name is exactly ips; ipsec-monitor is not relevant. This Advanced Shell command is not part of the published known-issue procedure and should be used only for support-coordinated diagnostics. In an HA cluster, capture the requested status separately on every affected node.

In SFOS 22.0 GA and later, required web policy configuration data may be missing in rare cases. The web policy service then fails to start, IPS cannot initialize its policy and remains in the DEAD state, and pattern updates also fail. In an HA cluster, each node may be affected independently.

Record the SFOS version, time, node, service status, ips.log, and sig_upgrade.log, and contact Sophos Support with reference to NC-181971. The status alone does not prove this cause. Sophos still does not list a fixed version in the current known-issues list and provides the workaround through Support. Repeated restarts or undocumented repair commands are not a sound diagnostic approach.

Use the full signature package only for confirmed special cases

During a pattern update, SFOS can download the full IPS signature package instead of a partial package. This option applies only to appliances with at least 32 GB RAM and, according to Sophos, may affect performance. It does not enable IPS or assign a policy to a firewall rule.

A valid reason to use it is a signature specifically identified by Sophos Support that is absent from the partial package. Do not enable this option preemptively simply because more signatures sound better. First, read the current state in the Device Console:

system ips full-signature-pack show

The Device Console help does not specify a default. After confirming the RAM requirement and the specific need, enable the full download:

system ips full-signature-pack enable

After the next pattern update, check the pattern timestamp, sig_upgrade.log, the expected signature, IPS status, CPU, RAM, and affected traffic. If the expected benefit does not materialize or operation deteriorates, restore the previously recorded state. If it was disable before the test, use this rollback command:

system ips full-signature-pack disable

PQC detection in SFOS 22.0 MR2 and later

SFOS 22.0 MR2 can detect and control pure and hybrid post-quantum key exchange methods based on ML-KEM. The new IPS patterns are disabled by default because PQC is not inherently suspicious. If you need to evaluate these connections, first use a dedicated pilot policy with Allow packet and logging. Only a defined use case and stable positive and control tests justify Drop session or Reset. Sophos Firewall v22 MR2: PQC control provides background information.

FAQ