Overview: Application Detection
When the Firepower System analyzes IP traffic, it attempts to identify the commonly used applications on your network. Application awareness is crucial to application control.
There are three types of applications that the system detects:
-
application protocols such as HTTP and SSH, which represent communications between hosts
-
clients such as web browsers and email clients, which represent software running on the host
-
web applications such as MPEG video and Facebook, which represent the content or requested URL for HTTP traffic
The system identifies applications in your network traffic according to the characteristics specified in the detector. For example, the system can identify an application by an ASCII pattern in the packet header. In addition, Secure Socket Layers (SSL) protocol detectors use information from the secured session to identify the application from the session.
There are two sources of application detectors in the Firepower System:
-
System-provided detectors detect web applications, clients, and application protocols.
The availability of system-provided detectors for applications (and operating systems) depends on the version of the Firepower System and the version of the VDB you have installed. Release notes and advisories contain information on new and updated detectors. You can also import individual detectors authored by Professional Services.
-
Custom application protocol detectors are user-created and detect web applications, clients, and application protocols.
You can also detect application protocols through implied application protocol detection, which infers the existence of an application protocol based on the detection of a client.
The system identifies only those application protocols running on hosts in your monitored networks, as defined in the network discovery policy. For example, if an internal host accesses an FTP server on a remote site that you are not monitoring, the system does not identify the application protocol as FTP. On the other hand, if a remote or internal host accesses an FTP server on a host you are monitoring, the system can positively identify the application protocol.
If the system can identify the client used by a monitored host to connect to a non-monitored server, the system identifies the client's corresponding application protocol, but does not add the protocol to the network map. Note that client sessions must include a response from the server for application detection to occur.
The system characterizes each application that it detects; see Application Characteristics. The system uses these characteristics to create groups of applications, called application filters. Application filters are used to perform access control and to constrain search results and data used in reports and dashboard widgets.
You can also supplement application detector data using exported NetFlow records, Nmap active scans, and the host input feature.
Application Detector Fundamentals
The Firepower System uses application detectors to identify the commonly used applications on your network. Use the Detectors page () to view the detector list and customize detection capability.
Whether you can modify a detector or change its state (active or inactive) depends on its type. The system uses only active detectors to analyze application traffic.
Note |
Cisco-provided detectors may change with Firepower System and VDB updates. See the release notes and advisories for information on updated detectors. |
Cisco-Provided Internal Detectors
Internal detectors are a special category of detectors for client, web application, and application protocol traffic. Internal detectors are delivered with system updates and are always on.
If an application matches against internal detectors designed to detect client-related activity and no specific client detector exists, a generic client may be reported.
Cisco-Provided Client Detectors
Client detectors detect client traffic and are delivered via VDB or system update, or are provided for import by Cisco Professional Services. You can activate and deactivate client detectors. You can export a client detector only if you import it.
Cisco-Provided Web Application Detectors
Web application detectors detect web applications in HTTP traffic payloads and are delivered via VDB or system update. Web application detectors are always on.
Cisco-Provided Application Protocol (Port) Detectors
Port-based application protocol detectors use well-known ports to identify network traffic. They are delivered via VDB or system update, or are provided for import by Cisco Professional Services. You can activate and deactivate application protocol detectors, and view a detector definition to use it as the basis for a custom detector.
Cisco-Provided Application Protocol (Firepower) Detectors
Firepower-based application protocol detectors analyze network traffic using Firepower application fingerprints and are delivered via VDB or system update. You can activate and deactivate application protocol detectors.
Custom Application Detectors
Custom application detectors are pattern-based. They detect patterns in packets from client, web application, or application protocol traffic. You have full control over imported and custom detectors.
Identification of Application Protocols in the Web Interface
The following table outlines how the Firepower System identifies detected application protocols:
Identification |
Description |
---|---|
application protocol name |
The Firepower Management Center identifies an application protocol with its name if the application protocol was:
|
|
The
Firepower Management Center
identifies an application protocol as
Most often, the system needs to collect and analyze more connection data before it can identify a pending application. In the Application Details and Servers tables and in the host
profile, the
|
|
The
Firepower Management Center
identifies an application protocol as
|
blank |
All available detected data has been examined, but no application protocol was identified. In the Application Details and Servers tables and in the host profile, the application protocol is left blank for non-HTTP generic client traffic with no detected application protocol. |
Implied Application Protocol Detection from Client Detection
If the system can identify the client used by a monitored host to access a non-monitored server, the Firepower Management Center infers that the connection is using the application protocol that corresponds with the client. (Because the system tracks applications only on monitored networks, connection logs usually do not include application protocol information for connections where a monitored host is accessing a non-monitored server.)
This process, or implied application protocol detection, has the following consequences:
-
Because the system does not generate a New TCP Port or New UDP Port event for these servers, the server does not appear in the Servers table. In addition, you cannot trigger either discovery event alerts or correlation rules using the detection of these application protocol as a criterion.
-
Because the application protocol is not associated with a host, you cannot view its details in host profiles, set its server identity, or use its information in host profile qualifications for traffic profiles or correlation rules. In addition, the system does not associate vulnerabilities with hosts based on this type of detection.
You can, however, trigger correlation events on whether the application protocol information is present in a connection. You can also use the application protocol information in connection logs to create connection trackers and traffic profiles.
Host Limits and Discovery Event Logging
When the system detects a client, server, or web application, it generates a discovery event unless the associated host has already reached its maximum number of clients, servers, or web applications.
Host profiles display up to 16 clients, 100 servers, and 100 web applications per host.
Note that actions dependent on the detection of clients, servers, or web applications are unaffected by this limit. For example, access control rules configured to trigger on a server will still log connection events.
Special Considerations for Application Detection
SFTP
In order to detect SFTP traffic, the same rule must also detect SSH.
Squid
The system positively identifies Squid server traffic when either:
-
the system detects a connection from a host on your monitored network to a Squid server where proxy authentication is enabled, or
-
the system detects a connection from a Squid proxy server on your monitored network to a target system (that is, the destination server where the client is requesting information or another resource).
However, the system cannot identify Squid service traffic if:
-
a host on your monitored network connects to a Squid server where proxy authentication is disabled, or
-
the Squid proxy server is configured to strip Via: header fields from its HTTP responses
SSL Application Detection
The system provides application detectors that can use session information from a Secure Socket Layers (SSL) session to identify the application protocol, client application, or web application in the session.
When the system detects an encrypted connection, it marks that
connection as either a generic HTTPS connection or as a more specific secure
protocol, such as SMTPS, when applicable. When the system detects an SSL
session, it adds
SSL client
to the
Client field in connection events for the session.
If it identifies a web application for the session, the system generates
discovery events for the traffic.
For SSL application traffic, managed devices can also detect the
common name from the server certificate and match that against a client or web
application from an SSL host pattern. When the system identifies a specific
client, it replaces
SSL client
with the name of the client.
Because the SSL application traffic is encrypted, the system can use only information in the certificate for identification, not application data within the encrypted stream. For this reason, SSL host patterns can sometimes only identify the company that authored the application, so SSL applications produced by the same company may have the same identification.
In some instances, such as when an HTTPS session is launched from within an HTTP session, managed devices detect the server name from the client certificate in a client-side packet.
To enable SSL application identification, you must create access
control rules that monitor responder traffic. Those rules must have either an
application condition for the SSL application or URL conditions using the URL
from the SSL certificate. For network discovery, the responder IP address does
not have to be in the networks to monitor in the network discovery policy; the
access control policy configuration determines whether the traffic is
identified. To identify detections for SSL applications, you can filter by the
SSL protocol
tag, in the application detectors list or
when adding application conditions in access control rules.
Referred Web Applications
Web servers sometimes refer traffic to other websites, which are often advertisement servers. To help you better understand the context for referred traffic occurring on your network, the system lists the web application that referred the traffic in the Web Application field in events for the referred session. The VDB contains a list of known referred sites. When the system detects traffic from one of those sites, the referring site is stored with the event for that traffic. For example, if an advertisement accessed via Facebook is actually hosted on Advertising.com, the detected Advertising.com traffic is associated with the Facebook web application. The system can also detect referring URLs in HTTP traffic, such as when a website provides a simple link to another site; in this case, the referring URL appears in the HTTP Referrer event field.
In events, if a referring application exists, it is listed as the web application for the traffic, while the URL is that for the referred site. In the example above, the web application for the connection event for that traffic would be Facebook, but the URL would be Advertising.com. A referred application may appear as the web application if no referring web application is detected, if the host refers to itself, or if there is a chain of referrals. In the dashboard, connection and byte counts for web applications include sessions where the web application is associated with traffic referred by that application.
Note that if you create a rule to act specifically on referred traffic, you should add a condition for the referred application, rather than the referring application. To block Advertising.com traffic referred from Facebook, for example, add an application condition to your access control rule for the Advertising.com application.
Application Detection in Snort 2 and Snort 3
In Snort 2, you can enable or disable application detection through the constraints in the access control policies and through network filters in the network discovery policies. However, the contraints in access control policy can override the network filters and enable application detection. For example, if you have defined network filters in network discovery policy and when the access control policy has constraints such as SSL, URL SI, DNS SI, and so on, that requires application detection, then these network discovery filters are overridden and all networks are monitored for application detection. This Snort 2 functionality is not supported in Snort 3.
In Snort 3, application detection is always enabled for all networks by default. To disable application detection, do the following:
Procedure
Step 1 |
Delete appliction rules from access control policy. |
Step 2 |
Delete SSL policy. |
Step 3 |
Delete network discovery policy. |
Step 4 |
Delete URL Allow/Block list in SI. |
Step 5 |
As you cannot delete default DNS rules, edit the default DNS policy to disable them. |
Step 6 |
Save and deploy the access control policy. |