ASA FirePOWER Module User Guide for the ASA5506-X, ASA5506H-X, ASA5506W-X, ASA5508-X, and ASA5516-X, Version 5.4.1

Specifying Rule Actions

License: Protection

Each rule header includes a parameter that specifies the action the system takes when a packet triggers a rule. Rules with the action set to alert generate an intrusion event against the packet that triggered the rule and log the details of that packet. Rules with the action set to pass do not generate an event against, or log the details of, the packet that triggered the rule.

Note In an inline deployment, rules with the rule state set to Drop and Generate Events generate an intrusion event against the packet that triggered the rule. Also, if you apply a drop rule in a passive deployment, the rule acts as an alert rule. For more information on drop rules, see Setting Rule States.

By default, pass rules override alert rules. You can create pass rules to prevent packets that meet criteria defined in the pass rule from triggering the alert rule in specific situations, rather than disabling the alert rule. For example, you might want a rule that looks for attempts to log into an FTP server as the user “anonymous” to remain active. However, if your network has one or more legitimate anonymous FTP servers, you could write and activate a pass rule that specifies that, for those specific servers, anonymous users do not trigger the original rule.

Within the rule editor, you select the rule type from the Action list. For more information about the procedures you use to build a rule header using the rule editor, see Constructing a Rule.

Specifying Protocols

License: Protection

In each rule header, you must specify the protocol of the traffic the rule inspects. You can specify the following network protocols for analysis:

• ICMP (Internet Control Message Protocol)
• IP (Internet Protocol)

Note The system ignores port definitions in an intrusion rule header when the protocol is set to ip. For more information, see Defining Ports in Intrusion Rules.

• TCP (Transmission Control Protocol)
• UDP (User Datagram Protocol)

Use IP as the protocol type to examine all protocols assigned by IANA, including TCP, UDP, ICMP, IGMP, and many more. See http://www.iana.org/assignments/protocol-numbers for a full list of IANA-assigned protocols.

Note You cannot currently write rules that match patterns in the next header (for example, the TCP header) in an IP payload. Instead, content matches begin with the last decoded protocol. As a workaround, you can match patterns in TCP headers by using rule options.

Within the rule editor, you select the protocol type from the Protocol list. See Constructing a Rule for more information about the procedures you use to build a rule header using the rule editor.

Specifying IP Addresses In Intrusion Rules

License: Protection

Restricting packet inspection to the packets originating from specific IP addresses or destined to a specific IP address reduces the amount of packet inspection the system must perform. This also reduces false positives by making the rule more specific and removing the possibility of the rule triggering against packets whose source and destination IP addresses do not indicate suspicious behavior.

Tip The system recognizes only IP addresses and does not accept host names for source or destination IP addresses.

Within the rule editor, you specify source and destination IP addresses in the Source IPs and Destination IPs fields. See Constructing a Rule for more information about the procedures you use to build a rule header using the rule editor.

When writing standard text rules, you can specify IPv4 and IPv6 addresses in a variety of ways, depending on your needs. You can specify a single IP address, any, IP address lists, CIDR notation, prefix lengths, a network variable, or a network object or network object group. Additionally, you can indicate that you want to exclude a specific IP address or set of IP addresses. When specifying IPv6 addresses, you can use any addressing convention defined in RFC 4291.

The following table summarizes the various ways you can specify source and destination IP addresses.

See the following sections for more in-depth information about the syntax you can use to specify source and destination IP addresses, and for information about using variables to specify IP addresses:

• IP Address Conventions.
• Working with Variable Sets
• Specifying Any IP Address
• Specifying Multiple IP Addresses
• Specifying Network Objects
• Excluding IP Addresses in Intrusion Rules

Specifying Any IP Address

License: Protection

You can specify the word any as a rule source or destination IP address to indicate any IPv4 or IPv6 address.

For example, the following rule uses the argument any in the Source IPs and Destination IPs fields and evaluates packets with any IPv4 or IPv6 source or destination address:

You can also specify :: to indicate any IPv6 address.

Specifying Multiple IP Addresses

License: Protection

You can list individual IP addresses by separating the IP addresses with commas and, optionally, by surrounding non-negated lists with brackets, as shown in the following example:

You can list IPv4 and IPv6 addresses alone or in any combination, as shown in the following example:

Note that surrounding an IP address list with brackets, which was required in earlier software releases, is not required. Note also that, optionally, you can enter lists with a space before or after each comma.

Note You must surround negated lists with brackets. See Excluding IP Addresses in Intrusion Rules for more information.

You can also use IPv4 Classless Inter-Domain Routing (CIDR) notation or IPv6 prefix lengths to specify address blocks. For example:

• 192.168.1.0/24 specifies the IPv4 addresses in the 192.168.1.0 network with a subnet mask of 255.255.255.0, that is, 192.168.1.0 through 192.168.1.255. For more information, see IP Address Conventions.
• 2001:db8::/32 specifies the IPv6 addresses in the 2001:db8:: network with a prefix length of 32 bits, that is, 2001:db8:: through 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff.

Tip If you need to specify a block of IP addresses but cannot express it using CIDR or prefix length notation alone, you can use CIDR blocks and prefix lengths in an IP address list.

Specifying Network Objects

License: Protection

You can specify a network object or network object group using the syntax:

where:

• object_name is the name of a network object
• group_name is the name of a network object group

See Working with Network Objects for information on creating network objects and network object groups.

Consider the case where you have created a network object named 192.168sub16 and a network object group named all_subnets. You could specify the following to identify IP addresses using the network object:

and you could specify the following to use the network object group:

You can also use negation with network objects and network object groups. For example:

See Excluding IP Addresses in Intrusion Rules for more information.

Excluding IP Addresses in Intrusion Rules

License: Protection

You can use an exclamation point ( !) to negate a specified IP address. That is, you can match any IP address with the exception of the specified IP address or addresses. For example, !192.168.1.1 specifies any IP address other than 192.168.1.1, and !2001:db8:ca2e::fa4c specifies any IP address other than 2001:db8:ca2e::fa4c.

To negate a list of IP addresses, place ! before a bracketed list of IP addresses. For example, ![192.168.1.1,192.168.1.5] would define any IP address other than 192.168.1.1 or 192.168.1.5.

Note You must use brackets to negate a list of IP addresses.

Be careful when using the negation character with IP address lists. For example, if you use [!192.168.1.1,!192.168.1.5] to match any address that is not 192.168.1.1 or 192.168.1.5, the system interprets this syntax as “anything that is not 192.168.1.1, or anything that is not 192.168.1.5.”

Because 192.168.1.5 is not 192.168.1.1, and 192.168.1.1 is not 192.168.1.5, both IP addresses match the IP address value of [!192.168.1.1,!192.168.1.5], and it is essentially the same as using “ any.”

Instead, use ![192.168.1.1,192.168.1.5]. The system interprets this as “ not 192.168.1.1 and not 192.168.1.5,” which matches any IP address other than those listed between brackets.

Note that you cannot logically use negation with any which, if negated, would indicate no address.

Defining Ports in Intrusion Rules

License: Protection

Within the rule editor, you specify source and destination ports in the Source Port and Destination Port fields. See Constructing a Rule for more information about the procedures you use to build a rule header using the rule editor.

The ASA FirePOWER module uses a specific type of syntax to define the port numbers used in rule headers.

Note The system ignores port definitions in an intrusion rule header when the protocol is set to ip. For more information, see Specifying Protocols.

You can list ports by separating the ports with commas, as shown in the following example:

Optionally, the following example shows how you can surround a port list with brackets, which was required in previous software versions but is no longer required:

Note that you must surround negated port lists in brackets, as shown in the following example:

Note also that a list of source or destination ports in an intrusion rule can include a maximum of 64 characters.

The following table summarizes the syntax you can use:

Specifying Direction

License: Protection

Within the rule header, you can specify the direction that the packet must travel for the rule to inspect it. The following table describes these options.

See Constructing a Rule for more information about the procedures you use to build a rule header using the rule editor.

Defining Intrusion Event Details

License: Protection

As you construct a standard text rule, you can include contextual information that describes the vulnerability that the rule detects attempts to exploit. 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.

See the following sections for more information about event-related keywords:

• Defining the Event Message
• Defining the Event Priority
• Defining the Intrusion Event Classification
• Defining the Event Reference

Defining the Event Message

License: Protection

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 rule editor, enter the event message in the Message field. See Constructing a Rule for more information about using the rule editor to build rules.

Defining the Event Priority

License: Protection

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.

To specify a priority using the rule editor, select priority from the Detection Options list, and select high, medium, or low from the drop-down list. 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. See Constructing a Rule for more information about using the rule editor to build rules.

Defining the Intrusion Event Classification

License: Protection

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.

To specify a classification in the rule editor, select a classification from the Classification list. See Writing New Rules for more information on the rule editor.

Adding Custom Classifications

License: Protection

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

To add classifications to the Classification list:

Step 1 Select Configuration > ASA FirePOWER Configuration > Policies> Intrusion Policy > Rule Editor.

The Rule Editor page appears.

Step 2 Click Create Rule.

The Create Rule page appears.

Step 3 Under the Classification drop-down list, click Edit Classifications.

A pop-up window appears.

Step 4 Type the name of the classification in the Classification Name field.

You can use up to 255 alphanumeric characters, but the page is difficult to read if you use more than 40 characters. The following characters are not supported: <>()\'"&$; and the space character.

Step 5 Type a description of the classification in the Classification Description field.

You can use up to 255 alphanumeric characters and spaces. The following characters are not supported: <>()\'"&$;

Step 6 Select a priority from the Priority list.

You can select high, medium, or low.

Step 7 Click Add.

The new classification is added to the list and becomes available for use in the rule editor.

Step 8 Click Done.

Defining the Event Reference

License: Protection

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.

To specify a reference using the rule editor, select reference from the Detection Options list, and enter a value in the corresponding field as follows:

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

For example, to specify the authentication bypass vulnerability on Microsoft Commerce Server 2002 servers documented in Bugtraq ID 17134, enter the following in the reference field:

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.

See Constructing a Rule for more information about using the rule editor to build rules.

Searching for Content Matches

License: Protection

Use the content keyword or the protected_content keyword to specify content that you want to detect in a packet. See the following sections for more information:

• Using the content Keyword
• Using the protected_content Keyword
• Configuring Content Matching

Using the content Keyword

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.

Using the protected_content Keyword

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.

Configuring Content Matching

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. See Constraining Content Matches for more information about modifiers to the content and protected_content keywords.

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. See Replacing Content in Inline Deployments for more information.

To enter content to be matched:

Step 1 In the content field, type the content you want to find (for example, |90C8 C0FF FFFF|/bin/sh).

If you want to search for any content that is not the specified content, select the Not check box.

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. For more information, see Not.

---

Step 2 Optionally, add additional keywords that modify the content keyword or add constraints for the keyword.

For more information on other keywords, see Understanding Keywords and Arguments in Rules. For more information on constraining the content keyword, see Constraining Content Matches.

Step 3 Continue with creating or editing the rule.

See Writing New Rules or Modifying Existing Rules for more information.

To enter protected content to be matched:

Step 1 Using a SHA-512, SHA-256, or MD5 hash generator, encode the content you want to find (for example, run the string Sample1 through a SHA-512 hash generator).

The generator outputs a hash for your string.

Step 2 In the protected_content field, type the hash you generated in step 1 (for example, B20AABAF59605118593404BD42FE69BD8D6506EE7F1A71CE6BB470B1DF848C814BC5DBEC2081999F15691A71FAECA5FBA4A3F8B8AB56B7F04585DA6D73E5DD15).

If you want to search for any content that is not the specified content, select the Not check box.

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. For more information, see Not.

---

Step 3 From the Hash Type drop-down list, select the hash function you used in step 1 (for example, SHA-512). Note that the number of bits in the hash entered in step 2 must match the hash type or the system does not save the rule. For more information, see Hash Type.

Tip If you select the Cisco-set Default, the system assumes SHA-512 as the hash function.

Step 4 Type a value in the required Length field. The value must correspond with the length of the original, unhashed string you want to find (for example, the string Sample1 from step 2 has the length 7).

For more information, see Length.

Step 5 Type a value in either the Offset or Distance field. You cannot mix the Offset and Distance options within a single keyword configuration.

For more information, see Using Search Location Options in the protected_content Keyword.

Step 6 Optionally, add additional constraining options that modify the protected_content keyword.

For more information, see Constraining Content Matches.

Step 7 Optionally, add additional keywords that modify the protected_content keyword.

For more information, see Understanding Keywords and Arguments in Rules.

Step 8 Continue with creating or editing the rule.

See Writing New Rules or Modifying Existing Rules for more information.

Constraining Content Matches

License: Protection

You can constrain the location and case-sensitivity of content searches with parameters that modify the content or protected_content keyword. Configure options that modify the content or protected_content keyword to specify the content for which you want to search.

For more information, see the following sections:

• Case Insensitive
• Hash Type
• Raw Data
• Not
• Search Location Options
• HTTP Content Options
• Use Fast Pattern Matcher

Case Insensitive

License: Protection

Note This option is not supported when configuring the protected_content keyword. For more information, see Using the protected_content Keyword.

You can instruct the rules engine to ignore case when searching for content matches in ASCII strings. To make your search case-insensitive, check Case Insensitive when specifying a content search.

To specify Case Insensitive when doing a content search:

Step 1 Select Case Insensitive for the content keyword you are adding.

Step 2 Continue with creating or editing the rule.

See Constraining Content Matches, Searching for Content Matches, Writing New Rules or Modifying Existing Rules for more information.

Hash Type

License: Protection

Note This option is only configurable with the protected_content keyword. For more information, see Using the protected_content Keyword.

Use the Hash Type drop-down to identify the hash function you used to encode your search string. The system supports SHA-512, SHA-256, and MD5 hashing for protected_content search strings. If the length of your hashed content does not match the selected hash type, the system does not save the rule.

The system automatically selects the Cisco-set default value. When Default is selected, no specific hash function is written into the rule and the system assumes SHA-512 for the hash function.

To specify a hash function when doing a protected content search:

Step 1 From the Hash Type drop-down list, select Default, SHA-512, SHA-256, or MD5 as the hash for the protected_content keyword you are adding.

Tip If you select the Cisco-set Default, the system assumes SHA-512 as the hash function. For more information, see Hash Type.

Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules, or Modifying Existing Rules for more information.

Raw Data

License: Protection

The Raw Data option instructs the rules engine to analyze the original packet payload before analyzing the normalized payload data (decoded by a network analysis policy) and does not use an argument value. You can use this keyword when analyzing telnet traffic to check the telnet negotiation options in the payload before normalization.

You cannot use the Raw Data option together in the same content or protected_content keyword with any HTTP content option. See HTTP Content Options for more information.

Tip You can configure the HTTP Inspect preprocessor Client Flow Depth and Server Flow Depth options to determine whether raw data is inspected in HTTP traffic, and how much raw data is inspected. For more information, see Selecting Server-Level HTTP Normalization Options.

To analyze raw data:

Step 1 Select the Raw Data check box for the content or protected_content keyword you are adding.

Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules, or Modifying Existing Rules for more information.

Not

License: Protection

Select the Not option to search for content that does not match the specified content. If you create a rule that includes a content or protected_content keyword with the Not option selected, you must also include in the rule at least one other content or protected_content keyword without the Not option selected.

Caution Do not create a rule that includes only one content or protected_content keyword if that keyword has the Not option selected. You may invalidate your intrusion policy.

---

For example, SMTP rule 1:2541:9 includes three content keywords, one of which has the Not option selected. A custom rule based on this rule would be invalid if you removed all of the content keywords except the one with the Not option selected. Adding such a rule to your intrusion policy could invalidate the policy.

To search for content that does not match the specified content:

Step 1 Select the Not check box for the content or protected_content keyword you are adding.

Tip You cannot select the Not check box and the Use Fast Pattern Matcher check box with the same content keyword.

Step 2 Include in the rule at least one other content or protected_content keyword that does not have the Not option selected.

Step 3 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules, or Modifying Existing Rules for more information.

Search Location Options

License: Protection

You can use search location options to specify where to begin searching for the specified content and how far to continue searching. For details about each option, see:

• Depth
• Distance
• Length
• Offset
• Within

For information about how to use search location options within the content or protected_content keyword, see:

• Using Search Location Options in the content Keyword
• Using Search Location Options in the protected_content Keyword

Depth

Note This option is only supported when configuring the content keyword. For more information, see Using the content Keyword.

Specifies the maximum content search depth, in bytes, from the beginning of the offset value, or if no offset is configured, from the beginning of the packet payload.

For example, in a rule with a content value of cgi-bin/phf, and offset value of 3, and a depth value of 22, the rule starts searching for a match to the cgi-bin/phf string at byte 3, and stops after processing 22 bytes (byte 25) in packets that meet the parameters specified by the rule header.

You must specify a value that is greater than or equal to the length of the specified content, up to a maximum of 65535 bytes. You cannot specify a value of 0.

The default depth is to search to the end of the packet.

Distance

Instructs the rules engine to identify subsequent content matches that occur a specified number of bytes after the previous successful content match.

Because the distance counter starts at byte 0, specify one less than the number of bytes you want to move forward from the last successful content match. For example, if you specify 4, the search begins at the fifth byte.

You can specify a value of -65535 to 65535 bytes. If you specify a negative Distance value, the byte you start searching on may fall outside the beginning of a packet. Any calculations will take into account the bytes outside the packet, even though the search actually starts on the first byte in the packet. For example, if the current location in the packet is the fifth byte, and the next content rule option specifies a Distance value of -10 and a Within value of 20, the search starts at the beginning of the payload and the Within option is adjusted to 15.

The default distance is 0, meaning the current location in the packet subsequent to the last content match.

Length

Note This option is only supported when configuring the protected_content keyword. For more information, see Using the protected_content Keyword.

The Length protected_content keyword option indicates the length, in bytes, of the unhashed search string.

For example, if you used the content Sample1 to generate a secure hash, use 7 for the Length value. You must enter a value in this field.

Offset

Specifies in bytes where in the packet payload to start searching for content relative to the beginning of the packet payload. You can specify a value of-65535 to 65535 bytes.

Because the offset counter starts at byte 0, specify one less than the number of bytes you want to move forward from the beginning of the packet payload. For example, if you specify 7, the search begins at the eighth byte.

The default offset is 0, meaning the beginning of the packet.

Within

Note This option is only supported when configuring the content keyword. For more information, see Using the content Keyword.

The Within option indicates that, to trigger the rule, the next content match must occur within the specified number of bytes after the end of the last successful content match. For example, if you specify a Within value of 8, the next content match must occur within the next eight bytes of the packet payload or it does not meet the criteria that triggers the rule.

You can specify a value that is greater than or equal to the length of the specified content, up to a maximum of 65535 bytes.

The default for Within is to search to the end of the packet.

Using Search Location Options in the content Keyword

You can use either of two content location pairs to specify where to begin searching for the specified content and how far to continue searching, as follows:

• Use Offset and Depth together to search relative to the beginning of the packet payload.
• Use Distance and Within together to search relative to the current search location.

When you specify only one of a pair, the default for the other option in the pair is assumed.

You cannot mix the Offset and Depth options with the Distance and Within options. For example, you cannot pair Offset and Within. You can use any number of location options in a rule.

When no location is specified, the defaults for Offset and Depth are assumed; that is, the content search starts at the beginning of the packet payload and continues to the end of the packet.

You can also use an existing byte_extract variable to specify the value for a location option. See Reading Packet Data into Keyword Arguments for more information.

To specify a search location value in a content keyword:

Step 1 Type the value in the field for the content keyword you are adding. You have the following choices:

• Offset
• Depth
• Distance
• Within

You can use any number of location options in a rule.

Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules or Modifying Existing Rules for more information.

Using Search Location Options in the protected_content Keyword

Use the required Length protected_content location option in combination with either the Offset or Distance location option to specify where to begin searching for the specified content and how far to continue searching, as follows:

• Use Length and Offset together to search for the protected string relative to the beginning of the packet payload.
• Use Length and Distance together to search for the protected string relative to the current search location.

Tip You cannot mix the Offset and Distance options within a single keyword configuration, but you can use any number of location options in a rule.

When no location is specified, the defaults are assumed; that is, the content search starts at the beginning of the packet payload and continues to the end of the packet.

You can also use an existing byte_extract variable to specify the value for a location option. For more information, see Reading Packet Data into Keyword Arguments.

To specify a search location value in a protected_content keyword:

Step 1 Type the value in the field for the protected_content keyword you are adding. You have the following choices:

• Length (required)
• Offset
• Distance

You cannot mix the Offset and Distance options within a single protected_content keyword, but you can use any number of location options in a rule.

Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules or Modifying Existing Rules for more information.

HTTP Content Options

License: Protection

HTTP content or protected_content keyword options let you specify where to search for content matches within an HTTP message decoded by the HTTP Inspect preprocessor.

Two options search status fields in HTTP responses:

• HTTP Status Code
• HTTP Status Message

Note that although the rules engine searches the raw, unnormalized status fields, these options are listed here separately to simplify explanation below of the restrictions to consider when combining other raw HTTP fields and normalized HTTP fields.

Five options search normalized fields in HTTP requests, responses, or both, as appropriate (see HTTP Content Options for more information):

• HTTP URI
• HTTP Method
• HTTP Header
• HTTP Cookie
• HTTP Client Body

Three options search raw (unnormalized) non-status fields in HTTP requests, responses, or both, as appropriate (see HTTP Content Options for more information):

• HTTP Raw URI
• HTTP Raw Header
• HTTP Raw Cookie

Use the following guidelines when selecting HTTP content options:

• HTTP content options apply only to TCP traffic.
• To avoid a negative impact on performance, select only those parts of the message where the specified content might appear.

For example, when traffic is likely to include large cookies such as those in shopping cart messages, you might search for the specified content in the HTTP header but not in HTTP cookies.

• To take advantage of HTTP Inspect preprocessor normalization, and to improve performance, any HTTP-related rule you create should at a minimum include at least one content or protected_content keyword with an HTTP URI, HTTP Method, HTTP Header, or HTTP Client Body option selected.
• You cannot use the replace keyword in conjunction with HTTP content or protected_content keyword options.

You can specify a single normalized HTTP option or status field, or use normalized HTTP options and status fields in any combination to target a content area to match. However, note the following restrictions when using HTTP field options:

• You cannot use the Raw Data option together in the same content or protected_content keyword with any HTTP option.
• You cannot use a raw HTTP field option ( HTTP Raw URI, HTTP Raw Header, or HTTP Raw Cookie) together in the same content or protected_content keyword with its normalized counterpart ( HTTP URI, HTTP Header, or HTTP Cookie, respectively).
• You cannot select Use Fast Pattern Matcher in combination with one or more of the following HTTP field options:

HTTP Raw URI, HTTP Raw Header, HTTP Raw Cookie, HTTP Cookie, HTTP Method, HTTP Status Message, or HTTP Status Code

However, you can include the options above in a content or protected_content keyword that also uses the fast pattern matcher to search one of the following normalized fields:

HTTP URI, HTTP Header, or HTTP Client Body

For example, if you select HTTP Cookie, HTTP Header, and Use Fast Pattern Matcher, the rules engine searches for content in both the HTTP cookie and the HTTP header, but the fast pattern matcher is applied only to the HTTP header, not to the HTTP cookie.

• When you combine restricted and unrestricted options, the fast pattern matcher searches only the unrestricted fields you specify to test whether to pass the rule to the rule editor for complete evaluation, including evaluation of the restricted fields. See Use Fast Pattern Matcher for more information.

The above restrictions are reflected in the description of each option in the following list describing the HTTP content and protected_content keyword options.

HTTP URI

Select this option to search for content matches in the normalized request URI field.

Note that you cannot use this option in combination with the pcre keyword HTTP URI (U) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

Note A pipelined HTTP request packet contains multiple URIs. When HTTP URI is selected and the rules engine detects a pipelined HTTP request packet, the rules engine searches all URIs in the packet for a content match.

HTTP Raw URI

Select this option to search for content matches in the normalized request URI field.

Note that you cannot use this option in combination with the pcre keyword HTTP URI (U) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

Note A pipelined HTTP request packet contains multiple URIs. When HTTP URI is selected and the rules engine detects a pipelined HTTP request packet, the rules engine searches all URIs in the packet for a content match.

HTTP Method

Select this option to search for content matches in the request method field, which identifies the action such as GET and POST to take on the resource identified in the URI.

HTTP Header

Select this option to search for content matches in the normalized header field, except for cookies, in HTTP requests; also in responses when the HTTP Inspect preprocessor Inspect HTTP Responses option is enabled.

Note that you cannot use this option in combination with the pcre keyword HTTP header (H) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

HTTP Raw Header

Select this option to search for content matches in the raw header field, except for cookies, in HTTP requests; also in responses when the HTTP Inspect preprocessor I nspect HTTP Responses option is enabled.

Note that you cannot use this option in combination with the pcre keyword HTTP raw header (D) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

HTTP Cookie

Select this option to search for content matches in any cookie identified in a normalized HTTP client request header; also in response set-cookie data when the HTTP Inspect preprocessor Inspect HTTP Responses option is enabled. Note that the system treats cookies included in the message body as body content.

You must enable the HTTP Inspect preprocessor Inspect HTTP Cookies option to search only the cookie for a match; otherwise, the rules engine searches the entire header, including the cookie. See Selecting Server-Level HTTP Normalization Options for more information.

Note the following:

– You cannot use this option in combination with the pcre keyword HTTP cookie (C) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

– The Cookie: and Set-Cookie: header names, leading spaces on the header line, and the CRLF that terminates the header line are inspected as part of the header and not as part of the cookie.

HTTP Raw Cookie

Select this option to search for content matches in any cookie identified in a raw HTTP client request header; also in response set-cookie data when the HTTP Inspect preprocessor Inspect HTTP Responses option is enabled; note that the system treats cookies included in the message body as body content.

You must enable the HTTP Inspect preprocessor Inspect HTTP Cookies option to search only the cookie for a match; otherwise, the rules engine searches the entire header, including the cookie. See Selecting Server-Level HTTP Normalization Options for more information.

Note the following:

– You cannot use this option in combination with the pcre keyword HTTP raw cookie (K) option to search the same content. See the Snort-Specific Post Regular Expression Modifiers table for more information.

– The Cookie: and Set-Cookie: header names, leading spaces on the header line, and the CRLF that terminates the header line are inspected as part of the header and not as part of the cookie.

HTTP Client Body

Select this option to search for content matches in the message body in an HTTP client request.

Note that for this option to function, you must specify a value of 0 to 65535 for the HTTP Inspect preprocessor HTTP Client Body Extraction Depth option. See Selecting Server-Level HTTP Normalization Options for more information.

HTTP Status Code

Select this option to search for content matches in the 3-digit status code in an HTTP response.

You must enable the HTTP Inspect preprocessor Inspect HTTP Responses option for this option to return a match. See Selecting Server-Level HTTP Normalization Options for more information.

HTTP Status Message

Select this option to search for content matches in the textual description that accompanies the status code in an HTTP response.

You must enable the HTTP Inspect preprocessor Inspect HTTP Responses option for this option to return a match. See Selecting Server-Level HTTP Normalization Options for more information.

To specify an HTTP content option when doing a content search of TCP traffic:

Step 1 Optionally, to take advantage of HTTP Inspect preprocessor normalization, and to improve performance, select:

• at least one from among the HTTP URI, HTTP Raw URI, HTTP Method, HTTP Header, HTTP Raw Header, or HTTP Client Body options for the content or protected_content keyword you are adding
• the HTTP Cookie or HTTP Raw Cookie option

Step 2 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Matches, Writing New Rules, or Modifying Existing Rules for more information.

Use Fast Pattern Matcher

License: Protection

Note These options are not supported when configuring the protected_content keyword. For more information, see Using the protected_content Keyword.

The fast pattern matcher quickly determines which rules to evaluate before passing a packet to the rules engine. This initial determination improves performance by significantly reducing the number of rules used in packet evaluation.

By default, the fast pattern matcher searches packets for the longest content specified in a rule; this is to eliminate as much as possible needless evaluation of a rule. Consider the following example rule fragment:

Almost all HTTP client requests contain the content GET, but few will contain the content /exploit.cgi. Using GET as the fast pattern content would cause the rules engine to evaluate this rule in most cases and would rarely result in a match. However, most client GET requests would not be evaluated using /exploit.cgi, thus increasing performance.

The rules engine evaluates the packet against the rule only when the fast pattern matcher detects the specified content. For example, if one content keyword in a rule specifies the content short, another specifies longer, and a third specifies longest, the fast pattern matcher will use the content longest and the rule will be evaluated only if the rules engine finds longest in the payload.

You can use the Use Fast Pattern Matcher option to specify a shorter search pattern for the fast pattern matcher to use. Ideally, the pattern you specify is less likely to be found in the packet than the longest pattern and, therefore, more specifically identifies the targeted exploit.

Note the following restrictions when selecting Use Fast Pattern Matcher and other options in the same content keyword:

• You can specify Use Fast Pattern Matcher only one time per rule.
• You cannot use Distance, Within, Offset, or Depth when you select Use Fast Pattern Matcher in combination with Not.
• You cannot select Use Fast Pattern Matcher in combination with any of the following HTTP field options:

HTTP Raw URI, HTTP Raw Header, HTTP Raw Cookie, HTTP Cookie, HTTP Method, HTTP Status Message, or HTTP Status Code

However, you can include the options above in a content keyword that also uses the fast pattern matcher to search one of the following normalized fields:

HTTP URI, HTTP Header, or HTTP Client Body

For example, if you select HTTP Cookie, HTTP Header, and Use Fast Pattern Matcher, the rules engine searches for content in both the HTTP cookie and the HTTP header, but the fast pattern matcher is applied only to the HTTP header, not to the HTTP cookie.

Note that you cannot use a raw HTTP field option ( HTTP Raw URI, HTTP Raw Header, or HTTP Raw Cookie) together in the same content keyword with its normalized counterpart ( HTTP URI, HTTP Header, or HTTP Cookie, respectively). See HTTP Content Options for more information.

When you combine restricted and unrestricted options, the fast pattern matcher searches only the unrestricted fields you specify to test whether to pass the packet to the rules engine for complete evaluation, including evaluation of the restricted fields.

• Optionally, when you select Use Fast Pattern Matcher you can also select Fast Pattern Matcher Only or Fast Pattern Matcher Offset and Length, but not both.
• You cannot use the fast pattern matcher when inspecting Base64 data; see Decoding and Inspecting Base64 Data for more information.

Using the Fast Pattern Matcher Only

The Fast Pattern Matcher Only option allows you to use the content keyword only as a fast pattern matcher option and not as a rule option. You can use this option to conserve resources when rules engine evaluation of the specified content is not necessary. For example, consider a case where a rule requires only that the content 12345 be anywhere in the payload. When the fast pattern matcher detects the pattern, the packet can be evaluated against additional keywords in the rule. There is no need for the rules engine to reevaluate the packet to determine if it includes the pattern 12345.

You would not use this option when the rule contains other conditions relative to the specified content. For example, you would not use this option to search for the content 1234 if another rule condition sought to determine if abcd occurs before 1234. In this case, the rules engine could not determine the relative location because specifying Fast Pattern Matcher Only instructs the rules engine not to search for the specified content.

Note the following conditions when using this option:

• The specified content is location-independent; that is, it may occur anywhere in the payload; thus, you cannot use positional options ( Distance, Within, Offset, Depth, or Fast Pattern Matcher Offset and Length).
• You cannot use this option in combination with Not.
• You cannot use this option in combination with Fast Pattern Matcher Offset and Length.
• The specified content will be treated as case-insensitive, because all patterns are inserted into the fast pattern matcher in a case-insensitive manner; this is handled automatically, so it is not necessary to select Case Insensitive when you select this option.
• You should not immediately follow a content keyword that uses the Fast Pattern Matcher Only option with the following keywords, which set the search location relative to the current search location:
• isdataat
• pcre
• content when Distance or Within is selected
• content when HTTP URI is selected
• asn1
• byte_jump
• byte_test
• byte_extract
• base64_decode

Specifying Fast Pattern Matcher Offset and Length

The Fast Pattern Matcher Offset and Length option allows you to specify a portion of the content to search. This can reduce memory consumption in cases where the pattern is very long and only a portion of the pattern is sufficient to identify the rule as a likely match. When a rule is selected by the fast pattern matcher, the entire pattern is evaluated against the rule.

You determine the portion for the fast pattern matcher to use by specifying in bytes where to begin the search (offset) and how far into the content (length) to search, using the syntax:

For example, for the content:

if you specify the number of offset and length bytes as:

the fast pattern matcher searches only for the content 23456.

Note that you cannot use this option together with Fast Pattern Matcher Only.

To specify the content searched for by the fast pattern matcher:

Step 1 Select Use Fast Pattern Matcher for the content keyword you are adding.

Step 2 Optionally, select Fast Pattern Matcher Only to determine without rules engine evaluation if the specified pattern exists in the packet.

Evaluation proceeds only if the fast pattern matcher detects the specified content.

Step 3 Optionally, specify in Fast Pattern Matcher Offset and Length a portion of the pattern to search for the content using the syntax:

where offset specifies how many bytes from the beginning of the content to begin the search, and length specifies the number of bytes to continue.

Step 4 Continue with creating or editing the rule. See Constraining Content Matches, Searching for Content Using PCRE, Writing New Rules, or Modifying Existing Rules for more information.

Replacing Content in Inline Deployments

License: Protection

You can use the replace keyword in an inline deployment to replace specified content.

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. For more information, see Using the protected_content Keyword.

Optionally, you can enclose the replacement string in quotation marks for backward compatibility with previous ASA FirePOWER module 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:

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 explain 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. See Searching for Content Matches and HTTP Content Options for more information.

To replace content in an inline deployment:

Step 1 On the Create Rule page, select content in the drop-down list and click Add Option.

The content keyword appears.

Step 2 Specify the content you want to detect in the content field and, optionally, select any applicable arguments. Note that you cannot use the HTTP request message content keyword options with the replace keyword.

Step 3 Select replace in the drop-down list and click Add Option.

The replace keyword appears beneath the content keyword.

Step 4 Specify the replacement string for the specified content in the replace: field.

Using Byte_Jump and Byte_Test

License: Protection

You can use byte_jump and byte_test to calculate where in a packet the rules engine should begin testing for a data match, and which bytes it should evaluate.

You can also use the byte_jump and byte_test DCE/RPC argument to tailor either keyword for traffic processed by the DCE/RPC preprocessor. When you use the DCE/RPC argument, you can also use byte_jump and byte_test in conjunction with other specific DCE/RPC keywords. See Decoding DCE/RPC Traffic and DCE/RPC Keywords for more information.

See the following sections for more information:

• byte_jump
• byte_test

byte_jump

License: Protection

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 of the packet payload, 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 neither argument is specified, network byte order is used).

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.

To use byte_jump:

Step 1 Select byte_jump in the drop-down list and click Add Option.

The byte_jump section appears beneath the last keyword you selected.

byte_test

License: Protection

The byte_test keyword calculates the number of bytes in a specified byte segment and compares them, according to the operator and value you specify.

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 neither argument is specified, network byte order is used.

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.

To use byte_test:

Step 1 On the Create Rule page, select byte_test in the drop-down list and click Add Option.

The byte_test section appears beneath the last keyword you selected.

Searching for Content Using PCRE

License: Protection

The pcre keyword allows you to use Perl-compatible regular expressions (PCRE) to inspect packet payloads for specified content. You can use PCRE to avoid writing multiple rules to match slight variations of the same content.

Regular expressions are useful when searching for content that could be displayed in a variety of ways. The content may have different attributes that you want to account for in your attempt to locate it within a packet’s payload.

Note that the regular expression syntax used in intrusion rules is a subset of the full regular expression library and varies in some ways from the syntax used in commands in the full library. When adding a pcre keyword using the rule editor, enter the full value in the following format:

where:

• ! is an optional negation (use this if you want to match patterns that do not match the regular expression).
• / pcre / is a Perl-compatible regular expression.
• ismxAEGRBUIPHDMCKSY is any combination of modifier options.

Also note that you must escape the characters listed in the following table for the rules engine to interpret them correctly when you use them in a PCRE to search for specific content in a packet payload.

Tip Optionally, you can surround your Perl-compatible regular expression with quote characters, for example, pcre_expression or “pcre_expression“.The option of using quotes accommodates experienced users accustomed to previous versions when quotes were required instead of optional. The rule editor does not display quotation marks when you display a rule after saving it.

You can also use m?regex?, where ? is a delimiter other than /. You may want to use this in situations where you need to match a forward slash within a regular expression and do not want to escape it with a backslash. For example, you might use m? regex ? ismxAEGRBUIPHDMCKSY where regex is your Perl-compatible regular expression and ismxAEGRBUIPHDMCKSY is any combination of modifier options. See Perl-Compatible Regular Expression Basics for more information about regular expression syntax.

The following sections provide more information about building valid values for the pcre keyword:

• Perl-Compatible Regular Expression Basics describes the common syntax used in Perl-compatible regular expressions.
• PCRE Modifier Options describes the options you can use to modify your regular expression.
• Example PCRE Keyword Values gives example usage of the pcre keyword in rules.

Perl-Compatible Regular Expression Basics

License: Protection

The pcre keyword accepts standard Perl-compatible regular expression (PCRE) syntax. The following sections describe that syntax.

Tip While this section describes the basic syntax you may use for PCRE, you may want to consult an online reference or book dedicated to Perl and PCRE for more advanced information.

Metacharacters

License: Protection

Metacharacters are literal characters that have special meaning within regular expressions. When you use them within a regular expression, you must “escape” them by preceding them with a backslash.

The following table describes the metacharacters you can use with PCRE and gives examples of each.

Character Classes

License: Protection

Character classes include alphabetic characters, numeric characters, alphanumeric characters, and white space characters. While you can create your own character classes within brackets (see Metacharacters), you can use the predefined classes as shortcuts for different types of character types. When used without additional qualifiers, a character class matches a single digit or character.

The following table describes and provides examples of the predefined character classes accepted by PCRE.

PCRE Modifier Options

License: Protection

You can use modifying options after you specify regular expression syntax in the pcre keyword’s value. These modifiers perform Perl, PCRE, and Snort-specific processing functions. Modifiers always appear at the end of the PCRE value, and appear in the following format:

where ismxAEGRBUPHMC can include any of the modifying options that appear in the following tables.

Tip Optionally, you can surround the regular expression and any modifying options with quotes, for example, “/pcre/ismxAEGRBUIPHDMCKSY”. The option of using quotes accommodates experienced users accustomed to previous versions when quotes were required instead of optional. The rule editor does not display quotation marks when you display a rule after saving it.

The following table describes options you can use to perform Perl processing functions.

The following table describes the PCRE modifiers you can use after the regular expression.

The following table describes the Snort-specific modifiers that you can use after the regular expression.

.

Note Do not use the U option in combination with the R option. This could cause performance problems. Also, do not use the U option in combination with any other HTTP content option (I, P, H, D, M, C, K, S, or Y).

Example PCRE Keyword Values

License: Protection

The following examples show values that you could enter for pcre, with descriptions of what each example would match.

• /feedback[(\d{0,1})]?\.cgi/U

This example searches packet payload for feedback, followed by zero or one numeric character, followed by .cgi, and located only in URI data.

This example would match:

• feedback.cgi
• feedback1.cgi
• feedback2.cgi
• feedback3.cgi

This example would not match:

• feedbacka.cgi
• feedback11.cgi
• feedback21.cgi
• feedbackzb.cgi
• /^ez(\w{3,5})\.cgi/iU

This example searches packet payload for ez at the beginning of a string, followed by a word of 3 to 5 letters, followed by .cgi. The search is case-insensitive and only searches URI data.

This example would match:

• EZBoard.cgi
• ezman.cgi
• ezadmin.cgi
• EZAdmin.cgi

This example would not match:

• ezez.cgi
• fez.cgi
• abcezboard.cgi
• ezboardman.cgi
• /mail(file|seek)\.cgi/U

This example searches packet payload for mail, followed by either file or seek, in URI data.

This example would match:

• mailfile.cgi
• mailseek.cgi

This example would not match:

• MailFile.cgi
• mailfilefile.cgi
• m?http\\x3a\x2f\x2f.*(\n|\t)+?U

This example searches packet payload for URI content for a tab or newline character in an HTTP request, after any number of characters. This example uses m? regex ? to avoid using http\:\/\/ in the expression. Note that the colon is preceded by a backslash.

This example would match:

• http://www.example.com?scriptvar=x&othervar=\n\..\..
• http://www.example.com?scriptvar=\t

This example would not match:

• ftp://ftp.example.com?scriptvar=&othervar=\n\..\..
• http://www.example.com?scriptvar=|/bin/sh -i|
• m?http\\x3a\x2f\x2f.*=\|.*\|+?sU

This example searches packet payload for a URL with any number of characters, including newlines, followed by an equal sign, and pipe characters that contain any number of characters or white space. This example uses m? regex ? to avoid using http\:\/\/ in the expression.

This example would match:

• http://www.example.com?value=|/bin/sh/ -i|
• http://www.example.com?input=|cat /etc/passwd|

This example would not match:

• ftp://ftp.example.com?value=|/bin/sh/ -i|
• http://www.example.com?value=x&input?|cat /etc/passwd|
• /[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}/i

This example searches packet payload for any MAC address. Note that it escapes the colon characters with backslashes.

Adding Metadata to a Rule

License: Protection

You can use the metadata keyword to add descriptive information to a rule. You can use the information you add to organize or identify rules in ways that suit your needs, and to search for rules.

The system validates metadata based on the format:

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

Alternatively, you can also use the format:

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

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

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.

Avoiding Restricted Characters

License: Protection

Note the following character restrictions:

• Do not use a semicolon (;) or colon (:) in a metadata keyword.
• Be aware when using commas that the system interprets a comma as a separator for multiple key value or key = value statements. For example:

• Be aware when using the equal to (=) character or space character that the system interprets these characters as separators between key and value. For example:

All other characters are permitted.

Adding service Metadata

License: Protection

The rules engine applies active rules with service metadata that match the application protocol information for the host in a packet to analyze and process traffic. If it does not match, the system does not apply the rule to the traffic. If a host does not have application protocol information, or if the rule does not have service metadata, the system checks the port in the traffic against the port in the rule to determine whether to apply the rule to the traffic.

The following diagram illustrates matching a rule to traffic based on application information:

To match a rule with an identified application protocol, you must define the metadata keyword and a key value statement, with service as the key and an application for the value. For example, the following key value statement in a metadata keyword associates the rule with HTTP traffic:

The following table describes the most common application values.

Note Contact Support for assistance in defining applications not in the table.

Avoiding Reserved Metadata

License: Protection

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

Note Contact Support for assistance in adding restricted metadata to local rules that might not otherwise function as expected. See Importing Local Rule Files for more information.

Inspecting IP Header Values

License: Protection

You can use keywords to identify possible attacks or security policy violations in the IP headers of packets. See the following sections for more information:

• Inspecting Fragments and Reserved Bits
• Inspecting the IP Header Identification Value
• Identifying Specified IP Options
• Identifying Specified IP Protocol Numbers
• Inspecting a Packet’s Type of Service
• Inspecting a Packet’s Time-To-Live Value

Inspecting Fragments and Reserved Bits

License: Protection

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.

Inspecting the IP Header Identification Value

License: Protection

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.

Identifying Specified IP Options

License: Protection

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.

Identifying Specified IP Protocol Numbers

License: Protection

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 find the complete list of protocol numbers at http://www.iana.org/assignments/protocol-numbers. 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.

Inspecting a Packet’s Type of Service

License: Protection

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.

Inspecting a Packet’s Time-To-Live Value

License: Protection

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 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).

Inspecting ICMP Header Values

License: Protection

The ASA FirePOWER module 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.

See the following sections for more information about ICMP-specific keywords:

• Identifying Static ICMP ID and Sequence Values
• Inspecting the ICMP Message Type
• Inspecting the ICMP Message Code

Identifying Static ICMP ID and Sequence Values

License: Protection

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.

icmp_id

The icmp_id keyword inspects an ICMP echo request or reply packet's ICMP ID number. Use a numeric value that corresponds with the ICMP ID number as the argument for the icmp_id keyword.

icmp_seq

The icmp_seq keyword inspects an ICMP echo request or reply packet's ICMP sequence. Use a numeric value that corresponds with the ICMP sequence number as the argument for the icmp_seq keyword.

Inspecting the ICMP Message Type

License: Protection

Use the itype keyword to look for packets with specific ICMP message type values. You can specify either a valid ICMP type value (see http://www.iana.org/assignments/icmp-parameters or http://www.faqs.org/rfcs/rfc792.html for a full list of ICMP type numbers) 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

Tip See http://www.iana.org/assignments/icmp-parameters or http://www.faqs.org/rfcs/rfc792.html for a full list of ICMP type numbers.

Inspecting the ICMP Message Code

License: Protection

ICMP messages sometimes include a code value that provides details when a destination is unreachable. (See the second section in http://www.iana.org/assignments/icmp-parameters for a full list of ICMP message codes correlated with the message types for which they can be used.)

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).

Inspecting TCP Header Values and Stream Size

License: Protection

The ASA FirePOWER module supports keywords that are designed to identify attacks attempted using TCP headers of packets and TCP stream size. See the following sections for more information about TCP-specific keywords:

• Inspecting the TCP Acknowledgment Value
• Inspecting TCP Flag Combinations
• Applying Rules to a TCP or UDP Client or Server Flow
• Identifying Static TCP Sequence Numbers
• Identifying TCP Windows of a Given Size
• Identifying TCP Streams of a Given Size

Inspecting the TCP Acknowledgment Value

License: Protection

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.

Inspecting TCP Flag Combinations

License: Protection

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. See Applying Rules to a TCP or UDP Client or Server Flow for more information about the flow keyword.

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

Tip For more information on Explicit Congestion Notification (ECN), see the information provided at: http://www.faqs.org/rfcs/rfc3168.html.

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.

Applying Rules to a TCP or UDP Client or Server Flow

License: Protection

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.

To specify flow, select the flow keyword from the Detection Options list on the Create Rule page and click Add Option. Next, select the arguments from the list provided for each field.

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.

Identifying Static TCP Sequence Numbers

License: Protection

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.

Identifying TCP Windows of a Given Size

License: Protection

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.

Identifying TCP Streams of a Given Size

License: Protection

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:

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.

Enabling and Disabling TCP Stream Reassembly

License: Protection

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:

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:

To use stream_reassemble:

Step 1 On the Create Rule page, select stream_reassemble in the drop-down list and click Add Option.

The stream_reassemble section appears.

Extracting SSL Information from a Session

License: Protection

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.

For more information, see the following sections:

• ssl_state
• ssl_version

ssl_state

License: Protection

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:

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

License: Protection

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:

Inspecting Application Layer Protocol Values

License: Protection

Although preprocessors perform most of the normalization and inspection of application layer protocol values, you can continue to inspect application layer values using the keywords described in the following sections:

• RPC
• ASN.1
• urilen
• DCE/RPC Keywords
• SIP Keywords
• GTP Keywords
• Modbus Keywords
• DNP3 Keywords

RPC

License: Protection

The rpc keyword identifies Open Network Computing Remote Procedure Call (ONC RPC) services in TCP or UDP packets. This allows you to detect attempts to identify the RPC programs on a host. Intruders can use an RPC portmapper to determine if any of the RPC services running on your network can be exploited. They can also attempt to access other ports running RPC without using portmapper. The following table lists the arguments that the rpc keyword accepts.

To specify the arguments for the rpc keyword, use the following syntax:

where application is the RPC application number, procedure is the RPC procedure number, and version is the RPC version number. You must specify all arguments for the rpc keyword — if you are not able to specify one of the arguments, replace it with an asterisk ( *).

For example, to search for RPC portmapper (which is the RPC application indicated by the number 100000), with any procedure or version, use 100000,*,* as the arguments.

ASN.1

License: Protection

The asn1 keyword allows you to decode a packet or a portion of a packet, looking for various malicious encodings.

The following table describes the arguments for the asn1 keyword.

For example, there is a known vulnerability in the Microsoft ASN.1 Library that creates a buffer overflow, allowing an attacker to exploit the condition with a specially crafted authentication packet. When the system decodes the asn.1 data, exploit code in the packet could execute on the host with system-level privileges or could cause a DoS condition. The following rule uses the asn1 keyword to detect attempts to exploit this vulnerability:

The above rule generates an event against TCP traffic traveling from any IP address defined in the $EXTERNAL_NET variable, from any port, to any IP address defined in the $HOME_NET variable using port 445. In addition, it only executes the rule on established TCP connections to servers. The rule then tests for specific content in specific locations. Finally, the rule uses the asn1 keyword to detect bitstring encodings and double ASCII encodings and to identify asn.1 type lengths over 100 bytes in length starting 55 bytes from the end of the last successful content match. (Remember that the offset counter starts at byte 0.)

urilen

License: Protection

You can use the urilen keyword in conjunction with the HTTP Inspect preprocessor to inspect HTTP traffic for URIs of a specific length, less than a maximum length, greater than a minimum length, or within a specified range.

After the HTTP Inspect preprocessor normalizes and inspects the packet, the rules engine evaluates the packet against the rule and determines whether the URI matches the length condition specified by the urilen keyword. You can use this keyword to detect exploits that attempt to take advantage of URI length vulnerabilities, for example, by creating a buffer overflow that allows the attacker to cause a DoS condition or execute code on the host with system-level privileges.

Note the following when using the urilen keyword in a rule:

• In practice, you always use the urilen keyword in combination with the flow:established keyword and one or more other keywords.
• The rule protocol is always TCP. See Specifying Protocols for more information.
• Target ports are always HTTP ports. See Defining Ports in Intrusion Rules and Optimizing Predefined Default Variables for more information.

You specify the URI length using a decimal number of bytes, less than (<) and greater than (>).

For example:

• specify 5 to detect a URI 5 bytes long.
• specify < 5 (separated by one space character) to detect a URI less than 5 bytes long.
• specify > 5 (separated by one space character) to detect a URI greater than 5 bytes long.
• specify 3 <> 5 (with one space character before and after <>) to detect a URI between 3 and 5 bytes long inclusive.

For example, there is a known vulnerability in Novell’s server monitoring and diagnostics utility iMonitor version 2.4, which comes with eDirectory version 8.8. A packet containing an excessively long URI creates a buffer overflow, allowing an attacker to exploit the condition with a specially crafted packet that could execute on the host with system-level privileges or could cause a DoS condition. The following rule uses the urilen keyword to detect attempts to exploit this vulnerability:

The above rule generates an event against TCP traffic traveling from any IP address defined in the $EXTERNAL_NET variable, from any port, to any IP address defined in the $HOME_NET variable using the ports defined in the $HTTP_PORTS variable. In addition, packets are evaluated against the rule only on established TCP connections to servers. The rule uses the urilen keyword to detect any URI over 8192 bytes in length. Finally, the rule searches the URI for the specific case-insensitive content /nds/.

DCE/RPC Keywords

License: Protection

The three DCE/RPC keywords described in the following table allow you to monitor DCE/RPC session traffic for exploits. When the system processes rules with these keywords, it invokes the DCE/RPC preprocessor. See Decoding DCE/RPC Traffic for more information.

Note in the table that you should always precede dce_opnum with dce_iface, and you should always precede dce_stub_data with dce_iface + dce_opnum.

You can also use these DCE/RPC keywords in combination with other rule keywords. Note that for DCE/RPC rules, you use the byte_jump, byte_test, and byte_extract keywords with their DCE/RPC arguments selected. For more information, see Using Byte_Jump and Byte_Test and Reading Packet Data into Keyword Arguments.

Cisco recommends that you include at least one content keyword in rules that include DCE/RPC keywords to ensure that the rules engine uses the fast pattern matcher, which increases processing speed and improves performance. 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. See Searching for Content Matches and Use Fast Pattern Matcher for more information.

You can use the DCE/RPC version and adjoining header information as the matching content in the following cases:

• the rule does not include another content keyword
• the rule contains another content keyword, but the DCE/RPC version and adjoining information represent a more unique pattern than the other content

For example, the DCE/RPC version and adjoining information are more likely to be unique than a single byte of content.

You should end qualifying rules with one of the following version and adjoining information content matches:

• For connection-oriented DCE/RPC rules, use the content |05 00 00| (for major version 05, minor version 00, and the request PDU (protocol data unit) type 00).
• For connectionless DCE/RPC rules, use the content |04 00| (for version 04, and the request PDU type 00).

In either case, position the content keyword for version and adjoining information as the last keyword in the rule to invoke the fast pattern matcher without repeating processing already completed by the DCE/RPC preprocessor. Note that placing the content keyword at the end of the rule applies to version content used as a device to invoke the fast pattern matcher, and not necessarily to other content matches in the rule.

See the following sections for more information:

• dce_iface
• dce_opnum
• dce_stub_data

dce_iface

License: Protection

You can use the dce_iface keyword to identify a specific DCE/RPC service.

Optionally, you can also use dce_iface in combination with the dce_opnum and dce_stub_data keywords to further limit the DCE/RPC traffic to inspect. See dce_opnum and dce_stub_data for more information.

A fixed, sixteen-byte Universally Unique Identifier (UUID) identifies the application interface assigned to each DCE/RPC service. For example, the UUID 4b324fc8-670-01d3-1278-5a47bf6ee188 identifies the DCE/RPC lanmanserver service, also known as the srvsvc service, which provides numerous management functions for sharing peer-to-peer printers, files, and SMB named pipes. The DCE/RPC preprocessor uses the UUID and associated header values to track DCE/RPC sessions.

The interface UUID is comprised of five hexadecimal strings separated by hyphens:

You specify the interface by entering the entire UUID including hyphens, as seen in the following UUID for the netlogon interface:

Note that you must specify the first three strings in the UUID in big endian byte order. Although published interface listings and protocol analyzers typically display UUIDs in the correct byte order, you might encounter a need to rearrange the UUID byte order before entering it. Consider the following messenger service UUID shown as it might sometimes be displayed in raw ASCII text with the first three strings in little endian byte order:

You would specify the same UUID for the dce_iface keyword by inserting hyphens and putting the first three strings in big endian byte order as follows:

Although a DCE/RPC session can include requests to multiple interfaces, you should include only one dce_iface keyword in a rule. Create additional rules to detect additional interfaces.

DCE/RPC application interfaces also have interface version numbers. You can optionally specify an interface version with an operator indicating that the version equals, does not equal, is less than, or greater than the specified value.

Both connection-oriented and connectionless DCE/RPC can be fragmented in addition to any TCP segmentation or IP fragmentation. Typically, it is not useful to associate any DCE/RPC fragment other than the first with the specified interface, and doing so may result in a large number of false positives. However, for flexibility you can optionally evaluate all fragments against the specified interface.

The following table summarizes the dce_iface keyword arguments.

dce_opnum

License: Protection

You can use the dce_opnum keyword in conjunction with the DCE/RPC preprocessor to detect packets that identify one or more specific operations that a DCE/RPC service provides.

Client function calls request specific service functions, which are referred to in DCE/RPC specifications as operations. An operation number (opnum) identifies a specific operation in the DCE/RPC header. It is likely that an exploit would target a specific operation.

For example, the UUID 12345678-1234-abcd-ef00-01234567cffb identifies the interface for the netlogon service, which provides several dozen different operations. One of these is operation 6, the NetrServerPasswordSet operation.

You should precede a dce_opnum keyword with a dce_iface keyword to identify the service for the operation. See dce_iface for more information.

You can specify a single decimal value 0 to 65535 for a specific operation, a range of operations separated by a hyphen, or a comma-separated list of operations and ranges in any order.

Any of the following examples would specify valid netlogon operation numbers:

dce_stub_data

License: Protection

You can use the dce_stub_data keyword in conjunction with the DCE/RPC preprocessor to specify that the rules engine should start inspection at the beginning of the stub data, regardless of any other rule options. Packet payload rule options that follow the dce_stub_data keyword are applied relative to the stub data buffer.

DCE/RPC stub data provides the interface between a client procedure call and the DCE/RPC run-time system, the mechanism that provides the routines and services central to DCE/RPC. DCE/RPC exploits are identified in the stub data portion of the DCE/RPC packet. Because stub data is associated with a specific operation or function call, you should always precede dce_stub_data with dce_iface and dce_opnum to identify the related service and operation.

The dce_stub_data keyword has no arguments. See dce_iface and dce_opnum for more information.

SIP Keywords

License: Protection

Four SIP keywords allow you to monitor SIP session traffic for exploits.

Note that the SIP protocol is vulnerable to denial of service (DoS) attacks. Rules addressing these attacks can benefit from rate-based attack prevention. See Adding Dynamic Rule States and Preventing Rate-Based Attacks for more information.

See the following sections for more information:

• sip_header
• sip_body
• sip_method
• sip_stat_code

sip_header

License: Protection

You can use the sip_header keyword to start inspection at the beginning of the extracted SIP request or response header and restrict inspection to header fields.

The sip_header keyword has no arguments. See sip_method and sip_stat_code for more information.

The following example rule fragment points to the SIP header and matches the CSeq header field:

sip_body

License: Protection

You can use the sip_body keyword to start inspection at the beginning of the extracted SIP request or response message body and restrict inspection to the message body.

The sip_body keyword has no arguments.

The following example rule fragment points to the SIP message body and matches a specific IP address in the c (connection information) field in extracted SDP data:

Note that rules are not limited to searching for SDP content. The SIP preprocessor extracts the entire message body and makes it available to the rules engine.

sip_method

License: Protection

A method field in each SIP request identifies the purpose of the request. You can use the sip_method keyword to test SIP requests for specific methods. Separate multiple methods with commas.

You can specify any of the following currently defined SIP methods:

Methods are case-insensitive. You can separate multiple methods with commas.

Because new SIP methods might be defined in the future, you can also specify a custom method, that is, a method that is not a currently defined SIP method. Accepted field values are defined in RFC 2616, which allows all characters except control characters and separators such as =, (, and }. See RFC 2616 for the complete list of excluded separators. When the system encounters a specified custom method in traffic, it will inspect the packet header but not the message.

The system supports up to 32 methods, including the 21 currently defined methods and an additional 11 methods. The system ignores any undefined methods that you might configure. Note that the 32 total methods includes methods specified using the Methods to Check SIP preprocessor option. See Selecting SIP Preprocessor Options for more information.

You can specify only one method when you use negation. For example:

Note, however, that multiple sip_method keywords in a rule are linked with an AND operation. For example, to test for all extracted methods except invite and cancel, you would use two negated sip_method keywords:

Cisco recommends that you include at least one content keyword in rules that include the sip_method keyword to ensure that the rules engine uses the fast pattern matcher, which increases processing speed and improves performance. 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. See Searching for Content Matches and Use Fast Pattern Matcher for more information.

sip_stat_code

License: Protection

A three-digit status code in each SIP response indicates the outcome of the requested action. You can use the sip_stat_code keyword to test SIP responses for specific status codes.

You can specify a one-digit response-type number 1-9, a specific three-digit number 100-999, or a comma-separated list of any combination of either. A list matches if any single number in the list matches the code in the SIP response.

The following table describes the SIP status code values you can specify.

Note also that the rules engine does not use the fast pattern matcher to search for the value specify using the sip_stat_code keyword, regardless of whether your rule includes a content keyword.

GTP Keywords

License: Protection

Three GSRP Tunneling Protocol (GTP) keywords allow you to inspect the GTP command channel for GTP version, message type, and information elements. You cannot use GTP keywords in combination with other intrusion rule keywords such as content or byte_jump. You must use the gtp_version keyword in each rule that uses the gtp_info or gtp_type keyword.

See the following sections for more information:

• gtp_version
• gtp_type
• gtp_info

gtp_version

You can use the gtp_version keyword to inspect GTP control messages for GTP version 0, 1, or 2.

Because different GTP versions define different message types and information elements, you must use this keyword when you use the gtp_type or gtp_info keyword. You can specify the value 0, 1, or 2.

To specify the GTP version:

Step 1 On the Create Rule page, select gtp_version in the drop-down list and click Add Option.

The gtp_version keyword appears.

Step 2 Specify 0, 1, or 2 to identify the GTP version.

gtp_type

Each GTP message is identified by a message type, which is comprised of both a numeric value and a string. You can use the gtp_type keyword in combination with the gtp_version keyword to inspect traffic for specific GTP message types.

You can specify a defined decimal value for a message type, a defined string, or a comma-separated list of either or both in any combination, as seen in the following example:

The system uses an OR operation to match each value or string that you list. The order in which you list values and strings does not matter. Any single value or string in the list matches the keyword. You receive an error if you attempt to save a rule that includes an unrecognized string or an out-of-range value.

Note in the table that different GTP versions sometimes use different values for the same message type. For example, the sgsn_context_request message type has a value of 50 in GTPv0 and GTPv1, but a value of 130 in GTPv2.

The gtp_type keyword matches different values depending on the version number in the packet. In the example above, the keyword matches the message type value 50 in a GTPv0 or GTPv1 packet and the value 130 in a GTPv2 packet. The keyword does not match a packet when the message type value in the packet is not a known value for the version specified in the packet.

If you specify an integer for the message type, the keyword matches if the message type in the keyword matches the value in the GTP packet, regardless of the version specified in the packet.

The following table lists the defined values and strings recognized by the system for each GTP message type.