Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

IDP Policies Overview

 

The Junos OS Intrusion Detection and Prevention (IDP) policy enables you to selectively enforce various attack detection and prevention techniques on network traffic passing through an IDP-enabled device. It allows you to define policy rules to match a section of traffic based on a zone, network, and application, and then take active or passive preventive actions on that traffic.

For more information, see the following topics:

IDP Policies Overview

An IDP policy defines how your device handles the network traffic. It allows you to enforce various attack detection and prevention techniques on traffic traversing your network.

A policy is made up of rule bases, and each rule base contains a set of rules. You define rule parameters, such as traffic match conditions, action, and logging requirements, then add the rules to rule bases. After you create an IDP Policy by adding rules in one or more rule bases, you can select that policy to be the active policy on your device.

Junos OS allows you to configure multiple IDP policies, but a device can have only one active IDP policy at a time. Validation of configurations is done for the IDP policy that is configured as an active policy. You can install the same IDP policy on multiple devices, or you can install a unique IDP policy on each device in your network. A single policy can contain only one instance of any type of rule base.

Note

The IDP feature is enabled by default. No license is required. Custom attacks and custom attack groups in IDP policies can also be configured and installed even when a valid license and signature database are not installed on the device.

The following IDP policies are supported:

  • DMZ_Services

  • DNS_Services

  • File_Server

  • Getting_Started

  • IDP_Default

  • Recommended

  • Web_Server

You can perform the following tasks to manage IDP policies:

  • Create new IDP policies starting from scratch.

  • Create an IDP policy starting with one of the predefined templates provided by Juniper Networks.

  • Add or delete rules within a rule base. You can use any of the following IDP objects to create rules:

    • Zone

      Note

      You can configure source-address and source-except addresses when from-zone is any, and similarly to have destination-address and destination-except addresses when to-zone is any.

    • Network objects available in the base system

    • Predefined service objects provided by Juniper Networks

    • Custom application objects

    • Predefined attack objects provided by Juniper Networks

  • Create custom attack objects.

  • Update the signature database provided by Juniper Networks. This database contains all predefined objects.

  • Maintain multiple IDP policies. Any one of the policies can be applied to the device.

The IDP policies for each user logical system are compiled together and stored on the data plane memory. To estimate adequate data plane memory for a configuration, consider these two factors:

  • IDP policies applied to each user logical system are considered unique instances because the ID and zones for each user logical system are different. Estimates need to consider the combined memory requirements for all user logical systems.

  • As the application database increases, compiled policies requires more memory. Memory usage should be kept below the available data plane memory to allow for database increases.

Overview of IDP Policy support for Unified Policies

Previously, when a policy is created, to start with, Layer 3 and Layer 4 traffic was considered for match criteria. Policy match conditions are used to classify the traffic that arrives on a device. The security policies made decisions based on the standard five-part tuple matching conditions which are source port, destination port, source IP address, destination IP address, and protocol. Applications were not explicitly allowed or considered as a discrete match. To provide an enhanced security device, the device must be able to match based on applications and provide the deep packet inspection inside the device by identifying the L3/L4 constructs/details.

Dynamic application is added to the matching conditions and the data traffic now can also be classified based on the Layer 7 application inspection results. Application identification identifies dynamic or real-time Layer 4 to Layer 7 application, and after a particular application is identified, actions are performed in accordance with configured rules as part of the security policy rules configuration on the device.

Unified Policies are supported on Juniper devices, allowing granular control and enforcement of Dynamic Layer Applications within the traditional Security Policy. Layer 7 dynamic applications are integrated with security policy match criteria and IDP policy supports Layer 7 application based security policies.

Any traffic denied or rejected by the security policy based on Layer 3 or Layer 4 criteria is dropped immediately. Traffic permitted by the security policy is further assessed by the application firewall at Layer 7 based on its application ID.

With the addition of dynamic applications as one of the matching conditions in the security policies IDP policy support for Layer 7 application based security policies is also included.

IDP policy is directly assigned in the security policy rule. This is to simplify IDP policy usage and to provide flexibility to have multiple policies active at the same time. As a part of session interest check IDP will enabled if IDP policy is present in any of the matched rules. IDP policy is activated in security policies, by permitting the IDP policy within the application services using the set security policies from-zone zone-name to-zone zone-name policy policy-name then permit application-services idp-policy idp-policy-name command. Since IDP policy name is directly use in the security policy rule, the [edit security idp active-policy policy-name] statement is deprecated.

Benefits of IDP Policy Unification with Security Policy

  • Provides true application based devices.

  • Improved and simplified IDP policy configurations. Heavy configurations used previously needed continuous maintenance.

  • Provides enhanced and granular security, by applying firewall policies initially and later applying IDP policy immediately based on match criteria

  • Reduced complexity for blocking an application in a network.

Understanding IDP Policy Support for Unified Policies

With the support of IDP policy within unified security policy:

  • IDP policy is activated using the set security policies from-zone <zone-name> to-zone <zone-name> policy <policy-name> then permit application-services idp-policy <idp-policy-name> command.

  • With the IDP policy being made available within the unified security policy all the IDP matches will be handled within the unified policy unless explicit source, destination, or application is defined (traditional policy).

  • You can additionally configure match conditions in IDP to achieve additional inspection granularity.

  • Configuring source or destination address, source and destination-except, from and to zone, or application is not required with unified policy, as the match happens in the security policy itself.

  • Layer 7 application might get changed during a session lifetime and this application change might lead to disabling of IDP service for the session.

  • Initial security policy match might result in single or multiple policy matches. As a part of session interest check IDP will be enabled if IDP policy is present in any of the matched rules.

If you have configured a traditional security policy (with 5-tuples matching condition or dynamic-application configured as none) and an unified policy (with 6-tuple matching condition), the traditional security policy matches the traffic first, prior to the unified policy.

When you configure a unified policy with a dynamic application as one of the matching condition, the configuration eliminates the additional steps involved in IDP policy configuration. All the IDP policy configurations are handled within the unified security policy and simplifies the task of configuring IDP policy to detect any attack or intrusions for a given session.

IDP Policy Selection for Unified Policies

When a security policy is processed for a session, initial security policy match might result in single or multiple policy matches. As a part of session interest check IDP will be enabled if IDP policy is present in any of the matched rules.

If application cache is present policy match will result in single policy match.

After dynamic application identification is performed, policy re-lookup is performed by the security policy. Layer 7 application services (IDP) will be informed to disable themselves if IDP is not configured on the final matched policy. With the IDP policy being made available within the unified security policy all the IDP matches will be handled within the unified policy unless explicit source, destination, or application is defined (traditional policy). Configuring source or destination address, source and destination-except, from and to zone, or application is not required with unified policy, as the match happens in the security policy itself. Figure 1 and Figure 2 below provide the workflow details for the IDP policy selection for Unified Policies.

Figure 1: IDP Processing for Flow First Path
IDP Processing for
Flow First Path
Figure 2: IDP Processing after Final Policy Lookup
IDP Processing
after Final Policy Lookup

Table 1: Example of Policy Selection within a Security Policy

Policy

Source

Zone
Source

Address
Destination

Zone
Destination

Address
Dynamic

Application
Application

service
Policies

P1

In

1.1.1.1

Out

Any

HTTP

IDP

recommended

P2

In

1.1.1.1

Out

Any

GMAIL

UTM

utm_policy_1

Traditional Policy and Unified Policy Details for IDP Policy

The following details are to be noted when you want to configure IDP policy after you have upgraded your devices for implementing unified policies:

  • All existing (traditional) IDP policies are treated the same way as a unified policy with dynamic application configured as none.

  • Configuring a traditional IDP policy and a unified policy with IDP policy as one of the potential policy with dynamic application as matching condition on the same security policy is not supported.

  • If you are downgrading from Junos OS Release 18.2R1 to any earlier versions of Junos OS Release, you must delete all unified policies to avoid commit check failure after the downgrade.

Enabling IDP in a Traditional Security Policy

For transit traffic to pass through IDP inspection, you configure a security policy and enable IDP application services on all traffic that you want to inspect. Security policies contain rules defining the types of traffic permitted on the network and the way that the traffic is treated inside the network. Enabling IDP in a security policy directs traffic that matches the specified criteria to be checked against the IDP rulebases.

Note

IDP is enabled by default. No license is required. Custom attacks and custom attack groups in IDP policies can be configured and installed even when a valid license and signature database are not installed on the device.

To allow transit traffic to pass through without IDP inspection, specify a permit action for the rule without enabling the IDP application services. Traffic matching the conditions in this rule passes through the device without IDP inspection.

Note

The action set in the security policy action must be permit. You cannot enable IDP for traffic that the device denies or rejects.

If you have configured a traditional security policy (with 5-tuples matching condition or dynamic application configured as none) and an unified policy (with 6-tuple matching condition), the traditional security policy matches the traffic first, prior to the unified policy.

When you configure a unified policy with a dynamic application as one of the matching condition, the configuration eliminates the additional steps of configuring, source and destination address, source destination except, from and to zones, or application. All the IDP policy configurations are handled within the unified security policy and simplifies the task of configuring IDP policy to detect any attack or intrusions for a given session. Configuring source or destination address, source and destination-except, from and to zone, or application is not required with unified policy, as the match happens in the security policy itself.

This type of configuration can be used to monitor traffic to and from a secure area of an internal network as an added security measure for confidential communications.

To enable IDP services on all HTTP and HTTPS traffic flowing in both directions on the device:

  1. Create a security policy for traffic flowing from Zone1 to Zone2 that has been identified as junos-http or junos-https application traffic.
  2. Specify the action to be taken on Zone1 to Zone2 traffic that matches conditions specified in the policy.
  3. Create another security policy for traffic flowing in the opposite direction that has been identified as junos-http or junos-https application traffic.
  4. Specify the action to be taken on traffic that matches the conditions specified in this policy.

To verify the configuration, enter the show security policies command.

Verifying the IDP Policy Compilation and Load Status

Purpose

Display the IDP log files to verify the IDP policy load and compilation status. When activating an IDP policy, you can view the IDP logs and verify if the policy is loaded and compiled successfully.

Action

To track the load and compilation progress of an IDP policy, configure either one or both of the following in the CLI:

  • You can configure a log file, which will be located in /var/log/, and set trace option flags to record these operations:

  • You can configure your device to log system log messages to a file in the /var/log directory:

After committing the configuration in the CLI, enter either of the following commands from the shell prompt in the UNIX-level shell:

Sample Output

user@host> start shell
user@host% tail -f /var/log/idpd

Sample Output

user@host> start shell
user@host% tail -f /var/log/messages

Meaning

Displays log messages showing the procedures that run in the background after you commit the set security idp active-policy command. This sample output shows that the policy compilation, sensor configuration, and policy load are successful.