One cool feature added with Firepower version 6 is probably best described as DNS-based Security Intelligence, Inspection and Sinkholing. The thought is pretty simple. If a host issues a DNS request for a host that is known to be malicious, that response is manipulated. The manipulated response can be host not found, an alternative IP address or no response at all. This allows an administrator to provide another layer of protection by preventing hosts ready access to the IP addresses of known malicious hosts.
So the first question that might come to mind is how are hosts on the Internet classified as bad. The short answer is that Talos maintains lists of known bad fully qualified domain names (fqdn). These are actually categorized and delivered into the Firepower solution as a feed. Each of the following category can be selected into one or multiple DNS Rules.
DNS Feeds and Lists
- DNS Attackers
- DNS Bogons
- DNS Bots
- DNS CnC
- DNS Dga
- DNS Exploitkit
- DNS Malware
- DNS Open_proxy
- DNS Open_relay
- DNS Phishing
- DNS Response
- DNS Spam
- DNS Suspicious
- DNS Tor_exit_node
In addition to the above, there are two built in lists that can be controlled by the UI.
The final way that fqdn’s can be assessed for a particular action is by creating a custom file and importing it as a custom DNS list.
In any case, what is being assessed is the fqdn in the DNS request. If a match is found, based on the DNS policy, an action is triggered. The following are possible actions.
DNS Rule Actions
- Domain Not Found
Some of these actions require a little more explanation. The Monitor action is a little unique. When this action has been taken, the rule processing is not terminated. That behavior is unique to the Monitor action. So a DNS request may match a Monitor rule and later match one of the other rules. DNS requests matching a Monitor rule will be logged as a Security Intelligence Event and an End of Connection event into the connections table. A typical use case for this might be to test a category without risk of intrusively manipulating a DNS response.
A Whitelist rule allows the DNS request to be answered normally. This is assuming that the request is allowed by the Access Control Policy (ACP) and not blocked by any IPS rules. Also, the Whitelist DNS action does not get logged as an Security Intelligence Event. The request connection and subsequent data connections to the host may be logged as a connection event, depending on the configuration of the ACP rule matched by the connection.
The Domain Not Found action manipulates the response to contain “No such name“. This prevents the host from obtaining the destination address and discourages it from re-requesting it (as in the case of the Drop action). The Drop action works similarly but simply disallows the DNS response from reaching the client. Both the Drop and Domain Not Found actions log a Security Intelligence Event and a Start of Connection event.
The Domain Not Found and Drop actions are most appropriate when the Firepower device is inline between the Client and the DNS Resolver. If the Firepower device is inline between the DNS Resolver and Internet Name Servers, the Resolver (not the client) will appear to Firepower as the source of all of the requests.
The final action is Sinkhole. This action changes the response to a different valid or non-valid IP address as configured by the administrator. The goal is to allow Firepower, or some system like a honeypot, to see these subsequent connection attempts. This is helpful in the case that Firepower is between the DNS Resolver and Internet Name Servers. In that case, the resolver will get the changed DNS response containing the Sinkhole IP address, cache it, and respond to the clients. The connections to the Sinkhole IP address can be observed so the misbehaving clients will be known.
The logging action for Sinkhole can be ‘log’ or ‘block and log’. This refers to the subsequent connections from the client to the Sinkhole IP address. So if an environment has a honeypot that is outside the Firepower device, a setting of Sinkhole/log might be appropriate. If the Sinkhole address is some non-valid IP address (like 126.96.36.199), the Firepower device can be set to block and log those subsequent connections. If the Sinkhole setting is log only, there is also a Connection entry logged at the end of connection. If the Sinkhole setting is block and log, the Connection entry is logged at the start of the connection attempt.
Configuration of the DNS Policies is straightforward, but might warrant another post in the future. Basically, the policies are created under Policies – Access Control -> DNS. These DNS Policies are then attached to Access Control Policies. This attachment is done in the ACP Security Intelligence tab.
Anyone using Firepower 6 really should take a look at the DNS Policies. This is a way to prevent many hosts from even getting the malicious IP address they are trying to connect to. This is obviously only one layer in threat protection. However, there can be some real and immediate benefit with little or no operational impact on the network.
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This
may or may does not reflect the position of past, present or future employers.