Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Unified Security Policies

Unified policies are the security policies that enable you to use dynamic applications as match conditions as part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to detect application changes over time.

Unified Policies Overview

Starting in Junos OS Release 18.2R1, unified policies are supported on SRX Series Firewalls, allowing granular control and enforcement of dynamic Layer 7 applications within the security policy.

Unified policies are the security policies that enable you to use dynamic applications as match conditions as part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to detect application changes over time. If the traffic matches the security policy rule, one or more actions defined in the policy are applied to the traffic.

By adding dynamic applications to the match criteria, the data traffic is classified based on the Layer 7 application inspection results. AppID identifies dynamic or real-time Layer 4 through Layer 7 applications. After a particular application is identified and the matching policy is found, then the actions are applied according to the policy.

Configuring dynamic applications as match criteria in a security policy is not mandatory.

Examples of configuring dynamic applications as a match condition within a security policy are as follows:

  • set security policies from-zone z1 to-zone z2 policy p1 match dynamic-application junos:FTP

  • set security policies from-zone z1 to-zone z2 policy p1 match dynamic-application junos:HTTP

  • set security policies from-zone z1 to-zone z2 policy p1 match dynamic-application junos:GOOGLE

Examples of configuring dynamic application groups as a match condition within a security policy are as follows:

  • set security policies from-zone trust to-zone untrust policy p1 match dynamic-application junos:p2p

  • set security policies from-zone trust to-zone untrust policy p1 match dynamic-application junos:web:shopping

Benefits

  • Simplifies application-based security policy management at Layer 7.

  • Enables your device to adapt to the dynamic traffic changes in the network.

  • Provides greater control and extensibility to manage dynamic applications traffic than a traditional security policy.

Unified Policies Configuration Overview

The following sections provide more information on unified policies:

Dynamic Application Configuration Options

Table 1 provides options for configuring a unified policy with dynamic applications.

Table 1: Dynamic Application Configuration Options

Dynamic Application Configuration Options

Description

Dynamic Applications or Application Groups

Specify dynamic applications or a dynamic application group.

Examples are as follows:

  • junos:FTP (dynamic application)

  • junos:web:shopping (dynamic application group)

Any

Configuring the dynamic application as any installs the policy with the application as a wildcard (default). If an application cannot be specified, configure any as the default application. Data traffic that match the parameters in a unified policy matches the policy regardless of the application type.

None

Configuring the dynamic application as none ignores classification results from AppID and does not use the dynamic application in security policy lookups. Within the list of potential match policies, if there is any policy configured with a dynamic application as none, this policy is matched as the final policy and is terminal. If any Layer 7 services are configured in this policy, deep packet inspection for the traffic is performed.

When upgrading the Junos OS release (where dynamic applications were not supported), all existing traditional policies are considered to be policies with the dynamic application configured as none.

Dynamic Application Not Configured

If a dynamic application is not configured within a security policy, the policy is considered to be a traditional security policy This policy is similar to a policy with the dynamic application configured as none.

Starting in Junos OS Releases 19.4R1 and 20.1R1, security policy does not support using following applications as dynamic-applications match criteria:

  • junos:HTTPS

  • junos:POP3S

  • junos:IMAPS

  • junos:SMTPS

Software upgrade to the Junos OS Releases 19.4R1 and 20.1R1 and later releases fails during the validation if any of the security policies are configured with junos:HTTPS, junos:POP3S, junos:IMAPS, junos:SMTPS as dynamic-applications as match criteria.

We recommend you to use therequest system software validate package-name option before upgrading to the above mentioned releases.

We recommend you to remove any configuration that includes the dynamic-application junos:HTTPS, junos:IMAPS, junos:SMTPS or junos:POP3S as match criteria in security policies.

Default Ports and Protocols as Application Matching Criteria

Starting in Junos OS Release 18.2R1, the junos-defaults option is introduced in the security policy configuration as application match criteria. The junos-defaults group contains preconfigured statements that include predefined values for common applications. As the default protocols and ports are inherited from junos-defaults, there is no requirement to explicitly configure the ports and protocols, thus simplifying the security policy configuration.

In the following example, the security policy L7-test-policy uses junos:HTTP as the dynamic application and inherits destination TCP ports: 80, 3128, 8000, and 8080 as the application match criteria.

set security policies from-zone trust to-zone untrust policy L7-test-policy match application junos-defaults dynamic-application junos:HTTP

If the application does not have default ports and protocols, then the application uses the default ports and protocols of the dependent application. For example, junos:FACEBOOK-CHAT uses default protocols and ports of HTTP2, HTTPS, and SPDY.

The junos-defaults option must be configured along with a dynamic application. If you configure the junos-defaults option without specifying any dynamic application, then an error message displays and the configuration commit fails. Use the show security policies detail command to validate the junos-defaults option.

Pre-ID Default Policy

A unified policy leverages the information from AppID to match the application and take action as specified in the policy. Before identifying the final application, the policy cannot be matched precisely.

The pre-ID default policy temporarily allows the session to get created so that DPI can get the packet and perform application identification (AppID).

Starting in Junos OS Release 23.4R1, the pre-ID default policy ( pre-id-default-policy ) denies the flow before performing application identification (AppID) when there are no potential policies to permit the flow.

When the device receives the first packet of a traffic flow, it performs the basic 5-tuple matching and checks the defined potential policies to determine how to treat the packet. If all potential policies have the action as "deny", and the default policy action is also set to "deny", then the device denies the traffic and does not perform application identification (AppID).

If any policy has action as other than "deny", then the device performs DPI to identify the application.

The device checks for potential policies on both zone context and global context.

Default Policy Actions Prior to Dynamic Application Identification

Before an application is identified by Application Identification (AppID), the pre-id-default-policy options are applied to the session. The session timeout value, along with the required mode of session logging, are applied according to the pre-id-default-policy configuration. If there is no configuration within the pre-id-default-policy stanza, the default session timeout values are applied to the session and no logs are generated for the pre-id-default-policy.

We recommend that customers implement the set security policies pre-id-default-policy then log session-close configuration, as shown below, in their own environments.

This configuration will ensure security logs are generated by the SRX if a flow is unable to leave the pre-id-default-policy. These events are generally a result of JDPI being unable to properly classify traffic, although they may also indicate potential attempts at evading the APPID engine.

In recent versions of Junos OS, the factory-default configuration of an SRX includes the session-close configuration.

CAUTION:

Configuring session-init logging for the pre-id-default-policy can generate a large amount of logs. Each session that enters the SRX that initially matches the pre-id-default-policy will generate an event. We recommend only using this option for troubleshooting purposes.

Global Policy Utilization with Unified Policies

Zone-based security policies are prioritized over global policies when a policy lookup is implemented. Starting in Junos OS Release 18.2R1, if a unified policy is configured within the zone-based security policies, then global policy lookup is not performed. Prior to Junos OS Release 18.2R1, if no zone-based policy is matched, then a global policy lookup is performed.

Starting in Junos OS Release 20.4R1, SRX Series Firewalls support unified policies at both zone-context and global-level policies at the same time. In previous releases, unified policies supported only zone-context policies.

If the session matches any unified policy, either at a zone-level or at a global-level, then the policy is added to potential policy match list. If the session does not match a policy at zone-level then the next policy match occurs at the global-level. Global-level policies have the same match criteria as any other security policy (example: source address, destination address, application, dynamic-application and so on).

Unified Policy Actions

In a unified policy configuration, specify one of the following actions:

  • Permit—Permit the traffic.

  • Deny—Drop the traffic and close the session.

  • Reject—Notify the client, drop the traffic, and close the session.

Redirect Profile for Reject Action

Unified policies log drop and reject actions. Unified policies do not notify connected clients for drop and reject actions. The clients are unaware that the webpage is not accessible and might continue their attempts to access it.

Starting in Junos OS Release 18.2R1, a redirect profile can be configured within a unified policy. When a policy blocks HTTP or HTTPS traffic with a deny or reject action, you can define a response in the unified policy to notify the connected clients.

To provide an explanation for the action or to redirect the client to an informative webpage, use the redirect-message option at the [edit security dynamic-application profile name] hierarchy level with the reject or deny action in a unified policy configuration to display a custom message.

When you configure the redirect option, you can specify the custom message or the URL to which the client is redirected.

Limitations to Configuring a Redirect Profile in Unified Policies

There are limitations to configuring a redirect profile in unified policies. They include:

  • Support for the redirect action with block messages with a redirect URL are not available for non-HTTP or non-HTTPS applications.

  • A unified policy does not check the validity and accessibility of a user-configured redirect URL.

  • For clear text processing, out-of-order HTTP packets, or segmented HTTP requests, the available policy actions are reject or deny. A redirect profile is not available.

  • The redirect profile can be applied in unified policies only. The reject action for traditional security policies do not support a redirect action with block message profiles or a redirect URL.

SSL Proxy Profile for Reject Action

Starting in Junos OS Release 18.2R1, you can configure a redirect profile within a unified policy. When a policy blocks HTTP or HTTPS traffic with a deny or reject action, you can apply an SSL proxy profile to the traffic. SSL proxy decrypts the traffic and application identification functionality identifies the application. Next, you can take action to redirect or drop the traffic as per the configuration.

Consider the following example:

In this example, you are rejecting some of the Facebook applications such as chat, Farmville, and so on in the policy ’policy-1’. As Facebook is an encrypted application, you need SSL proxy to decrypt the traffic first.

In this example, the policy rejects the encrypted Facebook traffic and applies the configured SSL proxy profile. The SSL proxy decrypts the traffic, and JDPI identifies the application.

Now the policy takes following actions based on your configuration:

  • Redirects the client access to other URL, and closes the original session.

  • Notifies the client with pre-defined text messages, and closes the session

  • Closes the session only. In the example, the policy closes the session.

Match Criteria and Rules for Unified Policies

Unified Policy Implicit and Explicit Match

Starting in Junos OS Release 18.2R1, the command unified-policy-explicit-match is introduced at the [edit security policies] hierarchy level. This command defines the explicit and implicit policy match behavior and is disabled by default.

  • Explicit match—If a dependent application does not have any matching policy, then the traffic is dropped if explicit match is enabled. Only those security policies that are explicitly configured for the application are applied.

  • Implicit Match—If the dependent application does not have any matching policy, then the security policy that is configured for the base application is applied.

By default, the unified policies enforce implicit rules on dependent applications.

In the example shown in Table 2, the unified policy P3 is configured for FACEBOOK-ACCESS traffic. HTTP is a dependent application of FACEBOOK-ACCESS and does not have any security policy explicitly configured for it.

Table 2: Example of an Explicit and Implicit Policy Match for a Dependent Application

Dynamic Application

Policy Configured

HTTP

None

FACEBOOK-ACCESS

P3

The results for implicit and explicit match behavior is shown in Table 3.

Table 3: Example of a Policy Match ( Implicit and Explicit Match Criteria)

Application Identified

Policy Matched

Explicit or Implicit Rule Type

Result

None

P3

Implicit (Explicit is not Enabled)

The identified application is HTTP. There is no matching security policy configured for HTTP. The explicit match is not enabled (implicit match), so traffic is further processed until FACEBOOK-ACCESS is identified. The security policy that is configured for FACEBOOK-ACCESS (policy P3) is applied.

HTTP

FACEBOOK-ACCESS

HTTP

None

Explicit

The identified application is HTTP. There is no matching policy available for HTTP. The explicit match is enabled, so no security policy is applied in this case.

Profile Overlap for Layer 7 Services

While using unified policies, if AppID results have not yet identified the final application, a policy search might return a list of policies instead of a fixed policy. These policies are referred to as potential match policies. Before the final application is identified, a conflict might occur due to multiple policy matches.

In this case, an appropriate profile or default profile is applied for services such as AppQoS, SSL proxy, Content Security, and IDP.

Policy Rematch

When the policy rematch option is enabled, the unified policy allows the device to reevaluate an active session when its associated security policy is modified.

The session remains open if it continues to match the policy that allowed the session initially. The session closes if its associated policy is renamed, deactivated, or deleted. Use the extensive option to reevaluate an active session when its associated security policy is renamed, deactivated, or deleted.

If policy rematch is configured in a unified policy before a final match, then rematch behavior might lead to a session closure. After the final match, a policy rematch triggers another policy lookup based on the 6-tuple match criteria and the final identified application.

Configure policy-rematch and the policy-rematch extensive options at the [edit security policies] hierarchy level.

Limitations to Configuring Unified Policies

There are limitations to configuring unified policies. They include:

  • An existing session might close in the following cases:

    • When there is a change in the final match for the policy.

    • When a new policy is inserted within the existing policies, and if this new policy is configured with new services.

    • When a final match policy enables new services after the session is created and before the final match.

  • Policy-based VPN is not supported for unified policies and can be applied only to the traditional policy.

  • ALG traffic processing on the Unified policies does not engage ALG functions.
  • ALGs are applied when matching against traditional security policies.
    • Policies using a match condition of dynamic-application as none are treated as traditional policies .
  • FTP is an exception to ALG support on Unified policies allowing FTP file scanning for Content Security Antivirus.

  • A security policy that is configured with GPRS might not work if the policy is part of a potential match list.

  • A group VPN and user firewall authentication can be applied to a traditional security policy.

  • Final policy match information might not be available within session-init logs for policies leveraging dynamic applications.

See Also

Example: Configure a Unified Policy Using a Redirect Message Profile

This example describes how to configure a unified policy with a redirect message profile. In this example, you configure a redirect profile with a redirect URL. You use the redirect profile as a block message in the policy for traffic in the dynamic applications GMAIL and FACEBOOK-CHAT. Simultaneously, you configure the application junos-defaults so that the default port and protocol from the dynamic applications are inherited as the current policy’s destination port and protocol match criteria.

Requirements

This example uses the following hardware and software components:

  • SRX Series Firewall running Junos OS Release 18.2R1. This configuration example is tested with Junos OS release 18.2R1.

Before you begin, configure security zones. See Example: Creating Security Zones.

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, you define the redirect profile as a response when a policy blocks HTTP or HTTPS traffic with a deny or reject action. Through a redirect profile, you provide an explanation for the action or you redirect the client request to an informative webpage when the reject or deny action is applied in a security policy.

To accomplish these objectives, you perform the following tasks:

  • Configure the redirect profile with a redirect URL such as http://abc.company.com/information/block-message and use it in the policy as a block message.

  • Configure the security policy match criteria source-address and destination-address with the value any.

  • Configure the application with junos-defaults, so that the default port and protocol from dynamic-application is inherited as the current policy’s destination port and protocol match criteria.

  • Configure dynamic-application with [junos:GMAIL, junos:FACEBOOK-CHAT] so that the policy can apply the block message profile on the applications.

Configuration

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Procedure

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 a unified policy with a redirect message profile:

  1. Configure security zones.

  2. Create a profile for the redirect message.

  3. Create a security policy with a dynamic application as the match criteria.

  4. Define the policy action.

Results

From configuration mode, confirm your configuration by entering the show security policies and show security dynamic-application commands. 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

Verifying Unified Policy Configuration

Purpose

Verify that the unified policy configuration is correct.

Action

From operational mode, enter the show security policies command to display a summary of all security policies on the device.

From operational mode, enter the show security policies detail command to display a detailed summary of all security policies on the device.

Meaning

The output displays information about all currently active security sessions on the device. Verify the following information:

  • Configured policy name

  • Source and destination addresses

  • Configured applications

  • Configured dynamic applications

  • Policy reject action

See Also

Configure a URL Category with Unified Policies

Understanding URL Category with Unified Policies

Starting from Junos OS Release 18.4R1, the unified policies feature is enhanced to include URL categories as match criteria for web filtering category. URL categories can be configured to unified policies with or without dynamic-application been applied. .

When the URL category is configured as url-category any to a policy, the policy matches all categories of traffic configured to the unified policies.

When the URL category is configured as url-category none to a policy, the URL category is not used in the policy look-up. The unified policy configured with url-category none is considered as the highest priority to policy match for a traffic. When the URL category to a policy is not configured, or when you upgrade a device from previous release to latest release, the URL category of all the policies are considered as url-category none.

Limitations of URL Category with Unified Policies

Using URL categories in an unified policy has the following limitation:

  • Only the ports that are generally used such as HTTP and HTTPs traffics are supported by url-category. Hence, the policy lookup supports HTTP and HTTPs traffics.

Example: Configuring a Unified Policy Using URL Category

This example describes how to configure a unified policy with a URL category.

Requirements

This example uses the following hardware and software components:

  • SRX Series Firewall running Junos OS Release 18.4R1. This configuration example is tested with Junos OS release 18.4R1.

Before you begin, configure security zones. See Example: Creating Security Zones.

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, URL category is added to security policy as match criteria for web filtering category.

To accomplish these objectives, you perform the following tasks:

  • Configure the security policy match criteria source-address and destination-address with the value any.

  • Configure the application with junos-defaults, so that the default port and protocol from dynamic-application is inherited as the current policy’s destination port and protocol match criteria.

  • Configure dynamic-application with [junos:GMAIL, junos:FACEBOOK-CHAT] so that the policy can apply the block message profile on the applications.

  • Configure url-category with Enhanced_News_and_Media as match criteria for web filtering category.

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

CLI Quick Configuration
Step-by-Step Procedure
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 a unified policy with a redirect message profile:

  1. Configure security zones.

  2. Create a security policy with a URL category as the match criteria.

  3. Define the policy action.

Results

From configuration mode, confirm your configuration by entering the show security policies and show security dynamic-application commands. 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

Verifying Unified Policy Configuration
Purpose

Verify that the unified policy configuration is correct.

Action

From operational mode, enter the show security policies command to display a summary of all security policies on the device.

Meaning

The output displays information about all currently active security sessions on the device. Verify the following information:

  • Configured policy name

  • Source and destination addresses

  • Configured applications

  • Configured dynamic applications

  • Configured URL Category

  • Policy reject action

Configure Applications in Unified Policies

Applications in Unified Policies

Starting in Junos OS Release 19.1R1, configuring the application statement at the [edit security policies from-zone zone-name to-zone zone-name policy policy-name match] hierarchy level is optional if the dynamic-application statement is configured at the same hierarchy level.

In releases before Junos OS Release 19.1R1, it is mandatory to configure the application statement even if the dynamic-application statement is configured.

  • When the application option is defined then the defined application is used.

  • When the application option is not defined and the dynamic-application option is defined as any, then the application any is implicitly added.

  • When the application option is not defined and the dynamic-application option is defined (and is not configured as any), then the application junos-defaults is implicitly added.

Example: Configure a Unified Policy Using Dynamic Applications

This example describes how to configure a unified policy using dynamic applications.

Requirements

This example uses the following hardware and software components:

  • SRX Series Firewall running Junos OS Release 19.1R1. This configuration example is tested with Junos OS release 19.1R1.

Before you begin, configure security zones. See Example: Creating Security Zones.

No special configuration beyond device initialization is required before configuring this feature.

Overview

In this example, dynamic applications are added to the security policy as match criteria.

To accomplish these objectives, perform the following tasks:

  • Configure the security policy match criteria source-address and destination-address with the value any.

  • Configure dynamic-application with [junos:CNN, junos:BBC] so that the policy can permit the applications junos:CNN and junos:BBC.

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

CLI Quick Configuration
Step-by-Step Procedure
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 a unified policy using dynamic applications:

  1. Configure security zones.

  2. Create a security policy with a dynamic application as the match criteria.

  3. Define the policy action.

Results

From configuration mode, confirm your configuration by entering the show security policies 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

Verifying Unified Policy Configuration
Purpose

Verify that the unified policy configuration is correct.

Action

From operational mode, enter the show security policies command to display a summary of all security policies on the device.

From operational mode, enter the show security policies detail command to display a detailed summary of all security policies on the device.

Meaning

The output displays information about all currently active security sessions on the device. Verify the following information:

  • Configured policy name

  • Source and destination addresses

  • Configured applications

    Note:

    The Applications field is autopopulated and its value junos-defaults is added implicitly.

  • Configured dynamic applications

  • Policy action

See Also

Configure Micro-Applications in Unified Policies

Starting in Junos OS Release 19.2R1, you can configure micro-applications in a unified policy. Micro-applications are sub-functions of an application. Micro-applications enable granular control of an application at a sub-function level instead of blocking or allowing the entire application. By default, detection of micro-applications is disabled.

The application identification (AppID) module detects an application at a sub-function level on your network. Security policies leverage the application identity information determined by the AppID module. After a specific application is identified, an action such as permit, deny, reject, or redirect is applied to the traffic according to the policy configured on the device. You must enable detection of micro-applications to use them in a security policy. See Enabling and Disabling Micro-Applications Detection.

Limit the Number of Policy Lookups

To process a policy, the policy lookup must return the final match state for the application. When using a micro-application, application classification does not reach the final match state because the micro-application constantly changes for the session. Because the micro-application changes from one transaction to another, an unlimited number of policy lookups is attempted.

Use the unified-policy max-lookups statement at the [edit security policies] hierarchy level to limit the number of policy lookups.

Configure Micro-Applications

To permit a base-level application and all its dependent micro-applications, you can configure a unified policy by specifying the base-level application as a matching criterion. You do not have to explicitly specify each dependent application as matching criteria for the policy. For example, if you specify the base-level application junos-MODBUS as a matching criterion in a unified policy, then you don't have to configure the micro-applications of the junos-MODBUS application (junos:MODBUS-READ-COILS and junos:MODBUS-WRITE-SINGLE-COIL) as matching criteria for the policy.

If you want to define a unified policy for granular-level control, then you must specify the micro-applications of the base-level application as matching criteria for the policy. You must not define the base-level application as match criteria in the policy. For more granular-level policy configuration, specify junos:MODBUS-READ-COILS as matching criteria in a unified policy. Ensure that the base-level application junos:MODBUS is not defined as as a matching criterion in the same unified policy.

Policy Lookup with Micro-Applications

Detection of micro-applications is disabled by default. To use micro-applications as matching criteria for policy lookup, you must enable detection of micro-applications and then specify them as matching criteria for the unified policy. If you have not enabled detection of micro-applications, the application identification (AppID) module does not detect any micro-application and considers the base-level application as the final matching criterion. For example, consider the base-level application junos-:MODBUS that has two micro-applications junos:MODBUS-READ-COILS and junos:MODBUS-WRITE-SINGLE-COIL:

  • If you have not enabled detection of micro-applications, junos:MODBUS is considered as the final match state for the AppID classification. If you enable micro-applications, then you can configure them in a unified policy as any other pre-defined dynamic application. This micro-application is used for policy lookup.

  • If you have enabled detection of micro-applications, the AppID module considers junos:MODBUS as the pre-match state. When the AppID module detects either junos:MODBUS-READ-COILS or junos:MODBUS-WRITE-SINGLE-COIL, AppID considers this result as the final match state and proceeds with policy lookup using this matching criterion.

See Also

Related Documentation