Application Firewall on NFX Devices
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 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.
When ALG is enabled on the device, 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
See also
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.
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.