A few days ago I wrote an article that described Firepower DNS Policies. One item that probably warrants a little more discussion is DNS Sinkholing. Although the title of this article indicates Firepower Threat Defense, this will also work with Firepower and Firepower Services.
For this article, I would like to first share some of the challenges around getting security intelligence visibility from DNS requests. A typical enterprise environment will have an internal DNS server. So even though we know we can return “Domain Not Found” with an FTD DNS policy, that might not give us the visibility necessary to remediate a problem.
So if the host in the diagram below makes a DNS request for bad.site.com, what happens? Basically that request is sent to the DNS Resolver. The DNS Resolver will look to the Root Hints and eventually get the request to an Internet based DNS server that has the appropriate domain ownership. The problem with this is that the only request seen by the Firewall (FTD in our example) is the one made by the DNS Resolver. The problem here is that there is no way the Firewall can tell which host needs to be scrubbed by the SecOps team.
Sinkholing can solve this problem. As a DNS Reply for a known malicious request passes through FTD, it can replace the server address with one of the administrator’s choosing. This simply needs to be an address that will cause the clients to send the traffic through the Firewall. This does two things. Similar to the other DNS actions, it drastically decreases the likelihood that the host pc will connect to the malicious host on the Internet. It also allows FTD to see the subsequent connection attempts to the modified address found in the DNS Reply.
In my testing, I’m not going to build an internal resolver. However, the DNS Request and Reply relationship between my client and Google’s DNS server will look the same to FTD.
The first part of the requirement is to configure a Sinkhole IP address. This address, from the client’s perspective, should be one that will be routed through the Firepower instance. The IP address could exist and accept connection (which could be independently tracked) or a nonexistent IP address that we expect FTD to block packets for. Once again, the goal is to get the follow-on connections to Firepower for visibility.
The Sinkhole IP Address is configured in Object -> Object Management -> Sinkhole.
Notice you must configure an IPv4 and IPv6 address and select whether to Block and Log or Log Only. There is also the opportunity to tell Firepower what types of connections to associate with these Sinkhole addresses.
Before leaving the Object Management area, it is also helpful to add a DNS List for testing. In this case, I am creating a file with two lines and uploading it as DNS-TEST. When we go from testing to actual day to day operations, we may instead use the Talos supplied feeds.
#DNS-TEST.txt test.packetu.com test1.packetu.com
Now we will can pull these components together in a DNS Policy Rule. These can be found in Policies -> Access-Control ->DNS.
In my case, I created a rule called DNS-TEST with an Action of “Sinkhole” and chose the Sinkhole Object I created. I also selected DNS-TEST as the match criteria for my testing. It is also possible to select any of the pre-existing Feeds. I then used the drag and drop feature to correctly position the rule I created.
It is also necessary to make sure the DNS policy is attached to the desired access control policy. These are found in Policy -> Access Control. Once the proper policy is opened, the DNS Policy can be selected from the Security Intelligence tab. Then, as with most things Firepower, the policy needs to be deployed to the managed devices.
Now we can attempt to reach test.packetu.com and see what happens.
PAULSTE-M-V04T:~ paulste$ ping test.packetu.com PING test.packetu.com (184.108.40.206): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 ^C --- test.packetu.com ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss
It this point, you should be able to see associated events and follow-on connections logged as Security Intelligence Events and Connection Events. The host should also be tagged with Indicators Of Compromised based on the Type of Sinkhole that was selected when the object was created.
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.