Cisco IDS Signature Engines

[ LiB ]

Every network environment is different and faces different threats. To tune your IDS to your specific network environment, you use signature engines to adjust the built-in signatures and to create new, custom signatures. Optimizing signatures for your environment involves establishing a balance between minimizing unnecessary workload created by false positives and retaining an environment sensitive enough to catch all possible threats. In other words, your goal is to detect all true positives and minimize false negatives . Signature configuration is covered in greater depth in Chapter 10. Here, we discuss general signature engine parameters and describe the Cisco Signature Engine series.

First, we examine signature engine parameters, both master and local, protected and required. Then, we look into some of the key master signature engine parameters such as AlarmThrottle and SummaryKey . Finally, we go into the whole series of signature engine categories, as listed in Table 9.3.

Table 9.3. Signature Engine Categories and Their Usage

Engine Category	Usage
Atomic	Single packet inspections
Flood	Detect attempted DoS attacks
Service	Analyze Layers 5, 6, and 7 protocols
State.String	Perform state-based, Regex pattern inspection for TCP streams
String	Inspect Regex patterns for multiple transport protocols
Sweep	Detect network reconnaissance activity
Traffic	Detect irregular traffic
Trojan	Target nonstandard protocols
OTHER	Handle signatures that don't fit into the other protocol decodes

Engine Parameters

You are now aware that sensors have a set of signature engines that are used to support different types of signatures. Each engine consists of an inspector and a parser and has a specific set of parameters with allowable ranges or sets of values.

An engine parameter is a name and value pair: both the name and the allowed values are determined by the signature engine category. Although the parameter name is consistent across all signatures for a specific signature engine, the allowed values vary for the signatures within the signature engine category.

Protected and Required Parameters

Signature engine parameters have the following attributes :

• Protected You cannot change a protected parameter for the default signatures; you can only change a protected parameter for custom signatures.

• Required A required signature parameter has to be defined for all signatures, whether default or custom.

A protected parameter can be changed for custom signatures but not default signatures. A required parameter needs to be defined for both custom and default signatures.

Master and Local Parameters

Cisco IDS signatures have master and local parameters. Master parameters are common across most signature engines, whereas local parameters are specific to each engine category. For example, all signature engines have an EventAction master signature parameter to define the signature response action. However, only State.String signatures have a StateName local signature parameter to define transitions within the state machine.

Master signature engine parameters are common across most signature engines.

Master engine parameters are summarized in Table 9.4. We then highlight some of the parameters that are particularly significant when implementing your IDS solution.

Table 9.4. Master Signature Engine Parameters

Master Signature Parameters	Value	Description
AlarmDelayTimer	13600	The number of seconds to delay further signature inspection after an alarm.
AlarmInterval	21000	Special handling for time events; use AlarmInterval Y with MinHits X for X alarms in a Y-second interval.
AlarmSeverity	High Medium Low Informational	The severity of the alert generated by the alarm.
AlarmThrottle	FireAll sends all alarms FireOnce sends the first alarm and then deletes the inspector Summarize sends an IntervalSummary alarm GlobalSummarize sends a GlobalSummary alarm	Technique used to limit alarm firings.
AlarmTraits	065,535	User -defined traits that further describe the signature.
ChokeThreshold	02,147,483,647	Threshold value of alarms per interval to autoswitch AlarmThrottle modes. If ChokeThreshold is defined, the Sensor switches AlarmThrottle modes when a high number of alarms appear in the ThrottleInterval .
Enabled	True enables the signature False disables the signature	Use to enable or disable a signature.
EventAction	Log Reset ShunHost ShunConnection ZERO	The action to perform when an alarm is fired from a signature trigger; a value of ZERO indicates that no action will be taken.
FlipAddr	True False	Swaps the source and destination information in the alarm event.
MaxInspectLength	02,147,483,647	Defines the maximum number of bytes to inspect.
MaxTTL	01000	Defines the maximum number of seconds to inspect a logical stream.
MinHits	02,147,483,647	Sets the minimum number of times the signature is triggered before an alarm event is sent.
Protocol	Frag IP TCP UDP ICMP ARP Cross ZERO Custom	Defines the protocol to be inspected.
ResetAfterIdle	21000	Sets the number of seconds to wait to reset the signature counters after the hosts were idle.
ServicePorts	< set list >	Defines a set of ports or port ranges where the target service resides.
SigComment	< string >	Defines miscellaneous information about the signature.
SIGID	99319,999 the range for default signatures 20,00050,000 the range for custom signatures	The numeric value assigned to the signature.
SigName	< string >	The alphanumeric name assigned to the signature.
SigStringInfo	< string >	Defines extra information included in the alarm message.
StorageKey	Xxxx Axxx xxBx AxBx AaBb Axxb Stream Double ZERO	Type of address key used to store persistent data.
SubSig	02,147,483,547	The number assigned to the subsignature.
SummaryKey	AaBb AxBx Axxb Axxx XxBx	The storage type on which to summarize this signature.
ThrottleInterval	01000	Defines the period of time used to control alarm summarization.
WantFrag	TRUE only fragmented packets generate an alarm FALSE only nonfragmented packets trigger an alarm <blank> both fragmented and nonfragmented packets trigger an alarm	Controls the inspection of fragmented packets.

Key Master Signature Engine Parameters

The following subsections discuss some of the key master signature engine parameters of those listed in the table. The parameters covered in these subsections are those that you would be most likely to tune to your unique network environment.

FlipAddr

You use the FlipAddr signature engine parameter when the traffic that fires the alarm is return traffic from the target system. In most situations, the traffic that triggers a signature has a source address of the attacker's IP address. In some situations, however, it's the return traffic that the signature must analyze to determine whether an attack is occurring.

Consider, for example, the ResetPortSweep signature, which searches for multiple resets sent from the target through various ports back to the attacker to determine whether an attack is underway. Without the FlipAddr parameter, this signature would return the IP address of the target hosts rather than the attacker. Setting the FlipAddr parameter to true allows the signature to display the correct source address of the attacker when an alarm is generated.

Configuring Alarm Throttling and Summarization

One way to prevent an attacker from flooding resources on your IDS is to limit the number of alarms generated; you can do so by setting the MinHits parameter. Recall from the preceding table that the MinHits parameter sets the minimum number of times the signature is triggered before an alarm event is sent. With this simple method, however, if the MinHits parameter were set to 1000, the alarm event would be sent after the thousandth hit, whether the 1000 triggers occurred over the period of 5 minutes or 5 hours; clearly, the two situations present different immediate threats to your network.

This is where alarm throttling and summarization come into play. With alarm throttling and summarization, you can limit the number of alarms generated by setting the AlarmThrottle parameter to one of four summarization settings and the ThrottleInterval parameter to a set duration. The summarization levels for the AlarmThrottle parameter are

• FireAll An alarm is fired for each match to the signature. The FireAll setting can generate a large number of alarms during an attack and is effectively the opposite of the FireOnce setting.

• FireOnce A single alarm is fired for each unique entry based on the SummaryKey parameter; a specified length of time as defined by the ThrottleInterval parameter must elapse before the alarm is generated for the same signature with the same SummaryKey settings.

• Summarize Alarms are consolidated for the address set specified in the SummaryKey parameter.

• GlobalSummarize Alarms are consolidated for all address combinations.

Automatic Alarm Summarization with the ChokeThreshold Signature Engine Parameter

We saw in the previous section that there are three levels of alarm summarization. FireAll is the baseline and does not summarize. Then we have FireOnce , Summarize , and GlobalSummarize . Automatic alarm summarization allows the signature to automatically move up to the next level of summarization once the number of alarms exceeds the level set in the ChokeThreshold parameter. If the number of alarms then exceeds twice the level set in the ChokeThreshold parameter, the signature again moves up to the next level of summarization (unless it is already at GlobalSummarize , the highest level of summarization).

StorageKey and SummaryKey Parameters

The StorageKey and SummaryKey parameters are similar; they specify which address to use for the counting algorithm. StorageKey specifies which address to view for pre-alarm counters, whereas SummaryKey specifies which address to view for post-alarm counters.

The StorageKey parameter specifies where "persistent cross-packet data" (in other words, stateful and nonatomic data) for the signature is stored; you shouldn't change this parameter even for custom signatures. The SummaryKey allows you to count the number of occurrences of a signature firing on various address sets.

The terminology used by both StorageKey and SummaryKey is as follows :

• AaBb The sequence to define the source address and port and destination address and port.

• A Designates source address.

• a Designates source port.

• B Designates destination address.

• b Designates destination port.

• x An x is used to designate that the value for the position that the x occupies is unimportant.

Table 9.5 shows examples of how you can define the StorageKey and SummaryKey parameters.

Table 9.5. Examples of StorageKey and SummaryKey Notation

Value	Description
Axxx	Only the source address is examined.
AxBx	Only the source and destination addresses are examined; source and destination ports are not examined.
xxBx	Only the destination address is examined; source address and port and destination port are not examined.
AaBb	Source and destination sockets are examined.

The FireOnce and Summarize levels for the AlarmThrottle parameter use the SummaryKey value, together with the ThrottleInterval value, to determine how alarms will be summarized.

Atomic Signature Engines

Atomic engines fire an alarm based on single-packet analysis. Because they are stateless and don't store persistent data across packets, atomic engines use the StorageKey xxxx . Table 9.6 lists and describes atomic signature engines. Subsections that follow discuss these engines in more detail.

Table 9.6. Atomic Signature Engines

Engine Name	Engine Description
Atomic.ARP	Used for basic Layer 2 Address Resolution Protocol (ARP) signatures and more advanced ARP spoof tools such as dsniff.
Atomic.ICMP	Used to examine Layer 3 ICMP packets; it has no required parameters and can be used to create an "any ICMP packet" signature.
Atomic.IPOptions	Used to examine Layer 3 IP packets with a specified IP option.
Atomic.L3.IP	Used to examine Layer 3 packets; it has no required parameters and can be used to create an "any IP packet" signature.
Atomic.TCP	Used to examine Layer 4 TCP packets.
Atomic.UDP	Used to examine Layer 4 User Datagram Protocol (UDP) packets.

Atomic.ARP Engine Parameter Examples

The Atomic.ARP signature engines detect Layer 2 ARP attacks. The key parameters are listed in Table 9.7.

Table 9.7. Atomic.ARP Key Parameters

Parameter	Value	Attribute	Description
ArpOperation	0255	Not protected Not required	Defines the operation code that the signature examines.
RequestInBalance	065,535	Not protected Not required	Defines the number of requests for an IP address against the replies. Once the number of requests exceeds the replies by x, the signature fires.

Atomic.ICMP Engine Parameter Examples

The Atomic.ICMP signature engines examine Layer 3 ICMP attacks; with no required parameters, this signature engine is useful for creating a custom ICMP signature. Key parameters of the Atomic.ICMP signature engine appear in Table 9.8.

Table 9.8. Atomic.ICMP Key Parameters

Parameter	Value	Attribute	Description
IcmpCode	0255	Not protected Not required	Defines the code value to match in the ICMP header code field
IcmpID	065,535	Not protected Not required	Defines the identification value to match the ICMP header identifier field
IcmpSeq	065,535	Not protected Not required	Defines the sequence value of the ICMP header sequence field
IcmpType	0255	Not protected Not required	Defines the type value to match in the ICMP header type field

Atomic.IPOptions Engine Parameter Examples

The Atomic.IPOptions signature engines detect Layer 3 attacks specifying an IP option. The parameters for this signature engine appear in Table 9.9.

Table 9.9. Atomic.IPOptions Key Parameters

Parameter	Value	Attribute	Description
HasBadOption	True False	Not protected Not required	Defines whether the list of IP options are malformed
IPOption	0255	Not protected Not required	Defines the IP option code

Atomic.L3.IP Engine Parameter Examples

The Atomic.L3.IP signature engine detects a broad range of attacks occurring at Layer 3, including exploitation of nonauthenticated routing protocols such as Routing Information Protocol (RIP). The key Atomic.L3.IP parameters appear in Table 9.10.

Table 9.10. Atomic.L3.IP Key Parameters

Parameter	Value	Attribute	Description
MaxProto	0255	Not protected Not required	Triggers an alarm if the IP protocol value is greater than this value
MinProto	0255	Not protected Not required	Triggers an alarm if the IP protocol value is less than this value
IsRFC1918	True False	Not protected Not required	Defines whether the packet is from a private RFC 1918 address

Use the Atomic.L3.IP signature engine to create custom signatures to examine traffic from routing protocols such as RIP, Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), and Enhanced Interior Gateway Routing Protocol (EIGRP).

Atomic.TCP Engine Parameter Examples

As the name of the signature engine suggests, the Atomic.TCP engine detects attacks involving a single TCP packet. The parameters appear in Table 9.11.

Table 9.11. Atomic.TCP Key Parameters

Parameter	Value	Attribute	Description
DstPort	065,535	Not protected Not required	Defines the destination port to match in the TCP header
Mask	FIN SYN RST PUSH ACK URG ZERO	Not protected Required	Defines the mask used in TCP flag comparisons
SinglePacketRegex	< string >	Not protected Not required	Defines the string to search for in a single TCP packet
SrcPort	165,535	Not protected Not required	Defines a single source port to match in the TCP header
TcpFlags	FIN SYN RST PUSH ACK URG ZERO	Not protected Required	Defines the TCP flags to match when masked by the mask

The Mask and TCPFlags parameters specify what type of TCP traffic you want the signature to match. Use the Mask parameter to specify the flags of interest and the TCPFlags parameter to specify which flag will fire the signature. Any flags that you don't include in the mask cannot be used to trigger the signature.

You can use the Atomic.TCP signature engine and its SinglePacketRegex parameter to create a custom signature that searches for failed login attempts using commonly used passwords.

Atomic.UDP Engine Parameter Examples

The Atomic.UDP engine examines Layer 4 UDP packets. Because UDP is a connectionless protocol, there are no masks or flags to define. The key parameters appear in Table 9.12.

Table 9.12. Atomic.UDP Key Parameters

Parameter	Value	Attribute	Description
DstPort	065,535	Not protected Not required	Defines a single destination port to match in the UDP header
MinUDPLength	065,535	Not protected Not required	Defines the minimum length of the UDP packet, after which the signature fires

Flood Signature Engines

Flood engines analyze traffic directed at one host from many (Flood.Host.*) or all the aggregate traffic on a segment (Flood.Net).

The Flood.Host signature engines detect many-to-one (or "n to 1") attacks and attach a packets-per-second (PPS) rate counter to the single destination address.

The Flood.Net signature engine detects attacks from many hosts to many targets (many-to-many, or "n to n") and counts the packet rate seen by the engine on a virtual Sensor basis. Because of the many-to-many nature of the signature engine, no address is used for counting; sampling is also performed on a per-second basis. Table 9.13 lists these flood signature engines; the subsections that follow this table discuss the flood signature engines in more detail.

Table 9.13. The Flood Signature Engines

Engine Name	Engine Description
Flood.Host.ICMP	Examines an excessive number of ICMP packets sent to a target host
Flood.Host.UDP	Examines an excessive number of UDP packets sent to a target host
Flood.Net	Examines an excessive number of packets sent to a network segment

Flood.Host.ICMP Engine Parameter Examples

The Flood.Host.ICMP detects attacks where a single host is the recipient of an ICMP attack from one or many sources. Table 9.14 lists the parameters for the Flood.Host.ICMP signature engine.

Table 9.14. Flood.Host.ICMP Key Parameters

Parameter	Value	Attribute	Description
IcmpType	0255	Not protected Not required	Defines the type value to match in the ICMP header TYPE field
Rate	02,147,483,647	Not protected Not required	Defines the maximum number of ICMP packets with the specified type allowed per second

Flood.Host.UDP Engine Parameter Examples

Like the Flood.Host.ICMP signature engine, the Flood.Host.UDP detects an attack where a single host is the target of a UDP-based attack from one or more source addresses. The key parameters for the Flood.Host.UDP engine parameters appear in Table 9.15.

Table 9.15. Flood.Host.UDP Key Parameters

Parameter	Value	Attribute	Description
ExcludeDst1	065,535	Not protected Not required	Defines the destination port to exclude from flood counting
ExcludeDst2	065,535	Not protected Not required	Defines the destination port to exclude from flood counting
Rate	02,147,483,647	Not protected Required	Defines the maximum number of UDP packets with the specified type allowed per second

Flood.Net Engine Parameter Examples

The Flood.Net signature engine generates an alarm when the PPS exceeds the value designated in the Rate parameter. There are no addresses because it is used to detect many-to-many attacks with multiple sources attacking an entire network segment. It's worth noting that if your rate parameter is set too low, the Flood.Net signature engine might cause a high number of false positives. The key Flood.Net parameters appear in Table 9.16.

Table 9.16. Flood.Net Key Parameters

Parameter	Value	Attribute	Description
Gap	02,147,483,647	Not protected Not required	Defines an interval, in seconds, at which the peak count is reset to 0 if the matched traffic remains below the defined rate
Peaks	02,147,483,647	Not protected Not required	Defines the maximum period of time, above the specified rate, necessary to trigger the signature
Rate	02,147,483,647	Not protected Not required	The maximum PPS required to trigger a flood

Service Signature Engines

Rather than defend against the more lively DoS attacks for which the Flood signature engines are responsible, the Service signature engines, listed in Table 9.17, perform a much more sublime task of protocol decode analysis at Layers 5, 6, and 7 to detect attacks between two hosts.

Table 9.17. The Service Signature Engines

Engine Name	Engine Description
Service.DNS	Examines TCP and UDP domain name service (DNS) packets
Service.FTP	Examines File Transfer Protocol (FTP) traffic
Service.Generic	Emergency response engine that supplements the String and State engines
Service.HTTP	Examines Hypertext Transfer Protocol (HTTP) traffic for string-based pattern matching
Service.IDENT	Examines TCP port 113 traffic
Service.MSSQL	Examines traffic used by Microsoft SQL
Service.NTP	Examines Network Time Protocol (NTP) traffic
Service.RPC	Examines Remote Procedure Call (RPC) traffic
Service.SMB	Examines Server Message Block (SMB) traffic
Service.SMTP	Examines Simple Mail Transfer Protocol (SMTP) traffic
Service.SNMP	Examines Simple Network Management Protocol (SNMP) traffic
Service.SSH	Examines Secure Shell (SSH) traffic
Service.Syslog	Examines syslog traffic

Remember that Service signature engines perform traffic analysis at Layers 5, 6, and 7.

Service.DNS Engine Parameter Examples

The Service.DNS signature engine detects DNS attacks using both TCP and UDP packets. Its key parameters appear in Table 9.18.

Table 9.18. Service.DNS Key Parameters

Parameter	Value	Attribute	Description
QuerySrcPort53	True False	Not protected Not required	Determines whether the DNS packet source port is port 53
QueryValue	True False	Not protected Not required	Determines whether the DNS query will be a query or a response

Service.FTP Engine Parameter Examples

To detect attacks based on the FTP protocol, you can use the Service.FTP signature engine. Its key parameters are described in Table 9.19.

Table 9.19. Service.FTP Key Parameters

Parameter	Value	Attribute	Description
ServicePorts	< set list >	Not protected Not required	Defines a list of ports where the target service may reside
isPASV	True False	Not protected Not required	Determines whether a PASV port spoof was detected

Service.Generic Engine Parameter Examples

The Service.Generic signature engine is an emergency response engine used to augment the String and State signature engines. Its key parameters appear in Table 9.20.

Table 9.20. Service.Generic Key Parameters

Parameter	Value	Attribute	Description
DstPort	065,535	Not protected Not required	The destination port of interest for this signature.
IntermediateInstructions	< string >	Protected Not required	Assembly or machine code in string form. This field is for expert use only.

Service.HTTP Engine Parameter Examples

The Service.HTTP signature engine, with its Regex parameters, uses string-based pattern matching to detect HTTP attacks. The String.HTTP parameters appear in Table 9.21.

Table 9.21. Service.HTTP Key Parameters

Parameter	Value	Attribute	Description
UriRegex	< string >	Protected Not required	Examines the Uniform Resource Identifier (URI) section of the HTTP request to match the Regex
RequestRegex	< string >	Protected Not required	Examines the entire HTTP request to match the Regex
Deobfuscate	True False	Not protected Not required	Determines whether to apply anti-evasive HTTP deobfuscation before examination

Service.IDENT Engine Parameter Examples

Service.IDENT examines traffic passing through TCP port 113. Table 9.22 describes its key parameters.

Table 9.22. Service.IDENT Key Parameters

Parameter	Value	Attribute	Description
MaxBytes	065,535	Not protected Not required	Defines the maximum amount of data in the payload
hasBadPort	True False	Not protected Not required	Defines whether a bad port number will cause the signature to trigger

Service.MSSQL Engine Parameter Examples

If you want to capture and analyze Microsoft SQL traffic involving usernames and passwords, use the Service.MSSQL signature engine. Table 9.23 lists the parameters for the Service.MSSQL signature engine.

Table 9.23. Service.MSSQL Key Parameters

Parameter	Value	Attribute	Description
SqlUsername	< string >	Not protected Not required	Defines the username to search for
PasswordPresent	True False	Not protected Not required	Defines whether or not a password was used for an MSSQL login

Service.NTP Engine Parameter Examples

To detect attacks intended to take advantage of NTP weaknesses, use the Service.NTP signature engine. Its parameters appear in Table 9.24.

Table 9.24. Service.NTP Key Parameters

Parameter	Value	Attribute	Description
Mode	07	Not protected Not required	Defines the mode of operation of the NTP packets
IsInvalidDataPacket	True False	Not protected Not required	Checks for incorrect NTP data packet structure

Service.RPC Engine Parameter Examples

The Service.RPC signature engine can fully decode an anti-evasive strategy and can handle fragmented messages, one message across multiple packets, or several messages in a single packet (batch messages). The RPC port mapper operates on port 111. Most RPC messages can be on ports 550 and above. RPC sweeps are similar to TCP sweeps; however, RPC sweeps only count unique ports when a valid RPC message is sent. Refer to Table 9.25 for the parameters of the Service.RPC signature engine.

Table 9.25. Service.RPC Key Parameters

Parameter	Value	Attribute	Description
RpcProgram	099,999	Not protected Not required	Defines the RPC program number to match in the RPC message
ExcludeDst2	065,535	Not protected Not required	Defines the destination port to exclude from flood counting
Rate	02,147,483,647	Not protected Required	Defines the maximum number of UDP packets with the specified type allowed per second

Service.SMB Engine Parameter Examples

The Service.SMB signature engine decodes the Server Message Block (SMB) protocol and includes the following built-in signatures:

3303	Login successful with guest privileges
3304	Null login attempt
3305	Windows 9X password file access
3306	Remote Registry access attempt
3307	RedButton reconnaissance
3308	REMOTE isarpc service access attempt
3309	REMOTE srvsvc service access attempt
6255	SMB login failure

The list of signatures changes with each signature update. This list applies to the 4.0 S37 release.

The parameters for the Service.SMB signature engine appear in Table 9.26.

Table 9.26. Service.SMB Key Parameters

Parameter	Value	Attribute	Description
AccountName	< string >	Not protected Not required	Defines the account name to watch
Filename	< string >	Not protected Not required	Defines the filename that will cause the signature to trigger when accessed

Service.SNMP Engine Parameter Examples

To accelerate protocol decode and to reduce storage space, CommunityName strings are converted into an integer-sized hash. The CommunityName decoded from a captured packet is also converted to an integer- sized hash. Each CommunityName string should produce a near-unique integer hash, which is then used to determine whether a match exists or whether a brute-force attack was attempted. Table 9.27 lists the key parameters for the Service.SNMP signature engine.

Table 9.27. Service.SNMP Key Parameters

Parameter	Value	Attribute	Description
BruteForceCount	132	Not protected Not required	Defines the number of unique community strings before the signature fires
IsBruteForce	True False	Protected Not required	Determines whether the signature will use the BruteForceCount parameter
IsValidPacket	True False	Protected Required	The token that signifies an SNMP protocol violation

Service.SSH Engine Parameter Examples

The Service.SSH signature engine examines traffic directed at the SSH port 22; because all traffic is encrypted after the setup phase, the engine only analyzes fields during the setup. There are two default SSH signatures, both of which can be tuned . However, it's worth noting that you cannot add new SSH signatures. The Service.SSH parameters appear in Table 9.28.

Table 9.28. Service.SSH Key Parameters

Parameter	Value	Attribute	Description
KeyLength	065,535	Not protected Not required	Defines the Rivest Shamir Adleman (RSA) key length
UserLength	065,535	Not protected Not required	Defines the maximum length of the username

You cannot create new SSH signatures using the Service.SSH signature engine.

Service.Syslog Engine Parameter Examples

Finally, the Service.Syslog signature engine analyzes traffic destined for the syslog UDP port 514 and handles the contents of syslog data by inspecting access control list (ACL) formats. If the contents of the syslog match the predetermined format for a Cisco ACL policy violation message, the contents of the syslog are used to generate an alarm. Syslog data not matching the ACL format is ignored. Key parameters for the Service.Syslog signature engine are described in Table 9.29.

Table 9.29. Service.Syslog Key Parameters

Parameter	Value	Attribute	Description
AclDataSource	< string >	Not protected Not required	A comma-separated list of IP addresses that are valid sources of ACL violations
AclFilterName	< string >	Not protected Not required	The name of the ACL filter

State Signature Engines

Protocols such as the Cisco Login and SMTP have different states, limiting the effectiveness of atomic, packet-level pattern-matching based signature engines. Cisco has developed the concept of state machines to provide the capability of searching for specific patterns at various states within the protocol.

The state machine consists of a starting state and a list of valid state machine transitions . A state machine can at a given point in time operate on input to progress from one state to another and cause an action or output to occur. State machines describe a specific event that causes an output or alarm. Cisco IDS supports three state machine engines, as listed in Table 9.30; these engines are described in subsections that follow.

Table 9.30. The State Machine Signature Engines

Engine Name	Engine Description
State.String.Ciscologin	Examines Cisco login attempts
State.String.LPRformat	Examines the line print (LPR) protocol
State.String.SMTP	Checks for specific patterns at different states within the SMTP protocol

State.String Engine Parameter Examples

All state machine engines have the same parameters of the State.String signature engine, as shown in Table 9.31.

Table 9.31. State.String Key Parameters

Parameter	Value	Attribute	Description
Direction	ToService FromService	Protected Required	Defines whether the Sensor listens to traffic destined to or from the service port, or possibly both
RegexString	< string >	Protected Required	Defines the Regex pattern
StateName	CiscoLogin LPRFormatString	Protected Required	Defines the name of the state machine to restrict the match of the Regex string

State.String.Ciscologin Transitions

Table 9.32 shows the State.String.Ciscologin state machine transitions.

Table 9.32. State.String.Ciscologin Transitions

Regex String	Required State	Next State	Direction
UserAccessVerification	Start	CiscoDevice	FromService
CiscoSystemsConsole	Start	CiscoDevice	FromService
password[:]	CiscoDevice	PassPrompt	FromService
\x03	PassPrompt	ControlC	ToService
(enable)	ControlC	EnableBypass	FromService
\x03[\x00-\xFF]	ControlC	PassPrompt	ToService

State.String.LPRformat Transitions

Refer to Table 9.33 for the State.String.LPRformat transitions.

Table 9.33. State.String.LPRformat Transitions

Regex String	Required State	Next State	Direction
[1-9]	Start	Abort	ToService
%	Start	CiscoDevice	ToService
[\x0a\x0d]	FormatChar	Abort	ToService

State.String.SMTP Transitions

Finally, Table 9.34 lists the State.String.SMTP transitions.

Table 9.34. State.String.SMTP Transitions

Regex String	Required State	Next State	Direction
[\r\n[250]]	Start	SmtpCommands	FromService
220[][^\r\n[\x7f-\xff]*SNMP	Start	SmtpCommands	FromService
(HEEH)LO	Start	SmtpCommands	ToService
[\r\n](235220.*TLS)	Start	Abort	FromService
[\r\n](235220.*TLS)	SmtpCommands	Abort	FromService
[Dd][Aa][Tt][Aa][Bb][Dd][Aa][Tt]	SmtpCommands	MailHeader	ToService
[\r\n]354	SmtpCommands	MailHeader	FromService
[\r\n][.][\r\n]	MailHeader	SmtpCommands	ToService
[\r\n][2][0-9][0-9][]	MailHeader	SmtpCommands	FromService
([\r][\n][\n] [\r]){2}	MailHeader	MailBody	ToService
[\r\n][.][\r\n]	MailBody	SmtpCommands	ToService
[\r\n][2][0-9][0-9][ ]	MailBody	SmtpCommands	FromService

String Signature Engines

The String signature engines support Regex pattern matching and alarm functionality for ICMP, UDP, and TCP, as shown in Table 9.35.

Table 9.35. String Signature Engines

Engine Name	Engine Description
String.ICMP	Examines ICMP packets for a string pattern
String.TCP	Examines TCP packets for a string pattern
String.UDP	Examines UDP packets for a string pattern

String Signature Engine Parameter Examples

Table 9.36 lists the key parameters for all three String signature engines, which share the same parameters.

Table 9.36. Key Parameters for All Three String Signature Engines

Parameter	Value	Attribute	Description
Direction	ToService FromService	Protected Not required	Defines whether examined traffic is traveling to or from the service port
RegexString	< string >	Protected Not required	Defines the string pattern to match the packet

Sweep Signature Engines

The Sweep signature engines detect attacks where one host or system makes multiple connections to other hosts or ports. Although these signature engines look similar to the Flood signature engines, they are used for detecting reconnaissance attacks rather than the DoS attacks that Flood signature engines detect. The Sweep signature engines appear in Table 9.37.

Table 9.37. The Sweep Signature Engines

Engine Name	Engine Description
Sweep.Host.ICMP	Single source scanning multiple network addresses using ICMP packets
Sweep.Host.TCP	Single source scanning multiple network addresses using TCP packets
Sweep.Port.TCP	TCP connections to multiple destination ports between two network addresses
Sweep.Port.UDP	UDP connections to multiple destination ports between two network addresses
Sweep.OTHER	Odd sweeps and scans , including nmap
Sweep.Multi	UDP and TCP combined port sweeps

Sweep signature engines detect reconnaissance attacks, whereas Flood signature engines detect DoS attacks.

Sweep.Host.ICMP Signature Engine Parameter Examples

The Sweep.Host.ICMP signature engine detects an attack where a single host is scanning multiple network addresses using ICMP packets. Table 9.38 lists the Sweep.Host.ICMP key parameters.

Table 9.38. Sweep.Host.ICMP Key Parameters

Parameter	Value	Attribute	Description
Direction	ToService FromService	Protected Not required	Defines whether examined traffic is traveling to or from the service port
RegexString	< string >	Protected Not Protected	Defines the string pattern to match the packet

The Sweep engine's alarm conditions depend on the count of the Unique parameter, which defines the threshold that triggers firing of the alarm when the number of hosts or ports on the set address detected exceeds the setting for the specified time period.

The master signature engine parameter ResetAfterIdle is used by the Sweep signature engines to reset the value of the Unique counter, which is cleared when no traffic has passed between the hosts for the duration specified by the ResetAfterIdle parameter.

The set address is determined by the value of the Summary key master parameter.

Sweep.Host.TCP Engine Parameter Examples

The Sweep.Host.TCP signature engine detects attacks where a single host is attacking multiple network addresses, using TCP packets. Again, although it might look similar to a Flood signature engine, the Sweep signature engines search for a range of scanned ports, as defined by the PortRange local parameter, rather than PPS as defined by the Rate local parameter of the Flood signature engines. Table 9.39 lists the Sweep.Host.TCP key parameters.

Table 9.39. Sweep.Host.TCP Key Parameters

Parameter	Value	Attribute	Description
Mask	FIN SYN RST PSH ACK URG ZERO	Not protected Required	Defines the mask used in TcpFlags comparisons
TcpFlags	FIN SYN RST PSH ACK URG ZERO	Not protected Required	Defines the TCP flags to match as defined by the mask
Unique	2-40	Not protected Required	Defines the number of unique connections allowed

Sweep.Port.TCP Engine Parameter Examples

The Sweep.Port.TCP signature engine detects multiple TCP connections to multiple ports between two network addresses. Table 9.40 lists the Sweep.Port.TCP key parameters.

Table 9.40. Sweep.Port.TCP Key Parameters

Parameter	Value	Attribute	Description
Mask	FIN SYN RST PSH ACK URG ZERO	Not protected Required	Defines the mask used in TcpFlags comparisons
PortRange	1Low 2High 0All	Not protected Required	Defines the port range to examine
TcpFlags	FIN SYN RST PSH ACK URG ZERO	Not protected Required	Defines the TCP flags to match as defined by the mask
Unique	240	Not protected Required	Defines the maximum number of connections allowed

The allowed values for the PortRange parameter are as follows:

• All ports are scanned.

• 1 Low ports, from 11024, are scanned.

• 2 High ports, from 102565,535, are scanned.

A PortRange value of for the Sweep.Port.TCP signature engine means that all ports are scanned.

Sweep.Port.UDP Engine Parameter Examples

The Sweep.Port.UDP signature engine detects UDP connections to many destination ports between two network addresses. With the PortsInclude parameter, you can specify a comma-separated list of the UDP ports used by the signature to search for unique connections; only the ports in this list are analyzed by the signature engine. Table 9.41 lists the Sweep.Port.UDP key parameters.

Table 9.41. Sweep.Port.UDP Key Parameters

Parameter	Value	Attribute	Description
PortsInclude	< set list >	Not protected Not required	Defines the list of ports or port ranges to examine
Unique	240	Not protected Required	Defines the maximum number of unique port connections allowed

Sweep.OTHER.TCP Engine Parameter Examples

If you want to detect sweep attacks such as nmap and Queso, which use a mixture of TCP packets with different flags set, the Sweep.OTHER.TCP engine allows you to designate four different TcpFlag combinations. Unlike the other TCP-based engines, the Sweep.OTHER.TCP engine does not use masks; instead, it searches for the flag combinations set in the TcpFlagsx parameters and the rest are ignored. Table 9.42 lists the Sweep.OTHER.TCP key parameters.

Table 9.42. Sweep.OTHER.TCP Key Parameters

Parameter	Value	Attribute	Description
PortRange	< set list >	Not protected Not required	Defines the list of ports or port ranges to examine
TcpFlags1	FIN SYN RST PSH ACK URG ZERO	Not protected Required	Defines the TCP flags to match
TcpFlags2	FIN SYN RST PSH ACK URG ZERO	Not protected Not required	Defines the TCP flags to match
TcpFlags3	FIN SYN RST PSH ACK URG ZERO	Not protected Not required	Defines the TCP flags to match
TcpFlags4	FIN SYN RST PSH ACK URG ZERO	Not protected Not required	Defines the TCP flags to match

Sweep.Multi Engine Parameter Examples

You can detect cross-protocol sweeps such as the SATAN scanning tool with the Sweep.Multi signature engine, which detects sweeps using both TCP and UDP ports. Table 9.43 lists the Sweep.Multi key parameters.

Table 9.43. Sweep.Multi Key Parameters

Parameter	Value	Attribute	Description
TcpInterest	1SATAN Normal 2SATAN Heavy	Not protected Not required	Designates the predefined TCP ports of interest
UdpInterest	1SATAN Normal 2SATAN Heavy	Not protected Not required	Designates the predefined UDP ports of interest
UniqueTcpPorts	240	Not protected Not required	Defines the number of unique TCP connections allowed
UniqueUdpPorts	240	Not protected Not required	Defines the number of unique UDP connections allowed

Miscellaneous Signature Engines

The last group of signature engines we cover includes those signature engines that handle nonstandard protocol signatures and as such don't fall into the other engine protocol decodes. This group includes Trojan signature engines, Traffic.ICMP signature engines, and the OTHER signature engines, as discussed in subsections that follow.

Trojan Signature Engines

You are most likely aware that Trojans can be used to gain "backdoor" access to your systems. Trojans can make their way into your system by hiding themselves within downloadable files from the Internet, for example, and subsequently cause a great deal of damage. The Trojan signature engines in Table 9.44 are designed to prevent Trojan programs from finding their way into the dark corners of your network.

Table 9.44. Trojan Signature Engines

Engine Name	Engine Description
Trojan.BO2K	Examines UDP and TCP traffic for nonstandard Back Orifice traffic
Trojan.TFN2K	Examines UDP, TCP, and ICMP traffic for irregular traffic patterns and corrupted headers
Trojan.UDP	Examines UDP traffic for Trojan attacks

BO2K is the Windows backdoor Trojan that runs over UDP and TCP using basic XOR encryption. The Trojan.UDP signature engine detects the original UDP-based Back Orifice (BO) Trojan that BO2K was based on, as well as the UDP modes of BO2K.

The TFN2K Trojan is the predecessor to the original Tribal Flood Network (TFN) Trojan, and is a DDoS agent that uses otherwise innocent hosts, aptly called zombies, to launch a coordinated attack involving hundreds or even thousands of other zombies . Although TFN2K randomizes the information in its packet headers, some distinguishing characteristics can define the signature, such as an incorrect Layer 3 checksum or remnants of BASE-64 encoding at the end of each packet.

There are no specific parameters for Trojan engines, which you can tune using the master signature engine parameters. However, you cannot use the Trojan engines to create custom signatures.

Remember that you cannot use the Trojan signature engines to create custom signatures.

Traffic.ICMP Signature Engine Parameter Examples

There is only one Traffic signature engine, the Traffic.ICMP engine, which is triggered by deviant use of the ICMP protocol. Attacks that exploit ICMP include the TFN and TFN2K attacks that we saw in the previous section, as well as Stacheldraht and Loki.

The Loki attack is another backdoor Trojan. Once a host is infected, Loki uses it to create an ICMP tunnel, which can traverse a firewall that allows ICMP traffic to pass. The host will be used to package malicious code inside the ICMP replies, which can then be sent to their target system. The Traffic.ICMP signature detects imbalances in ICMP requests and replies and basic IcmpCode and payload discriminators.

Stacheldraht and TFN are used to launch DDoS attacks similar to TFN2K, except that Stacheldraht and TFN use only ICMP and not TCP or UDP.

As with the Trojan signature engines, you cannot use the Traffic.ICMP signature engine to create custom signatures. Table 9.45 lists the Traffic.ICMP signature engine parameters.

Table 9.45. Traffic.ICMP Signature Engine Parameters

Parameter	Value	Attribute	Description
isLOKI	True False	Not protected Not required	Defines whether the signature is looking for the original Loki attack.
isModLOKI	True False	Not protected Not required	Defines whether the signature is looking for a modified Loki attack.
ReplyRatio	number	Not protected Not required	The difference between the number of ICMP replies and requests; the signature will fire when the difference reaches this number.
WantRequest	Any True False	Not protected Not required	Requires an ECHO REQUEST to be seenbefore the alarm is fired. True There must be a request to fire an alarm. False Cannot have a request to fire an alarm. Any Don't care.

The Signature Engine OTHER

Signatures that don't fit into a signature engine category are handled by the OTHER signature engine. These signatures include sensor status alarms indicating changes in the flow of traffic to the sensor. Again, you cannot create custom signature engines from the OTHER signature engine. Table 9.46 lists examples of parameters for the OTHER signature engine.

Table 9.46. The Signature Engine OTHER Parameter Examples

Parameter	Value	Attribute	Description
HijackMaxOldAck	02,147,483,647	Not protected Not required	Defines a maximum number of old dateless client-to-server ACKs (acknowledgments) before a hijack is triggered
SynFloodMaxEmbryonic	02,147,483,647	Not protected Not required	Defines the maximum number of allowed simultaneous embryonic connections to any service
TrafficFlowTimeout	02,147,483,647	Not protected Not required	Defines the number of seconds that must pass with no traffic to fire an alarm

[ LiB ]