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
- Understanding IDP Rule Objects
- Understanding IDP Rule Actions
- Understanding IDP Rule IP Actions
- Understanding IDP Rule Notifications
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-zoneandto-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. Specifyanyto monitor network traffic originating from and to any zone. The default value isany.Note:You can specify
source-addressandsource-exceptaddresses whenfrom-zoneisany. Similarly, whento-zoneisany, you can specifydestination-addressanddestination-exceptaddresses.Source IP address—Specify the source IP address from which the network traffic originates. You can specifyanyto monitor network traffic originating from any IP address. You can also specifysource-exceptto specify all sources except the specified addresses. The default value isany.Destination IP address—Specify the destination IP address to which the network traffic is sent. You can set this toanyto monitor network traffic sent to any IP address. You can also specifydestination-exceptto specify all destinations except the specified addresses. The default value isany.-
Application—Specify the Application Layer protocols supported by the destination IP address. You can specifyanyfor all applications or specify an application, for example,junos-bgp. You can specifydefaultfor 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
- Address or Network Objects
- Application or Service Objects
- Attack Objects
- Attack Object Groups
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 specifyjunos-tcp-anyto 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 specifyjunos-udp-anyto 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 specifyjunos-icmp-allto 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:
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 |
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
andshould be used in the exclude values. As is the case with all filters, the default expression isor. However, there is a choice ofandin 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-servercommandIn 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-nameshow security idp attack group-list attack-name
Use the
show security idp attack attack-list attack-group group-namecommand 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-listcommand 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-namecommand 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 andset security idp dynamic-attack-group dyn1 filters direction values client-to-serverset security idp dynamic-attack-group dyn1 filters direction values exclude-server-to-clientset 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:
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.
|
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:
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.
After enhancements to the central point, the system has the following limitations:
The maximum active mode
ip-actionnumber for each SPU is limited to 600000 entries. When this limit is reached, you cannot create a new active modeip-actionentry on the SPU.The maximum all modes (active mode and passive mode)
ip-actionnumber for each SPU is limited to 1200000 entries. When this limit is reached, you cannot create a new active modeip-actionentry on the SPU.When you run the
clear ip-actioncommand, theip-actionentries are deleted through ring messages. When the CPU usage is high, the deleted ring messages are dropped and resent by the active modeip-action. As the deleting process takes time, you can see fewip-actionentries when you run theshow ip-actioncommand.
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:
Configure network interfaces.
Define rules in a rulebase. See Example: Defining Rules for an IDP IPS RuleBase.
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:
Define the position of the rule in the rulebase based on the order in which you want the rule to be evaluated.
[edit] user@host# insert security idp idp-policy base-policy rulebase-ips rule R2 before rule R1
If you are done configuring the device, commit the configuration.
[edit] user@host# commit
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:
Configure network interfaces.
Define rules in a rulebase. See Example: Defining Rules for an IDP IPS RuleBase.
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:
Specify the rule that you want to deactivate.
[edit] user@host# deactivate security idp idp-policy base-policy rulebase-ips rule R2
Activate the rule.
[edit] user@host# activate security idp idp-policy base-policy rulebase-ips rule R2
If you are done configuring the device, commit the configuration.
[edit] user@host# commit
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.
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.
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:
Configure network interfaces.
Create security zones. See Example: Creating Security Zones.
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.
set security idp idp-policy base-policy set security idp idp-policy base-policy rulebase-ips rule R1 match from-zone trust to-zone untrust source-address any destination-address any application default set security idp idp-policy base-policy rulebase-ips rule R1 match attacks predefined-attack-groups "TELNET-Critical" set security idp idp-policy base-policy rulebase-ips rule R1 then action drop-connection set security idp idp-policy base-policy rulebase-ips rule R1 then notification log-attacks alert set security idp idp-policy base-policy rulebase-ips rule R1 then severity critical set security idp active-policy base-policy
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:
Create a policy by assigning a meaningful name to it.
[edit] user@host# edit security idp idp-policy base-policy
Associate a rulebase with the policy.
[edit security idp idp-policy base-policy] user@host# edit rulebase-ips
Add rules to the rulebase.
[edit security idp idp-policy base-policy rulebase-ips] user@host# edit rule R1
Define the match criteria for the rule.
[edit security idp idp-policy base-policy rulebase-ips rule R1] user@host# set match from-zone trust to-zone untrust source-address any destination-address any application default
Define an attack as match criteria.
[edit security idp idp-policy base-policy rulebase-ips rule R1] user@host# set match attacks predefined-attack-groups "TELNET-Critical"
Specify an action for the rule.
[edit security idp idp-policy base-policy rulebase-ips rule R1] user@host# set then action drop-connection
Specify notification and logging options for the rule.
[edit security idp idp-policy base-policy rulebase-ips rule R1] user@host# set then notification log-attacks alert
Set the severity level for the rule.
[edit security idp idp-policy base-policy rulebase-ips rule R1] user@host# set then severity critical
Activate the policy.
[edit] user@host# set security idp active-policy base-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.
[edit]
user@host# show security idp
idp-policy base-policy {
rulebase-ips {
rule R1 {
match {
from-zone trust;
source-address any;
to-zone untrust;
destination-address any;
application default;
attacks {
predefined-attack-groups Critical-TELNET;
}
}
then {
action {
drop-connection;
}
notification {
log-attacks {
alert;
}
}
severity critical;
}
}
}
}
active-policy base-policy;
If you are done configuring the device, enter commit from configuration mode.
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.
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.
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 |
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
Anyto exempt network traffic originating from any source or sent to any destination. You can also setsource-exceptordestination-exceptto specify all the sources or destinations except the specified source or destination addresses.Note:You can now specify
source-addressandsource-exceptaddresses whenfrom-zoneisany. Similarly, whento-zoneisany, you can specifydestination-addressanddestination-exceptaddresses.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.
set security idp idp-policy base-policy set security idp idp-policy base-policy rulebase-exempt rule R1 match from-zone trust to-zone any set security idp idp-policy base-policy rulebase-exempt rule R1 match source-address internal-devices destination-address any set security idp idp-policy base-policy rulebase-exempt rule R1 match attacks predefined-attacks "FTP:USER:ROOT" set security idp active-policy base-policy
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:
Specify the IDP IPS rulebase for which you want to define and exempt the rulebase.
[edit] user@host# edit security idp idp-policy base-policy
Associate the exempt rulebase with the policy and zones, and add a rule to the rulebase.
[edit security idp idp-policy base-policy] user@host# set rulebase-exempt rule R1 match from-zone trust to-zone any
Specify the source and destination addresses for the rulebase.
[edit security idp idp-policy base-policy] user@host# set rulebase-exempt rule R1 match source-address internal-devices destination-address any
Specify the attacks that you want to exempt from attack detection.
[edit security idp idp-policy base-policy] user@host# set rulebase-exempt rule R1 match attacks predefined-attacks "FTP:USER:ROOT"
Activate the policy.
[edit] user@host# set security idp active-policy base-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.
[edit]
user@host# show security idp
idp-policy base-policy {
rulebase-exempt {
rule R1 {
match {
from-zone trust;
source-address internal-devices;
to-zone any;
destination-address any;
attacks {
predefined-attacks FTP:USER:ROOT;
}
}
}
}
active-policy base-policy;
If you are done configuring the device, enter commit from configuration mode.
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
Nonefor 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 Connectionfor 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:
Configure network interfaces.
Enable IDP application services in a security policy.
Create security zones. See Example: Creating Security Zones.
Define rules. See Example: Inserting a Rule in the IDP Rulebase .
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.
set security idp idp-policy base-policy set security idp idp-policy base-policy rulebase-ips rule R2 match source-address internal destination-address any set security idp idp-policy base-policy rulebase-ips rule R2 terminal set security idp idp-policy base-policy rulebase-ips rule R2 match attacks predefined-attacks FTP:USER:ROOT set security idp idp-policy base-policy rulebase-ips rule R2 then action recommended
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:
Create an IDP policy.
[edit] user@host# set security idp idp-policy base-policy
Define a rule and set its match criteria.
[edit security idp idp-policy base-policy] user@host# set rulebase-ips rule R2 match source-address internal destination-address any
Set the terminal flag for the rule.
[edit security idp idp-policy base-policy] user@host# set rulebase-ips rule R2 terminal
Specify the attacks that you want to exempt from attack detection.
[edit security idp idp-policy base-policy] user@host# set rulebase-ips rule R2 match attacks predefined-attacks FTP:USER:ROOT
Specify an action for the rule.
[edit security idp idp-policy base-policy] user@host# rulebase-ips rule R2 then action recommended
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.
[edit]
user@host# show security idp
idp-policy base-policy {
rulebase-ips {
rule R2 {
match {
source-address internal;
destination-address any;
attacks {
predefined-attacks FTP:USER:ROOT;
}
}
then {
action {
recommended;
}
}
terminal;
}
}
}
If you are done configuring the device, enter commit from configuration mode.
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.
set security idp idp-policy base-policy set security idp idp-policy base-policy rulebase-ips rule R1 match from-zone Zone-1 to-zone Zone-2 source-address any destination-address any application default set security idp idp-policy base-policy rulebase-ips rule R1 match attacks predefined-attack-groups "HTTP - Critical" set security idp idp-policy base-policy rulebase-ips rule R1 then action mark-diffserv 50
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:
Create a policy by assigning a meaningful name to it.
[edit] user@host# edit security idp idp-policy base-policy
Associate a rulebase with the policy.
[edit security idp idp-policy base-policy] user@host# edit rulebase-ips
Add rules to the rulebase.
[edit security idp idp-policy base-policy rulebase-ips] user@host# edit rule R1
Define the match criteria for the rule.
[edit security idp idp-policy base-policy rulebase-ips R1] user@host# set match from-zone trust to-zone untrust source-address any destination-address any application default user@host# set match attacks predefined-attack-group “HTTP - Critical”
Specify an action for the rule.
[edit security idp idp-policy base-policy rulebase-ips R1] user@host# set then action mark-diffserv 50
Continue to specify any notification or logging options for the rule, if required.
Activate the policy.
[edit] user@host# set security idp active-policy base-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.
[edit]
user@host# show security idp
idp-policy base-policy{
rulebase-ips {
rule R1 {
match {
from-zone trust;
source-address any;
to-zone untrust;
destination-address any;
application default;
attacks {
predefined-attack-groups HTTP-Critical;
}
}
then {
action {
mark-diffserv {
50;
}
}
}
}
}
active-policy base-policy;
If you are done configuring the device, enter commit from configuration mode.
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.