Feedback
Table Of Contents
SERVICE.H255 Engine Parameters
SERVICE.HTTP Engine Parameters
SERVICE.MSRPC Engine Parameters
Signature Engines
This appendix describes the IPS signature engines. It contains the following sections:
About Signature Engines
A signature engine is a component of the Cisco IPS that is designed to support many signatures in a certain category. An engine is composed of a parser and an inspector. Each engine has a set of parameters that have allowable ranges or sets of values.
Note
The 5.0 engines support a standardized Regex.
IPS 5.0 contains the following signature engines:
•
It provides granular control over HTTP sessions to prevent abuse of the HTTP protocol. It allows administrative control over applications, such as instant messaging and gotomypc, that try to tunnel over specified ports. You can also use AIC to inspect FTP traffic and control the commands being issued.
There are two AIC engines: AIC.FTP and AIC.HTTP.
Note
For more information on configuring the AIC engine signatures, see Configuring AIC Signatures.
•
–
This engine lets you specify values to match for fields in the IP and Layer-4 headers, and lets you use Regex to inspect Layer-4 payloads.
Note
–
•
There are two FLOOD engines: FLOOD.HOST and FLOOD.NET.
•
Note
•
•
–
–
–
–
Helps the network administrator make sure the SETUP message coming in to the VoIP network is valid and within the bounds that the policies describe. Is also helps make sure the addresses and Q.931 string fields such as url-ids, email-ids, and display information adhere to specific lengths and do not contain possible attack patterns.
–
The WEBPORTS variable defines inspection port for HTTP traffic.
–
–
–
–
–
–
–
–
•
The state engine now has a hidden configuration file that is used to define the state transitions so new state definitions can be delivered in a signature update.
•
There are three STRING engines: STRING.ICMP, STRING.TCP, and STRING.UDP.
•
•
•
There are three Trojan engines: Bo2k, Tfn2k, and UDP. There are no user-configurable parameters in these engines.
MASTER Engine
The MASTER engine provides structures and methods to the other engines and handles input from configuration and alert output. This section describes the MASTER engine, and contains the following topics:
General Parameters
The following parameters are part of the MASTER engine and apply to all signatures.
Caution
Promiscuous delta lowers the RR of certain alerts in promiscuous mode. Because the sensor does not know the attributes of the target system and in promiscuous mode cannot deny packets, it is useful to lower the prioritization of promiscuous alerts (based on the lower risk rating) so the administrator can focus on investigating higher risk rating alerts.
In inline mode, the sensor can deny the offending packets and they never reach the target host, so it does not matter if the target was vulnerable. The attack was not allowed on the network and so we do not subtract from the risk rating value.
Signatures that are not service, OS, or application-specific have 0 for the promiscuously delta. If the signature is specific to an OS, service, or application, it has a promiscuous delta of 5, 10, or 15 calculated from 5 points for each category.
Table B-1 lists the general master engine parameters.
Alert Frequency
The purpose of the alert frequency parameter is to reduce the volume of the alerts written to the Event Store to counter IDS DoS tools, such as stick. There are four modes: Fire All, Fire Once, Summarize, and Global Summarize. The summary mode is changed dynamically to adapt to the current alert volume. For example, you can configure the signature to Fire All, but after a certain threshold is reached, it starts summarizing.
Table B-2 lists the alert frequency parameters.
Event Actions
The following event action parameters belong to each signature engine:
•
•
•
Note
•
•
•
•
•
•
•
•
•
•
Note
AIC Engine
The AIC engine inspects HTTP web traffic and enforces FTP commands. This section describes the AIC engine and its parameters, and contains the following topics:
Overview
The AIC engine defines signatures for deep inspection of web traffic. It also defines signatures that authorize and enforce FTP commands.
There are two AIC engines: AIC.HTTP and AIC.FTP.
The AIC engine has the following features:
•
–
–
–
–
–
–
–
–
–
This enforcement is done using regular expressions. There are predefined signature but you can expand the list.
•
–
For more information on configuring the AIC engine signatures, see Configuring AIC Signatures.
AIC Engine Parameters
AIC provides deep analysis of web traffic. It provides granular control over HTTP sessions to prevent abuse of the HTTP protocol. It allows administrative control over applications, such as instant messaging and gotomypc, that try to tunnel over specified ports. Inspection and policy checks for P2P and instant messaging are possible if these applications are running over HTTP.
AIC also provides a way to inspect FTP traffic and control the commands being issued.
You can enable or disable the predefined signatures or you can create policies through custom signatures.
The AIC engine runs when HTTP traffic is received on AIC web ports. If traffic is web traffic, but not received on the AIC web ports, the SERVICE.HTTP engine is executed. AIC inspection can be on any port if it is configured as an AIC web port and the traffic to be inspected is HTTP traffic.
Caution
Table B-3 lists the parameters that are specific to the AIC.HTTP engine:
Table B-4 lists the parameters that are specific to the AIC.FTP engine:
ATOMIC Engine
The ATOMIC engine contains signatures for simple, single packet conditions that cause alerts to be fired. This section describes the ATOMIC engine, and contains the following topics:
ATOMIC.ARP Engine
The ATOMIC.ARP engine defines basic Layer-2 ARP signatures and provides more advanced detection of the ARP spoof tools dsniff and ettercap.
Table B-5 lists the parameters that are specific to the ATOMIC.ARP engine.
ATOMIC.IP Engine
The ATOMIC.IP engine defines signatures that inspect IP protocol headers and associated Layer-4 transport protocols (TCP, UDP, and ICMP) and payloads.
Note
Table B-6 lists the parameters that are specific to the ATOMIC.IP engine.
FLOOD Engine
The FLOOD engine defines signatures that watch for any host or network sending multiple packets to a single host or network. For example, you can create a signature that fires when 150 or more packets per second (of the specific type) are found going to the victim host.
There are two types of FLOOD engines: FLOOD.HOST and FLOOD.NET.
Table B-7 lists the parameters specific to the FLOOD.HOST engine:
Table B-7 FLOOD.HOST Engine Parameters
protocol
Which kind of traffic to inspect.
ICMP
UDPrate
Threshold number of packets per second.
0 to 655351
icmp-type
Specifies the value for the ICMP header type.
0 to 65535
dst-ports
Specifies the destination ports when you choose UDP protocol.
0 to 655352
a-b[,c-d]src-ports
Specifies the source ports when you choose UDP protocol.
0 to 655353
a-b[,c-d]
1 An alert fires when the rate is greater than the packets per second.
2 The second number in the range must be greater than or equal to the first number.
3 The second number in the range must be greater than or equal to the first number.
Table B-8 lists the parameters specific to the FLOOD.NET engine:
Table B-8 FLOOD.NET Engine Parameters
gap
Gap of time allowed (in seconds) for a flood signature.
0 to 65535
peaks
Number of allowed peaks of flood traffic.
0 to 65535
protocol
Which kind of traffic to inspect.
ICMP
TCP
UDPrate
Threshold number of packets per second.
0 to 655351
sampling-interval
Interval used for sampling traffic.
1 to 3600
icmp-type
Specifies the value for the ICMP header type.
0 to 65535
1 An alert fires when the rate is greater than the packets per second.
META Engine
The META engine defines events that occur in a related manner within a sliding time interval. This engine processes events rather than packets. As signature events are generated, the META engine inspects them to determine if they match any or several META definitions. The META engine generates a signature event after all requirements for the event are met.
All signature events are handed off to the META engine by SEAP. SEAP hands off the event after processing the minimum hits option. Summarization and event action are processed after the META engine has processed the component events.
Caution
Table B-9 lists the parameters specific to the META engine.
For an example of a custom META engine signature, see Example MEG Signature.
NORMALIZER Engine
The NORMALIZER engine deals with IP fragmentation and TCP normalization. This section describes the NORMALIZER engine, and contains the following topics:
Overview
The NORMALIZER engine deals with IP fragment reassembly and TCP stream reassembly. With the NORMALIZER engine you can set limits on system resource usage, for example, the maximum number of fragments the sensor tries to track at the same time.
Note
•
Intentional or unintentional fragmentation of IP datagrams can hide exploits making them difficult or impossible to detect. Fragmentation can also be used to circumvent access control policies like those found on firewalls and routers. And different operating systems use different methods to queue and dispatch fragmented datagrams. If the sensor has to check for all possible ways that the end host will reassemble the datagrams, the sensor becomes vulnerable to denial of service attacks. Reassembling all fragmented datagrams inline and only forwarding completed datagrams, refragmenting the datagram if necessary, prevents this. The IP Fragmentation Normalization unit performs this function.
•
Through intentional or natural TCP session segmentation, some classes of attacks can be hidden. To make sure policy enforcement can occur with no false positives and false negatives, the state of the two TCP endpoints must be tracked and only the data that is actually processed by the real host endpoints should be passed on. Overlaps in a TCP stream can occur, but are extremely rare except for TCP segment retransmits. Overwrites in the TCP session should not occur. If overwrites do occur, someone is intentionally trying to elude the security policy or the TCP stack implementation is broken. Maintaining full information about the state of both endpoints is not possible unless the sensor acts as a TCP proxy. Instead of the sensor acting as a TCP proxy, the segments will be ordered properly and the normalizer will look for any abnormal packets associated with evasion and attacks.
Sensors in promiscuous mode report alerts on violations. Sensors in inline mode perform the action specified in the event-action parameter, such as produce-alert, deny-packet-inline, and modify-packet-inline.
For the procedures for configuring signatures in the NORMALIZER engine, see Configuring IP Fragment Reassembly Parameters, and Configuring TCP Stream Reassembly Parameters.
NORMALIZER Engine Parameters
Table B-10 lists the parameters that are specific to the NORMALIZER engine:
SERVICE Engines
The SERVICE engines analyze L5+ traffic between two hosts. These are one-to-one signatures that track persistent data. The engines analyze the L5+ payload in a manner similar to the live service.
The SERVICE engines have common characteristics but each engine has specific knowledge of the service that it is inspecting. The SERVICE engines supplement the capabilities of the generic string engine specializing in algorithms where using the string engine is inadequate or undesirable.
This section contains the following topics:
SERVICE.DNS Engine
The SERVICE.DNS engine specializes in advanced DNS decode, which includes anti-evasive techniques, such as following multiple jumps. It has many parameters such as lengths, opcodes, strings, and so forth. The SERVICE.DNS engine is a biprotocol inspector operating on both TCP and UDP port 53. It uses the STREAM for TCP and the QUAD for UDP.
Table B-11 lists the parameters specific to the SERVICE.DNS engine.
SERVICE.FTP Engine
The SERVICE.FTP engine specializes in FTP PORT command decode, trapping invalid PORT commands and the PASV port spoof. It fills in the gaps when the STRING engine is not appropriate for detection. The parameters are Boolean and map to the various error trap conditions in the PORT command decode. The SERVICE.FTP engine runs on TCP ports 20 and 21. Port 20 is for data and the SERVICE.FTP engine does not do any inspection on this. It inspects the control transactions on port 21.
Table B-12 lists the parameters that are specific to the SERVICE.FTP engine.
Table B-12 SERVICE.FTP Engine Parameters
direction
Direction of traffic:
•
•
from-service
to-serviceftp-inspection-type
Type of inspection to perform:
•
•
•
bad-port-cmd-address
bad-port-cmd-port
pasvservice-ports
A comma-separated list of ports or port ranges where the target service resides.
0 to 655351
a-b[,c-d]swap-attacker-victim
True if address (and ports) source and destination are swapped in the alert message. False for no swap (default).
true | false
1 The second number in the range must be greater than or equal to the first number.
SERVICE.GENERIC Engine
The SERVICE.GENERIC engine allows programmatic signatures to be issued in a config-file-only signature update. It has a simple machine and assembly language that is defined in the configuration file. It runs the machine code (distilled from the assembly language) through its virtual machine, which processes the instructions and pulls the important pieces of information out of the packet and runs them through the comparisons and operations specified in the machine code.
It is intended as a rapid signature response engine to supplement the STRING and STATE engines.
Note
Caution
Table B-13 lists the parameters specific to the SERVICE.GENERIC engine.
SERVICE.H225 Engine
This section describes the SERVICE.H225 engine, and contains the following topics:
•
Overview
The H225 engine analyzes H225.0 protocol, which consists of many subprotocols and is part of the H.323 suite. H.323 is a collection of protocols and other standards that together enable conferencing over packet-based networks.
H.225.0 call signaling and status messages are part of the H.323 call setup. Various H.323 entities in a network, such as the gatekeeper and endpoint terminals, run implementations of the H.225.0 protocol stack. The H225 engine analyzes H225.0 protocol for attacks on multiple H.323 gatekeepers, VoIP gateways, and endpoint terminals. It provides deep packet inspection for call signaling messages that are exchanged over TCP PDUs. The H225 engine analyzes the H.225.0 protocol for invalid H.255.0 messages, and misuse and overflow attacks on various protocol fields in these messages.
H.225.0 call signaling messages are based on Q.931 protocol. The calling endpoint sends a Q.931 setup message to the endpoint that it wants to call, the address of which it procures from the admissions procedure or some lookup means. The called endpoint either accepts the connection by transmitting a Q.931 connect message or rejects the connection. When the H.225.0 connection is established, either the caller or the called endpoint provides an H.245 address, which is used to establish the control protocol (H.245) channel.
Especially important is the SETUP call signaling message because this is the first message exchanged between H.323 entities as part of the call setup. The SETUP message uses many of the commonly found fields in the call signaling messages, and implementations that are exposed to probable attacks will mostly also fail the security checks for the SETUP messages. Therefore, it is highly important to check the H.225.0 SETUP message for validity and enforce checks on the perimeter of the network.
The H225 engine has built-in signatures for TPKT validation, Q.931 protocol validation, and ASN.1PER validations for the H225 SETUP message. ASN.1 is a notation for describing data structures. PER uses a different style of encoding. It specializes the encoding based on the data type to generate much more compact representations.
You can tune the Q.931 and TPKT length signatures and you can add and apply granular signatures on specific H.225 protocol fields and apply multiple pattern search signatures of a single field in Q.931 or H.225 protocol.
The H225 engine supports the following features:
•
•
•
•
•
•
•
There is a fixed number of TPKT and ASN.1 signatures. You cannot create custom signatures for these types. For TPKT signatures, you should only change the value-range for length signatures. You should not change any parameters for ASN.1. For Q.931 signatures, you can add new regular expression signatures for text fields. for SETUP signatures, you can add signatures for length and regular expression checks on various SETUP message fields.
SERVICE.H255 Engine Parameters
Table B-14 lists parameters specific to the SERVICE.H225 engine.
Table B-14 SERVICE.H.225 Engine Parameters
message-type
Type of H225 message to which the signature applies:
•
•
•
•
asn.1-per
q.931
setup
tpktpolicy-type
Type of H225 policy to which the signature applies:
•
•
•
•
•
Regex and presence are not valid for TPKT signatures.
length
presence
regex
validate
valuespecify-field-name
(Optional) Enables field name for use. Only valid for SETUP and Q.931 message types. Gives a dotted representation of the field name that this signature applies to.
•
1 to 512
specify-invalid-packet-index
(Optional) Enables invalid packet index for use for specific errors in ASN, TPKT, and other errors that have fixed mapping.
•
0 to 255
specify-regex-string
The regular expression to look for when the policy type is regex. This is never set for TPKT signatures:
•
•
regex-string
specify-min-match-lengthspecify-value-range
Valid for the length or value policy types (0x00 to 6535). Not valid for other policy types.
•
0 to 655351
a-b
1 The second number in the range must be greater than or equal to the first number.
SERVICE.HTTP Engine
This section describes the SERVICE.HTTP engine, and contains the following topics:
•
Overview
The SERVICE.HTTP engine is a service-specific string-based pattern-matching inspection engine. The HTTP protocol is one of the most commonly used in today's networks. In addition, it requires the most amount of preprocessing time and has the most number of signatures requiring inspection making it critical to the system's overall performance.
The SERVICE.HTTP engine uses a Regex library that can combine multiple patterns into a single pattern-matching table allowing a single search through the data. This engine searches traffic directed to web services only to web services, or HTTP requests. You cannot inspect return traffic with this engine. You can specify separate web ports of interest in each signature in this engine.
HTTP deobfuscation is the process of decoding an HTTP message by normalizing encoded characters to ASCII equivalent characters. It is also known as ASCII normalization.
Before an HTTP packet can be inspected, the data must be deobfuscated or normalized to the same representation that the target system sees when it processes the data. It is ideal to have a customized decoding technique for each host target type, which involves knowing what operating system and web server version is running on the target. The SERVICE.HTTP engine has default deobfuscation behavior for the Microsoft IIS web server.
For an example SERVICE.HTTP custom signature, refer to "Example SERVICE.HTTP Signature," in Configuring the Cisco Intrusion Prevention System Sensor Using the Command Line Interface 5.0.
SERVICE.HTTP Engine Parameters
Table B-15 lists the parameters specific the SERVICES.HTTP engine.
Table B-15 SERVICE.HTTP Engine Parameters
de-obfuscate
Applies anti-evasive deobfuscation before searching.
true | false
max-field-sizes
Maximum field sizes grouping.
specify-max-arg-field-length
(Optional) Enables maximum argument field length:
•
0 to 65535
specify-max-header-field-length
(Optional) Enables maximum header field length:
•
0 to 65535
specify-max-request-length
(Optional) Enables maximum request field length:
•
0 to 65535
specify-max-uri-field-length
(Optional) Enables the maximum URI field length:
•
0 to 65535
regex
Regular expression grouping.
—
specify-arg-name-regex
(Optional) Enables searching the Arguments field for a specific regular expression:
•
—
specify-header-regex
(Optional) Enables searching the Header field for a specific regular expression:
•
—
specify-request-regex
(Optional) Enables searching the Request field for a specific regular expression:
•
•
0 to 65535
specify-uri-regex
(Optional) Regular expression to search in HTTP URI field. The URI field is defined to be after the HTTP method (GET, for example) and before the first CRLF. The regular expression is protected, which means you cannot change the value.
[/\\][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][.]jpeg
service-ports
A comma-separated list of ports or port ranges where the target service resides.
0 to 655351
a-b[,c-d]swap-attacker-victim
True if address (and ports) source and destination are swapped in the alert message. False for no swap (default).
true | false
1 The second number in the range must be greater than or equal to the first number.
SERVICE.IDENT Engine
The SERVICE.IDENT engine inspects TCP port 113 traffic. It has basic decode and provides parameters to specify length overflows.
Table B-16 lists the parameters specific to the SERVICE.IDENT engine.
Table B-16 SERVICE.IDENT Engine Parameters
inspection-type
Type of inspection to perform.
—
has-bad-port
Inspects payload for a bad port.
true | false
has-newline
Inspects payload for a nonterminating new line character.
true | false
size
Inspects for payload length longer than this.
0 to 65535
service-ports
A comma-separated list of ports or port ranges where the target service resides.
0 to 655351
a-b[,c-d]direction
Direction of the traffic:
•
•
from-service
to-service
1 The second number in the range must be greater than or equal to the first number.
SERVICE.MSRPC Engine
This section describes the SERVICE.MSRPC engine, and contains the following topics:
•
Overview
The SERVICE.MSRPC engine processes MSRPC packets. MSRPC allows for cooperative processing between multiple computers and their application software in a networked environment. It is a transaction-based protocol, implying that there is a sequence of communications that establish the channel and pass processing requests and replies.
MS RPC is an ISO layer 5-6 protocol and is layered on top of other transport protocols such as UDP, TCP, and SMB. The MSRPC engine contains facilities to allow for fragmentation and reassembly of the MSRPC PDUs.
This communication channel is the source of recent Windows NT, Windows 2000, and Window XP security vulnerabilities.
The SERVICE.MSRPC engine only decodes the DCE and RPC protocol for the most common transaction types.
SERVICE.MSRPC Engine Parameters
Table B-17 lists the parameters specific to the SERVICE.MSRPC engine.
SERVICE.MSSQL Engine
The SERVICE.MSSQL engine inspects the protocol used by Microsoft's SQL server (MS SQL).
There is one MS SQL signature. It fires an alert when it detects an attempt to log in to an MS SQL server with the default sa account.
You can add custom signatures based on MS SQL protocol values, such as login username and whether a password was used.
Table B-18 lists the parameters specific to the SERVICE.MSSQL engine.
SERVICE.NTP Engine
The SERVICE.NTP engine inspects NTP protocol. There is one NTP signature, the NTPd readvar overflow signature, which fires an alert if a readvar command is seen with NTP data that is too large for the NTP service to capture.
You can tune this signature and create custom signatures based on NTP protocol values, such as mode and size of control packets.
Table B-19 lists the parameters specific to the SERVICE.NTP engine.
SERVICE.RPC Engine
The SERVICE.RPC engine specializes in RPC protocol and has full decode as an anti-evasive strategy. It can handle fragmented messages (one message in several packets) and batch messages (several messages in a single packet).
The RPC portmapper operates on port 111. Regular RPC messages can be on any port greater than 550. RPC sweeps are like TCP port sweeps, except that they only count unique ports when a valid RPC message is sent. RPC also runs on UDP.
Table B-20 lists the parameters specific to the SERVICE.RPC engine.
Table B-20 SERVICE.RPC Engine Parameters
direction
Direction of traffic:
•
•
from-service
to-serviceprotocol
Protocol of interest.
tcp
udpservice-ports
A comma-separated list of ports or port ranges where the target service resides.
0 to 655351
a-b[,c-d]specify-is-spoof-src
(Optional) Enables the spoof source address:
•
true | false
specify-port-map-program
(Optional) Enables the portmapper program:
•
0 to 9999999999
specify-rpc-max-length
(Optional) Enables RPC maximum length:
•
0 to 65535
specify-rpc-procedure
(Optional) Enables RPC procedure:
•
0 to 1000000
specify-rpc-program
(Optional) Enables RPC program:
•
0 to 1000000
1 The second number in the range must be greater than or equal to the first number.
SERVICE SMB Engine
The SERVICE.SMB engine inspects SMB packets. You can tune SMB signatures and create custom SMB signatures based on SMB control transaction exchanges and SMB NT_Create_AndX exchanges.
Table B-21 lists the parameters specific to the SERVICE.SMB engine.
Table B-21 SERVICE.SMB Engine Parameters
service-ports
A comma-separated list of ports or port ranges where the target service resides.
0 to 65535
a-b[,c-d] 1specify-allocation-hint
(Optional) Enables MS RPC allocation hint:
•
0 to 42949677295
specify-byte-count
(Optional) Enables byte count:
•
0 to 65535
specify-command
(Optional) Enables SMB commands:
•
0 to 255
specify-direction
(Optional) Enables traffic direction:
•
–
–
from service
to servicespecify-file-id
(Optional) Enables using a transaction file ID:
•
Note
0 to 65535
specify-function
(Optional) Enables named pipe function:
•
0 to 65535
specify-hit-count
(Optional) Enables hit counting:
•
0 to 65535
specify-operation
(Optional) Enables MS RPC operation:
•
0 to 65535
specify-resource
(Optional) Enables resource:
•
resource
specify-scan-interval
(Optional) Enables scan interval:
•
0 to 131071
specify-set-count
(Optional) Enables counting setup words:
•
0 to 255
specify-type
(Optional) Enables searching for the Type field of an MS RPC packet:
•
0 to 255
specify-word-count
(Optional) Enables word counting for command parameters:
•
0 to 255
swap-attacker-victim
True if address (and ports) source and destination are swapped in the alert message. False for no swap (default).
true | false
1 The second number in the range must be greater than or equal to the first number.
2 An exact match is optional.
3 An exact match is optional.
4 An exact match is required. Currently supporting the 37 (0x25) SMB_COM_TRANSACTION command \x26amp and the 162 (0xA2) SMB_COM_NT_CREATE_ANDX command.
5 An exact match is optional.
6 An exact match is required. Required for SMB_COM_TRANSACTION commands.
7 Valid for signatures 3302 and 6255 only.
8 Valid for signatures 3302 and 6255 only.
9 An exact match is required. Usually two are required for SMB_COM_TRANSACTION commands.
10 An exact match is required. Only 16 word transactions are decoded.
SERVICE.SNMP Engine
The SERVICE.SNMP engine inspects all SNMP packets destined for port 161. You can tune SNMP signatures and create custom SNMP signatures based on specific community names and object identifiers.
Instead of using string comparison or regular expression operations to match the community name and object identifier, all comparisons are made using the integers to speed up the protocol decode and reduce storage requirements.
Table B-22 lists the parameters specific to the SERVICE.SNMP engine.
SERVICE.SSH Engine
The SERVICE.SSH engine specializes in port 22 SSH traffic. Because all but the setup of an SSH session is encrypted, the engine only looks at the fields in the setup. There are two default signatures for SSH. You can tune these signatures, but you cannot create custom signatures.
Table B-23 lists the parameters specific to the SERVICE.SSH engine.
Table B-23 SERVICE.SSH Engine Parameters
length-type
Inspects for one of the following SSH length types:
•
–
•
–
0 to 65535
service-ports
A comma-separated list of ports or port ranges where the target service resides.
0 to 655351
a-b[,c-d]specify-packet-depth
(Optional) Enables packet depth:
•
0 to 65535
1 The second number in the range must be greater than or equal to the first number.
STATE Engine
The STATE engine provides state-based regular expression-based pattern inspection of TCP streams. A state engine is a device that stores the state of something and at a given time can operate on input to transition from one state to another and/or cause an action or output to take place. State machines are used to describe a specific event that causes an output or alarm.
There are three state machines in the STATE engine: SMTP, Cisco Login, and LPR Format String.
Table B-24 lists the parameters specific to the STATE engine.
Table B-24 STATE Engine Parameters
state-machine
State machine grouping.
—
cisco-login
Specifies the state machine for Cisco login:
•
–
–
–
–
cisco-device
control-c
pass-prompt
startlpr-format-string
Specifies the state machine to inspect for the LPR format string vulnerability:
•
–
–
–
abort
format-char
startsmtp
Specifies the state machine for the SMTP protocol:
•
–
–
–
–
–
abort
mail-body
mail-header
smtp-commands
startdirection
Direction of the traffic:
•
•
from-service
to-serviceservice-ports
A comma-separated list of ports or port ranges where the target service resides.
0 to 65535
a-b[,c-d] 1specify-exact-match-offset
(Optional) Enables exact match offset:
•
0 to 65535
specify-min-match-
length(Optional) Enables minimum match length:
•
0 to 65535
swap-attacker-victim
True if address (and ports) source and destination are swapped in the alert message. False for no swap (default).
true | false
1 The second number in the range must be greater than or equal to the first number.
STRING Engines
This section describes the STRING engine, and contains the following topics:
•
Overview
The STRING engine is a generic-based pattern-matching inspection engine for ICMP, TCP, and UDP protocols. The STRING engine uses a regular expression engine that can combine multiple patterns into a single pattern-matching table allowing for a single search through the data.
There are three STRING engines: STRING.ICMP, STRING.TCP, and STRING.UDP.
For an example custom STRING engine signature, see Example STRING.TCP Signature.
STRING.ICMP Engine Parameters
Table B-25 lists the parameters specific to the STRING.ICMP engine.
Table B-25 STRING.ICMP Engine Parameters
direction
Direction of the traffic:
•
•
from-service
to-serviceicmp-type
ICMP header TYPE value.
0 to 181
a-b[,c-d]specify-exact-match-offset
(Optional) Enables exact match offset:
•
0 to 65535
specify-min-match-length
(Optional) Enables minimum match length:
•
0 to 65535
swap-attacker-victim
True if address (and ports) source and destination are swapped in the alert message. False for no swap (default).
true | false
1 The second number in the range must be greater than or equal to the first number.
STRING.TPC Engine Parameters
Table B-26 lists the parameters specific to the STRING.TCP engine.
Table B-26 STRING.TCP Engine
direction
Direction of the traffic:
•
•
from-service
to-serviceservice-ports
A comma-separated list of ports or port ranges where the target service resides.
0 to 655351
a-b[,c-d]specify-exact-match-offset
(Optional) Enables exact match offset:
•
0 to 65535
specify-min-match-length
(Optional) Enables minimum match length:
•
0 to 65535
strip-telnet-options
Strips the telnet option characters from the data before the pattern is searched.2
true | false
swap-attacker-victim
True if address (and ports) source and destination are swapped in the alert message. False for no swap (default).
true | false
1 The second number in the range must be greater than or equal to the first number.
2 This parameter is primarily used as an IPS anti-evasion tool.
STRING-UDP Engine Parameters
Table B-27 lists the parameters specific to the STRING.UDP engine.
Table B-27 STRING.UDP Engine
direction
Direction of the traffic:
•
•
from-service
to-serviceservice-ports
A comma-separated list of ports or port ranges where the target service resides.
0 to 655351
a-b[,c-d]specify-exact-match-offset
(Optional) Enables exact match offset:
•
0 to 65535
specify-min-match-length
(Optional) Enables minimum match length:
•
0 to 65535
swap-attacker-victim
True if address (and ports) source and destination are swapped in the alert message. False for no swap (default).
true | false
1 The second number in the range must be greater than or equal to the first number.
SWEEP Engine
The SWEEP engine analyzes traffic between two hosts or from one host to many hosts. You can tune the existing signatures or create custom signatures. The SWEEP engine has protocol-specific parameters for ICMP, UDP, and TCP.
The alert conditions of the SWEEP engine ultimately depend on the count of the unique parameter. The unique parameter is the threshold number of distinct hosts or ports depending on the type of sweep. The unique parameter triggers the alert when more than the unique number of ports or hosts is seen on the address set within the time period. The processing of unique port and host tracking is called counting.
You can configure source and destination address filters, which means the sweep signature will exclude these addresses from the sweep-counting algorithm.
Event action filters based on source and destination IP addresses do not function for the Sweep engine, because they do not filter as regular signatures. To filter source and destination IP addresses in sweep alerts, use the source and destination IP address filter parameters in the Sweep engine signatures. A unique parameter must be specified for all signatures in the SWEEP engine. A limit of 2 through 40 (inclusive) is enforced on the sweeps. 2 is the absolute minimum for a sweep, otherwise, it is not a sweep (of one host or port). 40 is a practical maximum that must be enforced so that the sweep does not consume excess memory. More realistic values for unique range between 5 and 15.
TCP sweeps must have a TCP flag and mask specified to determine which sweep inspector slot in which to count the distinct connections.
The ICMP sweeps must have an ICMP type specified to discriminate among the various types of ICMP packets.
Table B-28 lists the parameters specific to the SWEEP engine.
TRAFFIC ICMP Engine
The TRAFFIC.ICMP engine analyzes nonstandard protocols, such as TFN2K, LOKI, and DDOS. There are only two signatures (based on the LOKI protocol) with user-configurable parameters.
Tribe Flood Net 2000 (TFN2K) is the newer version of the TFN. It is a Distributed Denial Of Service (DDoS) agent that is used to control coordinated attacks by infected computers (zombies) to target a single computer (or domain) with bogus traffic floods from hundreds or thousands of unknown attacking hosts. TFN2K sends randomized packet header information, but it has two discriminators that can be used to define signatures. One is whether the L3 checksum is incorrect and the other is whether the character 64 `A' is found at the end of the payload. TFN2K can run on any port and can communicate with ICMP, TCP, UDP, or a combination of these protocols.
LOKI is a type of back door Trojan. When the computer is infected, the malicious code creates an "Icmp Tunnel" that can be used to send small payload in ICMP replies (which may go straight through a firewall if it is not configured to block ICMP.) The LOKI signatures look for an imbalance of ICMP echo requests to replies and simple ICMP code and payload discriminators.
The DDoS category (excluding TFN2K) targets ICMP-based DDoS agents. The main tools used here are TFN (Tribe Flood Net) and Stacheldraht. They are similar in operation to TFN2K, but rely on ICMP only and have fixed commands: integers and strings.
Table B-29 lists the parameters specific to the TRAFFIC.ICMP engine.
TROJAN Engines
The TROJAN engines analyze nonstandard protocols, such as BO2K andTFN2K. There are three TROJAN engines: TROJAN.BO2K, TROJAN.TFN2K, and TROJAN.UDP.
BackOrifice (BO) was the original Windows back door Trojan that ran over UDP only. It was soon superseded by BackOrifice 2000 (BO2K). BO2K supported UDP and TCP both with basic XOR encryption. They have plain BO headers that have certain cross-packet characteristics.
BO2K also has a stealthy TCP module that was designed to encrypt the BO header and make the cross-packet patterns nearly unrecognizable.
The UDP modes of BO and BO2K are handled by the TROJAN.UDP engine. The TCP modes are handled by the TROJAN.BO2K engine.
There are no specific parameters to the TROJAN engines, except for swap-attacker-victim in the TROJAN.UDP engine.
