Create and test custom IPS signatures on Sophos Firewall

A custom IPS signature is useful when Sophos doesn’t provide a suitable signature for a clearly defined network or application pattern. It can detect a known plain-text string, an unusual protocol characteristic, or a precise combination of port, direction, and payload.

The signature alone doesn’t protect anything. It must be used in an IPS policy, that policy must be assigned to the firewall rule that actually matches, and the data stream must be visible to IPS. A pattern that is too broad can block legitimate traffic; one that is too narrow never matches.

Test a new signature first with Allow packet and logging on a small pilot path. Drop packet, Drop session, Reset, and Bypass session change production traffic and should only be used after a reproducible positive and negative test.

A controlled pilot in six steps

1. Describe the detection case with protocol, direction, port, and a unique pattern.
2. Under Intrusion prevention > Custom IPS signatures, create a narrow signature with Allow packet.
3. Add the signature to a dedicated rule in a deletable IPS policy.
4. Assign this IPS policy only to the intended pilot firewall rule and enable logging.
5. Generate one matching and one deliberately non-matching test, then compare Log Viewer, ips.log, and the rule match.
6. Set the intended action only after stable acceptance; remove the policy assignment or signature if unexpected matches occur.

A saved entry or a successful syntax check is not proof that it works. Success means that the positive test matches exactly the expected custom signature and firewall rule, the negative test doesn’t match, and the production application behaves as before.

When a custom signature is appropriate

Custom signatures suit a stable characteristic that is visible at packet or stream level. This can be a proprietary protocol value, a clear exploit indicator, or temporary protection for an internally known vulnerability. The expected data path and intended response must be defined before writing the signature.

For changing IP addresses or domains, hosts, services, and groups, threat feeds, or narrow firewall rules are usually more appropriate. A custom signature also doesn’t replace patch management or a well-maintained vendor rule. Developing a permanent custom signature for a single log event is rarely proportionate.

Encrypted payload is an important boundary. IPS can only detect a content pattern in an HTTPS payload if the content is actually decrypted and visible to the engine on the selected processing path. Without suitable TLS inspection, only unencrypted or otherwise visible characteristics are normally available.

Check the license and lifecycle first

Custom signatures can’t be configured if the IPS trial has expired or IPS Protection is turned off under Intrusion prevention > IPS policies. Sophos recommends turning IPS back on within 30 days if existing custom signatures must be retained. A backup or export therefore belongs in the rollback plan before licensing, IPS, or major policy changes.

IPS must then be active globally and the processing firewall rule needs an IPS policy. The complete baseline is covered in Set up and safely test Sophos Firewall IPS. A custom signature extends this data path; it isn’t a parallel protection mechanism.

Narrow the rule syntax deliberately

The form separates Protocol and Custom rule. The rule combines individual keywords, their values, and semicolons. Requiring several independent characteristics to match generally reduces accidental hits. At the same time, the signature must not become so specific that a harmless protocol change makes it ineffective.

For an exclusively controlled plain-text test, select TCP as the protocol and use a narrow payload pattern such as:

content:"AVANET-IPS-PILOT"; nocase;

AVANET-IPS-PILOT is a deliberately conspicuous documentation value. The corresponding pilot firewall rule is additionally limited to the test service, for example TCP port 8080. Replace the token, direction, and port with values that occur in the real data stream visible to IPS. This isn’t a universal attack signature and must not be placed unchanged on broad production rules.

Payload and search window

content searches for a character or byte sequence; binary values are enclosed in pipe characters. nocase ignores case for a content match, and rawbytes works on raw data. depth and offset limit the search absolutely in the payload, while distance and within work relative to the previous match. uricontent, isdataat, and pcre cover more specialized URI, position, and regular-expression cases.

A narrow search range reduces accidental matches and processing overhead. In particular, pcre, large windows, and several broad content patterns should only be introduced with realistic packets and observed load. If depth is shorter than the searched content pattern, the signature can never match.

Headers, streams, and structured values

Source, destination, and port can be narrowed with srcaddr, dstaddr, srcport, and dstport. IP header options include ttl, tos, id, ipopts, fragoffset, fragbits, dsize, ip_proto, and samip. TCP characteristics use flags, flow, seq, ack, and window; itype, icode, icmp_id, and icmp_seq apply to ICMP. rpc, byte_test, and byte_jump are intended for structured or binary protocols.

The complete SFOS 22 custom IPS syntax reference remains authoritative for complex rules. Don’t adopt undocumented Snort keywords or rules copied from other engines without verification.

Create the signature and assign it to a policy

Under Intrusion prevention > Custom IPS signatures > Add, specify Name, Protocol, Custom rule, Severity, and Recommended action. A name such as PILOT-TCP-8080-AVANET-TOKEN makes the purpose and test boundary visible. Severity is your own risk assessment; it doesn’t prove that the pattern is malicious.

Keep Recommended action set to Allow packet for the first run. The other actions have much stronger effects:

• Drop packet discards only the matching packet.
• Drop session terminates the session after the match.
• Reset terminates a TCP session and sends a reset to the originator.
• Bypass session permits the traffic and stops scanning the rest of the session.

When saving, SFOS reconfigures the IPS engine. According to Sophos, this happens without interruption when sufficient free RAM is available. With little free RAM, the engine can restart and cause a brief disruption. Even a seemingly small signature change therefore belongs in an observed maintenance window.

The often-missed second part follows: Open a deletable policy intended for the pilot under Intrusion prevention > IPS policies, add a rule, select the custom signature, and place the specific rule above broader rules. Then assign this policy under Rules and policies > Firewall rules to the pilot rule that actually matches.

Perform a positive and negative test

The positive test sends the agreed pattern over the intended port and in the expected direction. At the same time, record Firewall Rule ID, IPS policy, signature name, source, destination, action, and timestamp in Log Viewer. ips.log provides additional engine details; Test a firewall rule systematically explains how to connect the rule, packet capture, and security module.

At least one negative test follows: the same service without the token, another port, or a different direction. The signature must not match. For a content pattern, normal application requests are also important because short or generic strings can occur in completely legitimate payloads.

Only after both tests are stable should the intended blocking action be set and tested again. A blocking signature is accepted only when it stops exactly the positive case, the negative case continues, and no other firewall or IPS rule causes the effect.

Check the number of signatures

The count can be found in WebAdmin without using the shell. Under Intrusion prevention > IPS policies, open a deletable policy and add a new policy rule. With Select all, SFOS shows the total above Action. The list is only visible when adding a rule to a deletable policy; close the dialog without saving afterward.

Sophos also documents two read-only Advanced Shell queries:

psql -U nobody -d signature -p 5434 -c "select count (*) from tblidprules;"
psql -U nobody -d corporate -c "select count (*) from tblidpcustomsignature;"

The first command counts default signatures and the second counts custom signatures. These database queries don’t change data, but still belong in a documented support or diagnostic session. The count isn’t proof of quality or operation and can change with pattern updates.

When the signature doesn’t behave as expected

There is no match

First verify that IPS is active, the traffic matches the expected firewall rule with the correct IPS policy, and the custom signature is actually present in an evaluated policy rule. Then examine protocol, direction, port, encryption, and the real payload. A string shown in a browser doesn’t necessarily appear unchanged in the network packet.

A narrowly filtered packet capture helps confirm visible content and direction. If the pattern isn’t present there, changing the IPS rule can’t create it. If the packets are visible, check offset, depth, distance, within, stream state, and policy-rule order.

Too many connections match

Keep the signature on Allow packet until source, destination, port, direction, or search window has been narrowed. Generic words, short binary sequences, and unbounded regular expressions are typical causes. A broad firewall rule makes the effect even harder to control.

If the firewall shows increased resource usage or an IPS restart after saving, record the time, model, firmware, free resources, and ips.log. Repeatedly saving different variants isn’t a clean test at this point; first clarify the cause and a maintenance window.

Roll back safely

For unexpected matches, first remove the custom rule from the pilot policy or restore the previous IPS policy on the firewall rule. Then verify new sessions with the positive and negative tests. Delete the custom signature only when it has no other use.

Before deletion, document which policy, firewall rule, and application used it. Logs, the tested rule version, and the reason for rollback belong in the change record. Turning IPS off globally or removing the entire production policy isn’t an appropriate rollback for a single defective signature.

FAQ