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
- Application Firewall
- Benefit of Application Firewall
- Application Firewall with Unified Policies
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.
A predefined signature database is available on the Juniper Networks Security Engineering website. This database includes a library of application signatures. See Application Signatures for more details. These signature pages will give you visibility into the application category, group, risk-level, ports, and so on.
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 Application Firewall Overview.
Application Firewall Support with Unified Policies
Starting in Junos OS Release 18.2R1, SRX Series Firewalls and vSRX Virtual Firewall 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.AppFW functionality works if you continue to configure in the deprecated hierarchy. You can configure AppFW in the deprecated hierarchy in CLI by manual input only.
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.
See Also
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 Firewall 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 Firewall. 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.
set security dynamic-application profile profile1 redirect-message type custom-text content "THIS APPLICATION IS BLOCKED" set security policies from-zone trust to-zone untrust policy policy-1 match source-address any set security policies from-zone trust to-zone untrust policy policy-1 match destination-address any set security policies from-zone trust to-zone untrust policy policy-1 match application any set security policies from-zone trust to-zone untrust policy policy-1 match dynamic-application junos:YAHOO-MAIL set security policies from-zone trust to-zone untrust policy policy-1 match dynamic-application junos:FACEBOOK-ACCESS set security policies from-zone trust to-zone untrust policy policy-1 then reject profile profile1 set security policies default-policy permit-all set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone trust interfaces ge-0/0/0.0 set security zones security-zone untrust host-inbound-traffic system-services all set security zones security-zone untrust interfaces ge-0/0/1.0 set interfaces ge-0/0/0 unit 0 family inet address 4.0.0.254/24 set interfaces ge-0/0/1 unit 0 family inet address 5.0.0.254/24
Procedure
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/24Create 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 profile1Create 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.
[edit]
user@host#
show security dynamic-application { profile profile1 { redirect-message { type { custom-text { content "THIS APPLICATION IS BLOCKED"; } } } } } policies { from-zone trust to-zone untrust { policy policy-1 { match { source-address any; destination-address any; application any; dynamic-application [junos:YAHOO-MAIL junos:FACEBOOK-ACCESS ]; } then { reject { profile profile1; } } } } default-policy { permit-all; } } zones { security-zone trust { host-inbound-traffic { system-services { ping; } } interfaces { ge-0/0/0.0; } } security-zone untrust { host-inbound-traffic { system-services { ping; } } interfaces { ge-0/0/1.0; } } }
[edit]
user@host#
show interfaces ge-0/0/0 { unit 0 { family inet { address 4.0.0.254/24; } } } ge-0/0/1 { unit 0 { family inet { address 5.0.0.254/24; } } } fxp0 { unit 0 { family inet { address 10.102.70.185/24; } } }
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 detail Default policy: permit-all Pre ID default policy: permit-allPolicy: 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
- Application Firewall Rule Sets and Rules
- Application Firewall with ALG
- Unknown Applications
- Session Logging for Application Firewalls
- Application Firewall Support in Chassis Cluster
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:If you are using Junos OS Release 20.1 or later releases and have configured HTTP-based custom application signature, the legacy application firewall redirect action might not work for HTTPS traffic. Instead of redirecting the HTTPS traffic, the security device denies or rejects the traffic.
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:
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.
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.
..... rule 1 { match { dynamic-application junos:FACEBOOK-CHAT } then { reject { block-message; } } } .....
When AppFW rejects the traffic, a splash screen displays the following default message to the user:
user-name, Application Firewall has blocked your request to application FACEBOOK-CHAT at dst-ip:dst-port accessed from src-ip:src-port.
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.
... profile Redirect-Profile { block-message { type { custom-text { content "YOUR APPLICATION IS BLOCKED AS PER THE ORGANIZATION POLICY"; } } } } ...
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;
rule-sets Ruleset-1 { rule 1 { match { dynamic-application junos:FACEBOOK-CHAT; } then { reject { block-message; } } } profile Redirect-Profile; }
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 Firewall 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:
profile Redirect-Profile { block-message { type { custom-redirect-url { content http://abc.company.com/information; } } } }
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:
rule-sets Ruleset-1 { rule 1 { match { dynamic-application junos:FACEBOOK-CHAT; } then { reject { block-message; } } } profile Redirect-Profile; }
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 Firewall. 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 Firewall 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.
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 Firewalls, 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
- Application Firewall Rule to Explicitly Permit Certain Application and Deny All Else
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.
set security policies from-zone untrust to-zone trust policy policy1 match source-address any set security policies from-zone untrust to-zone trust policy policy1 match destination-address any 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 application-firewall rule-sets rs1 rule r1 match dynamic-application [junos:FACEBOOK-CHAT,junos:FACEBOOK-FARMVILLE ] set security application-firewall rule-sets rs1 rule r1 then deny set security application-firewall rule-sets rs1 default-rule permit
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 deny user@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 any user@host# set match destination-address any user@host# set match application junos-http user@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.
[edit] user@host# show security policies from-zone untrust to-zone trust { policy 1 { match { source-address any; destination-address any; application junos-http; } then { permit { application-services { application-firewall { rule-set rs1; } } } } } } user@host# show security application-firewall rule-sets rs1 { rule r1 { match { dynamic-application [junos:FACEBOOK-CHAT,junos:FACEBOOK-FARMVILLE]; } then { deny; } } default-rule { permit; } }
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.
set security policies from-zone untrust to-zone trust policy policy2 match source-address any set security policies from-zone untrust to-zone trust policy policy2 match destination-address any 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 rs2 rule r1 match dynamic-application [junos:FACEBOOK-ACCESS 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 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 any user@host# set match destination-address any user@host# set match application junos:http user@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 permit user@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.
[edit] user@host# show security policies from-zone untrust to-zone trust { policy 2 { match { source-address any; destination-address any; application junos:http; } then { permit { application-services { application-firewall { rule-set rs2; } } } } } } user@host# show security application-firewall rule-sets rs2 { rule r1 { match { dynamic-application [junos:FACEBOOK-ACCESS, junos:UNKNOWN]; } then { permit; } } default-rule { deny; } }
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
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 Firewall. 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 Firewall 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
Procedure
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.
set security application-firewall rule-sets social-network rule google-rule match dynamic-application junos:GOOGLETALK set security application-firewall rule-sets social-network rule google-rule then permit set security application-firewall rule-sets social-network rule denied-sites match dynamic-application-groups junos:social-networking set security application-firewall rule-sets social-network rule denied-sites match dynamic-application junos:UNKNOWN set security application-firewall rule-sets social-network rule denied-sites then deny set security application-firewall rule-sets social-network default-rule permit set security policies from-zone trust to-zone untrust policy outbound-traffic match source-address any set security policies from-zone trust to-zone untrust policy outbound-traffic match destination-address any set security policies from-zone trust to-zone untrust policy outbound-traffic match application junos:HTTP set security policies from-zone trust to-zone untrust policy outbound-traffic then permit application-services application-firewall rule-set social-network
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:GOOGLETALK user@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-networking user@host# set rule denied-sites match dynamic-application junos:UNKNOWN user@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 any user@host# set match destination-address any user@host# set match application junos:HTTP user@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.
[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
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
andshow 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.
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 Firewall. 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 Firewall 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.
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] set security application-firewall rule-sets appfw-rs-1 rule rule1 then permit set security application-firewall rule-sets appfw-rs-1 default-rule deny set security application-firewall rule-sets appfw-rs-2 rule rule1 match dynamic-application [junos:HULU] set security application-firewall rule-sets appfw-rs-2 rule rule1 then deny set security application-firewall rule-sets appfw-rs-2 default-rule permit
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 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 policy1 user@host# set match source-address any user@host# set match destination-address any user@host# set match application junos-https user@host# set then permit application-services application-firewall rule-set appfw-rs-1 user@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 policy2 user@host# set match source-address any user@host# set match destination-address any user@host# set match application junos-http user@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 permit user@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 deny user@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.
user@host> show security flow session ?
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.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
[edit security
application-firewall]
hierarchy and all the configuration options
under this hierarchy are deprecated.