Home  Prev  InCenter 2.2.5 On-Premises Administration Guide  Next

Chapter 21: IDP

This section describes configuring the NetWall Intrusion Detection and Prevention (IDP) feature using InCenter.

[Note] Note: NetWall nodes are not supported

This feature is only supported by NetWall nodes. In NetShield nodes, the cOS Core IPS feature provides the equivalent functionality. This is described in Chapter 20, IPS.

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

IDP with NetWall

Intrusion Detection and Prevention (IDP) provides an important defense against intrusion attempts. IDP works by scanning traffic that flows through the NetWall node, searching for data patterns that indicate an intrusion is being attempted. Once detected, the administrator can configure what action should be taken, including dropping the connection.

The traffic that IDP scans is determined by defining one or more IDPRule objects in the cOS Core configuration. The data patterns or signatures that IDP searches for are contained in a single signature database which resides in cOS Core non-volatile storage.

IDP Signature Storage and Updates

It should be noted that the IDP signature database is not held centrally on the InCenter server. The entire database is replicated across individual NetWall nodes and is periodically updated automatically for each node over the Internet. Setting updating up requires the following cOS Core CLI command: 
admin@InCenter:/my-node1> set UpdateCenter IDPEnabled=Yes
			EnableProxy=Yes
			HTTPProxyIP=<tpm-ipaddress>
			UpdateInterval=Daily
			UpdateHour=<hour-value>
			UpdateMinute=<minute-value>
Where nodes do not have direct access to the Internet, they can use InCenter as a proxy server for signature updates and this is specified by the HTTPProxy parameter in the command above. In addition, InCenter must be configured to act as the proxy and doing this is described in Section 6.10, Internet Proxy Setup.

Note that the complete documentation for the IDP feature in NetWall nodes can be found in the IDP section of the separate cOS Core Administration Guide.

IDP Configuration Objects

The following configuration objects are used to configure IDP:

  • IDPRule

    IDPRule objects should be defined to determine what traffic should be scanned. They are independent of IP rule set entries and all traffic flows are checked against the IDPRule set.

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

    IDP is enabled when one or more IDPRule objects exist in a node configuration. There is no global setting to enable or disable it.

  • IDPRuleAction

    One or more IDPRuleAction objects are added as children to an IDPRule 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 IDP signatures to apply are specified by the Signatures property.

    The Signatures property can be assigned a comma separated list of signature numbers. However, if a value is not specified for the property, the IDPRuleAction object will never be triggered and its associated action never taken.

IDP Processing Flow

The steps in IDP processing flow are the following:

  1. A packet arrives at an interface and the system performs normal verification. If the packet is part of a new connection then it is checked against the IP rule set first before being passed to the IDP subsystem. If the packet is part of an existing connection it is passed straight to the IDP system.

  2. Provided that the IP rules allow the new connection, the connection is then checked against the IDPRule object list. If an IDPRule matches, IDP scanning will begin on the connection using that rule and its child actions.

  3. If the IDP scanning begins, the rule's child IDPRuleAction objects are processed in order. The signatures specified for each child action are applied to the traffic.

  4. If the traffic triggers a match in one of the IDPRuleAction signatures, the Action property is used to determine what to do. The action performed can be be one of the following:

    • Protect - This option drops the connection and logs the event.

      This is the default.

    • Audit - Allow the connection to stay open but log the event.

    • Ignore - Do nothing if an intrusion is detected and allow the connection to stay open.

    • Pipe - Constrain the bandwidth coming from the host using a traffic shaping pipe.

HTTP Normalization

An IDPRule 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 IDP 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 IDPRule 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 IDP scanning to more than an initial portion of the traffic in a connection. This might be done for performance reasons since applying IDP to all the traffic in a connection may consume too many system resources.

IDP provides the ability to impose a scan limit which means that IDP 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 IDPRule 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 IDP in either direction.

  • ScanLimitBytes

    If ScanLimit is enabled then this property specifies how many bytes are scanned by IDP 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 21.2, Setting Up IDP.

Notes About Setting a Scan Limit

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

  • The feature should be used with caution since an attacker might deliberately choose to insert an attack at some point after the limit given by ScanLimitBytes. However, typically it is more likely that an attack that can be detected by IDP will be present in the initial portion.

  • 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 protected webserver, 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 the HTTP keepalive option 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 to indicate that a scan ended because the limit was reached. Doing so could generate an overwhelming number of log messages.

Home  Prev   Next