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 example.com 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 A27C6AAE-8E52-4174-A81A-47C59FECd3a5
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 example.info example.com example.net ... admin@FMC:/var/sf/sidns_download$
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 example.com example.com admin@FMC:/var/sf/sidns_download$
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
