Building Cisco IDS 3.0(3) Custom Signatures
- Signature Engine Types
- Engine Parameters
- Creating Custom Signatures
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Many intrusion-detection systems enable you to create custom signatures. Up through Cisco Secure Intrusion Detection System 2.5, the only customizable signatures available were string-based signatures. This forced customers to rely on signature updates to maintain current signature databases. Starting with version 3.0, the way in which signatures are defined and processed changed dramatically, by creating numerous signature engines. With these new engines, signatures are specified using a dynamic set of textual signature parameters. The system signatures are defined in a system configuration file. By specifying the correct parameters, however, you can also easily add new signatures to your own user configuration file, and thus create your own custom signatures. Furthermore, besides creating new signatures definitions, you can also tune existing system signatures so that they operate more effectively in your network configuration.
Understanding the custom signature capability with Cisco IDS requires understanding the following:
- Signature engine types
- Engine parameters
Signature Engine Types
To enable you to efficiently and effectively create custom signatures, signature processing is spread across five distinct categories of signature engines:
- Atomic engines
- Flood engines
- Sweep engines
- Service engines
- String engines
Each of the categories is composed of multiple signature engines that are programmed to handle intrusive activity possessing specific characteristics, such as protocol decodes and database access. To make configuration easier, each signature engine is designed to support all signatures falling into a certain category (such as single packet TCP signatures). Furthermore, each engine has a parser to read in the text-based descriptions for all signatures that the engine is responsible for detecting, and an inspector that actually looks for the intrusive activity in the network traffic stream.
Atomic Engines
The ATOMIC signatures are handled by the following five engines:
- ATOMIC.ICMP
- ATOMIC.IPOPTIONS
- ATOMIC.L3.IP
- ATOMIC.TCP
- ATOMIC.UDP
Each of these engines is designed to enable you to create simple single-packet signatures. Whenever a packet that matches a configured signature is detected, an alarm is triggered. The major difference between the different ATOMIC signature engines is that each engine has engine-specific parameters that are customized on protocol-specific characteristics. Some of the common engine specific parameters for the ATOMIC.TCP engine are the following:
Direction—Allows you to specify whether you are looking for traffic going to the specific TCP port (ToService) or from the specific TCP port (FromService).
ServicePorts—Allows you to specify a comma-delimited list of ports or port ranges in which a specific service may be found.
TcpFlags—Allows you to only examine packets with specific TCP flags set.
Flood Engines
There are four different FLOOD signature engines:
- FLOOD.HOST.ICMP
- FLOOD.HOST.UDP
- FLOOD.NET
- FLOOD.TCPSYN
All of the FLOOD engines are designed to enable you to create signatures that watch for one or more hosts sending packets to a single host. All these packets have similar characteristics (such as packets with the SYN flag set). Besides configuring the type of packets that you consider interesting, you also need to specify the rate (using the rate engine-specific parameter) at which the packets must arrive to trigger the alarm.
Sweep Engines
To process SWEEP signatures, Cisco IDS uses the following five signature engines:
- SWEEP.HOST.ICMP
- SWEEP.HOST.TCP
- SWEEP.PORT.TCP
- SWEEP.PORT.UDP
- SWEEP.RPC
The SWEEP.HOST signature engines handle detecting connections from one host to many hosts, whereas the SWEEP.PORT signature engines are focused on detecting port connections between two hosts. These signatures typically enable you to locate an attacker probing for services on a specific host on your network. Similar to the port connections tracked by the SWEEP.PORT signature engines, the SWEEP.RPC signature engine processes signatures that count valid RPC requests made to a set of ports. When creating SWEEP signatures, you will probably want to specify the number of unique connections that must be detected before triggering the alarm (Unique engine specific parameter). Another useful engine specific parameter is ResetAfterIdle. It enables you to specify the length of idle time that must pass before resetting the connection count.
Service Engines
The SERVICE engines are customized to analyze specific service characteristics above the transport layer (layers 5 and above) in the stack. There are currently four different SERVICE signature engines:
- SERVICE.DNS.TCP
- SERVICE.DNS.UDP
- SERVICE.PORTMAP
- SERVICE.RPC
The DNS signature engines analyze compressed DNS messages. You can use these signatures to alarm on specific characteristics such as request/reply conditions and overflow attempts. The RPC and PORTMAP engines are specifically designed to detect problems with RPC and Portmapper requests.
String Engines
The STRING engines are designed to enable you to easily search for REGEX strings in several different types of traffic streams. Presently, these signatures are divided into the following four different STRING engines:
- STRING.HTTP
- STRING.ICMP
- STRING.TCP
- STRING.UDP
Some useful STRING engine-specific parameters are MinMatchLength and MultipleHits. The MinMatchLength parameter enables you to specify a minimum string length that is valid. Any matches shorter than this length are ignored. The MultipleHits parameter allows you to create signatures that look for multiple occurrences of the same string in a single packet.