One of the most underutilized features of Firepower is the DNS Sinkhole function. There are many use cases, and this blog post will focus on the most common.
Many Firepower customers utilize DNS Blacklists, which are virtually mandatory if you want to have Internet Security. A blacklist simply says, “If a naughty DNS query is seen, drop it”. Again, this is great.
However, there is a downside. Who sent the DNS Query? This is where we spot the trouble. In many organizations, the DNS Servers are internal and are often not protected by Firepower. In this case, the blacklisting function of Firepower will only catch the query when the internal server sends it to Internet Root Servers. In other words, all blacklisted DNS Queries will show up in the logs as coming from your internal DNS Servers, not the end-users.
The use-case that adds the most value to the feature is Malware. Let’s say you have an infected PC trying to reach examplemalwaredomain.com. Without the sinkhole, the only thing you would know for sure is someone in your organization is infected. With the sinkhole, you will know the exact user and endpoint with the Malware.
DNS Sinkhole Lab
We have two users, Mary and Bob. In both cases, the endpoints are simple Windows workstations. The Switch in the middle is connected to an FTD, and various servers (FMC, Active Directory, DNS, and ISE). The FTD connects to the Internet.
The important part to consider is when Mary or Bob query DNS, they will hit SW1 and go directly to the DNS Server within the “Servers Cloud”. The query will never traverse the Firewall and will therefore not be logged. I will demonstrate how it works without the sinkhole, then we will add it to highlight the difference.
Firepower is integrated with Cisco ISE for Identity and both Mary and Bob are authenticated via 802.1x. Both users have the listed IPs and are configured to use internal DNS.
Firepower DNS Policy
Now that the basics are out of the way, we can build out a simple DNS Policy:
Policies ---> Access Control ---> DNS
By default, there are two policies “Default DNS Policy” and “Default Umbrella Policy”. We will create a new one:
Click Add DNS Policy
Name: This can be whatever you choose. I’m going to use “Lab-DNS”
Once you save the new policy, you should see two default rules, which are basically a whitelist and a blacklist.
Click Add DNS Rule
Name: Block-Bad-DNS
Enabled: Checked
Action: Drop
DNS: Add all DNS Categories
Click Add, then Save
Now we have a new DNS Policy, but it isn’t doing anything until we apply it and deploy our changes.
Policies ---> Access Control ---> Edit ---> Security Intelligence
Click the drop down under DNS Policy and choose the newly created DNS Policy:
Save and Deploy
Not too bad at all, you now have a fully functioning and automated DNS Blacklist. This single policy alone will block an enormous number of bad websites. Let’s see it in action!
Test DNS Policy
For the test, we will use a known Malware test URL provided by Cisco Umbrella. On a PC, we’ll try to get to: examplemalwaredomain.com.
So far so good, let’s see what it looks like in the Firepower logs:
The good news is the rule blocked the actual DNS query! The bad news is the traffic was initiated by the internal DNS Server. This is the problem a DNS Sinkhole fixes. If the sign of an infected workstation, is it is trying to communicate with examplemalwaredomain.com, we simply wouldn’t know which workstation had the problem.
DNS Sinkhole
The main function of a DNS Sinkhole is to return a dummy IP Address to a query. So far in our lab, Firepower will simply drop any DNS query that is on the automated blacklist. The DNS Sinkhole function goes a step further and instead of dropping the request, it intercepts it and returns the “fake” IP.
It works like this:
Step 1: The workstation queries the internal DNS Server for the IP of examplemalwaredomain.com.
Step 2: The internal DNS Server does not know the IP, so it queries its upstream DNS or Root DNS.
Step 3: Firepower knows the domain being requested is blacklisted and intercepts the query. This is where the magic happens. Instead of dropping the request, Firepower responds to the internal DNS Server with a dummy IP Address.
Step 4: The internal DNS Server receives the dummy IP Address and passes it on to the original requester.
Step 5: The workstation now “knows” how to get to examplemalwaredomain.com and begins the connection.
Step 6: Firepower sees the outgoing connection, drops it, but also logs the detail. Now we know the IP, workstation, and user that may be infected.
Sinkhole Configuration
Navigate to Objects ---> Object Management ---> Sinkhole ---> Add Sinkhole
Name: DNS-Sinkhole
IPv4 Policy: 1.1.1.1 (This is the fake IP; you can really use any IP you like as long as it routes through the firewall)
IPv6 Policy: ::2
Block and Log Connections to Sinkhole: Checked
Type: Malware
Save the new Sinkhole Policy
The next step is to attach it to our DNS Policy.
Policies ---> Access Control ---> DNS ---> Lab-DNS ---> Edit ---> Block-Bad-DNS ---> Edit
Simply change the Action from Drop to Sinkhole and populate the Sinkhole field with the policy we just created.
Press OK, Save, and Deploy
Sinkhole Testing
Let’s run the same test again, by going to the malware test site.
Now we can see who tried to get there!
For the lab, we didn’t create a rule to block the traffic to 1.1.1.1, but in production you certainly should or use a destination IP you own.
That’s it. Using a DNS Sinkhole is a quick and easy method of gaining visibility into every DNS request sent on your network. The feature also allows you to generate reports based on DNS requests alone. For example, your report can be something like – Show me every user that tried to reach malware.com in the last 30 days.
In Conclusion: The Power of Firepower DNS Sinkhole
By leveraging Firepower DNS Sinkhole, you gain a powerful tool to proactively combat malicious DNS requests. This solution not only helps prevent malware infection attempts but also provides valuable network visibility. You can easily generate reports to identify users who attempted to access malicious domains, allowing you to take further action and improve overall network security posture.
Ready to take the next step?
Contact one of CDA's security specialists to discuss how Firepower DNS Sinkhole can be integrated into your existing security framework.