Recommendations for application control
Keep in mind the following guidelines and limitations for application control:
Ensure that adaptive profiling is enabled
If adaptive profiling is not enabled (its default state), access control rules cannot perform application control.
Enable application detectors automatically
If no detector is enabled for an application you want to detect, the system automatically enables all system-provided detectors for the application. If none exist, the system enables the most recently modified user-defined detector for the application.
Configure your policy to examine the packets that must pass before an application is identified
The system cannot perform application control before both of the following occur:
-
A monitored connection is established between a client and server
-
The system identifies the application in the session
This identification should occur in 3 to 5 packets, or after the server certificate exchange in the SSL handshake if the traffic is encrypted. If you configure the access control rule to use application default ports, the application rule can be enforced without allowing initial packets to pass.
If early traffic matches all other criteria but application identification is incomplete, the system allows the packet to pass and the connection to be established (or the SSL handshake to complete). After the system completes its identification, the system applies the appropriate action to the remaining session traffic.
To ensure that your system examines these initial packets, select an intrusion policy in the Intrusion Policy used before Access Control rule is determined options in the access control policy advanced settings.
Understand limitations to identitifying applications
A server must adhere to the protocol requirements of an application for the system to be able to recognize it. For example, if you have a server that sends a keep-alive packet rather than an ACK when an ACK is expected, that application might not be identified, and the connection will not match the application-based rule. Instead, it will be handled by another matching rule or the default action. This might mean that connections you want to allow can be denied instead. If you run into this problem, and you cannot fix the server to follow the protocol standards, you need to write a non-application-based rule to cover traffic for that server, for example, by matching the IP address and port number.
Create separate rules for URL and application filtering
Create separate rules for URL and application filtering whenever possible, because combining application and URL criteria can lead to unexpected results, especially for encrypted traffic.
Rules that include both application and URL criteria should come after application-only or URL-only rules, unless the application+URL rule is acting as an exception to a more general application-only or URL-only rule.
Place URL rules before application and other rules
For the most effective URL matching, place rules that include URL conditions before other rules, particularly if the URL rules are block rules and the other rules meet both of the following criteria:
-
They include application conditions.
-
The traffic to be inspected is encrypted.
Handling application traffic packets without payloads
When performing access control, the system applies the default policy action to packets that do not have a payload in a connection where an application is identified.
Handling referred application traffic
To handle traffic referred by a web server, such as advertisement traffic, match the referred application rather than the referring application.
Controlling application traffic that uses multiple protocols
Some applications use multiple protocols. To control their traffic, make sure your access control policy covers all relevant options. These applications typically include the application name in each aspect that you can control. Also see Application-specific notes and limitations.