CIDS Signatures

CIDS signatures form the intelligence built into your network sensors. A signature is a set of rules pertaining to typical intrusion activity that, when matched, generates a unique response.

Signatures can be broken down to be included into a number of different categories to assist with the understanding of how the signature operates and analyzes network traffic. Each of these categories describes the operations of each signature. Signature implementations describe what the signature is examining. Signatures can analyze the protocol header information (context) or the data encapsulated in the packet (content). Signature structures categorize signatures based on the number of packets required to match the signature. Some signatures are matched by examining a single packet, while other signatures require multiple packets to make a match. Signature classes detail the type of attack the specific signature is used to detect. As discussed in Chapter 23, different attack types exist and, because there are different attack types, signature classes describe the type of attack the signature was created to detect. Signature types categorize each signature by describing the type of traffic the signature is used to monitor or match. Some signature types monitor protocol connections, while other types monitor SYSLOG output of a router to determine when traffic was denied because of an ACL violation. The last category used to describe a signature is the signature severity, which is a configurable parameter that can be used to judge the seriousness of the triggered signature.

To assist you in understanding CIDS signatures, this section discusses the following signature categories in detail:

Signature Series
Signature Implementations
Signature Structures
Signature Classes
Signature Types
Signature Severity

Signature Series

CIDS organizes all the signatures into a series. When an alarm is sent, the signature that generated the alarm is also sent. The Event Viewer displays not only the alarm, but also the signature ID. While recognizing every signature ID that could generate an alarm would be difficult, you can tell from the series of the signature what type of signature was matched. Cisco has organized the signatures to allow for easier identification.

Each of the series is a collection of related signatures. The signature series are 1000, 2000, 3000, 4000, 5000, 6000, 8000, and 10000. The following is a list of all the signature series and the signatures found in each.

STUDY TIP?

Be aware of each signature series and the type of traffic monitored by each.

1000 Series Signatures—IP Signatures

Includes the following:

IP Options
IP fragmentation
Bad IP Packets

2000 Series Signatures—ICMP Signatures

Includes the following:

ICMP Traffic Records
Ping Sweeps
ICMP Attacks

3000 Series Signatures—TCP Signatures

Includes the following:

TCP Traffic Records
TCP Port Scans
TCP Host Sweeps
Mail Attacks
FTP Attacks
Legacy CIDS Web Attacks (Signature IDs 3200–3233)
NetBIOS Attacks
SYN Flood and TCP Hijack Attacks
TCP Applications

4000 Series Signatures—UDP Signatures

Includes the following:

UDP Traffic Records
UDP Port Scans
UDP Attacks
UDP Applications

5000 Series Signatures—Web (HTTP) Signatures

Includes the following:

Web Attacks

6000 Series Signatures—Cross Protocol Signatures

Includes the following:

DNS Attacks
RPC Service Attacks
Authentication Failures
Loki Attacks
Distributed DoS Attacks

8000 Series Signatures—String Match Signatures

Includes the following:

Custom String Matches
TCP Applications

10000 Series Signatures—ACL Policy Violation Signatures

Includes the following:

Defined IOS ACL Violations

Signature Implementations

The signature implementations of CIDS signatures come in two types: every signature is either context based or content based. Each of these two types of signature implementations describes which part of the TCP/IP packet is examined.

Context-Based Signatures

Context-based signatures are triggered based on the data contained in the packet header. Information included in the IP headers is used to trigger a context-based signature. The information examined by context-based signatures includes the following:

IP Options
IP Fragmentation Parameters
TCP Flags
IP Protocol Field
IP, TCP, and UDP Checksums
IP Addresses
Port Numbers

Content-Based Signatures

Content-based signatures search the data portions of the TCP/IP packet, looking for a match. Table 26-1 lists example signatures of the signature definition used to detect these attacks.

Table 26-1: Content- and Context-Based Signatures
Signature Name	Signature Implementation
ICMP Echo Request	Content
ICMP Net Sweep w/ Echo	Context
WWW IIS Unicode	Content
TFN Client Request	Content

Signature Structure

As previously discussed, signature implementations deal with packet headers and packet payloads. The structure of the signatures deals with the number of packets that must be examined to trigger an alarm. Two types of signature structures exist and these are as follows:

Atomic
Composite

Atomic Structure

Some attacks can be detected by matching IP header information (context based) or string information contained in a single IP packet (content based). Any signatures that can be matched with a single packet fall into the atomic category. Because atomic signatures examine individual packets, there’s no need to collect or store state information.

An example of an atomic signature is the SYN-FIN signature (signature ID 3041). This signature looks for packets that have both the SYN and FIN flags set. The SYN flag indicates this is a packet attempting to begin a new connection. The FIN flag indicates this packet is attempting to close an existing connection. These two flags shouldn’t be used together and, when they are, this is an indication some intrusive activity might exist.

Composite Signatures

Composite signatures require a series of multiple packets to match before an alarm is triggered. Because composite signatures require multiple packets to make a match, the sensor must also keep state information describing the packets that were previously examined. If the sensor analyzes a packet that begins to match a composite signature, the sensor must record this information while it examines additional traffic to complete the signature match.

An example composite signature is the IP fragments overlap signature (signature ID 1103). The sensor must examine multiple IP fragments to discover an overlap between two or more IP fragments. Because this signature requires the examination of multiple packets to trigger an alarm, this is a composite structure signature.

Signature Classes

CIDS signatures fall into four classes. Signatures belong to one of the four classes, based on the type of attack the signature was designed to detect. As discussed in Chapter 23, there are three types of attacks: Reconnaissance, Access, and Denial of Service (DoS). Signature classes map to these three attack types and add one additional class. The four signature classes are as follows:

Reconnaissance
Access
Denial of Service
Informational

Reconnaissance Class Signatures

Reconnaissance class signatures are used to detect reconnaissance attacks against your network. Before intruders can launch an attack against your network resources, they must first map your network and network resources. Hackers have many different tools they can use to discover the type, location, and vulnerabilities of your network resources. Reconnaissance class signatures trigger as a result of analyzed activity known to be, or that could lead to, unauthorized discovery of systems, services, or vulnerabilities. Once triggered, these alarms alert security personnel when the sensors detect these tools are being used against your network. Common reconnaissance techniques used by hackers and detected by reconnaissance class signatures are as follows:

Ping Sweeps—Allow intruders to map the active IP addresses on your network.
Port Scans–Scan for open ports on ranges of network resources.
DNS Queries–Allow users and intruders to retrieve information about the topology of your network.

Access Class Signatures

Access class signatures are used to detect access attacks against your network systems. Access class signatures can detect attacks that could lead to unauthorized data retrieval, system access, or privileged escalation. Common access techniques used by hackers and detected by access class signatures are as follows:

Unix Tooltalk Database server attack
Internet Information Services (IIS) Unicode attack
Back Orifice or NetBus

Denial of Service (DoS) Class Signatures

Denial of service class signatures are used to detect DoS attacks against your network. These signatures trigger an activity used for the disablement of a network infrastructure, systems, or services. Common DoS techniques used by hackers and detected by DoS class signatures are as follows:

Ping of Death
Tribe Flood Network (TFN) attacks
Trinoo attacks

Informational Class Signatures

Informational class signatures are used to detect normal network activity, which, in itself, isn’t considered malicious, but the information can be used to judge the validity of an attack, as well as for forensic purposes. Common informational events detected by information class signatures are as follows:

ICMP echo requests
TCP connection requests
UDP connections

Signature Types

The signature types describe the type of network traffic the signature is used to match. Some signatures detect intrusions by examining the TCP connection requests or UDP connections. Other signature types examine the protocol information in the IP headers or the protocol-dependant application commands located in the packet payload. The four signature types are as follows:

General
Connection
String
Access control list

General Signature Types

General signatures are used to detect a wide range of intrusive activity. General signatures are used to detect intrusive activity from a number of different protocols included in the TCP/IP protocol suite. Protocols that general signatures monitor include the following:

IP
ICMP
TCP
UDP

Many of the general signature types are context based because they examine the protocol header data, while attempting to find abnormalities. Other of the general signature types are content based because they examine the application layer protocol information in the payload portion of the packet, such as HTTP web signatures. The following signature series contain general signatures:

Series 1000 signatures (IP)
Series 2000 signatures (ICMP)
Series 5000 signatures (Web/HTTP)
Series 6000 signatures (cross-protocol)

Connection Signatures

Connection signatures are used to monitor TCP and UDP connection requests between hosts. Connection signatures report the number of connections detected for each transport layer protocol. Connection signatures also have subsignatures, used to identify the port number each connection is using. The following two signature series make up your connection signatures:

TCP connections, series 3000
UDP traffic, series 4000

Connection signatures that detect TCP connections are from the 3000 series; UDP traffic is detected and monitored with 4000 series signatures. Each of these connection signatures has subsignatures, used to identify the TCP or UDP port. For example, a Telnet connection request (using TCP) creates an alarm with a 3000 series signature and a subsignature of 23 (Telnet). If the Telnet application is using UDP, a 4000 series signature triggers the alarm. The series identifies the protocol in use—TCP or UDP—while the subsignature identifies the port in use.

String Signatures

String signatures are used to detect text strings within the TCP/IP packets. You can determine and configure the strings that should be detected. String signatures trigger an alarm whenever the configured string is matched using a standard regular expression-matching algorithm. All string-matching signatures fall into the 8000 signature series.

Whenever a string signature is matched, an alarm is generated with a signature ID of 8000. The string subsignature is used to identify which string was matched by the sensor. When you want to configure a string signature, you must also define the subsignature used to specify the string that was matched. For example, you can create a string signature used to search for the string “root,” and then configure this signature with a subsignature ID of 11000. When this string is matched, the signature ID will be 8000, with a sub-ID of 11000. Based on this information, you can determine which string your network sensor matched. Some predefined signature series 8000 are configured on your network sensors:

Telnet-/etc/shadow (ID 8000, SubID 2302)
Rlogin + + (ID 8000, SubID 51303)

If you receive an alarm on your CSPM host with a signature ID of 8000, you know a string signature was matched. By examining the SubID, you can determine which string was matched.

Access Control Lists

Cisco routers can be configured with access control lists (ACLs) to block traffic that violates defined security policies. If configured to do so, the router can log information anytime an ACL denies traffic into or out of the network. This logged data can then be sent in real time to a SYSLOG server or a sensor. The sensor can monitor this SYSLOG information and generate alarms whenever the ACL is forced to block suspicious traffic. Access control signature types belong to the signature series 10000. All alarms triggered by router ACLs will have a signature ID of 10000. The subsignature ID is used to differentiate the ACL that generated the SYSLOG message.

Signature Severity

The signature severity represents the probability that the matched signature represents a real and immediate security threat to your systems and network. Each signature has a default severity assigned to it by Cisco security engineers and these default severities are normally adequate for most network environments.

While each signature already has an assigned severity, this is a configurable parameter and can be changed by security personnel. The three severity levels are low, medium, and high. The severity is based on the alarm level. Alarms can be assigned an alarm level of one to five. Table 26-2 shows how the alarm levels match the alarm severities.

Table 26-2: Alarm Levels and Severities
Severity/ Alarm Level	Description	Probability of an Actual Attack	Immediate Threat
Low, Levels 1–2	Benign activity, but recorded for informational purposes.	Very Low	No
Medium, Levels 3–4	Abnormal activity that could be malicious.	Medium	Low
High, Level 5	Actual attacks are detected that allow access or used for DoS.	Very High	Yes

Low Severity

Signatures configured (default) with low-severity alarm levels represent the lowest threat to your network. Many of the signatures configured for a low-severity level are actual informational signatures. Alarms generated by these signatures don’t usually indicate intrusive activity. Some signatures configured for a low-severity level are as follows:

FTP SYST Command (Signature ID 3151)
Unknown IP protocol (Signature ID 1101)

Medium Severity

Signatures configured with a medium-severity alarm level are used to detect abnormal network traffic that might be perceived as malicious. Some of these signatures are triggered on techniques that were effective in the past, but are usually no longer a threat in modern network environments. Intrusion attempts using these legacy vulnerabilities have a low probability of being successful and, therefore, are assigned a medium- severity level. Examples of signatures that have a medium-severity level include the following:

TCP SYN Port Sweep (Signature ID 3002)
ICMP network Sweep with Echo (Signature ID 2100)

High Severity

Signatures configured with a high-severity alarm level represent the most significant threats to your network and system security. Signatures that alarm with a high-severity level detect attacks that intruders use to gain access to network resources. By default, DoS attack signatures are also configured with a high-severity level. The following are examples of signatures configured with a high-severity level: