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) provides policy-based enforcement and control on traffic based on application signatures. By using AppFW, you can block any application traffic not sanctioned by the enterprise. For more information, see the following topics:

Application Firewall Overview

This topic includes the following sections:

Limitations with Stateful Firewalls

Traditionally stateful firewalls used to control applications such as HTTP, SMTP, and DNS because these applications used well-known standards ports only. However, now it is possible to run these applications on any port as long as the client and server are using same protocol and same ports. Because of this standard stateful firewalls are not able to detect evasive applications. Additionally, with the growing popularity of Web applications and the shift from traditional full client-based applications to the Web, more and more traffic is being transmitted over HTTP.

This limitation of stateful firewalls, in which firewalls inspect traffic based on Layer 3 and Layer 4, left open to allow application layer exploits.

Application Firewall

Juniper Networks’ application firewall (AppFW) leverages the results from the application identification to make an informed decision to permit, deny, reject, or redirect the traffic based on applications. AppFW enables you to enforce the policy control on Layer 7 traffic.

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:

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:

  • If you are downgrading from Junos OS Release 18.2R1 to any earlier versions of Junos OS:

    • You must delete all unified policies to avoid a commit check failure after a downgrade.

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

Example: Configure Application Firewall with Unified Policy

This example describes how to configure a unified policy to allow or block traffic based on the applications.

System Requirements

System Requirements

This example uses the following hardware and software components:

  • SRX Series Firewall running Junos OS Release 18.2R1. This configuration example is tested with Junos OS release 19.1R1.

Before You Begin

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.

Figure 1: Topology For Unified Policies ExampleTopology For Unified Policies Example

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.

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:

  1. Configure security zones and interfaces.

  2. Create redirect profile.

  3. Create a security policy with a dynamic application as the match criteria.

  4. Create a default policy to permit the remaining traffic.

Results

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

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

Verification

Use the following procedures to verify if the policy configuration.

Verifying Policy Action

Purpose

Verify that the unified policy has blocked that configured applications.

Action

From your Web browser, try to access the application. For example, Yahoo-Mail. The system displays the redirect message as shown in the following image.

Meaning

Whenever the security policy rejects traffic based on the dynamic application, the output displays the redirect message as configured by you in the dynamic application profile.

Verifying Unified Policy Configuration

Purpose

Verify that the unified policy configuration is correct.

Action

From operational mode, enter the show security policies detail command to display a detailed summary of all security policies on the device.

Meaning

The output displays information about security policy. Verify the following information:

  • Configured policy name policy-1 and policy action reject.

  • Configured dynamic applications junos:FACEBOOK-ACCESS and junos:YAHOO-MAIL.

  • Redirect profile profile1.

Traditional Application Firewall

This topic includes the following sections:

Understanding How Application Firewall Works

As you can use existing security policy to enforce traditional firewall controls on the traffic, you can use AppFW module to block certain application traffic, based on their application signatures, while still allowing other HTTP traffic to pass through the firewall.

Security device processes traffic in the following sequence when you have configured a AppFW:

  1. Security policy matches the zone pair specified in the policy.

  2. Security policy matches the packets with matching conditions (source and destination IP addresses, source and destination ports, and application type)

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

Table 1: Session Logging for Application Firewall Configuration

Security Policy Action

Log Creation

More Details

Permit

Creates a session and logs a session create message

When security policy permit action creates a session even before the AppFW rules are applied, log message includes one of the following update:

  • If the application is already identified, it’s information is added to the session create message.

  • If the application is in the process of being identified, the dynamic application field are updated as UNKNOWN.

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:

  • appfw deny or appfw deny redirect

  • appfw reject or appfw reject redirect

  • policy deny

  • policy reject

Application Firewall Support in Chassis Cluster

When your security device is in chassis cluster mode, the AppFW action before and after the failover depends on the application identification state, as shown in Table 2.

Table 2: Application Firewall Actions

Before Failover

After Failover

Application ID State Application Firewall Action Application ID State Application Firewall Action

Success

Deny

Success

Deny

Success

Permit

Success

Permit

Pending

UNKNOWN

Action based on the rule defined for unknown application

If there is no rule defined for unknown, then the default rule is applied

Note the following when you have your security device in chassis cluster mode:

  • When you enable application identification, the pre-match state application IDs are not synced to other node. If there are any failover sessions, which were still under classification, will not have any application IDs assigned. This could result in application statistics and counters mismatch.

  • In-service software upgrade (unified ISSU) is not supported due to lack of chassis cluster infrastructure support. Thus, the failover event is controlled through the application firewall policy by allowing or denying the unknown dynamic applications.

Creating Redirects in Application Firewall

When AppFW denies or rejects traffic, it does not notify clients that such action is taken. Clients being unaware that their request is rejected, might keep on trying to access the Web page. To alleviate this inconvenience, the Junos OS allows you to provide an explanation for the action or to redirect the client to an informative webpage. Following examples show you how to create a redirect message.

Redirect with Block Message

Use the block-message option with the reject or deny action in AppFW rule.

When AppFW rejects the traffic, a splash screen displays the following default message to the user:

Customize Redirect Message

You can customize the redirect action by including additional text on the splash screen or by specifying a URL to which you can redirect a user. To customize the block message, you must create a block message profile at [edit security application-firewall] hierarchy level and define the type and content as shown in the following sample.

Next, you refer the block message profile in the AppFW rule set, and apply it to one or more of the rules using the block-message option;

In this case, AppFW displays the configured block message whenever it rejects the traffic based on the configured rule.

Customize Redirect Message with URL

When AppFW rejects or redirects the traffic, you can redirect the client to the specified Web page for further action. The URL can be hosted on either the SRX Series 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:

Next, you refer the block message profile in the AppFW rule set, and apply to one or more of the rules using the block-message option as shown in the following sample:

In this case, AppFW redirects the use to the URL http://abc.company.com/information whenever it rejects the traffic based on the configured rule.

Example: Configuring Application Firewall

This example shows how to configure application firewall rule sets within the security policy.

Before You Begin

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.

Table 3: Configure Application Firewall to Permit or Deny Traffic

Objectives

Steps to Follows

Results

Block a certain application and allow other applications

Configure a security policy to allow HTTP traffic.

Security policy permits or drops the traffic based on matching specified Layer 3 or Layer 4 criteria.

Configure an AppFW rule set with following options:

  • Rules with dynamic applications that you want to block

  • Action to deny dynamic application traffic.

  • Default rule to permit other traffic

AppFW assess the permitted traffic at Layer 7 based on its application ID.

Refer the AppFW rule set in the security policy.

  • AppFW blocks the traffic matching the configured dynamic applications.

  • Default policy permits other traffic.

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:

  • Rules with dynamic applications that you want to permit

  • Action to permit dynamic application traffic.

  • Default rule to block other traffic.

AppFW assess the permitted traffic at Layer 7 based on its application ID.

Refer the AppFW rule set in the security policy.

  • AppFW permits the traffic matching the configured dynamic applications.

  • Default policy blocks other traffic.

Note:

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

In this example, you block dynamic-applications junos:FACEBOOK-CHAT junos:FACEBOOK-FARMVILLE and allow remaining traffic.

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see CLI User Guide.

To configure two security policies with application firewall rule sets that permit or deny traffic from different dynamic applications:

  1. Define the application firewall rule set to deny traffic from selected dynamic applications.

  2. Configure the security policy to allow HTTP traffic and invoke application firewall rule set rs1.

Results

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

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

Application Firewall Rule to Explicitly Permit Certain Application and Deny All Else

In this example, you permit dynamic-applications junos:FACEBOOK-ACCESS and block remaining traffic.

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see CLI User Guide.

To configure two security policies with application firewall rule sets that permit or deny traffic from different dynamic applications:

  1. Configure a security policy to process any traffic that does not go to the HTTP static ports with the application firewall rule set rs2.

  2. Define the application firewall rule set 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 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

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.

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

  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

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:

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.

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.

  1. Configure a security policy to process the traffic with AppFW rule set and SSL proxy profile.

  2. Configure another security policy with AppFW rule set.

  3. Define the AppFW rule set to permit an encrypted version of Oracle traffic and to deny any other encrypted traffic.

  4. Define another AppFW rule set 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:

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.

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.

Release
Description
18.2R1
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.