Tuning Intrusion Policies Using Rules

The following topics explain how to use rules to tune intrusion policies:

Intrusion Rule Tuning Basics

You can use the Rules page in an intrusion policy to configure rule states and other settings for shared object rules, standard text rules, and preprocessor rules.

You enable a rule by setting its rule state to Generate Events or to Drop and Generate Events. Enabling a rule causes the system to generate events on traffic matching the rule. Disabling a rule stops processing of the rule. You can also set your intrusion policy so that a rule set to Drop and Generate Events in an inline deployment generates events on, and drops, matching traffic. In a passive deployment, a rule set to Drop and Generate Events just generates events on matching traffic.

You can filter rules to display a subset of rules, enabling you to select the exact set of rules where you want to change rule states or rule settings.

When an intrusion rule or rule argument requires a disabled preprocessor, the system automatically uses it with its current configuration even though it remains disabled in the network analysis policy’s web interface.

Intrusion Rule Types

An intrusion rule is a specified set of keywords and arguments that the system uses to detect attempts to exploit vulnerabilities in your network. As the system analyzes network traffic, it compares packets against the conditions specified in each rule, and triggers the rule if the data packet meets all the conditions specified in the rule.

An intrusion policy contains:

  • intrusion rules, which are subdivided into shared object rules and standard text rules

  • preprocessor rules, which are associated with a detection option of the packet decoder or with one of the preprocessors included with the system

The following table summarizes attributes of these rule types:

Table 1. Intrusion Rule Types

Type

Generator ID (GID)

Snort ID (SID)

Source

Can Copy?

Can Edit?

shared object rule

3

lower than 1000000

Talos Intelligence Group

yes

limited

standard text rule

1

(Global domain or legacy GID)

lower than 1000000

Talos

yes

limited

1000 - 2000

(descendant domain)

1000000 or higher

Created or imported by user

yes

yes

preprocessor rule

decoder- or preprocessor- specific

lower than 1000000

Talos

no

no

1000000 or higher

Generated by the system during option configuration

no

no

You cannot save changes to any rule created by Talos, but you can save a copy of a modified rule as a custom rule. You can modify either variables used in the rule or rule header information (such as source and destination ports and IP addresses). In a multidomain deployment, rules created by Talos belong to the Global domain. Administrators in descendant domains can save local copies of the rules, which they can then edit.

For the rules it creates, Talos assigns default rule states in each default intrusion policy. Most preprocessor rules are disabled by default and must be enabled if you want the system to generate events for preprocessor rules and, in an inline deployment, drop offending packets.

License Requirements for Intrusion Rules

FTD License

Threat

Classic License

Protection

Requirements and Prerequisites for Intrusion Rules

Model Support

Any.

Supported Domains

Any

User Roles

  • Admin

  • Intrusion Admin

Viewing Intrusion Rules in an Intrusion Policy

You can adjust how rules are displayed in the intrusion policy, and can sort rules by several criteria. You can also display the details for a specific rule to see rule settings, rule documentation, and other rule specifics.

Procedure

Step 1

Choose Policies > Access Control > Intrusion.

Step 2

Click Snort 2 Version next to the policy you want to edit.

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

Step 3

Click Rules under Policy Information in the navigation panel.

Step 4

While viewing the rules, you can:

Intrusion Rules Page Columns

The Intrusion Rules page uses the same icons in its menu bar and column headers. For example, the Rule State menu uses the same Generate Events as the Rule State column in the rule listing.

Table 2. Rules Page Columns

Heading

Description

GID

Integer that indicates the Generator ID (GID) for the rule.

SID

Integer that indicates the Snort ID (SID), which acts a unique identifier for the rule.

For custom rules, the SID is 1000000 or higher.

Message

Message included in events generated by this rule, which also acts as the name of the rule.

Generate Events

The rule state for the rule:

  • Drop and Generate Events

  • Generate Events

  • Disabled

Note the icon for a disabled rule is a dimmed version of the icon for a rule that is set to generate events without dropping traffic. Also, clicking the rule state icon for a rule allows you to change the rule state.

Firepower Recommended rule state

Firepower recommended rule state for the rule.

Event Filter

Event filter, including event thresholds and event suppression, applied to the rule.

Dynamic state

Dynamic rule state for the rule, which goes into effect if specified rate anomalies occur.

Errors (error icon)

Alerts configured for the rule (currently SNMP alerts only).

Comment (comment icon)

Comments added to the rule.

You can also use the layer drop-down list to switch to the Rules page for other layers in your policy. Note that, unless you add layers to your policy, the only editable views listed in the drop-down list are the policy Rules page and the Rules page for a policy layer that is originally named My Changes; note also that making changes in one of these views is the same as making the changes in the other. The drop-down list also lists the Rules page for the read-only base policy.

Intrusion Rule Details

You can view rule documentation, Firepower recommendations, and rule overhead from the Rule Detail view. You can also view and add rule-specific features.

Table 3. Rule Details

Item

Description

Summary

The rule summary. For rule-based events, this row appears when the rule documentation contains summary information.

Rule State

The current rule state for the rule. Also indicates the layer where the rule state is set.

Firepower Recommendation

If Firepower recommendations have been generated, an icon that represents the recommended rule state; see Intrusion Rules Page Columns. If the recommendation is to enable the rule, the system also indicates the network assets or configurations that triggered the recommendation.

Rule Overhead

The rule’s potential impact on system performance and the likelihood that the rule might generate false positives. Local rules do not have an assigned overhead, unless they are mapped to a vulnerability.

Thresholds

Thresholds currently set for this rule, as well as the facility to add a threshold for the rule.

Suppressions

Suppression settings currently set for this rule, as well as the facility to add suppressions for the rule.

Dynamic State

Rate-based rule states currently set for this rule, as well as the facility to add dynamic rule states for the rule.

Alerts

SNMP alerts set for this rule, as well as the facility to add an alert for the rule.

Comments

Comments added to this rule, as well as the facility to add comments for the rule.

Documentation

The rule documentation for the current rule, supplied by the Talos Intelligence Group. Optionally, click Rule Documentation to view more-specific rule details.

Viewing Intrusion Rule Details

Procedure

Step 1

Choose Policies > Access Control > Intrusion.

Step 2

Click Snort 2 Version next to the policy you want to edit.

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

Step 3

On the navigation pane, click Rules.

Step 4

Click the rule whose rule details you want to view, then click Show details at the bottom of the page.

Rule details appear, as described in Intrusion Rule Details.

Step 5

From the rule details, you can configure:

Setting a Threshold for an Intrusion Rule

You can set a single threshold for a rule from the Rule Detail page. Adding a threshold overwrites any existing threshold for the rule.

Note that a Revert appears in a field when you enter an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.

Procedure

Step 1

From an intrusion rule’s details, click Add next to Thresholds.

Step 2

From the Type drop-down list, choose the type of threshold you want to set:

  • Choose Limit to limit notification to the specified number of event instances per time period.
  • Choose Threshold to provide notification for each specified number of event instances per time period.
  • Choose Both to provide notification once per time period after a specified number of event instances.

Step 3

From the Track By drop-down list, choose Source or Destination to indicate whether you want the event instances tracked by source or destination IP address.

Step 4

In the Count field, enter the number of event instances you want to use as your threshold.

Step 5

In the Seconds field, enter a number that specifies the time period, in seconds, for which event instances are tracked.

Step 6

Click OK.

Tip

 

The system displays an Event Filter next to the rule in the Event Filtering column. If you add multiple event filters to a rule, the system includes an indication of the number of event filters.

Setting Suppression for an Intrusion Rule

You can set one or more suppressions for a rule in your intrusion policy.

Note that a Revert appears in a field when you type an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.

Procedure

Step 1

From an intrusion rule’s details, click Add next to Suppressions.

Step 2

From the Suppression Type drop-down list, choose one of the following options:

  • Choose Rule to completely suppress events for a selected rule.
  • Choose Source to suppress events generated by packets originating from a specified source IP address.
  • Choose Destination to suppress events generated by packets going to a specified destination IP address.

Step 3

If you chose Source or Destination for the suppression type, in the Network field enter the IP address, an address block, or a comma-separated list comprised of any combination of these.

If the intrusion policy is associated with the default action of an access control policy, you can also specify or list a network variable in the default action variable set.

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 4

Click OK.

Tip

 

The system displays an Event Filter next to the rule in the Event Filtering column next the suppressed rule. If you add multiple event filters to a rule, a number over the filter indicates the number of filters.

Setting a Dynamic Rule State from the Rule Details Page

You can set one or more dynamic rule states for a rule. The first dynamic rule state listed has the highest priority. When two dynamic rule states conflict, the action of the first is carried out.

Dynamic rule states are policy-specific.

Note that a Revert appears in a field when you enter an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.

Procedure

Step 1

From an intrusion rule’s details, click Add next to Dynamic State.

Step 2

From the Track By drop-down list, choose an option to indicate how you want the rule matches tracked:

  • Choose Source to track the number of hits for that rule from a specific source or set of sources.
  • Choose Destination to track the number of hits for that rule to a specific destination or set of destinations.
  • Choose Rule to track all matches for that rule.

Step 3

If you set Track By to Source or Destination, enter the IP address of each host you want to track in the Network field.

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 4

Next to Rate, specify the number of rule matches per time period to set the attack rate:

  • In the Count field, specify the number of rule matches you want to use as your threshold.
  • In the Seconds field, specify the number of seconds that make up the time period for which attacks are tracked.

Step 5

From the New State drop-down list, choose the new action to be taken when the conditions are met.

Step 6

Enter a value in the Timeout field.

After the timeout occurs, the rule reverts to its original state. Enter 0 to prevent the new action from timing out.

Step 7

Click OK.

Tip

 

The system displays a dynamic state () next to the rule in the Dynamic State column. If you add multiple dynamic rule state filters to a rule, a number over the filters indicates the number of filters.

Setting an SNMP Alert for an Intrusion Rule

You can set an SNMP alert for a rule from the Rule Detail page.

Procedure

From an intrusion rule’s details, click Add SNMP Alert next to Alerts.

Tip

 

The system displays an alert Errors (error icon) next to the rule in the Alerting column. If you add multiple alerts to a rule, the system includes an indication of the number of alerts.

Adding a Comment to an Intrusion Rule

Procedure

Step 1

From an intrusion rule’s details, click Add next to Comments.

Step 2

In the Comment field, enter the rule comment.

Step 3

Click OK.

Tip

 

The system displays a Comment (comment icon) next to the rule in the Comments column. If you add multiple comments to a rule, a number over the comment indicates the number of comments.

Step 4

To delete a rule comment, click Delete in the rule comments section. You can only delete a comment if the comment is cached with uncommitted intrusion policy changes.

What to do next

Intrusion Rule Filters in an Intrusion Policy

You can filter the rules you display on the Rules page by a single criteria, or a combination of one or more criteria.

Rule filter keywords help you find the rules for which you want to apply rule settings, such as rule states or event filters. You can filter by a keyword and simultaneously select the argument for the keyword by selecting the argument you want from the Rules page filter panel.

Intrusion Rule Filters Notes

The filter you construct is shown in the Filter text box. You can click keywords and keyword arguments in the filter panel to construct a filter. When you choose multiple keywords, the system combines them using AND logic to create a compound search filter. For example, if you choose preprocessor under Category and then choose Rule Content > GID and enter 116, you get a filter of Category: “preprocessor” GID:”116”, which retrieves all rules that are preprocessor rules and have a GID of 116.

The Category, Microsoft Vulnerabilities, Microsoft Worms, Platform Specific, Preprocessor, and Priority filter groups allow you to submit more than one argument for a keyword, separated by commas. For example, you can choose os-linux and os-windows from Category to produce the filter Category:"os-windows,os-linux", which retrieves any rules in the os-linux category or in the os-windows category.

To show the filter panel, click the Show icon.

To hide the filter panel, click the Hide icon.

Intrusion Policy Rule Filters Construction Guidelines

In most cases, when you are building a filter, you can use the filter panel to the left of the Rules page in the intrusion policy to choose the keywords/arguments you want to use.

Rule filters are grouped into rule filter groups in the filter panel. Many rule filter groups contain sub-criteria so that you can more easily find the specific rules you are looking for. Some rule filters have multiple levels that you can expand to drill down to individual rules.

Items in the filter panel sometimes represent filter type groups, sometimes represent keywords, and sometimes represent the argument to a keyword. Note the following:

  • When you choose a filter type group heading that is not a keyword (Rule Configuration, Rule Content, Platform Specific, and Priority), it expands to list the available keywords.

    When you choose a keyword by clicking on a node in the criteria list, a pop-up window appears, where you supply the argument you want to filter by.

    If that keyword is already used in the filter, the argument you supply replaces the existing argument for that keyword.

    For example, if you click Drop and Generate Events under Rule Configuration > Recommendation in the filter panel, Recommendation:"Drop and Generate Events" is added to the filter text box. If you then click Generate Events under Rule Configuration > Recommendation, the filter changes to Recommendation:"Generate Events".

  • When you choose a filter type group heading that is a keyword (Category, Classifications, Microsoft Vulnerabilities, Microsoft Worms, Priority, and Rule Update), it lists the available arguments.

    When you choose an item from this type of group, the argument and the keyword it applies to are immediately added to the filter. If the keyword is already in the filter, it replaces the existing argument for the keyword that corresponds to that group.

    For example, if you click os-linux under Category in the filter panel, Category:"os-linux" is added to the filter text box. If you then click os-windows under Category, the filter changes to Category:"os-windows".

  • Reference under Rule Content is a keyword, and so are the specific reference ID types listed below it. When you choose any of the reference keywords, a pop-up window appears, where you supply an argument and the keyword is added to the existing filter. If the keyword is already in use in the filter, the new argument you supply replaces the existing argument.

    For example, if you click Rule Content > Reference > CVE ID in the filter panel, a pop-up window prompts you to supply the CVE ID. If you enter 2007, then CVE:”2007” is added to the filter text box. In another example, if you click Rule Content > Reference in the filter panel, a pop-up window prompts you to supply the reference. If you enter 2007, then Reference:”2007” is added to the filter text box.

  • When you choose rule filter keywords from different groups, each filter keyword is added to the filter and any existing keywords are maintained (unless overridden by a new value for the same keyword).

    For example, if you click os-linux under Category in the filter panel, Category:"os-linux" is added to the filter text box. If you then click MS00-006 under Microsoft Vulnerabilities, the filter changes to Category:"os-linux" MicrosoftVulnerabilities:"MS00-006".

  • When you choose multiple keywords, the system combines them using AND logic to create a compound search filter. For example, if you choose preprocessor under Category and then choose Rule Content > GID and enter 116, you get a filter of Category: “preprocessor” GID:”116”, which retrieves all rules that are preprocessor rules and have a GID of 116.

  • The Category, Microsoft Vulnerabilities, Microsoft Worms, Platform Specific, and Priority filter groups allow you to submit more than one argument for a keyword, separated by commas. For example, you can choose os-linux and os-windows from Category to produce the filter Category:"os-windows,app-detect", which retrieves any rules in the os-linux category or in the os-windows category.

The same rule may be retrieved by more than one filter keyword/argument pair. For example, the DOS Cisco attempt rule (SID 1545) appears if rules are filtered by the dos category, and also if you filter by the High priority.


Note

The Talos Intelligence Group may use the rule update mechanism to add and remove rule filters.

Note that the rules on the Rules page may be either shared object rules (generator ID 3) or standard text rules (generator ID 1, Global domain or legacy GID; 1000 - 2000, descendant domains). The following table describes the different rule filters.

Table 4. Rule Filter Groups

Filter Group

Description

Multiple Argument Support?

Heading is...

Items in List are...

Rule Configuration

Finds rules according to the configuration of the rule.

No

A grouping

keywords

Rule Content

Finds rules according to the content of the rule.

No

A grouping

keywords

Category

Finds rules according to the rule categories used by the rule editor. Note that local rules appear in the local sub-group.

Yes

A keyword

arguments

Classifications

Finds rules according to the attack classification that appears in the packet display of an event generated by the rule.

No

A keyword

arguments

Microsoft Vulnerabilities

Finds rules according to Microsoft bulletin number.

Yes

A keyword

arguments

Microsoft Worms

Finds rules based on specific worms that affect Microsoft Windows hosts.

Yes

A keyword

arguments

Platform Specific

Finds rules according to their relevance to specific versions of operating systems.

Note that a rule may affect more than one operating system or more than one version of an operating system. For example, enabling SID 2260 affects multiple versions of Mac OS X, IBM AIX, and other operating systems.

Yes

A keyword

arguments

Note that if you pick one of the items from the sub-list, it adds a modifier to the argument.

Preprocessors

Finds rules for individual preprocessors.

Note that you must enable preprocessor rules associated with a preprocessor option to generate events and, in an inline deployment, drop offending packets for the option when the preprocessor is enabled.

Yes

A grouping

sub-groupings

Priority

Finds rules according to high, medium, and low priorities.

The classification assigned to a rule determines its priority. These groups are further grouped into rule categories. Note that local rules (that is, rules that you import or create) do not appear in the priority groups.

Yes

A keyword

arguments

Note that if you pick one of the items from the sub-list, it adds a modifier to the argument.

Rule Update

Finds rules added or modified through a specific rule update. For each rule update, view all rules in the update, only new rules imported in the update, or only existing rules changed by the update.

No

A keyword

arguments

Intrusion Rule Configuration Filters

You can filter the rules listed in the Rules page by several rule configuration settings. For example, if you want to view the set of rules whose rule state does not match the recommended rule state, you can filter on rule state by selecting Does not match recommendation.

When you choose a keyword by clicking on a node in the criteria list, you can supply the argument you want to filter by. If that keyword is already used in the filter, the argument you supply replaces the existing argument for that keyword.

For example, if you click Drop and Generate Events under Rule Configuration > Recommendation in the filter panel, Recommendation:"Drop and Generate Events" is added to the filter text box. If you then click Generate Events under Rule Configuration > Recommendation, the filter changes to Recommendation:"Generate Events".

Intrusion Rule Content Filters

You can filter the rules listed in the Rules page by several rule content items. For example, you can quickly retrieve a rule by searching for the rule’s SID. You can also find all rules that inspect traffic going to a specific destination port.

When you select a keyword by clicking on a node in the criteria list, you can supply the argument you want to filter by. If that keyword is already used in the filter, the argument you supply replaces the existing argument for that keyword.

For example, if you click SID under Rule Content in the filter panel, a pop-up window appears, prompting you to supply a SID. If you type 1045, then SID:”1045”is added to the filter text box. If you then click SID again and change the SID filter to 1044, the filter changes to SID:”1044”.

Table 5. Rule Content Filters

This filter...

Finds rules that...

Message

contain the supplied string in the message field.

SID

have the specified SID.

GID

have the specified GID.

Reference

contain the supplied string in the reference field. You can also filter by a specific type of reference and supplied string.

Action

start with alert or pass.

Protocol

include the selected protocol.

Direction

are based on whether the rule includes the indicated directional setting.

Source IP

use the specified addresses or variables for the source IP address designation in the rule. You can filter by a valid IP address, a CIDR block/prefix length, or using variables such as $HOME_NET or $EXTERNAL_NET.

Destination IP

use the specified addresses or variables for the source IP address designation in the rule. You can filter by a valid IP address, a CIDR block/prefix length, or using variables such as $HOME_NET or $EXTERNAL_NET.

Source port

include the specified source port. The port value must be an integer between 1 and 65535 or a port variable.

Destination port

include the specified destination port. The port value must be an integer between 1 and 65535 or a port variable.

Rule Overhead

have the selected rule overhead.

Metadata

have metadata containing the matching key value pair. For example, type metadata:”service http” to locate rules with metadata relating to the HTTP application protocol.

Intrusion Rule Categories

The system places rules in categories based on the type of traffic the rule detects. On the Rules page, you can filter by rule category, so you can set a rule attribute for all rules in a category. For example, if you do not have Linux hosts on your network, you could filter by the os-linux category, then disable all the rules showing to disable the entire os-linux category.

You can hover your pointer over a category name to display the number of rules in that category.


Note

The Talos Intelligence Group may use the rule update mechanism to add and remove rule categories.

Intrusion Rule Filter Components

You can edit your filter to modify the special keywords and their arguments that are supplied when you click on a filter in the filter panel. Custom filters on the Rules page function like those used in the rule editor, but you can also use any of the keywords supplied in the Rules page filter, using the syntax displayed when you select the filter through the filter panel. To determine a keyword for future use, click on the appropriate argument in the filter panel on the right. The filter keyword and argument syntax appear in the filter text box. Remember that comma-separated multiple arguments for a keyword are only supported for the Category and Priority filter types.

You can use keywords and 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. When you type in search terms without a keyword, without initial capitalization of the keyword, or without quotes around the argument, the search is treated as a string search and the category, message, and SID fields are searched for the specified terms.

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.

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


keyword:”argument”

where keyword is one of the keywords in the intrusion rule filter groups and argument is enclosed in double quotes and is a single, case-insensitive, alphanumeric string to search for in the specific field or fields relevant to the keyword. Note that keywords should be typed with initial capitalization.

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.

Each rule filter can also 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. You can search for a partial SID by filtering with one or more character strings.

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

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

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

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

  • url:at login attempt cve:200

  • login attempt cve:200 url:at

  • login cve:200 attempt url:at

Intrusion Rule Filter Usage

You can select predefined filter keywords from the filter panel on the left side of the Rules page in the intrusion policy. When you select a filter, the page displays all matching rules, or indicates when no rules match.

You can add keywords to a filter to further constrain it. 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 also type a filter using the same keyword and argument syntax supplied when you select a filter, or modify argument values in a filter after you select it. When you type in search terms without a keyword, without initial capitalization of the keyword, or without quotes around the argument, the search is treated as a string search and the category, message, and SID fields are searched for the specified terms.

Setting a Rule Filter in an Intrusion Policy

You can filter the rules on the Rules page to display a subset of rules. You can then use any of the page features, including choosing any of the features available in the context menu. This can be useful, for example, when you want to set a threshold for all the rules in a specific category. You can use the same features with rules in a filtered or unfiltered list. For example, you can apply new rule states to rules in a filtered or unfiltered list.

All filter keywords, keyword arguments, and character strings are case-insensitive. If you click an argument for a keyword already in the filter, it replaces the existing argument.

Procedure

Step 1

Choose Policies > Access Control > Intrusion.

Step 2

Click Snort 2 Version next to the policy you want to edit.

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

Step 3

Construct a filter using any of the following methods, separately or in combination:

  • Enter a value in the Filter text box, and press Enter.
  • Expand any of the predefined keywords. For example, click Rule Configuration.
  • Click a keyword, and specify an argument value if prompted. For example:

    • Under Rule Configuration, you could click Rule State, choose Generate Events from the drop-down-list, and click OK.

    • Under Rule Configuration, you could click Comment, enter the string of comment text to filter by, and click OK.

    • Under Category, you could click app-detect, which the system uses as the argument value.

  • Expand a keyword, and click an argument value. For example, expand Rule State and click Generate Events.

Intrusion Rule States

Intrusion rule states allow you to enable or disable the rule within an individual intrusion policy, as well as specify which action the system takes if monitored conditions trigger the rule.

The Talos Intelligence Group sets the default state of each intrusion and preprocessor rule in each default policy. For example, a rule may be enabled in the Security over Connectivity default policy and disabled in the Connectivity over Security default policy. Talos sometimes uses a rule update to change the default state of one or more rules in a default policy. If you allow rule updates to update your base policy, you also allow the rule update to change the default state of a rule in your policy when the default state changes in the default policy you used to create your policy (or in the default policy it is based on). Note, however, that if you have changed the rule state, the rule update does not override your change.

When you create an intrusion rule, it inherits the default states of the rules in the default policy you use to create your policy.

Intrusion Rule State Options

In an intrusion policy, you can set a rule’s state to the following values:

Generate Events

You want the system to detect a specific intrusion attempt and generate an intrusion event when it finds matching traffic. When a malicious packet crosses your network and triggers the rule, the packet is sent to its destination and the system generates an intrusion event. The malicious packet reaches its target, but you are notified via the event logging.

Drop and Generate Events

You want the system to detect a specific intrusion attempt, drop the packet containing the attack, and generate an intrusion event when it finds matching traffic. The malicious packet never reaches its target, and you are notified via the event logging.

Note that rules set to this rule state generate events but do not drop packets in a passive deployment. For the system to drop packets, Drop when Inline must also be enabled (the default setting) in your intrusion policy and you must deploy your device inline.

Disable

You do not want the system to evaluate matching traffic.


Note

Choosing either the Generate Events or Drop and Generate Events options enables the rule. Choosing Disable disables the rule.

Cisco strongly recommends that you do not enable all the intrusion rules in an intrusion policy. The performance of your managed device is likely to degrade if all rules are enabled. Instead, tune your rule set to match your network environment as closely as possible.

Setting Intrusion Rule States

Intrusion rule states are policy-specific.

Procedure

Step 1

Choose Policies > Access Control > Intrusion.

Step 2

Click Snort 2 Version next to the policy you want to edit.

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

Tip

 
This page indicates the total number of enabled rules, the total number of enabled rules set to Generate Events, and the total number set to Drop and Generate Events. Note also that in a passive deployment, rules set to Drop and Generate Events only generate events.

Step 3

Click Rules immediately under Policy Information in the navigation panel.

Step 4

Choose the rule or rules where you want to set the rule state.

Step 5

Choose one of the following:

  • Rule State > Generate Events
  • Rule State > Drop and Generate Events
  • Rule State > Disable

Step 6

To save changes you made in this policy since the last policy commit, click Policy Information in the navigation panel, then click Commit Changes.

If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy.

What to do next

Intrusion Event Notification Filters in an Intrusion Policy

The importance of an intrusion event can be based on frequency of occurrence, or on source or destination IP address. In some cases you may not care about an event until it has occurred a certain number of times. For example, you may not be concerned if someone attempts to log into a server until they fail a certain number of times. In other cases, you may only need to see a few occurrences to know there is a widespread problem. For example, if a DoS attack is launched against your web server, you may only need to see a few occurrences of an intrusion event to know that you need to address the situation. Seeing hundreds of the same event only overwhelms your system.

Intrusion Event Thresholds

You can set thresholds for individual rules, per intrusion policy, to limit the number of times the system logs and displays an intrusion event based on how many times the event is generated within a specified time period. This can prevent you from being overwhelmed with a large number of identical events. You can set thresholds per shared object rule, standard text rule, or preprocessor rule.

Intrusion Event Thresholds Configuration

To set a threshold, first specify the thresholding type.

Table 6. Thresholding Options

Option

Description

Limit

Logs and displays events for the specified number of packets (specified by the Count argument) that trigger the rule during the specified time period. For example, if you set the type to Limit, the Count to 10, and the Seconds to 60, and 14 packets trigger the rule, the system stops logging events for the rule after displaying the first 10 that occur within the same minute.

Threshold

Logs and displays a single event when the specified number of packets (specified by the Count argument) trigger the rule during the specified time period. Note that the counter for the time restarts after you hit the threshold count of events and the system logs that event. For example, you set the type to Threshold, Count to 10, and Seconds to 60, and the rule triggers 10 times by second 33. The system generates one event, then resets the Seconds and Count counters to 0. The rule then triggers another 10 times in the next 25 seconds. Because the counters reset to 0 at second 33, the system logs another event.

Both

Logs and displays an event once per specified time period, after the specified number (count) of packets trigger the rule. For example, if you set the type to Both, Count to two, and Seconds to 10, the following event counts result:

  • If the rule is triggered once in 10 seconds, the system does not generate any events (the threshold is not met)

  • If the rule is triggered twice in 10 seconds, the system generates one event (the threshold is met when the rule triggers the second time)

  • If the rule is triggered four times in 10 seconds, the system generates one event (the threshold is met when the rule triggers the second time, and following events are ignored)

Next, specify tracking, which determines whether the event threshold is calculated per source or destination IP address.

Table 7. Thresholding IP Options

Option

Description

Source

Calculates event instance count per source IP address.

Destination

Calculates event instance count per destination IP address.

Finally, specify the number of instances and time period that define the threshold.

Table 8. Thresholding Instance/Time Options

Option

Description

Count

The number of event instances per specified time period per tracking IP address required to meet the threshold.

Seconds

The number of seconds that elapse before the count resets. If you set the threshold type to limit, the tracking to Source IP, the count to 10, and the seconds to 10, the system logs and displays the first 10 events that occur in 10 seconds from a given source port. If only 7 events occur in the first 10 seconds, the system logs and displays those; if 40 events occur in the first 10 seconds, the system logs and displays 10, then begins counting again when the 10-second time period elapses.

Note that you can use intrusion event thresholding alone or in any combination with rate-based attack prevention, the detection_filter keyword, and intrusion event suppression.


Tip

You can also add thresholds from within the packet view of an intrusion event.

Adding and Modifying Intrusion Event Thresholds

You can set a threshold for one or more specific rules in an intrusion policy. You can also separately or simultaneously modify existing threshold settings. You can set a single threshold for each. Adding a threshold overwrites any existing threshold for the rule.

You can also modify the global threshold that applies by default to all rules and preprocessor-generated events associated with the intrusion policy.

A Revert appears in a field when you enter an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.


Tip

A global or individual threshold on a managed device with multiple CPUs may result in a higher number of events than expected.

Procedure

Step 1

Choose Policies > Access Control > Intrusion.

Step 2

Click Snort 2 Version next to the policy you want to edit.

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

Step 3

Click Rules immediately under Policy Information in the navigation pane.

Step 4

Choose the rule or rules where you want to set a threshold.

Step 5

Choose Event Filtering > Threshold.

Step 6

Choose a threshold type from the Type drop-down list.

Step 7

From the Track By drop-down list, choose whether you want the event instances tracked by Source or Destination IP address.

Step 8

Enter a value in the Count field.

Step 9

Enter a value in the Seconds field.

Step 10

Click OK.

Tip

 

The system displays an Event Filter next to the rule in the Event Filtering column. If you add multiple event filters to a rule, a number over the filter indicates the number of event filters.

Step 11

To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes.

If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy.

What to do next

Viewing and Deleting Intrusion Event Thresholds

You may want to view or delete an existing threshold setting for a rule. You can use the Rules Details view to display the configured settings for a threshold to see if they are appropriate for your system. If they are not, you can add a new threshold to overwrite the existing values.

Note that you can also modify the global threshold that applies by default to all rules and preprocessor-generated events logged by the intrusion policy.

Procedure

Step 1

Choose Policies > Access Control > Intrusion.

Step 2

Click Snort 2 Version next to the policy you want to edit.

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

Step 3

Click Rules immediately under Policy Information in the navigation pane.

Step 4

Choose the rule or rules with a configured threshold you want to view or delete.

Step 5

To remove the threshold for each selected rule, choose Event Filtering > Remove Thresholds.

Step 6

Click OK.

Step 7

To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes.

If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy.

What to do next

Intrusion Policy Suppression Configuration

You can suppress intrusion event notification when a specific IP address or range of IP addresses triggers a specific rule or preprocessor. This is useful for eliminating false positives. For example, if you have a mail server that transmits packets that look like a specific exploit, you might suppress event notification for that event when it is triggered by your mail server. The rule triggers for all packets, but you only see events for legitimate attacks.

Intrusion Policy Suppression Types

Note that you can use intrusion event suppression alone or in any combination with rate-based attack prevention, the detection_filter keyword, and intrusion event thresholding.


Tip

You can add suppressions from within the packet view of an intrusion event. You can also access suppression settings by using the right-click context menu on the intrusion rules editor page (Objects > Intrusion Rules) and on any intrusion event page (if the event was triggered by an intrusion rule).

Suppressing Intrusion Events for a Specific Rule

You can suppress intrusion event notification for a rule or rules in your intrusion policy. When notification is suppressed for a rule, the rule triggers but events are not generated. You can set one or more suppressions for a rule. The first suppression listed has the highest priority. When two suppressions conflict, the action of the first is carried out.

Note that a Revert appears in a field when you enter an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.

Procedure

Step 1

Choose Policies > Access Control > Intrusion.

Step 2

Click Snort 2 Version next to the policy you want to edit.

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

Step 3

Click Rules immediately under Policy Information in the navigation panel.

Step 4

Choose the rule or rules for which you want to configure suppression conditions.

Step 5

Choose Event Filtering > Suppression.

Step 6

Choose a Suppression Type.

Step 7

If you chose Source or Destination for the suppression type, in the Network field enter the IP address, address block, or variable you want to specify as the source or destination IP address, or a comma-separated list comprised of any combination of these.

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 8

Click OK.

Tip

 

The system displays an Event Filter next to the rule in the Event Filtering column next the suppressed rule. If you add multiple event filters to a rule, a number over the filter indicates the number of event filters.

Step 9

To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes.

If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy.

What to do next

Viewing and Deleting Suppression Conditions

You may want to view or delete an existing suppression condition. For example, you can suppress event notification for packets originating from a mail server IP address because the mail server normally transmits packets that look like exploits. If you then decommission that mail server and reassign the IP address to another host, you should delete the suppression conditions for that source IP address.

Procedure

Step 1

Choose Policies > Access Control > Intrusion.

Step 2

Click Snort 2 Version next to the policy you want to edit.

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

Step 3

Click Rules immediately under Policy Information in the navigation panel.

Step 4

Choose the rule or rules for which you want to view or delete suppressions.

Step 5

You have the following choices:

  • To remove all suppression for a rule, choose Event Filtering > Remove Suppressions.
  • To remove a specific suppression setting, click the rule, then click Show details. Expand the suppression settings and click Delete next to the suppression settings you want to remove.

Step 6

Click OK.

Step 7

To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes.

If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy.

What to do next

Dynamic Intrusion Rule States

Rate-based attacks attempt to overwhelm a network or host by sending excessive traffic toward the network or host, causing it to slow down or deny legitimate requests. You can use rate-based prevention to change the action of a rule in response to excessive rule matches for specific rules.

You can configure your intrusion policies to include a rate-based filter that detects when too many matches for a rule occur in a given time period. You can use this feature on managed devices deployed inline to block rate-based attacks for a specified time, then revert to a rule state where rule matches only generate events and do not drop traffic.

Rate-based attack prevention identifies abnormal traffic patterns and attempts to minimize the impact of that traffic on legitimate requests. You can identify excessive rule matches in traffic going to a particular destination IP address or addresses or coming from a particular source IP address or addresses. You can also respond to excessive matches for a particular rule across all detected traffic.

In some cases, you may not want to set a rule to the Drop and Generate Events state because you do not want to drop every packet that matches the rule, but you do want to drop packets matching the rule if a particular rate of matches occurs in a specified time. Dynamic rule states let you configure the rate that should trigger a change in the action for a rule, what the action should change to when the rate is met, and how long the new action should persist.

The following diagram shows an example where an attacker is attempting to access a host. Repeated attempts to find a password trigger a rule which has rate-based attack prevention configured. The rate-based settings change the rule attribute to Drop and Generate Events after rule matches occur five times in a 10-second span. The new rule attribute times out after 15 seconds.

After the timeout, note that packets are still dropped in the rate-based sampling period that follows. If the sampled rate is above the threshold in the current or previous sampling period, the new action continues. The new action reverts to Generate Events only after a sampling period completes where the sampled rate was below the threshold rate.


Diagram demonstrating rate-based filtering.

Dynamic Intrusion Rule State Configuration

In the intrusion policy, you can configure a rate-based filter for any intrusion or preprocessor rule. The rate-based filter contains three components:

  • the rule matching rate, which you configure as a count of rule matches within a specific number of seconds

  • a new action to be taken when the rate is exceeded, with three available actions: Generate Events, Drop and Generate Events, and Disable

  • the duration of the action, which you configure as a timeout value

Note that when started, the new action occurs until the timeout is reached, even if the rate falls below the configured rate during that time period. When the timeout is reached, if the rate has fallen below the threshold, the action for the rule reverts to the action initially configured for the rule.

You can configure rate-based attack prevention in an inline deployment to block attacks, either temporarily or permanently. Without rate-based configuration, rules set to Generate Events do generate events, but the system does not drop packets for those rules. However, if the attack traffic matches rules that have rate-based criteria configured, the rate action may cause packet dropping to occur for the period of time that the rate action is active, even if those rules are not initially set to Drop and Generate Events.


Note

Rate-based actions cannot enable disabled rules or drop traffic that matches disabled rules.

You can define multiple rate-based filters on the same rule. The first filter listed in the intrusion policy has the highest priority. Note that when two rate-based filter actions conflict, the action of the first rate-based filter is carried out.

Setting a Dynamic Rule State from the Rules Page

You can set one or more dynamic rule states for a rule. The first dynamic rule state listed has the highest priority. When two dynamic rule states conflict, the action of the first is carried out.

Dynamic rule states are policy-specific.

A Revert appears in a field when you enter an invalid value; click it to revert to the last valid value for that field or to clear the field if there was no previous value.


Note

Dynamic rule states cannot enable disabled rules or drop traffic that matches disabled rules.

Procedure

Step 1

Choose Policies > Access Control > Intrusion.

Step 2

Click Snort 2 Version next to the policy you want to edit.

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

Step 3

Click Rules immediately under Policy Information in the navigation pane.

Step 4

Choose the rule or rules where you want to add a dynamic rule state.

Step 5

Choose Dynamic State > Add Rate-Based Rule State.

Step 6

Choose a value from the Track By drop-down list.

Step 7

If you set Track By to Source or Destination, enter the address of each host you want to track in the Network field. You can specify a single IP address, address block, variable, or a comma-separated list comprised of any combination of these.

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 8

Next to Rate, specify the number of rule matches per time period to set the attack rate:

  • Enter a value in the Count field.

  • Enter a value in the Seconds field.

Step 9

From the New State drop-down list, specify the new action to be taken when the conditions are met.

Step 10

Enter a value in the Timeout field.

After the timeout occurs, the rule reverts to its original state. Specify 0 or leave the Timeout field blank to prevent the new action from timing out.

Step 11

Click OK.

Tip

 

The system displays a Dynamic State next to the rule in the Dynamic State column. If you add multiple dynamic rule state filters to a rule, a number over the filter indicates the number of filters.

Tip

 

To delete all dynamic rule settings for a set of rules, choose the rules on the Rules page, then choose Dynamic State > Remove Rate-Based States. You can also delete individual rate-based rule state filters from the rule details for the rule by choosing the rule, clicking Show details, then clicking Delete by the rate-based filter you want to remove.

Step 12

To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes.

If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy.

What to do next

Adding Intrusion Rule Comments

You can add comments to rules in your intrusion policy. Comments added this way are policy-specific; that is, comments you add to a rule in one intrusion policy are not visible in other intrusion policies. Any comments you add can be seen in the Rule Details view on the Rules page for the intrusion policy.

After you commit the intrusion policy changes containing the comment, you can also view the comment by clicking Rule Comment on the rule Edit page.

Procedure

Step 1

Choose Policies > Access Control > Intrusion.

Step 2

Click Snort 2 Version next to the policy you want to edit.

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

Step 3

Click Rules immediately under Policy Information in the navigation panel.

Step 4

Choose the rule or rules where you want to add a comment.

Step 5

Choose Comments > Add Rule Comment.

Step 6

In the Comment field, enter the rule comment.

Step 7

Click OK.

Tip

 

The system displays a Comment (comment icon) next to the rule in the Comments column. If you add multiple comments to a rule, a number over the comment indicates the number of comments.

Step 8

Optionally, delete a rule comment by clicking Delete next to the comment.

You can only delete a comment if the comment is cached with uncommitted intrusion policy changes. After intrusion policy changes are committed, the rule comment is permanent.

Step 9

To save changes you made in this policy since the last policy commit, click Policy Information, then click Commit Changes.

If you leave the policy without committing changes, changes since the last commit are discarded if you edit a different policy.

What to do next