The task of deploying a network IPS (Intrusion Prevention System) device can be quite overwhelming for a network or security professional that hasn’t done it before. Before tackling such a task, it is very important to understand Cisco Signatures. The purpose of this document is to help a network or security professional understand Cisco Signatures, which includes the properties, engines, alerts, and actions. The content will remain at a high level, but there is more in depth information related to these topics found in the CCNP Security IPS 642-627 Official Cert Guide as well as the Cisco Configurations guides for the Cisco IPS appliance and IOS IPS.
What is a Signature?
IPS Signatures are a set of rules used by Cisco IPS sensors to detect known attacks, such as denial of service (DoS) attacks. The sensors analyze packets and, if malicious, a signature is triggered based on the way the IPS sensor has been configured to react to such. Cisco IPS sensors have some critical signatures enabled by default to ensure that a level of security is maintained after the sensor is integrated into the network, leading quickly to compliance with the Security policy as the case may be.
Due to the nature of some attacks, signatures are also designed to have sub-signatures. This implies that certain characteristics of the signature can be modified via the sub-signature without changing the entire signature. Cisco IPS sensor signatures are generally classified into three types.
- Default Signatures: are signatures created for known attacks.
- Tuned Signatures: are signatures created by modifying built-in signatures to suit particular needs
- Custom Signatures: are created based on certain criteria, which the administrator decides on.
Signature Properties
These signatures, though being different types, all have the same properties.
- Signature Name: is the user-friendly name of the signature, and it usually provides a short description of the attack that the signature is designed to detect or prevent
- Signature ID: is an integer that uniquely identifies the signature. The Cisco IPS assigns customer signatures, signature IDs above 60000. If a signature has multiple sub-signatures, each sub-signature is assigned a sub-signature ID unique in the context of the parent signature.
- Signature Status: describes the signature as enabled or disabled, which can mean either inspecting traffic or not or active or retired.
- Severity Engine: defines the Cisco IPS inspection routines that the signature uses to match traffic
- Severity Rating: determines the default severity that is assigned to events causing the signature to trigger. The severity can be later adjusted to reflect other environmental conditions.
- Fidelity Rating: describes the accuracy with which the signature matches attacks
- Triggering Conditions: (the most important part of the signature) describes network traffic properties that need to be present in order for the signature to trigger.
- Summarization Strategy: describes how often the signature generates alarms
- Response Actions: are taken by the sensor when the signature triggers.
Signature Engines
A signature engine is a component of the analysis engine of the sensor that inspects a particular aspect of network traffic and supports a category of signatures. Each Cisco IPS signature is created and controlled by a signature engine that is specifically designed for the type of traffic being monitored. For example, the STRING.TCP engine examines TCP connections searching for string patterns. It controls signatures such as the following:
- Signature 29619, Heap Feng Shui Code which triggers on detecting a heap spraying attack execution. This remote code execution exploit allows the attacker to insert arbitrary code into the systems heap memory space, which may cause a Denial of Service. This signature is enabled by default by the Cisco IPS sensor with the following parameters.
- Severity Rating – High
- Fidelity Rating – 95 (Means it is accurate in 95% of cases)
- Response Action - Block
The Cisco IPS engines run simultaneously with one another depending on the number of signatures that are enabled. Each engine is composed of a parser, an inspector, and a set of parameters that have configurable ranges or sets of values. These configurable parameters enable you to tune signatures to work optimally in your network and to create unique signatures as the occasion demands.
Another example is the ATOMIC.IP engine, which inspects IP protocol headers and associated Layer 4 transport protocols (TCP, UDP and ICMP) and payloads. It controls signatures such as the following:
- Signature 1006, IP Options-Strict Source Route which by default detects packets containing the Strict Source Route option in the IP header. These packets are often used in spoofing attacks to bypass normal network routing. This signature is also enabled by default by the Cisco IPS sensor with the following parameters
- Severity Rating – High
- Fidelity Rating – 100
- Triggering Conditions – IP Option 137 found in header
- Summarization strategy – Summarize if occurrences exceed 100 in 30 seconds
- Response Action – Produce Alert and log
Figure 1 below shows the properties of signature 1006 described:
(click on the image to enlarge)
Signature Alerts
The Cisco IPS sensor generates alerts by default after a signature is triggered due to matching malicious traffic. The alerting feature is a configurable signature action that can be disabled or left enabled. It is recommended to leave it enabled. Alerts are stored in the sensor EventStore, which is a fixed-size indexed store. The Cisco IPS Device Manager (IDM), Cisco IPS Manager Express (IME) or Cisco Monitoring Analysis and Response System (MARS) can pull alerts from the sensor via the Security Device Event Exchange (SDEE) protocol, which allows a host or hosts to collect alerts as needed without tasking the sensor processor.
There are two types of event requests used by the SDEE protocol for external monitoring applications as mentioned above when interfacing with the sensor:
- Query: Issue a query request to retrieve the events in the EventStore at the time of the request
- Subscription: Establish a live feed to view alerts as they occur.
Note: Multiple hosts can perform queries and subscribe to the live event feed simultaneously.
Based on the signature triggering an alert, a severity level is derived, which can be any of the following:
- Informational
- Low
- Medium
- High
These severity levels do not affect the format of the alert, because it stays consistent irrespective of the severity level. The format of an alert as it appears in the CLI conforms to the Cisco Intrusion Detection Event Exchange standards. The Cisco Intrusion Detection Exchange extends the SDEE and adds IPS specific elements that are used in Cisco IPS Sensor Software Version 7.0 alerts. A commonly used CLI command to view these events is show events alert.
The Cisco IPS sensor software version 7.0 contains more than 4500 built-in default signatures of which approximately 1500 are enabled by default. These signatures will increase as new known threats are discovered. The Cisco IPS can automatically update its signatures or it can be done manually. You cannot rename or delete built in signatures, but you can retire signatures that are old or are not applicable. If you are not running an application on your network, a signature preventing attacks to such an application is not required. Retiring signatures conserves memory and improves the performance of the sensor.
Note: Sensor performance can be improved by retiring signatures that are not in use or that are not applicable. You can always re-activate retired signatures if the need arises.
The maximum number of signatures you can enable depends on the sensor platform. The sensor will notify you after the maximum has been reached. The fact that a sensor can hold more signatures than other sensors does not indicate performance. Judging sensors based on signatures can be deceiving. Different vendors build signatures in different ways. The criteria below may help in making those considerations:
- Some vendors create many signatures to cover all variations, but another vendor may use a lower number of more generic signatures that cover all of these variations.
- Generic signatures are often better and tend to be less susceptible to evasion, but they may cause more false positives.
The Cisco IPS Sensor does not rely on signatures alone to mitigate attacks but also looks at behaviors. It relies on its Global correlation through using Sensor Base to mitigate attacks on all Cisco IPS-protected networks.
Signature Actions
As discussed previously, the mode in which the IPS is deployed or operates determines the criteria that trigger an action by matching network traffic. Typically, the sensor will operate primarily as an IDS, IPS, or a mixture of both. The Cisco IPS Sensor allows you to have various detective or preventive actions based on the signature. While some of these actions will work only in inline mode, others will work only with specific network protocols. Due to the cumbersomeness of configuring actions for each signature, Cisco pre-configures many actions for specific signatures and provides additional configuration tools allowing you to easily modify actions to many signatures at the same time.
The Cisco IPS supports the following detective actions based on matching network traffic:
- Produce Alert – This actions writes the event that is related to the trigger signatures to the EventStore as an alert
- Produce Verbose Alert – This action includes an encoded dump of the offending packet in the alert. This causes an alert to be written to the EventStore, even if the Produce Alert action is not selected.
- Log Attacker Packets – This action starts capturing packets that contain the IP address of the attacker. This causes an alert to be written to the EventStore, even if the Produce Alert action is not selected.
- Log Victim Packets – This action starts IP logging on packets that contain the IP address of the victim and sends an alert. This causes an alert to be written to the EventStore even if the Produce Alert action is not selected.
- Log Pair Packets – This action starts IP logging on packets that contain the attacker and victim address pair. This causes an alert to be written to the EventStore, even if the Produce Alert action is not selected.
- Request SNMP Trap - This action sends a request to the Notification Application component of the sensor to send an SNMP trap about this event. This causes an alert to be written to the EventStore, even if t the Produce Alert action is not selected.
The Cisco IPS supports the following preventive (aggressive) actions based on matching network traffic:
- Deny Packet Inline – This action drops the offending packet that has caused the signature to trigger. This is applicable only to virtual sensors in inline mode.
- Deny Connection Inline – This action drops the offending packet and future packets on a particular TCP or UDP flow. This is valid only when inline
- Deny Attacker Victim Pair Inline – This action drops the offending packet and future packets between the attacker and the victim addresses for a specified period of time, This is valid only for sensors in inline mode.
- Deny Attacker Service Pair Inline – This drops the offending packet and future packets from the attacker address and victim port pair for a specified period of time. This is valid only for sensors in inline mode
- Deny Attacker Inline – This action drops the offending packet and future packets from this attacker address for a specified period of time. The sensor maintains a list of the attackers currently being denied by the system. Entries can be removed from this list or allowed to expire based on a timer that is reset should a currently listed attacker issue another attack. This is valid only for inline modes.
- Reset TCP Connection – This action sends spoofed TCP reset (RST) segments to terminate the offending TCP connection. This can be used with the deny packet to quickly free the connection related resources of the target.
- Request Block Connection – This action sends a request to a remote blocking device to block a connection.
- Request Block Host – This action sends a request to a remote blocking device to block an attacker host
- Request Rate Limit – This action sends a request to a remote blocking device to start rate limiting traffic from the attacker host
- Modify Packet Inline – This action is used by the sensors’ IP and TCP normalization engines to change some packet property such as clearing a TCP flag.
You will notice that all the signature actions with Inline can be carried out only by sensors in inline mode and not in promiscuous mode. The Inline mode sensor supports all the actions listed above, but the promiscuous mode sensor supports only those without the inline.
You can try to use the Reset TCP Connection action in promiscuous mode to attempt to block TCP-based attacks in real time; however, this is not always reliable in high packet rate flows. Instead, you can use the Request Block Host and Request Block Connections action to prevent some attacks in promiscuous mode.
Dave Burns joined Cisco in July 2008 as a systems engineer working for a U.S.-based SP Mobility account. He came to Cisco from a large U.S.-based cable company, where he was a senior network and security design engineer. Dave has held various roles prior to joining Cisco during his 10-plus years in the industry, working in SP operations, SP engineering, SP architecture, enterprise IT, and United States military intelligence communications engineering. He is currently a Systems Engineering Manager working with US Service Providers on various architectures that include IP NGN, Data Center, Cloud, Security, Mobility, and Transport. He holds various sales and industry and Cisco technical certifications, including CISSP, CCSP, CCDP, and two associate-level certifications. Dave recently passed the CCIE Security written exam, and is currently preparing for the CCIE Security Lab. Dave is also currently working on his Masters in Business Administration in his ‘free’ time. Dave earned his Bachelor of Science degree in telecommunications engineering technology from Southern Polytechnic State University, Georgia, where he currently serves as a member of the industry advisory board for the Computer & Electrical Engineering Technology School.
 |
CCNP Security IPS 642-627 Official Cert Guide By David Burns, Odunayo Adesina, Keith Barker ISBN-10: 1-58714-255-4 ISBN-13: 978-1-58714-255-0 Published: October 25, 2011 US SRP: $55.99 Published by Cisco Press. |