Cisco FTD DNS Security Intelligence is used to quickly block connections to or from domain names with a bad reputation based on a database created by Cisco Talos security group. You have the option to drop DNS queries for malicious domain names or return a specific IP address called DNS sinkhole to redirect users to that sinkhole IP address and log the users accessing malicious domains.
Firepower DNS security intelligence and DNS Sinkhole
In the last video we have blocked IP addresses and URLs with bad reputation through security intelligence using cisco feed or custom list.
It is also possible to blovk domain names with inspecting DNS queries. The process is the same as for IP address and URL. We use Cisco Talos security groups database or custom list created by us or third party companies.
with IP address and URL, the only option is to block them if they are malicious. However, when querying DNS, we also have the option of returning an invalid IP address in the DNS response which is called sinkhole.
DNS Sinkhole Operation
Why do we need to return a not-valid IP address to the DNS query? Because DNS query usually comes from DNS servers and not directly from end users. If a not-valid sinkhole IP address is returned, then end user attempts to access the sinkhole IP address. Then we have the option to log the final user who is trying to access the domain name.
For example, the client sends a DNS query to the internal DNS server for the domain, example.com . The query is forwarded from the internal DNS server to the external DNS server. FTD sees the DNS query with the source of the DNS server and not with the client itself. FTD blocks the forwarding of the DNS query to the outside and sends a DNS reply with sinkhole IP address. Then the user tries to access the sinkhole IP address.
In the FTD, we block access to the sinkhole IP address and log the IP addresses trying to access the sinkhole IP address. Therefore, the end users trying to access domain names with a bad reputation are logged.
Configuring DNS Security Intelligence
In “Objects -> Object Management -> Security Intelligence -> DNS Lists and Feeds”, there is cisco DNS feed which is regularly updated by cisco Talos security group.
Global black list is empty by default and can be updated through connection events like what we have done for IP address and URL.
You need to select DNS query connection event with specific domain and then right click on the domain name to have the option to blacklist the domain name.
It is also possible to add custom DNS feeds and lists. In the DNS custom feed, you provide a URL where FTD pulls the updated list periodically. You can choose the update frequency.
In custom DNS list, we add and update the list of domains manually. In our list there are three domains that we will block any DNS query for these domains. “time.ir”, “google.com” and “cisco.com”.
Configure DNS Policy to enbale DNS Security Intelligence
The custom list or feed must be added in the DNS policy to be enabled.
In “Policies -> DNS”, there is “Default DNS Policy”. we can edit default DNS policy or we can add a new DNS policy.
There are by default two rules in default DNS policy. for domains in Global-Block-List-for-DNS, the action is “Domain Not Found”. and for domain in Global-Not-Block-List-for-DNS, the default action is to “Do Not Block” DNS query. In a few minutes I will talk about various action options in DNS policy.
I will add a new rule for my custom DNS list. There are five actions in DNS policy to be used for each rule.
Do Not Block: Allows DNS query to be forwarded
Monitor: log DNS query. DNS query is evaluated against other rules to determine whether it would permit or deny.
Domain Not Found: Returns a non-existent domain name (NXDOMAIN) response to the DNS query
Drop: Drops the DNS query. from user perspective, DNS query will be time out.
Sinkhole: DNS returns a sinkhole IP address in response to the query. The sinkhole can log, or log and block the user accessing sinkhole IP address.
"Do Not Block" action in DNS Policy
Let’s check each action to check the result. For the first practice I will choose the action, “Do Not Block.”
If you have added a new DNS policy and did not use “Default DNS Policy”, do not forget to enable it in security intelligence. By default, “Default DNS Policy” is enabled in security intelligence.
Be careful not to forget to deploy any security intelligence changes, including DNS policy, to the FTD appliance.
Now let’s check the DNS query from a computer behind FTD for the domain cisco.com which is in our custom DNS list. As you can see, we receive DNS reply without any problem.
DNS reply can also be checked in connection events. we filter connection events to show only DNS query to the domain “cisco.com”.
"Drop" action in DNS Policy
For the second practice I will choose the action, “Drop”.
Now let’s check again the DNS query from a computer behind FTD for the domain cisco.com which is in our custom DNS list. As you can see, we receive timeout DNS reply since DNS query is dropped and no reply is received.
DNS query action can also be checked in connection events. as you can see DNS query to domain cisco.com is blocked and it is matched with domain_list custom list.
"Domain Not Found" Action in DNS Policy
In the third scenario, we change the action from Drop to “Domain Not Found”.
We check again the DNS query from a computer behind FTD for the domain cisco.com. as we expect, the “Non-existent domain” is received in the DNS response.
We check it also in connection events. as you can see DNS query to domain cisco.com is blocked and the action “Domain Not Found” is returned.
Cofigure DNS Sinkhole in Cisco FTD
The last scenario that we are going to implement is to sinkhole DNS query and return a not-valid IP address.
As we have explained earlier, DNS query is normally forwarded with DNS server and not the client itself. With returning sinkhole IP address in DNS reply, the client itself try to access the sinkhole IP address, then we have the option to block and log the final user who is trying to access malicious domains.
To implement sinkhole action in DNS policy, first we have to configure sinkhole IP address in “Objects -> Object Management -> Sinkhole”.
For sinkhole object, first we have to give a sinkhole IPv4 and IPv6 address. This IP address will be returned to DNS query when the query is for the malicious domain in list.
Then we have to choose the option “log the access to sinkhole IP address” or both “block and log the access to sinkhole IP address”.
you have the option to configure multiple sinkhole IP address for different group of malicious domain lists. So we can identify which users are accessing which type of malicious domain list.
Then sinkhole object must be configured in DNS policy.
Now we can check sending DNS query for domain cisco.com to see the result of DNS reply.
As we expect the IP address of sinkhole IP Address 7.8.9.10 is returned.
We can check also connection event to see what is displayed in connection event. as you can see, sinkhole is shown also in connection event.
When we try to access sinkhole IP address, client IP address who is accessing malicious domains will be logged. It will not be blocked since in sinkhole object, I have selected log action and not “block and log” action
Why we don’t see the DNS query in the table view of Security intelligence events?