Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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 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 leverage the application identity information from the application identification (AppID) service to permit, deny, reject, or redirect the traffic.

Note

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:

For example on configuring a unified policies, see Configuring Unified Security Policies.

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:

  1. Match the zone pair specified in the policy.

  2. When specified, match the source and destination IP addresses, ports, and application type.

  3. 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.

Note

All IP fragmented packets received on the security 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.

Note

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.

Note

On your security 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.

Note

When your security device (example: 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 StateApplication Firewall ActionApplication ID StateApplication Firewall Action

Success

Deny

Success

Deny

Success

Permit

Success

Permit

Pending

UNKNOWN

Action based on the rule defined for unknown application

Note

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.

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

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.

Note

On all SRX Series devices, J-Web pages for AppSecure Services are preliminary. We recommend using CLI for configuration of AppSecure features.

Configuration

CLI Quick 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:

  1. Configure a policy to process the traffic that goes to the HTTP static ports with the application firewall rule set rs1.
  2. Configure another policy to process any traffic that does not go to the HTTP static ports with the application firewall rule set rs2.
  3. Define the application firewall rule set rs1 to deny traffic from selected dynamic applications.
  4. Define the application firewall rule set rs2 to permit traffic from selected dynamic applications.

Results

From configuration mode, confirm your configuration by entering the show security policies and show security application-firewall commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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 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.

Note

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:

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:

  1. Create the rule-set social-network.
  2. Define a rule to permit Google-Talk traffic.
  3. Define a second rule that denies all other social-networking traffic and traffic from an unknown application.

    Note that rule sequence is important. If the rules google-rule and denied-sites are reversed, GOOGLETALK traffic would never be permitted. The denied-sites rule would shadow google-rule.

  4. Define the default-rule that permits all other traffic.
  5. Configure the outbound-traffic policy to apply the social-network rule-set to all outbound traffic.

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.

Example: Configuring Application Firewall When SSL Proxy Is Enabled

Note

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:

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.

  1. Configure a policy to process the traffic with AppFW rule set appfw-rs-1 and SSL proxy profile ssl-profile-1.
  2. Configure another policy with rule set appfw-rs-2.
  3. Define the AppFW rule set appfw-rs-1 to permit an encrypted version of Oracle and to deny any other encrypted traffic.
  4. Define the AppFW rule set appfw-rs-2 to allow all plain text traffic except Hulu.

Results

From configuration mode, confirm your configuration by entering the show security policies and show security application-firewall commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Note

For application junos-https, SSL proxy detects an SSL session based on the dynamic application identified for that session. If you know any webservers that are running nonstandard ports, you can use a custom Junos OS application to identify the application. However, if the webservers are not known, for example on the Internet, use application any. Non-SSL sessions that come across the policy rule are ignored by SSL proxy. A syslog SSL_PROXY_SESSION_IGNORE is sent out for these sessions. Juniper Networks recommends that you use application “any” with caution because this can result in a lot of traffic, incurring initial SSL proxy processing and thereby impacting performance.

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.

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.

Release History Table
Release
Description
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.