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.

PHP2Shell: check detection and patch status separately

For PHP2Shell (CVE-2026-109618 and CVE-2026-109619), the Sophos advisory, version 4 dated 22 October 2026, describes IPS signatures available for Firewall and Endpoint since that date to detect exploitation attempts. This provides neither a blanket blocking guarantee nor specific WAF protection. Affected PHP runtimes must still be updated independently.

On the firewall, verify successful IPS pattern downloads, the rule actually matched by the affected traffic, its IPS policy and the effective signature action. The diagnostic sections below explain these checks. Correlate firewall and server logs by time; an absence of alerts establishes neither that a patch is installed nor that no attack occurred. A real exploit request is not a suitable production test.

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 technical scope; the category reference follows the configuration workflow.

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

SID is the unique ID of an IPS signature. Category identifies its functional group, Severity the degree of threat severity, and Platform the affected platform, such as Microsoft Windows. Target distinguishes client and server signatures; Recommended action specifies the intended action for a match. Category names and the category descriptions below do not guarantee blocking: the effective policy rule determines the action.

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:

Do not treat Warning as proof of blocking: The severity help describes Warning as always alerting, while the general rule help describes overriding the recommended action. These statements do not clearly establish how a particular Warning signature behaves when both apply. Do not infer blocking from the severity label or a selected Drop action alone. Verify the effective action in a controlled pilot for that use case, and resolve unclear behavior with Sophos Support before production use.

• 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.

Distinguish DDoS signatures from local DoS limits

DDoS signatures are available only on XGS 5500 and higher-capacity firewalls. On a supported model, create a dedicated policy, such as DDoS_Protection, under Intrusion prevention > IPS policies > Add and save it with Save. Then open Edit > Add, enter a rule name, choose Select all, type ddos in Smart filter, and press Enter. Set Action to Drop packet, save the rule first and then the policy with Save. Under Rules and policies > Firewall rules, assign the policy to the rule that actually matches the traffic. Check the license, global IPS switch, available signatures, and policy assignment as described above; the model name alone does not prove active inspection.

The local DoS settings under Intrusion prevention > DoS & spoof protection are separate and support IPv4 and IPv6. Set packet and burst rates based on your own traffic, select the relevant Apply Flag, and click Apply. When a source exceeds the enabled ICMP/ICMPv6 per-minute limit, the firewall drops excess packets while the attack continues. The documentation example of 1200 packets per minute per source is not a production default. DoS and spoof protection explains measurement, status, exceptions, and rollback. If the internet circuit is already saturated, provider or upstream protection is needed; IPS cannot recover that bandwidth. Do not generate a real flood attack for functional testing.

Category reference

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.

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

Safely interpret IPS configuration through the XML API

For repeatable configurations, the XML API distinguishes two tasks: IPSFullSignaturePack controls the package download, while IPSPolicy describes a policy with signature selection and actions. Neither object replaces the license check, the global IPS switch, assignment to the firewall rule that actually matches the traffic, or validation with new traffic. The prerequisites and pilot procedure above therefore also apply to automated changes. Use the XML API safely explains access and response evaluation.

Full package: Status is not a general Get

For IPSFullSignaturePack, the SFOS-22/23 API reference describes the required scalar field Status. Its values are exactly, and in lowercase, enable, disable, and show: the first two enable and disable the full package download, respectively, while the third queries the status within this object. The example shows only enable/disable; it does not establish a general Get operation. The API parameter table specifies disable as the default, whereas the Device Console help above does not specify a default. This is no substitute for reading the actual initial state.

Even through the API, the option remains restricted to appliances with at least 32 GB RAM and a demonstrated need. It is neither a license switch nor a policy assignment. For the IPSFullSignaturePack operation, the reference lists status 200 with Operation Successful. and 500 with Operation Fail.. A successful configuration response does not yet prove that the pattern download has completed or that IPS protection is effective: after the next update, perform the signature, resource, and traffic checks described above.

Policies: distinguish inherited rules from your own selection

In the configuration example, IPSPolicy encloses the fields Name, Description, Template, and RuleList. The comment for Template states that if an existing policy is selected as a template, all its rules are inherited and any additionally specified rules are added; without a template, the policy contains only the specified rules. A short rule list of your own therefore does not automatically mean a tightly scoped policy when a template is used. Check the complete list and order actually saved so that no broad inherited rule overrides a planned SID exception. The example provides no assurance about how a later update handles rules not included in the request.

Each Rule entry in RuleList combines a RuleName, the RuleType, the selection, and an Action. RuleType distinguishes between Default Signature and Custom Signature. The selection field is literally named SignaturSelectionType in the reference, without adding a missing letter. It distinguishes between All Application and Individual Application. The example also shows CategoryList with Category, SeverityList with Severity, PlatformList with Platform, TargetList with Target, and SignatureList with Signature. Filter criteria narrow the selection to what is technically relevant; individual signatures are named separately. The descriptions for Platform and Target refer to lists by ID: do not use display labels as API IDs without verification.

For Action, the example shows the text values Allow Packet, Drop Packet, Disable, Drop Session, Reset, Bypass Session, and Recommended. Their effects are explained above. The parameter table additionally lists 7 but does not explain any mapping to a named action. Do not guess a meaning or production setting from this number; if the selection is unclear, edit the policy in WebAdmin or clarify the syntax with Sophos Support.

The parameter table requires a scalar UTF-8 policy name without commas and with a maximum of 60 characters; Description is optional. For rules, it lists required names with a maximum of 70 characters, along with Rule Type, signature selection mode, and action as arrays with multiple values. According to the table, duplicate values are ignored only for rule names, not for the other arrays mentioned. Individual signatures and the four filter lists are optional two-dimensional string arrays. These table entries do not guarantee atomic processing or that omitted selection fields remain unchanged during an update. Before making a change, back up the complete policy, including inherited rules, actions, exceptions, and firewall rule assignments; afterward, read back the saved selection and order and validate the pilot with new sessions.

Responses: check the operation and saved state together

The following mappings appear in both SFOS-22/23 references. The Message.* identifiers remain unresolved documentation symbols: they are neither guaranteed runtime messages nor proof of a specific cause. The values are XML API status values, not automatically HTTP status codes.

Especially for 505 after Add, do not assume that the policy has remained unchanged, and do not infer an engine restart from the symbol alone. For 502, compare the existing name and the intended policy instead of creating a second policy; for 522, check the actual policy inventory. For 506, read the license and global IPS state without enabling IPS as automatic error handling. These checks help establish the state but do not replace evaluation of the actual response.

According to the reference, Delete identifies the policy through the required Name, with the same name restrictions. The Delete page does not contain a complete request wrapper; therefore, do not assemble an executable delete request from it here. Before an intended deletion, check assignments and dependencies and secure the required recovery path. For 503, check existing references in particular, without inferring a complete list of blocking relationships from the symbol. After an unclear or failed response, first check in WebAdmin whether the policy still exists and which rules, actions, and assignments are actually saved. Only after establishing the current state should you decide on a targeted retry or restoration of the documented initial values; the response tables promise neither automatic repeatability nor rollback. Continue to follow the central API safety procedure.

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