Set up and safely test Sophos Firewall IPS

Intrusion Prevention System (IPS) is one of the most important protection features on Sophos Firewall. IPS checks traffic for known attack patterns, exploits and suspicious protocol patterns. Used correctly, it adds protection for clients, servers, published services and VPN links alongside firewall rules, Web Protection, Application Control and TLS Inspection.

In practice, however, IPS is not a switch that should simply be enabled at maximum everywhere. An incorrect or overly broad IPS policy can break legitimate traffic, disrupt VoIP, consume performance or create false alerts. IPS should therefore be enabled in a planned way, selected appropriately per rule and then checked with logs and tests.

Which security-inspection article fits?

IPS is only one part of Security Inspection. Depending on the problem or rollout goal, another article may fit better:

This keeps the protection logic understandable: firewall rules limit permitted traffic, IPS checks this traffic for attack patterns, Web Protection controls web content, TLS Inspection provides more visibility for HTTPS, and Zero-Day Protection adds file and download inspection.

When IPS makes sense

IPS is especially worthwhile where traffic has a higher risk or where known exploits should be blocked early.

Typical use cases:

• Client networks with internet access
• Server networks and DMZs
• DNAT rules to internal servers
• Site-to-site VPN traffic between locations
• Remote access traffic when internal systems are accessed after VPN dial-in
• VoIP, only with careful policy selection and testing
• particularly critical segments such as management, backup or infrastructure networks

For published servers, IPS should always be considered together with clean NAT, tight firewall rules, logging and patch management. The article Publish servers via DNAT on Sophos Firewall explains the right context for NAT and firewall rules. For the basic rule structure, Understand and configure Sophos Firewall rules correctly fits.

Requirements

IPS only works when the necessary requirements are met.

Check before rollout:

• An active Network Protection subscription or trial licence is available.
• IPS Protection is enabled under Intrusion prevention > IPS policies.
• Pattern updates work and the firewall can reach Sophos update services.
• Firewall rules contain suitable IPS policies under Detect and prevent exploits (IPS).
• Logging is enabled for the affected rules and log types.
• There is a process for false positives, exceptions and policy adjustments.

If the Network Protection subscription expires, the IPS switch can still appear active even though IPS is no longer enforced. If IPS is disabled manually or after a trial expires, signatures, updates and configuration options may be restricted depending on the state. Before disabling it, an IPS configuration backup or export should therefore be planned.

Warning: IPS depends on licence and updates. A firewall rule with a selected IPS policy does not automatically mean that IPS is actually protecting traffic. Licence status, global IPS enablement, signatures and logs must be checked.

Enable IPS globally

Global enablement is done in the Sophos Firewall web interface:

1. Open Intrusion prevention > IPS policies.
2. Enable IPS Protection.
3. Check licence notices.
4. Wait until signatures are available.
5. Check existing default policies.
6. If necessary, clone a custom policy from an existing policy.

Changes to certain acceleration features can restart IPS. Such changes should therefore not be made during productive troubleshooting or in a narrow maintenance window without a plan.

Choose the right IPS policy

IPS policies should match the traffic. The strictest policy is not automatically the best policy.

A custom IPS policy is useful when a default policy is too broad or when only specific signatures with an adjusted action are required. Signatures should not be disabled without a plan. First it must be clear which traffic is affected, which signature triggered and whether it is really a false positive.

Build custom IPS policies cleanly

Custom IPS policies should be cloned from an existing policy and then adjusted specifically. IPS policy rules contain signatures and an action. The firewall evaluates these rules from top to bottom. As a result, a rule that is too broad above a specific rule can hide the desired behaviour.

For signatures, these fields are especially important:

The action in a policy rule can override the recommended signature action. This is useful, but risky. A blanket Allow packet, Disable or Bypass session can remove protection without this being immediately obvious in everyday operation later.

Practical handling of actions:

For production policies, a short change note is therefore useful: Which signature was changed, why, in which policy, for which firewall rule and by when will the adjustment be reviewed again?

Use IPS in firewall rules

IPS is not only enabled globally. The policy must also be used in the appropriate firewall rule.

1. Open Rules and policies > Firewall rules.
2. Edit or create the relevant rule.
3. Under Other security features, enable Detect and prevent exploits (IPS).
4. Select the appropriate IPS policy.
5. Enable rule logging.
6. Save the change.
7. Test traffic in a controlled way.

With several overlapping rules, the order is decisive. If traffic is matched by a rule without IPS, the IPS policy in a later rule does not help. For such cases, Sophos Firewall rule does not match: check the causes is the better follow-up article.

Rollout in production environments

IPS should be introduced step by step.

1. Start with pilot rules

First choose a small, well-known rule, for example a client test network or a single DNAT rule. Then check logs and test with real applications.

2. Evaluate hits

Filter for IPS events in the Log viewer. Source, destination, service, rule, signature, action and time are important. If several protection modules are involved, Web, Application Control, SSL/TLS Inspection and firewall logs must be considered together.

3. Narrow down false positives

If legitimate traffic is blocked, IPS should not immediately be disabled globally. A narrow analysis is better:

• Which signature triggered?
• Which application or service was affected?
• Does it affect one host, one network or only one port?
• Is the target system currently patched?
• Is a tighter firewall rule possible?
• Is an adjusted IPS policy sufficient instead of a global exception?

4. Expand gradually

Only when the pilot rule is stable should IPS be rolled out to further rules. Especially with VoIP, ERP systems, industrial protocols, VPN links and older applications, test windows and a fallback plan are needed.

Control exceptions and signature changes

IPS exceptions are security decisions. If a signature disrupts legitimate traffic, an adjustment may be necessary. Even so, the whole IPS policy should not be weakened reflexively and IPS should not be disabled on the rule. First it must be clear whether this is really a false positive or whether the signature makes a real risk visible.

Before an exception, at least collect:

If an exception is necessary, it should be set as narrowly as possible:

• disable an individual signature instead of a complete category
• use a custom IPS policy for exactly the affected firewall rule
• check policy rule order so that specific rules are not hidden by broad rules
• make source, destination and service tighter in the firewall rule
• document the exception with reason, owner and review date
• after the change, check whether only the expected traffic is affected

A temporary exception is often better than a permanent shutdown. After an application update, firmware update or target-system patch, the exception should be reviewed again. If many signatures for the same application cause problems, a custom policy or clean segmentation is usually better than a large global exception.

Logging and troubleshooting

IPS analysis needs several perspectives.

The article Sophos Firewall troubleshooting: services and logs classifies ips.log and related log files. For the combination of Log Viewer and Packet Capture, Test Sophos Firewall rules with Log Viewer and Packet Capture fits. If packets are dropped unexpectedly, Analyse dropped packets on Sophos Firewall helps.

Consider performance

IPS consumes resources. How much the load increases depends on the model, traffic, enabled signatures, TLS Inspection, Application Control, VPN, packet size and throughput.

Before and after enabling, check:

• CPU and memory load
• IPS- and DPI-related load
• Throughput on affected interfaces
• Latency and retransmits for critical applications
• Log volume and syslog load
• User or application messages after the change

If a throughput problem is suspected, IPS should not simply be disabled and the case closed. A comparison with a clear test method is better, for example using Interpret Sophos Firewall performance data correctly and Test Sophos Firewall performance with iPerf.

Common mistakes

• IPS Protection is globally disabled.
• Network Protection has expired or is not active.
• No IPS policy is selected in the firewall rule.
• Traffic hits a different rule than expected.
• Logging is disabled on the affected rule.
• A server policy is applied to client traffic or vice versa.
• VoIP or special protocols are inspected with an aggressive policy without a pilot phase.
• False positives are solved with global deactivation instead of a narrow adjustment.
• Signatures are disabled without evidence, owner or review date.
• After a trial expires, no check is made whether signatures or policies are still available.
• Performance problems are not compared with measured values before and after the change.

Operational checklist

• Network Protection or trial licence checked.
• IPS Protection enabled under Intrusion prevention > IPS policies.
• Signatures and pattern updates checked.
• Suitable IPS policy selected per firewall rule.
• Rule logging enabled.
• Pilot rule tested with real traffic.
• Log viewer and ips.log checked.
• False-positive process defined.
• IPS exceptions documented narrowly and reviewed again later.
• Custom IPS policies contain no unjustified Allow, Disable or Bypass session rules.
• Performance before and after enablement compared.
• Critical exceptions documented and given a review date.

FAQ