Foundation and Supplemental Topics
Cisco IPS SignaturesTo 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 EnginesCisco 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.
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 ParametersTo 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:
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 EnginesHTTP 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.
AIC FTP Signature Engine ParametersUsing the Application Inspection and Control (AIC) FTP signature engine involves configuring the parameters shown in Table 6-4.
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 ParametersUsing the AIC HTTP signature engine involves configuring the parameters shown in Table 6-5.
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 ParametersWhen 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.
Define Web Traffic Policy ParametersWhen 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 ParametersWhen 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.
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 ParametersWhen 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.
Transfer Encodings ParametersWhen 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.
Atomic Signature EnginesThe 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).
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 ParametersAtomic 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.
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:
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:
Atomic IP Engine ParametersThe 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:
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.
IP options provide optional information for the IP datagram. The major options are as follows:
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:
Atomic IP ICMP ParametersCreating ICMP atomic signatures involves configuring the parameters identified in Table 6-13.
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:
Atomic IP TCP ParametersCreating 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.
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:
Atomic IP UDP ParametersCreating 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.
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 ParametersWhen 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.
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 EnginesThe flood signature engines are shown in Table 6-17.
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 ParametersThe 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.
Flood Host ICMP ParametersUsing 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.
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:
Flood Host UDP ParametersThe 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.
Flood Net Engine ParametersThe 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.
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:
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 EngineThe 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.
Normalizer Signature EngineThe 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:
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 EnginesThe 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.
Service DNS Engine ParametersThe 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.
The engine-specific parameters for the Service DNS engine enable you to specify values for the following DNS fields:
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 ParametersThe 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.
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:
Service Generic Engine ParametersThe 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.
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 ParametersTo 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.
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:
When processing these message types, you can configure the policy applied to these messages by using one of the following policy types:
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 ParametersThe Service HTTP signature engine provides regular expression-based pattern inspection specifically designed to analyze HTTP. The major parameters are shown in Table 6-28.
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:
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:
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):
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:
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 ParametersThe 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.
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 ParametersThe Service MSSQL signature engine inspects the protocol used by the Microsoft SQL (MSSQL) server. The engine-specific parameters are listed in Table 6-30.
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 ParametersThe 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.
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:
Service RPC Engine ParametersRPC 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.
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 ParametersThe 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.
Service SNMP Engine ParametersThe 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.
The Service SNMP signature engine has the following inspection types:
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:
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 ParametersThe 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.
Using the Service SSH signature engine, you can examine the following setup fields:
State Signature EngineA state machine consists of a starting state and a list of valid state transitions. Cisco IDS supports the following three state machines:
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.
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 StatesWhen using the Cisco Login state machine, you can configure your signature to look for one of the following states:
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.
Note For more information on the format and structure of regex strings, refer to Chapter 7, "Advanced Signature Configuration." LPR Format String StatesWhen using the LPR Format String state machine, you can configure your signature to look for one of the following states:
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.
SMTP StatesWhen using the SMTP state machine, you can configure your signature to look for one of the following states:
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.
String Signature EnginesThe 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.
The String signature engines are divided into the following three signature engines:
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 ParametersThe unique String ICMP parameter is shown in Table 6-41.
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:
String TCP Engine-Specific ParametersThe unique String TCP parameter is shown in Table 6-42.
Sweep Signature EnginesThe 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.
Sweep Signature Engine ParametersThe 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.
Each protocol also has unique parameters that you can configure only for that type of sweep. Unique ICMP Sweep ParametersWhen 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.
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 ParametersWhen 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.
Use the following parameters to specify what type of TCP traffic you want the signature to match on:
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:
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:
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 ParametersThe 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.
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:
The signature will not trigger until it sees at least one packet matching each of the following criteria:
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 EnginesAttackers 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).
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. |
EAN: 2147483647
Pages: 119