[ 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.
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 |
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.
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. |
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.
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. |
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.
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.
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.
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).
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.
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 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.
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. |
The Atomic.ARP signature engines detect Layer 2 ARP attacks. The key parameters are listed in Table 9.7.
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. |
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.
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 |
The Atomic.IPOptions signature engines detect Layer 3 attacks specifying an IP option. The parameters for this signature engine appear in Table 9.9.
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 |
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.
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). |
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.
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. |
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.
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 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.
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 |
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.
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 |
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.
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 |
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.
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 |
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.
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. |
The Service.DNS signature engine detects DNS attacks using both TCP and UDP packets. Its key parameters appear in Table 9.18.
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 |
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.
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 |
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.
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. |
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.
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 examines traffic passing through TCP port 113. Table 9.22 describes its 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 |
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.
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 |
To detect attacks intended to take advantage of NTP weaknesses, use the Service.NTP signature engine. Its parameters appear in Table 9.24.
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 |
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.
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 |
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.
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 |
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.
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 |
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.
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. |
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.
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 |
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.
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 |
All state machine engines have the same parameters of the State.String signature engine, as shown in Table 9.31.
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 |
Table 9.32 shows the State.String.Ciscologin state machine 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 |
Refer to Table 9.33 for the State.String.LPRformat transitions.
Regex String | Required State | Next State | Direction |
---|---|---|---|
[1-9] | Start | Abort | ToService |
% | Start | CiscoDevice | ToService |
[\x0a\x0d] | FormatChar | Abort | ToService |
Finally, Table 9.34 lists the 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 |
The String signature engines support Regex pattern matching and alarm functionality for ICMP, UDP, and TCP, as shown in Table 9.35.
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 |
Table 9.36 lists the key parameters for all three String signature engines, which share the same 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 required | Defines the string pattern to match the packet |
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.
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. |
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.
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. |
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.
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 |
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.
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. |
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.
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 |
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.
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 |
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.
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 |
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.
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.
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. |
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.
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. |
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.
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 ] |