Understanding Cisco IDS Signatures
It is important to understand what a
signature is, and what exactly a signature does. A signature is a known type of
activity. It has already been detected in the wild and someone has captured the
personality or traffic pattern of the attack or intrusive activity and
documented it. In many ways, the signature is something akin to a fingerprint.
The fingerprint is unique to a person just like the signature is unique to a
certain attack or type of activity. A Cisco IDS sensor then compares traffic
against the signatures it has configured and will match up this activity when it
appears on your network. The parameters you set for the signature will tell the
sensor how to respond to the threat. The sensor can send an alarm to your IDS
management device, log the event, send e-mail alerts, or even block the suspect
traffic at the router, switch, or firewall.
When you load signature updates up to the IDS sensor, the
signatures are loaded onto the sensor with their recommended settings already
preconfigured. To view those signature settings with CSPM, scroll down the
network topology in the left pane and select Tools and Services |
Sensor Signatures. The name of the signature files is listed there. By
default, CSPM creates a Default signature file when the
sensor is added, as we see in Figure 7.1. You can have a different signature file
for each sensor on your network or use one for all of them. To get to the
signatures from inside Cisco's Intrusion Detection Manager (IDM), choose Configuration | Sensing Engine | Signature Configuration | Signature
Groups, shown in Figure 7.2. The most critical signatures are usually
configured and set to generate high- or, at the least, medium-level alarms. When
the sensor detects traffic that meets the enabled signatures, it fires off an
alarm. The sensor stores all alarms in the sensor logs that are informational
and above. If you have a Cisco IDS Management device, and it is configured as a
destination for alarms, the alarms are also sent to that device for viewing.
Signature
Implementation
The complexity of signatures can be explained fairly easily.
There are several components that make up the signatures and as long as you
understand the role each component plays, you will not have a problem with
understanding them. It is not a black art or magic, just a bit of common sense.
As we mentioned earlier, the signature is created from an already known
activity. Once intrusive or malicious activity is discovered in the wild, a
signature is created that looks for that specific behavior and nothing else. The
sensor has a database of all the signatures and their specific configurations,
and compares the traffic against that database. Signatures are implemented as
either content-based or context-based.
|
Note |
Content-based signatures are triggered by information
contained in the payload of the packet such as a URL string that could possibly
compromise a web server application.
Context-based signatures are triggered by the data in the packet
headers. This is an enhancement to Packet Signature Detection, which does not
consider any context. The most common implementations of Context-Based Signature
Detection are designed to look for attack signatures in particular fields or use
a particular offset within a packet stream (based on the protocol).
You need to keep this straight in your head when taking the
Cisco IDS exam. |
Signature
Classes
The class of the signatures is important to understand. The
attack and the intentions of the attack will drive the classification of the
signatures. Reconnaissance, Informational, Access, and Denial of Service are the
four main categories.
Reconnaissance is what the attackers do that enable them to
map out a network such as DNS queries, ports scans, and even pings. This type of
activity will trigger the reconnaissance class signatures. Once the active IP
addresses and open ports have been identified, information is gathered about the
hosts by attempting to connect or communicate with the host. The attacker may
try to connect to the host on a specific port. If the connection is successful,
the attacker can deduce what type of system it is by what ports are open. The
activity is not necessarily malicious but can be intrusive. Informational class
signatures are configured to detect this type of activity. Access signatures
fire alarms when known unauthorized access or attempts to access are detected.
Denial-of-Service or DoS class signatures trigger when the level of activity on
the network is detected as having the ability to disrupt services.
Signature
Structure
The structure of the signature depends on the number or
packets that have to be inspected. They can be either atomic or composite.
Atomic signatures can be detected by inspecting a single packet. No state
information is required. Some examples of an atomic signature are
-
1004-IP options-Loose Source Route
-
3050-Half-open SYN Attack
-
3455-Java Web Server Cmd Exec
-
3652-SSH Gobbles
A composite signature is detected by inspecting multiple packets.
If the sensor detects the first packet that is a potential attack, it stores
that information and the information of the following packets. State information
is required in order to perform this function. Examples of a composite signature
are:
-
3225-WWW websendmail File Access
-
3250-TCP Hijack
-
3314-Windows Locator Service Overflow
-
3990-BackOrifice BO2K TCP Non Stealth
For example, in the SYN Attack, a single packet with the SYN
bit set is sent without the rest of the normal TCP three-way handshake. All the
IDS sensor needs to see is the single SYN IP packet out of order. With the
Windows Locator attack, it requires more then a single packet of information and
the IDS sensor will match on the first one in the sequence, tag it as
interesting and look for more matches of the known attack sequence. Once the IDS
sensor sees more of the attack, it will trigger whatever alarms or actions it
was programmed to carry out.
Signature
Types
Cisco also categorizes the signatures into different traffic
types. The different types are
General signatures cover the 1000, 2000, 5000, and 6000 signature
series. Depending on the type of attack, the General signatures look for
abnormalities in a known type of traffic such as making sure a certain protocol
is behaving correctly or the payload in packets is or looks correct. An example
of a general signature is 3037-TCP FRAG SYN FIN Host
Sweep. This signature triggers when a series of packets (TCP) with both the
SYN and FIN flags set have been sent to multiple hosts with the same destination
port. Having the SYN and FIN flags set is abnormal, as is fragmentation.
Connection signatures are covered in the 3000 and 4000 signature
series. They observe traffic to UDP ports and TCP connections. An example of
connection signature is 3001-TCP Port Sweep. TCP Port
sweep is the perfect example of a connection signature. It fires when a series
of TCP connections are initiated on a host to multiple ports. The port range is
less than 1024. Be vary aware of these types of detects. It can be a prelude to
a major attack.
String signatures are highly flexible. They monitor strings (text)
within packets that you deem important. An example of a string signature is 8000:2303-Telnet-+ +. When a Telnet session is initiated and
the command "++" is entered, this signature will fire. All string detects will
generate an 8000 series alarm. It is the subID, 2303, that differentiates the
string signatures.
Access-Control-List signatures apply to traffic or activity
that is attempting to circumvent access control lists on the routers. These are
signatures in the 10000 series. Like the string signatures, the subID is what
differentiates the different signatures. An example of an Access-Control-List
signature is 10000:1001-IP-Spoof Interface 2. This
particular signature triggers when there is notification from a NetSentry device
that an IP datagram has been received from a source in front of the router with
an IP address that belongs behind the router.
Sections
Comments (0 posted)
Syndication
