Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Application Identification Support for Unified Policies

 

Understanding Unified Policies on Security Devices

With the growing popularity of Web applications, and because of the shift from traditional, full client-based applications to the Web, more and more traffic is being transmitted over HTTP. Applications such as instant messaging, peer-to-peer file sharing, Webmail, social networking, and IP voice and video collaboration evade security mechanisms by changing communication ports and protocols. Managing changes in the application behavior requires constant modification to the security rules, and maintenance of the security policy rules poses a major challenge. To handle such changes in application behavior, you need security policies to manage dynamic applications.

As a response to this challenge, starting in Junos OS Release 18.2R1, Juniper Networks SRX Series Services Gateways and vSRX support unified policies, allowing granular control and enforcement of dynamic Layer 7 applications within the security policy. Unified policies are security policies that enable you to use dynamic applications as part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to detect application changes over time.

A unified policy leverages the application identity information determined from the application identification (AppID) module. After a particular 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.

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 at Layer 7 based on its AppID information.

AppID is enabled when you configure a security policy with dynamic applications or when you enable any services such as application policy-based routing (APBR), application tracking (Apptrack), application quality of service (AppQoS), application firewall (AppFW), IDP, or Juniper Sky ATP in the security policy.

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.

Understanding How Unified Policies Use AppID Information

Accurate traffic classification is essential for network security in cloud and data center architectures. Identifying and classifying different types of application traffic (transacted on HTTP) is also a challenge as Web applications include documents, data, images, and audio and video files.

AppID detects the applications on your network regardless of the port, protocol, and encryption (TLS/SSL or SSH) or other evasive tactics. It uses deep packet inspection (DPI) techniques, a signature database, and well-known addresses and ports to identify applications. AppID provides the information such as dynamic application classification, default protocol and port of an application. For any application that is included in the dependent list of another application, AppID provides the information of dependent application.

A unified policy leverages the information from AppID to match the application and take action as specified in the policy. In a unified policy configuration, you can use a predefined dynamic application (from the application identification signature package) or a user-defined custom application as match condition.

Understanding Dependent Dynamic Application Identification

A dependent application list includes applications over which a dynamic application can be identified. For example, the dependent application list for Facebook comprises HTTP2 and SSL.

The default protocol and port of a dynamic application includes the protocol and port defined for that application. If the protocol and port for that application is not defined, then the list of default protocols and ports of its dependent applications is considered.

For example, the Facebook-Access application depends on applications such as HTTP, SSL, and HTTP2. Therefore, the default protocol and ports of these dependent applications are considered for the Facebook-Access application.

Note

The dependent application list and protocol and port mapping of an application might change during runtime whenever a new application signature pack is installed or a custom application configuration changes. AppID provides these details to the security policy.

Dynamic Application Classification States

During the application identification process, DPI processes every packet and classifies it into one of the following states until the application is finally identified:

  • Pre-match—Before an application is identified by the DPI.

  • Transaction final—For dynamic applications, one transaction is complete, but identification of the application is not final. Applications over Layer 7 can keep changing with each transaction because they have dependent applications. For example, Facebook applications have dependent applications such as HTTP, SSL, and so on.

  • Final match—A matched application over Layer 7 is considered as the final match according to the configured maximum number of transactions. That is, the match is considered as final only after the maximum number of transactions are complete.

Before identifying the final application, the policy cannot be matched precisely. A potential policy list is made available, and the traffic is permitted using the potential policy from the list. After the application is identified, the final policy is applied to the session. Policy actions such as permit, deny, reject, or redirect are applied to the traffic as specified in the policy rules.

Application classification is not terminated for applications that are transaction-based, such as Facebook. To terminate the classification for such applications, you can choose to consider the results from multiple transactions as the final classification.

Configuring Transactions Limit For Application Identification

You can configure the maximum number of transactions before concluding the final results for identifying an application using the set services application-identification maximum-transactions transactions-number statement. When you configure the maximum number of transactions, DPI is not terminated until the configured number of transactions are completed.

Example:

You can configure a transaction number from 0 through 25. By default, five transactions are considered.

If you set the transaction count as 0, the transaction does not terminate the DPI. The final match for the application might not be available; and the final security policy is not applied.

Table 1 shows the different states of application identification classification when the maximum transaction is set as five. Note that the values in the table are for example and are not actual values. The exact transaction might vary depending on the traffic pattern.

Table 1: Application Identification Transactions Example

Scenario

Application Identified

Application Identification State

Transactions

First packet of the session

None

Pre-match

0

Intermediate application

SSL

Pre-match

1

Intermediate application identified in decrypted payload

HTTP

Pre-match

2

Intermediate application identified

FACEBOOK-ACCESS

Pre-match

3

Intermediate application identified

FACEBOOK-CHAT

Final Transaction (Transaction =1)

4

Final application identified

FACEBOOK-MAIL

Final Match (Transaction = 2)

4

Note

In unified policies, configuring dynamic applications that can be identified based on Layer 3 or Layer 4 information (except ICMP-based applications) is not supported. Instead, you can use the junos-defaults group that contains predefined values for Layer 3 and Layer 4 based applications.

High Availability Support for Application Identification for Unified Policies

When an application is identified, its classification information is saved in the application system cache (ASC).

When your security device (example: SRX Series device) is operating in chassis cluster mode, the information saved in the ASC is synchronized between the primary node and the secondary node.

In case of dynamic application classification, per session application classification information from the DPI is synchronized with the secondary node when the application classification is final.

During a failover, the application classification information on the secondary node is in either of the following states:

  • Application not identified

  • Final application identified

After a failover, the application classification information that is available in the new primary node is considered as the final match. The same information is synchronized with the new secondary node as the classification does not proceed further after a failover. The example in Table 2 Table 2 shows application classification status in a chassis cluster setup.

Table 2: Application Classification Status in a Chassis Cluster Setup

Application Identification Status

Chassis Cluster Node

Before Failover

After Failover

Details

Final application is identified.

Identified application: SSL:Facebook

Primary node

Identified application: SSL:Facebook

Identified application: SSL:Facebook

No change after failover because complete application classification is synchronized to the secondary node.

Secondary node

Identified application: SSL:Facebook

Identified application: SSL:Facebook

Final application is not identified. (Partial application is identified.)

Identified application: SSL

Primary node

Identified application: SSL

Identified application: APP-INVALID

Application identification does not proceed further after a failover.

Secondary node

Identified application: not available

Identified application: APP-INVALID

Final application is not identified. (Partial application is identified)

Primary node

Identified application: not available

Identified application: APP-INVALID

In this case, a failover occurred after the first packet inspection, and no application is identified.

Application identification does not proceed further after a failover.

Secondary node

Identified application: not available

Identified application: APP-INVALID

Enabling or Disabling Application System Cache for Application Services

Starting in Junos OS Release 18.2R1, the default behavior of the ASC is changed as follows:

  • Security services including security policies, application firewall (AppFW), application tracking (AppTrack), application quality of service (AppQoS), Juniper Sky ATP, IDP, and UTM do not use the ASC by default.

  • Miscellaneous services including advanced policy-based routing (APBR) use the ASC for application identification by default.

Note

The change in the default behavior of the ASC affects the legacy AppFW functionality. With the ASC disabled by default for the security services starting in Junos OS Release 18.2 onward, AppFW will not use the entries present in the ASC.

You can revert to the ASC behavior as in Junos OS releases before Release 18.2 by using the set services application-identification application-system-cache security-services command.

Caution

The security device might become susceptible to application evasion techniques if the ASC is enabled for security services. We recommend that you enable the ASC only when the performance of the device in its default configuration (disabled for security services) is not sufficient for your specific use case.

Use the following commands to enable or disable the ASC:

  • Enable the ASC for security services:

  • Disable the ASC for miscellaneous services:

  • Disable the enabled ASC for security services:

  • Enable the disabled ASC for miscellaneous services:

You can use the show services application-identification application-system-cache command to verify the status of the ASC.

The following sample output provides the status of the ASC:

user@host>show services application-identification application-system-cache

In releases before Junos OS Release 18.2R1, application caching was enabled by default. You can manually disable it by using the set services application-identification no-application-system-cache command.

Application Identification Support for Micro-Applications

Starting in Junos OS Release 19.2R1 onwards, you can manage the applications at a sub-function level with application identification feature. In this document, we refer application sub-functions as micro-applications.

Micro-applications are part of application signature package. You must enable micro-application detection in application identification and then use them as matching criteria in security policy.

AppID detects the applications at sub-function level on your network and security policy leverages the application identity information determined from the application identification (AppID) module. After a particular 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.

Micro-applications concept is similar to transaction-based applications, where the nested application over a base application continuously change for the same session.

Example:

Consider a dynamic application MODBUS. READ and WRITE are sub functions or operations of MODBUS application. For these sub-functions, we must define micro-applications such as MODBUS-READ and MODBUS-WRITE. Application classification path can keep changing between MODBUS:MODBUS-READ and MODBUS:MODBUS-WRITE. In this case, MODBUS is the base application and MODBUS-READ and MODBUS-WRITE are nested applications, that is, micro-applications.

You can configure the micro-applications at the same hierarchy as predefined dynamic application in a security policy and take the action based on the policy rules.

By configuring these micro-applications in security policies, you can allow or deny MODBUS sub-functions rather than blocking or allowing the entire MODBUS application.

Micro-Application Classification

Application classification for micro-applications does not reach to the final match because, the micro-application keep changing for the session. A matched application is considered as the final match only after the maximum number of transactions are complete.

AppID has the maximum transaction limit as 25, however each service module has it’s own limit based on it’s own requirements. If service specific limit is reached before the maximum transaction limit (25), then the service module marks it’s policy as final. However, AppID continues application classification and offloads the session on reaching the limit of 25.

You can use the set services application-identification max-transactions command to configure the transaction limit.

Dependent Application List and Default Protocols and Ports

A dependent application list includes applications over which a dynamic application can be identified. The default protocol and port of a dynamic application includes the protocol and port defined for that application.

Dependent application list and default protocols and ports are used by unified policy for enforcing the security policy. Dependent application list and default protocols and ports of micro application is same as that of base application.

Example: Dependent application list and default ports of micro-application MODBUS-READ is same as dependent application list and default ports of MODBUS.

Policy Enforcement for Micro-Applications

A security policies enforce rules for transit traffic, in terms of what traffic can pass through the device, and the actions that need to take place on traffic as it passes through the device. If you have configured a security policy with micro-application as match criteria, then the policy module requires micro-application identification information from AppID.

Application classification with micro-applications does not reach the final match because, the micro-application keep changing for the session. However, final match for the application is required for policy lookup and processing of the policy. You can use the [edit security policies unified-policy-max-lookups] command to limit the number of policy lookups.

. After the application is identified, the final policy is applied to the session. Policy actions such as permit, deny, reject, or redirect are applied to the traffic as specified in the policy rules.

Installing Micro-Applications

Micro applications are part of application signature package. When you download application signature package and install it, micro applications are also installed and are available for configuring in the security policies. You can view the details of the micro applications using the show services application-identification status command.

Note

If you have configured micro-applications in a security policy starting in Junos OS Release 19.2, it is not possible to downgrade to the previous version of Junos OS release. To downgrade to the previous version of Junos OS releases, you must remove the micro applications configured in your security policies.

Enabling and Disabling Micro-Applications Detection

You can enable or disable micro-application detection. By default, detection of micro-applications are disabled. You must enable micro-applications to use them in your security policy.

You can enable or disable micro-applications using the following commands:

  • Enable micro-applications detection (from configuration mode).

  • Disable a specific micro-application (from operational mode).

    Example:

Example: Configuring Micro-Applications

This example shows how to configure micro-applications in a security policy to enforce the policy at sub-function level.

Requirements

This example uses the following hardware and software components:

  • SRX Series device with Junos OS Release 19.2R1 or later. This configuration example is tested on Junos OS Release 19.2R1.

  • Valid application identification feature license installed on an SRX Series device.

Before you begin, install an entire signature database from an IDP or an application identification security package. See Downloading and Installing the Junos OS Application Signature Package Manually or Downloading and Installing the Junos OS Application Signature Package As Part of the IDP Security Package.

Overview

In this example, you create a security policy with micro-applications MODBUS-READ-COILS and MODBUS-WRITE-SINGLE-COIL, MODBUS-READ-COILS, MODBUS-WRITE-MULTIPLE-COILS. Application traffic matching these micro-applications is permitted.

Configuration

Configuring Security Policy with Micro-Applications

CLI Quick Configuration

To quickly configure this section of the 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.

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.

To configure a custom application group for application identification:

  1. Enable micro-applications detection.
  2. Define a security policy with other policy matching criteria.
  3. Define application and micro-application as matching criteria.
  4. 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.

Configuring Application Quality-of-Service with Micro-Applications

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.

To configure a custom application group for application identification:

  1. Define AppQoS configuration parameters with micro-application junos:MODBUS-READ-COILS.
  2. Create a security policy.
  3. Define the policy action.

Results

From configuration mode, confirm your configuration by entering the how class-of-service command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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 Micro-Applications Status

Purpose

Verify that micro-applications are enabled.

Action

Use the show services application-identification status command to get the details of the micro-applications.

Verifying Micro-Applications Statistics

Purpose

Verify that micro-application are applied.

Action

Use the show services application-identification statistics applications command to get the details of the micro-applications.

Sample Output

Related Documentation

Release History Table
Release
Description
Starting in Junos OS Release 18.2R1, the default behavior of the ASC is changed
In releases before Junos OS Release 18.2R1, application caching was enabled by default. You can manually disable it by using the set services application-identification no-application-system-cache command.