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 any in 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

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

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

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

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:

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:

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:

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

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 (delete icon) 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

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 Admin return "admin", "CFADMIN", "Administrator" and so on.

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

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 (clear icon).

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


Caution


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


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


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


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


HTTP Method

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

HTTP Header

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

Note that you cannot use this option in combination with the pcre keyword HTTP header (H) option to search the same content.

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:


1234567

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

This example would not match:

  • feedbacka.cgi

  • feedback11.cgi

  • feedback21.cgi

  • feedbackzb.cgi

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

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

This example would match:

  • EZBoard.cgi

  • ezman.cgi

  • ezadmin.cgi

  • EZAdmin.cgi

This example would not match:

  • ezez.cgi

  • fez.cgi

  • abcezboard.cgi

  • ezboardman.cgi

  • /mail(file|seek)\.cgi/U

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

This example would match:

  • mailfile.cgi

  • mailseek.cgi

This example would not match:

  • MailFile.cgi

  • mailfilefile.cgi

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

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

This example would match:

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

  • http://www.example.com?scriptvar=\t

This example would not match:

  • ftp://ftp.example.com?scriptvar=&othervar=\n\..\..

  • http://www.example.com?scriptvar=|/bin/sh -i|

  • m?http\\x3a\x2f\x2f.*=\|.*\|+?sU

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

This example would match:

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

  • http://www.example.com?input=|cat /etc/passwd|

This example would not match:

  • ftp://ftp.example.com?value=|/bin/sh/ -i|

  • http://www.example.com?value=x&input?|cat /etc/passwd|

  • /[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}\:[0-9a-f]{2}/i

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

The metadata Keyword

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

The system validates metadata based on the argument format:

key value

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

Alternatively, you can also use the format:

key = value

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


author SnortGuru_20050406

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

author SnortGuru_20050406, revised_by SnortUser1_20050707,
revised_by SnortUser2_20061003, 
revised_by SnortUser1_20070123

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

Restricted Characters to Avoid

Note the following character restrictions:

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

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

    key value ,key value ,key value

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

    key value

    key =value

All other characters are permitted.

Reserved Metadata to Avoid

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


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

Note


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


Impact Level 1

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


impact_flag red

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

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

Service Metadata

The system detects applications running on the hosts in your network and inserts application protocol information into your network traffic; it does this regardless of the configuration of your discovery policy. You can use metadata keyword service arguments in a TCP or UDP rule to match application protocols and ports in your network traffic. You can combine one or more service application arguments in a rule with a single port argument.

Service Applications

You can use the metadata keyword with service as the key and an application as the value to match packets with the identified application protocol. For example, the following key value argument in a metadata keyword associates the rule with HTTP traffic:

service http

You can identify multiple applications separated by commas. For example:

service http, service smtp, service ftp

Caution


Adaptive profiling must be enabled (its default state) as described in Configuring Adaptive Profiles for intrusion rules to use service metadata.

The following table describes the most common application values used with the service keyword.


Note


Contact Support for assistance if you have difficulty identifying applications not in the table.


Table 34. service Values

Value

Description

cvs

Concurrent Versions System

dcerpc

Distributed Computing Environment/Remote Procedure Calls System

dns

Domain Name System

finger

Finger user information protocol

ftp

File Transfer Protocol

ftp-data

File Transfer Protocol (Data Channel)

http

Hypertext Transfer Protocol

imap

Internet Message Access Protocol

isakmp

Internet Security Association and Key Management Protocol

mysql

My Structured Query Language

netbios-dgm

NETBIOS Datagram Service

netbios-ns

NETBIOS Name Service

netbios-ssn

NETBIOS Session Service

nntp

Network News Transfer Protocol

oracle

Oracle Net Services

shell

OS Shell

pop2

Post Office Protocol, version 2

pop3

Post Office Protocol, version 3

smtp

Simple Mail Transfer Protocol

snmp

Simple Network Management Protocol

ssh

Secure Shell network protocol

sunrpc

Sun Remote Procedure Call Protocol

telnet

Telnet network protocol

tftp

Trivial File Transfer Protocol

x11

X Window System

Service Ports

You can use the metadata keyword with service as the key and a specified port argument as the value to define how the rule matches ports in combination with applications.

You can specify any of the port values in the table below, one value per rule.

Table 35. service Port Values

Value

Description

else-ports or unknown

The system applies the rule if either of the following conditions is met:

  • The packet application is known and matches the rule application.

  • The packet application is unknown and packet ports match the rule ports.

The else-ports and unknown values produce the default behavior that the system uses when service specifies an application protocol with no port modifier.

and-ports

The system applies the rule if the packet application is known and matches the rule application, and the packet port matches the ports in the rule header. You cannot use and-ports in a rule that does not specify an application.

or-ports

The system applies the rule if any of the following conditions are met:

  • The packet application is known and matches the rule application.

  • The packet application is unknown and packet port matches the rule ports.

  • The packet application does not match the rule application and packet ports match the rule ports.

  • The rule does not specify an application and packet ports match the rule ports.

Note the following:
  • You must include a service application argument with the service and-ports argument.

  • If a rule specifies more than one of the values in the table above, the system applies the last one that appears in the rule.

  • Port and application arguments can be in any order.

Except for the and-ports value, you can include a service port argument with or without one or more service application arguments. For example:

service or-ports, service http, service smtp
Applications and Ports in Traffic

The diagrams below illustrate the application and port combinations that intrusion rules support, and the results of applying these rule constraints to packet data.

Host application protocol else source/destination ports:


Host application protocol and source/destination ports:


Host application protocol or source/destination ports:


Example Matches

The following sample rules using the metadata keyword with service arguments are shown with examples of data they match and do not match:

  • alert tcp any any -> any [80,8080] (metadata:service and-ports, service http, service smtp;)

    Example Matches

    Example Non-Matches

    • HTTP traffic over TCP port 80

    • HTTP traffic over TCP port 8080

    • SMTP traffic over TCP port 80

    • SMTP traffic over TCP port 8080

    • POP3 traffic on ports 80 or 8080

    • Traffic of unknown application on ports 80 or 8080

    • HTTP traffic on port 9999

  • alert tcp any any -> any [80,8080] (metadata:service or-ports, service http;)

    Example Matches

    Example Non-Matches

    • HTTP traffic on any port

    • SMTP traffic on port 80

    • SMTP traffic on port 8080

    • Traffic of unknown application on port 80 and 8080

    • Non-HTTP and non-SMTP traffic on ports other than 80 or 8080

  • Any of the following rules:

    • alert tcp any any -> any [80,8080] metadata:service else-ports, service http;)

    • alert tcp any any -> any [80,8080] metadata:service unknown, service http;)
    • alert tcp any any -> any [80,8080] metadata:service http;)

    Example Matches

    Example Non-Matches

    • HTTP traffic on any port

    • port 80 if packet application is unknown

    • port 8080 if packet application is unknown

    • SMTP traffic on ports 80 or 8080

    • POP3 traffic on ports 80 or 8080

Metadata Search Guidelines

To search for rules that use the metadata keyword, select the metadata keyword on the rules Search page and, optionally, type any portion of the metadata. For example, you can type:

  • search to display all rules where you have used search for key .

  • search http to display all rules where you have used search for key and http for value .

  • author snortguru to display all rules where you have used author for key and SnortGuru for value .

  • author s to display all rules where you have used author for key and any terms such as SnortGuru or SnortUser1 or SnortUser2 for value .


    Tip


    When you search for both key and value , use the same connecting operator (equal to [=] or a space character) in searches that is used in the key value argument in the rule; searches return different results depending on whether you follow key with equal to (=) or a space character.


Note that regardless of the format you use to add metadata, the system interprets your metadata search term as all or part of a key value or key =value argument. For example, the following would be valid metadata that does not follow a key value or key =value format:


ab cd ef gh

However, the system would interpret each space in the example as a separator between a key and value . Thus, you could successfully locate a rule containing the example metadata using any of the following searches for juxtaposed and single terms:


cd ef
ef gh
ef

but you would not locate the rule using the following search, which the system would interpret as a single key value argument:


ab ef

IP Header Values

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

fragbits

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

Table 36. Fragbits Argument Values

Argument

Description

R

Reserved bit

M

More Fragments bit

D

Don’t Fragment bit

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

Table 37. Fragbit Operators

Operator

Description

plus sign (+)

The packet must match against all specified bits.

asterisk (*)

The packet can match against any of the specified bits.

exclamation point (!)

The packet meets the criteria if none of the specified bits are set.

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

id

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


Note


id argument values must be numeric.


ipopts

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

Table 38. IPoption Arguments

Argument

Description

rr

record route

eol

end of list

nop

no operation

ts

time stamp