Verifying DNS Lists – FMC

We are back with another post about Cisco’s Firepower Management Center and this time we are working with the DNS list which if you have a protect license you can have your Firepower modules or your FTD (Firepower Threat Defense) devices look at DNS requests and deny requests if they are malicious. These have to be applied on your access control policy to be able to use it and in this post we are going verify some of the domain names that are in this lists.

So this post is already assuming that you have an Access Control Policy deployed on a Firepower Module (ASA) or a FTD. We also are assuming that you have a DNS policy applied to the FM/FTD. These lists get downloaded about every two hours from Cisco and are updated regularly, best to keep it that way. 🙂

However like everything there is always someone, some system, some program that fails to connect and more often than not it’s usually this critical process that worked yesterday but doesn’t today, so how do we check if we are hitting this?

There are two ways to check this we can look at the connection events (if you are logging which by default is yes) it will show DNS the events and depending on your policy you’ll see the action taken. In this example we selected to use Domain Not Found for the action. In this example we can see Domain Not Found and we can also see the DNS category its hitting which is DNS Dga.

(Note: I have edited this screenshot to show instead of the malicious domain)

We can verify the domain is in this list DNS Dga by connecting to the FMC via SSH and browse to the actual list which is located at /var/sf/sidns_download. When you browse to this location you’ll see something like this:

admin@FMC:/var/sf/sidns_download$ ls
032ba433-c295-11e4-a919-d4ae5275b77b  Cisco_DNS_Intelligence_Feed
1b117672-7453-478c-be31-b72e89ca2dde  IPRVersion.dat
23f2a124-8278-4c03-8c9d-d28fe08b71ab  abdc925f-4f85-4504-90a7-c891979ad82a
2CCDA18E-DDFF-4F5C-AF9A-F00985219707  b1df3aa8-2841-4c88-8e64-bfaacec7111f
2b15cb6f-a3fc-4e0e-a342-ccc5e5804576  d7d996a6-6b92-4a56-8f10-e8506e432fb8
30f9e69c-d64c-479c-821d-0e4edab8348d  health
3e2af68e-5fc8-4b1c-b5bc-b4e7cab5abcd  health_status
5a0b6d6b-e2c3-436f-b4a1-48248b331d39  health_statuslock
5f8148f1-e5e4-427a-aa3b-ee1c2745d663  peers
60f4e2ab-d96c-44a0-bd38-830252b65259  rep_dd.yaml
6ba968f4-7a25-4793-a2c8-7cc77f1f1074  tmp

Each of these UIDs correspond to DNS feed. For example b1df3aa8-2841-4c88-8e64-bfaacec7111f is for DNS Dga category. You can easily figure out which UID is tied to which DNS category by using the more command, notice the top of the file.

(Note: I have replaced these domains with examples instead of the malicious domains)

admin@FMC:/var/sf/sidns_download$ more b1df3aa8-2841-4c88-8e64-bfaacec7111f
#Cisco DNS and URL intelligence feed: DNS Dga

We can see in this example that the domain we where trying to resolve is in this blacklist. Usually you’ll have to grep the file to find the domain as these lists can be big, to find a domain follow this command. I’m looking in the DNS Dga category.

admin@FMC:/var/sf/sidns_download$ more b1df3aa8-2841-4c88-8e64-bfaacec7111f |grep

This confirms it and we can can either whitelist it or drop the category and then redeploy polices. Unless you run into a bug, which I have ran into with whitelisting as it does not seem to work with some older firepower code, another upgrade is in the works. 🙄 In the meantime I dropped the DNS category,  I hope this information is helpful, feel free to comment below.

– Ryan

Leave a Reply...

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s