Chapter 27: IPS

Home Prev	cOS Stream 4.00.03 Administration Guide	Next

27.1. Overview

Computer servers can sometimes have vulnerabilities which leave them exposed to attacks carried by network traffic. Worms, trojans and backdoor exploits are examples of such attacks which, if successful, can potentially compromise or take control of a server. A generic term that can be used to describe these server orientated threats are intrusions.

Intrusions differ from viruses in that a virus is normally contained in a single file download and this is often downloaded to a client system which it then can infect. An intrusion manifests itself as a malicious pattern of Internet data aimed at bypassing server security mechanisms. Intrusions are not uncommon and they can constantly evolve because their creation can be automated by the attacker.

Intrusion Prevention with the Clavister NetShield Firewall

The Intrusion Prevention System (IPS) in cOS Stream provides an important defense against intrusion attempts. IPS works by scanning flows through the Clavister NetShield Firewall, searching for data patterns that indicate an intrusion is being attempted. Once detected, the administrator can choose what action to take, including dropping the flow.

Which data flows that IPS scans is determined by defining one or more IPSRule objects in the cOS Stream configuration. The data patterns that IPS searches for are contained in one or more signature files which reside on the firewall disk storage. These can consist of a single Clavister supplied signature file and/or multiple or a single custom signature file in Snort format.

	Note: IPS will never scan firewall management traffic
	The IPS feature in cOS Stream will never scan any management traffic. This includes SSH and SNMP traffic as well any log messages that are sent. This ensures that IPS cannot interrupt the ability to manage the firewall.

IPS and Scanning Encrypted SSL Traffic

Using the feature called SSL Inspection, it is possible for IPS to scan encrypted SSL traffic passing through the firewall. Configuring this is described in Chapter 15, SSL Inspection.

Behavior on License Validity Expiry

Note that if the Upgrades Valid Until date in the firewall's license has passed, the IPS subsystem will no longer scan traffic even if it has been enabled to do so. IPS will also not block any traffic.

IPS Configuration Objects

The following configuration objects are used to configure IPS:

IntrusionPrevention

This exists by default and is the parent object for all IPSRule objects created.
IPSRule

IPSRule objects should be defined to determine what traffic should be scanned. They are independent of IPRule objects and all flows are checked against the IPSRule set.

Each rule has a set of filtering criteria so that triggering traffic will be subject to the rule's IPSRuleAction children.

IPS is enabled when one or more IPSRule objects exist in a cOS Stream configuration. There is no global setting to enable or disable it.
IPSRuleAction

One or more IPSRuleAction objects are added as children to an IPSRule object. The Action property of the object determines what action should be taken when the parent rule triggers AND one of the object's filtering criteria triggers. The filtering criteria are the IPS signatures specified by the SignatureCategory and/or SignatureGroup properties.

The SignatureCategory and/or the SignatureGroup properties can be assigned a comma separated list. However, if a value is not specified for either property, the IPSRuleAction object will never be triggered and its associated action never taken.

Note that a category exists in the vendor signature file for each signature. For custom signature files added to cOS Stream by the administrator, the category of all signatures in the file is the filename itself. Multiple categories can be specified using the asterisk '*' wildcard character to represent any combination of characters. For example: IPS_WEB_*.
IPSSignatureGroup

A list of one or more IPSSignatureGroup objects can be assigned to an IPSRuleAction object. Each group represents one or more IPS signatures that are to be used when the traffic is scanned. No signatures are installed in a default configuration.

The IPSSignatureGroup object has many filtering options which are described next.

Using IPSSignatureGroup Filters

A list of one or more IPSSignatureGroup object can be assigned to the SignatureGroup property of an IPSAction object. An IPSSignatureGroup provides a means to specify individual or collections of signatures that are to be applied to the traffic specified by the associated IPSAction's parent IPSRule.

There are several filtering options for the IPSSignatureGroup which are specified using the following object properties:

IncludeVendorSignature

This specifies a list of one or more individual signature SIDs which may be found in the active vendor signature file.
IncludeCustomSignature

This specifies a list of one or more individual signature SIDs which may be found in the active custom signature file.

If both this and the IncludeVendorSignature property are specified then the two are combined using a logical OR. The complete logic applied to all the filters is described at the end of this property list.
IncludeSignatureGroup

This specifies a list of one or more other SignatureGroup objects. These member groups will then be filtered by the FilterBy properties specified below.
IncludeCategory

The categories to be selected. Different signatures in the vendor file can have different categories. All signatures in the custom file have the same category and that category is the name of the active custom file. For example, if the active custom file is called my_sigs.sig then the assigning this category would be done with:
```
		IncludeCategory=my_sigs.sig
```
FilterByCVE

The CVE (Common Vulnerabilities and Exposures) code is set for some of the signatures. The CVE for vendor signatures can be found in the advisory associated with a signature.
FilterBySeverity

This property can take one of the following values:
1. Attack or Scan for vendor signatures.
2. Custom for all signatures in the custom file.
FilterByString

This property provides the ability to perform a search for an arbitrary character sequence within the name and content of currently included filtering signatures.
CreatedAfter

Only individual signatures created after a certain date will be included. All the vendor signatures will have a creation date. Custom signatures may have a creation date.

The value specified for this property must be in the format yyyy-mm-dd. For example, to include the date 2025-03-22 and any later dates, the property would be set as:
```
	CreatedAfter="2025-03-21"
```

When multiple filter properties of the IPSSignatureGroup object are used, they are combined using the following logic:

(IncludeVendorSignature OR IncludeCustomSignature OR
		IncludeSignatureGroup OR IncludeCategory)
	AND FilterByCVE AND FilterBySeverity
	AND FilterByString AND CreatedAfter

IPS Processing Steps

The steps in IPS processing are the following:

A packet arrives at an interface and cOS Stream performs normal verification. If the packet is part of a new flow then it is checked against the main IP rule set first before being passed to the IPS subsystem. If the packet is part of an existing connection it is passed straight to the IPS system.
Provided that the IP rules allow a flow, all traffic is checked against the IPSRule object list.
If an IPSRule triggers, its child IPSRuleAction objects are processed in order. The signatures specified for each child action are applied to the traffic until one of them triggers.
If the traffic finds a match in the IPSRuleAction signatures specified by the SignatureCategory or SignatureGroup, the Action property specifies what to do. The action performed can be be one of the following:
- Ignore - Do nothing if an intrusion is detected and allow the flow to stay open.
- Audit - Allow the flow to stay open but log the event.
- Protect - This option drops the flow and logs the event. This is the default.

HTTP Normalization

An IPSRule object has a number of properties that can be used for HTTP normalization. This allows the administrator to choose the actions that should be taken when IPS finds inconsistencies in the URIs embedded in incoming HTTP requests. Some server attacks are based on creating URIs with sequences that can exploit weaknesses in some HTTP server products.

The IPSRule properties related to HTTP normalization are as follows:

URIInvalidUTF8

This looks for any invalid UTF8 characters in a URI. The default action when triggered is DropLog.
URIInvalidHex

A valid hex sequence is where a percentage sign is followed by two hexadecimal values to represent a single byte of data. An invalid hex sequence would be percentage sign followed by something which is not a valid hexadecimal value.

The default action when triggered is DropLog.
URIDoubleEnc

This looks for any hex sequence which itself is encoded using other hex escape sequences. An example would be the original sequence %2526 where %25 might be decoded by the HTTP server to '%' and results in the sequence '%26'. This is then finally decoded to '&'.

The default action when triggered is Ignore.

Setting a Scan Limit

In some circumstances, it may not be desirable to apply IPS scanning to more than an initial portion of the data sent in a flow. This may be done for performance reasons.

cOS Stream provides the ability to impose a scan limit which means that IPS will only scan a specified number of bytes at the beginning of a flow and then scanning will stop for the remainder of the flow.

By default, the scan limit feature is disabled. To enable it, the following properties of an IPSRule object are used:

ScanLimit

This is a boolean property that takes the value Yes or No. The default is No so no limit is applied. If set to Yes then a limit is applied to the number of initial bytes scanned by IPS in either direction.

ScanLimitBytes

If ScanLimit is enabled then this property specifies how many bytes are scanned by IPS in a flow, in either direction, before scanning stops.

The default value for this property is 800 bytes. This means that only the first 800 bytes for either direction of a flow will be scanned.

A CLI example of using these options can be found in Section 27.2, Setting Up IPS.

Notes About Setting a Scan Limit

The following points should be noted when using a scan limit with IPS:

The feature should be used with caution since an attacker might deliberately choose to insert an attack in a flow at some point after the limit given by ScanLimitBytes. However, typically it is more likely that an attack that can be detected by IPS will be present in the initial portion of a flow.
TCP flows are better candidates for applying a scan limit since the integrity of TCP flows is partially ensured by the mechanisms within the TCP protocol itself.

It should be noted that if the HTTP keepalive feature (also known as HTTP persistent connection) is used on a webserver protected by cOS Stream, it might be possible to insert an attack in HTTP requests that arrive after a scan limit is reached. For this reason, it is recommended to disable HTTP keepalive on the webserver when a scan limit is used.
Stateless protocols like UDP and ICMP are more exposed if a scan limit is applied since they lack the integrity mechanisms found in a stateful protocol like TCP.
Note that when a scan limit is enabled, no log event message is generated by cOS Stream to indicate that a scan ended because the limit was reached. Doing this could generate an overwhelming number of log messages.