Security Application Identification
Security Application Identification
Modified: 2018-07-17
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,
transfer, or otherwise revise this publication without notice.
®
Junos OS Application Security Feature Guide for Security Devices
Copyright © 2018 Juniper Networks, Inc. All rights reserved.
The information in this document is current as of the date on the title page.
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the
year 2038. However, the NTP application is known to have some difficulty in the year 2036.
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
https://www.juniper.net/support/eula/. By downloading, installing or using such software, you agree to the terms and conditions of that
EULA.
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Example: Configuring Advanced Policy-Based Routing Policies . . . . . . . . . . 143
Application Quality of Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Application Quality of Experience (AppQoE) . . . . . . . . . . . . . . . . . . . . . . . . 148
Introduction to Application Quality of Experience . . . . . . . . . . . . . . . . . 148
Benefits of Application Quality of Experience . . . . . . . . . . . . . . . . . . . . 149
Supported Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Understanding Application Quality of Experience Terminology . . . . . . . 150
How Application Quality of Experience Works? . . . . . . . . . . . . . . . . . . . . 151
How Application Quality of Experience Measures Application
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Switching Application Traffic to An Alternate Path . . . . . . . . . . . . . . . . . 154
Example: Application Quality of Experience (AppQoE) . . . . . . . . . . . . . . . . 155
Chapter 4 SSL Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
SSL Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
SSL Proxy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Benefits of SSL Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Supported Key Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Supported Ciphers in Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Supported SSL Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Server Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Trusted CA List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Root CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Client Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Whitelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Dynamic Resolution of Domain Names . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Session Resumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Session Renegotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
SSL Proxy Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Leveraging Dynamic Application Identification . . . . . . . . . . . . . . . . . . . . 181
Logical Systems Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Configuring SSL Forward Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
SSL Proxy Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Configuring a Root CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Configuring a CA Profile Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Configuring a Trusted CA Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Importing a Root CA Certificate into a Browser . . . . . . . . . . . . . . . . . . . 188
Applying an SSL Proxy Profile to a Security Policy . . . . . . . . . . . . . . . . . 189
Creating a Whitelist of Exempted Destinations . . . . . . . . . . . . . . . . . . . 190
Configuring SSL Proxy Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Configuring Ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Exporting Certificates to a Specified Location . . . . . . . . . . . . . . . . . . . . 193
application-traffic-control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
application-traffic-control (Application Services) . . . . . . . . . . . . . . . . . . . . . . . . 264
authorization (icap-redirect profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
block-message (Application Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
context (Application Identification) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
crl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
custom-ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
default-rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
destination-path-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
direction (Application Identification) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
disable (Application Tracking) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
download (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
dynamic-application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
dynamic-application-group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
enable-flow-tracing (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
enable-performance-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
enable-reverse-reroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
enable-session-cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
fallback-option (ICAP Redirect Service) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
file (System Logging) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
flag (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
format (Security Log) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
forwarding-classes (CoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
global-config (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
http (icap-redirect profile) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
icap-redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
icmp-mapping (Application Identification) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
ip-protocol-mapping (Application Identification) . . . . . . . . . . . . . . . . . . . . . . . . 297
initiation (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
level (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
log (Security) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
log (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
maximum-transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
no-application-identification (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
no-application-system-cache (Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
ngfw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
over (Application Identification) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
overlay-path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
passive-probe-params . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
policy (advanced-policy-based-routing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
policy (Security Policies) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
port-range (Application Identification) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
preferred-ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
profile (Application Firewall) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
profile (icap-redirect) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
profile (Rule Sets) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
profile (SSL Proxy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
profile (SSL Initiation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
If the information in the latest release notes differs from the information in the
documentation, follow the product Release Notes.
Juniper Networks Books publishes books by Juniper Networks engineers and subject
matter experts. These books go beyond the technical documentation to explore the
nuances of network architecture, deployment, and administration. The current list can
be viewed at https://www.juniper.net/books.
If you want to use the examples in this manual, you can use the load merge or the load
merge relative command. These commands cause the software to merge the incoming
configuration into the current candidate configuration. The example does not become
active until you commit the candidate configuration.
If the example configuration contains the top level of the hierarchy (or multiple
hierarchies), the example is a full example. In this case, use the load merge command.
If the example configuration does not start at the top level of the hierarchy, the example
is a snippet. In this case, use the load merge relative command. These procedures are
described in the following sections.
1. From the HTML or PDF version of the manual, copy a configuration example into a
text file, save the file with a name, and copy the file to a directory on your routing
platform.
For example, copy the following configuration to a file and name the file ex-script.conf.
Copy the ex-script.conf file to the /var/tmp directory on your routing platform.
system {
scripts {
commit {
file ex-script.xsl;
}
}
}
interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
}
2. Merge the contents of the file into your routing platform configuration by issuing the
load merge configuration mode command:
[edit]
user@host# load merge /var/tmp/ex-script.conf
load complete
Merging a Snippet
To merge a snippet, follow these steps:
1. From the HTML or PDF version of the manual, copy a configuration snippet into a text
file, save the file with a name, and copy the file to a directory on your routing platform.
For example, copy the following snippet to a file and name the file
ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory
on your routing platform.
commit {
file ex-script-snippet.xsl; }
2. Move to the hierarchy level that is relevant for this snippet by issuing the following
configuration mode command:
[edit]
3. Merge the contents of the file into your routing platform configuration by issuing the
load merge relative configuration mode command:
For more information about the load command, see CLI Explorer.
Documentation Conventions
Caution Indicates a situation that might result in loss of data or hardware damage.
Laser warning Alerts you to the risk of personal injury from a laser.
Table 2 on page xvii defines the text and syntax conventions used in this guide.
Bold text like this Represents text that you type. To enter configuration mode, type the
configure command:
user@host> configure
Fixed-width text like this Represents output that appears on the user@host> show chassis alarms
terminal screen.
No alarms currently active
Italic text like this • Introduces or emphasizes important • A policy term is a named structure
new terms. that defines match conditions and
• Identifies guide names. actions.
• Junos OS CLI User Guide
• Identifies RFC and Internet draft titles.
• RFC 1997, BGP Communities Attribute
Italic text like this Represents variables (options for which Configure the machine’s domain name:
you substitute a value) in commands or
configuration statements. [edit]
root@# set system domain-name
domain-name
Text like this Represents names of configuration • To configure a stub area, include the
statements, commands, files, and stub statement at the [edit protocols
directories; configuration hierarchy levels; ospf area area-id] hierarchy level.
or labels on routing platform • The console port is labeled CONSOLE.
components.
< > (angle brackets) Encloses optional keywords or variables. stub <default-metric metric>;
# (pound sign) Indicates a comment specified on the rsvp { # Required for dynamic MPLS only
same line as the configuration statement
to which it applies.
[ ] (square brackets) Encloses a variable for which you can community name members [
substitute one or more values. community-ids ]
GUI Conventions
Bold text like this Represents graphical user interface (GUI) • In the Logical Interfaces box, select
items you click or select. All Interfaces.
• To cancel the configuration, click
Cancel.
> (bold right angle bracket) Separates levels in a hierarchy of menu In the configuration editor hierarchy,
selections. select Protocols>Ospf.
Documentation Feedback
• Online feedback rating system—On any page of the Juniper Networks TechLibrary site
at https://www.juniper.net/documentation/index.html, simply click the stars to rate the
content, and use the pop-up form to provide us with information about your experience.
Alternately, you can use the online feedback form at
https://www.juniper.net/documentation/feedback/.
Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or Partner Support Service
support contract, or are covered under warranty, and need post-sales technical support,
you can access our tools and resources online or open a case with JTAC.
• JTAC hours of operation—The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.
• Find solutions and answer questions using our Knowledge Base: https://kb.juniper.net/
To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool: https://entitlementsearch.juniper.net/entitlementsearch/
Overview
An individual can connect to the network using multiple devices simultaneously, making
it impractical to identify a user, an application, or a device by a group of statically allocated
IP addresses and port numbers.
AppSecure works with additional content security through integrated unified threat
management (UTM), intrusion prevention systems (IPS), and Juniper Networks Sky
Advanced Threat Prevention (Sky ATP) on the SRX Series for deeper protection against
malware, spam, phishing, and application exploits.
• Enables you to control network traffic by setting and enforcing security policies based
on accurate application information.
Application Identification
Application Identification
Application Identification enables you to see the applications on your network and learn
how they work, their behavioral characteristics, and their relative risk. Using several
different identification mechanisms, App ID detects the applications on your network
regardless of the port, protocol, and encryption (TLS/SSL or SSH) or other evasive tactics
used. For more information, see the following topics:
Today, wireless networking and mobile devices require a different strategy. The way in
which devices connect to the network changes rapidly. An individual can connect to the
The detection mechanism has its own data feed and constructs to identify applications.
• Support for all versions of protocols and application decoders and dynamic updates
of decoders
• Support for encrypted and compressed traffic and most complex tunneling protocols
• Ability to identify all protocols from Layer 3 to Layer 7 and above Layer 7
Figure 1 on page 25 shows the sequence in which mapping techniques are applied and
how the application is determined.
In application identification, every packet in the flow passes through the application
identification engine for processing until the application is identified. Application bindings
are saved in the application system cache (ASC) to expedite future identification process.
The predefined signature package provides identification criteria for known application
signatures and is updated periodically.
Whenever new applications are added, the protocol bundle is updated and generated
for all relevant platforms. It is packaged together with other application signature files.
This package will be available for download through the security download website.
A subscription service allows you to regularly download the latest signatures for
up-to-date coverage without having to create entries for your own use.
By default, the ASC saves the mapping information for 3600 seconds. However, you can
configure the cache timeout value by using the CLI.
Refreshing all the ASC entries might have an impact on the performance of service. To
eliminate the service degradation, entries in the ASC are only refreshed when Transmission
Control Protocol (TCP) or User Datagram Protocol (UDP) traffic triggers a cache lookup.
Without a cache lookup, the entries in the ASC remain unchanged. For example, if you
have configured the cache timeout value 4800 seconds and there are no new TCP or
UDP session for 6000 seconds, then the ASC entries are not refreshed even if the
configured timeout value (4800 seconds) is already over.
NOTE: When you delete or disable a custom application signature, and the
configuration commit fails, the application system cache (ASC) entry is not
cleared completely; instead, a base application in the path of custom
application will be reported in ASC.
• Security services such as security policies, AppFW, Juniper Sky ATP, IDP, and UTM do
not use the ASC by default.
• Miscellaneous services such as APBR and AppTrack 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.
NOTE: The application system cache will display the cache for application
identification applications.
Action From CLI operation mode, enter the show services application-identification
application-system-cache command.
Sample Output
Meaning The output shows a summary of the ASC statistics information. Verify the following
information:
With this feature, the administrator can clear the statistics and configure the interval
values while maintaining bytes and session count statistics. Because the statistics count
occurs at session close event time, the byte and session counts are not updated until the
session closes. SRX Series devices support a history of eight intervals that an administrator
can use to display application session and byte counts.
If application grouping is supported in your configuration of Junos OS, then the Onbox
Application Identification Statistic feature supports onbox per-group matching statistics.
The statistics are maintained for predefined groups only.
Reinstalling an application signature package will not clear the application statistics. If
the application is disabled, there will not be any traffic for that application, but the
application is still maintained in the statistics. It does not matter if you are reinstalling a
predefined application, because applications are tracked according to application type.
For predefined group statistics, reinstalling a security package will not clear the statistics.
However, any changes to group memberships are updated. For example, junos:web might
have 50 applications in the current release and 60 applications following an upgrade.
Applications that are deleted and application groups that are renamed are handled in
the same way as applications that are added.
The Application Identification module maintains a 64-bit session counters for each
application on each Services Processing Unit (SPU). The counter increments when a
session is identified as a particular application. Another set of 64-bit counters aggregates
the total bytes per application on the SPU. Counters for unspecified applications are also
maintained. Statistics from multiple SPUs for both sessions and bytes are aggregated
on the Routing Engine and presented to the users.
Individual SPUs have interval timers to roll over statistics per interval time. To configure
the interval for statistics collection, use the set services application-identification statistics
interval time command. Whenever the Routing Engine queries for the required interval,
the corresponding statistics are fetched from each SPU, aggregated in the Routing Engine
and presented to the user.
Use the clear services application-identification statistics to clear all application statistics
such as cumulative, interval, applications, and application groups.
Use the clear services application-identification counter command to reset the counters
manually. Counters reset automatically when a device is upgraded or rebooted, when
flowd restarts, or when there is a change in the interval timer.
Starting from Junos OS Release 15.1X49-D120, on all SRX Series devices, the default time
interval for application identification statistics collection time is changed from 1 minute
to 1440 minutes.
Internet Message Access Protocol (IMAP) is an Internet standard protocol used by e-mail
clients for e-mail storage and retrieval services. IMAP cache is used for protocol parsing
and context generation. It stores parsing related information of an email.
Starting from Junos OS Release 15.1X49-D120, you can configure to limit the maximum
number of entries in the IMAP cache and specify the timeout value for the entries in the
cache.
You can use the following commands to modify the settings for IMAP cache:
Example:
[edit]
user@host# set services application-identification imap-cache imap-cache-size 50000
In this example, the IMAP cache size is configured to store 50,000 entries.
[edit]
user@host# set services application-identification imap-cache-timeout 600
In this example, time out period is configured to 600 seconds during which a cache entry
remains in IMAP cache.
[edit]
user@host# set services application-identification enable-performance-mode
2. (Optional) You can set the maximum packet threshold for DPI performance mode,
including both client-to-server and server-to-client directions.
You can set the packet inspection limit from 1 through 100.
[edit]
user@host# set services application-identification enable-performance-mode
max-packet-threshold value
[edit]
user@host# commit
Application Identification
Status Enabled
Sessions under app detection 0
Engine Version 4.18.2-24.006 (build date Jul 30 2014)
Max TCP session packet memory 30000
Force packet plugin Disabled
Force stream plugin Disabled
DPI Performance mode: Enabled
Statistics collection interval 1 (in minutes)
Protocol Bundle
Download Server https://signatures.juniper.net/cgi-bin/index.cgi
AutoUpdate Disabled
Slot 1:
Application package version 2399
Status Active
Version 1.40.0-26.006 (build date May 1 2014)
Sessions 0
Slot 2
Application package version 0
Status Free
Version
Sessions 0
The DPI Performance mode field displays whether the DPI performance mode is enabled
or not. This field is displayed in the CLI command output only if the performance mode
is enabled.
If you want to set DPI to default accuracy mode and disable the performance mode,
delete the configuration statement that specifies enabling of the performance mode:
[edit]
user@host# delete services application-identification enable-performance-mode
[edit]
user@host# commit
15.1X49-D120 Starting from Junos OS Release 15.1X49-D120, you can configure to limit
the maximum number of entries in the IMAP cache and specify the
timeout value for the entries in the cache.
You need to download and install the application signature package before configuring
application services. The application signature package is included in the IDP installation
directly and does not need to be downloaded separately.
• If you have IDP enabled and plan to use application identification, you can continue to
run the IDP signature database download. To download the IDP signature database,
run the following command: request security idp security-package download. The
application package download can be performed manually or automatically. See
“Downloading and Installing the Junos OS Application Signature Package As Part of
the IDP Security Package” on page 42.
• If you do not have IDP enabled and plan to use application identification, you can run
the following commands: request services application-identification download and
request services application-identification install. These commands will download the
application signature database and install it on the device.
You can perform the download manually or automatically. When you download the
extracted package manually, you can change the download URL.
After downloading and installing the application signature package, use CLI commands
to download and install database updates, and view summary and detailed application
information.
See “Downloading and Installing the Junos OS Application Signature Package Manually”
on page 39 or “Example: Scheduling the Application Signature Package Updates” on
page 45.
Example:
NOTE: On all SRX Series devices, J-Web pages for AppSecure Services are
preliminary. We recommend using the CLI for configuration of AppSecure
features.
SRX Series devices installed with Junos OS builds with legacy application identification
include legacy application identification security packages. When you upgrade these
devices with Junos OS Release 12.1X47-D10, the next-generation application identification
security package is installed along with the default protocol bundle. The device is
automatically upgraded to next-generation application identification.
NOTE:
• The next-generation application identification security package introduces
incremental updates to the legacy application identification package. You
are not required to remove or uninstall any existing applications.
• When you upgrade Junos OS, you can include the validate or no-validate
options with the request system software add command. Because the
existing features, which are not part of next-generation application
identification, are deprecated, incompatibility issues are not seen.
Licensing is usually ordered when the device is purchased, and this information is bound
to the chassis serial number. These instructions assume that you already have the license.
If you did not order the license during the purchase of the device, contact your account
team or Juniper customer care for assistance. For more information, refer to the Knowledge
Base article KB9731 at https://kb.juniper.net/InfoCenter/index?page=home.
You can install the license on the SRX Series device using either the automatic method
or manual method as follows:
To install or update your license automatically, your device must be connected to the
Internet .
Use the show system license command command to view license usage, as shown in
the following example:
License usage:
Licenses Licenses Licenses Expiry
Feature name used installed needed
logical-system 4 1 3 permanent
• Requirements on page 39
• Overview on page 40
• Configuration on page 40
• Verification on page 41
Requirements
• Ensure that your SRX Series device has a connection to the Internet to download
security package updates.
NOTE: DNS must be set up because you need to resolve the name of the
update server.
• Ensure that you have installed the application identification feature license. See
“Installing and Verifying Licenses for an Application Signature Package” on page 37.
Overview
Configuration
CLI Quick CLI quick configuration is not available for this example because manual intervention is
Configuration required during the configuration.
Download retrieves the application package from the Juniper Networks security
website https://signatures.juniper.net/cgi-bin/index.cgi.
You can also download a specific version of the application package or download
the application package from the specific location by using the following options:
• To change the download URL for the application package from configuration
mode:
[edit]
user@host# set services application-identification download url URL or File Path
NOTE: If you change the download URL and you want to keep that
change, make sure you commit the configuration.
NOTE: You can also use the system log to view the result of the
download.
The command output displays information about the downloaded and installed
versions of the application package and protocol bundle.
Verification
Action From operational mode, enter the show services application-identification status
command.
pic: 1/0
Application Identification
Status Enabled
Sessions under app detection 0
Engine Version 4.18.1-20 (build date Jan 25 2014)
Max TCP session packet memory 30000
Max C2S bytes 1024
Max S2C bytes 0
Force packet plugin Disabled
Force stream plugin Disabled
Statistics collection interval 1 (in minutes)
Protocol Bundle
Download Server https://services.netscreen.com/cgi-bin/index.cgi
AutoUpdate Enabled
Slot 1:
Status Active
Version 1.30.4-22.005 (build date Jan 17 2014)
Sessions 0
Slot 2
Status Free
Meaning The Status: Enabled field shows that application identification is enabled on the device.
Downloading and Installing the Junos OS Application Signature Package As Part of the IDP
Security Package
You can download and install application signatures through intrusion detection and
prevention (IDP) security packages.
This example shows how to enhance security by downloading and installing the IDP
signatures and application signature package. In this case, both IDP signature pack and
application signature pack are downloaded with a single command.
• Requirements on page 43
• Overview on page 43
• Configuration on page 43
• Verification on page 45
Requirements
• Ensure that your SRX Series device has a connection to the Internet to download
security package updates.
NOTE: DNS must be set up because you need to resolve the name of the
update server.
• Ensure that you have installed the application identification feature license. See
“Installing and Verifying Licenses for an Application Signature Package” on page 37.
Overview
In this example, you download and install the signature database from the Juniper
Networks website.
Configuration
CLI Quick CLI quick configuration is not available for this example because manual intervention is
Configuration required during the configuration.
[edit]
user@host# run request security idp security-package download
Will be processed in async mode. Check the status using the status checking
CLI
[edit]
user@host# run request security idp security-package download status
Done;Successfully downloaded
from(https://services.netscreen.com/cgi-bin/index.cgi).
Version info:2230(Mon Feb 4 19:40:13 2013 GMT-8, Detector=12.6.160121210)
[edit]
user@host# run request security idp security-package install
Will be processed in async mode. Check the status using the status checking
CLI
NOTE: Installing the attack database might take some time depending
on the security database size.
4. Check the attack database install status. The command output displays information
about the downloaded and installed versions of the attack database.
[edit]
user@host# run request security idp security-package install status
[edit]
user@host# run show security idp security-package-version
[edit]
user@host# run show services application-identification version
Verification
Action From operational mode, enter the show services application-identification version
command.
Meaning The sample output shows that the services application identification version is 1884.
• Requirements on page 45
• Overview on page 46
• Configuration on page 46
• Verification on page 47
Requirements
• Ensure that your SRX Series device has a connection to the Internet to download
security package updates.
NOTE: DNS must be set up because you need to resolve the name of the
update server.
• Ensure that you have installed the application identification feature license. See
“Installing and Verifying Licenses for an Application Signature Package” on page 37.
Overview
In this example, you want to download the current version of the application signature
package periodically. The download should start at 11:59 PM on December 10. To maintain
the most current information, you want to update the package automatically every 2
days from your company’s intranet site.
Configuration
GUI Step-by-Step To set up the automatic download and periodic update with the J-Web interface:
Procedure
1. Enter Configure>Security>AppSecure Settings to display the Applications Signature
page.
3. Click the Download Scheduler tab, and modify the following fields:
• URL: https://signatures.juniper.net/cgi-bin/index.cgi
• Interval: 48
4. Click Reset Setting to clear the existing start time, enter the new start time in
MM-DD.hh:mm format, and click OK.
Step-by-Step To use the CLI to automatically update the Junos OS application signature package:
Procedure
1. Specify the URL for the security package. The security package includes the detector
and the latest attack objects and groups. The following statement specifies
https://signatures.juniper.net/cgi-bin/index.cgi as the URL for downloading signature
database updates:
[edit]
user@host# set services application-identification download url
https://signatures.juniper.net/cgi-bin/index.cgi
2. Specify the time and interval for download. The following statement sets the interval
as 48 hours and the start time as 11:59 pm on December 10:
[edit]
user@host# set services application-identification download automatic interval 48
start-time 12-10.23:59
[edit]
user@host# commit
Verification
To verify that the application signature package is being updated properly, enter the
show services application-identification version command. Review the version number
and details for the latest update.
Scheduling the Application Signature Package Updates As Part of the IDP Security Package
The configuration instructions in this example describe how to setup automatic updates
of application identification signature package (part of IDP security package) at a specified
date and time.
• Requirements on page 47
• Overview on page 47
• Configuration on page 48
• Verification on page 49
Requirements
• Ensure that your SRX Series device has a connection to the Internet to download
security package updates.
NOTE: DNS must be set up because you need to resolve the name of the
update server.
• Ensure that you have installed the application identification feature license. See
“Installing and Verifying Licenses for an Application Signature Package” on page 37.
Overview
In this example, you want to download the current version of the application signature
package periodically. The download should start at 11:59 PM on December 10. To maintain
the most current information, you want to update the package automatically every 2
days from your company’s intranet site.
Configuration
GUI Step-by-Step To set up the automatic download and periodic update with the J-Web interface:
Procedure
1. Enter Configure>Security>IDP>Signature Updates to display the Security IDP Signature
Configuration page.
3. Click the Auto Download Settings tab, and modify the following fields:
• Interval: 48
4. Click Reset Setting to clear the existing fields, enter the new values. Click OK.
Step-by-Step To use the CLI to automatically update the Junos OS application signature package:
Procedure
1. Specify the URL for the security package. The security package includes the detector
and the latest attack objects and groups. The following statement specifies
https://signatures.juniper.net/cgi-bin/index.cgi as the URL for downloading signature
database updates:
[edit]
user@host# set security idp security-package url
https://signatures.juniper.net/cgi-bin/index.cgi
2. Specify the time and interval for download. The following statement sets the interval
as 48 hours and the start time as 11:55 pm on December 10, 2013:
[edit]
user@host# set security idp security-package automatic interval 48 start-time
2013-12-10.23:55:55
[edit]
user@host# set security idp security-package automatic enable
[edit]
user@host# commit
Verification
Action From operational mode, enter the show services application-identification version
command.
Meaning The sample output shows that, the services application identification version is 1884.
Example: Downloading and Installing the Application Identification Package in Chassis Cluster
Mode
This example shows how to download and install the application signature package
database to a device operating in chassis cluster mode.
• Requirements on page 49
• Overview on page 50
• Downloading and Installing the Application Identification Package on page 50
Requirements
• Set the chassis cluster node ID and cluster ID. See Example: Setting the Node ID and
Cluster ID for SRX Series Devices in a Chassis Cluster .
• Ensure that your SRX Series device has a connection to the Internet to download
security package updates.
NOTE: DNS must be set up because you need to resolve the name of the
update server.
• Ensure that you have installed application identification feature license. See “Installing
and Verifying Licenses for an Application Signature Package” on page 37.
Overview
If you use application identification, you can download the predefined application
signature package database. Juniper Networks regularly updates the database and makes
it available on the Juniper Networks website. This package includes application objects
that can be used to match traffic in IDP, application firewall policies, and application
tracking. For more details, see “Understanding the Junos OS Application Package
Installation” on page 35.
When you download the application identification security package on a device operating
in chassis cluster mode, the security package is downloaded to the primary node and
then synchronized to the secondary node.
The following example requires you to navigate various levels in the configuration
hierarchy. For instructions on how to do that, see CLI User Guide.
{primary:node0}[edit]
{primary:node0}[edit]
{primary:node0}[edit]
node0:
--------------------------------------------------------------------------
Please use command "request services application-identification install status"
to check status and use command "request services application-identification
proto-bundle-status" to check protocol bundle status
node1:
--------------------------------------------------------------------------
Please use command "request services application-identification install status"
to check status and use command "request services application-identification
proto-bundle-status" to check protocol bundle status
4. Check the application package update status. The command output displays
information about the downloaded and installed versions of the application package.
{primary:node0}[edit]
node0:
--------------------------------------------------------------------------
Install application package 2345 succeed
node1:
--------------------------------------------------------------------------
Install application package 2345 succeed
{primary:node0}[edit]
node0:
--------------------------------------------------------------------------
Please use command "request services application-identification uninstall
status" to check status and use command "request services
application-identification proto-bundle-status" to check protocol bundle status
node1:
--------------------------------------------------------------------------
Please use command "request services application-identification uninstall
status" to check status and use command "request services
application-identification proto-bundle-status" to check protocol bundle status
{primary:node0}[edit]
node0:
--------------------------------------------------------------------------
Uninstall application package 2345 succeed
node1:
--------------------------------------------------------------------------
Uninstall application package 2345 succeed
Protocol Bundle Version (1.30.4-22.005 (build date Jan 17 2014)) and application
secpack version (2345) is unloaded and deactivated
Purpose After successful download and installation of the application package, use the following
commands to view the predefined application signature package content.
pic: 1/0
Application Identification
Status Enabled
Sessions under app detection 0
Engine Version 4.18.1-20 (build date Jan 25 2014)
Max TCP session packet memory 30000
Max C2S bytes 1024
Max S2C bytes 0
Force packet plugin Disabled
Force stream plugin Disabled
Statistics collection interval 1 (in minutes)
Protocol Bundle
Download Server
https://services.netscreen.com/cgi-bin/index.cgi
AutoUpdate Enabled
Slot 1:
Status Active
Version 1.30.4-22.005 (build date Jan 17 2014)
Sessions 0
Slot 2
Status Free
2. Check the uninstall operation status of the application package. The command output
displays information about the uninstall status of the application package and protocol
bundle.
The application package and protocol bundle are uninstalled on the device. To reinstall
application identification, you need to download application package and reinstall it
again.
15.1X49-D65 Starting from 15.1X49-D65 and Junos OS Release 17.3R1, on SRX4100, and
SRX4200 devices, AppSecure is part of Juniper Networks Secure Edge
software (a default shipping software package).
User-defined custom application signatures can also be used to identify the application
regardless of the protocol and port being used. You can create custom signatures using
hostnames, IP address ranges, and ports, which allows you to track traffic to specific
destinations. For more information, see the following topics:
You can create custom application signatures using CLI by specifying a name, protocol,
port where the application runs, and match criteria. For more details, see “Example:
Configuring Junos OS Application Identification Custom Application Signatures” on
page 57.
You can view application signatures and application signature groups by using the show
services application-identification application and show services application-identification
group commands.
Unlike predefined signatures and groups, custom application signatures and groups are
saved in the configuration hierarchy, not in the predefined application signature database.
Custom application signatures and signature groups are located in the [services
application-identification] hierarchy.
ICMP-Based Mapping
The ICMP mapping technique maps standard ICMP message types and optional codes
to a unique application name. This mapping technique lets you differentiate between
various types of ICMP messages.
NOTE: IDP works only with TCP or UDP traffic. ICMP mapping, therefore,
does not apply to IDP and cannot support IDP features such as custom
attacks.
NOTE: The ICMP mapping technique used for mapping standard ICMP
message types and optional codes are not supported for ICMPv6 traffic.
Address-Based Mapping
Layer 3 and Layer 4 address mapping defines an application by the IP address and optional
port range of the traffic.
To ensure adequate security, use address mapping when the configuration of your private
network predicts application traffic to or from trusted servers. Address mapping provides
efficiency and accuracy in handling traffic from a known application.
Layer 3 and Layer 4 address-based custom applications, you can match the IP address
and port range to destination IP address and port. When both IP address and port are
configured, both should match destination tuples (IP address and port range) of the
packet.
Consider a Session Initiation Protocol (SIP) server that initiates sessions from its known
port 5060. Because all traffic from this IP address and port is generated by only the SIP
application, the SIP application can be mapped to the server’s IP address and port 5060
for application identification. In this way, all traffic with this IP address and port is identified
as SIP application traffic.
IP Protocol-Based Mapping
NOTE: IDP works only with TCP or UDP traffic. IP protocol mapping, therefore,
does not apply to IDP and cannot support IDP features such as custom
attacks.
Layer 7 custom signatures define an application running over TCP or UDP or Layer 7
applications. Layer 7-based custom application signatures are required for the
identification of multiple applications running on the same Layer 7 protocols. For example,
applications such as Facebook and Yahoo Messenger can both run over HTTP, but there
is a need to identify them as two different applications running on the same Layer 7
protocol.
Layer 7-based custom application signatures detect applications based on the patterns
in HTTP contexts. However, some HTTP sessions are encrypted in SSL, also called
Transport Layer Security (TLS). Application identification can also extract the server
name information or the server certification from the TLS or SSL sessions. It can also
detect patterns in TCP or UDP payload in Layer 7 applications.
• Requirements on page 57
• Overview on page 58
• Configuration on page 58
• Verification on page 62
Requirements
• Ensure that the SRX Series device with application signature package installed. See
“Downloading and Installing the Junos OS Application Signature Package Manually”
on page 39 or “Downloading and Installing the Junos OS Application Signature Package
As Part of the IDP Security Package” on page 42.
• The SRX Series device must be running Junos OS Release 15.1X49-D40 or later.
Overview
In this example, you create custom application signatures for applications based on
ICMP, IP protocol, IP address, and Layer 7.
For information about specify context for matching application, see context (Application
Identification).
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration 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.
HTTP Context-Based set services application-identification application mycustom-http over HTTP signature
Custom Signatures s1 member m01 context http-header-host
set services application-identification application mycustom-http over HTTP signature
s1 member m01 pattern .*agent1.*
set services application-identification application mycustom-http over HTTP signature
s1 member m01 direction client-to-server
SSL Context-Based set services application-identification application mycustom-ssl over SSL signature s1
Custom Signatures member m01 context ssl-server-name
set services application-identification application mycustom-ssl over SSL signature s1
member m01 pattern "example\.com"
set services application-identification application mycustom-ssl over SSL signature s1
member m01 direction client-to-server
TCP Stream-Based set services application-identification application mycustom-tcp over TCP signature s1
Custom Signatures member m01 context stream
set services application-identification application mycustom-tcp over TCP signature s1
member m01 pattern "123456789012345678901234567890"
set services application-identification application mycustom-tcp over TCP signature s1
member m01 direction client-to-server
Step-by-Step The following examples require you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see CLI User Guide.
2. Define the code for ICMP mapping. The code field provides further information
about the associated type field.
NOTE: You must provide the appropriate port range and specified IP
address to configure address-based custom application signatures.
Results From configuration mode, confirm your configuration by entering the show services
application-identification command. If the output does not display the intended
configuration, repeat the configuration instructions in this example to correct it.
[edit]
user@host# show services application-identification
download {
url https://services.netscreen.com/cgi-bin/index.cgi;
}
application MY-ICMP {
icmp-mapping {
type 100;
code 1;
}
}
application MY-IGMP {
ip-protocol-mapping {
protocol 2;
}
}
application My-ADDRESS {
address-mapping ADDR-SAMPLE {
filter {
ip 192.0.2.1/24;
port-range {
udp 5000-6000;
}
}
}
}
application mycustom-http {
over HTTP {
signature s1 {
member m01 {
context http-header-host;
pattern ".*agent1.*;";
direction client-to-server;
}
}
}
}
application mycustom-ssl {
over SSL {
signature s1 {
member m01 {
context ssl-server-name;
pattern "example\.com";
direction client-to-server;
}
}
}
}
application mycustom-tcp {
over TCP {
signature s1 {
member m01 {
context stream;
pattern 12345678901234567890123901234567;
direction client-to-server;
}
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Purpose Display predefined and custom application signatures and settings that are configured
on your device. Note that predefined application signature names use the prefix “junos:”
Action From configuration mode, enter the show services application-identification application
detail name command.
You can define an application group for both predefined applications, as well as custom
applications. An application group contains applications that need similar treatment
when defining a security policy. For more information, see the following topics:
Application group support associates related applications under a single name for
simplified, consistent reuse when using any application services.
All predefined application groups have the prefix “junos“ in the application group name
to prevent naming conflicts with custom application groups. You cannot modify the list
of applications within a predefined application group. However, you can copy a predefined
application group to use it as a template for creating a custom application group.
To customize a predefined application group, you must first disable the predefined group.
Note that a disabled predefined application group remains disabled after an application
database update. You can then use the operational command request services
application-identification group to copy the disabled predefined application group. The
copied group is placed in the configuration file, and the prefix “junos” is changed to “my”.
At this point, you can modify the list of applications in “my” application group and rename
the group with a unique name.
To reassign an application from one custom group to another, you must remove the
application from its current custom application group, and then reassign it to the other.
Example: Configuring a Custom Application Group for Junos OS Application Identification for
Simplified Management
This example shows how to configure custom application groups for Junos OS application
identification for consistent reuse when defining policies.
• Requirements on page 64
• Overview on page 64
• Configuration on page 64
Requirements
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” on page 39 or “Downloading and Installing the Junos OS
Application Signature Package As Part of the IDP Security Package” on page 42.
Overview
In this example, you define applications for an application group, delete an application
from an application group, and include an application group within another application
group.
Configuration
CLI Quick To quickly configure this section of the example, copy the following commands, paste
Configuration 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 The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode.
2. Add the list of applications that you want to include in your custom application
group.
4. Add the list of applications that you want to include in the group.
Results From configuration mode, confirm your configuration by entering the show services
application-identification group command. If the output does not display the intended
configuration, repeat the configuration instructions in this example to correct it.
[edit]
user@host# show services application-identification application-group my_web
applications {
junos:HTTP;
junos:FTP;
junos:GOPHER;
junos:AMAZON
}
user@host# show services application-identification application-group my_peer
applications {
junos:BITTORRENT;
junos:BITTORRENT-APPLICATION;
junos:BITTORRENT-WEB-CLIENT;
}
If you are done configuring the device, enter commit from configuration mode.
CLI Quick To quickly configure this section of the example, copy the following command, paste
Configuration 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.
[edit]
delete services application-identification application-group my_web applications
junos:AMAZON
Results From configuration mode, confirm your configuration by entering the show services
application-identification application group detail command. If the output does not display
the intended configuration, repeat the configuration instructions in this example to correct
it.
[edit]
user@host# show services application-identification group detail
application group my_web {
junos:HTTP;
junos:FTP;
junos:GOPHER;
}
If you are done configuring the device, enter commit from configuration mode.
CLI Quick To quickly configure this section of the example, copy the following commands, paste
Configuration 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.
Results From configuration mode, confirm your configuration by entering the show services
application-identification application-group application-group-name command. If the
output does not display the intended configuration, repeat the configuration instructions
in this example to correct it.
[edit]
user@host# show services application-identification application-group p2p
applications-groups {
my_web;
my_peer;
}
If you are done configuring the device, enter commit from configuration mode.
• For predefined application groups, you can disable and reenable a group using the
request services application-identification group command. You cannot delete a
predefined signature or signature group.
NOTE: Make sure to commit the configuration changes or roll back the
configuration when you are attempting to enable a disabled application
or an application group. Uncommitted changes might result in
configuration failure.
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.
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.
• 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.
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.
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.
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.
During the application identification process, DPI processes every packet and classifies
it into one of the following states until the application is finally identified:
• 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.
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.
Application Application
Scenario Identified Identification State Transactions
When an 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.
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 4 on page 72 shows application classification status in a
chassis cluster setup.
Application
Identification Chassis Cluster
Status Node Before Failover After Failover Details
• Security services such as security policies, AppFW, Juniper Sky ATP, IDP, and UTM do
not use the ASC by default.
• Miscellaneous services such as APBR and AppTrack 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.
Application Firewall
Application Firewall (AppFW) refers to the ability to take the results from the App ID
engine and leverage them to make an informed decision to permit, deny/ reject, or redirect
the traffic. For more information, see the following topics:
Evasive applications could remain undetected with a standard firewall that functions at
Layer 3 or Layer 4 by transmitting other protocols over these well-known ports that are
usually open by a firewall. AppFW enforces protocol and policy control at Layer 7. It
inspects the actual content of the payload and ensures that it conforms to the policy,
rather than identifying the application based on Layer 3 and Layer 4 information.
Additionally, with the growing popularity of Web applications and the shift from traditional
full client-based applications to the Web, more and more traffic is being transmitted
over HTTP. An application firewall identifies not only HTTP but also any application
running on top of it, letting you properly enforce policies. For example, an application
firewall rule could block HTTP traffic from Facebook but allow Web access to HTTP
traffic from MS Outlook.
• Create rules for each rule set that permit, reject, or deny traffic based on the application
ID.
• Configure a security policy to invoke the application firewall service and specify the
rule set to be applied to permitted traffic.
An application firewall permits, rejects, or denies traffic based on the application of the
traffic. The firewall consists of one or more rule sets with rules that specify match criteria,
including dynamic applications, and the action to be taken for matching traffic.
Each rule defines dynamic applications to permit, reject, or deny. Each rule consists of:
• The action to take for any traffic that matches one of the specified applications
• Reject—Notify the client, drop the traffic, close the session, and log the event.
• Deny—Drop the traffic, close the session, and log the event.
The default rule defines the action to be taken for any traffic that does not match one
of the rules. An application firewall rule set must contain a default rule.
There is no limit to the number of dynamic applications in a rule or to the number of rules
in a rule set. However, there is a limit to the overall number of rule sets and rules.
An application firewall is invoked using the then permit statement of the security policy.
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.
The following sample policy, outbound-traffic, permits matching HTTP traffic, and invokes
application services and an application firewall. The rule set, unknown-traffic, permits,
denies, or rejects, traffic based on its match criteria.
2. When specified, match the source and destination IP addresses, ports, and application
type.
• Reject—Notify the client, drop the traffic, and log the event.
NOTE: All IP fragmented packets received on the SRX Series device must be
reassembled before forwarding.
Application group support associates related applications under a single name for
simplified, consistent reuse when using any application services. As the predefined
signature database changes, the content of a predefined application group can be
modified to include new signatures without affecting existing firewall rules. When you
define application firewall rules, you can specify dynamic application groups as match
criteria.
Redirecting Users
Although drop and reject actions are logged, application firewall does not notify clients
when either action is taken. Clients are not aware that the webpage is not available and
might keep trying to access the page. To provide an explanation for the action or to
redirect the client to an informative webpage, use the block-message option with the
reject or deny action in an application firewall rule.
...
then reject block-message
When traffic is rejected by the application firewall rule, a splash screen with the following
default message is displayed to the user:
To help the user fully understand which request has been rejected or denied, the default
message includes traffic-specific details, such as the username, application, and address
information.
You can customize the redirect action by including additional text on the splash screen
or by specifying a URL to which the user is redirected. To customize the block message,
define the type and content in a block message profile defined in the rule set:
The block message profile is identified for the rule set, and applied to one or more of the
rules using the block-message option.
In this example, any traffic matching one of the specified dynamic applications is denied,
and the block message defined for rule set, deny-profile-1, is applied. Based on the profile
for deny-profile-1, the user is redirected to the URL http://abc.company.com/information
for further details.
With security policies, the permit action of the matched policy rule creates a session and
logs a session create message. A reject or deny action logs a reject or deny message, but
does not create a session.
When an application firewall is implemented, the permit action of the security policy
creates a session before the application firewall rules are applied. If the dynamic
application have been retrieved from the cache, this information is added to the session
create message. If the application is in the process of being identified, the dynamic
application fields specify UNKNOWN.
If traffic is rejected or denied by the application firewall, application firewall also closes
the session. The reject or deny message actions are logged with the reason field containing
one of the following phrases:
• policy deny
• policy reject
When the application ID is not identified during failover sessions, the ID is considered an
unknown application ID. During this session, the traffic is processed based on the action
defined in a rule specified for unknown. If there is no rule defined for unknown, then the
default rule is applied.
NOTE: When an SRX Series device is operating in chassis cluster mode and
application identification is enabled, pre-match state application IDs are not
synced to other node. If there are any failover sessions, which were still under
classification, will not have any application IDs assigned. This could result in
application statistics and counters mismatch.
When the application ID is identified before sessions fail over, the same action taken
before the failover is effective after the failover. The application firewall action taken
before and after the failover depends on the application ID state, as shown in
Table 5 on page 80.
Application ID State Application Firewall Action Application ID State Application Firewall Action
Success Deny Success Deny
Unified policies leverage the application identity information from the application
identification (AppID) service to permit, deny, reject, or redirect the traffic.
Unified policies using the new matching condition dynamic application facilitate the same
functionality of an AppFW configuration. When you configure a unified policy with a
dynamic application as the matching condition, the configuration eliminates the additional
steps involved in an AppFW configuration, which invoke the AppFW service in a security
policy.
A unified policy configuration handles all application firewall functionality and simplifies
the task of configuring a firewall policy to permit or block application traffic from the
network.
If you have configured a traditional security policy (configured using a 5-tuple matching
condition) and a unified policy (configured using a 6-tuple matching condition), the
traditional security policy matches the traffic first, before the unified policy.
When using AppFW after upgrading to the Junos OS Release 18.2R1 and later, note the
following changes:
• Configuring a traditional AppFW policy and a unified policy with a dynamic application
as the matching condition in the same security policy is not supported.
• All existing AppFW related CLI statements and commands are deprecated.
• If you are downgrading from Junos OS Release 18.2R1 to any earlier versions of Junos
OS, you must delete all unified policies to avoid a commit check failure after a
downgrade.
You can configure security policies using dynamic applications as the match conditions.
If you have configured AppFW and if the security policy with the dynamic application is
also configured and applied, the following error message is displayed:
• Requirements on page 82
• Overview on page 82
• Configuration on page 82
• Verification on page 85
Requirements
• Configure an address book with addresses for the policy. See Example: Configuring
Address Books and Address Sets.
Overview
In Junos OS, the security policies provide firewall security functionality by enforcing rules
for the traffic so that traffic passing through the device is permitted or denied based on
the action defined in the rules. The application firewall support in the policies provides
additional security control for dynamic applications.
The application firewall is defined by a collection of rule sets. These rule sets can be
defined independently and shared across network security policies. A rule set defines
the rules that match the application ID detected, based on the application signature.
• Permit or deny selected traffic from the untrust zone to the trust zone, based on the
application firewall rule sets defined with the rules matching the dynamic applications.
NOTE: On all SRX Series devices, J-Web pages for AppSecure Services are
preliminary. We recommend using CLI for configuration of AppSecure features.
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration 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 security policies from-zone untrust to-zone trust policy policy1 match source-address
198.51.100.1
set security policies from-zone untrust to-zone trust policy policy1 match
destination-address 192.0.2.1
set security policies from-zone untrust to-zone trust policy policy1 match application
junos-http
set security policies from-zone untrust to-zone trust policy policy1 then permit
application-services application-firewall rule-set rs1
set security policies from-zone untrust to-zone trust policy policy2 match source-address
198.51.100.1
set security policies from-zone untrust to-zone trust policy policy2 match
destination-address 192.0.2.1
set security policies from-zone untrust to-zone trust policy policy2 match application any
set security policies from-zone untrust to-zone trust policy policy2 then permit
application-services application-firewall rule-set rs2
set security application-firewall rule-sets rs1 rule r1 match dynamic-application
[junos:KAZAA junos:EDONKEY junos:YMSG]
set security application-firewall rule-sets rs1 rule r1 then deny
set security application-firewall rule-sets rs1 default-rule permit
set security application-firewall rule-sets rs2 rule r1 match dynamic-application
[junos:FACEBOOK-ACCESS junos:GOOGLETALK junos:MEEBOME junos:UNKNOWN]
set security application-firewall rule-sets rs2 rule r1 then permit
set security application-firewall rule-sets rs2 default-rule deny
Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see CLI User Guide.
To configure two security policies with application firewall rule sets that permit or deny
traffic from different dynamic applications:
1. Configure a policy to process the traffic that goes to the HTTP static ports with the
application firewall rule set rs1.
2. Configure another policy to process any traffic that does not go to the HTTP static
ports with the application firewall rule set rs2.
3. Define the application firewall rule set rs1 to deny traffic from selected dynamic
applications.
4. Define the application firewall rule set rs2 to permit traffic from selected dynamic
applications.
Results From configuration mode, confirm your configuration by entering the show security policies
and show security application-firewall commands. 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 {
policy 1 {
match {
source-address 198.51.100.1;
destination-address 192.0.2.1;
application junos-http;
}
then {
permit {
application-services {
application-firewall {
rule-set rs1;
}
}
}
}
}
policy 2 {
match {
source-address 198.51.100.1;
destination-address 192.0.2.1;
application any;
}
then {
permit {
application-services {
application-firewall {
rule-set rs2;
}
}
}
}
}
}
user@host# show security application-firewall
rule-sets rs1 {
rule r1 {
match {
dynamic-application [junos:KAZAA junos:EDONKEY junos:YMSG];
}
then {
deny;
}
}
default-rule {
permit;
}
}
rule-sets rs2 {
rule r1 {
match {
dynamic-application [junos:FACEBOOK-ACCESS junos:GOOGLETALK
junos:MEEBOME junos:UNKNOWN];
}
then {
permit;
}
}
default-rule {
deny;
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Purpose Verify information about application firewall support enabled under the security policy.
Action To verify the security policy configuration enabled with application firewall, enter the
show security policies and show security policies detail commands. To verify all the
application firewall rule sets configured on the device, enter the show security
application-firewall rule-set all command.
Meaning The output displays information about application firewall enabled policies configured
on the system. Verify the following information.
• Rule set
• Rules
• Match criteria
This example shows how to configure application groups within the application firewall
rule set.
• Requirements on page 86
• Overview on page 86
• Configuration on page 86
• Verification on page 89
Requirements
Overview
The following example configures network policies to control outbound traffic from the
trust zone to the untrust zone. All traffic permitted by the policy is processed further with
the specified application firewall. The application firewall denies outbound traffic from
unknown applications. Outbound Google Talk traffic is allowed, but all other known
social networking traffic is denied. All other traffic is permitted.
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration 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 The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode.
To configure application firewall rule-sets and security policies for outbound traffic:
[edit]
user@host# set security application-firewall rule-sets social-network
3. Define a second rule that denies all other social-networking traffic and traffic from
an unknown application.
Note that rule sequence is important. If the rules google-rule and denied-sites are
reversed, GOOGLETALK traffic would never be permitted. The denied-sites rule
would shadow google-rule.
Results From configuration mode, confirm your configuration by entering the show security
application-firewall and show security policies commands. If the output does not display
the intended configuration, repeat the instructions in this example to correct the
configuration.
[edit]
user@host# show security application-firewall
...
rule-sets social-network {
rule google-rule {
match {
dynamic-application junos:GOOGLETALK;
}
}
then {
permit ;
}
rule denied-sites {
match {
dynamic-application-groups junos:social-networking
dynamic-application junos:UNKNOWN;
}
then {
deny ;
}
}
default-rule {
permit;
}
}
...
[edit]
user@host# show security policies
from-zone untrust to-zone trust {
...
policy outbound-traffic {
match {
source-address any;
destination-address any;
application junos-http;
}
then {
permit {
application-services {
application-firewall {
rule-set social-network
}
}
}
}
}
...
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Purpose Verify information about application grouping support under the application firewall
policy.
Action • To verify the application firewall policy configuration enabled with application grouping,
from the operational mode, enter the show security policies and show security policies
detail commands.
• To verify all the application firewall rule sets configured on the device, from the
operational mode, enter the show security application-firewall rule-set all command.
• To verify the list of applications defined within the application group, from the
operational mode, enter the show services application-identification application-group
application-group-name command.
This example describes how AppFW supports this AppID functionality when SSL proxy
is enabled.
• Requirements on page 90
• Overview on page 90
• Configuration on page 90
Requirements
• Configure an address book with addresses for the policy. See Example: Configuring
Address Books and Address Sets.
• Create an application (or application set) that indicates that the policy applies to traffic
of that type. See Example: Configuring Applications and Application Sets.
• Create a SSL proxy profile that enables SSL proxy by means of a policy. See “Configuring
SSL Forward Proxy” on page 182.
Overview
This example shows how to verify the functionality of AppFW when SSL proxy is enabled
and a different action, deny or permit, is performed on plain text and encrypted traffic.
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration 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 security policies from-zone Z_1 to-zone Z_2 policy policy1 match source-address any
set security policies from-zone Z_1 to-zone Z_2 policy policy1 match destination-address
any
set security policies from-zone Z_1 to-zone Z_2 policy policy1 match application junos-https
set security policies from-zone Z_1 to-zone Z_2 policy policy1 then permit
application-services application-firewall rule-set appfw-rs-1
set security policies from-zone Z_1 to-zone Z_2 policy policy1 then permit
application-services ssl-proxy profile-name ssl-profile-1
set security policies from-zone Z_1 to-zone Z_2 policy policy2 match source-address any
set security policies from-zone Z_1 to-zone Z_2 policy policy2 match destination-address
any
set security policies from-zone Z_1 to-zone Z_2 policy policy2 match application junos-http
set security policies from-zone Z_1 to-zone Z_2 policy policy2 then permit
application-services application-firewall rule-set appfw-rs-2
set security application-firewall rule-sets appfw-rs-1 rule rule1 match dynamic-application
[junos:ORACLE]
user@host# set security application-firewall rule-sets appfw-rs-1 rule rule1 then permit
user@host# set security application-firewall rule-sets appfw-rs-1 default-rule deny
user@host# set security application-firewall rule-sets appfw-rs-2 rule rule1 match
dynamic-application [junos:HULU]
user@host# set security application-firewall rule-sets appfw-rs-2 rule rule1 then deny
user@host# set security application-firewall rule-sets appfw-rs-2 default-rule permit
Step-by-Step The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see CLI User Guide.
In this example, you configure two security policies with AppFW rule sets that permit or
deny traffic from plain text or encrypted traffic:
• Allow the encrypted version of Oracle and deny any other encrypted traffic.
1. Configure a policy to process the traffic with AppFW rule set appfw-rs-1 and SSL
proxy profile ssl-profile-1.
3. Define the AppFW rule set appfw-rs-1 to permit an encrypted version of Oracle and
to deny any other encrypted traffic.
4. Define the AppFW rule set appfw-rs-2 to allow all plain text traffic except Hulu.
Results From configuration mode, confirm your configuration by entering the show security policies
and show security application-firewall 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.
NOTE: For application junos-https, SSL proxy detects an SSL session based
on the dynamic application identified for that session. If you know any
webservers that are running nonstandard ports, you can use a custom Junos
OS application to identify the application. However, if the webservers are not
known, for example on the Internet, use application any. Non-SSL sessions
that come across the policy rule are ignored by SSL proxy. A syslog
SSL_PROXY_SESSION_IGNORE is sent out for these sessions. Juniper
Networks recommends that you use application “any” with caution because
this can result in a lot of traffic, incurring initial SSL proxy processing and
thereby impacting performance.
Purpose Verify that the application is configured correctly when SSL proxy is enabled in a policy.
Action From operational mode, enter the show security policies command.
The following output shows the options for the show security flow session command.
Possible completions:
<[Enter]> Execute this command
application Application protocol name
application-firewall Show application-firewall sessions
application-firewall-rule-set Show application firewall sessions matching
rule-set name
brief Show brief output (default)
destination-port Destination port (1..65535)
destination-prefix Destination IP prefix or address
dynamic-application Dynamic application name
extensive Show detailed output
+ encrypted Show encrypted traffic
family Show session by family
idp Show idp sessions
interface Name of incoming or outgoing interface
nat Show sessions with network address translation
protocol IP protocol number
resource-manager Show sessions with resource manager
session-identifier Show session with specified session identifier
source-port Source port (1..65535)
source-prefix Source IP prefix or address
summary Show output summary
tunnel Show tunnel sessions
| Pipe through a command
To display SSL encrypted UNKNOWN sessions, use the show security flow session
application-firewall dynamic-application junos:SSL extensive command.
To display all HTTPS sessions, use the show security flow session application-firewall
dynamic-application junos:HTTP encrypted extensive command.
Application Tracking
Application tracking (AppTrack) is a logging and reporting tool that can be used to share
information for application visibility. AppTrack sends log messages through syslog
providing application activity update messages. For more information, see the following
topics:
AppTrack messages are similar to session logs and use syslog or structured syslog formats.
The message also includes an application field for the session. If AppTrack identifies a
AppTrack supports both IPv4 and IPv6 addressing. Related messages display addresses
in the appropriate IPv4 or IPv6 format.
User identity details such as user name and user role have been added to the AppTrack
session create, session close, and volume update logs. These fields will contain the user
name and role associated with the policy match. The logging of user name and roles is
enabled only for security policies that provide UAC enforcement. For security policies
without UAC enforcement, the user name and user role fields are displayed as N/A. The
user name is displayed as unauthenticated user and user role is displayed as N/A, if the
device cannot retrieve information for that session because there is no authentication
table entry for that session or because logging of this information is disabled. The user
role field in the log contains the list of all the roles performed by the user if match criteria
is specific, authenticated user, or any, and the user name field in the log contains the
correct user name. The user role field in the log will contain N/A if the match criteria and
the user name field in the log contain unauthenticated user or unknown user.
If you enable AppTrack for a zone and specify a session-update-interval time, whenever
a packet is received, AppTrack checks whether the time since the start of the session or
since the last update is greater than the update interval. If so, AppTrack updates the
counts and sends an update message to the host. If a short-lived session starts and ends
within the update interval, AppTrack generates a message only at session close.
When you want the initial update message to be sent earlier than the specified update
interval, use the first-update-interval. The first-update-interval lets you enter a shorter
interval for the first update only. Alternatively, you can generate the initial update message
at session start by using the first-update option.
The close message updates the statistics for the last time and provides an explanation
for the session closure. The following codes are used:
• Provides visibility into the types of applications traversing through an SRX Series device.
• Enables you to gain insight into permitted applications and the risk they might pose.
Starting from Junos OS Release 15.1X49-D100, AppTrack session create, session close,
and volume update logs include a new field called destination interface. You can use the
destination interface field to see which egress interface is selected for the session when
a advanced policy-based routing (APBR) is applied to that session and AppTrack is
enabled and configured within any logical system.
Starting from Junos OS Release 15.1X49-D100, a new AppTrack log for route update is
added to include APBR profile, rule, and routing instance details. When APBR is applied
to a session, the new log is generated and the AppTrack session counter is updated to
indicate the number of times a new route update log is generated. The AppTrack session
close log is also updated to include APBR profile, rule, and routing instance details.
Starting from Junos OS Release 17.4R1, AppTrack session create, session close, and
volume update logs include the new fields category and subcategory. These fields provide
general information about the application attributes. For example, the category field
specifies the technology of the application (web, infrastructure) and subcategory field
specifies the subcategory of the application (for example, social networking, news, and
advertisements).
Because category and subcategory are not applicable for a custom application, the
AppTrack log messages present the category as custom application and the subcategory
as N/A.
For unknown applications, both category and subcategories are logged as N/A.
Starting from Junos OS Release 18.2R1, AppTrack session close logs include new fields
to record the packet bytes transmitted and received through the uplink interfaces. The
packet bytes transmitted and received through the uplink interfaces are reported by
uplink-tx-bytes, uplink-rx-bytes, and uplink-incoming-interface-name fields.
Example:
Starting from Junos OS Release 18.2R1, new application tracking messages are added
for AppQoE (application quality of experience).. The new Apptrack messages provide
information such as active and passive metric report, switching of application traffic path
as shown in the following samples:
• Requirements on page 98
• Overview on page 98
• Configuration on page 98
• Verification on page 101
Requirements
Before you configure AppTrack, ensure that you have downloaded the application
signature package, installed it, and verified that the application identification configuration
is working properly. See “Downloading and Installing the Junos OS Application Signature
Package Manually” on page 39 or “Downloading and Installing the Junos OS Application
Signature Package As Part of the IDP Security Package” on page 42. Use the show services
application-identification status command to verify the status.
Overview
Configuration
This example shows how to enable application tracking for the security zone named
trust. The first log message is to be generated when the session starts, and update
messages should be sent every 4 minutes after that. A final message should be sent at
session end.
The example also shows how to add the remote syslog device configuration to receive
AppTrack log messages in sd-syslog format. The source IP address that is used when
exporting security logs is 192.0.2.1, and the security logs are sent to the host located at
address 192.0.2.2.
NOTE: On all SRX Series devices, J-Web pages for AppSecure Services are
preliminary. We recommend using CLI for configuration of AppSecure features.
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration 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 The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see CLI User Guide.
To configure AppTrack:
[edit]
user@host# set security log mode stream
user@host# set security log format sd-syslog
user@host# set security log source-address 192.0.2.1
user@host# set security log stream app-track-logs host 192.0.2.2
[edit]
[edit]
user@host# set security application-tracking session-update-interval 4
The default interval between messages is 5 minutes. If a session starts and ends
within this update interval, AppTrack generates one message at session close.
However, if the session is long-lived, an update message is sent every 5 minutes.
The session-update-interval minutes is configurable as shown in this step.
4. (Optional) For this example, generate the first message when the session starts.
[edit]
user@host# set security application-tracking first-update
By default, the first message is generated after the first session update interval
elapses. To generate the first message at a different time than this, use the
first-update option (generate the first message at session start) or the
first-update-interval minutes option (generate the first message after the specified
minutes). For example, enter the following command to generate the first message
one minute after session start.
[edit]
user@host# set security application-tracking first-update-interval 1
Once the first message has been generated, an update message is generated each
time the session update interval is reached.
Results From configuration mode, confirm your configuration by entering the show security and
show security zones commands. If the output does not display the intended configuration,
repeat the configuration instructions in this example to correct it.
For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).
[edit]
user@host# show security
...
application-tracking {
first-update;
session-update-interval 4;
}
log {
mode stream;
format sd-syslog;
source-address192.0.2.2;
stream app-track-logs {
host {
192.0.2.1;
}
}
}
...
[edit]
user@host# show security zones
...
security-zone trust {
...
application-tracking;
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Use the JSA product on the remote logging device to view the AppTrack log messages.
To confirm that the configuration is working properly, you can also perform these tasks
on the SRX Series device:
Purpose Review AppTrack statistics to view characteristics of the traffic being tracked.
Action From operational mode, enter the show services application-identification statistics
applications command.
Action From operational mode, enter the show security application-tracking counters command.
Purpose Compare byte and packet counts in logged messages with the session statistics from
the show security flow session command output.
Action From operational mode, enter the show security flow session command.
Valid sessions: 1
Pending sessions: 0
Invalidated sessions: 0
Sessions in other states: 0
Total sessions: 1
Byte and packet totals in the session statistics should approximate the counts logged
by AppTrack but might not be exactly the same. AppTrack counts only incoming bytes
and packets. System-generated packets are not included in the total, and dropped
packets are not deducted.
Purpose Compare cache statistics such as IP address, port, protocol, and service for an application
from the show services application-identification application-system-cache command
output.
Purpose Compare session statistics for application identification counter values from the show
services application-identification counter command output.
Action From operational mode, enter the show services application-identification counter
command.
Requirements
• Create an SSL proxy profile that enables SSL proxy by means of a policy. See
“Configuring SSL Forward Proxy” on page 182.
Overview
You can configure AppTrack either in the to or from zones. This example shows how to
configure AppTrack in a to zone in a policy rule when SSL proxy is enabled.
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration 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 The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode.
In this example, you configure application tracking and permit application services in an
SSL proxy profile configuration.
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.
profile-name ssl-profile-1;
}
}
}
}
}
}
If application tracking has been previously disabled and you want to reenable it, delete
the configuration statement that specifies disabling of application tracking:
18.2R1 Starting from Junos OS Release 18.2R1, AppTrack session close logs include
new fields to record the packet bytes transmitted and received through the
uplink interfaces.
18.2R1 Starting from Junos OS Release 18.2R1, new application tracking messages
are added for AppQoE (application quality of experience).
17.4R1 Starting from Junos OS Release 17.4R1, AppTrack session create, session
close, and volume update logs include the new fields category and
subcategory
15.1X49-D100 Starting from Junos OS Release 15.1X49-D100, a new AppTrack log for route
update is added to include APBR profile, rule, and routing instance details.
Application QoS
AppQoS enable you to identify and control access to specific applications and provides
the granularity of the stateful firewall rule base to match and enforce quality of service
(QoS) at the application layer. For more information, see the following topics:
There are four ways to mark DSCP values on SRX Series devices:
IDP remarking is conducted at the ingress port based on IDP rules. Application remarking
is conducted at the egress port based on application rules. Interface-based remarking
also occurs at the egress port based on firewall filter rules. (See the Class of Service
Feature Guide for Security Devices for a detailed description of Junos OS CoS features.)
The remarking decisions of these three rewriters can be different. If a packet triggers all
three, the method that takes precedence is based on how deep into the packet content
the match is conducted. IDP remarking has precedence over application remarking which
has precedence over interface-based remarking.
If a packet triggers both AppQoS and ALG-based DSCP rewriters, then AppQoS takes
precedence over ALG-based DSCP rewriters.
The AppQoS DSCP rewriter conveys a packet’s quality of service through both the
forwarding class and a loss priority. The AppQoS rate-limiting parameters control the
transmission speed and volume for its associated queues.
AppQoS provides the ability to prioritize and meter the application traffic to provide
better service to business-critical or high-priority application traffic.
Unique forwarding class names protect AppQoS remarking from being overwritten by
interface-based rewrite rules. A firewall filter-based rewriter remarks a packet’s DSCP
value if the packet’s forwarding class matches a class defined specifically for this rewriter.
If the packet’s forwarding class does not match any of the firewall filter-based rewriter’s
classes, the DSCP value is not remarked. To protect AppQoS values from being
overwritten, therefore, use forwarding class names that are unknown to the firewall
filter-based rewriter.
Each forwarding class is assigned to an egress queue that provides the appropriate degree
of enhanced or standard processing. Many forwarding classes can be assigned to a single
queue. Therefore, any queues defined for the device can be used by IDP, AppQoS, and
firewall filter-based rewriters. It is the forwarding class name, not the queue, that
distinguishes the transmission priority. (See the Class of Service Feature Guide for Security
Devices for information about configuring queues and schedulers.)
For SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices, the AppQoS
forwarding class names and queue assignments are defined with the class-of-service
CLI configuration command:
[edit class-of-service]
user@host# forwarding-classes class forwarding-class-name queue-num queue-number
[edit class-of-service]
user@host# forwarding-classes queue queue-number forwarding-class-name
For AppQoS, traffic is grouped based on rules that associate a defined forwarding class
with selected applications. The match criteria for the rule includes one or more
applications. When traffic from a matching application encounters the rule, the rule
action sets the forwarding class, and remarks the DSCP value and loss priority to values
appropriate for the application.
A Differentiated Services (DiffServ) code point (DSCP) value is specified in the rule either
by a 6-bit bitmap value or by a user-defined or default alias. Table 6 on page 108 provides
a list of Junos OS default DSCP alias names and bitmap values.
ef 101110
af11 001010
af12 001100
af13 001110
af21 010010
af22 010100
af23 010110
af31 011010
af32 011100
af33 011110
af41 100010
af42 100100
af43 100110
be 000000
cs1 001000
cs2 010000
cs3 011000
cs4 100000
cs5 101000
nc1/cs6 110000
nc2/cs7 111000
The queue’s scheduler uses the loss priority to control packet discard during periods of
congestion by associating drop profiles with particular loss priority values. (See the Class
of Service Feature Guide for Security Devices for information about configuring queues
and schedulers.)
The rule applies a loss priority to the traffic groups. A high loss priority means a high
probability that the packet could be dropped during a period of congestion. Four levels
of loss priority are available:
• high
• medium-high
• medium-low
• low
[edit class-of-service]
user@host# application-traffic-control rule-sets ruleset-name rule rule-name1 match
application application-name application-name ...
user@host# application-traffic-control rule-sets ruleset-name rule rule-name1 match
application-group application-group-name application-group-name ...
user@host# application-traffic-control rule-sets ruleset-name rule rule-name1 then
forwarding-class fc-name
user@host# application-traffic-control rule-sets ruleset-name rule rule-name1 then
dscp-code-point bitmap
user@host# application-traffic-control rule-sets ruleset-name rule rule-name1 then
loss-priority loss-pri-value
When congestion occurs, AppQoS implements rate limiting on all egress PICs on the
device. If packets exceed the assigned limitations, they are dropped. Rate limiters maintain
a consistent level of throughput and packet loss sensitivity for different classes of traffic.
All egress PICs employ the same rate-limiting scheme.
The total bandwidth of a PIC is about 10 Gbps. Rate-limiter hardware for the PIC can
31
provision up to 2 Gbps. Therefore, the upper bandwidth limit for rate limiting is 2 bps.
AppQoS allows up to 16 profiles and up to 1000 rate limiters per device. Multiple rate
limiters can use the same profile. In the following example, five rate limiters are defined
using two profiles:
Profile
[edit class-of-service]
user@host# application-traffic-control rate-limiters rate-limiter-name bandwidth-limit
value-in-Kbps burst-rate-limit value-in-bytes
Rate-Limiter Assignment
Rate limiters are applied in rules based on the application of the traffic. Two rate limiters
are applied for each session: client-to-server and server-to-client. This usage allows traffic
in each direction to be provisioned separately.
Different AppQoS rules within the same rule set can share a rate limiter. In this case, the
applications of those rules share the same bandwidth. There are no limitations on the
number of rules in one rule set that can assign the same rate limiter.
The following examples show how the rate limiters defined in the preceding section could
be assigned. For instance, a rule set could reuse a rate limiter in several rules and in one
or both flow directions:
• rule-set-1
• rule-1A
• client-to-server limiter-1
• server-to-client limiter-1
• rule-1B
• client-to-server limiter-1
• server-to-client limiter-1
If the same profiles are needed in several rule sets, a sufficient number of rate limiters
needs to be defined specifying the same bandwidth-limit and burst-size-limit. The two
rule sets in the following example implement the same profiles by assigning different,
but comparable, rate limiters.
• rule-set-2
• rule-2A
• client-to-server limiter-2
• server-to-client limiter-2
• rule-2B
• client-to-server limiter-2
• server-to-client limiter-4
• rule-set-3
• rule-3A
• client-to-server limiter-3
• server-to-client limiter-3
• rule-3B
• client-to-server limiter-3
• server-to-client limiter-5
[edit class-of-service]
user@host# application-traffic-control rule-sets rule-set-name rule rule-name1 then
rate-limit client-to-server rate-limiter1 server-to-client rate-limiter2
If AppQoS and firewall filter-based rate limiting are both implemented on the egress PIC,
both are taken into consideration. AppQoS rate limiting is considered first. Firewall
filter-based rate limiting occurs after that.
NOTE: If packets are dropped from a PIC, the SRX Series device does not
send notifications to the client or the server. The upper-level applications on
the client and the server devices are responsible for retransmission and error
handling.
Rate-Limiter Action
Based on the type of SRX Series device, AppQoS rules can be configured with different
rate-limiter actions:
• Discard
• When this option is selected, the out-of-profile packets are just dropped.
• Loss-priority-high
• When this option is selected , it elevates the loss priority to maximum. In other words,
it is a delayed drop; that is, the discard decision is taken at the egress output queue
level. If there is no congestion, it allows the traffic even with maximum loss priority.
But if congestion occurs, it drop these maximum loss priority packets first.
• This option must be configured within the AppQoS rule (to override the default
action) using the following command:
[edit]
user@host# set class-of-service application-traffic-control rule-sets rset-01 rule r1
then rate-limit loss-priority-high
• This option is supported only on for SRX300, SRX320, SRX340, SRX345 devices.
The AppQoS rule set can be implemented in an existing policy or a specific application
policy.
[edit]
user@host# security policies from-zone zone-name to-zone zone-name
[edit security policies from-zone zone-name to-zone zone-name]
user@host# policy policy-name match source-address IP-address
user@host# policy policy-name match destination-address IP-address
user@host# policy policy-name match application application-name application-name
user@host# policy policy-name then permit application-services application-traffic-control
rule-set app-rule-set-name
Requirements
Overview
NOTE: On all SRX Series devices, J-Web pages for AppSecure Services are
preliminary. We recommend using CLI for configuration of AppSecure features.
Configuration
For SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices, use the
following command:
[edit]
[edit]
user@host# set class-of-service forwarding-classes queue-num 0 my-app-fc
2. Define rate limiters. In this example, two rate limiters are defined.
NOTE: For SRX5400, SRX5600, and SRX5800 devices, you can define
up to 1000 rate limiters for a device, but only 16 profiles (unique
bandwidth-limit and burst-size-limit combinations).
• test-r1 with a bandwidth of 100 Kbps and a burst limit of 13,000 bytes
• test-r2 with a bandwidth of 200 Kbps and a burst limit of 26,000 bytes
[edit]
user@host# set class-of-service application-traffic-control rate-limiters test-rl
bandwidth-limit 100
user@host# set class-of-service application-traffic-control rate-limiters test-rl
burst-size-limit 13000
user@host# set class-of-service application-traffic-control rate-limiters test-r2
bandwidth-limit 200
user@host# set class-of-service application-traffic-control rate-limiters test-r2
burst-size-limit 26000
3. Define AppQos rules and application match criteria. For this example, rule 0 in rule
set ftp-test1 is applied to junos:FTP packets.
[edit]
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
0 match application junos:FTP
4. Define the action for rule 0 when it encounters a junos:FTP packet. In this example,
when a match is made, the packet is marked with the forwarding class my-app-fc,
the DSCP value of af22, and a loss priority of low.
[edit]
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
0 then forwarding-class my-app-fc
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
0 then dscp-code-point af22
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
0 then loss-priority low
5. Assign rate limiters for rule 0 to traffic in each direction. In this case, the rate limiter
test-r1 is set in both directions.
[edit]
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
0 then rate-limit client-to-server test-r1
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
0 then rate-limit server-to-client test-r1
[edit]
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
0 then log
7. Define other rules to handle application packets that did not match the previous
rule. In this example, a second and final rule applies to all remaining applications.
[edit]
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
1 match application-any
8. Assign rate limiters for the second rule. In this example, any traffic that is not from
FTP is assigned rate limiter test-r2 in both directions.
[edit]
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
1 then rate-limit client-to-server test-r2
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
1 then rate-limit server-to-client test-r2
user@host# set class-of-service application-traffic-control rule-sets ftp-test1 rule
1 then log
9. Add the AppQoS implementation to a policy. In this example, policy p1 applies the
rule set ftp-test1 to all traffic from the trust zone to the untrust zone.
[edit]
user@host# set security policies from-zone trust to-zone untrust policy p1
[edit security policies from-zone trust to-zone untrust policy p1]
user@host# set match source-address any
user@host# set match destination-address any
user@host# set match application any
user@host# set then permit application-services application-traffic-control rule-set
ftp-test1
Results From configuration mode, confirm your policy configuration by entering the show security
policies command. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.
For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).
...
policy p1 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
application-services {
application-traffic-control {
rule-set ftp-test1
}
}
}
}
}
...
If you are done configuring the device, enter commit from configuration mode.
Verification
Action From operational mode, enter the show security flow session application-traffic-control
extensive command.
Meaning The entry for application traffic control identifies the rule set and rule of the current
session.
Purpose Verify that AppQoS session statistics are being accumulated at each egress node.
Action From operational mode, enter the show class-of-service application-traffic-control counter
command.
pic: 2/0
Counter type Value
Sessions processed 400
Sessions marked 300
Sessions honored 0
Sessions rate limited 200
Client-to-server flows rate limited 200
Server-to-client flows rate limited 200
Meaning The AppQoS statistics are maintained only if application-traffic-control service is enabled.
The number of sessions processed, marked, and honored show that sessions are being
directed based on configured AppQoS features. The rate-limiting statistics count the
number of directional session flows that have been rate limited.
Purpose Verify that bandwidth is being limited as expected when the FTP application is
encountered.
Meaning Real-time application bandwidth-limit information for each PIC is displayed by rule set.
This command provides an indication of the applications being rate limited and the profile
being applied.
pic: 2/0
Ruleset Rule Hits
ftp-test1 0 100
ftp-test1 1 200
Meaning This command provides information on the number of (session) hits for a rule under each
rule set.
Unified policies are the security policies that enable you to use dynamic applications as
part of the existing 5-tuple or 6-tuple (5-tuple with a user firewall) match conditions to
detect application changes over time.
Application quality of service (AppQoS) is supported when the SRX Series device is
configured with unified policies. You can configure a default AppQoS rule set to manage
unified policy conflicts if multiple security policies match the traffic.
AppQoS rule sets are included in the unified policy to implement application-aware
quality-of-service control. You can configure a rule set with rules under the
application-traffic-control option, and attach the AppQoS rule set to a unified security
policy as an application service. If the traffic matches the specified dynamic application
and the policy action is permit, the application-aware quality of service is applied.
• Upgrading from traditional security policy to a unified policy—In a unified policy, when
you configure the dynamic-application option as none, the AppQoS rule set is applied
during the security policy match and the AppQoS looks for the corresponding rule for
the identified traffic. This is the same behavior for AppQoS functionality in Junos OS
releases prior to Release 18.2R1.
• AppQoS rule with a unified policy—In the application traffic control configuration, the
AppQoS rule set is configured with the match condition as application-any and in the
unified policy, a specific dynamic application is used as the match condition, then, the
AppQoS functionality works according to the rule in the unified policy.
Understanding Default Application Quality of Service Rule Set for Unified Policies
You can configure an AppQoS default rule set to manage security policy conflicts.
The initial policy lookup phase occurs prior to identifying a dynamic application. If there
are multiple policies present in the potential policy list that contain different AppQoS
rule sets, then the SRX Series device applies the default AppQoS rule set until a more
explicit match has occurred.
You can set an AppQoS as a default AppQoS rule set under the edit security ngfw hierarchy
level. The default AppQoS rule set is leveraged from one of the existing AppQoS rule
sets, which are configured under the [edit class-of-service application-traffic-control]
hierarchy level.
Table 7 on page 120 summarizes the usage of the default AppQoS rule set under different
scenarios in a unified policy.
Application
Identification
Status AppQoS Rule Set Usage Action
No security policy The AppQoS rule set under the [edit AppQoS is applied as in the AppQoS rule set.
conflict. class-of-service application-traffic-control]
hierarchy is applied when the traffic matches the
security policy.
Security policy The default AppQoS rule set is not configured or Session is ignored because the default AppQoS
conflict and is not found. profile is not configured.
conflicting polices
have distinct As a result, even if the final matched policy in the
AppQoS rule sets. policy conflict scenario has an AppQoS rule set, this
rule set is not applied. We recommend configuring
a default AppQoS rule set to manage security policy
conflicts.
The default AppQoS rule set is configured. AppQoS is applied as in the default AppQoS rule
set.
Final application is The matching security policy has an AppQoS rule AppQoS is applied as in the default AppQoS rule
identified set, which is same as the default AppQoS rule set. set.
The matching security policy does not have an Default AppQoS rule set is not applied and AppQoS
AppQoS rule set. is not applied for the session.
The Matching security policy has an AppQoS rule Default AppQoS rule set remains as the default
set different from the default AppQoS rule set, AppQoS rule set.
which is already applied.
When a default AppQoS rule set is applied on the traffic and the final security policy has
a different AppQoS rule set, in such cases switching from the default AppQoS rule set
to the AppQoS rule set in the final security policy is not supported.
The following links are to examples that discuss the default AppQoS rule sets in different
scenarios:
• No Policy Conflict—All Policies Have the Same AppQoS Rule Set on page 121
• No Policy Conflict—All Policies Have the Same AppQoS Rule Set and the Final Policy
Has No AppQoS Rule Set on page 121
• Policy Conflict—No AppQoS Rule Set is Configured for the Final Policy on page 122
• Policy Conflict—Default AppQoS Rule Set and a Different AppQoS Rule Set for the
Final Policy on page 122
Table 8 on page 121 shows different AppQoS rule sets that are configured for unified
policies with dynamic applications as the match condition.
Source Destination
Security Source IP Destination IP Port Dynamic AppQoS
Policy Zone Address Zone Address Number Protocol Application Service Rule Set
In this example, any AppQoS rule sets (AppQoS-1, AppQoS-2, AppQoS-3) can be
configured as a default AppQoS rule set under the [security ngfw] hierarchy level. It is
not necessary for a default rule set to be part of a security policy configuration. Any
AppQoS rule set under the [edit class-of-service application-traffic-control] hierarchy
level can be assigned as the default AppQoS rule set.
All matching policies have the same AppQoS rule set as shown in Table 9 on page 121.
Source Destination
Security Source IP Destination IP Port Dynamic AppQoS
Policy Zone Address Zone Address Number Protocol Application Service Rule Set
In this scenario, the policies Policy-P1 and Policy-P2 have the same AppQoS rule set; that
is, AppQoS-1. The rule set AppQoS-1 is applied. Policy-P3 is not configured in this scenario.
If you have configured the rule set AppQoS-2 as the default rule set, it is not applied.
That’s because there is no conflict in the AppQoS rule sets in the conflicted policies
(Policy-P1 and Policy-P2).
No Policy Conflict—All Policies Have the Same AppQoS Rule Set and the Final Policy
Has No AppQoS Rule Set
All matching policies have the same AppQoS rule set as shown in Table 10 on page 121
and the final policy has no AppQoS rule set.
Table 10: All Matching Policies Have Same AppQoS Rule Sets and the Final Policy Has No AppQoS Rule Set
Source Destination
Security Source IP Destination IP Port Dynamic AppQoS
Policy Zone Address Zone Address Number Protocol Application Service Rule Set
Table 10: All Matching Policies Have Same AppQoS Rule Sets and the Final Policy Has No AppQoS Rule
Set (continued)
Source Destination
Security Source IP Destination IP Port Dynamic AppQoS
Policy Zone Address Zone Address Number Protocol Application Service Rule Set
In this scenario, both Policy-P1 and Policy-P2 have the same AppQoS rule set, that is,
AppQoS-1. In this case, the rule set AppQoS-1 is applied.
When the final policy Policy-P3 is matched, AppQoS ignores the session, because the
AppQoS rule set is not configured for Policy-P3.
If the final security policy does not have any AppQoS rule set, then AppQoS is not applied
on the traffic. All AppQoS settings that are applied in the prematch stage are reverted
to the original values.
Policy Conflict—No AppQoS Rule Set is Configured for the Final Policy
The default AppQoS rule set (in this scenario AppQoS-1) is applied during the potential
policy match as shown in Table 11 on page 122. The final policy Policy-P3 has no AppQoS
rule set.
Table 11: Matching Policies Have Different AppQoS Rule Sets and the Final Policy Has No AppQoS Rule Set
Source
Security Source IP Destination Destination Port Dynamic AppQoS
Policy Zone Address Zone IP Address Number Protocol Application Service Rule Set
AppQoS ignores the session if the final matching policy Policy-P3 is applied.
If the final security policy does not have any AppQoS rule set, then AppQoS is not applied
on the traffic. In this case, all AppQoS settings that are applied in the prematch stage
are reverted to the original values.
Policy Conflict—Default AppQoS Rule Set and a Different AppQoS Rule Set for the Final
Policy
The rule set AppQoS-1 is configured as a default rule set and is applied when the final
application is not yet identified. The final policy Policy-P3 has a different AppQoS rule
set (AppQoS-3) as shown in Table 12 on page 123.
Table 12: Different AppQoS Rule Set for the Final Policy
Source
Security Source IP Destination Destination Port Dynamic AppQoS
Policy Zone Address Zone IP Address Number Protocol Application Service Rule Set
When the final application is identified, the policy Policy-P3 is matched and applied. In
this case, the rule set AppQoS-3 is not applied. Instead the rule set AppQoS-1 is applied
as the default rule set and remains as the default rule set.
When a security policy is applied to the matching traffic, the AppQoS rule set is applied
to the permitted traffic. If the security policy and the applied AppQoS rule set have
different dynamic applications, then a conflict might occur as shown in the following
example:
user@host# set security policies from-zone trust to-zone untrust policy 1 match
source-address any
user@host# set security policies from-zone trust to-zone untrust policy 1 match
destination-address any
user@host# set security policies from-zone trust to-zone untrust policy 1 match
application any
user@host# set security policies from-zone trust to-zone untrust policy 1 match
dynamic-application junos:FTP
user@host# set security policies from-zone trust to-zone untrust policy 1 then permit
application-services application-traffic-control rule-set AQ2
In this example, the application traffic control rule is configured for junos:GOOGLE and
the security policy match condition for the dynamic application is junos: FTP. In such
cases, conflicts might occur when the final policy is applied.
Requirements
• SRX Series device running Junos OS Release 18.2R1 and later. This configuration example
is tested for Junos OS Release 18.2R1.
Overview
In this example, you configure an AppQoS rule set and invoke AppQoS as an application
service in the security policy for the Facebook application.
You define a default AppQoS rule set under the [edit security ngfw] hierarchy level to
manage security policy conflicts, if any.
Configuration
[edit]
user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1
match application junos:FACEBOOK-APP
user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then
forwarding-class fc-appqos loss-priority medium-low dscp-code-point 101110 log
user@host# set class-of-service application-traffic-control rule-sets RS1 rule 1 then
rate-limit client-to-server Ratelimit1
user@host# set class-of-service application-traffic-control rate-limiters Ratelimit1
bandwidth-limit 1000
2. Configure a default AppQoS rule set. Select the rule set RS1 that is created under
the application traffic control as the default AppQoS rule set.
[edit]
user@host# set security ngfw default-profile application-traffic-control rule-set
RS1
[edit]
user@host# set security policies from-zone untrust to-zone trust policy from_internet
match source-address any
user@host# set security policies from-zone untrust to-zone trust policy from_internet
match destination-address any
user@host# set security policies from-zone untrust to-zone trust policy from_internet
match application any
user@host# set security policies from-zone untrust to-zone trust policy from_internet
match dynamic-application junos:FACEBOOK-APP
user@host# set security policies from-zone untrust to-zone trust policy from_internet
then permit application-services application-traffic-control rule-set RS1
Results From configuration mode, confirm your policy configuration by entering the show security
policies command. If the output does not display the intended configuration, repeat the
instructions in this example to correct the configuration.
For brevity, this show command output includes only the configuration that is relevant
to this example. Any other configuration on the system has been replaced with ellipses
(...).
...
policies {
from-zone trust to-zone untrust {
policy permit-all {
match {
source-address any;
destination-address any;
application any;
dynamic-application junos:FACEBOOK-APP;
}
then {
permit {
application-services {
application-traffic-control {
rule-set RS1;
}
}
}
}
}
}
}
...
ngfw {
default-profile {
application-traffic-control {
rule-set RS1;
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Action From operational mode, enter the show class-of-service application-traffic-control counter
command.
Sample Output
pic: 0/0
Counter type Value
Sessions processed 2
Sessions marked 1
Sessions honored 1
Sessions rate limited 1
Client-to-server flows rate limited 0
Server-to-client flows rate limited 1
Session default ruleset hit 1
Session ignored no default ruleset 1
Meaning The output displays the number of sessions processed, marked, and honored. The
rate-limiting statistics count the number of directional session flows that have been rate
limited.
pic: 0/0
Ruleset Rule Hits
RS1 1 1
Meaning The output provides information on the number of sessions matched for the rule under
each AppQoS rule set.
Starting with Junos OS Release 15.1X49-D60, SRX Series Services Gateways support
advanced policy-based routing (APBR) to address these challenges.
Application Identification
SRX Series devices support application identification (AppID) using deep packet
inspection (DPI) technology. Junos OS application identification recognizes Web-based
and other applications and protocols at different network layers using characteristics
other than port number. Applications are identified by using a protocol bundle containing
application signatures and parsing information. The identification is based on protocol
parsing and decoding and session management. An application system cache (ASC) is
maintained, where the applications identified are cached based on server (destination)
IP address and port and logical system identification.
ASC saves the mapping between an application type and the corresponding destination
IP address, destination port, protocol type, and service. Once an application is identified,
its information is saved in the ASC so that only one matching entry is required for an
application running on a particular system. When the cache entry is present and it is valid,
the identified application is picked from cache, thereby expediting the identification
process.
SRX Series devices support filter-based forwarding, also known as policy-based routing
(PBR), in which data packets are forwarded and routed based on the defined policies or
filters. PBR includes a mechanism for selectively applying policies based on access list,
packet size, or other criteria and routing the packets on user-defined routes.
When a device receives a packet, it routes the packets based on the information present
in the packet header such as destination port, source IP address, and incoming interfaces.
While processing an incoming packet, the device performs a routing table lookup to find
the appropriate interface that leads to the destination address.
However, in some cases, you might need to forward the packet based on other criteria.
In filter-based forwarding, you must create a filter that will match the type of traffic that
you are going to direct to a different next hop. You can define matching criteria such as
IP address, port, protocol, TCP flags, and much more. Once you have defined your term
to include the match criteria, the action will be to send the traffic to an appropriate route
and corresponding interface.
For example, perhaps you want to offer services to your customers, and the services
reside on different servers. You can use filter-based forwarding to send traffic to the
servers by applying a match condition in the packet header such as destination port,
source IP address, and incoming interfaces, and send the packets to a certain outgoing
interface that is associated with the appropriate server.
APBR implements:
• Lookup in ASC for application type and the corresponding destination IP address,
destination port, protocol type, and service for a matching rule
If a matching rule is found, the traffic is directed to an appropriate route and the
corresponding interface or device.
Benefits of APBR
• Provides more flexible traffic-handling capabilities and offers granular control for
forwarding packets based on application attributes.
• Associate a routing instance with the application profile rule. When the traffic on the
ingress zone and interface matches an application profile, the associated static route
and next hop defined in the routing instance is used to route the traffic for the particular
session.
• Associate the application profile to the ingress traffic The application profile can be
attached to a security zone or it can be attached to a specific logical or physical interface
associated with the security zone. If the application profile is applied to a security zone,
then all interfaces belonging to that zone are attached to the application profile by
default unless a specific configuration already exists for that interface.
Figure 2 on page 130 shows the sequence in which APBR techniques are applied.
1. APBR evaluates the packets based on incoming interface to determine if the session
is candidate for application-based routing. If the traffic has not been flagged for
application-based routing, it undergoes normal processing (non-APBR route).
2. If the session needs application-based routing, APBR queries the application system
cache (ASC) module to get the application attributes details (IP address, destination
port, protocol type, and service).
If the ASC is found, it is further processed for a matching rule in the APBR profile (see
Step 3). If the ASC is not found and the application signature is installed and ASC is
enabled, application identification for the session is enabled so that ASC can be
populated for use by subsequent sessions for the destination tuple.
3. APBR uses the application details to look for a matching rule in the APBR profile
(application profile). If a matching rule is found, the traffic will be redirected to the
specified routing instance for the route lookup.
Starting with Junos OS Release 15.1X49-D110 and Junos OS Release 17.4R1, SRX Series
Services gateways support advanced policy-based routing (APBR) with an additional
enhancement to apply the APBR in the middle of a session (which is also known as
midstream support). With this enhancement, you can apply APBR for a non-cacheable
application and also for the first session of the cacheable application. The enhancement
provides more flexible traffic-handling capabilities that offer granular control for
forwarding packets.
Figure 3 on page 131 shows the sequence in which APBR techniques with midstream
support are applied.
APBR profile
is created
and attached to
a security zone.
Is
advanced
Incoming packet policy-based NO
(new session) routing is
required?
YES
2
Enable application
Is ASC lookup NO identification for
successful? the session.
YES
3
Enable application
Is ASC match NO identification for
final? the session.
YES
YES
5
g043622
to route the packet to
the destination.
Step 1: APBR evaluates the packets based on incoming security zone to determine if
the session is candidate for application-based routing. If this is first packet of the new
session and traffic is not flagged for application-based routing, it undergoes normal
processing (non-APBR route) step 6.
Step 2: If the session needs application-based routing, APBR queries the application
system cache (ASC) module to get the application attributes details (IP address,
destination port, protocol type, and service). If the ASC is found, it is further processed
to determine if the application match using ASC is final (see Step 3). APBR could also
identify applications using ALG for the data sessions. If the application is matched
using the ALG it is considered as final match. If the final application has not been
identified, the DPI engine is engaged for the session to identify the application. The
existing session undergoes normal processing (non-APBR route) step 6.
Step 3: If an application has been identified, it is further processed for a matching rule
in the APBR profile (see Step 4).
Step 4: APBR uses the application details to look for a matching rule in the APBR
profile (application profile). If a matching rule is found, the traffic will be redirected
to the specified routing instance for the route lookup. If matching rule is not found, it
undergoes normal processing (non-APBR route) (see step 6).
Step 5: Traffic is routed through the specified routing instance for the destination.
Step 6: Traffic traverses through a default route (non-APBR route) to the destination.
For a new session, when application cannot be identified based on first packet information
the traffic traverses through a default route (non-APBR route) to the destination. At the
same time, APBR is applied and the rest of the session packets passes through the route
as per the rules defined in the APBR profile. This means that, APBR rules are applied as
and when an application is identified by AppID. For first packet of session, always go
through midstream re-routing case. That is, when the application is not yet identified,
the traffic traverses through a default route (non-APBR route) to the destination. At the
same time, application identification is enabled for that session. This continues still
application signatures identify the application and APBR is applied and the rest of the
session packets passes through the route as per the rules defined in the APBR profile.
The traffic traverses through a non-APBR route till application signatures or ALG identify
the application.
You can enable, AppTrack to inspect traffic and collect statistics for application flows
in the specified zone. See “Understanding AppTrack” on page 93 for more details.
You can streamline the traffic handling with APBR by using the following options:
• Limit route change- Some sessions go through continuous classification in the middle
of the session as application signatures identify the application. Whenever an
application is identified by the application signatures, APBR is applied, and this results
in a change in the route of the traffic. You can limit the number of times a route can
change for a session by using the max-route-change option of the tunables statement.
Example:
[edit]
set security advance-policy-based-routing tunables max-route-change 5
In this example, you want to limit the number of route changes per session to 5. When
there is a change in the route in the middle of the session, this count is reduced to 4.
This process continues until the count reaches 0. After that, APBR is not applied in the
middle of the session.
If an identified application has an entry in the ASC, then, the count is not reduced for
that session, because the session started with the specified route according to the
APBR configuration.
behavior, you can terminate the session entirely, instead of allowing traffic to traverse
through the same route bypassing APBR, by using the drop-on-zone-mismatch option
of the tunables statement.
Example:
[edit]
set security advance-policy-based-routing tunables drop-on-zone-mismatch
• Enable logging—You can enable logging to record events that occur on the device, for
instance, when APBR is bypassed because of a change in the zones for interfaces. You
can use the enable-logging option of the tunables statement to configure the logging.
Example:
[edit]
set security advance-policy-based-routing tunables enable-logging
• Enable reverse reroute—For deployments that requires traffic symmetry for ECMP
routes, and the incoming traffic needs to switch in the middle of session, the rerouting
can be achieved using the option enable-reverse-reroute specific to a security zone as
follows:
Example:
[edit]
When the above configuration is enabled for a security zone, where an incoming packet
arrives on an interface and has a different outgoing/return interface, a change in the
interface is detected and triggers a reroute. A route lookup is performed for the reverse
path, and the preference will be given to the interface on which the packet has arrived.
Further processing stops for a particular session when a route lookup fails for the traffic
on reverse path.
Use Case
• APBR can be used for selecting high-bandwidth, low-latency links for important
applications, when more than one link is available.
• APBR can be used for creating a fallback link for important traffic in case of link
failure. When multiple links are available, and the main link carrying the important
application traffic suffers an outage, then the other link configured as the fallback
link can be used to carry traffic.
• APBR can be used for segregating the traffic for deep inspection or analysis. With
this feature, you can classify the traffic based on applications that are required to
go through deep inspection and audit. If required, such traffic can be routed to a
different device.
Limitations
• Redirecting the route for the traffic depends on the presence of an entry in the
application system cache (ASC). Routing will succeed only if the ASC lookup is
successful. For the first session, when the ASC is not present for the traffic, the traffic
traverses through a default route (non-APBR route) to the destination (this limitation
is applicable only for the releases before Junos OS 15.1X49-D110).
• APBR does not work if an application signature package is not installed or application
identification is not enabled.
• APBR does not work for Layer 3 and Layer 4 applications, because the Layer 3 and
Layer 4 applications custom signatures are not maintained in the ASC.
• APBR does not work for data sessions initiated by an entity from the control session,
such as active FTP.
• When using different NAT pools for source NAT and midstream APBR is applied, the
source IP address of the session continues to be the same as the one with which the
session has been using before applying the midstream APBR.
• APBR with midstream support works only when all egress interfaces are in the same
zone. Because of this, only the forwarding and virtual routing and forwarding (VRF)
routing instances can be used to avail APBR midstream support.
See Also • Example: Configuring Advanced Policy-Based Routing for Application-Aware Traffic
Management Solution on page 134
Requirements
• SRX Series device with Junos OS Release 15.1X49-D60 or later. This configuration
example is tested for Junos OS Release 15.1X49-D60.
Overview
In this example, you want to forward HTTP, social networking, and Yahoo traffic arriving
at the trust zone to a specific device or interface as specified by the next-hop IP address.
When traffic arrives at the trust zone, it is matched by the APBR profile, and if a matching
rule is found, the packets are forwarded to the static route and next hop as specified in
the routing instance. The static route configured in the routing table is inserted into the
forwarding table when the next-hop address is reachable. All traffic destined for the
static route is transmitted to the next-hop address for transit to a specific device or
interface.
Figure 4 on page 135 shows the topology used in this configuration example.
1.0.0.1
Service Provider
Network
1.0.0.254
192.168.2.1
192.168.1.1
ge-0/0/1.0 ge-0/0/1.0
ge-0/0/0.0 ge-0/0/0.0
192.168.1.254 192.168.2.254
SRX Series ge-0/0/2.0 ge-0/0/2.0 SRX Series
Client
Customer Premise Corporate Server
2.0.0.254
Service Provider
Network
2.0.0.1
Table 13 on page 135 provides the details of the parameters used in this example.
NOTE:
To use the APBR for redirecting the traffic based on applications, importing
interface routes might be required from one routing instance to another
routing instance. You can use one of the following mechanisms:
When you use routing policy to import interface routes, it might cause
management local routes (using fxp0) to leak to non-default routing instance,
if the appropriate action is not used for the routing policy. When devices are
in chassis cluster mode, such scenarios might result in RG0 failover due to
limitations. We recommend not configure fxp0 local route in the routing table
of non-default routing instance. Following sample depicts a sample
configuration of policy options. Note that the reject action helps in eliminating
the routes that are not required. You can use specific routes to reject the fxp0
routes.
policy-statement statement-name {
term 1 {
from {
instance master;
route-filter route-filter-ip-address exact;
}
then accept;
}
then reject;
}
NOTE: APBR is used for routing the packets in a forward path. For return
traffic to arrive over the same path, we recommend to configure the remote
SRX Series device with ECMP configuration along with load balance routing
policy as shown in the following sample configuration:
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration 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.
[edit]
user@host# set routing-instances R1 instance-type forwarding
user@host# set routing-instances R1 routing-options static route 1.0.0.254/8
next-hop 1.0.0.1
user@host# set routing-instances R2 instance-type forwarding
user@host# set routing-instances R2 routing-options static route 2.0.0.254/8
next-hop 2.0.0.1
2. Group one or more routing tables to form a RIB group called apbr_group and import
routes into the routing tables.
[edit]
set routing-options interface-routes rib-group inet apbr_group
set routing-options rib-groups apbr_group import-rib inet.0
set routing-options rib-groups apbr_group import-rib RI1.inet.0
set routing-options rib-groups apbr_group import-rib RI2.inet.0
[edit]
user@host# set security advance-policy-based-routing profile profile1 rule rule-app1
match dynamic-application junos:HTTP
user@host# set security advance-policy-based-routing profile profile1 rule rule-app1
then routing-instance R1
user@host# set security advance-policy-based-routing profile profile1 rule rule-app2
match dynamic-application-group junos:web:social-networking
user@host# set security advance-policy-based-routing profile profile1 rule rule-app2
then routing-instance R2
[edit]
user@host# set security zones security-zone trust host-inbound-traffic
system-services all
user@host# set security zones security-zone trust host-inbound-traffic protocols
all
user@host# set security zones security-zone trust interfaces ge-0/0/1.0
user@host# set security zones security-zone trust interfaces ge-0/0/2.0
user@host# set security zones security-zone trust
advance-policy-based-routing-profile profile1
Results
[edit]
user@host# show routing-instances
R1 {
instance-type forwarding;
routing-options {
static {
route 1.0.0.254/8 next-hop 1.0.0.1;
}
}
}
R2 {
instance-type forwarding;
routing-options {
static {
route 2.0.0.254/8 next-hop 2.0.0.1;
}
}
}
[edit]
user@host# show routing-options
interface-routes {
rib-group inet apbr_group;
}
rib-groups {
apbr_group {
import-rib [ inet.0 RI1.inet.0 RI2.inet.0 ];
}
}
[edit]
user@host# show security advance-policy-based-routing
profile profile1 {
rule rule-app1 {
match {
dynamic-application junos:HTTP;
}
then {
routing-instance R1;
}
}
rule rule-app2 {
match {
dynamic-application-group junos:web:social-networking;
}
then {
routing-instance R2;
}
}
}
[edit]
user@host# show security zones
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/1.0;
ge-0/0/2.0;
}
advance-policy-based-routing-profile {
profile1;
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Purpose Display the statistics for APBR such as the number of sessions processed for the
application-based routing, number of times the APBR is applied for the session, and so
on.
Action From configuration mode, enter the show security advance-policy-based-routing statistics
command.
• The number of times the application traffic matches the APBR profile and APBR is
applied for the session.
Purpose Display information about the sessions and packet flows active on the device, including
detailed information about specific sessions.
Action From configuration mode, enter the show security flow session command to display
information about all currently active security sessions on the device.
• Security attributes associated with a flow, for example, the policies that apply to traffic
belonging to that flow
• Session timeout value, when the session became active, how long the session has
been active, and if there is active traffic on the session
This enhancement provides more flexible traffic-handling capabilities that offer granular
control for forwarding packets.
If one or more APBR policy is configured for the security zone, then the policy is evaluated
during session creating phase. The policy lookup is terminated once the policy, matching
the session, is selected. After a successful match, the APBR profile configured with the
APBR policy is used for the session.
APBR policies are defined for a security zone. If there is one or more APBR policy
associated with a zone, the session that is initiated from the security zone goes through
the policy match.
The following sequences are involved in matching the traffic by an APBR policy and
applying advanced policy-based routing to forward the traffic, based on the defined
parameters/rules:
• When traffic arrives at the ingress zone, it is matched by the APBR policy rules. The
policy match condition include the source address, destination address and application.
• When the traffic matches the security policy rules, the action of the APBR policy is
applied to the traffic. You can enable APBR as an application service in the APBR policy
action by specifying the APBR profile name.
• The APBR profile configuration incudes the set of rules that contains set of dynamic
applications and dyamic application groups as match condition. The action part of
those rules contain the routing instance through which traffic needs to be forwarded.
The routing instance can include configuration of static routs or dynamic learned routes.
• All traffic destined for the static route is transmitted to the next-hop address for transit
to a specific device or interface.
APBR policy rules are terminal, which means that once the traffic is matched by a policy,
it is not processed further by the other policies.
If an APBR policy has the matching traffic and APBR profile does not have any traffic
matching the rule, then the traffic matching the APBR policy traverses through a default
routing-instance [inet0] to the destination.
Prior to the Junos OS Release 18.2R1, APBR profile was applied at security zone-level.
With the support for APBR policy, APBR configuration at security-zone level is deprecated
future, rather than being immediately removed in order to provide backward compatibility
and a chance to bring your configuration into compliance with the new configuration.
However, if you have configured a zone-based APBR, and you attempt to add an APBR
policy for the particular security zone, commit might fail. You must delete the zone-based
configuration in order to configure the APBR policy for the zone. Similarly if an APBR
policy is configured for a security zone, and you attempt to configure zone-based APBR,
results in commit error.
Limitation
• When using specific address or address set in the APBR policy rule, we recommend to
use the global address book. Because, zone specific rules might not be applicable for
destination address, as the destination zone is not known at time of policy evaluation.
• Configuring APBR policy for the security zone junos-host zone is not supported.
Requirements
• SRX Series device with Junos OS Release 18.2R1 or later. This configuration example
is tested on Junos OS Release 18.2R1.
Overview
In this example, you want to forward HTTP traffic arriving at the trust zone to a specific
device or interface as specified by the next-hop IP address.
When traffic arrives at the trust zone, it is matched by the APBR policy. When the traffic
matches the policy, the configured APBR rule is applied on the permitted traffic as
application services. The packets are forwarded based on the APBR rule to the static
route and next hop as specified in the routing instance. The static route configured in the
routing table is inserted into the forwarding table when the next-hop address is reachable.
All traffic destined for the static route is transmitted to the next-hop address for transit
to a specific device or interface.
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration 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.
[edit]
user@host# set routing-instances R1 instance-type forwarding
user@host# set routing-instances R1 routing-options static route 5.0.0.0/24
next-hop 3.0.0.2
2. Group one or more routing tables to form a RIB group called apbr_group and import
routes into the routing tables.
[edit]
user@host# set routing-options interface-routes rib-group inet fbf-group
user@host# set routing-options rib-groups fbf-group import-rib inet.0
user@host# set routing-options rib-groups fbf-group import-rib RI1.inet.0
[edit]
user@host# set security advance-policy-based-routing profile profile1 rule rule-app1
match dynamic-application junos:HTTP
user@host# set security advance-policy-based-routing profile profile1 rule rule-app1
then routing-instance R1
[edit]
user@host# set security zones security-zone trust host-inbound-traffic
system-services all
user@host# set security zones security-zone trust host-inbound-traffic protocols
all
user@host# set security zones security-zone trust interfaces ge-0/0/1.0
5. Create an APBR policy and apply the APBR profile to the security zone.
[edit]
user@host# set security advance-policy-based-routing from-zone trust policy SLA1
match source-address any
user@host# set security advance-policy-based-routing from-zone trust policy SLA1
match destination-address any
user@host# set security advance-policy-based-routing from-zone trust policy SLA1
match application any
user@host# set security advance-policy-based-routing from-zone trust policy SLA1
then application-services advance-policy-based-routing-profile profile1
Results
[edit]
user@host# show routing-instances
R1 {
instance-type forwarding;
routing-options {
static {
route 5.0.0.0/24 next-hop 3.0.0.2;
}
}
}
[edit]
user@host# show routing-options
interface-routes {
rib-group inet fbf_group;
}
rib-groups {
fbf_group {
import-rib [ inet.0 RI1.inet.0];
}
}
[edit]
user@host# show security advance-policy-based-routing
from-zone trust {
policy SLA1 {
match {
source-address any;
destination-address any;
application any;
}
then {
application-services {
advanced-policy-based-routing-profile profile1;
}
}
}
}
profile profile1 {
rule rule-app1 {
match {
dynamic-application junos:HTTP;
}
then {
routing-instance R1;
}
}
}
[edit]
user@host# show security zones
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/1.0;
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Purpose Display the statistics for APBR such as the number of sessions processed for the
application-based routing, number of times the APBR is applied for the session, and so
on.
Action From configuration mode, enter the show security advance-policy-based-routing statistics
command.
Rule matches 0
Route changed on cache hits 0
Route changed midstream 0
Zone mismatch 0
Drop on zone mismatch 0
Next hop not found 0
• The number of times the application traffic matches the APBR profile and APBR is
applied for the session.
Purpose Display information about the APBR policy, associated APBR profile and to display
information about the APBR policy hit count.
Number of policy: 3
• Display the utility rate of policies according to the number of hits they receive.
17.4 Starting with Junos OS Release 15.1X49-D110 and Junos OS Release 17.4R1,
SRX Series Services gateways support advanced policy-based routing
(APBR) with an additional enhancement to apply the APBR in the middle
of a session (which is also known as midstream support)
15.1X49-D60 Starting with Junos OS Release 15.1X49-D60, SRX Series Services Gateways
support advanced policy-based routing (APBR)
The relentless growth of cloud computing, mobility, and Web-based applications, requires
that the network identify and control the traffic at the application level, and handle each
application type separately to provide quality of experience (QoE) for users. To ensure
application-specific QoE (AppQoE), you need to effectively prioritize, segregate, and
route application traffic without compromising performance or availability.
AppQoE utilizes (or employs) the capabilities of two application security services -
application identification (AppID) and advanced policy-based routing (APBR). It uses
AppID to identify specific applications in your network and advanced policy-based routing
(APBR) to specify a path for certain traffic by associating SLA profiles to a routing instance
on which the application traffic is sent as per APBR rules.
AppQoE monitors the performance of business- critical applications, and based on the
score, selects the best possible link for that application traffic in order to meet
performance requirements specified as in SLA (service-level agreement).
The presence of an SLA rule in the APBR configuration triggers the AppQoE functionality;
If there are no SLA profiles available, the APBR functions without triggering AppQoE.
You can configure an AppQoE SLA service between two SRX Series device endpoints
(book-ended) and both SRX Series devices must have the same version of the Junos OS
image.
You can configure vSRX instances, SRX300 line devices, SRX550M as spoke devices
and SRX1500, SRX4100 and SRX4200 as hub devices.
• Increases customer retention and satisfaction by providing a guaranteed SLA for the
delivery of the certain traffic (such as video traffic). AppQoE ensures that the approved
traffic receives the appropriate priority, and bandwidth required to ensure the best
quality of experience to the user.
• Mesh networks—In a mesh configuration, an SRX Series device at the branch office or
remote site is configured to connect directly to any other SRX Series device in the
network that is also part of mesh.
Limitations
• All the different routes to the destination through different interfaces must have the
same preference, weight, and metrics configured. All routes must be added as ECMP
paths for the destination and must also be part of the same forwarding table.
• AppQoE SLA service only between two SRX Series devices endpoints (book-ended)
are supported. End-to-end AppQoE SLA service is not supported.
• AppQoE can be applied only if all interfaces are part of the same zone.
• AppQoE does not support IPv6/UDP probe encapsulation, GRES, chassis cluster (ISSU,
high-availability, dual CPE high availability, Z-mode high availability), and logical
systems.
• AppQoE does not support preferred path selection and transit virtual routing and
forwarding (VRF) are not supported.
• An input firewall filter is required at the non-WAN interfaces to discard UDP packets
with UDP destination port 36000.
This section includes some of the terminologies used in understanding about how AppQoE
works.
• SLA rule—An SLA rule includes all required information to measure SLA and to identify
whether any SLA violation has occurred or not. It contains the complete probe profiles,
period at which profile need to be sent, preferred SLA configuration and so on.
• SLA options—By using SLA options, you can specify that applications be seamlessly
diverted to the alternate path if the performance of the primary link is below acceptable
levels as specified by the SLA.
• SLA metrics profile — Defines the SLA metrics requirements parameters, which are
used by AppQoE to evaluate the SLA of the link. The metric profile includes parameters
such as jitter, jitter type, packet loss, round trip delay and so on.
• SLA violations—To accomplish an SLA, AppQoE monitors the network for sources of
failures or congestion. If the performance of a link is below acceptable levels as specified
by the SLA, the situation is considered as an SLA violation and an alternate path is
determined to select the best link that satisfies the SLA.
• Active and passive probes—Active and passive probe measurements are used for an
end-to-end analysis of the network. The data collected by active and passive probing
is used for monitoring the network for sources of failures or congestion. If there is a
violation detected for any application, the synthetic probe metrics are evaluated to
determine the best link that satisfies the SLA.
• Overlay path—an overlay path includes the overlay links that are used to send the
application traffic. Application or application groups are assigned to a particular overlay
link based on the SLA metrics of that overlay link.
AppQoE monitors the performance of applications, and based on the score, selects the
best possible link for that application traffic in order to meet performance requirements
specified as in SLA (service-level agreement).
2. APBR evaluates the packets based to determine if the session is candidate for
application-based routing (advance policy-based routing). If this is first packet of the
new session and traffic is not flagged for application-based routing, it undergoes
normal processing (non-APBR route) to destination.
3. If the session needs application-based routing, APBR queries the ASC module to get
the application attributes (IP address, destination port, protocol type, and service).
4. • If the application in ASC is found, traffic is further processed for a matching rule in
the APBR profile.
• If a matching rule is found, the traffic is redirected to the specified routing instance
for the route lookup.
• If SLA is not enabled for the session in the APBR rule, the AppQoE ignores that
session and the default behavior of APBR is applied to those sessions—that is,
traffic is routed through the specified routing instance for the destination.
• If a matching rule is not found, traffic traverses through a default route (non-APBR
route) to the destination.
• If the application in is not found in ASC, APBR requests for deep inspection of the
flow. that is, application signature package is installed and application identification
for the session is enabled, so that ASC can be populated for use by subsequent
sessions for APBR processing (see step 2).
The following steps summarize how AppQoE specifies a path for the application traffic
according to the SLA rules.
1. APBR uses the application details to look for a matching rule in the APBR profile
(application profile). Traffic matching the applications and application groups, are
forwarded to the static route and the next-hop address as specified in the routing
instance.
2. An SLA rule attached to the APBR profile specifies parameters, that are required to
measure the SLA and to identify whether any SLA violation has occurred or not.
3. The applications traffic is assigned to a particular overlay link based on the SLA metrics
of that overlay link measured using active probing.
The following steps take place for routing data traffic from source to destination,
specifically, to select the best path,
• For the first data packet of a flow (first path), if the application is already known (from
the ASC lookup), then the best path for the application is searched in the database. If
the application is not known or is new (from ASC lookup), then a random path or the
default path is chosen. This path continues for the entire session. Later, after the
application is detected by the DPI, the database is updated with the best path for the
application.
• For the remaining data packet of a flow (fast path), if the application is not known
initially, then the particular session continues on the same path. If the application is
known initially, then AppQoE selects the best path for the application traffic.
When a new application is detected, the path selection mechanism attempts to find a
path that satisfies all the SLA metrics. If no such path exists, then the next best path
(based on number of metrics satisfied) is used. If there are more than one path that
satisfies the metrics, a random path among the available paths is selected. The SLA
violation is detected when any one of the metric is violated or none of the metrics meets
the requirement, based on the profile configuration.
• RTT— A round-trip time required to travel from source to destination and vice versa.
• Packet loss—Packet loss reflects the number of packets lost per 100 of packets sent
by a host.
• Jitter—Jitter is the difference in the latency from packet to packet. Ingress jitter, egress
jitter, and two-way jitter can be specified for evaluating the performance of the link.
AppQoE monitors RTT, jitter, and packet loss on each link, and based on the score,
seamlessly diverts applications to the alternate path if performance of the primary link
is below acceptable levels as specified by SLA. Measurement and monitoring of
application performance is done using active and passive probes to detect SLA violations
and to select an alternate path for that particular application.
• Using passive probes (inline with the application datapath) and active probes (synthetic
probes for specific application) to monitor the traffic performance for application or
application group.
• Sending all collected performance metrics or metadata for analysis to a log collector.
AppQoE measures the application SLA across multiple WAN links, and maps the
application traffic to a path among the available links, that is, to the path that best serves
the SLA requirement.
Active and passive probe measurements are the two approaches used for end-to-end
analysis of the network.
• Active probe—Active probes measure the service quality of the application to provide
an end-to-end measurement of the network performance.
In active probing, custom packets are sent between spoke and hub points on all the
multiple routes and the RTT, latency, jitter, and packet-loss are measured between
the installed probe points. The active probes are sent periodically on all the active and
passive links. A configured number of samples is collected and a running average for
each such application’s probe path is measured. If there is a violation detected for any
application traffic, the probe metrics are evaluated to determine the best link that
satisfies the SLA.
• Passive probe—Passive probes are installed on links within the network, and they
monitor all the traffic that flows through those links.
Passive probing monitors links for SLA violations on live data traffic. In a passive probe,
the actual data packets are encapsulated in an IP/UDP probe header in the live traffic
between the SRX Series book-ended points, and RTT, jitter and packet loss between
the points of installation of the probes are measured to compute the service quality.
If there is a violation detected for any application, the synthetic probe metrics are
evaluated to determine the best link that satisfies the SLA.
You can configure an SLA rule with active and passive probe parameters and associate
the SLA rule with APBR profile. The APBR profile also includes a APBR rule. Rules are
associated with one or more than one application or application groups and the traffic
matching the rule is redirected to the routing instance
AppQoE triggers the probe requests to all probe paths of the application. Active and
passive probes monitor the network for areas or points of failures or congestion.
AppQoE collects traffic class statistics for learned applications using active and passive
probes and takes following actions:
1. Measure performance for SLA—The real-time metrics provided by probes are used
to score service quality according to the SLA for an application and determine whether
the application path does not meet SLA requirements. That is, if there is a violation
detected for any application, the synthetic probe metrics are evaluated to determine
the best alternate link for the application traffic that satisfies the SLA.
2. Reroute traffic—Switch the application traffic between the two links, that is, when
one link has performance issues, the traffic is routed to the other link during the same
session.
You can enable or disable switching of the application traffic to another route (local to
the device) during an SLA violation. When local route switching is enabled, switching of
the application traffic to an alternate route is enabled and the SLA monitoring and
reporting functionality is also available. Even when the option for switching of the
application traffic to an alternate path is disabled in the SLA rule configuration, AppQoE
resolves SLA violations---for example, by switching the application traffic to a new path
When local route switching is disabled, only SLA monitoring and reporting functionality
is available and switching of the application traffic to the different route because of an
SLA violation is tuned off.
When an application traffic switches to an alternative path, there will be a short time
period during which the application traffic cannot be switched again to another path in
case of SLA violation. This time period helps to avoid flapping of the traffic across links.
This example provides step-by-step procedures required for SRX Series devices to provide
the quality-of-experience (QoE) service using AppQoE. In this configuration, devices in
the network prioritize certain application traffic to enhance the user experience based
on service-level agreement (SLA).
Requirements
• Appropriate security policies to enforce rules for the transit traffic, in terms of what
traffic can pass through the device, and the actions that need to take place on the
traffic as it passes through the device.
• Enable application tracking support enabled for the zone. See Application Tracking.
• Supported SRX Series device with Junos OS Release 18.2 or later. This configuration
example is tested for Junos OS Release 18.2.
Overview
Figure 5 on page 156 shows the topology used in this configuration example.
T1
3.1.1.2 3.1.1.1
2.1.1.2 2.1.1.1
T2
SRX Series SRX Series
Client Spoke Hub App Server
1.1.1.2 1.1.1.1
g200251
T3
Table 14 on page 156 provides the details of the parameters used in this example.
APBR rule rule-app1 Define the rules for the APBR profile.
Associate the rule with one or more
rule-app2 than one application (example: for
HTTP, FTP, and SSH) or application
rule-app2 groups.
Probe
• Local IP addresses-
25.1.1.1
• Remote IP addresses-
25.1.1.10
path3
Tunnel
• Local IP addresses-
200.1.1.1
• Remote IP addresses-
250.1.1.1
Probe
• Local IP addresses-
225.1.1.1
• Remote IP addresses-
Destination Grouping destination-path-group-1 You can group all the overlay paths
terminating at the same destination
under a destination group. In this
example, you have a single
destination—that is, hub device. So,
all paths are configured under the
same destination group and all the
paths must be available in the routing
instance specific for active probing.
• When a traffic is identified for AppQoE, that traffic could be fragmented when the
packet size exceeds the supported MTU value with the additional encapsulation of
the probe header.
[edit]
user@hostset security flow tcp-mss ipsec-vpn mss 1200
user@hostset security flow tcp-mss all-tcp mss 1350
• The passive probe packet carries actual source and destination IP address of the client
packets. To allow the passive probe packets through the system, you must complete
the following configuration:
[edit]
user@hostset services application-identification application jun-appqoe priority high
user@hostset services application-identification application jun-appqoe
address-mapping addr1 filter port-range udp 36000
• You must create an appropriate security policy and application firewall policy to
support the above configuration.
NOTE: Passive probes generate application tracking log messages for session
create and session delete. Once the custom signature identifies these packets,
the message reports application as jun-appqoe.
Configuring AppQoE
Step-by-Step Configure APBR profiles for HTTP, FTP, and SSH applications traffic.
Procedure
1. Create routing instances.
2. Group one or more routing tables to form a RIB group and import routes into the
routing tables.
Step-by-Step 1. Create the set of metrics which AppQoE uses to evaluate the SLA of the link.
Procedure
user@host# set security advance-policy-based-routing metrics-profile metric1
sla-threshold jitter 5000
Step-by-Step Configure active probing to send custom packets between spoke device and hub device
Procedure on all routes to measure RTT, jitter, and packet loss between the points.
Step-by-Step Configure an overlay setup, which includes setting up both tunnel path and probe path,
Procedure between local and remote endpoint on both ends of the overlay (spoke device and hub
devices).
4. Group all the overlay paths terminating at a destination. Because there is a single
destination available—that is, the hub device— all paths must be configured under
the same destination group. All paths must be available in the routing instance
specific for active probing.
Step-by-Step Configure an SLA rule to measure the SLA and to identify any SLA violation has occurred
Procedure or not.
1. Configure the SLA rule, associate metrics profile, active probe parameter, and define
passive probe parameters.
Step-by-Step 1. Configure AppQoE as service. You must configure AppQoE as service for host
Procedure inbound traffic for a desired zone.
Results
From configuration mode, confirm your configuration by entering the show commands.
If the output does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit security]
user@host# show advance-policy-based-routing
profile apbr1 {
rule rule1 {
match {
dynamic-application [ junos:FTP junos:HTTP junos:SSH ];
}
then {
routing-instance appqoe;
sla-rule {
sla_rule1;
}
}
}
}
active-probe-params active_probes {
settings {
data-fill {
deadbead;
}
data-size {
100;
}
probe-interval {
10;
}
probe-count {
10;
}
burst-size {
10;
}
enable-sla-export {
600;
}
}
}
metrics-profile metrics_profile1 {
sla-threshold {
delay-round-trip {
4000;
}
jitter {
5000;
}
jitter-type {
two-way-jitter;
}
packet-loss {
50;
}
match {
all;
}
}
}
overlay-path overlay-path1 {
tunnel-path {
local {
ip-address {
1.1.1.2;
}
}
remote {
ip-address {
1.1.1.1;
}
}
}
probe-path {
local {
ip-address {
1.1.1.2;
}
}
remote {
ip-address {
1.1.1.1;
}
}
}
}
overlay-path overlay-path2 {
tunnel-path {
local {
ip-address {
2.1.1.2;
}
}
remote {
ip-address {
2.1.1.1;
}
}
}
probe-path {
local {
ip-address {
2.1.1.2;
}
}
remote {
ip-address {
2.1.1.1;
}
}
}
}
overlay-path overlay-path3 {
tunnel-path {
local {
ip-address {
3.1.1.2;
}
}
remote {
ip-address {
3.1.1.1;
}
}
}
probe-path {
local {
ip-address {
3.1.1.2;
}
}
remote {
ip-address {
3.1.1.1;
}
}
}
}
destination-path-group destination-path-group-1 {
probe-routing-instance {
abc;
}
overlay-path overlay-path1;
overlay-path overlay-path2;
overlay-path overlay-path3;
}
sla-rule sla_rule1 {
switch-idle-time {
60;
}
metrics-profile {
metrics_profile1;
}
active-probe-params {
active_probes;
}
passive-probe-params {
sampling-percentage {
25;
}
violation-count {
3;
}
sampling-period {
60000;
}
sla-export-factor {
60;
}
type {
book-ended;
}
}
}
[edit routing-instances]
user@host# show appqoe-vrf
routing-options {
static {
route 9.0.0.0/8 next-hop [ gr-0/0/0.0 gr-0/0/0.1 gr-0/0/0.2 ];
route 12.1.1.0/24 next-hop 22.1.1.2;
route 13.1.1.0/24 next-hop 23.1.1.2;
route 14.1.1.0/24 next-hop 24.1.1.2;
}
}
[edit routing-options]
user@host# show
rib-groups {
lanvrf {
import-rib [ lan-vrf.inet.0 inet.0 ];
}
}
forwarding-table {
export load-balancing-policy;
}
Action From operational mode, enter the show security advance-policy-based-routing sla version
command.
Meaning The command output displays the version of AppQoE. This information helps verify that
the SLA version on both hub device and spoke device is same.
Action From operational mode, enter the show security advance-policy-based-routing sla status
command.
Meaning The command output confirms that local switching is enabled. That is, switching of the
application traffic to another route (local to the device) during an SLA violations, is
enabled.
When local route switching is enabled, switching of application traffic to other route is
enabled and also SLA monitoring and reporting functionality is available. This configuration
selects the best possible link for that application traffic in order to meet performance
requirements as in the SLA.
Purpose Display the details of the SLA statistics based on APBR profile.
Action From operational mode, enter the show security advance-policy-based-routing sla statistics
command.
Meaning The command output displays the session details subjected to passive probe and active
probe.
Action From operational mode, enter the show security advance-policy-based-routing sla
command.
Meaning The command output samples help in understanding application details, APBR profile,
SLA rule, application status, SLA violations occurred, number of times application traffic
has switched route path, and monitored sessions.
Action From operational mode, enter the show security advance-policy-based-routing sla
active-probe-statistics active-probe-params-name command.
Meaning The output shows RTT, jitter and packet-loss measured between the installed probe
points.
SSL Proxy
SSL Proxy
SSL proxy acts as an intermediary, performing SSL encryption and decryption between
the client and the server. Better visibility into application usage can be made available
when SSL forward proxy is enabled. For more information, see the following topics:
SSL proxy is transparent; that is, it performs SSL encryption and decryption between the
client and the server.
Sharing server keys is sometimes not feasible or might not be available in certain
circumstances, in which case the SSL traffic cannot be decrypted. SSL proxy addresses
this problem by ensuring that it has the keys to encrypt and decrypt the payload:
• For the server, SSL proxy acts as a client—Because SSL proxy generates the shared
pre-master key, it determines the keys to encrypt and decrypt.
• For the client, SSL proxy acts as a server—SSL proxy first authenticates the original
server and replaces the public key in the original server certificate with a key that is
known to it. It then generates a new certificate by replacing the original issuer of the
certificate with its own identity and signs this new certificate with its own public key
(provided as a part of the proxy profile configuration). When the client accepts such
a certificate, it sends a shared pre-master key encrypted with the public key on the
certificate. Because SSL proxy replaced the original key with its own key, it is able to
receive the shared pre-master key. Decryption and encryption take place in each
direction (client and server), and the keys are different for both encryption and
decryption.
Figure 6 on page 173 shows how SSL proxy works on an encrypted payload. When
Advanced Security services such as application firewall (AppFW), Intrusion Detection
and Prevention (IDP),application tracking (AppTrack), UTM, and SkyATP is configured,
the SSL proxy acts as an SSL server by terminating the SSL session from the client and
establishing a new SSL session to the server. The SRX Series device decrypts and then
reencrypts all SSL proxy traffic. SSL proxy uses the following:
IDP, AppFW, AppTracking, advanced policy-based routing (APBR), UTM, SkyATP, and
ICAP service redirect can use the decrypted content from SSL proxy. If none of these
services are configured, then SSL proxy services are bypassed even if an SSL proxy profile
is attached to a firewall policy.
• Decrypts SSL traffic to obtain granular application information and enable you to apply
advanced security services protection and detect threats.
• Enforces the use of strong protocols and ciphers by the client and the server.
• Provides visibility and protection against threats embedded in SSL encrypted traffic.
Perfect Forward Secrecy (PFS) is a feature of specific key agreement protocols that
provides assurances your session keys will not be compromised even if the private key
of the server is compromised. By generating a unique session key for every session flow
a user initiates, the compromise of a single session key will not affect any data other than
that exchanged in the specific session protected by that particular key. For PFS to function,
the key used to protect transmission of data must not be used to derive any additional
keys, and if the key used to protect transmission of data was derived from some other
keying material, that material must not be used to derive any further keys.
ECDHE stands for Elliptic Curve Diffie Hellman Ephemeral and is a key exchange
mechanism based on elliptic curve cryptography. The ECDHE cipher suits are used to
enable the PFS on SSL proxy.
ECDHE cipher suits provide the same level of security as the RSA with smaller keys. SSL
proxy is targeted to support only ECDHE ciphers suites because they are less expensive
computationally than DHE ciphers.
Table 15 on page 174 provides the details of RSA keys supported on various SRX Series
devices.
SRX340, SRX345, SRX550, SRX1500, SRX4100, 512 bits, 1024 bits, 2048 bits, 4096 bits
SRX4200, SRX4600, SRX5400, SRX5600,
SRX5800
NOTE:
• Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1,
server certificates of key size 4096 bits are supported. Prior to Junos OS
Release 15.1X49-D30, server certificates with key size greater than 2048
bits were not supported because of cryptography hardware limitations.
Preferred Earliest
Ciphers Supported
Key Exchange Data Message Category Release
SSL Cipher Algorithm Encryption Integrity
ECDHE-RSA-AES256-GCM-SHA384 ECDHE/RSA key 256-bit SHA384 hash Strong Junos OS
exchange AES/GCM Release
15.1X49-D10
Preferred Earliest
Ciphers Supported
Key Exchange Data Message Category Release
SSL Cipher Algorithm Encryption Integrity
ECDHE-RSA-AES128-GCM-SHA256 ECDHE/RSA key 128-bit SHA256 hash Strong Junos OS
exchange AES/GCM Release
15.1X49-D10
RSA-RC4-128-MD5 RSA key exchange 128-bit RC4 Message Digest Medium Junos OS
5 (MD5) hash Release 12.1
RSA-RC4-128-SHA RSA key exchange 128-bit RC4 Secure Hash Medium Junos OS
Algorithm (SHA) Release 12.1
hash
RSA-DES-CBC-SHA RSA key exchange DES CBC SHA hash Week Junos OS
Release 12.1
RSA-3DES-EDE-CBC-SHA RSA key exchange 3DES EDE/CBC SHA hash Week Junos OS
Release 12.1
Preferred Earliest
Ciphers Supported
Key Exchange Data Message Category Release
SSL Cipher Algorithm Encryption Integrity
RSA-EXPORT-DES40-CBC-SHA RSA-export 40-bit DES/CBC SHA hash Week Junos OS
Release 12.1
RSA-EXPORT-1024-RC4-56-MD5 RSA 1024 bit 56-bit RC4 MD5 hash Week Junos OS
export Release 12.1
RSA-EXPORT-1024-RC4-56-SHA RSA 1024 bit 56-bit RC4 SHA hash Week Junos OS
export Release 12.1
NOTE: Cipher suites that have “export” in the title are intended for use outside
of the United States and might have encryption algorithms with limited key
sizes.
Export ciphers are not enabled by default. You need to either configure the
export ciphers to enable or install a domestic package.
The following SSL protocols are supported on SRX Series devices for SSL initiation and
termination service:
• TLS version 1.1—This enhanced version of TLS provides protection against cipher block
chaining (CBC) attacks.
• TLS version 1.2 — This enhanced version of TLS provides improved flexibility for
negotiation of cryptographic algorithms.
Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, TLS version
1.1 and TLS version 1.2 protocols are supported on SRX Series devices along with TLS
version 1.0.
Starting with Junos OS Release 15.1X49-D20 and Junos OS Release 17.3R1, the SSL
protocol 3.0 (SSLv3) support is deprecated.
Server Authentication
Implicit trust between the client and the device (because the client accepts the certificate
generated by the device) is an important aspect of SSL proxy. It is extremely important
that server authentication is not compromised; however, in reality, self-signed certificates
and certificates with anomalies are in abundance. Anomalies can include expired
certificates, instances of common name not matching a domain name, and so forth.
Server authentication is governed by setting the ignore-server-auth-failure option in the
SSL proxy.
• If the certificate has expired or if the common name does not match the domain
name, a new certificate is generated by replacing the keys and changing the issuer
name to SSL-PROXY: DUMMY_CERT:GENERATED DUE TO SRVR AUTH FAILURE.
This ensures that the client browser displays a warning that the certificate is not
valid.
Trusted CA List
SSL proxy ensures secure transmission of data between a client and a server. Before
establishing a secure connection, SSL proxy checks CA certificates to verify signatures
on server certificates. For this reason, a reasonable list of trusted CA certificates is required
to effectively authenticate servers.
• Loading the default trusted CA list—Junos OS provides a default list of certificates that
contains well-known trusted CA certificates similar to the default certificates used by
most common browsers. Without these default certificates, browsers would not be
able to validate the identity of most websites and would mark them as untrusted sites.
Alternatively, you can download trusted CAs from a browser to an SRX Series device.
See Knowledge Base Article KB23144.
command. You can use the default trusted CA bundle file embedded into Junos OS or
you can download the latest CA bundle list from another 3rd party such as Mozilla
(https://curl.haxx.se/docs/caextract.html). The list of trusted Certificate Authority
can change over time so we recommend you to use the latest CA bundle.
We recommend you load the default trusted CA list if you want to trust the same CA
certificates as common browsers and avoid importing CA certificates manually.
• Importing the trusted CA list manually—You can import your own trusted CA certificates
using the Public Key Infrastructure (PKI). The PKI helps verify and authenticate the
validity of the trusted CA certificates. You create CA profile groups that include trusted
CA certificates, then import the group on your device for server authentication.
Root CA
In a public key infrastructure (PKI) hierarchy, the root CA is at the top of the trust path.
The root CA identifies the server certificate as a trusted certificate.
Client Authentication
Currently, client authentication is not supported in SSL proxy. If a server requests client
authentication, a warning is issued that a certificate is not available. The warning lets
the server determine whether to continue or to exit.
Whitelists
Because SSL encryption and decryption might consume memory resources on the SRX
Series device, network administrators can selectively bypass SSL proxy processing for
some sessions. Such sessions mostly include connections and transactions with trusted
servers or domains with which network administrators are very familiar. There are also
legal requirements to exempt financial and banking sites. Such exemptions are achieved
by configuring the IP addresses or domain names of the servers under whitelists.
Starting with Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, the whitelisting
feature is extended to include URL categories supported by UTM in the whitelist
configuration of SSL forward proxy. In this implementation, the Server Name Indication
(SNI) field is extracted by the UTM module from client hello messages to determine the
URL category. Each URL category has a unique ID. The list of URL categories under
whitelist is parsed and the corresponding category IDs are pushed to the Packet
Forwarding Engine for each SSL forward proxy profile. The SSL forward proxy then
determines through APIs whether to accept, and proxy, or to ignore the session.
Starting with Junos OS Release 17.4R1, the whitelisting feature is extended to support
custom URL categories supported by UTM in the whitelist configuration of SSL forward
proxy.
The IP addresses associated with domain names are dynamic and can change at any
time. Whenever a domain IP address changes, it is propagated to the SSL proxy
configuration (similar to what is done in the firewall policy configuration).
Session Resumption
An SSL session refers to the set of parameters and encryption keys created by performing
a full handshake. A connection is the conversation or active data transfer that occurs
within the session. The computational overhead of a complete SSL handshake and
generation of master keys is considerable. In short-lived sessions, the time taken for the
SSL handshake can be more than the time for data transfer.
To improve throughput and still maintain an appropriate level of security, SSL session
resumption provides a session caching mechanism so that session information, such as
the pre-master secret key and agreed-upon ciphers, can be cached for both the client
and server. The cached information is identified by a session ID. In subsequent connections
both parties agree to use the session ID to retrieve the information rather than create a
new pre-master secret key. Session resumption shortens the handshake process and
accelerates SSL transactions.
Session Renegotiation
After a session is created and SSL tunnel transport has been established, a change in
SSL parameters requires renegotiation. SSL proxy supports both secure (RFC 5746) and
nonsecure (TLS v1.0, TLS v1.1, and TLS v1.2) renegotiation. When session resumption is
enabled, session renegotiation is useful in the following situations:
A change in an SSL proxy profile that modifies a certificate, cipher strength, or trusted
CA list flushes cache entries when the modified policy is committed. When a session is
resumed, the SSL parameters associated with its session ID are retrieved from the cache.
If the SSL proxy profile is not altered, cache entries corresponding to that profile are not
flushed and the session continues. If the cache has been flushed, however, a full
handshake must be performed to establish the new SSL parameters. (There is no impact
to non-SSL sessions.)
When logging is enabled in an SSL proxy profile, SSL proxy can generate the messages
shown in Table 17 on page 180.
SSL_PROXY_SSL_SESSION_ALLOW Logs generated when a session is processed by SSL proxy even after
encountering some minor errors.
SSL_PROXY_SESSION_IGNORE Logs generated if non-SSL sessions are initially mistaken as SSL sessions.
All logs contain similar information as shown in the following example (actual order of
appearance):
The message field contains the reason for the log generation. One of three prefixes shown
in Table 18 on page 180 identifies the source of the message. Other fields are descriptively
labeled.
Prefix Description
system Logs generated due to errors related to the device or an action taken as part of the SSL
proxy profile. Most logs fall into this category.
openssl error Logs generated during the handshaking process if an error is detected by the openssl
library.
certificate error Logs generated during the handshaking process if an error is detected in the certificate
(x509 related errors).
Sample logs:
NOTE: These logs capture sessions that are dropped by SSL proxy, not
sessions that are marked by other modules that also use SSL proxy services.
• An entry is not found in the application system cache. This can happen on the first
session, or when the application system cache has been cleaned or has expired. In
such a scenario, SSL proxy cannot wait for the final match (requires traffic in both
directions). In SSL proxy, traffic in reverse direction happens only if SSL proxy has
initiated an SSL handshake. Initially, for such a scenario SSL proxy tries to leverage
prematch or aggressive match results from application identification , and if the results
indicate SSL, SSL proxy will go ahead with the handshake.
• Application identification fails due to resource constraints and other errors. Whenever
the result from application identification is not available, SSL proxy will assume static
port binding and will try to initiate SSL handshake on the session. This will succeed for
actual SSL sessions, but it will result in dropped sessions for non SSL sessions.
It is possible to enable SSL proxy on firewall policies that are configured using logical
systems; however, note the following limitations:
• Because proxy profiles configured at a global level (within “services ssl proxy”) are
visible across logical system configurations, it is possible to configure proxy profiles at
a global level and then attach them to the firewall policies of one or more logical
systems.
Limitations
NOTE: On SRX Series devices, for a particular session, the SSL proxy is only
enabled if a relevant feature related to SSL traffic is also enabled. Features
that are related to SSL traffic are IDP, application identification, application
firewall, application tracking, advanced policy-based routing, UTM, SkyATP,
and ICAP redirect service. If none of these features are active on a session,
the SSL proxy bypasses the session and logs are not generated in this scenario.
NOTE: On all SRX Series devices, the current SSL proxy implementation has
the following connectivity limitations:
• The SSLv2 protocol is not supported. SSL sessions using SSLv2 are dropped.
SSL proxies provide encryption and decryption by residing between the server and the
client. Because SSL proxies are hidden from both the server and the client, secret keys
are shared between the two to decrypt the SSL traffic. Proxies are known as forward
proxies because proxy servers are used to hide any detailed information from the servers.
Integrity, confidentiality, and authenticity of traffic are validated through PKI, which
includes digital certificates issued by the CA, certificate validity and expiration dates,
details about the certificate owner and issuer, and security policies.
Figure 7 on page 184 displays an overview of how SSL proxy is configured. It includes some
required steps, such as configuring the root CA certificate, loading a CA profile group,
and applying an SSL proxy profile to a security policy, and some optional steps, such as
creating whitelists and SSL proxy logging.
Generate Import
or
a root CA certificate. a root CA certificate.
(Optional)
Configure SSL proxy logging.
(Optional)
Create whitelists of exempted
destinations.
g042395
Apply the SSL proxy profile
to a security policy.
A CA can issue multiple certificates in the form of a tree structure. A root certificate is
the topmost certificate of the tree, the private key of which is used to sign other certificates.
All certificates immediately below the root certificate inherit the signature or
trustworthiness of the root certificate. This is somewhat like the notarizing of an identity.
You can configure a root CA certificate by first obtaining a root CA certificate (by either
generating a self-signed one or importing one) and then applying it to an SSL proxy
profile. There are two ways you can obtain a root CA certificate—by using the Junos OS
CLI on an SRX Series device or by using OpenSSL on a UNIX device.
To generate a root CA certificate using the Junos OS CLI, follow these steps on an SRX
Series device:
1. From operational mode, generate a PKI public/private key pair for a local digital
certificate.
3. From configuration mode, apply the loaded certificate as root-ca in the SSL proxy
profile.
[edit]
user@host# set services ssl proxy profile profile-name root-ca certificate-id
4. Import the root CA as a trusted CA into client browsers. This is required for the client
browsers to trust the certificates signed by the SRX Series device. See “Importing a
Root CA Certificate into a Browser” on page 188.
To generate a root CA certificate using OpenSSL, follow these steps on a UNIX device:
mkdir /etc/pki/tls/keys
mkdir /etc/pki/tls/certs
cd /etc/pki/tls
3. Create a CA certificate key. The following command creates an RSA key using the
3DES encryption named ca.key that is 2048 in length. You also need to enter a
password that is used to encrypt the private key. This is critical to security if the key
is lost because it will still be encrypted.
4. Create a CA certificate based on the CA private key (created in the previous step).
The expiration date for this certificate is 3 years or 1095 days. However, you can set
it to a different value. When creating the certificate, you need to enter the password
and the certificate information that includes distinguished name (DN), country name,
and so forth.
5. Import the CA private and public keys into the SRX Series device. Copy the ca.key and
ca.cer keys to the /var/tmp directory on the SRX Series device. You can copy using
SCP, or open the files and copy them into “vi” on the SRX Series device to create new
files.
6. From configuration mode, apply the loaded certificate as root-ca in the SSL proxy
profile.
[edit]
user@host# set services ssl proxy profile ssl-inspect-profile root-ca ssl-inspect-ca
7. Import the root CA as a trusted CA into client browsers. This is required for the client
browsers to trust the certificates signed by the SRX Series device. See “Importing a
Root CA Certificate into a Browser” on page 188.
The CA profile defines the certificate information to be used for authentication. It includes
the public key that SSL proxy uses when generating a new certificate. Junos OS allows
you to create a group of CA profiles and load multiple certificates in one action, view
information about all certificates in a group, and delete unwanted CA groups.
You can load a group of CA profiles by obtaining a list of trusted CA certificates, defining
a CA group, and attaching the CA group to the SSL proxy profile.
• Junos OS provides a default list of trusted CA certificates that you can load on your
system using the default command option. The Junos OS package contains the
default CA certificates as a PEM file (for example, trusted_CA.pem). After you
download the Junos OS package, the default certificates are available on your
system.
From operational mode, load the default trusted CA certificates (the group name
identifies the CA profile group):
• Alternatively, you can define your own list of trusted CA certificates and import
them on your system. You get the list of trusted CAs in a single PEM file (for example
IE-all.pem) and save the PEM file in a specific location (for example, /var/tmp). See
Knowledge Base Article KB23144.
From operational mode, load the trusted list to the device (the group name identifies
the CA profile group):
2. From configuration mode, attach the trusted CA or trusted CA group to the SSL proxy
profile. You can attach all trusted CA or one trusted CA at a time:
• To attach one CA profile group (the group name identifies the CA profile group):
[edit]
user@host# set services ssl proxy profile profile-name trusted-ca ca-name
[edit]
user@host# set services ssl proxy profile profile-name trusted-ca all
You can easily display information about all certificates in a CA profile group:
You can delete a CA profile group. Remember that deleting a CA profile group deletes
all certificates that belong to that group:
1. From configuration mode, configure the CA profile used for loading the certificate.
[edit]
user@host# set security pki ca-profile profile-name ca-identity ca-identity
[edit]
user@host# set security pki ca-profile profile-name ca-identity ca-identity
revocation-check disable
4. From configuration mode, configure the loaded certificate as a trusted CA in the SSL
proxy profile.
[edit]
user@host# set services ssl proxy profile ssl-proxy-profile-name trusted-ca
ca-profile-name
5. (Optional) If you have multiple trusted CA certificates, you do not have to specify
each trusted CA separately. You can load all the trusted CA certificates using the
following command from configuration mode.
[edit]
user@host# set services ssl proxy profile ssl-proxy-profile-name trusted-ca all
NOTE: Alternatively, you can import a set of trusted CAs from your browser
into the SRX Series device. See Knowledge Base article KB23144.
In order to have your browser or system automatically trust all certificates signed by the
root CA configured in the SSL proxy profile, you must instruct your platform or browser
to trust the CA root certificate.
request security pki local-certificate export certificate-id root-ca type pem filename
path/file-name.pem
c. Select the Trusted Root Certification Authorities tab and click Import.
d. In the Certificate Import Wizard, navigate to the required root CA certificate and
select it.
b. From the Advanced menu, select the Certificates tab and click View Certificate.
c. In the Certificate Manager window, select the Authorities tab and click Import.
b. From the Advanced menu, select the Certificates tab and click View Certificate.
d. In the Certificate window, select Trusted Root Certification Authorities and click
Import.
e. In the Certificate Import Wizard, navigate to the required root CA certificate and
select it.
SSL proxy is enabled as an application service within a security policy. In a security policy,
you specify the traffic that you want the SSL proxy enabled on as match criteria and then
specify the SSL proxy CA profile to be applied to the traffic. Figure 8 on page 190 displays
a graphical view of SSL proxy profile and security policy configuration.
1. Create a security policy and specify the match criteria for the policy. As match criteria,
specify the traffic for which you want to enable SSL proxy.
[edit]
user@host# set security policies from-zone trust to-zone untrust policy policy-name
match source-address source-address
user@host# set security policies from-zone trust to-zone untrust policy policy-name
match destination-address destination-address
user@host# set security policies from-zone trust to-zone untrust policy policy-name
match application application
[edit]
user@host# set security policies from-zone trust to-zone untrust policy policy-name
then permit application-services ssl-proxy profile-name profile-name
SSL encryption and decryption might consume memory resources on SRX Series devices.
You can selectively bypass SSL proxy processing for some sessions by configuring a
whitelist. Typically, you would configure the whitelist to include trusted servers or domains
with which you are very familiar. You might also include financial and banking sites that
you are legally required to include.
Whitelists include addresses that you want to exempt from undergoing SSL proxy
processing. For example, if you want to exempt all sessions to www.mycompany.com,
then you would include it in the whitelist. To configure the whiltelist, you specify the
domain that you want to exempt in an address book and then configure the address in
the SSL proxy profile.
[edit]
user@host# set security address-book global address address dns-name
www.mycompany.com
2. Specify the global address book address in the SSL proxy profile.
[edit]
user@host# set services ssl proxy profile profile-name whitelist address
Whitelist addresses and address sets are created under the global address book. The
following type of addresses (from the global address book) are supported:
[edit]
user@host# set security address-book global address address-name ipv4-prefix
[edit]
user@host# set security address-book global address address-name range-address
range-low to range-high
[edit]
user@host# set security address-book global address address-name wildcard-address
addr/netmask
• 203.0.113.9/255.255.0.0 is supported.
[edit]
user@host# set security address-book global address address-name ipv6-prefix
[edit]
user@host# set security address-book global address address-name dns-name
domain-name
• Translated IP addresses. Sessions are whitelisted based on the actual IP address and
not on the translated IP address. Because of this, in the whitelist configuration of the
SSL proxy profile, the actual IP address should be provided and not the translated IP
address.
For example, consider a destination NAT rule that translates destination IP address
192.0.2.10/24 to 198.51.100.8/24 using the following commands:
[edit]
user@host# set security nat destination pool d1 address 198.51.100.8/24
user@host# set security nat destination rule-set dst-nat rule r1 match
destination-address 192.0.2.10/24
user@host# set security nat destination rule-set dst-nat rule r1 then destination-nat
pool d1
In this scenario, to exempt a session from SSL proxy inspection, the following IP address
should be added to the whitelist:
[edit]
user@host# set security address-book global address ssl-proxy-exempted-addr
192.0.2.10/24
user@host# set services ssl proxy profile ssl-inspect-profile whitelist
ssl-proxy-exempted-addr
Whitelist URL Categories: The whitelisting feature is extended to include URL categories
supported by UTM in the whitelist configuration of SSL forward proxy. In this
implementation, the Server Name Indication (SNI) field is extracted by the UTM module
from client hello messages to determine the URL category. Each URL category has a
unique ID. The list of URL categories under whitelist is parsed and the corresponding
category IDs are pushed to the Packet Forwarding Engine for each SSL forward proxy
profile. The SSL forward proxy then determines through APIs whether to accept, and
proxy, or to ignore the session.
[edit]
user@host# set services ssl proxy profile sslfp_url_whitelist whitelist-url-categories
Enhanced_Financial_Data_and_Services
NOTE: The predefined url categories depends on UTM. To enable URL- based
whitelisting in SSL proxy, the following basic URL configurations are required:
[edit]
user@host# set security utm feature-profile web-filtering type
juniper-enhanced
user@host# set security utm utm-policy utmpolicy web-filtering http-profile
junos-wf-enhanced-default
Starting with Junos OS Release 17.4R1, the whitelisting feature is extended to support
custom URL categories supported by UTM in the whitelist configuration of SSL forward
proxy.
[edit]
user@host# set security utm custom-objects url-pattern url1 value www.example.com
user@host# set security utm custom-objects custom-url-category example-url value url1
When configuring SSL proxy, you can choose to set the option to receive some or all of
the logs. SSL proxy logs contain the logical system name, SSL proxy whitelists, policy
information, SSL proxy information, and other information that helps you troubleshoot
when there is an error.
You can configure logging of all or specific events, such as error, warning, and information
events. You can also configure logging of sessions that are whitelisted, dropped, ignored,
or allowed after an error occurs.
[edit]
user@host# set services ssl proxy profile profile-name actions log all
user@host# set services ssl proxy profile profile-name actions log sessions-whitelisted
user@host# set services ssl proxy profile profile-name actions log sessions-allowed
user@host# set services ssl proxy profile profile-name actions log errors
Configuring Ciphers
You can configure the following ciphers for an SSL proxy profile:
• custom-ciphers–Custom ciphers allow you to define your own cipher list. If you do not
want to use one of the three categories, you can select ciphers from each of the
categories to form a custom cipher set. To configure custom ciphers, you must set
preferred-ciphers to custom.
The following example shows how to create a custom cipher. In this example, you set
preferred-cipher to custom and add the cipher list (rsa-with-3des-ede-cbc-sha and
rsa-with-aes-256-cbc-sha):
When a self-signed certificate is generated using a PKI command, the newly generated
certificate is stored in a predefined location (var/db/certs/common/local).
Use the following command to export the certificate to a specific location (within the
device). You can specify the certificate ID, the filename, and the type of file format
(DER/PEM):
We do not recommend using this option for authentication because configuring it results
in websites not being authenticated at all. However, you can use this option to effectively
identify the root cause of dropped SSL sessions.
[edit]
user@host# set services ssl proxy profile profile-name actions ignore-server-auth-failure
SSL proxy is a transparent proxy that performs SSL encryption and decryption between
the client and the server as follows:
• Reverse proxy—Proxying inbound session, that is, externally initiated SSL sessions from
the Internet to the local server
• Forward proxy—Proxying outbound session, that is, locally initiated SSL session to the
Internet.
The proxy model implementation for server protection (often called reverse proxy) is
supported on SRX Series devices to provide improved handshaking and support for more
protocol versions.
On SRX Series devices, client protection (forward proxy) and server protection (reverse
proxy) are supported using same echo system SSL-T-SSL [terminator on the client side]
and SSL-I-SSL [initiator on the server side]).
NOTE: You can enable Layer 7 services (application security, IPS, UTM, SKY
ATP) on the traffic decrypted by SSL reverse proxy.
Starting in Junos OS Release 15.1X49-D80, we recommend using the SSL reverse proxy
and Intrusion Detection and Prevention (IDP) instead of using the IDP SSL inspection
functionality.
Table 19 on page 196 provides the changes applicable on SRX Series devices post
15.1X48-D80 releases.
Table 19: Comparing Reverse Proxy Before and After Junos OS Release 15.1X49-D80
Proxy model Runs only in tap mode Instead of participating Terminates client SSL on the SRX Series device and
in SSL handshake, it listens to the SSL initiates a new SSL connection with a server.
handshake, computes session keys and then Decrypts SSL traffic from the client/server and
decrypts the SSL traffic. encrypts again (after inspection) before sending to
the server/client.
Protocol version Does not support TLS Version 1.1 and 1.2. Supports all current protocol versions.
Echo system Tightly coupled with IDP engine and its Uses existing SSL forward proxy with TCP proxy
detector. underneath.
Table 19: Comparing Reverse Proxy Before and After Junos OS Release 15.1X49-D80 (continued)
Security services Decrypted SSL traffic can be inspected only Just like forward proxy, decrypted SSL traffic is
by IDP. available for all security services.
Ciphers supported Limited set of ciphers are supported. All commonly used ciphers are supported.
Like forward proxy, reverse proxy requires a profile to be configured at the firewall rule
level. In addition, you must also configure server certificates with private keys for reverse
proxy. During an SSL handshake, the SSL proxy performs a lookup for a matching server
private key in its server private key hash table database. If the lookup is successful, the
handshake continues. Otherwise, SSL proxy aborts the hand shake. Reverse proxy does
not prohibit server certificates. It forwards the actual server certificate/chain as is to the
client without modifying it. Intercepting the server certificate occurs only with forward
proxy.
The following shows example forward and reverse proxy profile configurations.
actions {
log {
all;
}
}
}
}
...
You must configure either root-ca or server-certificate in an SSL proxy profile. Otherwise
the commit check fails. See Table 20 on page 198.
server-certificate
configured root-ca configured Profile type
Yes Yes Commit check fails. Configuring both server-certificate and root-ca
in the same profile is not supported.
Configuring multiple instances of forward and reverse proxy profiles are supported. But
for a given firewall policy, only one profile (either a forward or reverse proxy profile) can
be configured. Configuring both forward and reverse proxy on the same device is also
supported.
You cannot configure the previous reverse proxy implementation with the new reverse
proxy implementation for a given firewall policy. If both are configured, you will receive
a commit check failure message.
1. Load the server certificates and their keys into the SRX Series device certificate
repository using the CLI command request security pki local-certificate load filename
filename key key certificate-id certificate-id passphrase exmample@1234. For example:
2. Attach the server certificate identifier to the SSL Proxy profile using the CLI command
set services ssl proxy profile profile server-certificate certificate-id passphrase
exmample@1234. For example
3. Attach the trusted CA to the SSL proxy profile. In this example, you attach all trusted
CA at a time:
4. Use the show services ssl CLI command to verify your configuration. For example:
Requirements
Overview
A reverse proxy protects servers by hiding the details of the servers from the clients, there
by adding an extra layer of security.
Similar to SSL forward proxy (client protection), server protection also needs an SSL
proxy profile to be configured at the security policy rule level. For server protection,
additionally, server certificate(s) with private key(s) must be configured. Note that, for
server protection enabled session, SSL proxy do not interdicts server certificate, that
is—it forwards the actual server certificate/chain as it is to the client without modifying
it. Interdicting the server certificate happens on client protection enabled sessions only.
• Load the server certificate(s) and their key(s) into SRX Series device’s certificate
repository.
Configuration
3. Attach the trusted CA to the SSL proxy profile. In this example, you attach all trusted
CA at a time:
4. Create a security policy and specify the match criteria for the policy. As match
criteria, specify the traffic for which you want to enable SSL proxy.
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
user@host# set security policies from-zone untrust to-zone trust policy 1 then permit
application-services ssl-proxy profile-name server-protection-profile
Purpose Viewing the SSL reverse proxy statistics on the SRX Series device.
Action You can view the SSL proxy statistics by using the show services ssl proxy statistics
command.
sessions ignored 0
sessions active 0
sessions dropped 0
Brief Only error traces on both the Routing Engine and the Packet
Forwarding Engine.
selected-profile Enable tracing only for profiles that have enable-flow-tracing set.
You can enable logs in the SSL proxy profile to get to the root cause for the drop. The
following errors are some of the most common:
• Server certification validation error. Check the trusted CA configuration to verify your
configuration.
You can enable the ignore-server-auth-failure option in the SSL proxy profile to ensure
that certificate validation, root CA expiration dates, and other such issues are ignored. If
sessions are inspected after the ignore-server-auth-failure option is enabled, the problem
is localized.
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.
SSL proxy functionality is supported when the device is configured with unified policies.
As a part of this enhancement, you can configure a default SSL proxy profile.
During the initial policy lookup phase, which occurs prior to a dynamic application being
identified, if there are multiple policies present in the potential policy list which contains
different SSL proxy profiles, the SRX Series device applies the default SSL proxy profile
until a more explicit match has occurred.
We recommend that you create a default SSL proxy profile. The sessions are dropped
in case of policy conflicts, if there is no default SSL proxy profile available.
You can configure an SSL proxy profile under the [edit services ssl proxy] hierarchy level,
and then apply it as a default SSL proxy profile under the [edit security ngfw] hierarchy
level. This configuration does not impact the existing SSL service configuration.
Configuring a default SSL proxy profile is supported for both SSL forward and reverse
proxy.
Table 23 on page 203 summarizes the default SSL proxy profile behavior in unified policies.
Application
Identification Status SSL Proxy Profile Usage Action
No security policy SSL proxy profile is applied when traffic matches the SSL proxy profile is applied.
conflict security policy.
Security policy conflict Default SSL proxy profile is not configured or not Session is terminated, because the default
(conflicting polices have found. SSL proxy profile is not configured.
distinct SSL proxy
profiles)
Default SSL proxy profile is configured. Default SSL proxy profile is applied.
Final application is Matching security policy has a SSL proxy profile that Default SSL proxy profile is applied.
identified is same as default SSL proxy profile.
Matching security policy does not have a SSL proxy Default SSL proxy profile is applied.
profile.
Matching security policy has a SSL proxy profile that Default SSL proxy profile that is already
is different from the default SSL proxy profile that is applied, continues remain as applied.
already applied.
NOTE: A security policy can have either an SSL reverse proxy profile or an
SSL forward proxy profile configured at a time.
If a security policy has an SSL forward proxy profile and another security
policy has an SSL reverse proxy profile, in such case, a default profile—either
from SSL reverse proxy profile or from SSL forward proxy profile is considered.
nat-destination-address="5.0.0.1" nat-destination-port="443"
profile-name="(null)" source-zone-name="untrust"
source-interface-name="xe-2/2/1.0" destination-zone-name="trust"
destination-interface-name="xe-2/2/2.0" message="default ssl-proxy
profile is not configured"]
Following examples discuss in detail about the default SSL proxy profile in different
scenarios:
• No Policy Conflict—All Policies Have Same SSL Proxy Profile on page 204
• No Policy Conflict—All Policies Have Same SSL Proxy Profile and Final Policy Has No
SSL Profile on page 204
• Policy Conflict—No SSL Profile Configured for Final Policy on page 205
• Policy Conflict–Default SSL Proxy Profile and Different SSL Proxy Profile for Final
Policy on page 205
All matching policies have same SSL proxy profile as shown in Table 24 on page 204.
Table 24: No Policy Conflict—All Policies Have Same SSL Proxy Profile
Default
Source Destination SSL
Security Source IP Destination IP Port Dynamic Proxy
Policy Zone Address Zone Address Number Protocol Application Service Profile
In this case, both Policy-P1 and Policy-P2 have the same SSL proxy profile (SSL-1).
Because there is no conflict, the profile SSL-1 is applied.
If you have configured a default SSL proxy profile (SSL-2), it is not applied. Because there
is no conflict in the policies (Policy-P1 and Policy-P2).
No Policy Conflict—All Policies Have Same SSL Proxy Profile and Final Policy Has No
SSL Profile
Policy-P1 and Policy-P2 have same SSL proxy profile and the Policy-3 has no SSL profile
as shown in Table 25 on page 204.
Table 25: No Policy Conflict—All Policies Have Same SSL Proxy Profile and Final Policy Has No SSL Profile Configured
Default
Source Destination SSL
Security Source IP Destination IP Port Dynamic Proxy
Policy Zone Address Zone Address Number Protocol Application Service Profile
Table 25: No Policy Conflict—All Policies Have Same SSL Proxy Profile and Final Policy Has No SSL Profile
Configured (continued)
Default
Source Destination SSL
Security Source IP Destination IP Port Dynamic Proxy
Policy Zone Address Zone Address Number Protocol Application Service Profile
In this scenario, both Policy-P1 and Policy-P2 have the same SSL proxy profile (SSL-1).
Because there is no conflict, the profile SSL-1 is applied before the final policy match.
When the final application is identified, the security policy matching with the final
application, that is, Policy-P3 is applied. Because the Policy-P3 has no SSL proxy profile,
the already applied profile SSL-1 remains applied. This is because, the SSL proxy profile
is already applied on the traffic.
The default SSL proxy profile is applied during potential match as shown in
Table 26 on page 205. The final policy, Policy-P3 does not have any SSL proxy profile.
Table 26: Policy Conflict—No SSL Profile Configured for Final Policy
Default
Source SSL
Security Source IP Destination Destination Port Dynamic Proxy
Policy Zone Address Zone IP Address Number Protocol Application Service Profile
In this example, SSL proxy profile SSL-1 is configured as default SSL proxy profile. During
the policy conflict for Policy-P1 and Policy-P2, the default profile SSL-1 is applied.
When the final application is identified, the security policy matching with the final
application, that is, Policy-P3 is applied. Because the Policy-P3 has no SSL proxy profile,
the already applied profile SSL-1 continues to remain as applied. This is because, the
SSL proxy profile is applied on the traffic.
Policy Conflict–Default SSL Proxy Profile and Different SSL Proxy Profile for Final Policy
The SSL proxy profile SSL-1 is configured as a default SSL proxy profile and is already
applied before the final policy is matched. Refer Table 12 on page 123.
Table 27: Policy Conflict—Default SSL Proxy Profile and Different SSL Proxy Profile for Final Policy
Default
Source Destination SSL
Security Source IP Destination IP Port Dynamic Proxy
Policy Zone Address Zone Address Number Protocol Application Service Profile
When the final application is identified, the security policy matching with the final
application, that is, Policy-P3 is applied. The SSL profile for the Policy-P3, that is, SSL-3
is not applied. Instead, the SSL proxy profile SSL-2 configured and applied as default
profile, continues to remain as applied.
Switching from the default SSL proxy profile that is already applied to the traffic, to
another SSL proxy profile is not supported.
• When a default SSL proxy profile is enabled, it cannot be disabled even if the final
security policy does not have SSL proxy configured.
• When a default SSL proxy profile is enabled and applied on the traffic and the final
security policy has a different SSL proxy profile configured other than default profile,
switching from the default SSL proxy profile to the SSL proxy profile in the security
policy is not supported.
In this procedure, you configure an SSL forward proxy profile, and specify the profile as
the default profile.
1. Create an SSL profile and attach the CA profile group to the SSL proxy profile.
user@host# set services ssl proxy profile profile-name profle-name trusted-ca all
In this procedure, you configure an SSL reverse proxy profile and specify the profile as
the default profile.
1. Create an SSL profile and attach the CA profile group to the SSL proxy profile.
In this procedure, you assign the SSL forward proxy profile or the SSL reverse proxy profile
as the default profile in logical system configurations. In this case, one profile can be a
default profile either from the SSL forward proxy or from the SSL reverse proxy.
Requirements
• SRX Series device with Junos OS Release 18.2R1 or later. This configuration example
is tested for Junos OS Release 18.2R1.
Overview
In this example, you configure an SSL forward proxy profile by specifying the root CA
certificate. Next, configure the profile as default SSL proxy profile. Now, you create a
unified policy and invoke the SSL proxy as application services on the permitted traffic.
Configuration
1. Create an SSL profile and attach the CA profile group to the SSL proxy profile.
4. Create a unified policy and specify the dynamic application as the match criteria.
user@host# set security policies from-zone untrust to-zone trust policy from_internet
match source-address any
user@host# set security policies from-zone untrust to-zone trust policy from_internet
match destination-address any
user@host# set security policies from-zone untrust to-zone trust policy from_internet
match application any
user@host# set security policies from-zone untrust to-zone trust policy from_internet
match dynamic-application junos:web
5. Apply the SSL proxy profile to the permitted traffic in the security policy.
user@host# set security policies from-zone untrust to-zone trust policy from_internet
then permit application-services ssl-proxy profile-name SSL-FP-PROFILE-1
Verification
Purpose Confirm that the configuration is working properly by displaying the SSL proxy statistics.
Action From operational mode, enter the show services ssl proxy statistics command.
• Details about the default SSL proxy profile such as the sessions where the default
profile is applied and the sessions that are dropped due to the absence of the default
profile.
SSL proxy acts as an intermediary, performing SSL encryption and decryption between
the client and the server, but neither the server nor the client can detect its presence. SSL
relies on digital certificates and private-public key exchange pairs for client and server
authentication to ensure secure communication.
In order to validate (and trust) an SSL certificate, the CA that issued the certificate must
be included in the trusted CA list of the device that is connecting.
For example, when a connection is initiated, the connecting device (such as a Web
browser) checks whether the certificate is issued by a trusted CA. If not, , the device
checks whether the certificate of the issuing CA was issued by a trusted CA. This check
continues until either a trusted CA is found (at which point a trusted, secure connection
will be established), or no trusted CA can be found (at which point the device will usually
display an error).
If the intermediate certificates are not included in the trusted CA list, then the Web
browser of the clients might display a warning message stating that the certificate
presented by the device they are accessing is not trusted.
You can resolve this issue by using an SSL certificate chain. The list of SSL certificates,
from the root certificate to the end-user certificate, represents the SSL certificate chain.
Starting in Junos OS Release 15.1X49-D30, SSL forward proxy supports the certificate
chain and sends it to facilitate the certification chain validation by the client (that is, the
connecting device).
The certificate chain is a file that contains an ordered list of certificates, including an SSL
certificate and a chain of intermediate CA certificates, in Privacy-Enhanced Mail (PEM)
format. This enables the receiver to verify that the sender and all CAs are trustworthy.
Any certificate placed between the root CA certificate and the SSL certificate (used by
end-users) is considered an intermediate certificate. These must be installed to the
webserver with the end-user certificate for your website to link your certificate to a trusted
authority.
Any certificate signed by a trusted root CA certificate is also trusted. The root CA certificate
is always signed by the CA itself. The root CA certificate is the signer/issuer of the
intermediate certificate. In turn, the signed intermediate certificate can sign another
intermediate certificate and it will also be trusted. The chain terminates at the end-user
certificate.
SSL forward proxy sends the entire certificate chain, excluding or including the root CA
certificate, to facilitate certificate validation at the client side.
Root-CA is the common trusted CA for all devices in the network. Root-CA issues CA
certificates to the engineering and sales CAs, which are identified as Eng-CA and Sales-CA,
respectively. Eng-CA issues CA certificates to the development and quality assurance
CAs, which are identified as Dev-CA and Qa-CA, respectively. Host-A receives its certificate
from Dev-CA while Host-B receives its certificate from Sales-CA.
The end-user device needs to be loaded with the entire certificate chain. In this example,
Host-A must have Root-CA, Eng-CA, and Dev-CA certificates; and Host-B must have
Root-CA and Sales-CA certificates.
SSL certificate chains eliminate the need to deploy all intermediate certificates separately
on all clients.
• Administrator loads the certificate chain and the local certificate (signing certificate)
into the PKI daemon certificate cache.
• The Network Security Daemon (nsd) sends a request to the PKI daemon to provide
the certificate chain information for a signing certificate configured in the SSL proxy
profile.
• SSL forward proxy stores this certificate chain information (CA certificate profile name)
in therespective SSL profile. As a part of security policy implementation, SSL profiles
having the certificate chain information and CA certificates are used.
This example shows how to install the certificate chain to enable browsers to trust your
certificate. It shows how to install the root CA certificate and enable the certificate chain
in order to ensure secure communications over the Web when using the service.
Requirements
Overview
Some certificate authorities (CAs) do not sign with their root certificate, but instead use
an intermediate certificate. An intermediate CA can sign certificates on behalf of the root
CA certificate. The root CA signs the intermediate certificate, forming a chain of trust.
In order to trust a server's certificate, the client must be configured to trust the CA that
signed the server certificate. However, clients are configured to trust only the root CA
certificate. Therefore the server must present the chain of intermediate CA certificates
to ensure that the trust is properly established when clients connect to a server.
Figure 10 on page 212 depicts a full certificate chain, from the root CA certificate to the
end-user certificate. The chain terminates at the end-user certificate.
Figure 10: Certification Path from the Certificate Owner to the Root CA
End User
Certificate
Utilizes
Issued By
Certificate-1
Utilizes
XYZ-Authority
Issued By
Certificate-2
Utilizes
Intermediate-CA1
Issued By
Certificate-3
Utilizes
Intermediate-CA2
Issued By
Certificate-4
Utilizes
Intermediate-CA3
Issued By
g043726
Root-CA
In this example, you have a domain, example.domain-1, and you want to purchase a
certificate from XYZ-Authority for your domain. However, XYZ -Authority is not a Root-CA
and the visiting Web browser trusts only Root-CA certificate. In other words, its certificate
is not directly embedded in your Web browser and therefore it is not explicitly trusted. In
this case, trust is established in the following manner using the certificate chain (of
intermediate certificates):
Its certificate is directly embedded in your Web browser; therefore it can be explicitly
trusted. The certificate chain includes all the certificates starting from Certificate-1 to
Root-CA certificate. Because the web browser trusts the root CA, it also implicitly trusts
all the intermediate certificates.
Certificate-1 is your end-user certificate, the one you purchase from the CA. The certificates
from 2 to 3 are called intermediate certificates. Certificate-4, at the end, is called the root
CA certificate.
When you install your end-user certificate for the server example.domain-1, you must
bundle all the intermediate certificates and install them along with your end-user
certificate. If the SSL certificate chain is invalid or broken, your certificate will not be
trusted by some devices.
NOTE:
• All certificates must be in Privacy-Enhanced Mail (PEM) format.
• When you import the concatenated certificate file into the device, the CA
provides a bundle of chained certificates that must be added to the signed
server certificate. The server certificate must appear before the chained
certificates in the combined file.
Configuration
• Purchase an SSL certificate from a CA that includes a signing certificate and a respective
key.
• Load the intermediate and root CA in public key infrastructure (PKI) memory. This
certificate file contains all the required CA certificates, one after each other, in PEM
format.
• Set up your device to use the signing certificate received from the CA by configuring
and applying the SSL proxy profile to a security policy.
3. Attach the signing certificate profile as created in Step 1 to the SSL proxy profile.
4. Attach the trusted CA profiles created in Step 2 to the SSL proxy profile.
This example assumes that you have already purchased an SSL certificate from a CA.
Note that the certificate ID will be used under the root-ca section in the SSL proxy
profile.
Step-by-Step The CA profile defines the certificate information to be used for authentication. It includes
Procedure the public key that SSL proxy uses when generating a new certificate. Junos OS allows
you to create a group of CA profiles and load multiple certificates in one action, view
information about all certificates in a group, and delete unwanted CA groups.
The CA profile includes the certificate information used for authentication. It includes
the public key that SSL proxy uses when generating a new certificate.
Step-by-Step SSL forward proxy stores this certificate chain information (CA certificate profile name)
Procedure into respective the SSL profile. As a part of security policy implementation, SSL profiles
having the certificate chain information and CA certificates are used.
1. Attach the CA profile group to the SSL proxy profile. You can attach trusted CA one
at a time or load all in one action.
3. Create a security policy and specify the match criteria for the policy. As match
criteria, specify the traffic for which you want to enable SSL proxy.
user@host# set security policies from-zone trust to-zone untrust policy 1 match
source-address any
user@host# set security policies from-zone trust to-zone untrust policy 1 match
destination-address any
user@host# set security policies from-zone trust to-zone untrust policy 1 match
application any
user@host# set security policies from-zone trust to-zone untrust policy 1 then permit
application-services ssl-proxy profile-name ssl-proxy
5. Create a security policy and specify the match criteria for the policy. As match
criteria, specify the traffic for which you want to enable SSL proxy.
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
user@host# set security policies from-zone untrust to-zone trust policy 1 then permit
application-services ssl-proxy profile-name ssl-proxy
Action You can view the certificate chain on the connecting Web browser (that is, the client).
• Private key associated with the CA that issued the certificate was compromised.
• The owner of the certificate is no longer affiliated with the issuer of the certificate and
does not have rights to access the certificate or does not require it any longer.
• The certificate is on hold pending further action. It is treated as revoked but might be
accepted in the future.
The CRL contains the list of digital certificates that have been canceled before their
expiration date. When a participating device uses a digital certificate, it checks the
certificate signature and validity. It also acquires the most recently issued CRL and checks
that the certificate serial number is not on that CRL. By default, CRL verification is enabled
on SSL proxy profile.
CRL validation on SRX Series device involves checking for revoked certificates from
servers. You can enable or disable the CRL validation to meet your specific security
requirements.
Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1, certificate
revocation list (CRL) checks are supported.
In order to enhance security, the certificate revocation checking feature has been enabled
by default on SRX Series devices on any SSL proxy profile. You can enable or disable the
CRL validation to meet your specific security requirements.
[edit]
user@host# set services ssl proxy profile profile-name actions crl disable
You can reenable CRL validation by using the delete services ssl proxy profile profile-name
actions crl disable command.
Sometimes CRL information might not be available because of various reasons. For
example:
• CRL download failed and the PKI daemon did not or could not fetch the CRL from the
CA.
• The CRL path was not available from the configuration and it is not present in the root
or intermediate certificate, or no URL was configured.
You can allow or drop the sessions when a CRL information is not available.
• To ensure that the sessions are not dropped for any reason when CRL information is
not available:
[edit]
user@host# edit set services ssl proxy profile profile-name actions crl if-not-present
allow
[edit]
user@host# edit set services ssl proxy profile profile-name actions crl if-not-present
drop
You can configure how an SRX Series device will respond when updated CRL information
is not available, and the server certificate that is currently offered is not known to be
revoked from a previous query. Certificates are presumed not to be revoked, by default,
which means they are valid, and a temporary failure to obtain a CRL does not
automatically result in an SSL handshake failure. By default, sessions are allowed if CRL
status is unknown.
You can configure an SRX Series device to accept a certificate without a reliable
confirmation available on the revocation status.
• To allow the sessions when a certificate is revoked and the revocation reason is on
hold:
[edit]
user@host# edit set services ssl proxy profile profile-name actions crl
ignore-hold-instruction-code
On the SSL payload, IDP can inspect attacks and anomalies; for example, HTTP chunk
length overflow on HTTPS. On encrypted applications, such as Facebook, AppFW can
enforce policies and AppTrack (when configured in the from and to zones) can report
logging issues based on dynamic applications.
NOTE: The IDP module will not perform an SSL inspection on a session if an
SSL proxy is enabled for that session. That is, if both SSL inspection and SSL
proxy are enabled on a session, SSL proxy will always take precedence.
See Also • Example: Configuring Application Firewall When SSL Proxy Is Enabled on page 89
• Example: Configuring Application Tracking When SSL Proxy Is Enabled on page 103
The SSL/TLS handshake used for providing secure connections involves number of
communications passed back and forth between the user’s browser (client) and web
application (server) to verify if the connection is trusted. It is a CPU-intensive process.
Since SSL/TLS is the most widely used security protocol on the web, it’s performance
results in significant impact on the web performance.
Starting from Junos OS Release 15.1X49-D120, when using SSL/TLS for connections
between clients and servers, the following new options are available for optimizing the
SSL performance:
• AES128-CBC-SHA
• AES256-CBC-SHA
Certificate cache stores the interdicted server certificate along with the server certificate
details. During SSL/TLS handshake, SSL proxy can present the cached interdicted
certificate to client instead of generating the new interdicted certificate. This operation
also does not involve RSA involvement. The default timeout period of the certificate
cache entry is 600 seconds and it can be changed using the appropriate configuration.
For example:
To set the certificate cache timeout to 300 seconds, that is, the time in seconds that
certificate details are stored in the cache, use the following command:
[edit]
user@host# services ssl proxy global-config certificate-cache-timeout 300
To disable the certificate cache and allow the SSL full handshake to occur for a new
connection, use the following command:
[edit]
user@host# services ssl proxy global-config disable-cert-cache
[edit]
user@host# services ssl proxy global-config invalidate-cache-on-crl-update
Data loss prevention (DLP) is a method for inspecting and keeping the sensitive data
from leaving the network.
You can prevent data loss from your network by employing Internet Content Adaptation
Protocol (ICAP) redirect services. ICAP is a lightweight HTTP-based remote procedure
call protocol. ICAP allows its clients to pass HTTP-based content (HTML) to the ICAP
servers for performing services such as virus scanning, content translation, or content
filtering and so on for the associated client requests.
SRX Series devices support DLP to redirect HTTP or HTTPS traffic to any third-party
server through ICAP. The SRX Series device acts as an SSL proxy server and decrypts the
pass-through traffic with the proper SSL profile under a security policy. SRX Series device
decrypts HTTPS traffic and redirects HTTP message to a third-party on-premise server
using an ICAP channel. After DLP processing, the traffic is redirected back to the SRX
Series device and action is taken according to the results from the ICAP server. If any
sensitive data is detected per the policies, the SRX Series device logs, redirects, or blocks
the data traffic as configured in the profile.
2. The request goes through the SRX Series device that is acting as a proxy server.
3. The SRX Series device receives information from the end-host, encapsulates the
message and forwards the encapsulated ICAP message to the third-party on-premise
ICAP server.
4. The ICAP server receives the ICAP request and analyzes it.
5. If the request does not contain any confidential information, the ICAP server sends it
back to the proxy server, and directs the proxy server to send the HTTP to the internet.
6. If the request contains confidential information, you can choose to take action (block,
permit, log) as per your requirement.
NOTE: The HTTP throughput depends on the connections between the SRX
Series device and the ICAP channel.
ICAP Profile
When you configure ICAP redirect service on SRX Series devices, you must configure the
ICAP server information. This profile is applied to a security policy as application services
for the permitted traffic. The ICAP profile defines the settings that allow the ICAP server
to process request messages, response messages, fallback options (in case of a timeout),
connectivity issues, too many requests, or any other conditions.
Starting from Junos OS Release 18.2R1, SRX Series devices support ICAP service redirect
feature when the device is configured with unified 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.
In a unified policy with dynamic applications as a match condition, you configure an ICAP
redirect profile and SSL proxy profile and apply these profiles as application services in
the security policy for the permitted traffic. When the traffic matches the policy, the ICAP
redirect service profile that is configured as application services is applied. The ICAP
server profile defines the behavior of redirection and server specifications. The ICAP server
performs the policy scan and the traffic is redirected to the SRX Series device, and the
specified action is taken as per the ICAP redirect profile.
Note the following behavior while using ICAP redirect service with unified policy:
• When ICAP redirect is configured in a unified policy and the data that needs to be
redirected has arrived and the final policy is not determined, the request is ignored by
the ICAP redirect service.
• Because ICAP redirect is one of services located in the service chain, the data received
by the ICAP redirect service might be different from the original data. The data sent by
the ICAP redirect might affect downstream services.
NOTE: The HTTP throughput depends on the connections between the SRX
device and SRX ICAP .
Requirements
• SRX Series device with Junos OS Release 18.2R1 or later. This configuration example
is tested for Junos OS Release 18.2R1.
Overview
In this example, you configure an ICAP redirect profile and an SSL proxy profile and apply
these profiles as application services in the security policy for the permitted traffic.
To enable the service redirect using ICAP, you must configure an SSL profile to secure
the connection to the ICAP server. Next, you configure a security policy to process the
traffic, and specify the action for the permitted traffic.
Table 28 on page 222 lists the details of the parameters used in this example.
Profile icap-pf1 The ICAP server profile allows the ICAP server to process
request messages, response messages, fallback options
and so on, for the permitted traffic. This profile is applied
as an application service in the security policy.
Server name icap-svr1 The machine name of the remote ICAP host. Client’s
request is redirected to this ICAP server.
icap-svr2
Server IP 5.0.0.2 The IP address of the remote ICAP host. Client’s request
address is redirected to this ICAP server.
5.0.0.179
SSL proxy ssl-inspect-profile An SSL proxy profile defines SSL behavior for the SRX
profile Series device. The SSL proxy profile is applied to the
security policy as an application service.
SSL profile dlp_ssl The SRX Series device that is acting as an SSL proxy
client, initiates and maintains SSL sessions with an SSL
server. This configuration enables you to secure the
connection to the ICAP server.
Security policy sp1 In a security policy, apply the SSL proxy profile and ICAP
redirect profile. to the permitted traffic.
Configuration
CLI Quick To quickly configure this example, copy the following commands, paste them into a text
Configuration 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 The following example requires you to navigate various levels in the configuration
Procedure hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration
Mode in the CLI User Guide.
[edit services]
user@host# set services ssl proxy profile ssl-inspect-profile root-ca ssl-inspect-ca
user@host# set services ssl proxy profile ssl-inspect-profile actions
ignore-server-auth-failure
2. Configure the SSL profile for a secured connection with the ICAP server.
[edit services]
user@host# set ssl initiation profile dlp_ssl trusted-ca all
user@host# set ssl initiation profile dlp_ssl actions ignore-server-auth-failure
user@host# set ssl initiation profile dlp_ssl actions crl disable
3. Configure the ICAP redirect profile for the first server (icap-svr1).
[edit services]
user@host# set icap-redirect profile icap-pf1 server icap-svr1 host 5.0.0.2
user@host# set icap-redirect profile icap-pf1 server icap-svr1 reqmod-uri echo
user@host# set icap-redirect profile icap-pf1 server icap-svr1 respmod-uri echo
user@host# set icap-redirect profile icap-pf1 server icap-svr1 sockets 64
4. Configure the ICAP redirect profile for the second server (icap-svr2).
[edit services]
user@host# set icap-redirect profile icap-pf1 server icap-svr2 host 5.0.0.179
user@host# set icap-redirect profile icap-pf1 server icap-svr2 reqmod-uri echo
user@host# set icap-redirect profile icap-pf1 server icap-svr2 respmod-uri echo
user@host# set icap-redirect profile icap-pf1 server icap-svr2 sockets 64
user@host# set icap-redirect profile icap-pf1 server icap-svr2 tls-profile dlp_ssl
5. Configure the redirect request and the redirect response for the HTTP traffic.
[edit services]
user@host# set icap-redirect profile icap-pf1 http redirect-request
user@host# set icap-redirect profile icap-pf1 http redirect-response
6. Configure a security policy to apply application services for the ICAP redirect to the
permitted traffic.
[edit security]
user@host# set policies from-zone trust to-zone untrust policy sec_policy match
source-address any
user@host# set policies from-zone trust to-zone untrust policy sec_policy match
destination-address any
user@host# set policies from-zone trust to-zone untrust policy sec_policy match
application any
user@host# set policies from-zone trust to-zone untrust policy sec_policy then
permit application-services ssl-proxy profile-name ssl-inspect-profile
user@host# set policies from-zone trust to-zone untrust policy sec_policy then
permit application-services icap-redirect icap-pf1
user@host# set policies default-policy permit-all
[edit security]
user@host# set interfaces xe-5/0/0 unit 0 family inet address 192.0.2.1/8
user@host# set interfaces xe-5/0/0 unit 0 family inet6 address 2001:db8::1/64
user@host# set interfaces xe-5/0/1 unit 0 family inet address 198.51.100.1/8
user@host# set interfaces xe-5/0/1 unit 0 family inet6 address 2001:db8::2/64
user@host# set zones security-zone trust host-inbound-traffic system-services all
user@host# set zones security-zone trust host-inbound-traffic protocols all
user@host# set zones security-zone trust interfaces xe-5/0/0.0
user@host# set zones security-zone untrust host-inbound-traffic system-services
all
user@host# set zones security-zone untrust host-inbound-traffic protocols all
user@host# set zones security-zone untrust interfaces xe-5/0/1.0
Results From configuration mode, confirm your configuration by entering the show services
icap-redirect, show security policies, show security zones, and show interfaces commands.
If the output does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
respmod-uri echo;
sockets 64;
}
server icap-svr2 {
host 5.0.0.179;
reqmod-uri echo;
respmod-uri echo;
sockets 10;
tls-profile dlp_ssl;
}
http {
redirect-request;
redirect-response;
}
}
If you are done configuring the device, enter commit from configuration mode.
Step-by-Step You can follow the procedure below if you have configured a unified policy (supported
Procedure from Junos OS Release 18.2R1).
The following example requires you to navigate to 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.
[edit services]
2. Configure the SSL profile for secured connection with the ICAP server.
[edit services]
user@host# set ssl initiation profile dlp_ssl trusted-ca all
user@host# set ssl initiation profile dlp_ssl actions ignore-server-auth-failure
user@host# set ssl initiation profile dlp_ssl actions crl disable
3. Configure the ICAP redirect profile for the first server (icap-svr1).
[edit services]
user@host# set icap-redirect profile icap-pf1 server icap-svr1 host 5.0.0.2
user@host# set icap-redirect profile icap-pf1 server icap-svr1 reqmod-uri echo
user@host# set icap-redirect profile icap-pf1 server icap-svr1 respmod-uri echo
user@host# set icap-redirect profile icap-pf1 server icap-svr1 sockets 64
4. Configure the ICAP redirect profile for the second server (icap-svr2).
[edit services]
user@host# set icap-redirect profile icap-pf1 server icap-svr2 host 5.0.0.179
user@host# set icap-redirect profile icap-pf1 server icap-svr2 reqmod-uri echo
user@host# set icap-redirect profile icap-pf1 server icap-svr2 respmod-uri echo
user@host# set icap-redirect profile icap-pf1 server icap-svr2 sockets 64
user@host# set icap-redirect profile icap-pf1 server icap-svr2 tls-profile dlp_ssl
[edit services]
user@host# set icap-redirect profile icap-pf1 http redirect-request
user@host# set icap-redirect profile icap-pf1 http redirect-response
6. Configure a security policy to apply application services for the ICAP redirect to the
permitted traffic.
[edit security]
user@host# set policies from-zone trust to-zone untrust policy sec_policy match
source-address any
user@host# set policies from-zone trust to-zone untrust policy sec_policy match
destination-address any
user@host# set policies from-zone trust to-zone untrust policy sec_policy match
application any
user@host# set policies from-zone trust to-zone untrust policy sec_policy match
dynamic-application junos:HTTP
user@host# set policies from-zone trust to-zone untrust policy sec_policy then
permit application-services ssl-proxy profile-name ssl-inspect-profile
user@host# set policies from-zone trust to-zone untrust policy sec_policy then
permit application-services icap-redirect icap-pf1
user@host# set policies default-policy permit-all
Verification
Purpose Verify that the ICAP redirect service is configured on the device.
Action From operational mode, enter the show services icap-redirect status and show services
icap-redirect statistic commands.
ICAP Status :
Spu-1 Profile: icap-pf1 Server: icap-svr1 : UP
ICAP Status :
Spu-1 Profile: icap-pf1 Server: icap-svr2 : UP
ICAP Status :
Spu-2 Profile: icap-pf1 Server: icap-svr1 : UP
ICAP Status :
Spu-2 Profile: icap-pf1 Server: icap-svr2 : UP
ICAP Status :
Spu-3 Profile: icap-pf1 Server: icap-svr1 : UP
ICAP Status :
Spu-3 Profile: icap-pf1 Server: icap-svr2 : UP
Meaning The status Up indicates that the ICAP redirect service is enabled. The Message Redirected
and the Message Received fields show the number of HTTP requests that have passed
through the ICAP channel.
18.1R1 Starting in Junos OS Release 18.1R1, SSL proxy support is available on SRX300
and SRX320 devices
17.4R1 Starting with Junos OS Release 17.4R1, the whitelisting feature is extended to
support custom URL categories supported by UTM in the whitelist configuration
of SSL forward proxy.
17.4R1 Starting with Junos OS Release 17.4R1, the whitelisting feature is extended to
support custom URL categories supported by UTM in the whitelist configuration
of SSL forward proxy.
15.1X49-D80 Starting with Junos OS Release 15.1X49-D80 and Junos OS Release 17.3R1, the
whitelisting feature is extended to include URL categories supported by UTM
in the whitelist configuration of SSL forward proxy. In this implementation, the
Server Name Indication (SNI) field is extracted by the UTM module from client
hello messages to determine the URL category. Each URL category has a
unique ID. The list of URL categories under whitelist is parsed and the
corresponding category IDs are pushed to the Packet Forwarding Engine for
each SSL forward proxy profile. The SSL forward proxy then determines through
APIs whether to accept, and proxy, or to ignore the session.
15.1X49-D30 Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1,
server certificates of key size 4096 bits are supported.
15.1X49-D30 Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1,
TLS version 1.1 and TLS version 1.2 protocols are supported on SRX Series
devices along with TLS version 1.0.
15.1X49-D30 Starting with Junos OS Release 15.1X49-D30 and Junos OS Release 17.3R1,
certificate revocation list (CRL) checks are supported.
15.1X49-D20 Starting with Junos OS Release 15.1X49-D20 and Junos OS Release 17.3R1, the
SSL protocol 3.0 (SSLv3) support is deprecated.
Configuration Statements
active-probe-params
In active probing, custom packets are sent between a spoke device and a hub device on
multiple routes to measure RTT,jitter, and packet loss between the book-ended points.
You can configure to send active probes periodically on all the active and passive links.
Active probing starts after the configuration is committed. A configured number of samples
are collected and used for measuring the SLA. If there is a violation detected for any
application, the probe metrics are evaluated to determine the best possible link for that
application traffic in order to meet performance requirements as in the SLA.
Consider the example, where you configure the probe count as 1000, probe interval as
10 seconds, and burst size as 100. Burst count is calculated as probe count/burst size
(1000/100 = 10). Burst-count is 10. So, probes are sent in sets of 10 bursts each containing
100 packets.
burst-size—Number of probes sent as a burst. This value should be less than or equal to
probe-count.
Range: 1—100
Default: 10
data-fill string—Data payload for a probe packet. This is a hexadecimal string, which is
used the payload for probe.
Syntax actions {
crl {
disable;
if-not-present (allow | drop);
ignore-hold-instruction-code;
}
disable-session-resumption;
ignore-server-auth-failure;
logs {
all;
errors;
info;
sessions-allowed;
sessions-dropped;
sessions-ignored;
sessions-whitelisted;
warning;
}
renegotiation {
(allow | allow-secure | drop);
}
}
Release Information Statement introduced in Junos OS Release 12.1X44-D10. The crl statement is supported
from Junos OS Release 15.1X49-D30.
Description Specify the logging and traffic related actions for a SSL proxy profile.
An SSL proxy profile is required to configure SSL proxy on your SRX Series device. As a
part of the proxy profile configuration, you can configure– actions related to certification
revocations checks, options to specify if a change in SSL parameters requires renegotiation
for a session, option to disable session resumption, option to ignore certificate validation,
root CA expiration dates, and other such issues based on your requirements.
Syntax actions {
crl {
disable;
if-not-present (allow | drop);
ignore-hold-instruction-code;
}
ignore-server-auth-failure;
}
Description Specify the certification revocation checks and traffic related actions for configuring SSL
initiation support service. As a part of SSL initiation profile, you can specify actions related
to certification revocations checks and chose an option to ignore certificate validation,
root CA expiration dates, and other such issues based on your requirements. Commonly
ignored errors include the inability to verify CA signature, incorrect certificate expiration
dates, and so forth. We do not recommend using this option for authentication because
configuring it results in websites not being authenticated at all.
Layer 3 and Layer 4 address mapping defines an application by the IP address and optional
port range of the traffic. You can use the address mapping option to configure custom
applications signatures when the configuration of your private network predicts application
traffic to or from trusted servers.
Address mapping provides efficiency and accuracy in handling traffic from a known
application.
advance-policy-based-routing
Syntax advance-policy-based-routing {
active-probe-params probe-name {
settings {
burst-size {
size;
}
data-fill {
fill;
}
data-size {
size;
}
dscp-code-points {
dscp;
}
probe-count {
count;
}
probe-interval {
interval;
}
enable-sla-export {
interval;
}
}
}
destination-path-group name {
overlay-path {
overlay-path-name;
}
probe-routing-instance {
routing-instance-name;
}
}
from-zone name {
policy name {
description description;
match {
source-address;
destination-address;
application;
destination-address-excluded;
source-address-excluded;
}
then {
application-services {
apbr-profile apbr-profile;
}
}
}
}
metrics-profile metrics-name {
sla-threshold {
delay-round-trip {
delay-value;
}
jitter {
jitter-value;
}
jitter-type {
egress-jitter ;
ingress-jitter;
two-way-jitter;
}
match {
[all | any-one] ;
}
packet-loss {
loss-value;
}
}
overlay-path overlay-path-name {
probe-path {
local ip-address;
remote ip-address
}
tunnel-path {
local ip-address;
remote ip-address
}
}
profile profile-name {
rule rule-name {
match {
dynamic-application [system-application];
dynamic-application-group [system-application-group];
}
then {
routing-instance name ;
}
}
sla-options {
local-route-switch {
[enabled | disabled];
}
logging {
syslog:
}
}
sla-rule sla-rule-name {
active-probe-params {
probe-params-name;
}
metrics-profile {
metric-profile-name;
}
passive-probe-params {
sampling-percentage {
percentage;
}
sampling-period {
period;
}
sla-export-factor {
value;
}
violation-count {
count;
}
switch-idle-time {
period;
}
type {
book-ended;
}
}
traceoptions {
file {
filename ;
files number;
match regular-expression;
size maximum-file-size;
(world-readable | no-world-readable);
}
flag flag;
no-remote-trace;
}
tunables {
drop-on-zone-mismatch;
max-route-change value;
enable-logging;
}
}
You can create an advanced policy-based routing (APBR) profile (application profile)
to match applications and application groups and redirect those matching traffic to the
specified routing instance for the route lookup. The profile includes multiple rules. Each
rule can contain multiple applications or application groups. If the application matches
any of the application or application groups of a rule in a profile, the application profile
rule is considered to be a match.
The APBR profile evaluates the application-aware traffic and permits or denies traffic
based on the applications and application groups.
Options profile profile-name—Name of the profile. Must be a unique name with a maximum
length of 63 characters.
Syntax advance-policy-based-routing;
Description Enable or apply the advanced policy-based (APBR) routing profile (application profile)
on the specified security zone.
To classify and redirect the traffic, the APBR profile matches applications and application
groups and if the matching rule is found, the packets are routed to the routing instance
that sends the traffic to a different interface as specified in the next-hop IP address. So,
you must associate the application profile to the ingress traffic—that is, attach the
application profile to a security zone.
When the application profile is applied to a security zone, then all interfaces belonging
to that zone are attached to the application profile by default unless there is a specific
configuration for an interface belonging to that zone.
appfw-profile (System)
Syntax appfw-profile {
maximum amount;
reserved amount;
}
As a master administrator, you can create a security profile and specify the kinds and
amounts of resources to allocate to a logical system to which the security profile is bound.
A security profile is used for share the device’s resources, including policies, zones,
addresses and address books, flow sessions, and various forms of NAT, among all logical
systems appropriately. You can dedicate various amounts of a resource to the logical
systems and allow them to compete for use of the free resources.
• reserved amount—Specify a reserved quota value that guarantees that the resource
amount specified is always available to the logical system.
appfw-rule
Syntax appfw-rule {
maximum amount;
reserved amount;
}
Description Specify the number of application firewall rule configurations that a master administrator
can configure for a master logical system or user logical system when the security profile
is bound to the logical systems.
• Binds security profiles to the master logical system and the user logical systems
• Can configure more than one security profile, allocating different numbers of resources
in various profiles
Only the master administrator can create security profiles and bind them to logical
systems.
Options • maximum amount—A maximum allowed quota. If a logical system requires more of a
resource than its reserved amount allows, it can use resources configured for the global
maximum amount if they are available—that is, if they are not allocated to other logical
systems. The maximum allowed quota specifies the portion of the free global resources
that the logical system can use. The maximum allowed quota does not guarantee that
the amount specified for the resource in the security profile is available. Logical systems
compete for global resources.
• reserved amount—A reserved quota that guarantees that the resource amount specified
is always available to the logical system.
appfw-rule-set
Syntax appfw-rule-set {
maximum amount;
reserved amount;
}
Description Specify the number of application firewall rule set configurations that a master
administrator can configure for a master logical system or user logical system when the
security profile is bound to the logical systems.
• Binds security profiles to the master logical system and the user logical systems
• Can configure more than one security profile, allocating different numbers of resources
in various profiles
Only the master administrator can create security profiles and bind them to logical
systems.
Options • maximum amount—A maximum allowed quota. If a logical system requires more of a
resource than its reserved amount allows, it can use resources configured for the global
maximum amount if they are available—that is, if they are not allocated to other logical
systems. The maximum allowed quota specifies the portion of the free global resources
that the logical system can use. The maximum allowed quota does not guarantee that
the amount specified for the resource in the security profile is available. Logical systems
compete for global resources.
• reserved amount—A reserved quota that guarantees that the resource amount specified
is always available to the logical system.
application-firewall
Syntax application-firewall {
profile profile-name {
block-message type {
custom-text content custom-html-text;
custom-redirect-url content custom-redirect-url;
}
}
rule-sets rule-set-name {
default-rule {
(deny [block-message] | permit | reject [block-message]);
}
profile profile-name;
rule rule-name {
match {
dynamic-application [system-application];
dynamic-application-groups [system-application-group];
ssl-encryption (any | yes | no);
}
then {
(deny [block-message] | permit | reject [block-message]);
}
}
}
traceoptions {
file {
filename;
files number;
match regular-expression;
(world-readable | no-world-readable);
size maximum-file-size;
}
flag flag;
no-remote-trace;
}
}
Release Information Statement introduced in Junos OS Release 11.1. Updated with the ssl-encryption and reject
options in Junos OS Release 12.1X44-D10. Updated with the block-message option in
Junos OS Release 12.1X45-D10.
Description Specify the profile options, rule set and rule specifications, and trace options to be used
for application firewall implementations.
You can configure the application firewall by defining a collection of rule sets. These rule
sets can be defined independently and shared across network security policies. A rule
set defines the rules that match the application ID detected, based on the application
signature.
The application firewall support in the security policies provides additional security control
for dynamic applications.
Options The remaining statements are explained separately. See CLI Explorer.
You can create custom application signatures by specifying a name, protocol, port where
the application runs, and match criteria. You can create ICMP-based, address-based, IP
protocol-based, and Layer 7-based custom application signatures. Custom applications
are created to to identify applications over Layer 7 and transiting or temporary applications,
and to achieve further granularity of known applications.
Custom application definitions can be used for applications that are not part of the
Juniper Networks predefined application database.
order number—Specify the order for the custom application. Lower order has higher
priority. This option is used when multiple custom applications of the same type
match the same traffic. However, you cannot use this option to prioritize among
different type of applications such as TCP stream-based applications against TCP
port-based applications or IP address-based applications against port-based
applications.
Syntax application-firewall {
rule-set rule-set-name;
}
Hierarchy Level [edit security policies from-zone zone-name to-zone zone-name policy policy-name then
permit application-services]
Description Specify the rule sets configured as part of application firewall to be applied to permitted
traffic in a security policy.
The application firewall is defined by a collection of rule sets. You can implement an
application firewall by defining one or more application firewall rule sets and creating
rules for each rule set that permit, reject, or deny traffic based on the application ID. These
rule sets can be defined independently and shared across network security policies. Then
you configure a security policy to invoke the application firewall service and specify the
rule set to be applied to permitted traffic.
Options rule-set rule-set-name—Name of the rule set that contains application firewall specification
rules.
application-identification
Syntax application-identification {
application application-name {
address-mapping address-name {
filter {
ip ip-address-and-prefix-length;
port-range {
tcp [port];
udp [port];
}
}
}
cacheable;
description;
icmp-mapping {
code number;
type number;
}
ip-protocol-mapping {
protocol number;
}
order;
over protocol-type {
signature name {
member name {
context {
http-get-url-parsed-param-parsed;
http-header-content-type;
http-header-cookie;
http-header-host;
http-header-user-agent;
http-post-url-parsed-param-parsed;
http-post-variable-parsed ;
http-url-parsed;
http-url-parsed-param-parsed;
ssl-server-name;
stream;
}
direction {
any;
client-to-server;
server-to-client;
}
pattern pattern;
}
port-range value;
priority [high | low];
type;
}
application-group group-name {
application-groups application-group-name;
applications application-name;
}
application-system-cache-timeout value;
download {
automatic {
interval hours;
start-time MM-DD.hh:mm;
}
url url;
}
enable-performance-mode max-packet-threshold number;
imap-cache-size number;
imap-cache-timeout number;
no-application-identification;
no-application-system-cache;
statistics {
interval minutes;
}
traceoptions {
file {
filename ;
files number;
match regular-expression;
size maximum-file-size;
(world-readable | no-world-readable);
}
flag flag;
level [all | error | info | notice | verbose | warning]
no-remote-trace;
}
}
Release Information Statement introduced in Junos OS Release 10.2. Custom application definition option
introduced in Junos OS Release 15.1X49-D40.
Once the application is determined, other AppSecure service modules can be configured
to monitor and control traffic for tracking, prioritization, access control, detection, and
prevention based on the application ID of the traffic.
Options The remaining statements are explained separately. See CLI Explorer.
application-group (Services)
Applications can be grouped under predefined and custom application groups. You can
add number of applications or application groups that you want to include in your custom
application group.
You can configure an application group to associates related applications under a single
name for simplified, consistent reuse in configuring application-based policies.
Options group-name—Name of the group. This name is used in policy configuration statements
in place of multiple predefined applications, user-defined applications, or other
groups.
Syntax application-services {
advanced-anti-malware-policy advanced-anti-malware-policy;
application-firewall {
rule-set rule-set;
}
application-traffic-control {
rule-set rule-set;
}
gprs-gtp-profile gprs-gtp-profile;
gprs-sctp-profile gprs-sctp-profile;
idp idp;
(redirect-wx redirect-wx | reverse-redirect-wx reverse-redirect-wx);
security-intelligence-policy security-intelligence-policy;
ssl-proxy {
profile-name profile-name;
}
uac-policy {
captive-portal captive-portal;
}
utm-policy utm-policy;
}
Hierarchy Level [edit security policies from-zone zone-name to-zone zone-name policy policy-name then
permit]
Description Enable application services within a security policy. You can enable service such as
application firewall, IDP, UTM, SSL proxy, and so on by specifying them in a security policy
permit action, when the traffic matches the policy rule.
redirect-wx—Specify the WX redirection needed for the packets that arrive from the
LAN.
uac-policy —Enable Unified Access Control (UAC) for the security policy. This statement
is required when you are configuring the SRX Series device to act as a Junos OS
Enforcer in a UAC deployment.
utm-policy utm-policy—Specify UTM policy name. The UTM policy configured for antivirus,
antispam, content-filtering, traffic-options, and Web-filtering protocols is attached
to the security policy to be applied to the permitted traffic.
application-system-cache
Syntax application-system-cache;
Release Information Statement introduced in Junos OS Release 9.2. The options no-miscellaneous-services
and security-services are introduced in Junos OS Release 18.2R1.
Description Enable application system cache (ASC) to save the mapping between an application
type and the corresponding destination IP address, destination port, protocol type, and
service.
ASC is enabled by default when a session is created. You can manually turn this caching
off using the set services application-identification no-application-system-cache command.
You can re-enable the ASC by using the delete services application-identification
application-system-cache command.
You can enable the ASC for faster application identification process and disable it for
performance benefits and security.
Note the differences in the default behavior of ASC for services starting from Junos OS
Release 18.2R1:
• Security services such as security policies, application firewall (AppFW), Juniper Sky
ATP, IDP, and UTM do not use the ASC by default.
• Miscellaneous services such as APBR and AppTrack use the ASC for application
identification by default.
application-system-cache-timeout (Services)
Release Information Statement introduced in Junos OS Release 9.2. Support for application identification in
the services hierarchy added in Junos OS Release 10.2.
Description Specify the timeout value in seconds for the application system cache (ASC) entries.
ASC saves the mapping between an application type and the corresponding destination
IP address, destination port, protocol type, and service. By default, the ASC saves the
mapping information for 3600 seconds.
NOTE: On SRX Series devices, when you change the timeout value for the
application system cache entries using the command set services
application-identification application-system-cache-timeout, the cache entries
need to be cleared to avoid inconsistency in timeout values of existing entries.
NOTE: ASC is not cleared when the IDP policy is loaded. Users need to
manually clear or wait for the cache entries to expire.
application-tracking
Syntax application-tracking {
disable;
(first-update | first-update-interval first-update-interval);
session-update-interval session-update-interval;
}
Release Information Statement introduced in Junos OS Release 10.2. Support for disable added in Junos OS
Release 11.4.
After application identification identifies the application, AppTrack collects statistics for
the application usage on the device, and when the session closes, AppTrack generates
a message that provides the byte and packet counts and duration of the session, and
sends details to the host device such as Security Threat Response Manager (STRM).
STRM retrieves the data and provides flow-based application visibility details.
• minutes—Maximum number of minutes after session start for the first update
message to be sent. This value must be smaller than the
session-update-interval setting.
Default: 1
Syntax application-tracking;
application-traffic-control
Syntax application-traffic-control {
rate-limiters {
rate-limiter-name {
bandwidth-limit value-in-kbps;
burst-size-limit value-in-bytes;
}
}
rule-sets ruleset-name{
{
rule rule-name {
match {
application application-name1;
application-any;
application-group application-group-name;
application-known;
application-unknown;
}
then {
dscp-code-point dscp-value;
forwarding-class forwarding-class-name;
log;
loss-priority [ high | medium-high | medium-low | low ];
rate-limit {
loss-priority-high;
client-to-server rate-limiter-name;
server-to-client rate-limiter-name;
}
}
}
}
}
}
Description Mark DSCP values for outgoing packets or apply rate limits based on the specified Layer
7 application types.
Options The remaining statements are explained separately. See CLI Explorer.
Syntax application-traffic-control {
rule-set rule-set-name;
}
Hierarchy Level [edit security policies from-zone zone-name to-zone zone-name policy policy-name then
permit application-services]
Description Enables AppQoS, application-aware quality of service, as specified in the rules of the
specified rule set.
Options • rule-set rule-set-name—Name of the rule set that contains application-aware traffic
control specification rules.
Syntax authorization {
authorization-type authorization-type;
credentials (ascii ascii | base64 base64);
}
Description User authentication for the ICAP server if the request needs to be authorized.
Options authorization-type—Authentication type for the ICAP server. Authorization type is basic
by default.
Description Defines the profile of the notification to be sent to clients when HTTP or HTTPS traffic
is blocked by a reject or deny action from an application firewall.
NOTE: The block message option is not supported for non-HTTP traffic such
as FTP, SSH, Telnet, and so on. In these instances, if the action is drop or
reject, the traffic is silently dropped or rejected. The user is not informed of
the action and no redirection occurs. The associated system log message
identifies the action taken for this traffic.
The reject or deny message actions are logged with the reason field containing
one of the following phrases:
• appfw deny
• appfw reject
Following sample shows a system log message for SSH traffic, where the
traffic was rejected:
NOTE: You need to enable SSL forward proxy for the HTTPS traffic that
needs to be blocked by a reject or a deny action from an application firewall.
When the block-message option is specified, a splash screen and message inform the
client that the traffic has been blocked. The default message text is:
The variables in the message are replaced with specific traffic values. For clarity, the
prefix junos: is truncated from the application name.
NOTE: You need to enable SSL forward proxy for the HTTPS traffic,that
needs to be blocked by a reject or a deny action from an application firewall.
Options Use the following option pairs to customize the default message or to redirect the client
to a custom webpage instead of the default splash screen.
NOTE: Both the type and content fields must be used to add custom text or
redirect the client to a URL.
When specified, the user is redirected when a reject or deny action is taken during
one of the following HTTP methods: GET, POST, OPTIONS, HEAD, PUT, DELETE,
TRACE, CONNECT, PROPFIND, PROPPATCH, LOCK, UNLOCK, COPY, MOVE, MKCOL,
BCOPY, BDELETE, BCOPY, BMOVE, BPROPFIND, BPROPPATCH, POLL, SEARCH,
SUBSCRIBE, and UNSUBSCRIBE. If the reject or deny action occurs during a different
HTTP method, the traffic is silently dropped.
• custom-redirect-url—URL redirection.
NOTE: The content value must match the type option selected: custom-text
requires text, and custom-redirect-url requires a URL value.
Enter the redirect URL in quotation marks for an HTTP or HTTPS site, as shown in
the following examples:
“http://custom-redirect-url”
“https://custom-redirect-url”
Syntax context {
http-get-url-parsed-param-parsed;
http-header-content-type;
http-header-cookie;
http-header-host;
http-header-user-agent;
http-post-url-parsed-param-parsed;
http-post-variable-parsed ;
http-url-parsed;
http-url-parsed-param-parsed;
ssl-server-name;
stream;
}
Description Specify context for matching application running over TCP, UDP, or Layer 7.
ssl-server-name —Server name in the TLS server name extension or the SSL server
certificate. This is also known as Server Name Indication (SNI).
Starting from Junos OS release 15.1X49-D60 and Junos OS Release 17.3R1, when
configuring custom application signatures, the context-direction combinations as
mentioned in Table 29 on page 270 is supported. Any other combination other than
this is not supported.
Context Direction
http-get-url-parsed-param-parsed client-to-server
http-header-host client-to-server
http-header-user-agent client-to-server
http-post-url-parsed-param-parsed client-to-server
http-post-variable-parsed client-to-server
http-url-parsed client-to-server
http-url-parsed-param-parsed client-to-server
ssl-server-name client-to-server
stream any/client-to-server/server-to-client
http-header-content-type any/client-to-server/server-to-client
http-header-cookie any/client-to-server/server-to-client
crl
Syntax crl {
disable disable;
if-not-present (allow | drop);
ignore-hold-instruction-code ignore-hold-instruction-code;
}
Release Information Statement introduced in Junos OS Release 15.1X49-D30. This statement is supported in
the SRX340, SRX345, SRX550M, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600,
and SRX5800 devices and vSRX instances.
CRL validation on SRX Series device involves checking for revoked certificates from
servers. You can enable or disable the CRL validation to meet your specific security
requirements. You can allow or drop the sessions when a CRL information is not available.
To enhance security, the certificate revocation checking feature has been enabled by
default on SRX Series devices on any SSL proxy profile.
Related • Working with the Certificate Revocation Lists for SSL Proxy on page 216
Documentation
custom-ciphers
Description Configure custom cipher, which SSH server can use to perform encryption and decryption
functions.
Custom ciphers allow you to define your own cipher list. If you do not want to use one of
the three categories, you can select ciphers from each of the categories to form a custom
cipher set.
default-rule
Syntax default-rule {
(deny [block-message] | permit | reject [block-message]);
}
Release Information Statement introduced in Junos OS Release 11.1. Statement updated in Junos OS Release
12.1X44-D10 with the reject option. The block-message option added in Junos OS Release
12.1X45-D10.
Description Configure the default rule that defines the actions to be performed on a packet that does
not match any defined rule.
An application firewall permits, rejects, or denies traffic based on the application of the
traffic. The firewall consists of one or more rule sets with rules that specify match criteria,
including dynamic applications, and the action to be taken for matching traffic. The
application firewall rule set must contain a single default rule. The default rule defines
the action to be taken for any traffic that does not match one of the rules.
Options • deny—Block the traffic at the firewall. The device drops the packet. No message is
returned to the sender.
• reject—Block the traffic at the firewall. For TCP traffic, by default the device drops the
packet and returns a TCP reset (RST) message to the source host and to the server in
some cases. For UDP and other protocol traffic, by default the device drops the packet
and returns an ICMP “destination unreachable, port unreachable” message to both
the client and the server.
Related • Example: Configuring Application Firewall Rule Sets Within a Security Policy on page 82
Documentation
destination-path-group
Description Define a group containing multiple overlay paths terminating at a same destination.
Syntax direction {
any;
client-to-server;
server-to-client;
}
Description The connection direction of the packets to apply pattern matching. You can specify
match patterns on both client to server and server to client while configuring custom
application signatures.
Options any—The directions of packets are either from client-side to server-side or from server-side
to client-side.
Syntax disable;
Description Disable application tracking on a device without deleting the zone configuration.
[edit]
user@host# delete security application-tracking disable
download (Services)
Syntax download {
automatic {
interval hours;
start-time MM-DD.hh:mm;
}
url url;
Description Configure automatic download for the application identification services application
package.
The application package contains definitions for known applications, such as: DNS,
Facebook, FTP, Skype, and SNMP. The application package is extracted from the IDP
signature database located at https://signatures.juniper.net. If you do not have access
to the default download site from your device, you can use the URL option to download
from a different location.
• url—Use this option to change the default download location of the application package.
dynamic-application
Hierarchy Level [edit security application-firewall rule-sets rule-set-name rule rule-name match]
Description Specify the dynamic application names for match criteria in application firewall rule set.
dynamic-application-group
Hierarchy Level [edit security application-firewall rule-sets rule-set-name rule rule-name match]
Description Specify the dynamic application group to match. When you define application firewall
rules, you can specify dynamic application groups as match criteria.
enable-flow-tracing (Services)
Syntax enable-flow-tracing;
Release Information Statement introduced in Junos OS Release 12.1X44-D10. This statement is supported on
the SRX550M, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800
devices.
When you configure enable-flow-tracing for SSL profiles, the debug tracing will be enabled
on that profile when the flag is set as selected-profile.
enable-performance-mode
Description Set the deep packet inspection (DPI) in performance mode for application identification.
The application traffic throughput can be improved by setting the DPI in performance
mode with default packet inspection limit as two packets, including both client-to-server
and server-to-client directions. By default, performance mode is disabled on SRX Series
devices.
If you want to set DPI to default accuracy mode and disable the performance mode,
delete the configuration statement that specifies enabling of the performance mode by
using the delete services application-identification enable-performance-mode command.
Options max-packet-threshold number—Set the maximum packet threshold for DPI performance
mode.
Range: 1 through 100
Default: 2
enable-reverse-reroute
Syntax enable-reverse-reroute;
Description Reroute the reverse traffic when there is a link switch for the incoming traffic.
When you configure the enable-reverse-reroute option for a security zone, then the packets
of each session that has been initiated from the zone are checked for the change in the
incoming interface. When an incoming packet arrives on an interface that is different
from the one cached in session, the route lookup is performed for the reverse path, and
the preference is given to the interface on which the packet has arrived when there are
ECMP routes available to the source. Ensure that when you configure
enable-reverse-reroute option, the new interface on which packets arrive must be part
of the same zone as the earlier interface.
You can enable reverse rerouting in hub-and-spoke deployments, where a spoke device
uses APBR to re-route the traffic based on the dynamic applications. In such cases reverse
re-route can be used on hub device to correctly re-route the reverse traffic.
enable-session-cache
Syntax enable-session-cache;
Release Information Statement introduced in Junos OS Release 12.1X44-D10. This statement is supported on
the SRX550M, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices.
You can enable session caching to cache session information, such as the pre-master
secret key and agreed-upon ciphers, for both the client and server.
Syntax fallback-option {
connectivity (block | log-permit | permit);
default-action (block | log-permit | permit);
timeout (block | log-permit | permit);
}
Description Specify fallback options for the device. Fallback settings enable the device to handle
errors.
The fallback option is used to define the actions such as permit, log-and-permit, or block.
This is the action that occurs when a request fails due to conditions such as too many
requests, or a timeout occurred, or connectivity issues.
Release Information Statement introduced before Junos OS Release 12.1X47 for SRX Series.
• no-binary-data—Do not mark the file such that it contains binary data.
• start-time—Specify the start time for file transmission. Enter the start time in the
yyyy-mm-dd.hh:mm format.
• brief—Omit English language text from the end of the logged message.
flag (Services)
Release Information Statement introduced in Junos OS Release 12.1X44-D10. This statement is supported on
the SRX1500, SRX5400, SRX5600, and SRX5800 devices and vSRX.
Release Information Statement introduced prior to Junos OS Release 10.0. Statement updated in Junos OS
Release 12.1.
Description Set the default log format for event mode security logging on the device.
Default: syslog.
forwarding-classes (CoS)
Syntax forwarding-classes {
class class-name {
priority (high | low);
queue-num number;
spu-priority (high | low | medium-high | medium-low);
}
queue queue-number {
class-name {
priority (high | low);
}
}
}
Release Information Statement introduced in Junos OS Release 8.5. Statement updated in Junos OS Release
11.4. The spu-priority option introduced in Junos OS Release 11.4R2.
Options • class class-name—Display the forwarding class name assigned to the internal queue
number.
global-config (Services)
Syntax global-config {
disable-cert-cache;
certificate-cache-timeout;
invalidate-cache-on-crl-update;
session-cache-timeout seconds;
}
Description Specify the global proxy configuration. When SSL proxy is configured at a global level
(within “services ssl proxy”), it is visible across the system configurations on the device.
Syntax http {
redirect-request;
redirect-response;
}
Description Enable the redirect request and the redirect response for the HTTP traffic.
You can forward HTTP requests and HTTP responses to a Internet Content Adaptation
Protocol (ICAP) server before sending a request to a Web server or returning a response
to the client system.
The SRX Series device decrypts the HTTPS traffic and redirects the HTTP message to a
third-party, on-premise, DLP server using the ICAP channel. After DLP processing, the
traffic is reflected back to the SRX Series device.
icap-redirect
Syntax icap-redirect {
profile name {
fallback-option {
connectivity (block | log-permit | permit);
default-action (block | log-permit | permit);
timeout (block | log-permit | permit);
}
http {
redirect-request redirect-request;
redirect-response redirect-response;
}
server name {
authorization {
authorization-type authorization-type;
credentials (ascii ascii | base64 base64);
}
host host;
port port;
reqmod-uri reqmod-uri;
respmod-uri respmod-uri;
routing-instance ri-name;
sockets sockets;
tls-profile tls-profile;
}
timeout timeout;
}
traceoptions {
file <filename> <files files>< match match><size size> (world-readable |
no-world-readable)>;
flag name;
no-remote-trace no-remote-trace;
}
}
The SRX Series device acts as an SSL proxy, decrypts HTTP or HTTPS traffic, and redirects
the HTTP message to a third-party, on-premise DLP server through the Internet Content
Adaptation Protocol (ICAP) channel. To enable ICAP redirection service, you must
configure an ICAP redirect profile.
The ICAP server profile allows the ICAP server to process request messages, response
messages, fallback options, and so on, to the permitted traffic. This profile is applied as
an application service in the security policy.
Syntax icmp-mapping {
code number;
type number;
}
Description Specify the Internet Control Message Protocol (ICMP) value for an application to match
while configuring custom application signatures for Junos OS application identification.
The ICMP mapping technique maps standard ICMP message types and optional codes
to a unique application name. The ICMP code and type provide additional specification,
for packet matching in an application definition.
Options code number—Numeric value of an ICMP code. The code field provides further information
about the associated type field.
Range: 0-254
type number—Numeric value of an ICMP type. The type field identifies the ICMP message.
Range: 0-254
Syntax ip-protocol-mapping {
protocol number;
}
Description Specify the IP protocol value for an application to match. This parameter is used to
identify an application based on IP and is intended only for IP traffic. To ensure adequate
security, use IP protocol mapping only in your private network for trusted servers.
You can find a complete list of industry standard protocol numbers at the IANA website.
initiation (Services)
Syntax initiation{
profile name {
actions {
crl {
disable disable;
if-not-present (allow | drop);
ignore-hold-instruction-code ignore-hold-instruction-code;
}
ignore-server-auth-failure ignore-server-auth-failure;
}
client-certificate client-certificate;
custom-ciphers (ecdhe-rsa-with-3des-ede-cbc-sha | ecdhe-rsa-with-aes-128-cbc-sha
| ecdhe-rsa-with-aes-128-cbc-sha256 | ecdhe-rsa-with-aes-128-gcm-sha256 |
ecdhe-rsa-with-aes-256-cbc-sha | ecdhe-rsa-with-aes-256-cbc-sha384 |
ecdhe-rsa-with-aes-256-gcm-sha384 | rsa-export-with-des40-cbc-sha |
rsa-export-with-rc4-40-md5 | rsa-export1024-with-des-cbc-sha |
rsa-export1024-with-rc4-56-md5 | rsa-export1024-with-rc4-56-sha |
rsa-with-3des-ede-cbc-sha | rsa-with-aes-128-cbc-sha | rsa-with-aes-128-cbc-sha256
| rsa-with-aes-128-gcm-sha256 | rsa-with-aes-256-cbc-sha |
rsa-with-aes-256-cbc-sha256 | rsa-with-aes-256-gcm-sha384 | rsa-with-des-cbc-sha
| rsa-with-null-md5 | rsa-with-null-sha | rsa-with-rc4-128-md5 | rsa-with-rc4-128-sha);
enable-flow-tracing enable-flow-tracing;
enable-session-cache enable-session-cache;
preferred-ciphers (custom | medium | strong | weak);
protocol-version (all | ssl3 | tls1 | tls11 | tls12);
trusted-ca ;
}
}
Release Information Statement introduced in Junos OS Release 12.1X44-D10. The protocol-version statement
is updated to include tls11 and tls12 from Junos OS Release 15.1X49-D30.
Description Specify the configuration for Secure Socket Layer (SSL) initiation support service. The
SRX Series device, acting as an SSL proxy client, initiates and maintains SSL sessions
between itself and an SSL server. SRX device receives un-encrypted data from an HTTP
client, and encrypts and transmits the data as ciphertext to the SSL server.
level (Services)
Description Specify the level of debugging the output. This statement is supported on the SRX550M,
SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and vSRX.
log (Security)
Syntax log {
cache {
exclude exclude-name {
destination-address destination-address;
destination-port destination-port;
event-id event-id;
failure;
interface-name interface-name;
policy-name policy-name;
process process-name;
protocol protocol;
source-address source-address;
source-port source-port;
success;
user-name user-name;
}
limit value;
}
disable;
event-rate rate;
facility-override (authorization | daemon | ftp | kernel | local | user);
file {
files max-file-number;
name file-name;
path binary-log-file-path;
size maximum-file-size;
}
format (binary | sd-syslog | syslog);
max-database-record <max-database-record>;
mode (event | stream);
rate-cap <rate-cap-value>;
report;
(source-address source-address | source-interface interface-name);
stream stream-name {
category (all | content-security | fw-auth | screen | alg | nat | flow | sctp | gtp | ipsec | idp
| rtlog |pst-ds-lite | appqos |secintel);
file {
name file-name;
size file-size;
rotation max-rotation-number;
}
filter {
threat-attack;
}
format (binary | sd-syslog | syslog | welf);
host {
ip-address;
port port-number;
}
rate-limit {
log-rate;
}
Description Configure security log. Set the mode of logging (event for traditional system logging or
stream for streaming security logs through a revenue port to a server). You can also
specify all the other parameters for security logging.
event-rate rate—Limit the rate at which logs are streamed per second.
Range: 0 through 1500
Default: 1500
file—Specify the security log file options for logs in binary format.
Values:
• max-file-number—Maximum number of binary log files.
max-database-record—The following are the disk usage range limits for the database:
Range:
• SRX1500, SRX4100, and SRX4200: 0 through 15,000,000
Default:
• SRX1500, SRX4100, and SRX4200: 15,000,000
• vSRX: 1,000,000
rate-cap rate-cap-value—Work with event mode only. This option limits the rate at which
data plane logs are generated per second.
Range: 0 through 5000 logs per second
Default: 5000 logs per second
• The range is 1 through 65,535 logs per second and the default value is 65,535 .
log (Services)
Syntax log {
all;
errors;
info;
sessions-allowed;
sessions-dropped;
sessions-ignored;
sessions-whitelisted;
warning;
}
Description Specify the logging actions. When configuring SSL proxy, you can choose to set the option
to receive some or all of the logs.
SSL proxy logs contain the logical system name, SSL proxy whitelists, policy information,
SSL proxy information, and other information that helps you troubleshoot when there is
an error.
You can configure logging of all or specific events, such as error, warning, and information
events. You can also configure logging of sessions that are whitelisted, dropped, ignored,
or allowed after an error occurs.
maximum-transactions
Application classification does not terminate for applications that are transaction based
such as Facebook applications. To terminate the application classifications for such
applications, you can choose to consider the results from multiple transaction as the
final classification. You can configure the number of transactions before concluding the
final result for the identified application.
For example, when you configure the maximum number of transactions as 10, the
following sequence is applied for identifying the final application:
• In the first and second transactions, application-1 and application-2 are identified
respectively.
• Since 10th transaction is equal to the configured value of the maximum number of
transactions, the application identified in this transaction is considered as the final
match.
Range: 0 through 25
Default: 5
no-application-identification (Services)
Syntax no-application-identification;
no-application-system-cache (Services)
Syntax no-application-system-cache;
Description Application identification information is saved in the application system cache to improve
performance. This cache is updated when a different application is identified. This caching
is turned on by default. Use the no-application-system-cache statement to turn it off.
ASC is enabled by default when a session is created. You can manually turn this caching
off using the set services application-identification no-application-system-cache command.
You can re-enable the ASC by using the set services application-identification
application-system-cache command.
Related • Enabling or Disabling Application System Cache for Application Services on page 28
Documentation
ngfw
Syntax ngfw {
default-profile {
application-traffic-control {
rule-set rule-set;
}
ssl-proxy {
profile-name profile-name;
}
}
}
Description Specify a default profile to manage conflicts when a security policy lookup returns a list
of policies before the final application is identified.
The initial policy lookup phase occurs prior to identifying a dynamic application. If there
are multiple policies present in the potential policy list that contain different SSL proxy
profiles, then the SRX Series device applies the default profile until a more explicit match
has occurred.
You can configure a default profile for an SSL proxy and for an application quality of
service (AppQoS) under the [edit security ngfw] hierarchy level.
You can configure an SSL proxy profile under the [edit services ssl proxy] hierarchy level,
which can be applied as the default SSL proxy profile under the [edit security ngfw]
hierarchy level. Similarly, you can configure application traffic rule sets under the [edit
class-of-service] hierarchy level, and apply the rule set under the [edit security ngfw]
hierarchy level as the default AppQoS rule set.
ssl-proxy—Specify the SSL forward proxy profile or the SSL reverse proxy profile as the
default profile.
Configure a custom signature based on Layer 4/Layer 7 applications. You create Layer
7-based custom application signatures for the identification of multiple applications
running on the same Layer 7 protocols. For example, applications such as Facebook and
Yahoo Messenger can both run over HTTP, but there is a need to identify them as two
different applications running on the same Layer 7 protocol.
signature name —Name of the custom application signature. Must be a unique name
with a maximum length of 63 characters.
member name —Member name for a custom application signature. Custom signatures
can contain multiple members that define attributes for an application. (The
supported member name range is m01 through m15.)
overlay-path
Description Configure overlay path to specify the destinations to which the active probe data needs
to be sent. Overlay paths are configured for all overlay endpoints. Overlay path
configuration includes two set of IP addresses—tunnel IP addresses and probe IP
addresses.
You need to create the overlay setup between local and remote endpoints on both ends
of the overlay (spoke device and hub device).
probe-path—Probe IP addresses are used as probes’ start and end addresses to send
over the corresponding tunnel paths. Probe IP addresses must be unique across
individual overlay paths.
passive-probe-params
Syntax passive-probe-params {
sampling-percentage {
percentage;
}
sampling-period {
period;
}
sla-export-factor {
value;
}
type {
book-ended;
}
violation-count {
count;
}
Description Configure the passive probe parameters with the SLA rule.
Passive probes measure the service quality of an application by inserting a custom probe
header in the live traffic between the spoke and hub points and measuring the RTT, jitter
and packet loss between the points of installation of the probes.
Example: If 18 sessions are available for a particular application are available, and
if you have configured 25%, then 25% of the 18 sessions—that is 5 sessions out of
18 sessions, are evaluated.
Range: 1-100
Range: 5-200
Default: 25
policies
Syntax policies {
default-policy (deny-all | permit-all);
from-zone zone-name to-zone zone-name {
policy policy-name {
description description;
match {
application {
[application];
any;
}
destination-address {
[address];
any;
any-ipv4;
any-ipv6;
}
source-address {
[address];
any;
any-ipv4;
any-ipv6;
}
source-identity {
[role-name];
any;
authenticated-user;
unauthenticated-user;
unknown-user;
}
}
scheduler-name scheduler-name;
then {
count {
alarm {
per-minute-threshold number;
per-second-threshold number;
}
}
deny;
log {
session-close;
session-init;
}
permit {
application-services {
application-firewall {
rule-set rule-set-name;
}
application-traffic-control {
rule-set rule-set-name;
}
gprs-gtp-profile profile-name;
gprs-sctp-profile profile-name;
idp;
idp-policy idp-policy;
redirect-wx | reverse-redirect-wx;
ssl-proxy {
profile-name profile-name;
}
uac-policy {
captive-portal captive-portal;
}
utm-policy policy-name;
}
destination-address {
drop-translated;
drop-untranslated;
}
firewall-authentication {
pass-through {
access-profile profile-name;
client-match user-or-group-name;
ssl-termination-profile profile-name;
web-redirect;
web-redirect-to-https;
}
user-firewall {
access-profile profile-name;
domain domain-name
ssl-termination-profile profile-name;
}
web-authentication {
client-match user-or-group-name;
}
}
services-offload;
tcp-options {
sequence-check-required;
syn-check-required;
}
tunnel {
ipsec-group-vpn group-vpn;
ipsec-vpn vpn-name;
pair-policy pair-policy;
}
}
reject;
}
}
}
global {
policy policy-name {
description description;
match {
application {
[application];
any;
}
destination-address {
[address];
any;
any-ipv4;
any-ipv6;
}
from-zone {
[zone-name];
any;
}
source-address {
[address];
any;
any-ipv4;
any-ipv6;
}
source-identity {
[role-name];
any;
authenticated-user;
unauthenticated-user;
unknown-user;
}
to-zone {
[zone-name];
any;
}
}
scheduler-name scheduler-name;
then {
count {
alarm {
per-minute-threshold number;
per-second-threshold number;
}
}
deny;
log {
session-close;
session-init;
}
permit {
application-services {
application-firewall {
rule-set rule-set-name;
}
application-traffic-control {
rule-set rule-set-name;
}
gprs-gtp-profile profile-name;
gprs-sctp-profile profile-name;
idp;
idp-policy idp-policy;
redirect-wx | reverse-redirect-wx;
ssl-proxy {
profile-name profile-name;
}
uac-policy {
captive-portal captive-portal;
}
utm-policy policy-name;
}
destination-address {
drop-translated;
drop-untranslated;
}
firewall-authentication {
pass-through {
access-profile profile-name;
client-match user-or-group-name;
ssl-termination-profile profile-name;
web-redirect;
web-redirect-to-https;
}
web-authentication {
client-match user-or-group-name;
}
}
services-offload;
tcp-options {
initial-tcp-mss mss-value;
reverse-tcp-mss mss-value;
sequence-check-required;
syn-check-required;
}
}
reject;
}
}
}
policy-rematch;
policy-stats {
system-wide (disable | enable) ;
}
traceoptions {
file {
filename;
files number;
match regular-expression;
size maximum-file-size;
(world-readable | no-world-readable);
}
flag flag;
no-remote-trace;
}
}
policy (advanced-policy-based-routing)
You can create APBR policies for a security zone and apply advanced policy-based routing
(APBR) profiles on the traffic that matches the policy.
In the APBR policy, you can define source addresses, destination addresses, and
applications as match conditions; and after a successful match, the configured APBR
profile is applied as an application services for the session.
The routing instance associated with APBR profile includes a static route and next hop
configured. The matching traffic arriving at the trust zone is forwarded to a specific device
or interface as specified by the next-hop IP address.
NOTE: When using specific address or address set in the APBR policy rule,
we recommend to use the global address book. Because, zone specific rules
might not be applicable for destination address, as the destination zone is
not known at time of policy evaluation.
then—Specify the policy action to be performed when packets match the defined criteria.
redirect-wx | reverse-redirect-wx;
ssl-proxy {
profile-name profile-name;
}
uac-policy {
captive-portal captive-portal;
}
utm-policy policy-name;
}
destination-address {
drop-translated;
drop-untranslated;
}
firewall-authentication {
pass-through {
access-profile profile-name;
client-match user-or-group-name;
web-redirect;
}
user-firewall {
access-profile profile-name;
domain domain-name
ssl-termination-profile profile-name;
}
web-authentication {
client-match user-or-group-name;
}
}
services-offload;
tcp-options {
initial-tcp-mss mss-value;
reverse-tcp-mss mss-value;
sequence-check-required;
syn-check-required;
}
tunnel {
ipsec-group-vpn group-vpn;
ipsec-vpn vpn-name;
pair-policy pair-policy;
}
}
reject;
}
}
Release Information Statement introduced in Junos OS Release 8.5. The services-offload option added in
Junos OS Release 11.4. Statement updated with the source-identity option and the
description option added in Junos OS Release 12.1. Support for the user-firewall option
added in Junos OS Release 12.1X45-D10. Support for the initial-tcp-mss and
reverse-tcp-mss options added in Junos OS Release 12.3X48-D20.
The junos-twamp application is introduced in Junos OS Release 18.2R1.
Syntax port-range {
tcp [port];
udp [port];
}
Description Specify a port to match a TCP or UDP destination port for Layer 3 and Layer 4
address-based custom applications.
Layer 3 and Layer 4 address-based custom applications, you can match the IP address
and port range to destination IP address and port. When both IP address and port are
configured, both should match destination tuples (IP address and port range) of the
packet. The format for numeric port ranges is in the format
minimum-value–maximum-value.
Options • tcp [port]—Define the TCP port range for the application.
preferred-ciphers
Description Select preferred ciphers. Preferred ciphers allow you to define an SSL cipher that can be
used with acceptable key strength. Ciphers are divided in three categories depending on
their key strength: strong, medium, or weak.
Custom ciphers allow you to define your own cipher list. If you do not want to use one of
the three categories, you can select ciphers from each of the categories to form a custom
cipher set. To configure custom ciphers, you must set preferred-ciphers to custom.
Description Define the profile of the response to be issued when an application firewall rule set blocks
HTTP or HTTPS traffic with a deny or reject action.
Although drop and reject actions are logged, application firewall does not notify users
when either action is taken. To provide an explanation for the action or to redirect the
users to an informative webpage, you can use the block-message option with the reject
or deny action in an application firewall rule.
You can customize the redirect action by including additional text on the splash screen
or by specifying a URL to which the user is redirected. To customize the block message,
define the type and content in a block message profile defined in the rule set.
profile (icap-redirect)
The ICAP server profile allows the ICAP server to process request messages, response
messages, fallback options, and so on, for the permitted traffic.
When you configure an ICAP redirect service on SRX Series devices, you must configure
the ICAP redirect profile. The ICAP redirect profile defines the settings for ICAP server to
process request messages, response messages, fallback options incase of a timeout,
connectivity issues, too many requests, or other conditions.
This profile is applied to a security policy as an application service when the traffic is
permitted by the security policy.
fallback-option—Fallback options to specify the actions the device applies if the ICAP
server is unavailable.
Values:
• redirect-request—Enable the redirect service on HTTP request
Description Specifies the profile of the block message to be used for any deny or reject action in the
rule set that specifies the block-message option.
The block-message option enables you to provide an explanation for the action or to
redirect the client to an informative webpage. You can configure the block-message in
set security application-firewall profile hierarchy.
Options profile-name—Name of the block-message profile to be used for this rule set.
Release Information Statement introduced in Junos OS Release 12.1X44-D10. The crl statement is supported
from 15.1X49-D30.
Description Specify the SSL server profile. An SSL proxy profile defines SSL behavior for the SRX
Series device.
The SSL proxy profile will be applied to the security policy as application services.
Release Information Statement introduced in Junos OS Release 12.1X44-D10. The protocol-version statement
is updated to include tls11 and tls12 from Junos OS Release 15.1X49-D30.
Description Specify the name of the profile for SSL initiation support service.
The SRX Series device, acting as an SSL proxy client, initiates and maintains SSL sessions
between itself and an SSL server. SRX device receives un-encrypted data from an HTTP
client, and encrypts and transmits the data as ciphertext to the SSL server.
client-certificate—Local certificate.
Description Specify the name of the profile for SSL termination support service.
The SRX Series device, acting as an SSL proxy server, terminates the SSL session from
the client and then establishing a new SSL connection to the server. The SRX Series
device decrypts the data and then sends the data as un-encrypted request to the other
servers (HTTP server).
The SSL proxy profile will be applied to the security policy as application services.
Options custom-ciphers—Configure custom cipher, which SSH server can use to perform
encryption and decryption functions.
protocol-version
Release Information Statement introduced in Junos OS Release 12.1X44-D10. The tls11 and tls12 options are
introduced in 15.1X49-D30.
You can specify the SSL/TLS protocol version the SRX Series device uses to negotiate
in SSL connections.
• TLS version 1.0—Accept TLS version 1.0. It provides secure communication over networks
by providing privacy and data integrity between communicating applications
• TLS version 1.1—Accept TLS version 1.1. This enhanced version of TLS provides protection
against cipher-block chaining (CBC) attacks.
• TLS version 1.2 —Accept TLS version 1.2. This enhanced version of TLS provides improved
flexibility for negotiation of cryptographic algorithms.
proxy (Services)
Syntax proxy {
global-config {
session-cache-timeout seconds;
}
profile profile-name {
actions {
crl {
disable;
if-not-present (allow | drop);
ignore-hold-instruction-code;
}
disable-session-resumption;
ignore-server-auth-failure;
logs {
all;
errors;
info;
sessions-allowed;
sessions-dropped;
sessions-ignored;
sessions-whitelisted;
warning;
}
renegotiation {
(allow | allow-secure | drop);
}
}
custom-ciphers [cipher];
enable-flow-tracing;
preferred-ciphers (custom | medium | strong | weak);
root-ca root-certificate;
trusted-ca (all | [ca-profile] );
whitelist [global-address-book-addresses];
}
}
Release Information Statement introduced in Junos OS Release 12.1X44-D10. The crl statement is supported
from 15.1X49-D30.
Description Specify the configuration for Secure Socket Layer (SSL) proxy support service.
Options The remaining statements are explained separately. See CLI Explorer.
rate-limiters
Syntax rate-limiters {
rate-limiter-name {
bandwidth-limit value-in-kbps;
burst-size-limit value-in-bytes;
}
}
Description Share the available bandwidth and burst size of a device’s PICs by defining rate limiter
profiles and applying them in AppQoS rules.
Options • rate-limiter-name—Name of the rate limiter. It is applied in AppQoS rules to share device
resources based on quality-of-service requirements.
A maximum of 1000 rate limiters can be created. Rate limiters are defined for the
device, and are assigned in rules in a rule set. A single rate limiter can be used multiple
times within the same rule set. However, the rate limiter cannot be used in another rule
set.
renegotiation (Services)
root-ca (Services)
Description Root certificate for interdicting server certificates in proxy mode. This statement is
supported on the SRX1500, SRX5400, SRX5600, and SRX5800 devices and vSRX.
Options root-ca-name—Specify root certificate for interdicting server certificates in proxy mode.
Hierarchy Level [edit security advance-policy-based-routing profile profile-name rule rule-name then]
Description Specify a specific routing instance to which the device sends the matched packets.
When traffic arrives at the specified zone or interface, it is matched by the advanced
policy-based routing (APBR) profile (application profile). The application profile matches
applications and application groups and if the matching rule is found, the packets are
routed to the routing instance that sends the traffic to a different interface as specified
in the next-hop IP address.
The routing instances specify the routing table and the destination to which a packet is
forwarded. The following types of routing instances are supported:
• Virtual router—Similar to the forwarding instance type, but used for non-VPN-related
applications.
Description Configure rules for the advanced policy-based routing (APBR) profile (application profile).
Associate the rule with one or more than one applications (example: for HTTP) or
application groups.
The deep packet inspection and pattern matching capabilities of AppID to identify
application traffic and application system cache (ASC) is consulted to get application
type for matching the rule condition.
If the application matches any of the application or application groups of a rule in a profile,
the application profile rule is considered as a match and the traffic will be redirected to
the defined routing instance for the route lookup.
Options match—Define an APBR term as dynamic application or dynamic application group for
match criteria.
then—Define the action for matching condition by specifying the name of the routing
instance for redirecting traffic.
Release Information Statement introduced in Junos OS Release 11.1. Statement updated in Junos OS Release
12.1X44-D10 to include the ssl-encryption and reject options. The block-message options
added in Junos OS Release 12.1X45-D10.
You need to create rules to permit, reject, or deny traffic for dynamic applications to
configure application firewall rule sets within the security policy. The application firewall
support in the policies provides additional security control for dynamic applications.
• no—Non-encrypted rule.
• yes—Encrypted rule.
then—Specify the action to be performed when traffic matches the associated match
criteria.
deny—Block the traffic at the firewall. The device drops the packet. By default, no
message is returned to the sender.
reject—Block the traffic at the firewall. For TCP traffic, by default the device drops
the packet and returns a TCP reset (RST) message to the source host. For UDP
and other protocol traffic, by default the device drops the packet and returns
an ICMP “destination unreachable, port unreachable” message to both the client
and the server.
metrics-profile
Description Create a set of metrics, which can be used by AppQoE to evaluate the SLA of the link.
A metrics profile defines the performance metrics for delay round trip, one-way jitter or
two-way jitter, and packet loss.
To ensure compliance with the SLA, metrics are required to measure and monitor the
network performance. This measurement capability provides a greater visibility into the
performance characteristics of the links and helps in network performance evaluation.
jitter jitter-value—Total jitter (in microseconds) for a test, which, if exceeded, triggers a
probe failure
jitter-type—Jitter type.
Values: Ingress jitter, egress jitter, and two-way jitter.
Default: Two-way jitter
all—The path selection mechanism attempts to find a path that satisfies all the
metrics. If no such path exists, then the next best path (based on number of
metrics satisfied) is used. If there are more than one path that satisfy the metric,
a random path among the available paths will be selected. Also, SLA violation
will be detected and raised even if any one of the metrics is violated.
any—Path selection mechanism attempts to find a path which satisfies the maximum
number of metrics. For example, if there is a path available that conforms to
more than one metric, then the path is chosen over another path which satisfies
less number of metrics. In this case, SLA violation is detected only when none
of the metrics meets the requirement. If either one of the metric is meets the
requirement, then violation is not triggered.
Syntax rule-sets {
rule-set-name {
rule rule-name {
match {
application application-name;
application-any;
application-group application-group-name;
application-known;
application-unknown;
}
then {
dscp-code-point dscp-value ;
forwarding-class forwarding-class-name;
log;
loss-priority [ high | medium-high | medium-low | low ];
rate-limit {
loss-priority-high;
client-to-server rate-limiter-name;
server-to-client rate-limiter-name;
}
}
}
}
}
Description Defines AppQoS rule sets and the rules that establish priorities based on quality-of-service
requirements for the associated applications. AppQoS rules can be included in policy
statements to implement application-aware quality of service control.
• rule rule-name—Name applied to the match criteria and resulting actions that control
the quality-of-service provided to any matching applications.
• application-any —Any application encountering this rule. Note that when you use this
specification, all application matching ends. Any application rule following this one
will never be encountered.
• loss-priority—Loss priority with which matching applications will be marked. This value
is used to determine the likelihood that a packet would be dropped when encountering
congestion. A high loss priority means that there is an 80% chance of packet loss in
congestion. Possible values are high, medium-high, medium-low and low.
Release Information Statement introduced in Junos OS Release 11.1. Statement updated in Junos OS Release
12.1X44-D10 to include the ssl-encryption and reject options. The block-message options
added in Junos OS Release 12.1X45-D10.
The application firewall is defined by a collection of rule sets. These rule sets can be
defined independently and shared across network security policies. A rule set defines
the rules that specify match criteria, including dynamic applications, and the action to
be taken for matching traffic.
• Create rules for each rule set that permit, reject, or deny traffic based on the application
ID.
• Configure a security policy to invoke the application firewall service and specify the
rule set to be applied to permitted traffic.
The application firewall support in the policies provides additional security control for
dynamic applications.
security-zone
Release Information Statement introduced in Junos OS Release 8.5. Support for wildcard addresses added
in Junos OS Release 11.1. The description option added in Junos OS Release 12.1.
Description Define a security zone, which allows you to divide the network into different segments
and apply different security options to each segment.
When you configure the ICAP redirect service on SRX Series devices, you must configure
the ICAP server details. ICAP server configuration allows you to define the settings required
to process request messages, response messages, authorization, and so on. You can
also specify an SSL profile in the ICAP server configuration that enables you to secure
the connection to the ICAP server.
port—ICAP server listening port, default port is reached according to the protocol defined.
Default: 1344
Range: 1025 through 65535
server-certificate (Services)
Release Information Statement introduced in Junos OS Release 12.1X44-D10. This statement is supported on
the SRX1500, SRX5400, SRX5600, and SRX5800 devices and vSRX.
session-update-interval
Description Configure the interval between session update messages for long-lived sessions being
monitored by AppTrack. Byte count, packet count, and start and end times are updated
and logged when the amount of time between session start or the previous update and
the current time exceeds the interval.
signature
Description Application signature for pattern matching. A unique application signature identifier.
Must be a unique name with a maximum length of 63 characters.
You need to define an application signature to match the pattern by defining a unique
application signature identifier, application signature member identifier, connection
direction of the packets, and set the context to be matched. You also need to specify
port range for TCP or UDP.
Options member—Member name for a custom application signature. Custom signatures can
contain multiple members that define attributes for an application. (The supported
member name range is m01 through m15.)
size (Services)
Description Specify the maximum trace file size. This statement is supported on the SRX1500,
SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and vSRX.
ssl (Services)
Syntax ssl {
initiation {
profile profile-name {
actions {
ignore-server-auth-failure;
}
client-certificate;
custom-ciphers [cipher];
enable-flow-tracing;
enable-session-cache;
preferred-ciphers (custom | medium | strong | weak);
protocol-version (all | tls1 | tls11 | tls12);
trusted-ca (all | [ca-profile] );
}
}
proxy {
global-config {
session-cache-timeout seconds;
}
profile profile-name {
actions {
crl {
disable;
if-not-present (allow | drop);
ignore-hold-instruction-code;
}
disable-session-resumption;
ignore-server-auth-failure;
log {
all;
errors;
info;
sessions-allowed;
sessions-dropped;
sessions-ignored;
sessions-whitelisted;
warning;
}
renegotiation {
(allow | allow-secure | drop);
}
}
custom-ciphers [cipher];
enable-flow-tracing;
preferred-ciphers (custom | medium | strong | weak);
root-ca root-certificate;
trusted-ca (all | [ca-profile] );
whitelist [global-address-book-addresses];
}
}
termination {
profile profile-name {
custom-ciphers [cipher];
enable-flow-tracing;
enable-session-cache;
preferred-ciphers (custom | medium | strong | weak);
protocol-version (all | tls1 | tls11 | tls12);
server-certificate certificate-identifier;
}
}
traceoptions {
file {
filename;
files number;
match regular-expression;
(no-world-readable | world-readable);
size maximum-file-size;
}
flag flag;
level [brief | detail | extensive | verbose];
no-remote-trace;
}
}
Release Information Statement introduced in Junos OS Release 12.1X44-D10. The crl statement is supported
from 15.1X49-D30. The protocol-version statement is updated to include tls11 and tls12
from Junos OS Release 15.1X49-D30.
Description Specify the configuration for Secure Socket Layer (SSL) support service. This statement
is supported on the SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800
devices and vSRX.
Options The remaining statements are explained separately. See CLI Explorer.
ssl-encryption
Hierarchy Level [edit security application-firewall rule-sets rule-set-name rule rule-name match]
Description Distinguishes between encrypted and unencrypted SSL traffic as match criteria for the
rule. In application firewall usage, this option lets you specify different actions for
encrypted and unencrypted SSL traffic.
Syntax ssl-proxy {
profile-name profile-name
}
Hierarchy Level [edit security policies from-zone zone-name to-zone zone-name policy policy-name then
permit application-services]
Description Enable SSL proxy and identify the name of the SSL proxy profile to be used. This option
is supported on SRX340, SRX345, SRX550M, SRX1500, SRX4100, SRX4200, SRX5400,
SRX5600, and SRX5800 devices.
statistics (Services)
Syntax statistics {
interval interval-number;
}
NOTE: For SRX Series devices, the maximum number of interval periods for
which statistics are stored is 8.
sla-options
Syntax sla-options {
local-route-switch {
[enabled | disabled];
}
logging {
syslog:
}
}
Description Enable or disable switching of the application traffic to another route (local to the device)
during an SLA violation.
When local route switching is enabled, switching of the application traffic to an alternate
route is enabled and also SLA monitoring and reporting functionality is available.
When local route switching is disabled, only SLA monitoring and reporting functionality
is available and switching of the application traffic to the different route because of an
SLA violation is tuned off.
sla-rule
An SLA rule includes all information required to measure the SLA and to identify whether
any SLA violation has occurred or not. It contains the complete probe profiles, time interval
which the profiles need to be sent, preferred SLA configuration, and so on.
When you configure an APBR rule, you must associate the corresponding SLA rule for
the application.
The presence of SLA rule in the APBR configuration triggers the AppQoE functionality; If
there are no SLA profiles available, APBR operates without AppQoE.
metrics-profile profile-name—Metric profile name. The SLA rule contains metric profiles
that provides the acceptable threshold. If the violation goes beyond, the threshold,
an alternate path is identified and then traffic is re-routed.
switch-idle-time period—Path switch idle time in seconds. This is the period during which
no subsequent switching of application traffic path occurs till the expiry of switch
idle time. This idle time starts when application traffic switches the path.
Range: 5-300 seconds
Default: 15 seconds
termination (Services)
Syntax termination {
profile profile-name {
custom-ciphers [cipher];
enable-flow-tracing;
enable-session-cache;
preferred-ciphers (custom | medium | strong | weak);
protocol-version (all | tls1 | tls11 | tls12);
server-certificate certificate-identifier;
}
}
Release Information Statement introduced in Junos OS Release 12.1X44-D10. The protocol-version statement
is updated to include tls11 and tls12 from Junos OS Release 15.1X49-D30.
Description Specify the configuration for Secure Socket Layer (SSL) termination support service.
Following types of SSL profiles are supported on SRX Series to secure connections based
on the role of the SRX Series device:
• SSL initiation: The SRX Series device, acting as an SSL proxy client, initiates and
maintains SSL sessions between itself and an SSL server. SRX device receives
unencrypted data from an HTTP client, and encrypts and transmits the data as
ciphertext to the SSL server.
• SSL termination: The SRX Series device, actings as an SSL proxy server, terminates
the SSL session from the client and then establishing a new SSL connection to the
server. The SRX Series device decrypts the data and then sends the data as
un-encrypted request to the other servers (HTTP server).
The SSL proxy profile will be applied to the security policy as application services.
Options The remaining statements are explained separately. See CLI Explorer.
Syntax then {
(deny [block-message] | permit | reject [block-message]);
}
Release Information Statement introduced in Junos OS Release 11.1. Statement updated in Junos OS Release
12.1X44-D10 with the reject option. The block-message option added in Junos OS Release
12.1X45-D10.
Description Specify the action to be performed when traffic matches the associated match criteria.
Note that an application firewall is applied after a session has already been created by
the security firewall. When traffic is rejected or denied by an application firewall, therefore,
logs contain a session open message, a session reject or deny message, and a session
close message.
Options • deny—Block the traffic at the firewall. The device drops the packet. By default, no
message is returned to the sender.
• reject—Block the traffic at the firewall. For TCP traffic, by default the device drops the
packet and returns a TCP reset (RST) message to the source host. For UDP and other
protocol traffic, by default the device drops the packet and returns an ICMP “destination
unreachable, port unreachable” message to both the client and the server.
Syntax traceoptions {
file {
filename;
files number;
match regular-expression;
size maximum-file-size;
(world-readable | no-world-readable);
}
flag flag;
no-remote-trace;
}
• filename—Name of the file to receive the output of the tracing operation. Enclose
the name within quotation marks. All files are placed in the directory /var/log. By
default, the name of the file is the name of the process being traced.
• files number—Maximum number of trace files. When a trace file named trace-file
reaches its maximum size, it is renamed to trace-file.0, then trace-file.1, and so on,
until the maximum number of trace files is reached. The oldest archived file is
overwritten.
If you specify a maximum number of files, you also must specify a maximum file size
with the size option and a filename.
Default: 10 files
• match regular-expression—Refine the output to include lines that contain the regular
expression.
If you specify a maximum file size, you also must specify a maximum number of trace
files with the files option and a filename.
Range: 10 KB through 1 GB
Default: 128 KB
• flag—Trace operation to perform. To specify more than one trace operation, include
multiple flag statements.
Syntax traceoptions {
file {
filename;
files number;
match regular-expression;
size maximum-file-size;
(world-readable | no-world-readable);
}
flag flag;
no-remote-trace;
}
• filename—Name of the file to receive the output of the tracing operation. Enclose
the name within quotation marks. All files are placed in the directory /var/log. By
default, the name of the file is the name of the process being traced.
• files number—Maximum number of trace files. When a trace file named trace-file
reaches its maximum size, it is renamed to trace-file.0, then trace-file.1, and so on,
until the maximum number of trace files is reached. The oldest archived file is
overwritten.
If you specify a maximum number of files, you also must specify a maximum file size
with the size option and a filename.
Default: 10 files
• match regular-expression—Refine the output to include lines that contain the regular
expression.
continues until the maximum number of trace files is reached. Then the oldest trace
file is overwritten.
If you specify a maximum file size, you also must specify a maximum number of trace
files with the files option and a filename.
Range: 10 KB through 1 GB
Default: 128 KB
• flag—Trace operation to perform. To specify more than one trace operation, include
multiple flag statements.
Syntax traceoptions {
file {
filename ;
files number;
match regular-expression;
size maximum-file-size;
(world-readable | no-world-readable);
}
flag all;
level (all | error | info | notice | verbose | warning)
no-remote-trace;
}
• filename—Name of the file to receive the output of the tracing operation. Enclose
the name within quotation marks. All files are placed in the directory /var/log. By
default, the name of the file is the name of the process being traced.
• files number—Maximum number of trace files. When a trace file named trace-file
reaches its maximum size, it is renamed to trace-file.0, then trace-file.1, and so on,
until the maximum number of trace files is reached. The oldest archived file is
overwritten.
If you specify a maximum number of files, you also must specify a maximum file size
with the size option and a filename.
Default: 10 files
• match regular-expression—Refine the output to include lines that contain the regular
expression.
If you specify a maximum file size, you also must specify a maximum number of trace
files with the files option and a filename.
Range: 10 KB through 1 GB
Default: 128 KB
• flag—Trace operation to perform. To specify more than one trace operation, include
multiple flag statements.
trusted-ca (Services)
Description Specify the list of trusted certificate authority profiles. This statement is supported on
the SRX1500, SRX5400, SRX5600, and SRX5800 devices, and vSRX.
Syntax traceoptions {
file {
filename;
files number;
match regular-expression;
size maximum-file-size;
(world-readable | no-world-readable);
}
flag flag;
level [brief | detail | extensive | verbose];
no-remote-trace;
}
Release Information Statement introduced in Junos OS Release 12.1X44-D10. This statement is supported on
the SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and
vSRX.
Debug tracing on both Routing Engine and the Packet Forwarding Engine can be enabled
for SSL proxy by using [edit services ssl traceoptions] command.
• no-world-readable size—Do not allow any user to read the log file.
• flag—Trace operation to perform. To specify more than one trace operation, include
multiple flag statements.
tunables
Syntax tunables {
drop-on-zone-mismatch;
enable-logging;
max-route-change value;
}
Description Configure the advanced policy-based (APBR) routing options to streamline the traffic
handling.
You can streamline the traffic handling with APBR such as limiting the number of times
a route can change for a session, terminating the session if there is a mismatch between
zones when APBR is being applied in the middle of the session, and enabling logging to
record events that occur on the device.
Fine-tuning the APBR configuration is required to avoid the possible issues such as
excessive transitions due to route changes.
whitelist (Services)
Description Specify the addresses exempted from the SSL proxy. This statement is supported on
the SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and
vSRX.
You can selectively bypass SSL proxy processing for some sessions by configuring a
whitelist. Typically, you might configure the whitelist to include trusted servers or domains
with which you are very familiar. Whitelists include addresses that you want to exempt
from undergoing SSL proxy processing.
To configure the whiltelist, you need to specify the domain that you want to exempt in
an address book and then configure the address in the SSL proxy profile.
whitelist-url-categories
Whitelist URL categories include URL categories supported by UTM in the whitelist
configuration of SSL forward proxy.
The predefined URL categories depends on UTM. To enable the URL-based whitelisting
in SSL proxy, the following basic configurations are required:
[edit]
user@host# set security utm feature-profile web-filtering type juniper-enhanced
user@host# set security utm utm-policy policy-name web-filtering http-profile
junos-wf-enhanced-default
Options url-category-list— List of custom URLs along with URL categories defined by enhanced
Web filtering that need to be whitelisted.
zones
Syntax zones {
functional-zone {
management {
description text;
host-inbound-traffic {
protocols protocol-name {
except;
}
system-services service-name {
except;
}
}
interfaces interface-name {
host-inbound-traffic {
protocols protocol-name {
except;
}
system-services service-name {
except;
}
}
}
screen screen-name;
}
}
security-zone zone-name {
address-book {
address address-name {
ip-prefix {
description text;
}
description text;
dns-name domain-name {
ipv4-only;
ipv6-only;
}
range-address lower-limit to upper-limit;
wildcard-address ipv4-address/wildcard-mask;
}
address-set address-set-name {
address address-name;
address-set address-set-name;
description text;
}
}
advance-policy-based-routing;
application-tracking;
description text;
host-inbound-traffic {
protocols protocol-name {
except;
}
system-services service-name {
except;
}
}
interfaces interface-name {
host-inbound-traffic {
protocols protocol-name {
except;
}
system-services service-name {
except;
}
}
}
screen screen-name;
tcp-rst;
}
}
Release Information Statement introduced in Junos OS Release 8.5. Support for wildcard addresses added
in Junos OS Release 11.1. The description option added in Junos OS Release 12.1.
Description A zone is a collection of interfaces for security purposes. All interfaces in a zone are
equivalent from a security point of view. Configure the following zones:
• Security zone—Most common type of zone that is used as a building block in policies.
Options The remaining statements are explained separately. See CLI Explorer.
Operational Commands
Sample Output
Description Clear all the security application firewall rule set statistics information.
Syntax The master, or root, administrator can issue the following statements:
The user logical system administrator can issue the following statement:
NOTE: User logical system administrators can clear statistics only for the
logical systems they can access. For information about master and user
administrator roles in logical systems, see Understanding the Master Logical
System and the Master Administrator Role.
all—(default) Clear all rule set statistics for a specific logical system or all logical systems.
root-logical-system—Clear application firewall rule set statistics on the root logical system
(master administrator only).
Description Clears all Junos OS application statistics such as cumulative, interval, applications, and
application groups.
Release Information Command introduced in Junos OS Release 10.2. Command syntax updated in Junos OS
Release 12.1.
• all—All nodes
• local—Local node
• primary—Primary node
Release Information Command introduced in Junos OS Release 10.2. Command updated in Junos OS Release
12.1-X47-D15.
Output Fields When you enter this command, you are provided feedback on the status of your request.
Sample Output
Release Information Command introduced in Junos OS Release 12.1; default option added in Junos OS Release
12.1X47-D10.
Description For SSL forward proxy, you need to load trusted CA certificates on your system. By default,
Junos OS provides a list of trusted CA certificates that include default certificates used
by common browsers. Alternatively, you can define your own list of trusted CA certificates
and import them on to your system.
Use this command to load the default certificates or to specify a path and filename of
trusted CA certificates that you define.
List of Sample Output request security pki ca-certificate ca-profile-group load (default) on page 392
request security pki ca-certificate ca-profile-group load (path/filename) on page 393
Output Fields When you enter this command, you are provided feedback on the status of your request.
Sample Output
Sample Output
...
ca-manual_195_sysgen: Loading done.
ca-manual_196_sysgen: Loading done.
ca-profile-group 'ca-manual’ successfully loaded. Success[193] Skipped[3]
List of Sample Output request security pki local-certificate export on page 394
Output Fields When you enter this command, you are provided feedback on the status of your request.
Sample Output
Description Manually generate a self-signed certificate for the given distinguished name.
• CN—Common name
• O—Organization name
• ST—State
• C—Country
Output Fields When you enter this command, you are provided feedback on the status of your request.
Sample Output
Syntax request security pki local-certificate load certificate-id certificate-id-name filename path
List of Sample Output request security pki local-certificate load on page 396
Output Fields When you enter this command, you are provided feedback on the status of your request.
Sample Output
• If you disable an application signature, for example, junos:HTTP, that has nested
applications, the nested applications are not recognized.
Output Fields When you enter this command, the system provides feedback on the status of your
request.
Sample Output
Description Manually download the application package for Junos OS application identification. The
application package is extracted from the IDP signature database and contains signature
definitions for known applications, such as: DNS, Facebook, FTP, Skype, and SNMP.
Options version—(Optional) Download a specific version of the application package from the
Juniper Networks security website. If you do not enter a version, the most recent version
is downloaded.
Output Fields When you enter this command, you are provided feedback on the status of your request.
Sample Output
Description Check the download status of the application signature package. The downloaded
application package is saved under /var/db/appid/sec-download/.
List of Sample Output request services application-identification download status on page 399
Output Fields When you enter this command, the system provides feedback on the status of your
request.
Sample Output
Options copy—(Optional) Copy a predefined application signature group from the database to
the configuration and change the name (for example, my:FTP). The ID and order are
generated automatically. Do not name your custom application signature group with
the junos prefix; this prefix is reserved for predefined application signature groups.
You can copy the same predefined application signature group only once; duplicate
custom signature groups are not allowed.
Output Fields When you enter this command, the system provides feedback on the status of your
request.
Sample Output
Output Fields When you enter this command, the system provides feedback on the status of your
request.
Sample Output
Output Fields When you enter this command, the system provides feedback on the status of your
request.
Sample Output
Description Display the status of the install operation of the protocol bundle.
Output Fields When you enter this command, the system provides feedback on the status of your
request.
Sample Output
Release Information Statement introduced in Junos OS Release 10.2. Statement modified in Junos OS Release
10.4. Statement modified in Junos OS Release 11.4.
The uninstall operation will fail if any active security policies reference predefined
application signatures or predefined application signature groups in the Junos OS
configuration.
Output Fields When you enter this command, the system provides feedback on the status of your
request.
Sample Output
Output Fields When you enter this command, the system provides feedback on the status of your
request.
Sample Output
Description Display AppQoS DSCP marking and honoring statistics based on Layer 7 application
classifiers.
Output Fields Table 30 on page 407 lists the output fields for the show class-of-service
application-traffic-control counter command. Output fields are listed in the approximate
order in which they appear.
NOTE: The PIC number is always displayed as 0 for SRX300, SRX320, SRX340, SRX345,
SRX550M, and SRX1500 devices.
Sessions processed The number of sessions where the class of service was checked.
Sessions marked The number of sessions marked based on application-aware DSCP marking.
Sessions honored The number of sessions honored based on application-aware traffic honoring.
Sessions rate limited The number of sessions that have been rate limited.
Client-to-server flows rate limited The number of client-to-server flows that have been rate limited.
Server-to-client flows rate limited The number of server-to-client flows that have been rate limited.
Sample Output
pic: 2/1
Counter type Value
Sessions processed 300
Sessions marked 200
Sessions honored 0
Sessions rate limited 100
Client-to-server flows rate limited 100
Server-to-client flows rate limited 70
pic: 2/0
Counter type Value
Sessions processed 400
Sessions marked 300
Sessions honored 0
Sessions rate limited 200
Client-to-server flows rate limited 200
Server-to-client flows rate limited 100
Description Display AppQoS real-time run information about application rate limiting of current or
recent sessions.
List of Sample Output show class-of-service application-traffic-control statistics rate-limiter on page 409
Output Fields Table 31 on page 409 lists the output fields for the show class-of-service
application-traffic-control statistics rate-limiter command. Output fields are listed in the
approximate order in which they appear.
NOTE: The PIC number is always displayed as 0 for SRX300, SRX320, SRX340, SRX345,
and SRX550M devices.
Sample Output
Rate(kbps)
my-ruleset-1 HTTP my-http-c2s-rl 10000000 my-http-s2c-rl
20000000
my-ruleset-2 HTTP my-http-c2s-rl-2 20000000 my-http-s2c-rl-2
30000000
my-ruleset-2 FTP my-ftp-c2s-rl 50000 my-ftp-s2c-rl
50000
...
pic: 2/0
Ruleset Application Client-to-server Rate(kbps) Server-to-client
Rate(kbps)
my-ruleset-1 HTTP my-http-c2s-rl 10000000 my-http-s2c-rl
20000000
my-ruleset-2 HTTP my-http-c2s-rl-2 20000000 my-http-s2c-rl-2
30000000
my-ruleset-2 FTP my-ftp-c2s-rl 50000 my-ftp-s2c-rl
50000
List of Sample Output show class-of-service application-traffic-control statistics rule on page 411
Output Fields Table 32 on page 411 lists the output fields for the show class-of-service
application-traffic-control statistics rule command. Output fields are listed in the
approximate order in which they appear.
NOTE: The PIC number is always displayed as 0 for for SRX300, SRX320, SRX340,
SRX345, and SRX550M devices.
Hits The number of times a match for the rule was encountered.
Sample Output
pic: 2/1
Ruleset Rule Hits
my-ruleset-1 ftp-rule 200
You can use this command to understand the details of an APBR policy such as:
• The number of times the traffic matches the APBR policy and APBR profile applied
for the session.
detail—Display a detailed view of all of the APBR policies configured on the device.
Output Fields Table 33 on page 413 lists the output fields for the show security
advanced-policy-based-routing policy-name command. Output fields are listed in the
approximate order in which they appear.
State Status of the policy. The policy is in one of the following state:
• enabled: The policy can be used in the policy lookup process, which determines access
rights for a packet and the action taken in regard to it.
• disabled: The policy cannot be used in the policy lookup process, and therefore it is
not available for access control.
Sequence Number Number of the policy within a given context. For example, three policies that are applicable
in a from-zone A-to-zone B context might be ordered with sequence numbers 1, 2, 3.
Also, in a from-zone C-to-zone D context, four policies might have sequence numbers 1,
2, 3, 4.
Source addresses The names of the source addresses for a policy. Address sets are resolved to their
individual names.
Destination addresses Name of the destination address (or address set) as it was entered in the destination
zone’s address book
Applications Name of a preconfigured or custom application whose type the packet matches, as
specified at configuration time.
Table 34 on page 414 lists the output fields for the show security
advanced-policy-based-routing detail command. Output fields are listed in the
approximate order in which they appear.
State Status of the policy. The policy is in one of the following state:
• enabled: The policy can be used in the policy lookup process, which determines access
rights for a packet and the action taken in regard to it.
• disabled: The policy cannot be used in the policy lookup process, and therefore it is
not available for access control.
Sequence Number Number of the policy within a given context. For example, three policies that are applicable
in a from-zone A-to-zone B context might be ordered with sequence numbers 1, 2, 3.
Also, in a from-zone C-to-zone D context, four policies might have sequence numbers 1,
2, 3, 4.
Source addresses The names and corresponding IP addresses of the source addresses for a policy. Address
sets are resolved to their individual address name-IP address pairs.
Destination addresses Name of the destination address (or address set) as it was entered in the destination
zone’s address book. A packet’s destination address must match this value for the policy
to apply to it.
Applications Name of a preconfigured or custom application whose type the packet matches, as
specified at configuration time.
• IP protocol: The Internet protocol used by the application—for example, TCP, UDP,
ICMP.
• ALG: If an ALG is explicitly associated with the policy, the name of the ALG is displayed.
If application-protocol ignore is configured, ignore is displayed. Otherwise, 0 is
displayed. However, even if this command shows ALG: 0, ALGs might be triggered for
packets destined to well-known ports on which ALGs are listening, unless ALGs are
explicitly disabled or when application-protocol ignore is not configured for custom
applications.
• Inactivity timeout: Elapsed time without activity after which the application is
terminated.
• Source port range: The low-high source port range for the session application.
• Destination port range: The low-high destination port range for the session application.
Table 35 on page 415 lists the output fields for the show security
advanced-policy-based-routing from-zone command. Output fields are listed in the
approximate order in which they appear.
Table 36 on page 415 lists the output fields for the show security
advanced-policy-based-routing hit-count command. Output fields are listed in the
approximate order in which they appear.
Number of policy Number of security policies for which hit counts are displayed.
Sample Output
Number of policy: 1
Output Fields Table 37 on page 418 lists the output fields for the show security
advance-policy-based-routing profile command. Output fields are listed in the approximate
order in which they appear.
NOTE: The PIC number is always displayed as 0 for SRX300, SRX320, SRX340, SRX345,
SRX550M, and SRX1500 devices.
Sample Output
pic: 0/0
Profile Zone
Profile1 trust
Release Information Command introduced in Junos OS Release 15.1X49-D60. Support for Advanced
Policy-Based Routing Midstream is introduced in Junos OS Release 15.1X49-D110.
You can use this command to understand the details on traffic handling with APBR such
as:
• The number of times the application traffic matches the APBR profile and APBR is
applied for the session.
Output Fields Table 33 on page 413 lists the output fields for the show security
advance-policy-based-routing statistics command. Output fields are listed in the
approximate order in which they appear.
Session Processed The number of sessions processed for the application-based routing.
ASC Success The number of times the presence of an entry in the application system cache (ASC) is
found.
Rule match success The number of times the application traffic matches the APBR profile.
Route modified The number of times the APBR is applied for the session.
AppID Requested The number of times AppID was consulted to identify application traffic.
Table 39 on page 420 lists the output fields for the show security
advance-policy-based-routing statistics command for midstream support. Output fields
are listed in the approximate order in which they appear.
Table 39: show security advance-policy-based-routing statistics (Advanced Policy-Based Routing Midstream
Support)
Session Processed The number of sessions processed for the application-based routing.
AppID cache hits The number of times the presence of an entry in the application system cache (ASC) is
found.
AppID Requested The number of times AppID was consulted to identify application traffic.
Rule matches The number of times the application traffic matches the APBR profile.
Route changed on cache hits The number of times the APBR is applied for the session.
Zone mismatch No of times a zone for an interface is changed in the middle of a session.
Drop on zone mismatch Number of times a session is terminated because of change of zone in the middle of the
session.
Sample Output
You can create an advanced policy-based routing (APBR) profile (application profile)
to match applications and application groups and redirect those matching traffic to the
specified routing instance for the route lookup. The application profile is attached to a
security zone or it can be attached to a specific logical or physical interface associated
with the security zone.
Sample Output
Description Displays the details of active probe parameters. Active probe parameters are used by
AppQoE to evaluate the SLA of the link. In active probing, custom packets are sent
between a spoke device and a hub device on multiple routes to measure RTT, jitter, and
packet loss between two SRX Series devices.
Output Fields Table 40 on page 422 lists the output fields for the show command. Output fields are
listed in the approximate order in which they appear.
Sample Output
Description Displays the number of times SLA violations occurred, application traffic switched route
path, and monitored sessions.
Output Fields Table 33 on page 413 lists the output fields for the show command. Output fields are
listed in the approximate order in which they appear.
APBR Profile Name Name of the advanced policy-based (APBR) routing profile.
Path Switch Idle State Path switch idle state where no subsequent switching of application traffic path occurred.
Selected Tunnel Destination Selected tunnel destination where active probes are sent.
SLA Metrics SLA metrics parameters, that are used by AppQoE to evaluate the SLA of the link. The
SLA metric includes following parameters such as packet loss, RTT, jitter, and jitter type.
Sample Output
Output Fields Table 42 on page 426 lists the output fields for the show security
advance-policy-based-routing sla statistics command. Output fields are listed in the
approximate order in which they appear.
Passive Probe Session Number of sessions on which passive probes are sent.
Processed
Passive Probe Sessions Number of sessions, from which, data is subjected to sampling.
Sampled
Passive Probe Ongoing Number of sessions on which passive probes are active.
Sessions
Active Probe Session Number of sessions on which active probes are sent.
Active Probe Paths down Number of links on which active probes are sent, are not active.
Sample Output
Description Display the status of enabling switching of application path to an alternate route.
When local route switching is enabled, switching of application traffic to other route is
enabled and also SLA monitoring and reporting functionality is available. By enabling
local switch routing, the best possible link is selected for the application traffic to meet
performance requirements as specified in SLA (service-level agreement).
Sample Output
Description Displays AppQoE version details. This information helps verify that the SLA version on
both hub device and spoke device is same.
Release Information Command introduced in Junos OS Release 11.1. Updated in Junos OS Release 12.1X44-D10
with output format changes. Updated in Junos OS Release 12.1X45-D10 with redirection
counters.
Description Display information about the specified rule set defined in the application firewall.
The application firewall is defined by a collection of rule sets. A rule set defines the rules
that specify match criteria, including dynamic applications, and the action to be taken
for matching traffic.
List of Sample Output show security application-firewall rule-set my_ruleset1 on page 431
show security application-firewall rule-set all on page 431
Output Fields Table 43 on page 430 lists the output fields for the show security application-firewall
rule-set command. Output fields are listed in the approximate order in which they appear.
Profile The redirect profile to be used for rules requiring redirection for reject or deny actions.
Default rule The default rule applied when the identified application is not specified in any rules of
the rule set.
Number of sessions with appid Number of sessions that are pending application identification processing
pending
Sample Output
Sample Output
Rule-set: appfw
Logical system: root-logical-system
Profile: lsy2_pf555
Rule: 2
Dynamic Applications: junos:HTTP
SSL-Encryption: any
Action:deny or redirect
Number of sessions matched: 2
Number of sessions redirected: 2
Rule: 1
Dynamic Applications: junos:FTP
SSL-Encryption: any
Action:permit
Number of sessions matched: 0
Number of sessions redirected: 0
Default rule:permit
Number of sessions matched: 0
Number of sessions redirected: 0
Number of sessions with appid pending: 0
Syntax The master, or root, administrator can issue the following statements:
The user logical system administrator can issue the following statement:
Description Display information about application firewall rule set(s) associated with a specific
logical system, all logical systems, or the root logical system configured on a device.
NOTE: The master administrator can configure and view application firewall
rule sets for the root logical system and all user logical systems configured
on the device. User logical system administrators can configure and view
application firewall rule set information only for the user logical systems for
which they have access. For information about master and user administrator
roles in logical systems, see Understanding Logical Systems for SRX Series
Services Gateways.
all—(default) Display all rule sets for all logical systems. The user logical system
administrator can display all rule sets only for the logical system they can access.
root-logical-system—Display application firewall rule set information for the root logical
system (master administrator only).
List of Sample Output show security application-firewall rule-set logical-system all on page 434
show security application-firewall rule-set all on page 435
Output Fields Table 44 on page 434 lists the output fields for the show security application-firewall
rule-set logical-system command. Output fields are listed in the approximate order in
which they appear.
Default rule The default rule applied when the identified application is not specified in any rules of
the rule set.
Number of sessions with appid Number of sessions that are pending with the application ID processing.
pending
Sample Output
Rule-set: root_rs1
Logical system: root-logical-system
Rule: r1
Dynamic Applications: junos:FTP
Action:permit
Number of sessions matched: 10
Default rule:deny
Number of sessions matched: 100
Number of sessions with appid pending: 4
Rule-set: root-rs2
Logical system: root-logical-system
Rule: r1
Dynamic Application Groups: junos:web
Action:permit
Number of sessions matched: 20
Default rule:deny
Number of sessions matched: 100
Number of sessions with appid pending: 10
Rule-set: ls-product-design-rs1
Logical system: ls-product-design
Rule: r1
Dynamic Applications: junos:TELNET
Action:permit
Number of sessions matched: 10
Default rule:deny
Number of sessions matched: 100
Number of sessions with appid pending: 2
Rule-set: ls-product-design-rs1
Logical system: ls-product-design
Rule: r2
Dynamic Application Groups: junos:web
Action:permit
Number of sessions matched: 20
Default rule:deny
Number of sessions matched: 200
Number of sessions with appid pending: 4
Rule-set: ls-product-design-rs2
Logical system: ls-product-design
Rule: r1
Dynamic Applications: junos:FACEBOOK-ACCESS
Action:deny
Number of sessions matched: 40
Default rule:permit
Number of sessions matched: 400
Number of sessions with appid pending: 10
Output Fields Table 45 on page 436 lists the output fields for the show security application-tracking
counters command. Output fields are listed in the approximate order in which they appear.
Session create messages The number of log messages generated when a session was created.
Session close messages The number of log messages generated when a session was closed.
Session volume updates The number of log messages generated when an update interval was exceeded.
Session route updates The number of log messages generated when an egress interface was selected based
on application carried in the session by APBR.
Failed messages The number of messages that were not generated due to memory or session constraints.
Sample Output
Release Information Command introduced in Junos OS Release 8.5. Support for filter and view options added
in Junos OS Release 10.2.
Application firewall, dynamic application, and logical system filters added in Junos OS
Release 11.2.
Policy ID filter added in Junos OS Release 12.3X48-D10.
Support for connection tag added in Junos OS Release 15.1X49-D40.
Description Display information about all currently active security sessions on the device.
NOTE: For the normal flow sessions, the show security flow session command
displays byte counters based on IP header length. However, for sessions in
Express Path mode, the statistics are collected from the IOC2 and IOC3 ASIC
hardware engines and include full packet length with L2 headers. Because
of this, the output displays slightly larger byte counters for sessions in Express
Path mode than for the normal flow session.
The following filters reduce the display to those sessions that match the criteria
specified by the filter. Refer to the specific show command for examples of the filtered
output.
destination-port—Destination port.
dynamic-application—Dynamic application.
dynamic-application-group—Dynamic application.
encrypted—Encrypted traffic.
idp—IDP-enabled sessions.
resource-manager—Resource manager.
source-port—Source port.
source-prefix—Source IP prefix.
tunnel—Tunnel sessions.
Output Fields Table 46 on page 439 lists the output fields for the show security flow session command.
Output fields are listed in the approximate order in which they appear.
Session ID Number that identifies the session. Use this ID to get more brief
information about the session.
extensive
none
none
extensive
none
Conn Tag A 32-bit connection tag that uniquely identifies the GPRS brief
tunneling protocol, user plane (GTP-U) and the Stream Control
Transmission Protocol (STCP) sessions. The connection tag extensive
for GTP-U is the tunnel endpoint identifier (TEID) and for SCTP
is the vTag. The connection ID remains 0 if the connection tag none
is not used by the sessions.
CP Session ID Number that identifies the central point session. Use this ID to brief
get more information about the central point session.
extensive
none
Policy name Name and ID of the policy that the first packet of the session brief
matched.
extensive
none
extensive
none
none
extensive
none
extensive
none
extensive
none
none
Flag Internal flag depicting the state of the session, used for extensive
debugging purposes.
Source NAT pool The name of the source pool where NAT is used. extensive
Application traffic control AppQoS rule set for this session. extensive
rule-set
Current timeout Remaining time for the session unless traffic exists in the session. extensive
Start time Time when the session was created, offset from the system extensive
start time.
• Valid sessions
• Pending sessions
• Invalidated sessions
• Sessions in other states
Sample Output
Session ID: 10115977, Policy name: SG/4, State: Active, Timeout: 56, Valid
In: 203.0.113.1/1000 --> 203.0.113.11/2000;udp, Conn Tag: 0x0, If: reth1.0,
Pkts: 1, Bytes: 86, CP Session ID: 10320276
Out: 203.0.113.11/2000 --> 203.0.113.1/1000;udp, Conn Tag: 0x0, If: reth0.0,
Pkts: 0, Bytes: 0, CP Session ID: 10320276
Total sessions: 1
Session ID: 10115977, Policy name: SG/4, State: Active, Timeout: 62, Valid
In: 203.0.113.11/1000 --> 203.0.113.1/2000;udp, Conn Tag: 0x0, If: reth1.0,
Pkts: 1, Bytes: 86, CP Session ID: 10320276
Out: 203.0.113.1/2000 --> 203.0.113.11/1000;udp, Conn Tag: 0x0, If: reth0.0,
Pkts: 0, Bytes: 0, CP Session ID: 10320276
Total sessions: 1
Include options to filter the output and display only those enabled sessions with the
specified features.
• rule rule-name–Display only those enabled sessions that match the specified rule.
The output fields for the brief and summary options are the same as those of the show
security flow session command. Only the extensive display is different and is shown in
the following output table and examples.
List of Sample Output show security flow session application-firewall extensive on page 446
show security flow session application-firewall dynamic-application junos:FTP
extensive on page 446
show security flow session application-firewall dynamic-application junos:UNKNOWN
extensive on page 447
show security flow session application-firewall dynamic-application-group junos:WEB
extensive on page 448
Output Fields Table 47 on page 445 lists the output fields for the show security flow session
application-firewall extensive command. Output fields are listed in the approximate order
in which they appear in the extensive display.
Table 47: show security flow session application-firewall extensive Output Fields
Session ID Number that identifies the session. Use this ID to display more information about a
session.
Flag Internal flag depicting the state of the session. It is used for debugging purposes.
Policy name The name of the policy that permitted the traffic.
Source NAT pool The name of the source pool where NAT is used.
Dynamic application Name of the dynamic application of the session. If the dynamic application has yet to
be determined, the output indicates Pending. If the dynamic application cannot be
determined, the output indicates junos:UNKNOWN.
Dynamic application group Name of the dynamic application group of the session. If the dynamic application cannot
be determined, the output indicates junos:UNASSIGNED.
Dynamic nested application Name of the dynamic nested application of the session if one exists. If the dynamic
nested application is yet to be determined, the output indicates Pending. If the dynamic
nested application cannot be determined, the output indicates junos:UNKNOWN.
Application firewall rule-set Name of the rule set that the session matched.
Rule Name of the rule that the session matched. If the match has not yet been made, the
output indicates Pending. If the rule has been deleted since the match was made, the
output indicates the rule is invalid.
Maximum timeout Maximum amount of idle time allowed for the session.
Current timeout Number of seconds that the current session has been idle.
Start time Time when the session was created. Start time is indicated as an offset from the system
start time.
Table 47: show security flow session application-firewall extensive Output Fields (continued)
Out Reverse flow (source and destination IP addresses, application protocol, interface,
session token, route, gateway, tunnel, port sequence, FIN sequence, FIN state, packets
and bytes).
Total sessions Total number of sessions per PIC that fit the display criteria.
Sample Output
The displayed information is similar to the show security flow session output but includes
dynamic application and application firewall details for the session.
Total sessions: 1
Entering a specific dynamic application in the command line filters the output and displays
only those sessions with the specified application.
Total sessions: 1
Using the keyword junos:UNKNOWN displays those enabled sessions where the dynamic
application cannot be determined.
Total sessions: 2
Entering a specific dynamic application group in the command line filters the output and
displays only those sessions with the specified application group.
Total sessions: 1
Specifying a rule set name reduces the display to only those sessions matching the
specified rule set.
Total sessions: 2
Description Display information about certificate authority (CA) digital certificates installed in the
router.
Output Fields Table 48 on page 450 lists the output fields for the show security pki ca-certificate
command. Output fields are listed in the approximate order in which they appear.
Issued to Device that was issued the digital certificate. none brief
Issuer Authority that issued the digital certificate, including details of the authority detail
organized using the distinguished name format. Possible subfields are:
Subject Details of the digital certificate holder organized using the distinguished name detail
format. Possible subfields are:
Validity Time period when the digital certificate is valid. Values are: All levels
Public key Encryption algorithm used with the private key, such as rsaEncryption(1024 bits). All levels
algorithm
Signature algorithm Encryption algorithm that the CA used to sign the digital certificate, such as detail
sha1WithRSAEncryption.
Fingerprint Secure Hash Algorithm (SHA1) and Message Digest 5 (MD5) hashes used to detail
identify the digital certificate.
Distribution CRL Distinguished name information and the URL for the certificate revocation list detail
(CRL) server.
Use for key Use of the public key, such as Certificate signing, CRL signing, Digital signature, detail
or Key encipherment.
Sample Output
Certificate identifier:abe
Issued to: First Officer, Issued by: example
Validity:
Release Information Command modified in Junos OS Release 9.1. Subject string output field added in Junos
OS Release 12.1X44-D10.
Description Display information about the local digital certificates, corresponding public keys, and
the automatically generated self-signed certificate configured on the device.
Options • none—Display basic information about all configured local digital certificates,
corresponding public keys, and the automatically generated self-signed certificate.
List of Sample Output show security pki local-certificate certificate-id hello on page 456
show security pki local-certificate certificate-id hello detail on page 456
show security pki local-certificate system-generated on page 457
show security pki local-certificate system-generated detail on page 457
show security pki local-certificate certificate-id mycert - (local certificate enrolled
online using SCEP) on page 458
show security pki local-certificate certificate-id mycert detail - (local certificate enrolled
online using SCEP) on page 458
Output Fields Table 49 on page 454 lists the output fields for the show security pki local-certificate
command. Output fields are listed in the approximate order in which they appear.
Issuer Authority that issued the digital certificate, including details of the authority organized
using the distinguished name format. Possible subfields are:
• Organization—Organization of origin.
• Organizational unit—Department within an organization.
• Country—Country of origin.
• Locality—Locality of origin.
• Common name—Name of the authority.
Subject Details of the digital certificate holder organized using the distinguished name format.
Possible subfields are:
• Organization—Organization of origin.
• Organizational unit—Department within an organization.
• Country—Country of origin.
• Locality—Locality of origin.
• Common name—Name of the authority.
• Serial number—Serial number of the device.
If the certificate contains multiple subfield entries, all entries are displayed.
Alternate subject Domain name or IP address of the device related to the digital certificate.
Validity Time period when the digital certificate is valid. Values are:
Public key algorithm Encryption algorithm used with the private key, such as rsaEncryption(1024 bits).
Public key verification status Public key verification status: Failed or Passed. The detail output also provides the
verification hash.
Signature algorithm Encryption algorithm that the CA used to sign the digital certificate, such as
sha1WithRSAEncryption.
Fingerprint Secure Hash Algorithm (SHA1) and Message Digest 5 (MD5) hashes used to identify the
digital certificate.
Distribution CRL Distinguished name information and URL for the certificate revocation list (CRL) server.
Use for key Use of the public key, such as Certificate signing, CRL signing, Digital signature, or Data
encipherment.
Sample Output
Sample Output
Sample Output
Sample Output
Sample Output
show security pki local-certificate certificate-id mycert - (local certificate enrolled online using SCEP)
user@host> show security pki local-certificate certificate-id mycert
Certificate identifier: mycert
Issued to: bubba, Issued by: DC = local, DC = demo, CN = domain-example-WIN-CA
Validity:
Not before: 11-15-2012 18:58
Not after: 11-15-2014 18:58
Public key algorithm: rsaEncryption(1024 bits)
Sample Output
show security pki local-certificate certificate-id mycert detail - (local certificate enrolled online using SCEP)
user@host> show security pki local-certificate certificate-id mycert detail
Certificate identifier: mycert
Certificate version: 3
Serial number: 1f00b50a000000013ad2
Issuer:
Common name: Example-CA,
Domain component: local, Domain component: demo
Subject:
Organization: example, Organizational unit: SSD, Country: US,
Common name: host1, Serial number: SRX240-11152012
Subject string:
serialNumber=SRX240-11152012, C=US, O=example, OU=SSD, CN=host1
Alternate subject: "[email protected]", user.example.net, 192.0.2.1
Validity:
Not before: 11-15-2012 18:58
Not after: 11-15-2014 18:58
Public key algorithm: rsaEncryption(1024 bits)
30:81:89:02:81:81:00:e3:e5:ae:c0:82:af:db:94:01:2f:56:46:50
7d:3d:0b:0c:f0:1f:1d:7d:c3:aa:d4:4c:a0:cd:23:8b:3f:47:05:ee
7b:65:42:a0:dc:c4:ac:a7:b6:a6:9f:5c:ea:d8:22:b0:bf:03:75:09
be:fa:77:cb:d6:67:19:e6:80:fa:a5:7c:93:af:96:66:9f:cc:45:d5
eb:ab:c1:f0:32:a6:d9:27:1b:80:bb:57:ec:31:a2:e0:2b:e1:42:c0
92:8a:9b:ed:a6:d2:ec:7c:84:5a:8a:d9:96:a7:7e:40:c3:80:0e:f4
d6:a2:5d:78:93:3b:7d:d5:8a:f5:de:fb:bc:0d:6d:02:03:01:00:01
Signature algorithm: sha1WithRSAEncryption
Distribution CRL:
ldap:///Example-CA,CN=cn-win,CN=CDP,CN=Public%20Key%20Services,
CN=Services,CN=Configuration,DC=demo,DC=local?certificateRevocationList?
base?objectClass=cRLDistributionPoint
http://example.example.net/CertEnroll/Example-CA.crl
Use for key: Key encipherment, Digital signature, 1.3.6.1.5.5.8.2.2,
1.3.6.1.5.5.8.2.2
Fingerprint:
1f:2f:a9:22:a8:d5:a9:36:cc:c4:bd:81:59:9d:9c:58:bb:40:15:72 (sha1)
51:27:e4:d5:29:90:f7:85:9e:67:84:a1:75:d1:5b:16 (md5)
Auto-re-enrollment:
Status: Disabled
Next trigger time: Timer not started
Release Information Command modified in Junos OS Release 9.2. Support for IPv6 addresses added in Junos
OS Release 10.2. Support for wildcard addresses added in Junos OS Release 11.1. Support
for global policy added in Junos OS Release 11.4. Support for services offloading added
in Junos OS Release 11.4. Support for source-identities added in Junos OS Release 12.1.
The Description output field added in Junos OS Release 12.1. Support for negated address
added in Junos OS Release 12.1X45-D10. The output fields for Policy Statistics expanded,
and the output fields for the global and policy-name options expanded to include
from-zone and to-zone global match criteria in Junos OS Release 12.1X47-D10. Support
for the initial-tcp-mss and reverse-tcp-mss options added in Junos OS Release
12.3X48-D20. Output field and description for source-end-user-profile option added in
Junos OS Release 15.1x49-D70. Output field and description for dynamic-applications
option added in Junos OS Release 15.1x49-D100. Output field and description for
dynapp-redir-profile option added in Junos OS Release 18.2R1.
Description Display a summary of all security policies configured on the device. If a particular policy
is specified, display information specific to that policy.
• detail—(Optional) Display a detailed view of all of the policies configured on the device.
Output Fields Table 50 on page 460 lists the output fields for the show security policies command. Output
fields are listed in the approximate order in which they appear.
• enabled: The policy can be used in the policy lookup process, which determines access
rights for a packet and the action taken in regard to it.
• disabled: The policy cannot be used in the policy lookup process, and therefore it is
not available for access control.
Sequence number Number of the policy within a given context. For example, three policies that are applicable
in a from-zoneA-to-zoneB context might be ordered with sequence numbers 1, 2, 3. Also,
in a from-zoneC-to-zoneD context, four policies might have sequence numbers 1, 2, 3,
4.
Source addresses For standard display mode, the names of the source addresses for a policy. Address sets
are resolved to their individual names.
For detail display mode, the names and corresponding IP addresses of the source
addresses for a policy. Address sets are resolved to their individual address name-IP
address pairs.
Destination addresses Name of the destination address (or address set) as it was entered in the destination
zone’s address book. A packet’s destination address must match this value for the policy
to apply to it.
source-end-user-profile Name of the device identity profile (referred to as end-user-profile in the CLI) that contains
attributes, or characteristics of a device. Specification of the device identity profile in the
source-end-user-profile field is part of the device identity feature. If a device matches the
attributes specified in the profile and other security policy parameters, then the security
policy’s action is applied to traffic issuing from the device.
Source addresses (excluded) Name of the source address excluded from the policy.
Destination addresses (excluded) Name of the destination address excluded from the policy.
Applications Name of a preconfigured or custom application whose type the packet matches, as
specified at configuration time.
• IP protocol: The Internet protocol used by the application—for example, TCP, UDP,
ICMP.
• ALG: If an ALG is explicitly associated with the policy, the name of the ALG is displayed.
If application-protocol ignore is configured, ignore is displayed. Otherwise, 0 is displayed.
However, even if this command shows ALG: 0, ALGs might be triggered for packets
destined to well-known ports on which ALGs are listening, unless ALGs are explicitly
disabled or when application-protocol ignore is not configured for custom applications.
• Inactivity timeout: Elapsed time without activity after which the application is
terminated.
• Source port range: The low-high source port range for the session application.
• Default rule—The default rule applied when the identified application is not specified
in any rules of the rule set.
Action or Action-type • The action taken for a packet that matches the policy’s tuples. Actions include the
following:
• permit
• firewall-authentication
• tunnel ipsec-vpn vpn-name
• pair-policy pair-policy-name
• source-nat pool pool-name
• pool-set pool-set-name
• interface
• destination-nat name
• deny
• reject
• services-offload
Session log Session log entry that indicates whether the at-create and at-close flags were set at
configuration time to log session information.
Scheduler name Name of a preconfigured scheduler whose schedule determines when the policy is active
and can be used as a possible match for traffic.
Policy statistics • Input bytes—The total number of bytes presented for processing by the device.
• Initial direction—The number of bytes presented for processing by the device from
the initial direction.
• Reply direction—The number of bytes presented for processing by the device from
the reply direction.
• Input packets—The total number of packets presented for processing by the device.
• Initial direction—The number of packets presented for processing by the device from
the initial direction.
• Reply direction—The number of packets presented for processing by the device from
the reply direction.
Per policy TCP Options Configured syn and sequence checks, and the configured TCP MSS value for the initial
direction, the reverse direction or, both.
Sample Output
The following example displays the output with unified policies configured.
Policy statistics:
Input bytes : 18144 545 bps
Initial direction: 9072 272 bps
Reply direction : 9072 272 bps
Output bytes : 18144 545 bps
Initial direction: 9072 272 bps
Reply direction : 9072 272 bps
Input packets : 216 6 pps
Initial direction: 108 3 bps
Reply direction : 108 3 bps
Output packets : 216 6 pps
Initial direction: 108 3 bps
Reply direction : 108 3 bps
Session rate : 108 3 sps
Active sessions : 93
Session deletions : 15
Policy lookups : 108
The following example displays the output with unified policies configured.
source-end-user-profile: marketing-profile
Applications: any
Action: permit
role2
role4
Application: any
IP protocol: 0, ALG: 0, Inactivity timeout: 0
Source port range: [0-0]
Destination port range: [0-0]
Per policy TCP Options: SYN check: No, SEQ check: No
The following example displays the output with unified policies configured.
Release Information Command introduced in Junos OS Release 11.4. Starting in Junos OS Release 15.1X49-D100,
the options Cacheable, Activation Date, and Last modified are introduced for show services
application-identification application detail command. The Underlying consolidated
Protocols/ports application is dependent on and Layer-7 Immediate Protocol(s) options
are introduced in Junos OS Release 18.2R1.
Description Display detailed information about a specified application signature, detailed information
about all application signatures, or a summary of the existing application signatures.
List of Sample Output show services application-identification application summary on page 472
show services application-identification application detail on page 473
show services application-identification application detail (Custom
Applications) on page 473
show services application-identification application detail (Unified Policies) on page 474
Output Fields Table 51 on page 470 lists shows the output details for the show services
application-identification application detail command.
Disabled The status of the application and whether the mapping method is currently used to
identify this application.
Order Number used to specify priority when multiple applications match the traffic. The lowest
order number takes the highest priority.
Table 52 on page 471 lists the output fields for the show services application-identification
application command. Output fields are listed in the approximate order in which they
appear.
Application ID The unique ID number of an application signature. ID numbers 1 through 32,767 are
automatically generated for application; these IDs do not change.
Disabled The status of the application and whether the mapping method is currently used to
identify this application.
Cacheable The status whether the application identification results caching is enabled or not for
the application.
When this option is enabled, you can cache the application detection result in an ASC
table.
Activation Date Date when the application was activated for the first time.
Number of Parent Group(s) Total number of parent groups in this application signature group or cluster.
Application Group Name of the application signature group associated with this application signature. Must
be a unique name with a maximum length of 32 characters.
Application Tags General information about this application type, for example, associated risk factors,
technology, type of traffic, and so on.
Support of application signature tags is dependent on the version of the loaded signature
database (Juniper Networks security website).
Underlying consolidated List of default protocols and ports for dependent applications of the specified application.
Protocols/ports application is
dependent on
Layer-7 Immediate Protocol(s) List of applications over which that dynamic application can be identified.
Application Specific Ports: The default port for this application type.
Signature: Signature mapping criteria for application identification: Port range, Client-to-server,
and Order.
Sample Output
junos:GOOGLE-TRUSTED-STORE No 2819 5
junos:AMJILT No 2272 4
junos:DSI No 2644 3
junos:HLN No 2096 2
junos:ETSI-LI No 537 1
junos:CRAZYSALOON No 1720 5
junos:EKSISOZLUK No 2436 4
junos:SABAH No 2574 3
junos:AFREECA No 2373 2
junos:SENEWEB No 2068 1
junos:DIINO No 776 5
junos:CARE2 No 376 4
junos:MOBAGE No 1456 3
junos:CARTOONNETWORK No 982 2
junos:AVATARS-UNITED No 363 1
junos:CONVIVA No 2015 5
junos:DREAMORA No 1725 4
junos:ELWATANNEWS No 2381 3
junos:REUTERS No 1044 2
junos:BABYCENTER No 364 1
junos:SOUTHWEST No 289 5
junos:ONEDIO No 2517 4
........
........
Sample Output
TCP Ports:
Port: 443
Port: 554
Port: 80
UDP Ports:
Port: 554
Layer-7 Immediate Protocol(s):
Protocol: GOOGLE-GEN / 943
Alias List:
junos:GOOGLE-SSL
Application Specific Ports:
Default ports: N/A
Signature:
Port range: N/A
Client-to-server
Order: 1
Release Information Command introduced in Junos OS Release 10.2. Command updated in Junos OS Release
12.1X47-D10. Output updated in Junos OS Release 12.1X47-D15. The Cache lookup for
security-services and the Cache lookup for miscellaneous-services are introduced in Junos
OS Release 18.2R1.
Description Display application ID from default port/protocol binding or from the application system
cache.
Output Fields Table 53 on page 476 and Table 54 on page 477 list the output fields for the show services
application-identification application-system-cache command. Output fields are listed
in the approximate order in which they appear.
IP address IP address.
Table 54: show services application-identification application-system-cache Output Fields (For Unified Policies)
Cache lookup for security-services On or Off status of the application cache for security services such as security policies,
application firewall (AppFW), Juniper Sky ATP, IDP, and UTM. By default, the ASC is
disabled for the security services.
Cache lookup for On or Off status of the application cache for miscellaneous services such as APBR and
miscellaneous-services AppTrack. By default, the ASC is enabled for the miscellaneous services.
Sample Output
pic: 1/1
Logical system name: root-logical-system
IP address: 192.0.2.2 Port: 80 Protocol:
TCP
Application: HTTP Encrypted: No
Sample Output
Description Display information about the commit status. Because the custom signatures commit
is performed asynchronously, the command output shows the current status of your
configuration commit.
Sample Output
Release Information Command introduced in Junos OS Release 10.2. Output updated in Junos OS Release
12.1X47-D10. Command and output updated in Junos OS Release 12.1X47-D15.
Description Display the status of all Junos OS application identification counter values per SPU.
Output Fields Table 55 on page 480 lists the output fields for the show services application-identification
counter command. Output fields are listed in an approximate order in which they appear.
NOTE: The PIC number is always displayed as 0 for SRX300, SRX320, SRX340, and
SRX345 devices.
Cache hits Number of sessions that matched the application in the AI cache.
Cache misses Number of sessions that did not find the application in the AI cache.
Server-to-client layer encrypted bytes Number of server-to-client encrypted payload bytes processed.
processed
Sessions bypassed due to resource Number of sessions bypassed due to resource allocation failure.
allocation failure
Segment case 1 - New segment to left TCP segments contained before the previous segment.
Segment case 2 - New segment TCP segments that start before the previous segment and are contained in it.
overlap right
Segment case 3 - Old segment TCP segments that start before the previous segment and extend beyond it.
overlapped
Segment case 4 - New segment TCP segments that start and end within the previous segment.
overlapped
Segment case 5 - New segment TCP segments that start within the previous segments and extend beyond it.
overlap left
Segment case 6 - New segment TCP segments that start after the previous segment. This is the normal case.
overlap left
Sample Output
pic: 6/0
Counter type Value
Unknown applications 5
Encrpted unknown applications 0
Cache hits 0
Cache misses 8
Client-to-server packets processed 678
Server-to-client packets processed 0
Client-to-server bytes processed 83577
Server-to-client bytes processed 0
Client-to-server encrypted packets processed 0
Server-to-client encrypted packets processed 0
Client-to-server encrypted bytes processed 0
Server-to-client encrypted bytes processed 0
Sessions bypassed due to resource allocation failure 0
Segment case 1 - New segment to left 0
Segment case 2 - New segment overlap right 0
Segment case 3 - Old segment overlapped 0
Segment case 4 - New segment overlapped 0
Segment case 5 - New segment overlap left 0
Segment case 6 - New segment to right 0
Sample Output
pic: 1/0
Counter type Value
AI cache hits 0
AI cache hits by nested application 0
AI cache misses 0
AI matches 0
AI uni-matches 0
AI no-matches 0
AI partial matches 0
AI no-partial matches 0
Sessions that triggered Appid create session API 0
Sessions that do not incur signature match or decoding 0
Sessions that incur signature match or decoding 0
Client-to-server packets processed 0
Server-to-client packets processed 0
Client-to-server layer-7 bytes processed 0
Server-to-client layer-7 bytes processed 0
Terminal first data packets on both direction 0
pic: 1/1
Counter type Value
AI cache hits 0
AI cache hits by nested application 0
AI cache misses 0
AI matches 0
AI uni-matches 0
AI no-matches 0
AI partial matches 0
AI no-partial matches 0
Sessions that triggered Appid create session API 0
Sessions that do not incur signature match or decoding 0
Sessions that incur signature match or decoding 0
Client-to-server packets processed 0
Server-to-client packets processed 0
Client-to-server layer-7 bytes processed 0
Description Display detailed or summary information about a specified application signature group
or all application signature groups. Both custom and predefined application signature
groups can be displayed.
Options detail application-group name—(Optional) Display detailed information for the specified
application signature group.
List of Sample Output show services application-identification group summary on page 485
show services application-identification group detail on page 485
Output Fields Table 56 on page 484 lists the output fields for the show services application-identification
group command. Output fields are listed in the approximate order in which they appear.
Disabled The status of the application signature group and whether the signature method is
currently used to identify this application. The default is No.
Applications The application signatures associated with this application signature group.
Sample Output
Release Information Command introduced in Junos OS Release 11.4. Command updated in Junos OS Release
12.1.
Options • none—Display cumulative session and byte statistics per application. Statistics are
displayed in alphabetical order.
List of Sample Output show services application-identification statistics applications on page 487
show services application-identification statistics applications interval 3 on page 487
Output Fields Table 57 on page 486 lists the output fields for the show services application-identification
statistics applications command. Output fields are listed in the approximate order in
which they appear.
NOTE: When an SRX Series device is operating in chassis cluster mode (Active/Active
mode - Z mode), the show services application-identification statistics applications
command output does not provide complete statistics for bytes count for the session
in application/application group statistics. This is because, ingress and egress traffic
byte counts are updated separately on the primary and secondary nodes in the chassis
cluster setup for a given application.
Sample Output
Options • none—Display cumulative session and byte statistics per application group. Statistics
are displayed in alphabetical order.
List of Sample Output show services application-identification statistics application-groups on page 489
show services application-identification statistics application-groups interval
8 on page 489
Output Fields Table 58 on page 488 lists the output fields for the show services application-identification
statistics application-groups command. Output fields are listed in the approximate order
in which they appear.
NOTE: When an SRX Series device is operating in Chassis Cluster mode (Active/Active
mode - Z mode), the show services application-identification statistics application-groups
command output does not provide complete statistics for bytes count for the session
in application/application group statistics. This is because, ingress and egress traffic
byte counts are updated separately on the primary and secondary nodes in the chassis
cluster setup for a given application.
Sample Output
Output Fields Table 59 on page 490 lists the output fields for the show services application-identification
status command. Output fields are listed in the approximate order in which they appear.
Max TCP session packet Maximum number of TCP sessions that application identification
memory maintains.
DPI Performance mode DPI performance mode status. This field is displayed only if the DPI
performance mode is enabled.
Negative cache status Status on the number of sessions that reach the Unknown cache
entry: Enabled or Disabled.
Cache timeout Idle timeout after which the cache entries expires.
Download Server CGI Name of the server from where protocol bundle was downloaded.
Auto Update Status of auto update to receive protocol bundle updates from the
server: Enabled or Disabled.
Starting from Junos OS Release 17.4R1, Juniper Networks Deep Packet Inspection-Decoder
(JDPI-Decoder) engine, is packaged along with the application signature package version
534 that includes protobundle version 1.270.0.48.005. When you upgrade to Junos OS
Release 17.4R1 or later from the earlier versions of Junos OS, the application identification
security package installed is of version 534.
However, if you require latest versions of the protocol bundle, you must download and
install the application signature package separately.
Sample Output
Application Identification
Status Enabled
Sessions under app detection 0
Engine Version 4.18.1-20 (build date Feb 15 2014)
Max TCP session packet memory 30000
Force packet plugin Disabled
Force stream plugin Disabled
Statistics collection interval 1 (in minutes)
Protocol Bundle
Download Server https://services.netscreen.com/cgi-bin/index.cgi
AutoUpdate Disabled
Slot 1:
Status Active
Version 1.30.4-22.005 (build date Jan 17 2014)
Sessions 0
Slot 2
Status Free
Sample Output
Application Identification
Status Enabled
Sessions under app detection 0
Engine Version 4.18.2-24.006 (build date Jul 30 2014)
Max TCP session packet memory 30000
Force packet plugin Disabled
Force stream plugin Disabled
DPI Performance mode: Enabled
Statistics collection interval 1 (in minutes)
Protocol Bundle
Download Server https://services.netscreen.com/cgi-bin/index.cgi
AutoUpdate Disabled
Slot 1:
Application package version 2399
Status Active
Version 1.40.0-26.006 (build date May 1 2014)
Sessions 0
Slot 2
Application package version 0
Status Free
Version
Sessions 0
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 1 (in minutes)
Protocol Bundle
Download Server
https://indiavm-sigdb2.englab.juniper.net/cgi-bin/index.cgi
AutoUpdate Disabled
Slot 1:
Application package version 534
Status Active
PB Version 1.270.0-48.005 (build date May 22 2017)
Engine version 4.20.0-49.005 (build date May 22 2017)
Sessions 0
Sample Output
The following output shows that the application package version is 1608.
Sample Output
Sample Output
NOTE: When devices are operating in chassis cluster mode, the SSL proxy
statistics increment only on the active node of the chassis cluster setup.
List of Sample Output show services ssl proxy statistics on page 498
Output Fields Table 60 on page 497 describes the output fields for the show services ssl proxy statistics
command. Output fields are listed in the approximate order in which they appear.
Sessions bypassed: non The number of proxy sessions that are bypassed because the non SSL sessions limit was exceeded
SSL
Sessions bypassed: The number of proxy sessions that are bypassed because the memory usage limit per session was
memory overflow reached.
sessions bypassed: low The number of proxy sessions that are bypassed because of low memory on Packet Forwarding
memory Engine.
Sessions created The number of proxy sessions that are newly created.
Table 60: show services ssl proxy statistics Output Fields (continued)
Sessions whitelisted The number of sessions that are whitelisted. Whitelists comprise addresses or domain names that
you want to exempt from the SSL proxy processing.
whitelisted url category Whitelists comprise url hostnames that you want to exempt from the SSL proxy processing.
match
Sample Output