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:
Application Firewall Overview
Traditionally, applications like HTTP, SMTP, and DNS use well-known standard ports and are easily controlled by a stateful firewall. However, it is possible to run these applications on any port as long as the client and server are using the same protocol as the well-known ports.
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.
A security administrator implements an application firewall by performing the following tasks:
Define one or more application firewall rule sets.
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.
This topic includes the following sections:
Benefit of Application Firewall
Controls access to high-risk applications based on user-defined policies.
Understanding Application Firewall Rule Sets
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.
An application firewall rule set consists of:
The name of the rule set
One or more rules
A single default rule
Each rule defines dynamic applications to permit, reject, or deny. Each rule consists of:
The name of the rule
A list of dynamic applications to be used as match criteria
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.
Permit—Permit the traffic.
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.
The junos:UNKNOWN keyword is reserved for unknown dynamic applications. In the following cases, the application ID is set to junos:UNKNOWN:
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.
Configuring an Application Firewall Within a Security Policy
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.
Traffic is processed in the following sequence:
Match the zone pair specified in the policy.
When specified, match the source and destination IP addresses, ports, and application type.
Apply the security policy action to 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.
All IP fragmented packets received on the SRX Series device must be reassembled before forwarding.
Application Group Support for Application Firewall
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.
An application group can contain applications and groups simultaneously. It is possible to assign one application to multiple groups. There is no limit to the number of dynamic application groups contained in one rule.
For information on creating or listing application groups, see Customizing Application Groups for Junos OS Application Identification.
On all SRX Series devices, when ALG is enabled, application identification includes the ALG result to identify the application of the control sessions. Application firewall permits ALG data sessions whenever control sessions are permitted. If the control session is denied, there will be no data sessions. When ALG is disabled, application identification relies on its signatures to identify the application of the control and data sessions. If a signature match is not found, the application is considered unknown. Application firewall handles applications based on the application identification result.
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.
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.
Session Logging for Application Firewalls
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:
appfw deny or appfw deny redirect
appfw reject or appfw reject redirect
policy deny
policy reject
Application Firewall Support in Chassis Cluster
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.
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 1.
Table 1: 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 |
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
Application Firewall Support with Unified Policies on SRX Series Devices
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 leverage the application identity information from the application identification (AppID) service to permit, deny, reject, or redirect the traffic.
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.
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.
Unified Policies with Traditional Application Firewall Configurations
When using AppFW after upgrading to the Junos OS Release 18.2R1 and later, note the following changes:
An existing traditional security policie is considered to be a unified policy with a dynamic application that is configured as none.
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:
Traditional AppFW and dynamic-application can't be applied to same policy
Example: Configuring Application Firewall Rule Sets Within a Security Policy
This example shows how to configure application firewall rule sets within the security policy.
Requirements
Create zones. See Example: Creating Security Zones.
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.
This configuration example shows how to:
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.
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 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 policy to process the traffic that goes to
the HTTP static ports with the application firewall rule set rs1.[edit security policies from-zone untrust to-zone trust policy policy1]user@host# set match source-address 198.51.100.1user@host# set match destination-address 192.0.2.1user@host# set match application junos-httpuser@host# set then permit application-services application-firewall rule-set rs1
- Configure another 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 198.51.100.1user@host# set match destination-address 192.0.2.1user@host# set match application anyuser@host# set then permit application-services application-firewall rule-set rs2
- Define the application firewall rule set rs1 to deny traffic
from selected dynamic applications.[edit security application-firewall rule-sets rs1]user@host# set rule r1 match dynamic-application [junos:KAZAA junos:EDONKEY junos:YMSG]user@host# set rule r1 then denyuser@host# set default-rule permit
- Define the application firewall rule set rs2 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:GOOGLETALK junos:MEEBOME 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 an Application Group for Application Firewall
With application identification, multiple applications can be configured in a dynamic application groups for consistent reuse. AppFW rules permit and deny traffic by specifying application names, dynamic application group names, or both. By using predefined application groups, AppFW rules require no updating when new applications are added to common groups.
The application group is managed by the application identification module.
This example shows how to configure application groups within the application firewall rule set.
Requirements
Before you begin:
Create zones. See Example: Creating Security Zones.
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.
The junos:GOOGLETALK application is included in the predefined group junos:social-networking. To allow junos:GOOGLETALK traffic and deny the rest of the group, the rule permitting junos:GOOGLETALK traffic must come before the rule denying traffic from the rest of the applications in the group.
This configuration example shows how to:
Configure dynamic application groups in an application firewall.
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 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.
- 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
If none of the services (AppFW, IDP, or AppTrack) are configured, then SSL proxy services are bypassed even if an SSL proxy profile is attached to a firewall policy.
This example describes how AppFW supports this AppID functionality when SSL proxy is enabled.
Requirements
Before you begin:
Create zones. See Example: Creating Security Zones.
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 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.
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 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.
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.
Allow all HTTP traffic, except Hulu.
- Configure a policy to process the traffic with AppFW rule
set appfw-rs-1 and SSL proxy profile ssl-profile-1.[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 policy with rule set appfw-rs-2.[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 appfw-rs-1 to permit an encrypted
version of Oracle 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 the AppFW rule set appfw-rs-2 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.
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.
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.