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:

• Enable IPS, select a policy and check false positives: This article.
• Control web categories, web policies and user web traffic: Set up Sophos Firewall Web Protection with Web Policies.
• Decrypt and inspect encrypted web traffic: Roll out Sophos Firewall TLS Inspection correctly.
• Check files and downloads with sandbox or ML: Understand and operate Sophos Firewall Zero-Day Protection.
• Block known malicious IPs, domains or URLs: Set up and operate Sophos Firewall Threat Feeds safely.
• Reduce simple spoofing or flooding patterns: Check Sophos Firewall Spoof Protection and DoS Settings.
• Secure publicly reachable servers with NAT and IPS: Publish servers via DNAT on Sophos Firewall.
• Analyse unexpected drops, rule ID or IPS policy ID: Analyse dropped packets on Sophos Firewall.

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.
• For published services and segment boundaries, it is clear which firewall rule really matches the traffic.

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

In current SFOS versions, global enablement is done under Protect > Intrusion prevention > IPS policies. In some views, the menu path appears in shortened form as Intrusion prevention > IPS policies.

1. Open Protect > 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.

A custom policy is created with Add, given a name and cloned from an existing policy as a starting point. Then only the rules that are really needed are adjusted. This is easier to understand later than a completely free collection of individual signatures where nobody knows why it was built that way.

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.

• Clients to internet: Client or LAN-to-WAN policy. Consider Web, Application Control and TLS Inspection as well.
• Internet to internal server via DNAT: Server or web server policy. Monitor target system, ports and false positives closely.
• Site VPN: Policy depending on source and target systems. Test performance, MTU/MSS and applications.
• VoIP: very cautious and specific. SIP/RTP must not break because of overly aggressive signatures.
• Management networks: targeted and restrictive. Test admin access, monitoring and backup traffic.

IPS is also worthwhile at segment boundaries: client to server, VPN to server, management to infrastructure. This makes lateral movement after an initial compromised system more difficult. The order of firewall rules remains important, however. IPS only protects traffic that really passes through a rule with a selected IPS 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.

When adding an IPS policy rule, signatures are selected. They can be filtered by Category, Severity, Platform and Target. Custom IPS signatures can be added for special cases. This should only be done when the detection case is clearly described and the policy will be reviewed later.

For signatures, these fields are especially important:

• SID: unique signature ID for logs, tickets and exceptions.
• Category: technical area, for example browser, operating system, DNS, RPC or malware.
• Severity: severity of the threat.
• Platform: target platform, for example Windows, Linux or browser-related components.
• Target: client- or server-related signature.
• Recommended action: default action recommended by Sophos.

Severity should not be read by gut feeling. Sophos roughly maps Critical to CVSS 9 to 10, Major to 7 to below 9, Moderate to 4 to below 7 and Minor to 1 to below 4 or less critical signatures. Warning indicates suspicious traffic and is treated as an alert. For policy decisions, this means that a Major signature on an exposed server should be assessed differently from a Warning hit in a test network.

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.

Packet-based actions inspect every packet. Session-based actions inspect until the first hit and then affect the session. Drop session, Reset and Bypass session are therefore stronger interventions than allowing or dropping a single packet.

Practical handling of actions:

• Recommended: Default for most production rules. Behaviour depends on the signature.
• Allow packet: Observation without blocking, for example in a pilot. Attack is not prevented.
• Drop packet: Drop individual packets. Can disrupt applications.
• Drop session: End the session when an attack should be prevented. Stronger intervention in production traffic.
• Reset: Actively reset TCP session. User or application sees hard interruptions.
• Disable: Disable signature. Protection is removed for this signature.
• Bypass session: Stop scanning the rest of the session. Depending on the architecture, this traffic can run in FastPath or offload. This can remove more traffic from inspection than expected.

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.

If the firewall rule does not contain an IPS policy, global IPS enablement has no effect on this traffic. 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, SID, severity, 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:

• Signature ID and signature name: shows which detection triggered.
• Source, destination, service and firewall rule: narrows down the affected traffic.
• Time and frequency: separates a single event from a recurring pattern.
• Application or protocol: helps assess whether the traffic is legitimate.
• Patch level of the target system: reduces the risk of allowing a real exploit.
• Packet Capture or log excerpt: provides evidence before the policy change.

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.

• Log viewer: IPS hits, signature, action, source, destination, rule.
• ips.log: deeper indications about IPS, DPI and Application Control decisions.
• Packet Capture: packet flow, rule ID, NAT ID, IPS policy ID and direction.
• Rule test: check which firewall rule actually matches.
• Syslog or Central Reporting: longer retention and correlation.

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.
• A broad IPS policy rule is above a specific rule and hides it.
• 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 Protect > 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