Chapter 19
Discovering Network Applications and Controlling Application Traffic
The Firepower System can dynamically discover what applications are running in a network. It can also identify the host and user who are running a particular application. FTD can discover a network application with or without the help of any active scanner. FTD allows you to block certain traffic solely based on the type of an application a user might be running. This chapter describes how to configure network discovery policy to enable Application Visibility and Control (AVC) with Firepower.
Application Discovery Essentials
When you access a website, you interact with at least three types of applications: a browser on a client computer that originates the web communication, an underlying protocol that establishes the communication channel to the web, and the web contents for which you want to access a website. When an FTD device is configured and deployed properly, it is able to discover all three of these applications in a network. Moreover, it can categorize applications based on risk level, business relevance, content category, and so on.
Application Detectors
The Firepower System uses application detectors to identify the network applications running on a monitored network. The detection capability can vary, depending on the source of the detectors. There are mainly two sources for detectors:
System-provided detectors: The Firepower software, by default, comes with a set of application detectors. However, for a precise detection of the latest applications, you must update the Vulnerability Database (VDB).
The VDB contains the fingerprints of various applications, operating systems, and client software. It also keeps a record of the known vulnerabilities. When a Firepower system discovers an application, it can correlate the application with any known vulnerabilities to determine its impact within a network.
User-created detectors: You can create your own detectors based on patterns you notice on custom applications. The FMC provides full administrative control over your custom detectors, so that you can modify or disable them as necessary. Behind the scenes, it leverages OpenAppID—an open source application detection module.
Note
When a host from a monitored network connects to a server in a nonmonitored network, the FMC infers the application protocol (on the nonmonitored network) by using the information on the client software (of the monitored network).
Table 19-1 shows the type of application detectors supported by Firepower. Except for the built-in internal detectors, you can activate or deactivate any types of detector, as necessary.
Table 19-1 Types of Application Detector
Type of Detector |
Functions |
Internal detector |
Detects protocol, client, and web applications. Internal detectors are always on; they are built in within the software. |
Client detector |
Detects client traffic. It also helps to infer an application protocol on a nonmonitored network. |
Web application detector |
Detects traffic based on the contents in a payload of HTTP traffic. |
Port-based application protocol detector |
Detects traffic based on well-known ports. |
Firepower-based application protocol detector |
Detects traffic based on application fingerprints. |
Custom application detector |
Detects traffic based on user-defined patterns. |
Figure 19-1 shows the application detector page on the FMC. To find this page, go to Policies > Application Detectors. You can search for any desired application to determine its coverage. For example, Figure 19-1 shows retrieval of 69 detectors that are related to Facebook. The total number of detectors can vary, depending on the VDB version running on the FMC.
Operational Architecture
FTD can control an application when a monitored connection is established between a client and server, and the application in a session is identified. To identify an application, FTD has to analyze the first few packets in a session. Until the identification is complete, FTD cannot apply an application rule. To ensure protection during the analysis period, FTD inspects those early packets by using the default intrusion policy of an active access control policy. Upon successful identification, FTD is able to act on the rest of the session traffic based on the access rule created using an application filtering condition. If a prefilter policy or an access control policy is configured to block any particular traffic, FTD does not evaluate the traffic further against a network discovery policy.
Figure 19-2 illustrates the operational workflow of the Firepower engine. It demonstrates that a connection is subject to Application Visibility and Control (AVC) only if it passes the Security Intelligence inspection.
Best Practices for Network Discovery Configuration
FTD discovers a network passively; it does not directly affect the traffic flow. However, to ensure the performance of an FTD device, you should consider the following best practices when you enable network discovery:
Note
Network discovery policy on a Firepower system consists of three functionalities: application discovery, host discovery, and user discovery. This chapter primarily focuses on discovery and control of network applications. You can also learn how to perform host discovery.
Keep the VDB version up to date. Installing the latest version ensures the detection of the latest software with more precise version information.
By default, the FMC comes with an application discovery rule, which uses 0.0.0.0/0 and ::/0 as the network address. This address enables a Firepower system to discover applications from any observed networks. Do not remove this default rule, as Snort leverages the application discovery data for intrusion detection and prevention by detecting the service metadata of a packet.
When you add a custom rule for host and user discovery, include only the network addresses you own. Do not add the network address 0.0.0.0/0 and ::/0 to a host and user discovery rule, because doing so can deplete the host and user licenses quickly.
Exclude the IP addresses of any NAT and load balancing devices from the list of monitored networks. These types of IP address can represent multiple computers running in a LAN, which leads an FTD device to generate excessive discovery events whenever there are activities in the LAN. Exclusion of NAT and load balancing IP addresses can improve the performance of FTD.
Figure 19-3 shows the positions of two types of intermediate devices—a router and a load balancer—that can each represent multiple network hosts.
You can also exclude any ports from monitoring if you are sure about the service a port might be running. Doing so reduces the number of discovery events for known ports and services.
Avoid creating overlapping rules that include the same hosts multiple times to prevent performance degradation.
Deploy the FTD device as close as possible to the hosts. The lower the hop count between an FTD device and a host, the faster the FTD device detects the host and with a higher confidence value.
Fulfilling Prerequisites
Before you begin configuring a network discovery rule, fulfill the following requirements:
The Firepower System uses the Adaptive Profiles option to perform application control. This option enhances detection capabilities of an FTD. The Adaptive Profile Updates option leverages the service metadata and helps an FTD determine whether a particular intrusion rule is pertinent to an application running on a particular host and whether the rule should be enabled.
By default, the Adaptive Profiles option is enabled (see Figure 19-4). You can verify the configuration status in the Advanced tab of an access control policy, under Detection Enhancement Settings.
Create network objects for the network addresses that you want to add to a discovery rule. This helps you manage your configuration once you deploy a network discovery policy. To create an object, go to Objects > Object Management on the GUI. This page also enables you to modify the value of a custom object if necessary. However, you cannot modify a system-provided network object. To determine the type of an object, look at the rightmost column—a custom network object shows a pencil icon (see Figure 19-5), which you can select to modify the value of the object.
Tip
The system also enables you to create an object on the fly directly from the rule editor window (see Figure 19-8, later in the chapter).
Discovering Applications
In the following sections, you will learn how to configure a network discovery policy to discover network applications as well as network hosts. To demonstrate the impact of an intermediate networking device representing multiple internal hosts, a router has been placed between the FTD device and the LAN switch in the topology.
Figure 19-6 shows the topology that is used in this chapter to demonstrate the configuration of a network discovery policy.
Configuring a Network Discovery Policy
To configure a network discovery policy, follow these steps:
Step 1. In the FMC, navigate to Policies > Network Discovery. The default rule for application discovery appears (see Figure 19-7). It monitors traffic from any network to discover applications.
Step 2. Click the Add Rule button. The Add Rule window appears.
Step 3. First, add a rule to exclude the IP address of any intermediate NAT and load balancing devices. To do that, select Exclude from the Action dropdown, and then select a network object that represents your desired IP address.
Tip
If you did not create a network object previously in the Fulfilling Prerequisites section, you can do it now on the fly using the green plus icon. Alternatively, you can add an IP address directly on the rule editor window.
Figure 19-8 shows a discovery rule that excludes a network object, NAT-Outside-IP. The object maps the IP address of the router’s outside interface. The figure also highlights the available options to add an object or address on the fly.
Step 4. Click the Save button to return to the network discovery policy page.
Step 5. Next, to include the network you want to monitor, click the Add Rule button again. The Add Rule window appears.
Step 6. Select Discover from the Action dropdown, and then select a network object that represents your desired IP network.
Tip
If you want to monitor a private network, you can select one of the system-provided network objects.
Figure 19-9 shows a network discovery rule that can discover hosts and applications running on a network with private IP addresses (RFC 1918).
Step 7. Click the Save button to return to the network discovery policy page, and then click the Deploy button to deploy the network discovery policy on your FTD device.
Figure 19-10 shows the two network discovery rules you have just created.
Verification and Troubleshooting Tools
Now you can verify the functionality of network discovery by passing network traffic through an FTD device. First, from your client computers, go to various websites on the Internet. Doing so generates traffic through the FTD device. If the network discovery policy is properly configured and deployed, you will be able to view discovery events in the FMC GUI.
Analyzing Application Discovery
You can view a summary of the application data by using the Application Statistics dashboard, located at Overview > Dashboards > Application Statistics. The dashboard shows several data points in different widgets. You can add, remove, or modify any widgets, as desired.
Figure 19-11 shows six widgets in the Application Statistics dashboard. Each widget displays a unique statistic of the application running in a monitored network.
Figure 19-12 shows different types of discovery events. They are generated when a user connects an Apple Mac OS X to a network and opens a web browser, Safari. This figure also shows subsequent discoveries of various applications on the Mac.
Analyzing Host Discovery
You can view the operating systems running on a monitored network from the Analysis > Hosts > Hosts page. The Firepower System can identify most of the operating systems, along with their version detail. Click the Summary of the OS Versions to view the version information.
If some operating systems appear as pending, it is because FTD is currently analyzing the collected data or waiting on further packets to conclude. The unknown state indicates that the pattern of packets does not match an application detector. Updating the VDB to the latest version can reduce the number of unknown discovery events.
Figure 19-13 shows the name and version of operating systems running on a monitored network. It also shows examples of unknown and pending operating system.
Tip
Remember this best practice: The lower the hop count between an FTD device and a host, the faster the FTD device detects the host and with a higher confidence value. Moreover, additional intermediate devices between an FTD device and hosts can alter or truncate important packet data. Therefore, you should deploy an FTD device as close as possible to the monitored hosts.
Undiscovered New Hosts
If you find a new host undetected by your FTD device, you should check a couple items:
Check whether the FMC generates any health alerts for exceeding the host limits. To receive an alert due to the oversubscription of host discovery, the health monitor module for Host Limit must be enabled.
Figure 19-14 shows the option to enable a health module that can trigger an alert when the FMC exceeds its host limit. To find this page, go to System > Health > Policy and edit a health policy you want to apply.
By analyzing the network map on the FMC, you can determine the number of unique hosts identified by a Firepower system and compare the number with the host limit for an FMC model. You can also recognize any hosts that might be representing multiple hosts, such as a router with NAT feature enabled or a load balancer. It helps you to select an IP address for exclusion.
Table 19-2 shows the maximum number of hosts the FMC can discover at any time.
Table 19-2 FMC Limitation for Host Discovery
FMC Model |
Host Limit |
FS 2000 |
150,000 |
FS 4000 |
600,000 |
Virtual |
50,000 |
As of this writing, Cisco supports additional FMC models, such as FS750, FS1500, and FS3500, which were designed prior to the Sourcefire acquisition. While this book uses the latest hardware models, you can still apply this knowledge on any legacy hardware models. For any specific information on the legacy hardware models, read the official user guide.
Figure 19-15 demonstrates that, although there are only 3 hosts in an internal network, FTD discovers more than 300 hosts in the external network within a few minutes. This discovery consumes additional resources and licenses from the Firepower System. To find this page, go to Analysis > Hosts > Network Map.
Check how the network discovery policy is configured to handle a host when the FMC reaches the threshold for host limit. You can configure a policy to stop discovering any new hosts or to drop the earliest discoveries when the FMC reaches its limit.
Figure 19-16 shows the navigation to a dropdown where you can choose between dropping an old host and locking down any new entries.
Blocking Applications
If an access control policy has no access rule with an application filtering condition, FTD allows any applications as long as connections to an application are permitted by the policy on the default action. You can verify this default behavior by attempting to access an application such as Facebook. However, if you want to restrict access to an application, you need to add an access rule for it.
Configuring Blocking of Applications
To block access to an application, you need to create an access rule by following these steps:
Step 1. Navigate to Policies > Access Control > Access Control. A list of available access control policies appears.
Step 2. Use the pencil icon to edit the access control policy that you want to deploy on an FTD device. The access control policy editor page appears.
Step 3. Click the Add Rule button. The rule editor window appears.
Step 4. Give a name to the rule and select a desired action for the matched traffic.
Step 5. Select the Applications tab. A list of available application filters appears.
Figure 19-17 shows an access rule with an application filtering condition. FTD uses the rule to block a connection by sending reset packets whenever it detects an application in the Social Networking category.
Step 6. Use the search field in the Application Filter section to find a desired application category. You can select traffic based on categories, business relevance, risks, types, and so on. Alternatively, to find a specific application, you can just enter the application name in the search field in the Available Applications section.
Step 7. After you select the desired applications, add them to the rule.
Step 8. Go to the Logging tab to enable logging for any matching connections. This is an optional step, but it allows you to view an event when FTD blocks a connection.
Step 9. Click the Save button in the rule editor window to complete the creation of an access rule with an application filtering condition.
Figure 19-18 shows this new access rule, which blocks any applications that are related to the Social Networking category only. Any other applications are subject to the default action.
Step 10. Finally, on the policy editor page, click Save to save the configurations, and click Deploy to deploy the policy on an FTD device.
Verification and Troubleshooting Tools
After deploying the policy that you created earlier in this chapter, in this section you’ll try to access the Facebook application once again. This time the connection should be blocked.
Figure 19-19 shows two types of connections to the Facebook application. When a connection is allowed, it hits the default action. However, when the social networking rule finds a match, it inspects the connection and blocks with reset packets.
Example 19-1 shows the debugging data generated by the firewall engine. It confirms that FTD is able to detect facebook.com and then applies the rule action to block with reset.
Example 19-1 Debugging Messages Generated by the Firewall Engine
> system support firewall-engine-debug
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Monitoring firewall engine debug messages
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 New session
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 Starting with minimum 2, 'Social
Networking Rule', and SrcZone first with zones -1 -> -1, geo 0(0) -> 0, vlan 0,
sgt tag: untagged, svc 0, payload 0, client 0, misc 0, user 9999997, url , xff
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 pending rule order 2,
'Social Networking Rule', AppId
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 Starting with minimum 2, 'Social
Networking Rule', and SrcZone first with zones -1 -> -1, geo 0(0) -> 0, vlan 0,
sgt tag: untagged, svc 0, payload 0, client 0, misc 0, user 9999997, url , xff
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 pending rule order 2,
'Social Networking Rule', AppId
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 Starting with minimum 2, 'Social
Networking Rule', and SrcZone first with zones -1 -> -1, geo 0(0) -> 0, vlan 0,
sgt tag: untagged, svc 0, payload 0, client 0, misc 0, user 9999997, url , xff
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 pending rule order 2,
'Social Networking Rule', AppId
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 URL SI: ShmDBLookupURL
("www.facebook.com") returned 0
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 Starting with minimum 2, 'Social
Networking Rule', and SrcZone first with zones -1 -> -1, geo 0(0) -> 0, vlan 0,
sgt tag: untagged, svc 1122, payload 629, client 1296, misc 0, user 9999997, url
www.facebook.com, xff
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 match rule order 2,
'Social Networking Rule', action Reset
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 reset action
172.16.100.110-4677 > 31.13.65.36-443 6 AS 4 I 1 Deleting session
Example 19-2 shows the debugging of application data generated by the Firepower engine. It displays the identification number (appID) of the application that is detected by the FTD device.
Example 19-2 Debugging Messages for Application Identification
> system support application-identification-debug
Please specify an IP protocol: tcp
Please specify a client IP address:
Please specify a client port:
Please specify a server IP address:
Please specify a server port:
Monitoring application identification debug messages
.
.
172.16.100.110-4677 -> 31.13.65.36-443 6 R AS 4 I 1 port service 0
172.16.100.110-4677 -> 31.13.65.36-443 6 AS 4 I 1 3rd party returned 847
172.16.100.110-4677 -> 31.13.65.36-443 6 AS 4 I 1 SSL is service 1122,
portServiceAppId 1122
172.16.100.110-4677 -> 31.13.65.36-443 6 AS 4 I 1 ssl returned 10
172.16.100.110-4677 -> 31.13.65.36-443 6 AS 4 I 1 appId: 629
(safe)search_support_type=NOT_A_SEARCH_ENGINE
^C
Caught interrupt signal
Exiting
Example 19-3 shows a query from the FMC database. It retrieves the mapping of the appID with an associated application name (appName). It confirms that the FTD device was able to identify the Facebook application correctly.
Example 19-3 Mapping Application ID with an Application Name
admin@FMC:~$ sudo OmniQuery.pl -db mdb -e "select appId,appName from appIdInfo where
appId=629";
Password:
getting filenames from [/usr/local/sf/etc/db_updates/index]
getting filenames from [/usr/local/sf/etc/db_updates/base-6.1.0]
+-------+----------+
| appId | appName |
+-------+----------+
| 629 | Facebook |
+-------+----------+
----------------------------
OmniQuery v2.1
(c) 2016 Cisco Systems, Inc.
.:|:.:|:.
----------------------------
mdb> exit
admin@FMC:~$
Summary
This chapter describes how the Firepower System can make you aware of the applications running on your network and empower you to control access to any unwanted applications. It also shows how to verify whether an FTD device can identify an application properly.
Quiz
1. Which of the following statements is true?
a. A network discovery policy allows you to exclude network addresses but not any port numbers.
b. You cannot determine the number of unique hosts identified by a Firepower system until it reaches the license limit.
c. If a prefilter policy or an access control policy is configured to block any particular traffic, FTD does not evaluate the traffic further against a network discovery policy.
d. All of the above.
2. Which of the following commands provides the ID for a discovered application?
a. system support app-id-debug
b. system support firewall-debug
c. system support firepower-engine-debug
d. system support application-identification-debug
3. Which of the following can affect the accuracy of network discovery?
a. Snort rule database
b. URL Filtering database
c. Vulnerability Database
d. Discovery event database
4. To improve the performance of network discovery, which of the following should you consider?
a. Ensure that the network discovery policy is set to monitor the load balancer devices.
b. Use the network address 0.0.0.0/0 and ::/0 in any discovery rules you create.
c. Enable Firepower Recommendations in an intrusion policy.
d. Keep the Vulnerability Database (VDB) version up to date.