The Intrusion Rules Editor
An Introduction to Intrusion Rule Editing
License Requirements for the Intrusion Rule Editor
Requirements and Prerequisites for the Intrusion Rule Editor
Rule Anatomy
- The Intrusion Rule Header
- Intrusion Event Details
Custom Rule Creation
Searching for Rules
- Search Criteria for Intrusion Rules
Rule Filtering on the Intrusion Rules Editor Page
Keywords and Arguments in Intrusion Rules

The Intrusion Rules Editor

The following topics describe how to use the intrusion rules editor:

An Introduction to Intrusion Rule Editing

An intrusion rule is a set of keywords and arguments that the system uses to detect attempts to exploit vulnerabilities on your network. As the system analyzes network traffic, it compares packets against the conditions specified in each rule. If the packet data matches all the conditions specified in a rule, the rule triggers. If a rule is an alert rule, it generates an intrusion event. If it is a pass rule, it ignores the traffic. For a drop rule in an inline deployment, the system drops the packet and generates an event. You can view and evaluate intrusion events from the Firepower Management Center web interface.

The Firepower System provides two types of intrusion rules: shared object rules and standard text rules. The Cisco Talos Intelligence Group (Talos) can use shared object rules to detect attacks against vulnerabilities in ways that traditional standard text rules cannot. You cannot create shared object rules. When you write your own intrusion rule, you create a standard text rule.

You can write custom standard text rules to tune the types of events you are likely to see. Note that while this documentation sometimes discusses rules targeted to detect specific exploits, the most successful rules target traffic that may attempt to exploit known vulnerabilities rather than specific known exploits. By writing rules and specifying the rule’s event message, you can more easily identify traffic that indicates attacks and policy evasions.

When you enable a custom standard text rule in a custom intrusion policy, keep in mind that some rule keywords and arguments require that traffic first be decoded or preprocessed in a certain way. This chapter explains the options you must configure in your network analysis policy, which governs preprocessing. Note that if you disable a required preprocessor, the system automatically uses it with its current settings, although the preprocessor remains disabled in the network analysis policy web interface.

Caution

Make sure you use a controlled network environment to test any intrusion rules that you write before you use the rules in a production environment. Poorly written intrusion rules may seriously affect the performance of the system.

In a multidomain deployment, the system displays rules created in the current domain, which you can edit. It also displays rules created in ancestor domains, which you cannot edit. To view and edit rules created in a lower domain, switch to that domain. The system-provided intrusion rules belong to the Global domain. Administrators in descendant domains can make local editable copies of these system rules.

License Requirements for the Intrusion Rule Editor

FTD License

Threat

Classic License

Protection

Requirements and Prerequisites for the Intrusion Rule Editor

Model Support

Any.

Supported Domains

Any

User Roles

Admin
Intrusion Admin

Rule Anatomy

All standard text rules contain two logical sections: the rule header and the rule options. The rule header contains:

the rule's action or type
the protocol
the source and destination IP addresses and netmasks
direction indicators showing the flow of traffic from source to destination
the source and destination ports

The rule options section contains:

event messages
keywords and their parameters and arguments
patterns that a packet’s payload must match to trigger the rule
specifications of which parts of the packet the rules engine should inspect

The following diagram illustrates the parts of a rule:

Diagram illustrating the components of a standard text rule: the rule header and the rule options.

Note that the options section of a rule is the section enclosed in parentheses. The intrusion rules editor provides an easy-to-use interface to help you build standard text rules.

The Intrusion Rule Header

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

Diagram illustrating the parts of a rule header: Type, Protocol, Source IP, Source Port, Operator, Destination, and Destination Port.

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

Table 1. Rule Header Values
Rule Header Component	Example Value	This Value...
Action	`alert`	Generates an intrusion event when triggered.
Protocol	`tcp`	Tests TCP traffic only.
Source IP Address	`$EXTERNAL_NET`	Tests traffic coming from any host that is not on your internal network.
Source Ports	`any`	Tests traffic coming from any port on the originating host.
Operator	`->`	Tests external traffic (destined for the web servers on your network).
Destination IP Address	`$HTTP_SERVERS`	Tests traffic to be delivered to any host specified as a web server on your internal network.
Destination Ports	`$HTTP_PORTS`	Tests traffic delivered to an HTTP port on your internal network.

Note

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

Intrusion Rule Header Action

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.

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 intrusion rules editor, you select the rule type from the Action list.

Intrusion Rule Header Protocol

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.

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.

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 Intrusion Rules editor, you select the protocol type from the Protocol list.

Intrusion Rule Header Direction

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.

Table 2. Directional Options in Rule Headers
Use...	To Test...
Directional	only traffic from the specified source IP address to the specified destination IP address
Bidirectional	all traffic traveling between the specified source and destination IP addresses

Intrusion Rule Header Source and Destination IP Addresses

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 intrusion rules editor, you specify source and destination IP addresses in the Source IPs and Destination IPs fields.

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, or a network variable. 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.

IP Address Syntax in Intrusion Rules

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

Table 3. Source/Destination IP Address Syntax
To Specify...	Use...	Example
any IP address	`any`	`any`
a specific IP address	the IP address Note that you would not mix IPv4 and IPv6 source and destination addresses in the same rule.	`192.168.1.1` `2001:db8::abcd`
a list of IP addresses	brackets (`[]`) to enclose the IP addresses and commas to separate them	`[192.168.1.1,192.168.1.15]` `[2001:db8::b3ff, 2001:db8::0202]`
a block of IP addresses	IPv4 CIDR block or IPv6 address prefix notation	`192.168.1.0/24` `2001:db8::/32`
anything except a specific IP address or set of addresses	the `!` character before the IP address or addresses you want to negate	`!192.168.1.15` !`2001:db8::0202:b3ff:fe1e`
anything in a block of IP addresses except one or more specific IP addresses	a block of addresses followed by a list of negated addresses or blocks	`[10.0.0/8, !10.2.3.4, !10.1.0.0/16]` `[2001:db8::/32, !2001:db8::8329, !2001:db8::0202]`
IP addresses defined by a network variable	the variable name, in uppercase letters, preceded by `$` Note that preprocessor rules can trigger events regardless of the hosts defined by network variables used in intrusion rules.	`$HOME_NET`
all IP addresses except addresses defined by an IP address variable	the variable name, in uppercase letters, preceded by `!$`	`!$HOME_NET`

The following descritpions provide additional information on some of the IP address entry methods.

Any IP Address

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 anyin the Source IPs and Destination IPs fields and evaluates packets with any IPv4 or IPv6 source or destination address:


alert tcp any any -> any any

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

Multiple IP Addresses

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:


[192.168.1.100,192.168.1.103,192.168.1.105]

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


[192.168.1.100,2001:db8::1234,192.168.1.105]

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.

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

IP Addresses Negation

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.

Intrusion Rule Header Source and Destination Ports

Within the intrusion rules editor, you specify source and destination ports in the Source Port and Destination Port fields.

Port Syntax in Intrusion Rules

The Firepower System 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.

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


80, 8080, 8138, 8600-9000, !8650-8675

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:


[80, 8080, 8138, 8600-9000, !8650-8675]

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


![20, 22, 23]

The following table summarizes the syntax you can use:

Table 4. Source/Destination Port Syntax
To Specify...	Use	Example
any port	`any`	`any`
a specific port	the port number	`80`
a range of ports	a dash between the first and last port number in the range	`80-443`
all ports less than or equal to a specific port	a dash before the port number	`-21`
all ports greater than or equal to a specific port	a dash after the port number	`80-`
all ports except a specific port or range of ports	the `!` character before the port, port list, or range of ports you want to negate Note that you can logically use negation with all port designations except any, which if negated would indicate no port.	`!20`
all ports defined by a port variable	the variable name, in uppercase letter, preceded by `$`	`$HTTP_PORTS`
all ports except ports defined by a port variable	the variable name, in uppercase letter, preceded by `!$`	`!$HTTP_PORTS`

Intrusion Event Details

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

Message

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

Tip

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

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

Classification

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

Table 5. Rule Classifications
Number	Classification Name	Description
1	not-suspicious	Not Suspicious Traffic
2	unknown	Unknown Traffic
3	bad-unknown	Potentially Bad Traffic
4	attempted-recon	Attempted Information Leak
5	successful-recon-limited	Information Leak
6	successful-recon-largescale	Large Scale Information Leak
7	attempted-dos	Attempted Denial of Service
8	successful-dos	Denial of Service
9	attempted-user	Attempted User Privilege Gain
10	unsuccessful-user	Unsuccessful User Privilege Gain
11	successful-user	Successful User Privilege Gain
12	attempted-admin	Attempted Administrator Privilege Gain
13	successful-admin	Successful Administrator Privilege Gain
14	rpc-portmap-decode	Decode of an RPC Query
15	shellcode-detect	Executable Code was Detected
16	string-detect	A Suspicious String was Detected
17	suspicious-filename-detect	A Suspicious Filename was Detected
18	suspicious-login	An Attempted Login Using a Suspicious Username was Detected
19	system-call-detect	A System Call was Detected
20	tcp-connection	A TCP Connection was Detected
21	trojan-activity	A Network Trojan was Detected
22	unusual-client-port-connection	A Client was Using an Unusual Port
23	network-scan	Detection of a Network Scan
24	denial-of-service	Detection of a Denial of Service Attack
25	non-standard-protocol	Detection of a Non-Standard Protocol or Event
26	protocol-command-decode	Generic Protocol Command Decode
27	web-application-activity	Access to a Potentially Vulnerable Web Application
28	web-application-attack	Web Application Attack
29	misc-activity	Misc Activity
30	misc-attack	Misc Attack
31	icmp-event	Generic ICMP Event
32	inappropriate-content	Inappropriate Content was Detected
33	policy-violation	Potential Corporate Privacy Violation
34	default-login-attempt	Attempt to Login By a Default Username and Password
35	sdf	Sensitive Data
36	malware-cnc	Known malware command and control traffic
37	client-side-exploit	Known client side exploit attempt
38	file-format	Known malicious file or file based exploit

Custom Classification

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


Argument	Description
Classification Name	The name of the classification. The page is difficult to read if you use more than 40 characters. The following characters are not supported: `<>()\'"&$;` and the space character.
Classification Description	A description of the classification. You can use alphanumeric characters and spaces. The following characters are not supported: `<>()\'"&$;`
Priority	High, medium, or low.

Custom Priority

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

Custom Reference

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

Table 6. External Attack Identification Systems
System ID	Description	Example ID
`bugtraq`	Bugtraq page	`8550`
`cve`	Common Vulnerabilities and Exposure ID	`2020-9607`
`mcafee`	McAfee page	`98574`
`url`	Website reference	`www.example.com?exploit=14`
`msb`	Microsoft security bulletin	`MS11-082`
`nessus`	Nessus page	`10039`
`secure-url`	Secure Website Reference (https://...)	`intranet/exploits/exploit=14` Note that you can use `secure-url` with any secure website.

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


id_system,id

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

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


cve,2020-9607

Note the following when adding references to a rule:

Do not use a space after the comma.
Do not use uppercase letters in the system ID.

Adding a Custom Classification

In a multidomain deployment, the system displays custom classifications created in the current domain, and you can set the priorities for these classifications. It also displays custom classifications created in ancestor domains, but you cannot set the priorities for these classifications. To view and edit custom classifications created in a lower domain, switch to that domain.

Procedure

Step 1	While creating or editing a rule, choose Edit Classifications from the Classification drop-down list. If View Classifications displays instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.
Step 2	Enter a Classification Name and Classification Description as described in Intrusion Event Details.
Step 3	Choose a priority for the classification from the Priority drop-down list.
Step 4	Click Add.
Step 5	Click Done.

What to do next

Continue with creating or editing the rule. See Writing New Rules or Modifying Existing Rules for more information.

Defining an Event Priority

Procedure

Step 1	While creating or editing a rule, choose `priority` from the Detection Options drop-down list.
Step 2	Click Add Option.
Step 3	Choose a value from the priority drop-down list.
Step 4	Click Save.

What to do next

Continue with creating or editing the rule. See Writing New Rules or Modifying Existing Rules for more information.

Defining an Event Reference

Procedure

Step 1	While creating or editing a rule, choose `reference` from the Detection Options drop-down list.
Step 2	Click Add Option.
Step 3	Enter a value in the reference field as described in Intrusion Event Details.
Step 4	Click Save.

What to do next

Continue with creating or editing the rule. See Writing New Rules or Modifying Existing Rules for more information.

Custom Rule Creation

You can create a custom intrusion rule by:

creating your own standard text rules
saving existing standard text rules as new
saving system-provided shared object rules as new
in a multidomain deployment, saving ancestor rules as new in a descendant domain
importing a local rule file

The system saves the custom rule in the local rule category, regardless of the method you used to create it.

When you create a custom intrusion rule, the system assigns it a unique rule number, which has the format GID:SID:Rev. The elements of this number are:

GID: Generator ID. For all standard text rules, this value is 1 (Global domain or legacy GID) or 1000 - 2000 (descendant domains). For all shared object rules you save as new, this value is 1.
SID: Snort ID. Indicates whether the rule is a local rule of a system rule. When you create a new rule, the system assigns the next available SID for a local rule.; SID numbers for local rules start at 1000000, and the SID for each new local rule is incremented by one.
Rev: The revision number. For a new rule, the revision number is one. Each time you modify a custom rule the revision number increments by one.

In a custom standard text rule, you set the rule header settings and the rule keywords and arguments. You can use the rule header settings to focus the rule to only match traffic using a specific protocol and traveling to or from specific IP addresses or ports.

In a custom system-provided standard text rule or shared object rule, you are limited to modifying rule header information such as the source and destination ports and IP addresses. You cannot modify the rule keywords or arguments.

Modifying header information for a shared object rule and saving your changes creates a new instance of the rule with a generator ID (GID) of 1 (Global domain) or 1000 - 2000 (descendant domains) and the next available SID for a custom rule. The system links the new instance of the shared object rule to the reserved soid keyword, which maps the rule you create to the rule created by the Cisco Talos Intelligence Group (Talos). You can delete instances of a shared object rule that you create, but you cannot delete shared object rules created by Talos.

Writing New Rules

Procedure

Step 1

Access the intrusion rules using either of the following methods:

Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
Choose Objects > Intrusion Rules.

Step 2

Click Create Rule.

Step 3

Enter a value in the Message field.

Step 4

Choose a value from each of the following drop-down lists:

Classification
Action
Protocol
Direction

Step 5

Enter values in the following fields:

Source IPs
Destination IPs
Source Port
Destination Port

The system uses the value any if you do not specify a value for these fields.

Note

The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal IP addresses to constrain this configuration can have unexpected results.

Step 6

Choose a value from the Detection Options drop-down list.

Step 7

Click Add Option.

Step 8

Enter any arguments for the keyword you added.

Step 9

Optionally, repeat steps 6 to 8.

Step 10

If you added multiple keywords, you can:

Reorder keywords — Click the up or down arrow next to the keyword you want to move.
Delete a keyword — Click the X next to that keyword.

Step 11

Click Save As New.

What to do next

Enable your new or changed rules within the appropriate intrusion policy; see Viewing Intrusion Rules in an Intrusion Policy.
Deploy configuration changes; see Deploy Configuration Changes.

Modifying Existing Rules

You can modify custom intrusion rules. In a multidomain deployment, you can modify custom intrusion rules that belong to the current domain only.

You can save system-provided rules and rules belonging to ancestor domains as new custom rules in the local rule category, which you can then modify.

Procedure

Step 1

Access the intrusion rules using either of the following methods:

Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
Choose Objects > Intrusion Rules.

Step 2

Locate the rule you want to modify. You have the following choices:

Navigate through the folders to the rule.
Search for the rule; see Searching for Rules.
Filter for the group to which the rule belongs; see Filtering Rules.

Step 3

Click Edit ( edit icon ) next to the rule or, in the case of search results, click the rule message.

If View ( view button ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.

Step 4

Modify the rule as appropriate for the rule type.

Note

Do not modify the protocol for a shared object rule; doing so would render the rule ineffective.

Step 5

You have the following choices:

Click Save if you are editing a custom rule and want to overwrite the current version of that rule.
Click Save As New if you are editing a system-provided rule or any rule belonging to an ancestor domain, or if you are editing a custom rule and want to save the changes as a new rule.

What to do next

If you want to use the local modification of the rule instead of the system-provided rule, deactivate the system-provided rule by using the procedures at Intrusion Rule States and activate the local rule.
Deploy configuration changes; see Deploy Configuration Changes.

Viewing Rule Documentation

From the Rule Edit page, you can view rule documentation supplied by the Cisco Talos Intelligence Group (Talos). While viewing, you can click external references to view additional informaton provided by Talos. You can also click Context Explorer to view contextual information for events generated by the rule.

Procedure

Step 1

Access an intrusion rule using either of the following methods:

Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
Choose Objects > Intrusion Rules.

Step 2

Locate the rule you want to view. You have the following choices:

Navigate through the folders to the rule.
Search for the rule; see Searching for Rules.
Filter for the group to which the rule belongs; see Filtering Rules.

Step 3

Click Edit ( edit icon ) next to the rule or, in the case of search results, click the rule message.

If View ( view button ) appears instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the configuration.

Step 4

Click View Documentation.

Step 5

Optionally, click either of the following links:

References—see Keyword Filtering and Custom Reference in Intrusion Event Details for information on available external references.
Context Explorer—see for information on viewing event data for the rule in the context explorer.

Tip

Selecting an external link closes the documentation pop-up window; to exit the rule edit page without modifying the rule, select any menu path.

Adding Comments to Intrusion Rules

You can add comments to any intrusion rule. Such comments can be helpful to provide context and additional information about the rule and the exploit or policy violation it identifies.

In a multidomain deployment, the system displays comments created in the current domain, which you can delete. It also displays comments created in ancestor domains, which you cannot delete. To view comments created in a lower domain, switch to that domain.

Procedure

Step 1

Access the intrusion rules using either of the following methods:

Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
Choose Objects > Intrusion Rules.

Step 2

Locate the rule you want to annotate. You have the following choices:

Navigate through the folders to the rule.
Search for the rule; see Searching for Rules.
Filter for the group where the rule belongs; see Filtering Rules.

Step 3

Click Edit ( edit icon ) next to the rule or, in the case of search results, click the rule message.

If View ( view button ) appears next to a rule instead, the rule belongs to an ancestor policy, or you do not have permission to modify the rule.

Step 4

Click Rule Comment.

Step 5

Enter your comment in the text box.

Step 6

Click Add Comment.

Tip

You can also add and view rule comments in an intrusion event’s packet view.

What to do next

Continue with creating or editing the rule. See Writing New Rules or Modifying Existing Rules for more information.

Deleting Custom Rules

You can delete custom rules if the rules are not currently enabled in an intrusion policy. You cannot delete either standard text rules or shared object rules provided by the system. In a multidomain deployment, you can delete local rules created in the current domain only.

The system stores deleted rules in the deleted category, and you can use a deleted rule as the basis for a new rule. The Rules page in an intrusion policy does not display the deleted category, so you cannot enable deleted custom rules.

Tip

Custom rules include shared object rules that you save with modified header information. The system also saves these in the local rule category and lists them with a GID of 1 (Global domain or legacy GID) or 1000 - 2000 (descendant domains). You can delete your modified version of a shared object rule, but you cannot delete the original shared object rule.

Procedure

Step 1

Access the intrusion rules using either of the following methods:

Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
Choose Objects > Intrusion Rules.

Step 2

You have two choices:

Delete all local rules — Click Delete Local Rules, then click OK.
Delete a single rule — Choose Local Rules from the Group Rules By drop-down, click Delete () next to a rule you want to delete, and click OK to confirm the deletion.

Searching for Rules

The Firepower System provides thousands of standard text rules, and the Cisco Talos Intelligence Group (Talos) continues to add rules as new vulnerabilities and exploits are discovered. You can easily search for specific rules so that you can activate, deactivate, or edit them.

Procedure

Step 1	Access the intrusion rules using either of the following methods: Choose Policies > Access Control > Intrusion, and click Intrusion Rules. Choose Objects > Intrusion Rules.
Step 2	Click Search on the toolbar.
Step 3	Add search criteria.
Step 4	Click Search.

What to do next

If you want to view or edit a located rule (or a copy of the rule, if it is a system rule), click the hyperlinked rule message. See Writing New Rules or Modifying Existing Rules for more information.

Search Criteria for Intrusion Rules

The following table describes the available search options:

Table 7. Rule Search Criteria
Option	Description
Signature ID	To search for a single rule based on Snort ID (SID), enter an SID number. To search for multiple rules, enter a comma-separated list of SID numbers. This field has an 80-character limit.
Generator ID	To search for standard text rules, select 1. To search for shared object rules, select 3.
Message	To search for a rule with a specific message, enter a single word from the rule message in the Message field. For example, to search for DNS exploits, you would enter `DNS`, or to search for buffer overflow exploits, enter `overflow`.
Protocol	To search rules that evaluate traffic of a specific protocol, select the protocol. If you do not select a protocol, search results contain rules for all protocols.
Source Port	To search for rules that inspect packets originating from a specified port, enter a source port number or a port-related variable.
Destination Port	To search for rules that inspect packets destined for a specific port, enter a destination port number or a port-related variable.
Source IP	To search for rules that inspect packets originating from a specified IP address, enter a source IP address or an IP address-related variable.
Destination IP	To search for rules that inspect packets destined for a specified IP address, enter a destination IP address or an IP address-related variable.
Keyword	To search for specific keywords, you can use the keyword search options. You select a keyword and enter a keyword value for which to search. You can also precede the keyword value with an exclamation point (`!`) to match any value other than the specified value.
Category	To search for rules in a specific category, select the category from the Category list.
Classification	To search for rules that have a specific classification, select the classification name from the Classification list.
Rule State	To search for rules within a specific policy and a specific rule state, select the policy from the first Rule State list, and choose a state from the second list to search for rules set to Generate Events, Drop and Generate Events, or Disabled.

Rule Filtering on the Intrusion Rules Editor Page

You can filter the rules on the intrusion rules editor page to display a subset of rules. This can be useful, for example, when you want to modify a rule or change its state but have difficulty finding it among the thousands of rules available.

When you enter a filter, the page displays any folder that includes at least one matching rule, or a message when no rule matches.

Filtering Guidelines

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

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

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

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

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

Tip

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

Keyword Filtering

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


keyword:argument

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

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

Tip

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

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

Table 8. Rule Filter Keywords
Keyword	Description	Example
`arachnids`	Returns one or more rules based on all or part of the Arachnids ID in a rule reference.	`arachnids:181`
`bugtraq`	Returns one or more rules based on all or part of the Bugtraq ID in a rule reference.	`bugtraq:2120`
`cve`	Returns one or more rules based on all or part of the CVE number in a rule reference.	`cve:2003-0109`
`gid`	The argument `1` returns standard text rules. The argument `3` returns shared object rules.	`gid:3`
`mcafee`	Returns one or more rules based on all or part of the McAfee ID in a rule reference.	`mcafee:10566`
`msg`	Returns one or more rules based on all or part of the rule Message field, also known as the event message.	`msg:chat`
`nessus`	Returns one or more rules based on all or part of the Nessus ID in a rule reference.	`nessus:10737`
`ref`	Returns one or more rules based on all or part of a single alphanumeric string in a rule reference or in the rule Message field.	`ref:MS03-039`
`sid`	Returns the rule with the exact Snort ID.	`sid:235`
`url`	Returns one or more rules based on all or part of the URL in a rule reference.	`url:faqs.org`

Character String Filtering

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

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

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

Combination Keyword and Character String Filtering

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

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

url:at login attempt cve:200
login attempt cve:200 url:at
login cve:200 attempt url:at

Filtering Rules

On the Intrusion Rules page, you can filter rules into subsets so you can more easily find specific rules. You can then use any of the page features, including choosing any of the features available in the context menu.

Rule filtering can be particularly useful to locate a specific rule to edit.

Procedure

Step 1

Access the intrusion rules using either of the following methods:

Choose Policies > Access Control > Intrusion, and click Intrusion Rules.
Choose Objects > Intrusion Rules.

Step 2

Prior to filtering, you have the following choices:

Expand any rule group you want to expand. Some rule groups also have sub-groups that you can expand.
Expanding a group on the original, unfiltered page can be useful when you expect that a rule might be in that group. The group remains expanded when the subsequent filter results in a match in that folder, and when you return to the original, unfiltered page by clicking filter Clear ().
Choose a different grouping method from the Group Rules By drop-down list.

Step 3

Enter filter constraints in the text box next to Filter ( filter icon ) under the Group Rules By list.

Step 4

Press Enter.

Note

Clear the current filtered list by clicking filter Clear ( clear icon ).

Keywords and Arguments in Intrusion Rules

Using the rules language, you can specify the behavior of a rule by combining keywords. Keywords and their associated values (called arguments) dictate how the system evaluates packets and packet-related values that the rules engine tests. The Firepower System currently supports keywords that allow you to perform inspection functions, such as content matching, protocol-specific pattern matching, and state-specific matching. You can define up to 100 arguments per keyword, and combine any number of compatible keywords to create highly specific rules. This helps decrease the chance of false positives and false negatives and focus the intrusion information you receive.

Note that you can also use adaptive profile updates in passive deployments to dynamically adapt active rule processing for specific packets based on rule metadata and host information.

Keywords described in this section are listed under Detection Options in the rules editor.

The content and protected_content Keywords

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

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

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

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

content

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

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

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

Caution

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

protected_content

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

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

Table 9. protected_content Option Exceptions
Option	Description
Hash Type	New option for the `protected_content` rule keyword.
Case Insensitive	Not supported
Within	Not supported
Depth	Not supported
Length	New option for the `protected_content` rule keyword.
Use Fast Pattern Matcher	Not supported
Fast Pattern Matcher Only	Not supported
Fast Pattern Matcher Offset and Length	Not supported

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

Caution

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

Basic content and protected_content Keyword Arguments

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.

Case Insensitive

Note

This option is not supported when configuring 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.

Hash Type

Note

This option is only configurable with 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.

Raw Data

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 contentor protected_contentkeyword with any HTTP content option.

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.

Not

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_contentkeyword with the Not option selected, you must also include in the rule at least one other content or protected_contentkeyword without the Not option selected.

Caution

Do not create a rule that includes only one content or protected_contentkeyword 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.

Tip

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

content and protected_content Keyword Search Locations

You can use search location options to specify where to begin searching for the specified content and how far to continue searching.

Permitted Combinations: content Search Location Arguments

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.

Tip

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

Permitted Combinations: protected_content Search Location Arguments

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.

content and protected_content Search Location Arguments

Depth

Note

This option is only supported when configuring 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.

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.

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.

Overview: HTTP content and protected_content Keyword Arguments

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 :

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:

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 intrusion rules editor for complete evaluation, including evaluation of the restricted fields.

HTTP content and protected_content Keyword Arguments

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.

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.

Note

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.

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

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.

Note the following:

You cannot use this option in combination with the pcre keyword HTTP cookie (C) option to search the same content.
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.

Note the following:

You cannot use this option in combination with the pcre keyword HTTP raw cookie (K) option to search the same content.
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.

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.

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.

Overview: content Keyword Fast Pattern Matcher

Note

These options are not supported when configuring 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:

alert tcp any any -> any 80 (msg:"Exploit"; content:"GET";

http_method; nocase; content:"/exploit.cgi"; http_uri;

nocase;)

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.

content Keyword Fast Pattern Matcher Arguments

Use Fast Pattern Matcher

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

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.

Fast Pattern Matcher Only

This 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_math
- byte_extract
- base64_decode

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:


offset,length

For example, for the content:

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

1,5

the fast pattern matcher searches only for the content 23456.

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

The replace Keyword

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

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

Note

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

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


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

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

The following are example uses of the replace keyword:

If the system detects an incoming packet that contains an exploit, you can replace the malicious string with a harmless one. Sometimes this technique is more successful than simply dropping the offending packet. In some attack scenarios, the attacker simply resends the dropped packet until it bypasses your network defenses or floods your network. By substituting one string for another rather than dropping the packet, you may trick the attacker into believing that the attack was launched against a target that was not vulnerable.
If you are concerned about reconnaissance attacks that try to learn whether you are running a vulnerable version of, for example, a web server, then you can detect the outgoing packet and replace the banner with your own text.

Note

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

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

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

The byte_jump Keyword

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

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

Table 10. Required byte_jump Arguments
Argument	Description
Bytes	The number of bytes to pick up from the packet. If used without DCE/RPC, the allowed values are 0 to 10, with the following restrictions: If used with the `From End` argument, bytes can be 0. If Bytes is 0, the extracted value is 0. If you specify a number of bytes other than 1, 2, or 4, you must specify a Number Type (hexadecimal, octal, or decimal.) If used with DCE/RPC, allowed values are 1, 2, and 4.
Offset	The number of bytes into the payload to start processing. The `offset` counter starts at byte 0, so calculate the `offset` value by subtracting 1 from the number of bytes you want to jump forward from the beginning of the packet payload or the last successful content match. You can specify -65535 to 65535 bytes. You can also use an existing `byte_extract` variable or `byte_math` result to specify the value for this argument.

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

Table 11. Additional Optional byte_jump Arguments
Argument	Description
Relative	Makes the offset relative to the last pattern found in the last successful content match.
Align	Rounds the number of converted bytes up to the next 32-bit boundary.
Multiplier	Indicates the value by which the rules engine should multiply the `byte_jump` value obtained from the packet to get the final `byte_jump` value. That is, instead of skipping the number of bytes defined in a specified byte segment, the rules engine skips that number of bytes multiplied by an integer you specify with the Multiplier argument.
Post Jump Offset	The number of bytes -65535 through 65535 to skip forward or backward after applying other `byte_jump` arguments. A positive value skips forward and a negative value skips backward. Leave the field blank or enter `0` to disable. Note that some `byte_jump` arguments do not apply when you select the DCE/RPC argument.
From Beginning	Indicates that the rules engine should skip the specified number of bytes in the payload starting from the beginning of the packet payload, instead of from the current position in the packet.
From End	The jump will originate from the byte that follows the last byte of the buffer.
Bitmask	Applies the specified hexadecimal bitmask using the AND operator to the bytes extracted from the Bytes argument. A bitmask can be 1 to 4 bytes. The result will be right-shifted by the number of bits equal to the number of trailing zeros in the mask.

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

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

Table 12. Byte-Ordering byte_jump Arguments
Argument	Description
Big Endian	Processes data in big endian byte order, which is the default network byte order.
Little Endian	Processes data in little endian byte order.
DCE/RPC	Specifies a `byte_jump` keyword for traffic processed by the DCE/RPC preprocessor. The DCE/RPC preprocessor determines big endian or little endian byte order, and the Number Type and Endian arguments do not apply. When you enable this argument, you can also use `byte_jump` in conjunction with other specific DCE/RPC keywords.

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

Table 13. Number Type Arguments
Argument	Description
Hexadecimal String	Represents converted string data in hexadecimal format.
Decimal String	Represents converted string data in decimal format.
Octal String	Represents converted string data in octal format.

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

Bytes = 4
Offset = 12
Relative enabled
Align enabled

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

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

Bytes = 4
Offset = 12
From Beginning enabled
Multiplier = 2

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

The byte_test Keyword

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

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

Table 14. Required byte_test Arguments
Argument	Description
Bytes	The number of bytes to calculate from the packet. If used without DCE/RPC, the allowed values are 1 to 10. However, if you specify a number of bytes other than 1, 2, or 4, you must specify a Number Type (hexadecimal, octal, or decimal.). If used with DCE/RPC, allowed values are 1, 2, and 4.
Value	Value to test, including its operator. Supported operators: <, >, =, !, &, ^, !>, !<, !=, !&, or !^. For example, if you specify `!1024`, `byte_test` would convert the specified number, and if it did not equal 1024, it would generate an event (if all other keyword parameters matched). Note that ! and != are equivalent. You can also use an existing `byte_extract` variable or `byte_math` result to specify the value for this argument.
Offset	The number of bytes into the payload to start processing. The `offset` counter starts at byte 0, so calculate the `offset` value by subtracting 1 from the number of bytes you want to count forward from the beginning of the packet payload or the last successful content match. You can use an existing `byte_extract` variable or `byte_math` result to specify the value for this argument.

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

Table 15. Additional Optional byte_test Arguments
Argument	Description
Bitmask	Applies the specified hexadecimal bitmask using the AND operator to the bytes extracted from the Bytes argument. A bitmask can be 1 to 4 bytes. The result will be right-shifted by the number of bits equal to the number of trailing zeros in the mask.
Relative	Makes the offset relative to the last successful pattern match.

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

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

Table 16. Byte-Ordering byte_test Arguments
Argument	Description
Big Endian	Processes data in big endian byte order, which is the default network byte order.
Little Endian	Processes data in little endian byte order.
DCE/RPC	Specifies a `byte_test` keyword for traffic processed by the DCE/RPC preprocessor. The DCE/RPC preprocessor determines big endian or little endian byte order, and the Number Type and Endian arguments do not apply. When you enable this argument, you can also use `byte_test` in conjunction with other specific DCE/RPC keywords.

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

Table 17. Number Type byte-test Arguments
Argument	Description
Hexadecimal String	Represents converted string data in hexadecimal format.
Decimal String	Represents converted string data in decimal format.
Octal String	Represents converted string data in octal format.

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.

The byte_extract Keyword

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

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

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

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

Table 18. Required byte_extract Arguments
Argument	Description
Bytes to Extract	The number of bytes to pick up from the packet. If you specify a number of bytes other than 1, 2, or 4, you must specify a Number Type (hexadecimal, octal, or decimal.)
Offset	The number of bytes into the payload to begin extracting data. You can specify -65535 to 65535 bytes. The offset counter starts at byte 0, so calculate the offset value by subtracting 1 from the number of bytes you want to count forward. For example, specify `7` to count forward 8 bytes. The rules engine counts forward from the beginning of the packet payload or, if you also specify Relative, after the last successful content match. Note that you can specify negative numbers only when you also specify Relative. You can use an existing `byte_math` result to specify the value for this argument.
Variable Name	The variable name to use in arguments for other detection keywords. You can specify an alphanumeric string that must begin with a letter.

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

Table 19. Additional Optional byte_extract Arguments
Argument	Description
Multiplier	A multiplier for the value extracted from the packet. You can specify 0 to 65535. If you do not specify a multiplier, the default value is 1.
Align	Rounds the extracted value to the nearest 2-byte or 4-byte boundary. When you also select Multiplier, the system applies the multiplier before the alignment.
Relative	Makes Offset relative to the end of the last successful content match instead of the beginning of the payload.
Bitmask	Applies the specified hexadecimal bitmask using the AND operator to the bytes extracted from the Bytes to Extract argument. A bitmask can be 1 to 4 bytes. The result will be right-shifted by the number of bits equal to the number of trailing zeros in the mask.

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

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

Table 20. Byte-Ordering byte_extract Arguments
Argument	Description
Big Endian	Processes data in big endian byte order, which is the default network byte order.
Little Endian	Processes data in little endian byte order.
DCE/RPC	Specifies a `byte_extract` keyword for traffic processed by the DCE/RPC preprocessor. The DCE/RPC preprocessor determines big endian or little endian byte order, and the Number Type and Endian arguments do not apply. When you enable this argument, you can also use `byte_extract` in conjunction with other specific DCE/RPC keywords.

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

Table 21. Number Type byte_extract arguments
Argument	Description
Hexadecimal String	Reads extracted string data in hexadecimal format.
Decimal String	Reads extracted string data in decimal format.
Octal String	Reads extracted string data in octal format.

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

Bytes to Extract = 4
Variable Name = var
Offset = 8
Relative = enabled

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

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

Table 22. Arguments Accepting a byte_extract Variable
Keyword	Argument
content	Depth, Offset, Distance, Within
byte_jump	Offset
byte_test	Offset, Value
byte_math	RValue, Offset
isdataat	Offset

The byte_math Keyword

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

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

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

Table 23. Required byte_math Arguments
Argument	Description
Bytes	The number of bytes to calculate from the packet. If used without DCE/RPC, the allowed values are 1 to 10: Bytes can be 1 to 10 when the operator is +, -. *, or /. Bytes can be 1 to 4 when the operator is << or >>. If you specify a number of bytes other than 1, 2, or 4, you must specify a Number Type (hexadecimal, octal, or decimal.) If used with DCE/RPC, allowed values are 1, 2, and 4.
Offset	The number of bytes into the payload to start processing. The `offset` counter starts at byte 0, so calculate the `offset` value by subtracting 1 from the number of bytes you want to jump forward from the beginning of the packet payload or (if you specified Relative) from the last successful content match. You can specify -65535 to 65535 bytes. You can also specify the `byte_extract` variable here.
Operator	+, -, *, /, <<, or >>
RValue	The value following the operator. This can be an unsigned integer or a variable passed from `byte_extract`.
Result Variable	The name of the variable into which the result of the `byte_math` calculation will be stored. You can use this variable as an argument in other keywords. This value is stored as an unsigned integer. This variable name: Must use alphanumeric characters Must not begin with a number May include special characters supported by the Microsoft filename/variable name convention Cannot consist entirely of special characters

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

Table 24. Additional Optional byte_math Arguments
Argument	Description
Relative	Makes the offset relative to the last pattern found in the last successful content match instead of the beginning of the payload.
Bitmask	Applies the specified hexadecimal bitmask using the AND operator to the bytes extracted from the Bytes argument. A bitmask can be 1 to 4 bytes. The result will be right-shifted by the number of bits equal to the number of trailing zeros in the mask.

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

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

Table 25. Byte-Ordering byte_math Arguments
Argument	Description
Big Endian	Processes data in big endian byte order, which is the default network byte order.
Little Endian	Processes data in little endian byte order.
DCE/RPC	Specifies a `byte_math` keyword for traffic processed by the DCE/RPC preprocessor. The DCE/RPC preprocessor determines big endian or little endian byte order, and the Number Type and Endian arguments do not apply. When you enable this argument, you can also use `byte_math` in conjunction with other specific DCE/RPC keywords.

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

Table 26. Number Type Arguments
Argument	Description
Hexadecimal String	Represents string data in hexadecimal format.
Decimal String	Represents string data in decimal format.
Octal String	Represents string data in octal format.

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

Bytes = 2
Offset = 0
Operator = *
RValue = height
Result Variable = area

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

Table 27. Arguments Accepting a byte_math Variable
Keyword	Argument
byte_jump	Offset
byte_test	Offset, Value
byte_extract	Offset
isdataat	Offset

Overview: The pcre Keyword

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 intrusion rules editor, enter the full value in the following format:


!/pcre/ ismxAEGRBUIPHDMCKSY

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.

Table 28. Escaped PCRE Characters
You must escape...	with a backslash...	or Hex code...
# (hash mark)	\#	\x23
; (semicolon)	\;	\x3B
\| (vertical bar)	\\|	\x7C
: (colon)	\:	\x3A

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.

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 intrusion rules editor does not display quotation marks when you display a rule after saving it.

pcre Syntax

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

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.

Table 29. PCRE Metacharacters
Metacharacter	Description	Example
`.`	Matches any character except newlines. If `s` is used as a modifying option, it also includes newline characters.	`abc.` matches `abcd`, `abc1`, `abc#`, and so on.
`*`	Matches zero or more occurrences of a character or expression.	`abc*` matches `abc`, `abcc`, `abccc`, `abccccc`, and so on.
`?`	Matches zero or one occurrence of a character or expression.	`abc?` matches `abc`.
`+`	Matches one or more occurrences of a character or expression.	`abc+` matches `abc`, `abcc`, `abccc`, `abccccc`, and so on.
`()`	Groups expressions.	`(abc)+` matches `abc`, `abcabc`, `abcabcabc` and so on.
`{}`	Specifies a limit for the number of matches for a character or expression. If you want to set a lower and upper limit, separate the lower limit and upper limit with a comma.	`a{4,6}` matches `aaaa`, `aaaaa`, or `aaaaaa`. `(ab){2}` matches `abab`.
`[]`	Allows you to define character classes, and matches any character or combination of characters described in the set.	`[abc123]` matches `a` or `b` or `c`, and so on.
`^`	Matches content at the beginning of a string. Also used for negation, if used within a character class.	`^in` matches the “in” in `info`, but not in `bin`. `[^a]` matches anything that does not contain `a`.
`$`	Matches content at the end of a string.	`ce$` matches the “`ce`” in `announce`, but not `cent`.
`\|`	Indicates an OR expression.	`(MAILTO\|HELP)` matches `MAILTO` or `HELP`.
`\`	Allows you to use metacharacters as actual characters and is also used to specify a predefined character class.	`\.` matches a period, `\*` matches an asterisk, `\\` matches a backslash and so on. `\d` matches the numeric characters, `\w` matches alphanumeric characters, and so on.

Character Classes

Character classes include alphabetic characters, numeric characters, alphanumeric characters, and white space characters. While you can create your own character classes within brackets, 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.

Table 30. PCRE Character Classes
Character Class	Description	Character Class Definition
\d	Matches a numeric character (“digit”).	[0-9]
\D	Matches anything that is not an numeric character.	[^0-9]
\w	Matches an alphanumeric character (“word”).	[a-zA-Z0-9_]
\W	Matches anything that is not an alphanumeric character.	[^a-zA-Z0-9_]
\s	Matches white space characters, including spaces, carriage returns, tabs, newlines, and form feeds.	[ \r\t\n\f]
\S	Matches anything that is not a white space character.	[^ \r\t\n\f]

pcre Modifier Options

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:


/pcre/ismxAEGRBUIPHDMCKSY

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 intrusion rules 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.

Table 31. Perl-Related Post Regular Expression Options
Option	Description
i	Makes the regular expression case-insensitive.
s	The dot character (.) describes all characters except the newline or `\n` character. You can use `"s"` as an option to override this and have the dot character match all characters, including the newline character.
m	By default, a string is treated as a single line of characters, and `^` and `$` match the beginning and ending of a specific string. When you use `"m"` as an option, `^` and `$` match content immediately before or after any newline character in the buffer, as well as at the beginning or end of the buffer.
x	Ignores white space data characters that may appear within the pattern, except when escaped (preceded by a backslash) or included inside a character class.

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

Table 32. PCRE-Related Post Regular Expression Options
Option	Description
A	The pattern must match at the beginning of the string (same as using `^` in a regular expression).
E	Sets `$` to match only at the end of the subject string. (Without `E`, `$` also matches immediately before the final character if it is a newline, but not before any other newline characters).
G	By default, `* +` and `?` are “greedy,” which means that if two or more matches are found, they will choose the longest match. Use the G character to change this so that these characters always choose the first match unless followed by a question mark character (`?`). For example, `?` +`?` and `??` would be greedy in a construct using the G modifier, and any incidences of ``, `+`, or `?` without the additional question mark will not be greedy.

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

Table 33. Snort-Specific Post Regular Expression Modifiers
Option	Description
R	Searches for matching content relative to the end of the last match found by the rules engine.
B	Searches for the content within data before it is decoded by a preprocessor (this option is similar to using the `Raw Data`argument with the `content` or `protected_content` keyword).
U	Searches for the content within the URI of a normalized HTTP request message decoded by the HTTP Inspect preprocessor. Note that you cannot use this option in combination with the `content` or `protected_content` keyword HTTP URI option to search the same content. Note that a pipelined HTTP request packet contains multiple URIs. A PCRE expression that includes the U option causes the rules engine to search for a content match only in the first URI in a pipelined HTTP request packet. To search all URIs in the packet, use the `content` or `protected_content` keyword with HTTP URI selected, either with or without an accompanying PCRE expression that uses the U option.
I	Searches for the content within the URI of a raw HTTP request message decoded by the HTTP Inspect preprocessor. Note that you cannot use this option in combination with the `content` or `protected_content` keyword HTTP Raw URI option to search the same content
P	Searches for the content within the body of a normalized HTTP request message decoded by the HTTP Inspect preprocessor.
H	Searches for the content within the header, excluding cookies, of an HTTP request or response message decoded by the HTTP Inspect preprocessor. Note that you cannot use this option in combination with the `content` or `protected_content` keyword HTTP Header option to search the same content.
D	Searches for the content within the header, excluding cookies, of a raw HTTP request or response message decoded by the HTTP Inspect preprocessor. Note that you cannot use this option in combination with the `content` or `protected_content` keyword HTTP Raw Header option to search the same content.
M	Searches for the content within the method field of a normalized HTTP request message decoded by the HTTP Inspect preprocessor; the method field identifies the action such as GET, PUT, CONNECT, and so on to take on the resource identified in the URI.
C	When the HTTP Inspect preprocessor Inspect HTTP Cookies option is enabled, searches for the normalized content within any cookie in an HTTP request header, and also within any set-cookie in an HTTP response header when the preprocessor Inspect HTTP Responses option is enabled. When Inspect HTTP Cookies is not enabled, searches the entire header, including the cookie or set-cookie data. Note the following: Cookies included in the message body are treated as body content. You cannot use this option in combination with the `content` or `protected_content` keyword HTTP Cookie option to search the same content. 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.
K	When the HTTP Inspect preprocessor Inspect HTTP Cookies option is enabled, searches for the raw content within any cookie in an HTTP request header, and also within any set-cookie in an HTTP response header when the preprocessor Inspect HTTP Responses option is enabled. When Inspect HTTP Cookies is not enabled, searches the entire header, including the cookie or set-cookie data. Note the following: Cookies included in the message body are treated as body content. You cannot use this option in combination with the `content` or `protected_content` keyword HTTP Raw Cookie option to search the same content. 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.
S	Searches the 3-digit status code in an HTTP response.
Y	Searches the textual description that accompanies the status code in an HTTP response.

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

pcre Example Keyword Values

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