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 Firewalls and vSRX Virtual Firewall 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 ATP Cloud 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
- Dynamic Application Classification States
- Configuring Transactions Limit For Application Identification
- High Availability Support for Application Identification for Unified Policies
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.
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:
user@host# set services application-identification maximum-transactions 5
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.
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 |
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 Firewall) 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.
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:
- Before Junos OS Release 18.2R1—ASC is enabled by default for all services including security services.
-
From Junos OS Release 18.2R1 onwards—ASC is enabled by default; note the difference in security services lookup:
-
ASC lookup for security services is not enabled by default. That is—security services including security policies, application firewall (AppFW), application tracking (AppTrack), application quality of service (AppQoS), Juniper ATP Cloud, IDP, and Content Security do not use the ASC by default.
-
ASC lookup for miscellaneous services is enabled by default. That is—miscellaneous services including advanced policy-based routing (APBR) use the ASC for application identification by default.
-
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.
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:
user@host#set services application-identification application-system-cache security-servicesDisable the ASC for miscellaneous services:
user@host#set services application-identification application-system-cache no-miscellaneous-servicesDisable the enabled ASC for security services:
user@host#delete services application-identification application-system-cache security-servicesEnable the disabled ASC for miscellaneous services:
user@host#delete services application-identification application-system-cache no-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
Application System Cache Configurations:
application-cache: on
Cache lookup for security-services: off
Cache lookup for miscellaneous-services: on
cache-entry-timeout: 3600 seconds
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.
user@host# set services application-identification no-application-system-cache
See Also
Tunnelling Applications Support
Starting in Junos OS Release 20.4R1, we’ve enhanced unified policy lookup on security device to manage tunneling applications. You can now block a specific tunneling application by using the unified policy.
When you want to block certain tunneling applications such as QUIC or SOCK, you can configure these tunneling applications to unified policy with action deny or reject.
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
- Dependent Application List and Default Protocols and Ports
- Policy Enforcement for Micro-Applications
- Installing Micro-Applications
- Managing DNS-over-HTTP and DNS-over-TLS Application Traffic
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.
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.
Managing DNS-over-HTTP and DNS-over-TLS Application Traffic
In Junos OS Release 20.4R1, we introduce a new micro-application, DNS-ENCRYPTED, to enhance the application signature package. By configuring this micro-application in a security policy, you can have granular control for DNS-over-HTTP and DNS-over-TLS application traffic.
The DNS-ENCRYPTED application is enabled by default. You can
disable it using the request services application-identification
application disable DNS-ENCRYPTED command.
You can view the details of the micro-applications using the show services application-identification application command.
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).
user@host# set services application-identification micro-apps
Disable a specific micro-application (from operational mode).
user@host> request services application-identification application disable application-name
Example:
user@host>request services application-identification application disable junos:MODBUS
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 Firewall 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 Firewall.
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
- Configuring Application Quality-of-Service with Micro-Applications
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.
set services application-identification micro-apps set security policies from-zone untrust to-zone trust policy P1 match source-address any set security policies from-zone untrust to-zone trust policy P1 match destination-address any set security policies from-zone untrust to-zone trust policy P1 match application any set security policies from-zone untrust to-zone trust policy P1 match dynamic-application junos:MODBUS-READ-COILS set security policies from-zone untrust to-zone trust policy P1 match dynamic-application junos:MODBUS-WRITE-SINGLE-COIL set security policies from-zone untrust to-zone trust policy P1 match dynamic-application junos:MODBUS-WRITE-MULTIPLE-COILS set security policies from-zone untrust to-zone trust policy P1 then permit
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy.
To configure a custom application group for application identification:
Enable micro-applications detection.
[edit] user@host# set services application-identification micro-apps
Define a security policy with other policy matching criteria.
[edit] user@host# set security policies from-zone untrust to-zone trust policy P1 match source-address any user@host# set security policies from-zone untrust to-zone trust policy P1 match destination-address any user@host# set security policies from-zone untrust to-zone trust policy P1 match application any
Define application and micro-application as matching criteria.
[edit] user@host# set security policies from-zone untrust to-zone trust policy P1 match dynamic-application junos:MODBUS-READ-COILS user@host# set security policies from-zone untrust to-zone trust policy P1 match dynamic-application junos:MODBUS-WRITE-SINGLE-COIL user@host# set security policies from-zone untrust to-zone trust policy P1 match dynamic-application junos:MODBUS-WRITE-MULTIPLE-COILS
Define the policy action.
[edit] user@host# set security policies from-zone untrust to-zone trust policy P1 then permit
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.
[edit]
user@host# show security policies from-zone untrust to-zone trust
from-zone untrust to-zone trust {
policy P1 {
match {
source-address any;
destination-address any;
application any;
dynamic-application [ junos:MODBUS-READ-COILS junos:MODBUS-WRITE-SINGLE-COIL junos:MODBUS-WRITE-MULTIPLE-COILS ];
}
then {
permit;
}
}
}
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.
To configure a custom application group for application identification:
Define AppQoS configuration parameters with micro-application junos:MODBUS-READ-COILS.
[edit] user@host# set class-of-service application-traffic-control rate-limiters RL1 bandwidth-limit 1000 user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 match application junos:MODBUS-READ-COILS user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then dscp-code-point 111110 user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then loss-priority high user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then rate-limit client-to-server RL1 user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then log
Create a security policy.
[edit security] user@host# set security policies from-zone untrust to-zone trust policy 1 match source-address any user@host# set security policies from-zone untrust to-zone trust policy 1 match destination-address any user@host# set security policies from-zone untrust to-zone trust policy 1 match application any
Define the policy action.
[edit security] user@host# set security policies from-zone untrust to-zone trust policy 1 then permit application-services application-traffic-control rule-set RS1
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.
[edit]
user@host# show class-of-service
application-traffic-control {
rate-limiters RL1 {
bandwidth-limit 1000;
}
rule-sets RS1 {
rule 1 {
match {
application junos:MODBUS-READ-COILS;
}
then {
dscp-code-point 111110;
loss-priority high;
rate-limit {
client-to-server RL1;
}
log;
}
}
}
}
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.
[edit]
user@host# show security policies from-zone untrust to-zone trust
from-zone untrust to-zone trust {
policy 1 {
match {
source-address any;
destination-address any;
application any;
dynamic-application [ junos:MODBUS-READ-COILS];
}
then {
permit {
application-services {
application-traffic-control {
rule-set RS1;
}
}
}
}
}
}
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 micro-applications version and use show services application-identification application micro-applications command to get the details of the micro-applications.
Application Identification Status Enabled Sessions under app detection 0 Max TCP session packet memory 0 Force packet plugin Disabled Force stream plugin Disabled Statistics collection interval 1440 (in minutes) Application System Cache Status Enabled Cache lookup security-services Disabled Cache lookup miscellaneous-services Disabled Max Number of entries in cache 0 Cache timeout 3600 (in seconds) Protocol Bundle Download Server https://signatures.juniper.net/cgi-bin/index.cgi AutoUpdate Disabled Proxy Details Proxy Profile Not Configured Slot 1: Application package version 3172 Status Active PB Version 1.380.0-64.005 (build date May 13 2019) Engine version 5.3.0-56 (build date May 13 2019) Micro-App Version 1.0.0-0 Sessions 0
Sample Output
show services application-identification application micro-applications
user@host> show services application-identification application micro-applications Micro Applications junos:BACNET-GET-EVENT-INFORMATION junos:BACNET-SUBSCRIBE-COV-PROPERTY junos:BACNET-LIFE-SAFETY-OPERATION junos:BACNET-READ-RANGE junos:BACNET-REQUEST-KEY junos:BACNET-AUTHENTICATE junos:BACNET-VT-DATA junos:BACNET-VT-CLOSE junos:BACNET-VT-OPEN junos:BACNET-REINITIALIZE-DEVICE junos:BACNET-CONFIRMED-TEXT-MESSAGE junos:BACNET-CONFIRMED-PRIVATE-XFER junos:BACNET-DEVICE-COMM-CONTROL junos:BACNET-WRITE-PROP-MULTIPLE junos:BACNET-WRITE-PROPERTY junos:BACNET-READ-PROP-MULTIPLE junos:BACNET-READ-PROP-CONDITIONAL junos:BACNET-READ-PROPERTY junos:BACNET-DELETE-OBJECT junos:BACNET-CREATE-OBJECT junos:BACNET-REMOVE-LIST-ELEMENT junos:BACNET-ADD-LIST-ELEMENT junos:BACNET-ATOMIC-WRITE-FILE junos:BACNET-ATOMIC-READ-FILE junos:BACNET-SUBSCRIBE-COV junos:SIEMENS-S7-SETUP-COMM junos:SIEMENS-S7-UPLOAD-START ......
See show services application-identification application micro-applications for more details.
Verifying Micro-Applications Statistics
Purpose
Verify that micro-application are applied.
Action
Use the following commands to get the details of the micro-applications.
Sample Output
command-name
user@host> show services application-identification statistics applications
Last Reset: 2018-12-16 01:45:47 PST
Application Sessions Bytes Encrypted
MODBUS-READ-COILS 1 1026 No
MODBUS-WRITE-SINGLE-COIL 1 1254 No
user@host> show services application-identification statistics applications details (Junos OS Release 20.3)
Logical System: root-logical-system
Last Reset: 2020-05-08 08:55:31 PDT
Application Enc DPI final-match Pre-match Limits
final-match
NTP No 1 0 0
SYSLOG No 5 0 0
set services application-identification
no-application-system-cache command.