Foundation and Supplemental Topics


Cisco IPS Signatures

To identify malicious activity, Cisco IPS monitors network traffic and generates alerts when traffic matching specific signatures is detected. A signature is basically a description of network traffic that attackers use while conducting network-based attacks. To support a wide range of signatures and enable users to develop their own custom signatures, Cisco IPS uses a set of signature engines that each examine network traffic for intrusive activity with similar characteristics. An example of these signature engines are the TCP-based string engines, which handle signatures that search for specific textual strings in TCP traffic. Signature engines parse a list of signature definitions and then search for traffic matching those signatures in the network traffic stream.

Since signature engines and signatures are the foundation of Cisco IPS, Cisco security engineers are continually researching and developing these components. The signature engines are designed to perform a wide range of functions, such as pattern matching, stateful pattern matching, protocol decoding, deep-packet inspection, and other heuristic methods. Furthermore, new signature engines are being added to efficiently support a larger range of signatures.

Cisco IPS Signature Engines

Cisco IPS monitors network traffic with a suite of signature engines. By spreading signature processing across distinct categories where all of the signatures for a category share similar characteristics, you can analyze network traffic more efficiently and add your own custom signatures more easily. The signature engines fall into the categories shown in Table 6-2.

Table 6-2. Signature Engine Categories

Engine Category

Usage

Application Inspection and Control (AIC)

Used to provide deep-packet inspection from Layer 4 through Layer 7

Atomic

Used for single-packet conditions

Flood

Used to detect denial-of-service (DoS) attempts

Meta

Used to create meta signatures based on multiple individual signatures

Normalizer

Used to normalize fragmented and TCP streams when in inline mode (cannot create custom signatures)

Service

Used when services at OSI Layers 5, 6, and 7 require protocol analysis

State

Used when stateful inspection is required

String

Used for string pattern matching

Sweep

Used to detect network reconnaissance scans

Miscellaneous

Various assorted signature engines (such as Traffic ICMP and Trojan horse signature engines)


Understanding the capabilities of each of the signature engines is crucial to tuning built-in signatures and developing custom signatures that are unique to your network environment. This section will explain the various signature engines and highlight many of the parameters that you will need to use to both tune built-in signatures and develop custom signatures. Before examining the different engines, you should understand the parameters that you will use to define a signature.

Signature Parameters

To identify the traffic that a specific signature is looking for, you should define each signature by specifying a set of parameters. Some parameters are unique to a signature engine whereas other parameters are common to all signatures. All of the parameters are stored in configuration files for each signature engine to parse. Each parameter falls into one of the following groups:

  • Basic signature fields

  • Signature description fields

  • Engine-specific fields

  • Event counter fields

  • Alert frequency fields

  • Status fields

Along with the parameters that are common to every signature, each signature also has engine-specific parameters. These parameters enable the efficient creation of signatures without an unwanted number of extra and unnecessary parameters being tagged onto every signature that you create. Some of the major engine-specific parameters will be explained in the explanation of the signature engines themselves.

Application Inspection and Control Signature Engines

HTTP and FTP are protocols that commonly traverse firewalls on many networks. Because of this, many applications (and attackers) have started using these protocols to tunnel traffic (other than HTTP and FTP) through firewalls in an attempt to circumvent the security policies implemented on various networks. Cisco IPS version 5.0 enables you to conduct a more thorough analysis of HTTP and FTP through application policy enforcement. Currently, application policy enforcement is available through the signature engines listed in Table 6-3.

Table 6-3. AIC Signature Engines

Engine

Description

AIC FTP

Application layer-inspection signatures for FTP traffic

AIC HTTP

Application layer-inspection signatures for HTTP traffic


AIC FTP Signature Engine Parameters

Using the Application Inspection and Control (AIC) FTP signature engine involves configuring the parameters shown in Table 6-4.

Table 6-4. AIC FTP Signature Engine Parameters

Parameter Name

Values

Description

Signature Type

FTP Commands

Identifies the type of FTP commands that the signature will detect

 

Unrecognized FTP Command

 

FTP Command

Help, Noop, Stat, Syst, User, abor, acct, allo, appe, cdup, cwd, dele, list, mkd, mode, nlst, pass, pasv, port, pwd, quit, rein, rest, retr, rmd, rnfr, rnto, site, smnt, stor, stou, stru, type

The FTP command that the signature will check for


Basically, AIC FTP signatures look for either specific or unrecognized FTP commands. You specify the signature type and then the command that the signature triggers on (if the signature type is FTP Commands).

AIC HTTP Signature Engine Parameters

Using the AIC HTTP signature engine involves configuring the parameters shown in Table 6-5.

Table 6-5. AIC HTTP Signature Engine Parameters

Parameter Name

Values

Description

Signature Type

Content Types

Identifies the type of HTTP traffic that the signature will detect or analyze

 

Define Web Traffic Policy

 
 

Max Outstanding Requests Overrun

 
 

Msg Body Pattern

 
 

Request Methods

 
 

Transfer Encodings

 


When configuring an AIC HTTP signature, you first specify the signature type shown in Table 6-5. Then you configure the parameters unique to that type of signature. These unique parameters will be explained in detail in the following sections.

Content Types Parameters

When defining AIC HTTP signatures by using the Content Types signature type, you specify the content types that the signature will search for in the HTTP messages. The parameters for this AIC HTTP signature type are shown in Table 6-6.

Table 6-6. Content Types Parameters

Parameter Name

Values

Description

Content Type

string

A specified HTTP content type

Content Types

Define Content Type

Type of content type processing the signature will use

 

Define Recognized Content Types

 

Content Type Details

Content Verification

Identifies the extra information to be specified for the content type

 

Length

 
 

No Additional Details

 

Content Type Verify

Yes

Indicates whether the signature verifies the content type

 

No

 

Enforce Accept Content Types

Yes

Identifies whether the signature verifies that the content type specified matches one of the types specified in the Accept field

 

No

 

Entry Key

string

Name of a specific recognized content type entry

Length

0 65535

Length of the content type

Name

string

Description name of the content type entry

Recognized Content Types

Entry_Keys

List of recognized content types composed of one or more entry keys

Regex String

string

(Optional) Specifies the regular expression that the signature will search for

Regex End Offset

0 65535

(Optional) Indicates the maximum number of bytes to be inspected during the search for the string match

Magic Number List

Magic_Number_Keys

A list of regex (regular expression) entries to search for


Define Web Traffic Policy Parameters

When defining a signature by using the Define Web Traffic Policy signature type, you are creating a signature that checks if the traffic is valid based on the HTTP RFC (RFC 2616). The only parameter for the signature type is Alarm on Non-HTTP Traffic. This parameter can be either Yes (default) or No. If you specify Yes, the signature will trigger whenever non-HTTP traffic is detected going to the specified ports.

Msg Body Pattern Parameters

When defining AIC HTTP signatures by using the Msg Body signature type, you specify a list of regex strings to search for in the HTTP messages. The parameters for this AIC HTTP signature type are shown in Table 6-7.

Table 6-7. Msg Body Pattern Parameters

Parameter Name

Values

Description

Entry Key

string

Name of a specific regex entry

Regex Pattern

string

(Optional) Specifies the regular expression that the signature will search for

Regex Min Match Length

0 65535

(Optional) Requires the string matched to be at least the specified minimum number of bytes

Regex End Offset

0 65535

(Optional) Indicates the maximum number of bytes to be inspected when looking for the string match

Regex List

Entry_Keys

A list of regex entries to search for

Regex List in Order

Yes

If Yes, the signature must search for the regex entries in the order in which they are listed in the regex list

 

No

 


Basically, you configure a list of regex entries to search for in the body of the HTTP message. For each regex you can specify the minimum match length and number of bytes in the stream or packet to search for the pattern. Finally, you can also specify whether the regex strings need to be found in the order specified by using the Regex List in Order parameter.

Request Methods Parameters

When defining AIC HTTP signatures by using the Request Methods signature type, you specify a request method or a list of request methods to search for in the HTTP messages. The parameters for an AIC HTTP Request Method signature are shown in Table 6-8.

Table 6-8. Request Methods Parameters

Parameter Name

Values

Description

Request Method

string

A specified HTTP request method

Request Methods

Define Request Method

Type of request method processing the signature will use

 

Define Recognized Request Methods

 

Define Request Method

string

Identifies a specified request method for the signature to use

Entry Key

string

Name of a specific recognized request method entry

Recognized Request Methods

Entry_Keys

List of recognized content types composed of one or more entry keys


Transfer Encodings Parameters

When defining AIC HTTP signatures by using the Transfer Encodings signature type, you specify a transfer encoding or a list of transfer encodings to search for in the HTTP messages. The parameters for this AIC HTTP signature type are shown in Table 6-9.

Table 6-9. Transfer Encodings Parameters

Parameter Name

Values

Description

Define Transfer Encoding

string

A specified HTTP transfer encoding method

Transfer Encodings

Chunked Transfer Encoding Error

Type of transfer encoding processing the signature will use

 

Define Transfer Encoding

 
 

Recognized Transfer Encodings

 

Content Type Details

Content Verification

Identifies the extra information to be specified for the content type

 

Length

 
 

No Additional Details

 

Transfer Encoding

string

The transfer encoding configured for a specific entry key

Entry Key

string

Name of a specific recognized transfer encoding entry

Recognized Transfer Encodings

Entry_Keys

List of recognized content types composed of one or more entry keys


Atomic Signature Engines

The two signature engines shown in Table 6-10 handle all of the atomic signatures. Each of these engines is designed to efficiently support signatures that trigger based on information in a single packet. Whenever a packet that matches a configured signature is detected, the appropriate signature engine triggers an alarm. The atomic engines are constructed to efficiently handle searching different types of traffic streams (such as ICMP, TCP, and UDP).

Table 6-10. Atomic Signature Engines

Engine

Description

Atomic ARP

ARP simple and cross-packet signatures

Atomic IP

Simple IP alarms based on various IP parameters (including TCP, UDP, and ICMP simple signatures)


Since these atomic signature engines examine single packets, they do not need to maintain state. Therefore, the atomic engines do not store any persistent data across multiple data packets.

Atomic ARP Engine Parameters

Atomic ARP provides the ability to support basic Layer 2 Address Resolution Protocol (ARP) signatures (see RFC 826, "An Ethernet Address Resolution Protocol"). Numerous tools enable an attacker to attack your network at the link layer, including dsniff (http://www.monkey.org/~dugsong/dsniff) and ettercap (http://ettercap.sourceforge.net). The Atomic ARP signature engine enables Cisco IPS to detect the use of these tools on your network. To tune existing Atomic ARP signatures or create custom signatures, you need to understand the parameters shown in Table 6-11.

Table 6-11. Atomic ARP Engine Parameters

Parameter Name

Values

Description

ARP Operation

0 255

The ARP operation code that this signature will match on

Mac Flip Times

0 65535

Fires an alert when the Media Access Control (MAC) address for an IP address changes more than this number of times

Request Inbalance

0 65535

Fires an alert when there are this many more ARP requests than replies for an IP address

Type of ARP Sig

Dst Broadcast

Same Src and Dst

Src Broadcast

Src Multicast

Fires an alert when the traffic matches the specified address parameters


The Specify Arp Operation field enables you to create alarms based on a specific ARP operation code. The two normal ARP operations codes are as follows:

  • ARP Request (operation code 1)

  • ARP Reply (operation code 2)

The Specify Request Inbalance field causes a signature to trigger if more ARP requests than replies are detected for a specific IP address. Normally, the requests and replies are matched up one to one so that an imbalance can indicate malicious activity.

A normal ARP request is sent to the broadcast Ethernet address so that every system on a segment can see the request and potentially respond. A broadcast Ethernet address in any other situation (such as in the Ethernet source address) is an indication of potential intrusive activity and should be investigated. The Specify Type of ARP Sig field enables you to create ARP signatures that look for traffic based on one of the following criteria:

  • Destination is broadcast

  • Source and destination are the same

  • Source is broadcast

  • Source is multicast

Atomic IP Engine Parameters

The Atomic IP engine enables you to create specialized atomic signatures based on any IP protocol. Most of your Atomic IP signatures will fall into one of the following protocol categories:

  • ICMP (Internet Control Message Protocol)

  • TCP

  • UDP (User Datagram Protocol)

The Atomic IP signature engine comprises IP-specific fields and the specific fields for the IP protocol that the signature is based on. Table 6-12 identifies the basic IP fields for the Atomic IP signature engine.

Table 6-12. IP Fields for Atomic IP Signature Engine

Parameter Name

Values

Description

Fragment Status

Any

Fragmented

Not Fragmented

Matches all packets

Matches only fragmented packets

Matches only nonfragmented packets

Layer 4 Protocol

ICMP Protocol

Other IP Protocols

TCP Protocol

UDP Protocol

The Layer 4 protocol that the signature will examine

IP Payload Length

0 65535

The length of the payload to search for

IP Header Length

0 65535

The value for the IP header length to look for

IP Type of Service

0 255

The value for the IP Header type of service (ToS) to match

IP Time-to-Live

0 255

Specifies the value for the Time-to-Live (TTL) field to look for

IP Version

0 16

Specifies the IP version to search for

IP Identifier

0 65535

Specifies the IP identifier to search for

IP Total Length

0 65535

Triggers an alarm if the IP data length exceeds this value

IP Option Inspection Options

IP Option

IP Option Abnormal Option

Specifies whether to search for a specific IP option or just abnormal options

IP Option

0-65535

The IP option code to match

IP Option Abnormal Option

Yes

No

Specifies whether the signature checks to see if the option list is malformed

IP Address Options

Address with Localhost

IP addresses

RFC 1918 Addresses

Src IP Equal Dst IP

Matches if address is 127.0.0.1

Matches on regular IP addresses

Matches on reserved IP address specified by RFC 1918

Both the source IP address and the destination IP address are the same


IP options provide optional information for the IP datagram. The major options are as follows:

  • Security and handling restrictions (IP option 2)

  • Record route (IP option 7)

  • Timestamp (IP option 4)

  • Loose source routing (IP option 3)

  • Strict source routing (IP option 9)

You can specify an IP option to search for by using the IP Option parameter. The only other option is the IP Option Abnormal Option parameter. By setting this parameter to True, you cause the signature to trigger when a packet with an invalid option is detected.

The IP Address Options field enables you to cause the signature to match based on one of the following IP address types:

  • Localhost addresses (127.0.0.1)

  • RFC 1918 reserved addresses

  • Packets with source equal to destination

  • Regular IP addresses

Atomic IP ICMP Parameters

Creating ICMP atomic signatures involves configuring the parameters identified in Table 6-13.

Table 6-13. ICMP Fields for Atomic IP Signature Engine

Parameter Name

Values

Description

ICMP Code

0 255

The value to match for the Code field in the ICMP header

ICMP Identifier

0 65535

The value to match for the Identifier field in the ICMP header

ICMP Sequence

0 65535

The value to match for Sequence Number field in the ICMP header

ICMP Type

0 255

The value to match for Type field in the ICMP header

ICMP Total Length

0 65535

The minimum length (of the ICMP header and payload) to match


The ICMP parameters enable you to efficiently detect specific ICMP traffic (see RFC 792) on your network. You can specify single values for the following ICMP header fields:

  • Code

  • Identifier

  • Sequence Number

  • Type

  • Total Length

Atomic IP TCP Parameters

Creating TCP atomic signatures involves configuring the parameters identified in Table 6-14. These signatures identify traffic based on various TCP fields, such as source and destination ports, or the contents of the packet's data.

Table 6-14. TCP Fields for Atomic IP Signature Engine

Parameter Name

Values

Description

Destination Port Range

port-list

The destination port range to match (each port can be 0 65535, and the two ports of the range are separated by a hyphen)

Source Port Range

port-list

The source port range to match (each port can be 0 65535, and the two ports of the range are separated by a dash)

TCP Flags

FIN

SYN

RST

PSH

ACK

URG

ZERO

The TCP Flags (out of the flags included in the mask) that need to be set for the signature to trigger

TCP Header Length

0 15

(Optional) Indicates the required TCP header length

TCP Mask

FIN

SYN

RST

PSH

ACK

URG

ZERO

The mask used when the TCP Flags

This field indicates the TCP flags that you want to include in your checking

TCP Payload Length

0 65535

(Optional) Indicates the length of payload required

TCP Reserved

0 63

(Optional) Indicates the required value for the TCP reserved flags

TCP Urgent Pointer

0 65535

(Optional) Indicates the required urgent field size

TCP Window Size

0 65535

(Optional) Indicates the required window size


When specifying atomic TCP signatures, you must specify the TCP Mask and TCP Flags parameters. The TCP Mask parameter essentially identifies the TCP flags that you are interested in, whereas the TCP Flags parameter indicates which of the TCP flags need to be set. Any TCP flags that you fail to include in the mask cannot impact whether the signature triggers. For instance, assume that you set the TCP Mask parameter to include FIN and ACK, and the TCP Flags parameter to include only FIN. The signature will trigger only based on the values of the FIN and ACK flags in the packets (all of the other TCP flags in the packet will be ignored). Packets will trigger the signature as follows:

  • If the ACK and FIN flags are set, the signature will not trigger.

  • If the FIN flag is set and the ACK flag is not set, the signature will trigger (regardless of the settings for the other TCP flags).

  • If the FIN flag is not set, the signature will not trigger.

Atomic IP UDP Parameters

Creating UDP atomic signatures involves configuring the parameters identified in Table 6-15. These parameters enable you to define UDP signatures. These are Layer 4, or transport layer, signatures.

Table 6-15. UDP Fields for Atomic IP Signature Engine

Parameter Name

Values

Description

Destination Port Range

port-list

The destination port range to match (each port can be 0 65535, and the two ports of the range are separated by a dash)

UDP Valid Length

0 65535

(Optional) Specifies the required UDP packet length

UDP Length Mismatch

Yes

No

(Optional) Causes a match if IP data length is less than the UDP header length

Source Port Range

port-list

The source port range to match (each port can be 0 65535, and the two ports of the range are separated by a dash)


This basic engine provides the capability to examine ports and packet lengths. You can search for specific ports by using the Destination Port Range and Source Port Range parameters.

A UDP packet contains two length fields: a length in the IP header that indicates the entire length of the IP packet, and a length in the UDP header that indicates the size of the UDP payload. Using the UDP Length Mismatch parameter, you can create signatures that trigger on packets in which the length in the IP header indicates that the length in the UDP header should be greater than it is.

Atomic IP Payload Parameters

When creating atomic signatures, you can also cause the signature to examine the payload of the packet. The Atomic IP payload parameters are shared by the various types of atomic signatures (including ICMP, TCP, and UDP). Configuring payload inspection involves using the parameters identified in Table 6-16.

Table 6-16. Payload Inspection Fields for Atomic Signatures

Parameter Name

Values

Description

Exact Match Offset

0 65535

(Optional) The exact offset at which the string must occur for a match to be valid

Min Match Length

0 65535

(Optional) Requires the string matched to be at least the specified minimum number of bytes

Min Match Offset

1 65535

(Optional) Requires the matched string to occur within the specified number of bytes from the beginning of the packet

Max Match Offset

1 65535

(Optional) Indicates the maximum number of bytes to be inspected during the search for the string match

Regex String

string

(Optional) A regular expression to search for in a TCP packet


When inspecting the payload for an atomic signature, you specify a regex string and then refine valid matches by specifying offset and length restrictions. The Min Match Length parameter causes the signature to match only strings that are at least the size specified.

Using the Min Match Offset parameter enables you to force the string to occur within a specified number of bytes from the beginning of the packet. Conversely, Max Match Offset specifies the maximum number of bytes that will be inspected during the search for the string. Finally, you can use the Exact Match Offset parameter to specify the exact location at which the string must occur to be considered a valid match.

Flood Signature Engines

The flood signature engines are shown in Table 6-17.

Table 6-17. Flood Signature Engines

Engine

Description

Flood Host

Flood signatures based on ICMP or UDP packets

Flood Net

Flood signatures that use Gap, Peaks, and Rate to trigger a flood of TCP, UDP, and ICMP traffic


The Flood Host signature engine analyzes traffic directed at one specific destination host from many source hosts. It attaches a packets per second (PPS) rate counter to a specific destination address, with the sampling being done on a per-second basis.

The Flood Net signature engine analyzes the aggregate traffic on the entire network segment. The signatures using this engine examine traffic for a specific protocol and generate a PPS counter for a virtual sensor instead of a specific address. Sampling is also done on a per-second basis.

Flood Host Engine Parameters

The Flood Host signature engine analyzes traffic directed at one specific destination host from many source hosts. The signatures using this engine can check for both UDP and ICMP traffic floods. The parameters common to all Flood Host signatures are shown in Table 6-18. For all of the Flood Host signatures, you need to specify the PPS of traffic that should trigger an alert. This maximum rate is specified using the Rate field.

Table 6-18. Common Fields for Flood Host Signatures

Parameter Name

Values

Description

Rate

0 65535

Indicates the PPS for the desired traffic that should generate an alert

Protocol

UDP

ICMP

The protocol of the traffic the signature will use


Flood Host ICMP Parameters

Using the Flood Host signature engine, you can create signatures that detect ICMP traffic coming from many source hosts to a single destination host. The ICMP-specific parameter is shown in Table 6-19.

Table 6-19. Flood Host ICMP Engine Parameter

Parameter Name

Values

Description

ICMP Type

0 255

(Optional) The value to match for the ICMP header TYPE


These signatures identify traffic floods based on either all ICMP traffic (if you do not specify the ICMP Type parameter) or specific ICMP traffic floods based on a specific ICMP type, such as the following common ICMP type codes:

  • Echo reply (0)

  • Destination unreachable (3)

  • Source quench (4)

  • Redirect (5)

  • Echo request (8)

  • Router advertisement (9)

  • Router solicitation (10)

  • Time exceeded (11)

  • Parameter problem (12)

  • Timestamp request (13)

  • Timestamp reply (14)

  • Information request (15)

  • Information reply (16)

  • Address mask request (17)

  • Address mask reply (18)

Flood Host UDP Parameters

The Flood Host signature engine supports signatures that detect floods of UDP traffic to a specific host on your network. The UDP-specific parameters are shown in Table 6-20.

Table 6-20. Flood Host UDP Engine Parameters

Parameter Name

Values

Description

Destination Ports

port-list

Indicates the destination ports to be included in the flood calculation (separate individual ports with a comma and ranges with a dash)

Source Ports

port-list

Indicates the source ports to be included in the flood calculation (separate individual ports with a comma and ranges with a dash)


Flood Net Engine Parameters

The Flood Net signature engine is designed to support flood signatures that are triggered by a flood of traffic against your entire network (as opposed to a single host). The engine-specific parameters are shown in Table 6-21.

Table 6-21. Flood Net Engine Parameters

Parameter Name

Values

Description

Gap

0 65535

Defines an interval (in seconds) at which the peak count is reset to 0 if the matched traffic remains below the defined rate

ICMP Type

0 255

(Optional) The value to match for the ICMP header TYPE; this parameter is valid only if the Protocol parameter is set to ICMP

Peaks

0 65535

Defines the maximum period of time (above the specified rate) necessary to trigger the signature

Protocol

ICMP

TCP

UDP

Protocol for the traffic that the flood signature is looking for

Rate

0 65535

The maximum PPS required to trigger a flood


When defining signatures for this engine, you need to first determine which type of traffic you are going to monitor. You specify the traffic type by using the Protocol parameter. If you set this value to ICMP, you can also specify a type of ICMP traffic by using the ICMP Type parameter.

Next you need to define the following three parameters that specify the amount of traffic that constitutes a flood:

  • Gap

  • Peaks

  • Rate

With the Rate parameter, you specify the maximum time interval during which the monitored traffic is allowed to exceed the specified rate. The Rate parameter works in conjunction with the Peaks parameter. The Peaks parameter defines the maximum period of time in seconds (during a given summary interval) that the monitored traffic must remain above the specified rate to trigger the signature. The final parameter, Gap, indicates how long the monitored traffic must remain below the specified rate before the peak count is reset to 0 (during a summary interval).

When you are setting the parameters for a Flood Net signature, the hardest task is determining the appropriate values for the Rate parameter since it varies from one network to the next. To more accurately calculate the rate, you can run the signature in diagnostic mode or feedback mode.

Note

Determining the rate at which certain traffic normally occurs on the network can be a challenging task since the rate varies from network to network. By specifying a rate of 0, you can place a Flood Net signature in diagnostic mode. In this mode, the signature will trigger informational alarms that indicate the rate of traffic (that matches the signature) that is observed during each summary interval. This information will be provided in the Alarm Details field (as a textual string such as MaxPPS=xyz). By running the signature in diagnostic mode over a period of time, you can determine the normal rate of the traffic for each Flood Net signature. Then you can define a rate that is above the measured normal rate so that the flood signatures will indicate abnormal network activity that needs to be investigated.


Meta Signature Engine

The Meta Signature engine enables you to create signatures that represent a combination of individual signatures. The parameters you use when configuring meta signatures are shown in Table 6-22.

Table 6-22. Meta Signature Engine Parameters

Parameter Name

Values

Description

Component Count

1 256

Number of times a specific component signature must trigger for the component entry to generate a match

Component List

Component_Signatures

A list of component signatures that comprise the meta signatures

Component List Order

Yes

No

Determines whether the individual component signatures must be seen in a specific order

Component Sig ID

1000 50000

ID for a specific component signature

Component SubSig ID

0 128

Subsignature ID of the component signature (default is 0)

Entry Key

string

Name of a specific component signature entry

Meta Key

Attacker address

Attacker and victim addresses

Attacker and victim addresses and ports

Victim address

Identifies which addresses are used by the meta signatures when determining matching traffic

Meta Reset Interval

0 3600

Defines an interval (in seconds) at which the signature resets the signatures already seen (default is 60 seconds)

Unique Victims

1 256

The number of unique victims needed for the meta signatures to fire (default is 1)


Normalizer Signature Engine

The Normalizer signature engine supports signatures that analyze TCP connection states. Maintaining state on a TCP connection is important to identifying various attacks, such as the following:

  • TTL manipulation

  • URG pointer manipulation

  • Out of order RST or FIN

  • Out of order packets

  • TCP window size manipulation

The Normalizer engine performs TCP stream reassembly for sensors running in promiscuous mode as well as sensors running in inline mode. With inline mode, however, the Normalizer signatures can actually prevent the various TCP state-based attacks. For instance, to nullify the TTL manipulation attack, the Normalizer engine can force all of the outgoing TCP packets to use the smallest TTL observed during the TCP connection.

Unlike other engines, the Normalizer signature engine does not provide functionality to allow you to create custom signatures. You can, however, configure the existing signatures to fit your network requirements. Most of the signatures enable you to configure only a specific TCP parameter. For instance, signature 1202, "Datagram too long," allows you to configure only the Max Datagram Size parameter.

When your sensor is in inline mode, the Normalizer signatures manipulate TCP sessions in various ways (such as dropping or modifying packets). Many of these signatures, however, do not have the "Produce Alert" signature action. Therefore, when they trigger, they perform their configured actions but provide no indication on your monitoring application. For instance, by default, signature 1330 (subsig 18), "TCP Drop Segment out of window," only drops the packet (without generating an alert). Another example is signature 1305, "TCP URG flag set." By default, signature 1305 modifies the packet (removing the URG bit) before forwarding the packet (without generating an alert). Usually these default settings are adequate and minimize alert traffic to your monitoring console. However, when debugging network operational problems, you need to understand that your sensor may be modifying or dropping TCP traffic without generating alerts.

Service Signature Engines

The service signature engines analyze traffic above the basic UDP and TCP transport layers. Each of these signature engines has detailed knowledge of the service it examines. This includes decoding application-layer protocols such as remote-procedure call (RPC), Simple Network Management Protocol (SNMP), and Network Time Protocol (NTP). By decoding the traffic payloads similar to the actual applications, the service signatures engines can accurately detect attack traffic while minimizing false positives. The various service signature engines are shown in Table 6-23.

Table 6-23. Service Signature Engines

Engine

Description

Service DNS

Examines TCP and UDP DNS packets

Service FTP

Examines FTP port command traffic

Service Generic

Emergency response engine to support rapid signature response

Service H225

Examines voice-over-IP (VoIP) traffic based on the H.225 protocol

Service HTTP

Examines HTTP traffic by using string-based pattern matching

Service Ident

Examines Identification (IDENT) protocol (see RFC 1413) traffic

Service MSRPC

Examines signatures based on the Microsoft RPC service

Service MSSQL

Examines traffic used by the Microsoft SQL server

Service NTP

Examines NTP traffic

Service RPC

Examines RPC traffic

Service SMB

Examines Server Message Block (SMB) traffic

Service SNMP

Examines SNMP traffic

Service SSH

Examines Secure Shell Host (SSH) traffic


Service DNS Engine Parameters

The Service DNS signature engine performs advanced decoding of DNS traffic. This decoding enables detecting various anti-evasion techniques such as following multiple jumps in the DNS payload. The major engine-specific signature parameters for the Service DNS signature engine are shown in Table 6-24.

Table 6-24. Service DNS Engine Parameters

Parameter Name

Values

Description

Protocol

TCP

UDP

Specifies the protocol to use for the signature

Query Chaos String

string

Defines the DNS query class chaos string to match

Query Class

0 65535

Defines the DNS query class 2-byte value to match

Query Invalid Domain Name

Yes

No

If Yes, matches when the DNS query length is greater than 255

Query Jump Count Exceeded

Yes

No

DNS compression counter

Query Opcode

0 255

Defines the DNS query opcode value

Query Record Data Invalid

Yes

No

If Yes, matches when DNS record data is incomplete

Query Record Data Length

0 65535

Determines the DNS-response data length

Query Src Port 53

Yes

No

If Yes, matches if the DNS query comes from port 53; if No, matches if the DNS query does not come from port 53

Query Stream Len

0 65535

Matches when the DNS packet length is greater than this value

Query Type

0 65535

Defines the DNS query type to match

Query Value

Yes

No

If Yes, matches when the DNS request is a query; if No, matches when the DNS request is a response


The engine-specific parameters for the Service DNS engine enable you to specify values for the following DNS fields:

  • Chaos String

  • Class

  • Opcode

  • Type

You can apply your signatures to either DNS response packets or DNS request packets by using the Query Value parameter. If this parameter is set to Yes, the signature will trigger when the traffic is a DNS request. Similarly, you can determine whether a DNS query originates from port 53 by using the Query Src Port 53 parameter.

You can check the size of the domain name by using the Query Invalid Domain Name parameter. If this parameter is set to Yes, the signature will trigger if the domain name is longer than 255 characters. Finally, you can also create DNS signatures that trigger if the DNS packet length is greater than a certain value. You define this value by using the Query Stream Len parameter.

Service FTP Engine Parameters

The String TCP engine is useful for creating many FTP string-based FTP signatures. Certain signatures, however, are not appropriate for the string signature engines. The Service FTP signature fills this gap by providing an engine that supports signatures specifically centered on the FTP port command. This engine decodes FTP port commands and traps invalid port commands or attacks based on the port command. The control traffic is examined only on port 21 traffic since port 20 is used by FTP to transport only data traffic. The major parameters for the Service FTP signature engine are shown in Table 6-25.

Table 6-25. Service FTP Engine Parameters

Parameter Name

Values

Description

FTP Inspection Type

Invalid Address in PORT Command

Invalid Port in PORT Command

PASV Port Spoof

Indicates the type of invalid FTP traffic to search for

Direction

From Service

Determines whether the signature matches on traffic to or from the FTP service port

 

To Service

 

Service Ports

port-list

A comma-separated list of ports or port ranges on which to look for the FTP traffic

Swap Attacker Victim

Yes

No

If Yes, the signature switches source and destination Ip addresses in the alarm information


The Service Ports parameter enables you to define which ports the signature engine will analyze. By default this parameter is set to port 21, but you can alter this value if you happen to use other ports for the FTP protocol. In conjunction with this parameter, you can use the Direction parameter to indicate whether the signature will trigger on traffic to the service port or from the service port.

You can specify the following three FTP inspection types that relate to the validity of the actual FTP port commands analyzed by the engine:

  • Invalid Address in PORT Command

  • Invalid Port in PORT Command

  • PASV Port Spoof

Service Generic Engine Parameters

The Service Generic engine is an unusual signature engine. You will not use this engine to create regular custom signatures. Instead, this signature engine is designed as an emergency response engine that supports rapid signature response. The major parameters are shown in Table 6-26.

Table 6-26. Service Generic Engine Parameters

Parameter Name

Values

Description

Dst Port

0 65535

Destination port of interest for this signature

Intermediate Instructions

string

Assembly or machine code in string form (this field is for expert use only)

IP Protocol

0 255

The IP protocol that applies to this signature

Payload Source

ICMPData

L2Header

L3Header

L4Header

TCPData

UDPData

Identifies where to begin payload search

Src Port

0 65535

Source port of interest for this signature


The signatures supported by this engine use assembly language and machine code to define how the signatures process different parts of the analyzed packets. These signatures can search various payload sources to locate intrusive activity.

Caution

Creating signatures by using the Service Generic signature engine requires an expert level of understanding to create the appropriate assembly language instructions and is not intended for use by normal users.


Service H225 Engine Parameters

To improve signature support for VoIP, Cisco IPS version 5.0 includes an H225 signature engine. Table 6-27 shows the parameters for the H225 signature engine.

Table 6-27. Service H225 Engine Parameters

Parameter Name

Values

Description

Field Name

string

(Optional) Field name to inspect

Invalid Packet Index

0 255

(Optional) Specifies the index of a specific check in a list of built-in checks that validate H225 messages

Message Type

ASN.1-PERS

Q.931

SETUP

TPKT

H225 message type

Min Match Length

0 2147483647

(Optional) Minimum number of bytes the regex string must match

Policy Type

Field Validation

Length Check

Presence

Regex

Value

The policy that the signature will apply to the specified message types

Regex String

string

(Optional) The regular expression that the signature searches for in a single packet

Value Range

0 65535

(Optional) Range of values


Using the H225 signature engine, you can easily create signatures that inspect H225 traffic by matching on one or more of the following message types:

  • ASN.1-PERS

  • Q.931

  • SETUP

  • TPKT

When processing these message types, you can configure the policy applied to these messages by using one of the following policy types:

  • Field Validation

  • Length Check

  • Presence

  • Regex

  • Value

For instance, if you have a message type of Q.931, a policy type of Length Check, a Field Name of UserUser, and a Value Range of 10 20, then Q.931 packets where the specified field has a size outside this range will trigger the signature.

Service HTTP Engine Parameters

The Service HTTP signature engine provides regular expression-based pattern inspection specifically designed to analyze HTTP. The major parameters are shown in Table 6-28.

Table 6-28. Service HTTP Engine Parameters

Parameter Name

Values

Description

Uri Regex

string

(Optional) The regular expression used to search for a pattern in the uniform resource identifier (URI) section of the HTTP request; the URI is after the valid HTTP method and before the first <CR><LF> or argument delimiter (? or &)

Arg Name Regex

string

(Optional) The regular expression used to search for a pattern in the Arguments section

Arg Value Regex

string

(Optional) The regular expression used to search for a pattern in the Arguments section after the Arg Name regex is matched

Header Regex

string

(Optional) The regular expression used to search for a pattern in the Header section

Request Regex

string

(Optional) The regular expression used to search for a pattern anywhere in the HTTP request

Max Uri Field Length

0 65535

(Optional) Specifies the maximum URI length considered normal

Max Arg Field Length

0 65535

(Optional) Specifies the maximum Argument field length considered normal

Max Header Field Length

0 65535

(Optional) Specifies the maximum Header field length considered normal

Max Request Field Length

0 65535

(Optional) Specifies the maximum HTTP request length considered normal

Deobfuscate

Yes

No

Determines whether to perform anti-evasion HTTP deobfuscation before examining the HTTP request (default is Yes)

Service Ports

port-list

A comma-separated list of ports or port ranges to search for the HTTP traffic

Min Request Match Length

0 65535

(Optional) The minimum number of bytes that the Uri regex must match


Note

The <CR><LF> refers to the nonprintable carriage return and line feed characters that are used to delimit command input. Whenever you press Enter on your keyboard (while editing a document, for instance) the system inserts a carriage return <CR> character and a line feed <LF> character into the document (even though they are not directly printable). The carriage return character is 13, and the line feed character is 10.


The pattern-matching functionality provided by the Service HTTP signature engine is enabled through the implementation of various regular expression (regex) strings. These regex strings search the following portions of a regular HTTP message:

  • Entire HTTP request

  • HTTP header

  • URI

  • Arguments and entity body

Figure 6-1 shows a sample HTTP request that highlights the various HTTP message components.

Figure 6-1. Sample HTTP Request


The URI identifies the file or resource that the HTTP request is attempting to access. The Uri Regex parameter specifies a regular expression that searches this field. The URI begins after the HTTP method (such as GET or POST) and goes up to the first <CR><LF> or argument delimiter (? or &) that is detected.

When you set the Header regex, the HTTP header is searched for the specified pattern. The header section begins after the first <CR><LF> and ends when a double <CR><LF> combination is detected.

Searching the arguments section involves the following two parameters:

  • Arg Name regex

  • Arg Value regex

The Arg Name regex is a regular expression that identifies the name of the argument that you are looking for in the HTTP request. If the Arg Name regex is found, the signature uses the Arg Value regex to search for a specific value after the argument that was located. These two regular expressions search for arguments in the following two places (see Figure 6-1):

  • After the URI, beginning with the argument delimiter (? or &) and ending at the first <CR><LF>

  • The entity body section of the HTTP request

You can also specify the Request Regex parameter. This regular expression identifies a pattern that the signature will search for anywhere in the HTTP request. Sometimes, you may want the signature to trigger if the pattern matched by the Request Regex is larger than a specified size. A large HTTP request can indicate potential buffer overflow attempts. Using the Min Request Match Length parameter, you cause the signature to trigger only if the Request Regex is found and the size of the pattern matched is larger than the value specified by the Min Request Match Length parameter.

Note

The Min Request Match Length parameter is applicable only when the Request Regex contains an iterator (* or +) that enables the pattern to match on variable length patterns.


Besides pattern matching, you can also specify the following parameters that indicate maximum field values:

  • Max Uri Field Length

  • Max Arg Field Length

  • Max Header Field Length

  • Max Request Field Length

If the length of any of these fields exceeds the specified value, the signature will trigger. These parameters enable you to generate alarms if any of these fields are abnormally large in an HTTP request.

The Service Ports parameter enables you to indicate on which ports the signature should look for HTTP traffic. By default, web-servers run on port 80, but many people use various other ports such as 8080. You need to configure this parameter based on your network configuration, indicating all ports that may be used for HTTP traffic.

Note

Because HTTP pattern matching requires a lot of sensor resources (memory and CPU), if a valid HTTP method (GET, HEAD, or POST) is not detected in the first 20 bytes of the HTTP request, HTTP inspection processing is stopped for the entire data stream.


Service Ident Engine Parameters

The Identification (IDENT) protocol is defined by RFC 1413. Basically, it is a service that enables a remote system to gain information about the user who is attempting to make a TCP connection with it. Numerous security problems have been associated with this protocol, which normally runs on TCP port 113. The parameters for the Service Ident signature engine are shown in Table 6-29.

Table 6-29. Service Ident Engine Parameters

Parameter Name

Values

Description

Direction

From Service

To Service

Determines whether the signature matches on traffic to the service port or from the service port

Inspection Type

Has Bad Port

Has Newline

Payload Size

Indicates the type of inspection to be performed

Max Bytes

0 65535

Defines the maximum number of bytes in the payload that is considered normal (valid only in conjunction with Payload Size inspection type)

Service Ports

port-list

A comma-separated list of ports or port ranges on which the service may reside


The Service Ident signature engine performs a basic decode of the IDENT protocol and enables you to look for abnormal IDENT packets. Setting the Inspection Type parameter to Has Bad Port will cause the signature to trigger if the packet contains a bad port number. Similarly, setting the Inspection Type to Has Newline causes the signature to trigger if the packet contains any newline characters besides the one signaling the end of the IDENT request.

As in the Service HTTP engine, you can specify the ports on which the IDENT traffic may be found. The Service Ident signatures will examine all traffic for the ports specified by the Service Ports parameter. Using the Direction parameter, you control whether the signature checks for traffic to the service port or from the service port.

Finally, you can check for buffer overflow attacks by using the Max Bytes parameter (in conjunction with the inspection type of Payload Size). Any IDENT request that is larger than this value will cause your signature to trigger.

Service MSSQL Engine Parameters

The Service MSSQL signature engine inspects the protocol used by the Microsoft SQL (MSSQL) server. The engine-specific parameters are listed in Table 6-30.

Table 6-30. Service MSSQL Engine Parameters

Parameter Name

Values

Description

Sql Username

string

Determines the username (exact match) to match for a user logging in to the MSSQL service

Password Present

Yes

No

If Yes, the signature matches if a password is not provided in the MSSQL login request


Using the Sql Username parameter, you can specify a username that will cause the signature to trigger if the engine detects this username in a login request sent to the SQL server. This parameter is the exact username that will cause the signature to trigger.

You can also use the Password Present parameter to search for login attempts that do not specify a password. If this parameter is set to Yes, the signature will trigger on any login attempts to the SQL server that do not specify a password.

Service NTP Engine Parameters

The Service NTP signature engine inspects NTP traffic. NTP enables systems on your network to synchronize their system clocks. It is defined by RFC 1305. The parameter for this engine is shown in Table 6-31.

Table 6-31. Service NTP Engine Parameter

Parameter Name

Values

Description

Inspection Type

Inspect NTP Packets

Is Invalid Data Packet

Is Non NTP Traffic

Determines the type of NTP traffic inspected


When defining a signature by using the Service NTP engine, you specify only the type of NTP traffic being inspected. You can choose from the following three options:

  • Inspect NTP Packets

  • Is Invalid Data Packet

  • Is Non NTP Traffic

Service RPC Engine Parameters

RPC is a protocol that one program can use to request a specific service from a program located on another computer across the network (see RFC 1057). The major parameters for the Service RPC engine are shown in Table 6-32.

Table 6-32. Service RPC Engine Parameters

Parameter Name

Values

Description

Direction

To Service

From Service

Specifies whether traffic is matched going to or from the service port (default is To Service)

Port Map Program

0 99999

The program number sent to the portmapper that this signature is interested in

Protocol

TCP

UDP

Specifies the traffic to be examined by the signature

Rpc Max Length

0 99999

Defines the maximum RPC message length that is considered normal

Rpc Procedure

0 65535

The RPC procedure number that this signature will match on

Rpc Program

0 99999

The RPC program number that this signature will match on

Service Ports

port-list

A comma-separated list of ports or port ranges on which the service may reside

Is Spool Src

Yes

No

If Yes, matches when the source address is 127.0.0.1


RPC has a utility that provides the port numbers for various services that are running on a system. RPC-based signatures typically identify an attacker attempting to bypass the portmapper program and access RPC services directly.

The Port Map Program parameter enables you to create signatures that look for client requests to the portmapper program that are requesting the port for a specific RPC service (identified by a single RPC program number). For instance, if you wanted to create a signature that watches for requests to the ypbind service, you would set the Port Map Program parameter to 100007. Then, any time the sensor detects a client request to the portmapper program with a value of 100007, the signature will trigger an alarm.

You can also create signatures that examine generic RPC traffic. Using the Rpc Program and Rpc Procedure parameters, you can create signatures that decode the RPC header, which enables the signatures to trigger on a specified RPC program number and RPC procedure. For instance, you can create a signature that looks for RPC traffic to a specific procedure within ypbind by creating a custom signature that specifies an Rpc Program value of 100007 (along with defining the value for the RPC procedure that you are interested in).

Service SMB Engine Parameters

The Service SMB signature engine decodes the Server Message Block (SMB) protocol. Using this engine, you can create signatures that detect unwanted SMB traffic. The major parameters for the Service SMB engine are shown in Table 6-33.

Table 6-33. Service SMB Engine Parameters

Parameter Name

Values

Description

Allocation Count

0 42949677295

Microsoft RCP (MSRPC) allocation hint

Byte Count

0 65535

(Optional) Specifies a required byte count for the SMB_COM_ TRANSACTION structure

Command

0 255

SMB command

Direction

From Service

To Service

Specifies whether the signature looks at traffic to or from the service (default is To Service)

File ID

0 65535

(Optional) Transaction file ID

Function

0 65535

(Optional) Named pipe function

Hit Count

0 65535

(Optional) Threshold number of occurrences in the scan interval to trigger alarms 3302 and 6255

Operation

0 65535

(Optional) MSRPC operation request

Resource

string

(Optional) Pipe or SMB filename for signature

Service Ports

port-list

A comma-separated list of ports on which to search for traffic (default is 139,445)

Swap Attacker Victim

Yes

No

If Yes, the signature will switch source and destination IP addresses in the alarm information (default is Yes)

Scan Interval

1 131071

(Optional) The time interval in seconds that is used to determine alarm rates (for signatures 3302 and 6255 only)

Set Count

0 255

(Optional) Number of setup words

Type

0 255

Type field of MSRPC packet (0, request; 2, response; 11, Bind; 12, Bind Ack)

Word Count

0 255

(Optional) Word count for command parameters


Service SNMP Engine Parameters

The Service SNMP signature engine supports signatures that examine SNMP traffic (see RFC 3412). The major parameters for this engine are shown in Table 6-34.

Table 6-34. Service SNMP Engine Parameters

Parameter Name

Values

Description

Community Name

string

The SNMP password (community string) that the signature matches on (used with SNMP Inspection inspection type)

Object ID

string

The object identifier that the signature will match on (used with SNMP Inspection inspection type)

Brute Force Count

1 65535

Defines the number of unique community names seen between two systems to constitute a brute-force attempt (specified for the Brute Force Inspection inspection type)

Inspection Type

Brute Force Inspection

Invalid Packet Inspection

Non-SNMP Traffic Inspection

SNMP Inspection

Identifies the type of traffic to be inspected


The Service SNMP signature engine has the following inspection types:

  • Brute Force Inspection

  • Invalid Packet Inspection

  • Non-SNMP Traffic Inspection

  • SNMP Traffic Inspection

When you set the inspection type to Non-SNMP Traffic Inspection, the signature will trigger when the traffic examined does not represent a valid SNMP packet. Similarly, setting the inspection type to Invalid Packet Inspection causes the signature to trigger when the traffic appears to be an SNMP packet but the data is malformed in some fashion.

You can use the following parameters to check for brute-force attempts to guess a valid community name:

  • Brute Force Inspection

  • Bruce Force Count

Setting the inspection type to Brute Force Inspection causes the signature to trigger if it detects a single system using more unique community names against a single target system than the value specified by the Brute Force Count parameter. For instance, if the Brute Force Count is set to 4 and the inspection type is Brute Force Inspection, the signature will trigger if host A sends 4 or more SNMP requests (with different community name strings) to host B.

You can also create signatures that search for specific community names or object IDs by setting the Community Name and Object ID parameters and by setting the inspection type to SNMP Inspection.

Note

The Service SNMP signature engine inspects traffic only for SNMP version 1.


Service SSH Engine Parameters

The Service SSH signature engine supports signatures that examine SSH traffic. Since everything except the initial setup fields are encrypted in an SSH session, these signatures examine only the setup fields. The major parameters for this engine are listed in Table 6-35.

Table 6-35. Service SSH Engine Parameters

Parameter Name

Values

Description

Length

0 65535

Defines the RSA key length or user length; the signature triggers when this length is exceeded

Length Type

Key Length

User Length

Identifies whether the length being used is the key length or the user length

Packet Depth

0 65535

Defines the number of packets to watch before determining that a session key was missed

Service Ports

port-list

A comma-separated list of ports or port ranges at which the SSH service may reside


Using the Service SSH signature engine, you can examine the following setup fields:

  • RSA Key Length

  • Username Length

State Signature Engine

A state machine consists of a starting state and a list of valid state transitions. Cisco IDS supports the following three state machines:

  • Cisco Login

  • Line Printer Remote (LPR) Format String

  • SMTP

Each of these machines has a set of valid states and configuration parameters. The parameters that are common to all of these state machines are shown in Table 6-36.

Table 6-36. Common State Signature Engine Parameters

Parameter Name

Values

Description

Direction

To Service

From Service

Indicates whether to inspect traffic to the service (default) or from the service

Exact Match Offset

0 65535

(Optional) The exact offset at which the string must occur for a match to be valid

Min Match Length

0 65535

(Optional) The minimum number of bytes the regex string must match from the beginning to the end of the match

Min Match Offset

0 65535

(Optional) Requires the matched string to occur a minimum number of bytes from the beginning of the packet

Max Match Offset

0 65535

(Optional) Indicates the maximum number of bytes to be inspected during the search for the string match

Regex String

string

The regular expression that specifies the pattern to search for

Service Ports

port-list

A comma-separated list of ports or port ranges at which the SSH service may reside

State Machine

Cisco Login

LPR Format String

SMTP

Defines the state scenario that the signature applies to

Swap Attacker Victim

Yes

No

If Yes, the signature switches source and destination IP addresses in the alarm information (default is Yes)


The State Machine parameter indicates the state machine that will be used to begin searching for the pattern specified by the Regex String parameter. If a match is found in the correct state, the signature triggers.

You can restrict pattern matching by using the Exact Match Offset, Min Match Offset, Max Match Offset, and Min Match Length parameters. The Exact Match Offset parameter limits the searching to a specific location in the packet. The Min Match Offset requires the Regex String parameter match to occur a specified number of bytes from the beginning of the packet, and the Max Match Offset limits the maximum number of bytes in the packet that are inspected during the search for the regex string. The Min Match Length specifies a minimum number of bytes that the Regex String parameter must match in order for the signature to trigger.

Each of the state machines also shares a State Name parameter, but the allowed values vary, depending on the machine chosen.

Cisco Login States

When using the Cisco Login state machine, you can configure your signature to look for one of the following states:

  • Cisco Device

  • Control C

  • Pass Prompt

  • Start

Table 6-37 shows the transitions defined for the Cisco Login state machine. These states relate to interactive logins to Cisco devices. You can use these defined transitions (in conjunction with the State Name parameter) to create signatures that check for specific patterns at different states in the Cisco login process.

Table 6-37. Cisco Login State Machine Transitions

Regex String

Required State

Next State

Direction

User[ ]Access[ ]Verification

START

CiscoDevice

FromService

Cisco[ ]Systems[ ]Console

START

CiscoDevice

FromService

assword[:]

CiscoDevice

PassPrompt

FromService

\x03

PassPrompt

ControlC

ToService

(enable)

ControlC

EnableBypass

FromService

\x03[\x00-\xFF]

ControlC

PassPrompt

ToService


Note

For more information on the format and structure of regex strings, refer to Chapter 7, "Advanced Signature Configuration."


LPR Format String States

When using the LPR Format String state machine, you can configure your signature to look for one of the following states:

  • Abort

  • Format Char

  • Start

Note

The LPR Format String state engine checks requests being sent to the printer process on UNIX systems and printer devices.


Table 6-38 shows the transitions defined for the LPR Format String state machine.

Table 6-38. LPR Format String State Machine Transitions

Regex String

End Offset

Required State

Next State

Direction

[1-9]

1

START

ABORT

ToService

%

n/a

START

FormatChar

ToService

[\x0a\x0d]

n/a

FormatChar

ABORT

ToService


SMTP States

When using the SMTP state machine, you can configure your signature to look for one of the following states:

  • Abort

  • Mail Body

  • Mail Header

  • SMTP Commands

  • START

Table 6-39 shows the transitions defined for the SMTP state machine. These states relate to SMTP. You can use these transitions (in conjunction with the State Name parameter) to create signatures that check for specific patterns at different states in the SMTP protocol.

Table 6-39. SMTP State Machine Transitions

Regex String

Required State

Next State

Direction

[\r\n]250[ ]

START

SmtpCommands

FromService

250[ ][^\r\n] [\x7f-\xff]*SNMP

START

SmtpCommands

FromService

(HE|EH)LO

START

SmtpCommands

ToService

[\r\n](235|220.*TLS)

START

ABORT

FromService

[\r\n](235|220.*TLS)

SmtpCommands

ABORT

FromService

[Dd][Aa][Tt][Aa][Bb] [Dd][Aa][Tt]

SmtpCommands

MailHeader

ToService

[\r\n]354

SmtpCommands

MailHeader

FromService

[\r\n][.][\r\n]

MailHeader

SmtpCommands

ToService

[\r\n][2][0-9][0-9][ ]

MailHeader

SmtpCommands

FromService

([\r\n]|[\n][\r]){2}

MailHeader

MailBody

ToService

[\r\n][.][\r\n]

MailBody

SmtpCommands

ToService

[\r\n][2][0-9][0-9][ ]

MailBody

SmtpCommands

FromService


String Signature Engines

The String signature engines support regex pattern matching and alarm functionality for the following three protocols: ICMP, UDP, and TCP. Each of these engines shares the common engine-specific parameters shown in Table 6-40.

Table 6-40. Common String Engine Parameters

Parameter Name

Values

Description

Direction

To Service

From Service

Indicates whether to inspect traffic to the service or from the service

Exact Match Offset

0 65535

The exact stream offset (in bytes) in which the regex string must report a match

Min Match Length

0 65535

The minimum number of bytes the regex string must match from the beginning to the end of the match

Min Match Offset

0 65535

(Optional) Requires the matched string to occur a minimum number of bytes from the beginning of the packet

Max Match Offset

1 65535

(Optional) Indicates the maximum number of bytes to be inspected during the search for the string match

Regex String

string

The regular expression that specifies the pattern to search for

Service Ports

port-list

A comma-separated list of ports or port ranges at which the service may reside (applies only to TCP and UDP)

Swap Attacker Victim

Yes

No

If Yes, the signature switches source and destination IP addresses in the alarm information (default is Yes)


The String signature engines are divided into the following three signature engines:

  • String ICMP

  • String TCP

  • String UDP

Each of the engines supports signatures that search their specific protocol for configured patterns through these common parameters. String ICMP and String TCP also each have a unique engine-specific parameter.

String ICMP Engine Specific Parameters

The unique String ICMP parameter is shown in Table 6-41.

Table 6-41. String ICMP Unique Engine Parameter

Parameter Name

Values

Description

ICMP Type

0 18

Indicates the ICMP types in which to search for the string (default is 0 18)


The ICMP Type parameter specifies which ICMP types that the signature will check for the specified string. The following shows some common ICMP type values:

  • Echo Reply (0)

  • Destination Unreachable (3)

  • Source Quench (4)

  • Redirect (5)

  • Echo Request (8)

  • Timestamp (13)

  • Timestamp Reply (14)

  • Information Request (15)

  • Information Reply (16)

String TCP Engine-Specific Parameters

The unique String TCP parameter is shown in Table 6-42.

Table 6-42. String TCP Unique Engine Parameter

Parameter Name

Values

Description

StripTelnetOptions

Yes

No

If Yes, any Telnet options are stripped off before a regex pattern match is performed on the data (default is No)


Sweep Signature Engines

The Sweep Signature engines identify situations in which one system is making connections to either multiple hosts or multiple ports. The Sweep Signature engines are shown in Table 6-43.

Table 6-43. Sweep Signature Engines

Engine

Description

Sweep

Sweeps signatures for ICMP, TCP, and UDP traffic

Sweep Other TCP

Identifies odd sweeps and scans such as nmap


Sweep Signature Engine Parameters

The Sweep Signature engine supports signatures for ICMP, TCP, and UDP sweeps. The parameters that are common to all of these protocols are shown in Table 6-44.

Table 6-44. Sweep Signature Engine Parameters

Parameter Name

Values

Description

Port Range

port-list

The range of ports that the signature will use when checking for sweep traffic (applicable only to TCP and UDP Sweeps)

Protocol

ICMP

TCP

UDP

Protocol of the traffic that the sweep signature will detect

Storage Key

Attacker Address

Attacker Address and Victim Port

Attacker and Victim Addresses

Identifies which addresses determine unique instances of the signature

Swap Attacker Victim

Yes

No

If Yes, the signature switches source and destination IP addresses in the alarm information (default is Yes)

Unique

0 65535

Identifies the number of unique connections allowed until the signature fires


Each protocol also has unique parameters that you can configure only for that type of sweep.

Unique ICMP Sweep Parameters

When the protocol selected for the sweep is ICMP, the signature triggers when one host sends ICMP traffic to multiple destination systems. The ICMP-specific parameter is shown in Table 6-45.

Table 6-45. Unique ICMP Sweep Parameter

Parameter Name

Values

Description

Icmp Type

0 255

The ICMP type that this signature matches on (default is 0)


You use the Icmp Type parameter to define which type of ICMP traffic you want the signature to trigger on. Then you use the Unique parameter to indicate how many instances of the ICMP traffic are required to trigger the signature.

Note

If you do not specify a value by using the Icmp Type parameter, the signature examines all ICMP traffic.


Unique TCP Sweep Parameters

When the protocol selected for the sweep is TCP, the signature triggers when one host sends TCP traffic to multiple destination systems (host sweep) or multiple ports on the same systems (port sweep). The TCP-specific parameters are shown in Table 6-46.

Table 6-46. Unique TCP Sweep Parameters

Parameter Name

Values

Description

Fragment Status

Any

Fragmented

Not Fragmented

Identifies whether the fragment status of the packet impacts processing by the signature (default is Any)

Inverted Sweep

Yes

No

If Yes, signature uses source port instead of the destination port to count unique connections (default is No)

Mask

FIN

SYN

RST

PSH

ACK

URG

ZERO

The mask used when checking the Tcp Flags This field indicates the TCP flags that you want to include in your checking

Suppress Reverse

Yes

No

Do not trigger the signature when a sweep is detected in the reverse direction on this address set (default is No)

TCP Flags

FIN

SYN

RST

PSH

ACK

URG

ZERO

Indicates the TCP flags (out of the flags included in the Mask parameter) that need to be set for the signature to match


Use the following parameters to specify what type of TCP traffic you want the signature to match on:

  • Mask

  • TCP Flags

The Mask parameter essentially identifies the TCP flags that you are interested in, whereas the TCP Flags parameter indicates which of the TCP flags need to be set. TCP flags that you do not include in the Mask parameter have no impact on whether the signature triggers. For instance, assume that you set the Mask parameter to include FIN and RST and the TCP Flags parameter to include only RST. The signature will trigger based on only the values of the FIN and RST flags in the packets (all of the other TCP flags in the packet are ignored). Packets will trigger the signature as follows:

  • If the RST and FIN flags are set, the signature will not trigger.

  • If the RST flag is set and the FIN flag is not set, the signature will trigger (regardless of the value for the other TCP flags).

  • If the RST flag is not set, the signature will not trigger.

The Unique parameter indicates the number of unique connections required to trigger the signature.

The Sweep signature engine supports detecting both host sweeps and port sweeps. A TCP port sweep is a signature that detects when a single host attempts to connect to multiple TCP ports on the same target system.

As with host sweeps, you need to specify the TCP flags that you want to include in your processing by using the Mask and TCP Flags parameters. TCP Port Sweep signatures, however, also use the following parameters:

  • Inverted Sweep

  • Suppress Reverse

  • Port Range

When you set the Inverted Sweep parameter to Yes, the signature will trigger on the source port instead of the destination port when it is counting unique connections. Similarly, the Suppress Reverse parameter controls whether the signature attempts to automatically trigger in the reverse direction. When the parameter is set to Yes, the reverse direction is not checked.

Note

When configuring UDP port sweep signatures, you also configure a port range. By default a port range is not specified, so the default signature is a UDP host sweep.


Sweep Other TCP Signature Engine Parameters

The Sweep Other TCP Signature engine supports signatures that trigger when a mixture of TCP packets (with different flags set) is detected on the network. The engine parameters for this engine are shown in Table 6-47.

Table 6-47. Sweep Other TCP Signature Engine Parameters

Parameter Name

Values

Description

Port Range

port-range

The range of ports that the signature will use when checking for sweep traffic

Set TCP Flags

FIN

SYN

RST

PSH

ACK

URG

ZERO

Identifies a list of TCP flag combinations that cause the signature to fire when packets matching all of the flag combinations (and the other engine parameters) have been detected


The Port Range parameter identifies the ports that are valid for the signature to process. You specify a range of ports by entering the beginning port and the ending port (separated by a dash). For instance, to use ports 1000 through 2000 in your signature, you will use the following port range:

1000-2000 

You can specify a list of TCP flag combinations. Each of the TCP flag combinations that you specify must be detected before the signature triggers. Unlike other TCP-based engines, this engine does not have a Mask parameter. In this situation, the signature looks for only the flags specified in the Set TCP Flags list and ignores any other TCP flags. For instance, suppose you add the following TCP flags combinations to the Set TCP Flags list:

  • SYN, FIN

  • FIN, RST

  • RST, PSH

The signature will not trigger until it sees at least one packet matching each of the following criteria:

  • Packet with at least the SYN and FIN flags set

  • Packet with at least the FIN and RST flags set

  • Packet with at least the RST and PSH flags set

This engine is useful for detecting attacks from various scanning tools (such as Nmap and Queso) that send TCP packets with strange flag combinations in an attempt to identify the target operating system.

Trojan Horse Signature Engines

Attackers can place various backdoor Trojan horse programs on systems in a network to enable them to operate from systems within your network. Cisco IDS has three signature engines specifically designed to detect the presence of Trojan horse programs on your network (see Table 6-48).

Table 6-48. Trojan Horse Signature Engines

Engine

Description

Trojan Bo2K

Detects the presence of BO2K by using the TCP protocol

Trojan Tfn2K

Detects the presence of the TFN2K Trojan horse by examining UDP, TCP, and ICMP traffic

Trojan UDP

Detects the presence of BO and BO2K by using the UDP protocol


The only one of these engines that has any user-configurable parameters is the Trojan Horse UDP Signature Engine. With the Trojan horse UDP signature, you can configure the Swap Attacker Victim parameter. Since Trojan horse signature engines are highly specialized, you usually do not create custom signatures for them.



CCSP IPS Exam Certification Guide
CCSP IPS Exam Certification Guide
ISBN: 1587201461
EAN: 2147483647
Year: 2004
Pages: 119
Authors: Earl Carter

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net