Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IDP Policy Rules and IDP Rule Bases

Intrusion Detection and Prevention (IDP) policies are collections of rules and rulebases.

For more information, see the following topics:

Understanding IDP Policy Rule Bases

A rulebase is an ordered set of rules that use a specific detection method to identify and prevent attacks.

Rules are instructions that provide context to detection mechanisms by specifying which part of the network traffic the IDP system should look in to find attacks. When a rule is matched, it means that an attack has been detected in the network traffic, triggering the action for that rule. The IDP system performs the specified action and protects your network from that attack.

Each rulebase can have multiple rules—you determine the sequence in which rules are applied to network traffic by placing them in the desired order. Each rulebase in the IDP system uses specific detection methods to identify and prevent attacks. Junos OS supports two types of rulebases—intrusion prevention system (IPS) rulebase and exempt rulebase.

Understanding IDP Policy Rules

Each instruction in an Intrusion Detection and Prevention (IDP) policy is called a rule. Rules are created in rulebases.

Rulebases are a set of rules that combine to define an IDP policy. Rules provide context to detection mechanisms by specifying which part of the network traffic the IDP system should look in, to find attacks. When a rule is matched, it means that an attack has been detected in the network traffic, triggering the action for that rule. The IDP system performs the specified action and protects your network from that attack.

IDP policy rules are made up of the following components:

Understanding IDP Rule Match Conditions

Match conditions specify the type of network traffic you want IDP to monitor for attacks.

Match conditions use the following characteristics to specify the type of network traffic to be monitored:

  • From-zone and to-zone—All traffic flows from a source to a destination zone. You can select any zone for the source or destination. You can also use zone exceptions to specify unique to and from zones for each device. Specify any to monitor network traffic originating from and to any zone. The default value is any.

    Note:

    You can specify source-address and source-except addresses when from-zone is any. Similarly, when to-zone is any, you can specify destination-address and destination-except addresses.

  • Source IP address—Specify the source IP address from which the network traffic originates. You can specify any to monitor network traffic originating from any IP address. You can also specify source-except to specify all sources except the specified addresses. The default value is any.

  • Destination IP address—Specify the destination IP address to which the network traffic is sent. You can set this to any to monitor network traffic sent to any IP address. You can also specify destination-except to specify all destinations except the specified addresses. The default value is any.

  • Application—Specify the Application Layer protocols supported by the destination IP address. You can specify any for all applications or specify an application, for example, junos-bgp. You can specify default for the application configured in the attack object for the rule to match default and automatically detected ports to the applications implied in the attack objects.

Understanding IDP Rule Objects

Objects are reusable logical entities that you can apply to rules. Each object that you create is added to a database for the object type.

You can configure the following types of objects for IDP rules.

Zone Objects

A zone or security zone is a collection of one or more network interfaces. IDP uses zone objects configured in the base system.

Address or Network Objects

Address objects represent components of your network, such as host machines, servers, and subnets. You use address objects in IDP policy rules to specify the network components that you want to protect.

Application or Service Objects

Service objects represent network services that use Transport Layer protocols such as TCP, UDP, RPC, and ICMP. You use service objects in rules to specify the service an attack uses to access your network. Juniper Networks provides predefined service objects, a database of service objects that are based on industry-standard services. If you need to add service objects that are not included in the predefined service objects, you can create custom service objects. IDP supports the following types of service objects:

  • Any—Allows IDP to match all Transport Layer protocols.

  • TCP—Specifies a TCP port or a port range to match network services for specified TCP ports. You can specify junos-tcp-any to match services for all TCP ports.

  • UDP—Specifies a UDP port or a port range to match network services for specified UDP ports. You can specify junos-udp-any to match services for all UDP ports.

  • RPC—Specifies a remote procedure call (RPC from Sun Microsystems) program number or a program number range. IDP uses this information to identify RPC sessions.

  • ICMP—Specifies a type and code that is a part of an ICMP packet. You can specify junos-icmp-all to match all ICMP services.

  • default—Allows IDP to match default and automatically detected protocols to the applications implied in the attack objects.

Attack Objects

IDP attack objects represent known and unknown attacks. IDP includes a predefined attack object database that is periodically updated by Juniper Networks. Attack objects are specified in rules to identify malicious activity. Each attack is defined as an attack object, which represents a known pattern of attack. Whenever this known pattern of attack is encountered in the monitored network traffic, the attack object is matched. The three main types of attack objects are described in Table 1:

Table 1: IDP Attack Objects Description

Attack Objects

Description

Signature Attack Objects

Signature attack objects detect known attacks using stateful attack signatures. An attack signature is a pattern that always exists within an attack; if the attack is present, so is the attack signature. With stateful signatures, IDP can look for the specific protocol or service used to perpetrate the attack, the direction and flow of the attack, and the context in which the attack occurs. Stateful signatures produce few false positives because the context of the attack is defined, eliminating huge sections of network traffic in which the attack would not occur.

Protocol Anomaly Attack Objects

Protocol anomaly attack objects identify unusual activity on the network. They detect abnormal or ambiguous messages within a connection according to the set of rules for the particular protocol being used. Protocol anomaly detection works by finding deviations from protocol standards, most often defined by RFCs and common RFC extensions. Most legitimate traffic adheres to established protocols. Traffic that does not, produces an anomaly, which may be created by attackers for specific purposes, such as evading an intrusion prevention system (IPS).

Compound Attack Objects

A compound attack object combines multiple signatures and/or protocol anomalies into a single object. Traffic must match all of the combined signatures and/or protocol anomalies to match the compound attack object; you can specify the order in which signatures or anomalies must match. Use compound attack objects to refine your IDP policy rules, reduce false positives, and increase detection accuracy. A compound attack object enables you to be very specific about the events that need to occur before IDP identifies traffic as an attack. You can use And, Or, and Ordered and operations to define the relationship among different attack objects within a compound attack and the order in which events occur.

Attack Object Groups

IDP contains a large number of predefined attack objects. To help keep IDP policies organized and manageable, attack objects can be grouped. An attack object group can contain one or more attack objects of different types. Junos OS supports the following three types of attack groups:

  • Predefined attack object groups—Contain objects present in the signature database. The predefined attack object groups are dynamic in nature. For example, FTP: Minor group selects all attacks of application- FTP and severity- Minor. If a new FTP attack of minor severity is introduced in the security database, it is added to the FTP: Minor group by default.

  • Dynamic attack groups—Contain attack objects based on a certain matching criteria. For example, a dynamic group can contain all attacks related to an application. During signature update, the dynamic group membership is automatically updated based on the matching criteria for that group.

    For a dynamic attack group using the direction filter, the expression and should be used in the exclude values. As is the case with all filters, the default expression is or. However, there is a choice of and in the case of the direction filter.

    For example, if you want to choose all attacks with the direction client-to-server, configure the direction filter using set security idp dynamic-attack-group dyn1 filters direction values client-to-server command

    In the case of chain attacks, each of the multiple members has its own direction. If a policy includes chain attacks, a client-to-server filter selects all chain attacks that have any member with client-to-server as the direction. This means chain attacks that include members with server-to-client or ANY as the direction are selected if the chain has at least one member with client-to-server as the direction.

    You can view the attack objects that are present in a particular attack object group (predefined, dynamic, and custom attack groups) and the group to which a predefined attack object belongs using the following commands:

    • show security idp attack attack-list attack-group group-name

    • show security idp attack group-list attack-name

    Use the show security idp attack attack-list attack-group group-name command to:

    • View the list of all attacks present in the specified attack group such as custom, dynamic, and predefined groups.

    • Specify the names of the group such as predefined-group <predefined-group-name> or dynamic-group <dynamic-group-name> or custom-group <custom-group-name> to display the list of attacks in that group.

    Use the show security idp attack group-list command to view the list of attack groups to which the predefined attack belongs.

    Note:

    In case of a predefined attack groups that do not have a defined filter, such groups are not displayed as members for an attack.

    Use the show security idp attack attack-list policy policy-name command to view the attacks available in a configured IDP policy. If an IDP policy is configured to contain a particular attack belonging to various attack groups, then the redundant attack names are displayed as part of the attack in an IDP policy command output.

    Previously IDP signature updates supported only nine tags under filters. The seven tags are category, direction, false-positives, performance, product, recommended, service, severity, and vendor. IDP signature updates now support four new additional tags under filters for creating more sophisticated dynamic groups in addition to the existing nine tags.

    The additional tags are:

    • Common Vulnerability Scoring System (CVSS) (measured in terms of numerical numbers raging between 0 to 10. The value is a real number including decimal values. So, number value such as 5.5 is also a valid CVSS score.)

    • Age of attack (in terms of years and the rage between (0 to 100 years). For example: greater than or lesser than in term of years)

    • File Type (for example: MPEG, MP4, PPT, *.doc, and so on)

    • Vulnerability Type (for example: buffer overflow, injection, use after free, Cross-site scripting (XSS), Remote Code Execution (RCE), and so on.

    Additionally, the CLI interface for configuring the existing Product and Vendor tags is made more user friendly with possible completions being available for configuration.

    • Vendor (for example: Microsoft, Apple, Red Hat, Google, Juniper, Cisco, Oracle, and so on.)

    • Product (for example: Office, Database, Firefox, Chrome, Flash, DirectX, Java, Kerberos, and so on.)

    To prevent these chain attacks from being added to the policy, configure the dynamic group as follows:

    • set security idp dynamic-attack-group dyn1 filters direction expression and

    • set security idp dynamic-attack-group dyn1 filters direction values client-to-server

    • set security idp dynamic-attack-group dyn1 filters direction values exclude-server-to-client

    • set security idp dynamic-attack-group dyn1 filters direction values exclude-any

  • Custom attack groups—Contain customer-defined attack groups and can be configured through the CLI. They can contain specific predefined attacks, custom attacks, predefined attack groups, or dynamic attack groups. They are static in nature, because the attacks are specified in the group. Therefore the attack groups do not change when the security database is updated.

Starting Junos release 21.2R3, you can view the IPS Policy in predefined attacks and attack groups under IPS/Exempt rule in tenant and logical system modes. Use the commands, show security idp attack attack-group-entries, show security idp attack attack-list, and show security idp attack group-list to view the IPS policies in logical system and tenant modes.

Understanding IDP Rule Actions

Actions specify the actions you want IDP to take when the monitored traffic matches the attack objects specified in the rules.

Table 2 shows the actions you can specify for IDP rules:

Table 2: IDP Rule Actions

Term

Definition

No Action

No action is taken. Use this action when you only want to generate logs for some traffic.

Ignore Connection

Stops scanning traffic for the rest of the connection if an attack match is found. IDP disables the rulebase for the specific connection.

Note:

This action does not mean ignore an attack.

Diffserv Marking

Assigns the indicated Differentiated Services code point (DSCP) value to the packet in an attack, then passes the packet on normally.

Note that DSCP value is not applied to the first packet that is detected as an attack, but is applied to subsequent packets.

Drop Packet

Drops a matching packet before it can reach its destination but does not close the connection. Use this action to drop packets for attacks in traffic that is prone to spoofing, such as UDP traffic. Dropping a connection for such traffic could result in a denial of service that prevents you from receiving traffic from a legitimate source-IP address.

Note:

When an IDP policy is configured using a non-packet context defined in a custom signature for any application and has the action drop packet, when IDP identifies an attack the decoder will promote drop_packet to drop_connection. With a DNS protocol attack, this is not the case. The DNS decoder will not promote drop_packet to drop_connection when an attack is identified. This will ensure that only DNS attack traffic will be dropped and valid DNS requests will continue to be processed. This will also avoid TCP retransmission for the valid TCP DNS requests.

Drop Connection

Drops all packets associated with the connection, preventing traffic for the connection from reaching its destination. Use this action to drop connections for traffic that is not prone to spoofing.

Close Client

Closes the connection and sends an RST packet to the client but not to the server.

Close Server

Closes the connection and sends an RST packet to the server but not to the client.

Close Client and Server

Closes the connection and sends an RST packet to both the client and the server.

Recommended

All predefined attack objects have a default action associated with them. This is the action that Juniper Networks recommends when that attack is detected.

Note:

This action is supported only for IPS rulebases.

Recommended —A list of all attack objects that Juniper Networks considers to be serious threats, organized into categories.

  • Attack type groups attack objects by type (anomaly or signature). Within each type, attack objects are grouped by severity.

  • Category groups attack objects by predefined categories. Within each category, attack objects are grouped by severity.

  • Operating system groups attack objects by the operating system to which they apply: BSD, Linux, Solaris, or Windows. Within each operating system, attack objects are grouped by services and severity.

  • Severity groups attack objects by the severity assigned to the attack. IDP has five severity levels: Critical, Major, Minor, Warning, and Info. Within each severity, attack objects are grouped by category.

Understanding IDP Rule IP Actions

IP actions are actions that apply on future connections that use the same IP action attributes. For example, you can configure an IP action in the rule to block all future HTTP sessions between two hosts if an attack is detected on a session between the hosts. Or you can specify a timeout value that defines that the action should be applied only if new sessions are initiated within that specified timeout value. The default timeout value for IP actions is 0, which means that IP actions are never timed out.

IP actions are similar to other actions; they direct IDP to drop or close the connection. However, because you now also have the attacker’s IP address, you can choose to block the attacker for a specified time. If attackers cannot immediately regain a connection to your network, they might try to attack easier targets. Use IP actions in conjunction with actions and logging to secure your network.

IP action attributes are a combination of the following fields:

  • Source IP address

  • Destination IP address

  • Destination port

  • From-zone

  • Protocol

Table 3 summarizes the types IP actions supported by IDP rules:

Table 3: IDP Rule IP Actions

Term

Definition

Notify

Does not take any action against future traffic, but logs the event. This is the default.

Drop/Block Session

All packets of any session matching the IP action rule are dropped silently.

Close Session

Any new sessions matching this IP action rule are closed by sending RST packets to the client and server.

When traffic matches multiple rules, the most severe IP action of all matched rules is applied. The most severe IP action is the Close Session action, the next in severity is the Drop/Block Session action, and then the Notify action.

Note:

After enhancements to the central point, the system has the following limitations:

  • The maximum active mode ip-action number for each SPU is limited to 600000 entries. When this limit is reached, you cannot create a new active mode ip-action entry on the SPU.

  • The maximum all modes (active mode and passive mode) ip-action number for each SPU is limited to 1200000 entries. When this limit is reached, you cannot create a new active mode ip-action entry on the SPU.

  • When you run the clear ip-action command, the ip-action entries are deleted through ring messages. When the CPU usage is high, the deleted ring messages are dropped and resent by the active mode ip-action. As the deleting process takes time, you can see few ip-action entries when you run the show ip-action command.

On devices where central point enhancements are not done, only active mode ip-action exists and the maximum ip-action number is limited to 600000. When this limit is reached, you cannot create a new active mode ip-action entry.

Understanding IDP Rule Notifications

Notification defines how information is to be logged when an action is performed. When attacks are detected, you can choose to log an attack and create log records with attack information and send that information to the log server.

By using notifications, you can also configure the following options that instruct the log server to perform specific actions on logs generated for each rule:

  • Set Alerts—Specify an alert option for a rule in the IDP policy. When the rule is matched, the corresponding log record displays an alert in the alert column of the Log Viewer. Security administrators use alerts to become aware of and react to important security events.

  • Set Severity Level—Set severity levels in logging to support better organization and presentation of log records on the log server. You can use the default severity settings of the selected attack objects or choose a specific severity for your rule. The severity you configure in the rules overrides the inherited attack severity. You can set the severity level to the following levels:

    • Info—2

    • Warning—3

    • Minor—4

    • Major—5

    • Critical—7

Example: Inserting a Rule in the IDP Rulebase

This example shows how to insert a rule in the IDP rulebase.

Requirements

Before you begin:

Overview

The IDP rule-matching algorithm starts from the top of the rulebase and checks traffic against all rules in the rulebase that match the specified match conditions. You determine the sequence in which rules are applied to network traffic by placing them in the desired order. When you add a rule to the rulebase, it is placed at the end of the existing list of rules. To place a rule in any other location than at the end of the rulebase, you insert the rule at the desired location in the rulebase. This example places rule R2 before rule R1 in the IDP IPS rulebase in a policy called base-policy.

Configuration

Procedure

Step-by-Step Procedure

To insert a rule in the rulebase:

  1. Define the position of the rule in the rulebase based on the order in which you want the rule to be evaluated.

  2. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security idp status command.

Example: Deactivating and Activating Rules in an IDP Rulebase

This example shows how to deactivate and activate a rule in a rulebase.

Requirements

Before you begin:

Overview

In a rulebase, you can disable and enable rules by using the deactivate and activate commands. The deactivate command comments out the specified statement from the configuration. Rules that have been deactivated do not take effect when you issue the commit command. The activate command adds the specified statement back to the configuration. Rules that have been activated take effect when you next issue the commit command. This example shows how to deactivate and reactivate rule R2 in an IDP IPS rulebase that is associated with a policy called base-policy.

Configuration

Procedure

Step-by-Step Procedure

To deactivate and activate a rule in a rulebase:

  1. Specify the rule that you want to deactivate.

  2. Activate the rule.

  3. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security idp status command.

Understanding IDP Application-Level DDoS Rulebases

The application-level DDoS rulebase defines parameters used to protect servers, such as DNS or HTTP, from application-level distributed denial-of-service (DDoS) attacks. You can set up custom application metrics based on normal server activity requests to determine when clients should be considered an attack client. The application-level DDoS rulebase is then used to defines the source match condition for traffic that should be monitored, then takes the defined action: close server, drop connection, drop packet, or no action. It can also perform an IP action: ip-block, ip-close, ip-notify, ip-connection-rate-limit, or timeout. Table 4 summarizes the options that you can configure in the application-level DDoS rulebase rules.

Table 4: Application-Level DDoS Rulebase Components

Term

Definition

Match condition

Specify the network traffic you want the device to monitor for attacks.

Action

Specify the actions you want Intrusion Detection and Prevention (IDP) to take when the monitored traffic matches the application-ddos objects specified in the application-level DDoS rule.

IP Action

Enables you to implicitly block a source address to protect the network from future intrusions while permitting legitimate traffic. You can configure one of the following IP action options in application-level DDoS: ip-block, ip-close, ip-notify, and ip-connection-rate-limit.

Understanding IDP IPS Rulebases

The intrusion prevention system (IPS) rulebase protects your network from attacks by using attack objects to detect known and unknown attacks. It detects attacks based on stateful signature and protocol anomalies. Table 5 summarizes the options that you can configure in the IPS-rulebase rules.

Table 5: IPS Rulebase Components

Term

Definition

Match condition

Specify the type of network traffic you want the device to monitor for attacks. For more information about match conditions, see Understanding IDP Policy Rules.

Attack objects/groups

Specify the attacks you want the device to match in the monitored network traffic. Each attack is defined as an attack object, which represents a known pattern of attack. For more information about attack objects, see Understanding IDP Policy Rules.

Terminal flag

Specify a terminal rule. The device stops matching rules for a session when a terminal rule is matched. For more information about terminal rules, see Understanding IDP Terminal Rules .

Action

Specify the action you want the system to take when the monitored traffic matches the attack objects specified in the rules. If an attack triggers multiple rule actions, then the most severe action among those rules is executed. For more information about actions, see Understanding IDP Policy Rules.

IP Action

Enables you to protect the network from future intrusions while permitting legitimate traffic. You can configure one of the following IP action options in the IPS rulebase—notify, drop, or close. For more information about IP actions, see Understanding IDP Policy Rules.

Notification

Defines how information is to be logged when action is performed. You can choose to log an attack, create log records with the attack information, and send information to the log server. For more information, see Understanding IDP Policy Rules.

Example: Defining Rules for an IDP IPS RuleBase

This example shows how to define rules for an IDP IPS rulebase.

Requirements

Before you begin:

Note:

For using IDP custom policy with pre-defined attacks, you need to have Signature database downloaded on the device.

For more details see Example: Updating the IDP Signature Database Manually.

Overview

Each rule is composed of match conditions, objects, actions, and notifications. When you define an IDP rule, you must specify the type of network traffic you want IDP to monitor for attacks by using the following characteristics—source zone, destination zone, source IP address, destination IP address, and the Application Layer protocol supported by the destination IP address. The rules are defined in rulebases, and rulebases are associated with policies.

This example describes how to create a policy called base-policy, specify a rulebase for this policy, and then add rule R1 to this rulebase. In this example, rule R1:

  • Specifies the match condition to include any traffic from a previously configured zone called trust to another previously configured zone called untrust. The match condition also includes a predefined attack group Critical - TELNET. The application setting in the match condition is default and matches any application configured in the attack object.

  • Specifies an action to drop connection for any traffic that matches the criteria for rule R1.

  • Enables attack logging and specifies that an alert flag is added to the attack log.

  • Specifies a severity level as critical.

After defining the rule, you specify base-policy as the active policy on the device.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To define rules for an IDP IPS rulebase:

  1. Create a policy by assigning a meaningful name to it.

  2. Associate a rulebase with the policy.

  3. Add rules to the rulebase.

  4. Define the match criteria for the rule.

  5. Define an attack as match criteria.

  6. Specify an action for the rule.

  7. Specify notification and logging options for the rule.

  8. Set the severity level for the rule.

  9. Activate the policy.

Results

From configuration mode, confirm your configuration by entering the show security idp command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform this task:

Verifying the Configuration

Purpose

Verify that the rules for the IDP IPS rulebase configuration are correct.

Action

From operational mode, enter the show security idp status command.

Understanding IDP Exempt Rulebases

The exempt rulebase works in conjunction with the intrusion prevention system (IPS) rulebase to prevent unnecessary alarms from being generated. You configure rules in this rulebase to exclude known false positives or to exclude a specific source, destination, or source/destination pair from matching an IPS rule. If traffic matches a rule in the IPS rulebase, the system attempts to match the traffic against the exempt rulebase before performing the action specified. Carefully written rules in an exempt rulebase can significantly reduce the number of false positives generated by an IPS rulebase.

Configure an exempt rulebase in the following conditions:

  • When an IDP rule uses an attack object group that contains one or more attack objects that produce false positives or irrelevant log records.

  • When you want to exclude a specific source, destination, or source/destination pair from matching an IDP rule. This prevents IDP from generating unnecessary alarms.

Note:

Make sure to configure the IPS rulebase before configuring the exempt rulebase.

Table 6 summarizes the options that you can configure in the exempt-rulebase rules.

Table 6: Exempt Rulebase Options

Term

Definition

Match condition

Specify the type of network traffic you want the device to monitor for attacks in the same way as in the IPS rulebase. However, in the exempt rulebase, you cannot configure an application; it is always set to any.

Attack objects/groups

Specify the attack objects that you do not want the device to match in the monitored network traffic.

Example: Defining Rules for an IDP Exempt Rulebase

This example shows how to define rules for an exempt IDP rulebase.

Requirements

Before you begin, create rules in the IDP IPS rulebase. See Example: Defining Rules for an IDP IPS RuleBase.

Overview

When you create an exempt rule, you must specify the following:

  • Source and destination for traffic you want to exempt. You can set the source or destination to Any to exempt network traffic originating from any source or sent to any destination. You can also set source-except or destination-except to specify all the sources or destinations except the specified source or destination addresses.

    Note:

    You can now specify source-address and source-except addresses when from-zone is any. Similarly, when to-zone is any, you can specify destination-address and destination-except addresses.

  • The attacks you want IDP to exempt for the specified source/destination addresses. You must include at least one attack object in an exempt rule.

This example shows that the IDP policy generates false positives for the attack FTP:USER:ROOT on an internal network. You configure the rule to exempt attack detection for this attack when the source IP is from your internal network.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To define rules for an exempt IDP rulebase:

  1. Specify the IDP IPS rulebase for which you want to define and exempt the rulebase.

  2. Associate the exempt rulebase with the policy and zones, and add a rule to the rulebase.

  3. Specify the source and destination addresses for the rulebase.

  4. Specify the attacks that you want to exempt from attack detection.

  5. Activate the policy.

Results

From configuration mode, confirm your configuration by entering the show security idp command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform this task:

Verifying the Configuration

Purpose

Verify that the defined rules were exempt from the IDP rulebase configuration.

Action

From operational mode, enter the show security idp status command.

Understanding IDP Terminal Rules

The Intrusion Detection and Prevention (IDP) rule-matching algorithm starts from the top of the rulebase and checks traffic against all rules in the rulebase that match the source, destination, and service. However, you can configure a rule to be terminal. A terminal rule is an exception to this algorithm. When a match is discovered in a terminal rule for the source, destination, zones, and application, IDP does not continue to check subsequent rules for the same source, destination, and application. It does not matter whether or not the traffic matches the attack objects in the matching rule.

You can use a terminal rule for the following purposes:

  • To set different actions for different attacks for the same Source and Destination.

  • To disregard traffic that originates from a known trusted source. Typically, the action is None for this type of terminal rule.

  • To disregard traffic sent to a server that is vulnerable only to a specific set of attacks. Typically, the action is Drop Connection for this type of terminal rule.

Use caution when defining terminal rules. An inappropriate terminal rule can leave your network open to attacks. Remember that traffic matching the source, destination, and application of a terminal rule is not compared to subsequent rules, even if the traffic does not match an attack object in the terminal rule. Use a terminal rule only when you want to examine a certain type of traffic for one specific set of attack objects. Be particularly careful about terminal rules that use any for both the source and destination. Terminal rules should appear near the top of the rulebase before other rules that would match the same traffic.

Example: Setting Terminal Rules in Rulebases

This example shows how to configure terminal rules.

Requirements

Before you begin:

Overview

By default, rules in the IDP rulebase are not terminal, which means IDP examines all rules in the rulebase and executes all matches. You can specify that a rule is terminal; that is, if IDP encounters a match for the source, destination, and service specified in a terminal rule, it does not examine any subsequent rules for that connection.

This example shows how to configure terminal rules. You define rule R2 to terminate the match algorithm if the source IP of the traffic originates from a known trusted network in your company. If this rule is matched, IDP disregards traffic from the trusted network and does not monitor the session for malicious data.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, seeUsing the CLI Editor in Configuration Mode in the CLI User Guide.

To configure terminal rules:

  1. Create an IDP policy.

  2. Define a rule and set its match criteria.

  3. Set the terminal flag for the rule.

  4. Specify the attacks that you want to exempt from attack detection.

  5. Specify an action for the rule.

Results

From configuration mode, confirm your configuration by entering the show security idp command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform this task:

Verifying the Configuration

Purpose

Verify that the terminal rules were configured correctly.

Action

From operational mode, enter the show security idp status command.

Understanding DSCP Rules in IDP Policies

Differentiated Services code point (DSCP) is an integer value encoded in the 6-bit field defined in IP packet headers. It is used to enforce class-of-service (CoS) distinctions. CoS allows you to override the default packet forwarding behavior and assign service levels to specific traffic flows.

You can configure DSCP value as an action in an IDP policy rule. You first define the traffic by defining match conditions in the IDP policy and then associate a DiffServ marking action with it. Based on the DSCP value, behavior aggregate classifiers set the forwarding class and loss priority for the traffic deciding the forwarding treatment the traffic receives.

All packets that match the IDP policy rule have the CoS field in their IP header rewritten with the DSCP value specified in the matching policy. If the traffic matches multiple rules with differing DSCP values, the first IDP rule that matches takes effect and this IDP rule then applies to all traffic for that session.

Example: Configuring DSCP Rules in an IDP Policy

This example shows how to configure DSCP values in an IDP policy.

Requirements

Before you begin:

  • Configure network interfaces

  • Enable IDP application services in a security policy

  • Create security zones

  • Define rules

Overview

Configuring DSCP values in IDP policies provides a method of associating CoS values—thus different levels of reliability—for different types of traffic on the network.

This example shows how to create a policy called policy1, specify a rulebase for this policy, and then add rule R1 to this rulebase. In this example, rule R1:

  • Specifies the match condition to include any traffic from a previously configured zone called trust to another previously configured zone called untrust. The match condition also includes a predefined attack group called HTTP - Critical. The application setting in the match condition is specified as the default and matches any application configured in the attack object.

  • Specifies an action to rewrite the CoS field in the IP header with the DSCP value 50 for any traffic that matches the criteria for rule R1.

    Note:

    Use the command show security idp attack attack-list recursive predefined-group "HTTP - Critical" to see the details of what is included in the pre-defined group "HTTP - Critical".

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure DSCP values in an IDP policy:

  1. Create a policy by assigning a meaningful name to it.

  2. Associate a rulebase with the policy.

  3. Add rules to the rulebase.

  4. Define the match criteria for the rule.

  5. Specify an action for the rule.

  6. Continue to specify any notification or logging options for the rule, if required.

  7. Activate the policy.

Results

From configuration mode, confirm your configuration by entering the show security idp command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform this task:

Verifying the Configuration

Purpose

Verify that the DSCP values were configured in an IDP policy.

Action

From operational mode, enter the show security idp status command.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
18.2R1
Previously IDP signature updates supported only nine tags under filters. The seven tags are category, direction, false-positives, performance, product, recommended, service, severity, and vendor. IDP signature updates now support four new additional tags under filters for creating more sophisticated dynamic groups in addition to the existing nine tags.