Keep in mind the following guidelines and limitations for application control:
Ensuring that Adaptive Profiling is Enabled
If adaptive profiling is not enabled (its default state), access control rules cannot perform application control.
Automatically Enabling Application Detectors
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, including Intelligent Application Bypass (IAB) and rate limiting, before both of the following occur:
This identification should occur in 3 to 5 packets, or after the server certificate exchange in the SSL handshake if the traffic
Important! To ensure that your system examines these initial packets, see Specify a Policy to Handle Packets That Pass Before Traffic Identification.
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.
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
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.
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:
Application Control for Encrypted and Decrypted Traffic
The system can identify and filter encrypted and decrypted traffic:
Encrypted traffic—The system can detect application traffic encrypted with StartTLS, including SMTPS, POPS, FTPS, TelnetS,
and IMAPS. In addition, it can identify certain encrypted applications based on the Server Name Indication in the TLS ClientHello
message, or the subject distinguished name value from the server certificate. These applications are tagged SSL Protocol; in an SSL rule, you can choose only these applications. Applications without this tag can only be detected in unencrypted
or decrypted traffic.
Decrypted traffic—The system assigns the decrypted traffic tag to applications that the system can detect in decrypted traffic only, not encrypted or unencrypted.
TLS Server Identity Discovery and Application Control
The latest version of the Transport Layer Security (TLS) protocol 1.3, defined by RFC 8446, is the preferred protocol for many web servers to provide secure communications. Because the TLS 1.3 protocol encrypts the
server's certificate for additional security, and the certificate is needed to match application and URL filtering criteria
in access control rules, the Firepower System provides a way to extract the server certificate without decrypting the entire packet.
We strongly recommend enabling it for any traffic you want to match on application or URL criteria, especially if you want
to perform deep inspection of that traffic. An
SSL policy is not required because traffic is not decrypted in the process of extracting the server certificate.
For more information, see Access Control Policy Advanced Settings.
Exempting Applications from Active Authorization
In an identity policy, you can exempt certain applications from active authentication, allowing traffic to continue to access
control. These applications are tagged User-Agent Exclusion. In an identity rule, you can choose only these applications.
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
Controlling Application Traffic That Uses Multiple Protocols (Skype, Zoho)
Some applications use multiple protocols. To control their traffic, make sure your access control policy covers all relevant
options. For example:
Skype—To control Skype traffic, choose the Skype tag from the Application Filters list rather than selecting individual applications. This ensures that the system can detect and control all Skype traffic
the same way.
Zoho—To control Zoho mail, choose both
Zoho and Zoho mail from the Available Application list.
Search Engines Supported for Content Restriction Features
The system supports Safe Search filtering for specific search engines only. The system assigns the safesearch supported tag to application traffic from these search engines.