Application Firewall
Application firewall (AppFW) provides policy-based enforcement and control on traffic based on application signatures. By using AppFW, you can block any application traffic not sanctioned by the enterprise. For more information, see the following topics:
Application Firewall Overview
This topic includes the following sections:
Limitations with Stateful Firewalls
Traditionally stateful firewalls used to control applications such as HTTP, SMTP, and DNS because these applications used well-known standards ports only. However, now it is possible to run these applications on any port as long as the client and server are using same protocol and same ports. Because of this standard stateful firewalls are not able to detect evasive applications. 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.
This limitation of stateful firewalls, in which firewalls inspect traffic based on Layer 3 and Layer 4, left open to allow application layer exploits.
Application Firewall
Juniper Networks’ application firewall (AppFW) leverages the results from the application identification to make an informed decision to permit, deny, reject, or redirect the traffic based on applications. AppFW enables you to enforce the policy control on Layer 7 traffic.
The AppFW allows you to block the applications based on their application signatures, while still allowing other HTTP traffic to pass through the firewall. For example, an application firewall rule could block HTTP traffic from Facebook but allow Web access to HTTP traffic from MS Outlook.
Benefit of Application Firewall
Provides granular security control to high-risk applications based on user-defined policies.
Adds flexibility by providing policy control over application access based on the requirements.
Application Firewall with Unified Policies
Starting in Junos OS release 18.2R1, you can use unified policies to avail the same functionality of an AppFW configuration. Unified policies leverage the application identity information from the application identification (AppID) service to permit, deny, reject, or redirect the traffic. A unified policy configuration handles all application firewall functionality and simplifies the task of configuring a firewall policy.
Read one of the following topic for configuring AppFW:
If you are using Junos OS version 18.2 and later releases, you must configure Unified policies to get same benefits as traditional AppFW. See Application Firewall Support with Unified Policies.
If you are using Junos OS version prior to Junos OS 18.2, you can configure traditional AppFW. See Traditional Application Firewall.
Application Firewall Support with Unified Policies
Starting in Junos OS Release 18.2R1, SRX Series devices and vSRX instances support unified policies, allowing granular control and enforcement of Layer 7 dynamic applications within the traditional security policy.
Unified policies are the security policies that enable you to use dynamic applications as match conditions as part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to detect application changes over time.
If you are planning to upgrade to Junos OS Release 18.2R1 and later releases, note the following points regarding using APPFW functionality:
All existing AppFW related CLI statements and commands are deprecated. That is—
Starting in Junos OS Release 18.2R1 Application Firewall (AppFW) functionality is deprecated— rather than immediately removed—to provide backward compatibility and an opportunity to bring your configuration into compliance with the new configuration. As a part of this change, the [edit security application-firewall] hierarchy and all the configuration options under this hierarchy are deprecated.
Configuring a traditional AppFW policy and a unified policy in the same security policy is not supported. The system displays the following error message if you attempt to do so:
Traditional AppFW and dynamic-application can't be applied to same policy
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.
For example on configuring a unified policies, see Configuring Unified Security Policies.
Example: Configure Application Firewall with Unified Policy
This example describes how to configure a unified policy to allow or block traffic based on the applications.
System Requirements
System Requirements
This example uses the following hardware and software components:
SRX Series device running Junos OS Release 18.2R1. This configuration example is tested with Junos OS release 19.1R1.
Before You Begin
Install a valid application identification feature license on your SRX Series device. See Managing Junos OS Licenses.
Download and install the Junos OS application signature package. Downloading and Installing the Junos OS Application Signature Package.
Overview
In this example, you create a very common scenario to block certain application and application group such as Yahoo-Mail and Facebook-Access.
Topology
This example uses the topology as shown in Figure 1.
This example uses following zones and interfaces configuration.
The client system is connected to the ge-0/0/0.0 interface with IP address 4.0.0.254/24. It is part of the trust zone.
The server system is connected to the ge-0/0/1.0 interface with IP address 5.0.0.254/24. It is part of the untrust zone.
Create a security policy configuration to block certain applications using the following steps:
Create a security policy for the traffic from zone trust to untrust to block the access to the Yahoo-Mail or Facebook-Access applications.
Create a redirect message for the denied or rejected traffic to inform the user about the status of their request.
Create a default policy to allow rest of the traffic.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
Step-by-Step Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.
To configure a unified policy using dynamic applications:
- Configure security zones and interfaces.[edit]user@host#set security zones security-zone trust host-inbound-traffic system-services alluser@host#set security zones security-zone trust interfaces ge-0/0/0.0user@host#set security zones security-zone untrust host-inbound-traffic system-services alluser@host#set security zones security-zone untrust interfaces ge-0/0/1.0user@host#set interfaces ge-0/0/0 unit 0 family inet address 4.0.0.254/24user@host#set interfaces ge-0/0/1 unit 0 family inet address 5.0.0.254/24
- Create redirect profile.[edit]user@host#set security dynamic-application profile profile1 redirect-message type custom-text content "THIS APPLICATION IS BLOCKED"
- Create a security policy with a dynamic application as
the match criteria.[edit]user@host#set security policies from-zone trust to-zone untrust policy policy-1 match source-address anyuser@host#set security policies from-zone trust to-zone untrust policy policy-1 match destination-address anyuser@host#set security policies from-zone trust to-zone untrust policy policy-1 match application anyuser@host#set security policies from-zone trust to-zone untrust policy policy-1 match dynamic-application junos:YAHOO-MAILuser@host#set security policies from-zone trust to-zone untrust policy policy-1 match dynamic-application junos:FACEBOOK-ACCESSuser@host#set security policies from-zone trust to-zone untrust policy policy-1 then reject profile profile1
- Create a default policy to permit the remaining traffic.[edit]user@host#set security policies default-policy permit-all
Results
From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
If you are done configuring the device, enter commit from configuration mode.
Verification
Use the following procedures to verify if the policy configuration.
Verifying Policy Action
Purpose
Verify that the unified policy has blocked that configured applications.
Action
From your Web browser, try to access the application. For example, Yahoo-Mail. The system displays the redirect message as shown in the following image.
Meaning
Whenever the security policy rejects traffic based on the dynamic application, the output displays the redirect message as configured by you in the dynamic application profile.
Verifying Unified Policy Configuration
Purpose
Verify that the unified policy configuration is correct.
Action
From operational mode, enter the show security policies detail command to display a detailed summary of all security policies on the device.
user@host> show security policies
detailDefault policy: permit-all Pre ID default policy: permit-all Policy: policy-1, action-type: reject, State: enabled, Index: 7, Scope Policy: 0 Policy Type: Configured Sequence number: 1 From zone: trust, To zone: untrust Source vrf group: any Destination vrf group: any Source addresses: any-ipv4(global): 0.0.0.0/0 any-ipv6(global): ::/0 Destination addresses: any-ipv4(global): 0.0.0.0/0 any-ipv6(global): ::/0 Application: any IP protocol: 0, ALG: 0, Inactivity timeout: 0 Source port range: [0-0] Destination ports: [0-0] Dynamic Application: junos:FACEBOOK-ACCESS: 244 junos:YAHOO-MAIL: 236 dynapp-redir-profile: profile1(1) Per policy TCP Options: SYN check: No, SEQ check: No, Window scale: No
Meaning
The output displays information about security policy. Verify the following information:
Configured policy name policy-1 and policy action reject.
Configured dynamic applications junos:FACEBOOK-ACCESS and junos:YAHOO-MAIL.
Redirect profile profile1.
Traditional Application Firewall
This topic includes the following sections:
Understanding How Application Firewall Works
As you can use existing security policy to enforce traditional firewall controls on the traffic, you can use AppFW module to block certain application traffic, based on their application signatures, while still allowing other HTTP traffic to pass through the firewall.
Security device processes traffic in the following sequence when you have configured a AppFW:
Security policy matches the zone pair specified in the policy.
Security policy matches the packets with matching conditions (source and destination IP addresses, source and destination ports, and application type)
Security policy applies one of the following actions to the matching traffic.
Reject—Notify the client, drop the traffic, and log the event.
Deny—Drop the traffic, and log the event.
Permit—Open a session, log the event, and apply services as specified.
Invoke application services to retrieve the application ID for the traffic.
Apply the specified application firewall rule set.
Note All IP fragmented packets received on the security device must be reassembled before forwarding.
Application Firewall Rule Sets and Rules
Consider following when configuring application firewall:
You can apply one AppFW rule set to multiple different security policies.
You can configure an AppFW inside a logical system.
You can configure multiple dynamic applications in a rule and multiple rules in a rule set. However, there is a limit to the overall number of rule sets and rules.
You can configure a dynamic application group as match criteria in a rule. An application group includes multiple related applications. For more information, see Predefined and Custom Application Groups for Application Identification.
The default rule defines the action required for any traffic that does not match any rule. So, a AppFW rule set must contain a default rule.
Application Firewall with ALG
On your security devices, when you enable ALG, application identification includes the ALG results to identify the applications in the control session. AppFW permits ALG data sessions whenever control sessions are permitted. If the control session is denied, there will be no data sessions. If you disable ALG, application identification relies on signatures to identify the application in the control and data sessions. If a signature match is not found, the application is considered unknown. AppFW handles the applications based on the application identification result.
Unknown Applications
Application identification classifies unknown dynamic applications with ID junos:UNKNOWN. AppID uses the reserved keyword junos:UNKNOWN in the following cases
The traffic does not match an application signature in the database.
The system encounters an error when identifying the application.
The session fails over to another device.
Traffic with an application ID of junos:UNKNOWN matches a rule with a dynamic application of junos:UNKNOWN. If there is no rule defined for junos:UNKNOWN, the default rule is applied.
Session Logging for Application Firewalls
You can log the traffic by enabling the log option under a security policy. Note the following while you inspect a log message when AppFW is configured as given in Table 1:
Table 1: Session Logging for Application Firewall Configuration
Security Policy Action | Log Creation | More Details |
|---|---|---|
Permit | Creates a session and logs a session create message | When security policy permit action creates a session even before the AppFW rules are applied, log message includes one of the following update:
|
Reject/Deny | Logs reject or deny message, but does not create a session. | When a AppFW rule denies or rejects traffic, the log message includes one of the following phrases in the reason field:
|
Application Firewall Support in Chassis Cluster
When your security device is in chassis cluster mode, the AppFW action before and after the failover depends on the application identification state, as shown in Table 2.
Table 2: Application Firewall Actions
Before Failover | After Failover | ||
|---|---|---|---|
| Application ID State | Application Firewall Action | Application ID State | Application Firewall Action |
Success | Deny | Success | Deny |
Success | Permit | Success | Permit |
Pending | — | UNKNOWN | Action based on the rule defined for unknown application If there is no rule defined for unknown, then the default rule is applied |
Note the following when you have your security device in chassis cluster mode:
When you enable application identification, the 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.
In-service software upgrade (unified ISSU) is not supported due to lack of chassis cluster infrastructure support. Thus, the failover event is controlled through the application firewall policy by allowing or denying the unknown dynamic applications.
See also
Creating Redirects in Application Firewall
When AppFW denies or rejects traffic, it does not notify clients that such action is taken. Clients being unaware that their request is rejected, might keep on trying to access the Web page. To alleviate this inconvenience, the Junos OS allows you to provide an explanation for the action or to redirect the client to an informative webpage. Following examples show you how to create a redirect message.
Redirect with Block Message
Use the block-message option with the reject or deny action in AppFW rule.
When AppFW rejects the traffic, a splash screen displays the following default message to the user:
Customize Redirect Message
You can customize the redirect action by including additional text on the splash screen or by specifying a URL to which you can redirect a user. To customize the block message, you must create a block message profile at [edit security application-firewall] hierarchy level and define the type and content as shown in the following sample.
Next, you refer the block message profile in the AppFW rule set, and apply it to one or more of the rules using the block-message option;
In this case, AppFW displays the configured block message whenever it rejects the traffic based on the configured rule.
Customize Redirect Message with URL
When AppFW rejects or redirects the traffic, you can redirect the client to the specified Web page for further action. The URL can be hosted on either the SRX Series device or an external server.
You can set the redirects to the other server by configuring block-message type as custom-redirect-url as shown in the sample below:
Next, you refer the block message profile in the AppFW rule set, and apply to one or more of the rules using the block-message option as shown in the following sample:
In this case, AppFW redirects the use to the URL http://abc.company.com/information whenever it rejects the traffic based on the configured rule.
Example: Configuring Application Firewall
This example shows how to configure application firewall rule sets within the security policy.
Before You Begin
Valid application identification feature license installed on an SRX Series device. See Managing Junos OS Licenses.
Download and install the Junos OS application signature package. Downloading and Installing the Junos OS Application Signature Package.
System 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 create application firewall for the following two common scenarios as described in Table 3.
Table 3: Configure Application Firewall to Permit or Deny Traffic
Objectives | Steps to Follows | Results |
|---|---|---|
Block a certain application and allow other applications | Configure a security policy to allow HTTP traffic. | Security policy permits or drops the traffic based on matching specified Layer 3 or Layer 4 criteria. |
Configure an AppFW rule set with following options:
| AppFW assess the permitted traffic at Layer 7 based on its application ID. | |
Refer the AppFW rule set in the security policy. |
| |
Allow a certain application and block other applications | Configure a security policy to allow HTTP traffic. | Security policy permits or drops the traffic based on matching specified Layer 3 or Layer 4 criteria. |
Configure an AppFW rule set with following options:
| AppFW assess the permitted traffic at Layer 7 based on its application ID. | |
Refer the AppFW rule set in the security policy. |
|
On all SRX Series devices, J-Web pages for AppSecure Services are preliminary. We recommend using CLI for configuration of AppSecure features.
Configuration
Application Firewall Rule to Explicitly Deny Certain Application and Permit All Else
In this example, you block dynamic-applications junos:FACEBOOK-CHAT junos:FACEBOOK-FARMVILLE and allow remaining traffic.
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see CLI User Guide.
To configure two security policies with application firewall rule sets that permit or deny traffic from different dynamic applications:
- Define the application firewall rule set to deny traffic
from selected dynamic applications.[edit security application-firewall rule-sets rs1]user@host# set rule r1 match dynamic-application [junos:FACEBOOK-CHAT,junos:FACEBOOK-FARMVILLE]user@host# set rule r1 then denyuser@host# set default-rule permit
- Configure the security policy to allow HTTP traffic and
invoke application firewall rule set rs1.[edit security policies from-zone untrust to-zone trust policy policy1]user@host# set match source-address anyuser@host# set match destination-address anyuser@host# set match application junos-httpuser@host# set then permit application-services application-firewall rule-set rs1
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.
Application Firewall Rule to Explicitly Permit Certain Application and Deny All Else
In this example, you permit dynamic-applications junos:FACEBOOK-ACCESS and block remaining traffic.
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see CLI User Guide.
To configure two security policies with application firewall rule sets that permit or deny traffic from different dynamic applications:
- Configure a security policy to process any traffic that
does not go to the HTTP static ports with the application firewall
rule set rs2.[edit security policies from-zone untrust to-zone trust policy policy2]user@host# set match source-address anyuser@host# set match destination-address anyuser@host# set match application junos:httpuser@host# set then permit application-services application-firewall rule-set rs2
- Define the application firewall rule set to permit traffic
from selected dynamic applications.[edit security application-firewall rule-sets rs2]user@host# set rule r1 match dynamic-application [junos:FACEBOOK-ACCESS, junos:UNKNOWN]user@host# set rule r1 then permituser@host# set default-rule deny
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.
Verification
To confirm that the configuration is working properly, perform these tasks:
Verifying Application Firewall Configuration
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
See also
Example: Configuring Application Firewall with Application Groups
The application identification (AppID) module manages predefined application groups. An application group includes related applications under a single name for simplified, consistent reuse when using in any application services. An application group can contain multiple applications and application groups simultaneously. It is possible to assign one application to multiple groups.
You can configure a AppFW rule to permit or to deny traffic by specifying a predefined application group along with applications as match criteria.
Advantage of using predefined application groups is - As the application signature database changes, the predefined application group is modified automatically to include new signatures. In this case, if you already have a AppFW rule with predefined application group, the inclusion of new signatures in the application group does not affect the existing AppFW rule.
This example shows how to configure application groups in a AppFW rule set.
Before You Begin
Install a valid application identification feature license on your SRX Series device. See Managing Junos OS Licenses.
Download and install the Junos OS application signature package. Downloading and Installing the Junos OS Application Signature Package.
System 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 configure a security policy to control outbound traffic from the trust zone to the untrust zone. Next you create a AppFW rule to allow specific application traffic (junos:GOOGLETALK), but deny all other known similar application traffic (social networking traffic) using application group.
It is very important to note the order of AppFW rules because, the predefined group junos:social-networking includes the junos:GOOGLETALK application. To allow junos:GOOGLETALK traffic and deny the rest of the group, you must place the rule permitting junos:GOOGLETALK traffic before the rule denying traffic from the rest of the applications in the group.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.
To configure application firewall rule-sets and security policies for outbound traffic:
- Create the rule-set social-network.[edit]user@host# set security application-firewall rule-sets social-network
- Define a rule to permit Google-Talk traffic.[edit security application-firewall rule-sets social-network]user@host# set rule google-rule match dynamic-application junos:GOOGLETALKuser@host# set rule google-rule then permit
- Define a second rule that denies all other social-networking
traffic and traffic from an unknown application.[edit security application-firewall rule-sets social-network]user@host# set rule denied-sites match dynamic-application-groups junos:social-networkinguser@host# set rule denied-sites match dynamic-application junos:UNKNOWNuser@host# set rule denied-sites then deny
Note that the rule sequence is very important. You must place the rule with junos:GOOGLETALK before the rule with junos:social-networking. Otherwise, AppFW rule denies even GOOGLETALK traffic along junos:social-networking.
- Define the default-rule that permits all other traffic.[edit security application-firewall rule-sets social-network]user@host# user@host# set default-rule permit
- Configure the outbound-traffic policy to apply the social-network
rule-set to all outbound traffic.[edit security policies from-zone trust to-zone untrust policy outbound-traffic]user@host# set match source-address anyuser@host# set match destination-address anyuser@host# set match application junos:HTTPuser@host# set then permit application-services application-firewall rule-set social-network
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.
If you are done configuring the device, enter commit from configuration mode.
Verification
Verifying Application Firewall Configuration
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.
See also
Example: Configuring Application Firewall When SSL Proxy Is Enabled
This example describes how to configure a AppFW when you have enabled the SSL proxy.
For application junos-https, SSL proxy detects an SSL session based on the dynamic application identified for that session. In case if any known Web servers are running nonstandard ports, you can use a custom Junos OS application to identify the application. However, if the Web servers are not known, for example on the Internet, you can 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.
The security device bypasses SSL proxy services if when SSL proxy profile is attached to the security rule, when none of the services (AppFW, IDP, or AppTrack) are configured
Requirements
Before you begin:
Install a valid application identification feature license on your SRX Series device. See Managing Junos OS Licenses.
Download and install the Junos OS application signature package. Downloading and Installing the Junos OS Application Signature Package.
Create an application (or application set) that indicates that the policy applies to traffic of that type. See Example: Configuring Security Policy Applications and Application Sets.
Create a SSL proxy profile that enables SSL proxy by means of a policy. See Configuring SSL Forward Proxy.
System 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 configure two security policies with AppFW rule sets to permit or deny traffic from plain text or encrypted traffic:
Allow the encrypted version of Oracle and deny any other encrypted traffic.
Allow all HTTP traffic, except Hulu.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see CLI User Guide.
- Configure a security policy to process the traffic with
AppFW rule set and SSL proxy profile.[edit security policies from-zone Z_1 to-zone Z_2 policy policy1user@host# set match source-address anyuser@host# set match destination-address anyuser@host# set match application junos-httpsuser@host# set then permit application-services application-firewall rule-set appfw-rs-1user@host# set then permit application-services ssl-proxy profile-name ssl-profile-1
- Configure another security policy with AppFW rule set.[edit security policies from-zone Z_1 to-zone Z_2 policy policy2user@host# set match source-address anyuser@host# set match destination-address anyuser@host# set match application junos-httpuser@host# set then permit application-services application-firewall rule-set appfw-rs-2
- Define the AppFW rule set to permit an encrypted version
of Oracle traffic and to deny any other encrypted traffic.[edit security application-firewall rule-sets appfw-rs1]user@host# set rule rule1 match dynamic-application [junos:ORACLE]user@host# set rule rule1 then permituser@host# set default-rule deny
- Define another AppFW rule set to allow all plain text
traffic except Hulu.[edit security application-firewall rule-sets appfw-rs2]user@host# set rule rule1 match dynamic-application [junos:HULU]user@host# set rule rule1 then denyuser@host# set default-rule permit
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.
Verifying Application Firewall In an SSL Proxy Enabled Policy
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.