Every standard text rule and shared object rule has a rule header containing parameters and arguments. The following illustrates parts of a rule header:

The following table describes each part of the rule header shown above.

Note	The previous example uses default variables, as do most intrusion rules.

As you construct a standard text rule, you can include contextual information that describes the vulnerability that the rule detects in exploit attempts. You can also include external references to vulnerability databases and define the priority that the event holds in your organization. When analysts see the event, they then have information about the priority, exploit, and known mitigation readily available.

Message

You can specify meaningful text that appears as a message when the rule triggers. The message gives immediate insight into the nature of the vulnerability that the rule detects attempts to exploit. You can use any printable standard ASCII characters except curly braces ({}). The system strips quotes that completely surround the message.

Tip	You must specify a rule message. Also, the message cannot consist of white space only, one or more quotation marks only, one or more apostrophes only, or any combination of just white space, quotation marks, or apostrophes.

To define the event message in the intrusion rules editor, you enter the event message in the Message field.

Classification

For each rule, you can specify an attack classification that appears in the packet display of the event. The following table lists the name and number for each classification.

Custom Classification

If you want more customized content for the packet display description of the events generated by a rule you define, you can create a custom classification.

Custom Priority

By default, the priority of a rule derives from the event classification for the rule. However, you can override the classification priority for a rule by adding the priority keyword to the rule and selecting a high, medium, or low priority. For example, to assign a high priority for a rule that detects web application attacks, add the priority keyword to the rule and select high as the priority.

Custom Reference

You can use the reference keyword to add references to external web sites and additional information about the event. Adding a reference provides analysts with an immediately available resource to help them identify why the packet triggered a rule. The following table lists some of the external systems that can provide data on known exploits and attacks.

bugtraq

8550

cve

2020-9607

mcafee

98574

url

www.example.com?exploit=14

msb

MS11-082

nessus

10039

secure-url

intranet/exploits/exploit=14

You specify a reference by entering a reference value, as follows:

id_system,id

where id_system is the system being used as a prefix, and id is the CVE ID number, Arachnids ID, or URL (without http://).

For example, to specify the Adobe Acrobat and Reader issue documented in CVE-2020-9607, enter the value:

cve,2020-9607

Note the following when adding references to a rule:

• Do not use a space after the comma.

• Do not use uppercase letters in the system ID.

Your filter can include special keywords and their arguments, character strings, and literal character strings in quotes, with spaces separating multiple filter conditions. A filter cannot include regular expressions, wild card characters, or any special operator such as a negation character (!), a greater than symbol (>), less than symbol (<), and so on.

All keywords, keyword arguments, and character strings are case-insensitive. Except for the gid and sid keywords, all arguments and strings are treated as partial strings. Arguments for gid and sid return only exact matches.

You can expand a folder on the original, unfiltered page and the folder remains expanded when the subsequent filter returns matches in that folder. This can be useful when the rule you want to find is in a folder that contains a large number of rules.

You cannot constrain a filter with a subsequent filter. Any filter you enter searches the entire rules database and returns all matching rules. When you enter a filter while the page still displays the result of a previous filter, the page clears and returns the result of the new filter instead.

You can use the same features with rules in a filtered or unfiltered list. For example, you can edit rules in a filtered or unfiltered list on the intrusion rules editor page. You can also use any of the options in the context menu for the page.

Tip	Filtering may take significantly longer when the combined total of rules in all sub-groups is large because rules appear in multiple categories, even when the total number of unique rules is much smaller.

Each rule filter can include one or more keywords in the format:

keyword:argument

where keyword is one of the keywords in the following table and argument is a single, case-insensitive, alphanumeric string to search for in the specific field or fields relevant to the keyword.

Arguments for all keywords except gid and sid are treated as partial strings. For example, the argument 123 returns "12345", "41235", "45123", and so on. The arguments for gid and sid return only exact matches; for example, sid:3080 returns only SID 3080.

Tip	You can search for a partial SID by filtering with one or more character strings.

The following table describes the specific filtering keywords and arguments you can use to filter rules.

arachnids

arachnids:181

bugtraq

bugtraq:2120

cve

cve:2003-0109

gid

gid:3

mcafee

mcafee:10566

msg

msg:chat

nessus

nessus:10737

ref

ref:MS03-039

sid

sid:235

url

url:faqs.org

Each rule filter can include one or more alphanumeric character strings. Character strings search the rule Message field, Snort ID (SID), and Generator ID (GID). For example, the string 123 returns the strings "Lotus123", "123mania", and so on in the rule message, and also returns SID 6123, SID 12375, and so on.

All character strings are case-insensitive and are treated as partial strings. For example, any of the strings ADMIN, admin, or Admin return "admin", "CFADMIN", "Administrator" and so on.

You can enclose character strings in quotes to return exact matches. For example, the literal string "overflow attempt" in quotes returns only that exact string, whereas a filter comprised of the two strings overflow and attempt without quotes returns "overflow attempt", "overflow multipacket attempt", "overflow with evasion attempt", and so on.

You can narrow filter results by entering any combination of keywords, character strings, or both, separated by spaces. The result includes any rule that matches all the filter conditions.

You can enter multiple filter conditions in any order. For example, each of the following filters returns the same rules:

• url:at login attempt cve:200

• login attempt cve:200 url:at

• login cve:200 attempt url:at

Use the content keyword or the protected_content keyword to specify content that you want to detect in a packet.

You should almost always follow a content or protected_content keyword by modifiers that indicate where the content should be searched for, whether the search is case sensitive, and other options.

Note that all content matches must be true for the rule to trigger an event, that is, each content match has an AND relationship with the others.

Note also that, in an inline deployment, you can set up rules that match malicious content and then replace it with your own text string of equal length.

content

When you use the content keyword, the rules engine searches the packet payload or stream for that string. For example, if you enter /bin/sh as the value for one of the content keywords, the rules engine searches the packet payload for the string /bin/sh.

Match content using either an ASCII string, hexadecimal content (binary byte code), or a combination of both. Surround hexadecimal content with pipe characters (|) in the keyword value. For example, you can mix hexadecimal content and ASCII content using something that looks like |90C8 C0FF FFFF|/bin/sh.

You can specify multiple content matches in a single rule. To do this, use additional instances of the content keyword. For each content match, you can indicate that content matches must be found in the packet payload or stream for the rule to trigger.

Caution

You may invalidate your intrusion policy if you create a rule that includes only one content keyword and that keyword has the Not option selected.

protected_content

The protected_content keyword allows you to encode your search content string before configuring the rule argument. The original rule author uses a hash function (SHA-512, SHA-256, or MD5) to encode the string before configuring the keyword.

When you use the protected_content keyword instead of the content keyword, there is no change to how the rules engine searches the packet payload or stream for that string and most of the keyword options function as expected. The following table summarizes the exceptions, where the protected_content keyword options differ from the content keyword options.

Cisco recommends that you include at least one content keyword in rules that include a protected_content keyword to ensure that the rules engine uses the fast pattern matcher, which increases processing speed and improves performance. Position the content keyword before the protected_content keyword in the rule. Note that the rules engine uses the fast pattern matcher when a rule includes at least one content keyword, regardless of whether you enable the content keyword Use Fast Pattern Matcher argument.

Caution

You may invalidate your intrusion policy if you create a rule that includes only one protected_content keyword and that keyword has the Not option selected.

You can use the replace keyword in an inline deployment to replace specified content or to replace content in SSL traffic detected by the Cisco SSL Appliance.

To use the replace keyword, construct a custom standard text rule that uses the content keyword to look for a specific string. Then use the replace keyword to specify a string to replace the content. The replace value and content value must be the same length.

Note	You cannot use the replace keyword to replace hashed content in a protected_content keyword.

Optionally, you can enclose the replacement string in quotation marks for backward compatibility with previous software versions. If you do not include quotation marks, they are added to the rule automatically so the rule is syntactically correct. To include a leading or trailing quotation mark as part of the replacement text, you must use a backslash to escape it, as shown in the following example:

"replacement text plus \"quotation\" marks""

A rule can contain multiple replace keywords, but only one per content keyword. Only the first instance of the content found by the rule is replaced.

The following are example uses of the replace keyword:

• If the system detects an incoming packet that contains an exploit, you can replace the malicious string with a harmless one. Sometimes this technique is more successful than simply dropping the offending packet. In some attack scenarios, the attacker simply resends the dropped packet until it bypasses your network defenses or floods your network. By substituting one string for another rather than dropping the packet, you may trick the attacker into believing that the attack was launched against a target that was not vulnerable.

• If you are concerned about reconnaissance attacks that try to learn whether you are running a vulnerable version of, for example, a web server, then you can detect the outgoing packet and replace the banner with your own text.

Note	Make sure that you set the rule state to Generate Events in the inline intrusion policy where you want to use the replace rule; setting the rule to Drop and Generate events would cause the packet to drop, which would prevent replacing the content.

As part of the string replacement process, the system automatically updates the packet checksums so that the destination host can receive the packet without error.

Note that you cannot use the replace keyword in combination with HTTP request message content keyword options.

The byte_jump keyword calculates the number of bytes defined in a specified byte segment, and then skips that number of bytes within the packet, either forward from the end of the specified byte segment, or from the beginning or end of the packet payload, or from a point relative to the last content match, depending on the options you specify. This is useful in packets where a specific segment of bytes describe the number of bytes included in variable data within the packet.

The following table describes the arguments required by the byte_jump keyword.

The following table describes options you can use to define how the system interprets the values you specified for the required arguments.

You can specify only one of DCE/RPC, Endian, or Number Type.

If you want to define how the byte_jump keyword calculates the bytes, you can choose from the arguments described in the following table. If you do not select a byte-ordering argument, the rules engine uses big endian byte order.

Define how the system views string data in a packet by using one of the arguments in the following table.

For example, if the values you set for byte_jump are as follows:

• Bytes = 4

• Offset = 12

• Relative enabled

• Align enabled

the rules engine calculates the number described in the four bytes that appear 13 bytes after the last successful content match, and skips ahead that number of bytes in the packet. For instance, if the four calculated bytes in a specific packet were 00 00 00 1F, the rules engine would convert this to 31. Because align is specified (which instructs the engine to move to the next 32-bit boundary), the rules engine skips ahead 32 bytes in the packet.

Alternately, if the values you set for byte_jump are as follows:

• Bytes = 4

• Offset = 12

• From Beginning enabled

• Multiplier = 2

the rules engine calculates the number described in the four bytes that appear 13 bytes after the beginning of the packet. Then, the engine multiplies that number by two to obtain the total number of bytes to skip. For instance, if the four calculated bytes in a specific packet were 00 00 00 1F, the rules engine would convert this to 31, then multiply it by two to get 62. Because From Beginning is enabled, the rules engine skips the first 63 bytes in the packet.

The byte_test keyword tests the specified byte segment against the Value argument and its operator.

The following table describes the required arguments for the byte_test keyword.

You can further define how the system uses byte_test arguments with the arguments described in the following table.

You can specify only one of DCE/RPC, Endian, or Number Type.

To define how the byte_test keyword calculates the bytes it tests, choose from the arguments in the following table. If you do not select a byte-ordering argument, the rules engine uses big endian byte order.

You can define how the system views string data in a packet by using one of the arguments in the following table.

For example, if the value for byte_test is specified as the following:

• Bytes = 4

• Operator and Value > 128

• Offset = 8

• Relative enabled

The rules engine calculates the number described in the four bytes that appear 9 bytes away from (relative to) the last successful content match, and, if the calculated number is larger than 128 bytes, the rule is triggered.

You can use the byte_extract keyword to read a specified number of bytes from a packet into a variable. You can then use the variable later in the same rule as the value for specific arguments in certain other detection keywords.

This is useful, for example, for extracting data size from packets where a specific segment of bytes describes the number of bytes included in data within the packet. For example, a specific segment of bytes might say that subsequent data is comprised of four bytes; you can extract the data size of four bytes to use as your variable value.

You can use byte_extract to create up to two separate variables in a rule concurrently. You can redefine a byte_extract variable any number of times; entering a new byte_extract keyword with the same variable name and a different variable definition overwrites the previous definition of that variable.

The following table describes the arguments required by the byte_extract keyword.

To further define how the system locates the data to extract, you can use the arguments described in the following table.

You can specify only one of DCE/RPC, Endian, or Number Type.

To define how the byte_extract keyword calculates the bytes it tests, you can choose from the arguments in the following table. If you do not select a byte-ordering argument, the rules engine uses big endian byte order.

You can specify a number type to read data as an ASCII string. To define how the system views string data in a packet, you can select one of the arguments in the following table.

For example, if the value for byte_extract is specified as the following:

• Bytes to Extract = 4

• Variable Name = var

• Offset = 8

• Relative = enabled

the rules engine reads the number described in the four bytes that appear 9 bytes away from (relative to) the last successful content match into a variable named var, which you can specify later in the rule as the value for certain keyword arguments.

The following table lists the keyword arguments where you can specify a variable defined in the byte_extract keyword.

The byte_math keyword performs a mathematical operation on an extracted value and a specified value or existing variable, and stores the outcome in a new resulting variable. You can then use the resulting variable as an argument in other keywords.

You can use multiple byte_math keywords in a rule to perform multiple byte_math operations.

The following table describes the arguments required by the byte_math keyword.

The following table describes options you can use to define how the system interprets the values you specified for the required arguments.

You can specify only one of DCE/RPC, Endian, or Number Type.

If you want to define how the byte_math keyword calculates the bytes, you can choose from the arguments described in the following table. If you do not select a byte-ordering argument, the rules engine uses big endian byte order.

Define how the system views string data in a packet by using one of the arguments in the following table.

For example, if the values you set for byte_math are as follows:

• Bytes = 2

• Offset = 0

• Operator = *

• RValue = height

• Result Variable = area

the rules engine extracts the number described in the first two bytes in the packet and multiplies it by the RValue (which uses the existing variable, height) to create the new variable, area.

You can use the metadata keyword to add your own descriptive information to a rule. You can also use the metadata keyword with service arguments to identify applications and ports in network traffic. You can use the information you add to organize or identify rules in ways that suit your needs, and you can search rules for information you add and for service arguments.

The system validates metadata based on the argument format:

key value

where key and value provide a combined description separated by a space. This is the format used by the Talos Intelligence Group for adding metadata to rules provided by Cisco.

Alternatively, you can also use the format:

key = value

For example, you could use the key value format to identify rules by author and date, using a category and sub-category as follows:

author SnortGuru_20050406

You can use multiple metadata keywords in a rule. You can also use commas to separate multiple key value arguments in a single metadata keyword, as seen in the following example:

author SnortGuru_20050406, revised_by SnortUser1_20050707,

revised_by SnortUser2_20061003, 

revised_by SnortUser1_20070123

You are not limited to using a key value or key =value format; however, you should be aware of limitations resulting from validation based on these formats.

Restricted Characters to Avoid

Note the following character restrictions:

• Do not use a semicolon (;) or colon (:).

• The system interprets a comma as a separator for multiple key value or key =value arguments. For example:

  key value ,key value ,key value

• The system interprets the equal to (=) character or space character as separators between key and value . For example:

  key value

  key =value

All other characters are permitted.

Reserved Metadata to Avoid

Avoid using the following words in a metadata keyword, either as a single argument or as the key in a key value argument; these are reserved for use by Talos:

application
engine
impact_flag
os
policy
rule-type
rule-flushing
soid

Note	Contact Support for assistance in adding restricted metadata to local rules that might not otherwise function as expected.

Impact Level 1

You can use the following reserved key value argument in a metadata keyword:

impact_flag red

This key value argument sets the impact flag to red (level 1) for a local rule you import or a custom rule you create using the intrusion rules editor.

Note that when Talos includes the impact_flag red argument in a rule provided by Cisco, Talos has determined that a packet triggering the rule indicates that the source or destination host is potentially compromised by a virus, trojan, or other piece of malicious software.

You can use keywords to identify possible attacks or security policy violations in the IP headers of packets.

fragbits

The fragbits keyword inspects the fragment and reserved bits in the IP header. You can check each packet for the Reserved Bit, the More Fragments bit, and the Don't Fragment bit in any combination.

To further refine a rule using the fragbits keyword, you can specify any operator described in the following table after the argument value in the rule.

For example, to generate an event against packets that have the Reserved Bit set (and possibly any other bits), use R+ as the fragbits value.

id

The id keyword tests the IP header fragment identification field against the value you specify in the keyword’s argument. Some denial-of-service tools and scanners set this field to a specific number that is easy to detect. For example, in SID 630, which detects a Synscan portscan, the id value is set to 39426, the static value used as the ID number in packets transmitted by the scanner.

Note	id argument values must be numeric.

ipopts

The IPopts keyword allows you to search packets for specified IP header options. The following table lists the available argument values.

Analysts most frequently watch for strict and loose source routing because these options may be an indication of a spoofed source IP address.

ip_proto

The ip_proto keyword allows you to identify packets with the IP protocol specified as the keyword’s value. You can specify the IP protocols as a number, 0 through 255. You can combine these numbers with the following operators: <, >, or !. For example, to inspect traffic with any protocol that is not ICMP, use !1 as a value to the ip_proto keyword. You can also use the ip_proto keyword multiple times in a single rule; note, however, that the rules engine interprets multiple instances of the keyword as having a Boolean AND relationship. For example, if you create a rule containing ip_proto:!3; ip_proto:!6, the rule ignores traffic using the GGP protocol AND the TCP protocol.

tos

Some networks use the type of service (ToS) value to set precedence for packets traveling on that network. The tos keyword allows you to test the packet’s IP header ToS value against the value you specify as the keyword’s argument. Rules using the tos keyword will trigger on packets whose ToS is set to the specified value and that meet the rest of the criteria set forth in the rule.

Note	Argument values for tos must be numeric.

The ToS field has been deprecated in the IP header protocol and replaced with the Differentiated Services Code Point (DSCP) field.

ttl

A packet’s time-to-live (ttl) value indicates how many hops it can make before it is dropped. You can use the ttl keyword to test the packet’s IP header ttl value against the value, or range of values, you specify as the keyword’s argument. It may be helpful to set the ttl keyword parameter to a low value such as 0 or 1, as low time-to-live values are sometimes indicative of a traceroute or intrusion evasion attempt. (Note, though, that the appropriate value for this keyword depends on your managed device placement and network topology.) Use syntax as follows:

• Use an integer from 0 to 255 to set a specific value for the TTL value. You can also precede the value with an equal (=) sign (for example, you can specify 5 or =5).

• Use a hyphen (-) to specify a range of TTL values (for example, 0-2 specifies all values 0 through 2, -5 specifies all values 0 through 5, and 5- specifies all values 5 through 255).

• Use the greater than (>) sign to specify TTL values greater than a specific value (for example, >3 specifies all values greater than 3).

• Use the greater than and equal to signs (>=) to specify TTL values greater than or equal to a specific value (for example, >=3 specifies all values greater than or equal to 3).

• Use the less than (<) sign to specify TTL values less than a specific value (for example, <3 specifies all values less than 3).

• Use the less than and equal to signs (<=) to specify TTL values less than or equal to a specific value (for example, <=3 specifies all values less than or equal to 3).

The system supports keywords that you can use to identify attacks and security policy violations in the headers of ICMP packets. Note, however, that predefined rules exist that detect most ICMP types and codes. Consider enabling an existing rule or creating a local rule based on an existing rule; you may be able to find a rule that meets your needs more quickly than if you build an ICMP rule from scratch.

icmp_id and icmp_seq

The ICMP identification and sequence numbers help associate ICMP replies with ICMP requests. In normal traffic, these values are dynamically assigned to packets. Some covert channel and Distributed Denial of Server (DDoS) programs use static ICMP ID and sequence values. The following keywords allow you to identify ICMP packets with static values.

itype

Use the itype keyword to look for packets with specific ICMP message type values. You can specify either a valid ICMP type value or an invalid ICMP type value to test for different types of traffic. For example, attackers may set ICMP type values out of range to cause denial of service and flooding attacks.

You can specify a range for the itype argument value using less than (<) and greater than (>).

For example:

• <35

• >36

• 3<>55

icode

ICMP messages sometimes include a code value that provides details when a destination is unreachable.

You can use the icode keyword to identify packets with specific ICMP code values. You can choose to specify either a valid ICMP code value or an invalid ICMP code value to test for different types of traffic.

You can specify a range for the icode argument value using less than (<) and greater than (>).

For example:

• to find values less than 35, specify <35.

• to find values greater than 36, specify >36.

• to find values between 3 and 55, specify 3<>55.

Tip

You can use the icode and itype keywords together to identify traffic that matches both. For example, to identify ICMP traffic that contains an ICMP Destination Unreachable code type with an ICMP Port Unreachable code type, specify an itype keyword with a value of 3 (for Destination Unreachable) and an icode keyword with a value of 3 (for Port Unreachable).

The system supports keywords that are designed to identify attacks attempted using TCP headers of packets and TCP stream size.

ack

You can use the ack keyword to compare a value against a packet’s TCP acknowledgment number. The rule triggers if a packet’s TCP acknowledgment number matches the value specified for the ack keyword.

Argument values for ack must be numeric.

flags

You can use the flags keyword to specify any combination of TCP flags that, when set in an inspected packet, cause the rule to trigger.

Note	In situations where you would traditionally use A+ as the value for flags, you should instead use the flow keyword with a value of established. Generally, you should use the flow keyword with a value of stateless when using flags to ensure that all combinations of flags are detected.

You can either check for or ignore the values described in the following table for the flag keyword.

When using the flags keyword, you can use an operator to indicate how the system performs matches against multiple flags. The following table describes these operators.

flow

You can use the flow keyword to select packets for inspection by a rule based on session characteristics. The flow keyword allows you to specify the direction of the traffic flow to which a rule applies, applying rules to either the client flow or server flow. To specify how the flow keyword inspects your packets, you can set the direction of traffic you want analyzed, the state of packets inspected, and whether the packets are part of a rebuilt stream.

Stateful inspection of packets occurs when rules are processed. If you want a TCP rule to ignore stateless traffic (traffic without an established session context), you must add the flow keyword to the rule and select the Established argument for the keyword. If you want a UDP rule to ignore stateless traffic, you must add the flow keyword to the rule and select either the Established argument or a directional argument, or both. This causes the TCP or UDP rule to perform stateful inspection of a packet.

When you add a directional argument, the rules engine inspects only those packets that have an established state with a flow that matches the direction specified. For example, if you add the flow keyword with the established argument and the From Client argument to a rule that triggers when a TCP or UDP connection is detected, the rules engine only inspects packets that are sent from the client.

Tip	For maximum performance, always include a flow keyword in a TCP rule or a UDP session rule.

The following table describes the stream-related arguments you can specify for the flow keyword:

The following table describes the directional options you can specify for the flow keyword:

Notice that From Server and To Client perform the same function, as do To Server and From Client. These options exist to add context and readability to the rule. For example, if you create a rule designed to detect an attack from a server to a client, use From Server. But, if you create a rule designed to detect an attack from the client to the server, use From Client.

The following table describes the stream-related arguments you can specify for the flow keyword:

For example, you can use To Server, Established, Only Stream Traffic as the value for the flow keyword to detect traffic, traveling from a client to the server in an established session, that has been reassembled by the stream preprocessor.

seq

The seq keyword allows you to specify a static sequence number value. Packets whose sequence number matches the specified argument trigger the rule containing the keyword. While this keyword is used rarely, it is helpful in identifying attacks and network scans that use generated packets with static sequence numbers.

window

You can use the window keyword to specify the TCP window size you are interested in. A rule containing this keyword triggers whenever it encounters a packet with the specified TCP window size. While this keyword is used rarely, it is helpful in identifying attacks and network scans that use generated packets with static TCP window sizes.

stream_size

You can use the stream_size keyword in conjunction with the stream preprocessor to determine the size in bytes of a TCP stream, using the format:

direction,operator,bytes

where bytes is number of bytes. You must separate each option in the argument with a comma (,).

The following table describes the case-insensitive directional options you can specify for the stream_size keyword:

The following table describes the operators you can use with the stream_size keyword:

For example, you could use client, >=, 5001216 as the argument for the stream_size keyword to detect a TCP stream traveling from a client to a server and greater than or equal to 5001216 bytes.

You can use the stream_reassemble keyword to enable or disable TCP stream reassembly for a single connection when inspected traffic on the connection matches the conditions of the rule. Optionally, you can use this keyword multiple times in a rule.

Use the following syntax to enable or disable stream reassembly:

enable|disable, server|client|both, option, option

The following table describes the optional arguments you can use with the stream_reassemble keyword.

For example, the following rule disables TCP client-side stream reassembly without generating an event on the connection where a 200 OK status code is detected in an HTTP response:

alert tcp any 80 -> any any (flow:to_client, established; content: “200 OK”; 
stream_reassemble:disable, client, noalert

You can use SSL rule keywords to invoke the Secure Sockets Layer (SSL) preprocessor and extract information about SSL version and session state from packets in an encrypted session.

When a client and server communicate to establish an encrypted session using SSL or Transport Layer Security (TLS), they exchange handshake messages. Although the data transmitted in the session is encrypted, the handshake messages are not.

The SSL preprocessor extracts state and version information from specific handshake fields. Two fields within the handshake indicate the version of SSL or TLS used to encrypt the session and the stage of the handshake.

ssl_state

The ssl_state keyword can be used to match against state information for an encrypted session. To check for two or more SSL versions used simultaneously, use multiple ssl_version keywords in a rule.

When a rule uses the ssl_state keyword, the rules engine invokes the SSL preprocessor to check traffic for SSL state information.

For example, to detect an attacker’s attempt to cause a buffer overflow on a server by sending a ClientHello message with an overly long challenge length and too much data, you could use the ssl_state keyword with client_hello as an argument then check for abnormally large packets.

Use a comma-separated list to specify multiple arguments for the SSL state. When you list multiple arguments, the system evaluates them using the OR operator. For example, if you specify client_hello and server_hello as arguments, the system evaluates the rule against traffic that has a client_hello OR a server_hello.

You can also negate any argument; for example:

!client_hello, !unknown

To ensure the connection has reached each of a set of states, multiple rules using the ssl_state rule option should be used. The ssl_state keyword takes the following identifiers as arguments:

ssl_version

The ssl_version keyword can be used to match against version information for an encrypted session. When a rule uses the ssl_version keyword, the rules engine invokes the SSL preprocessor to check traffic for SSL version information.

For example, if you know there is a buffer overflow vulnerability in SSL version 2, you could use the ssl_version keyword with the sslv2 argument to identify traffic using that version of SSL.

Use a comma-separated list to specify multiple arguments for the SSL version. When you list multiple arguments, the system evaluates them using the OR operator. For example, if you wanted to identify any encrypted traffic that was not using SSLv2, you could add ssl_version:ssl_v3,tls1.0,tls1.1,tls1.2 to a rule. The rule would evaluate any traffic using SSL Version 3, TLS Version 1.0, TLS Version 1.1, or TLS Version 1.2.

The ssl_version keyword takes the following SSL/TLS version identifiers as arguments:

You can use the appid keyword to identify the application protocol, client application, or web application in a packet. For example, you could target a specific application that you know is susceptible to a specific vulnerability.

Within the appid keyword of an intrusion rule, click Configure AppID to select one or more applications that you want to detect.

Browsing the Available Applications

When you first start to build the condition, the Available Applications list is unconstrained and displays every application the system detects, 100 per page:

• To page through the applications, click the arrows underneath the list.

• To display a pop-up window with summary information about the application’s characteristics, as well as Internet search links that you can follow, click Information () next to an application.

Using Application Filters

To help you find the applications you want to match, you can constrain the Available Applications list in the following ways:

• To search for applications, click the Search by name prompt above the list, then type a name. The list updates as you type to display matching applications.

• To constrain the applications by applying a filter, use the Application Filters list. The Available Applications list updates as you apply filters. For your convenience, the system uses an Unlock icon to mark applications that the system can identify only in decrypted traffic—not encrypted or unencrypted.

Note	If you select one or more filters in the Application Filters list and also search the Available Applications list, your selections and the search-filtered Available Applications list are combined using an AND operation.

Selecting Applications

To select a single application, select it and click Add to Rule. To select all applications in the current constrained view, right-click and select Select All.