Sourcefire Security Intelligence – DNS Policy

On July 2nd last year, we talked about Sourcefire Security Intelligence. Briefly, what it does is making use of huge collection of known bad IPs and blocking them before our users access them. In this collection we can find IPs categorized as Bots, Malware, Tor, C2, Phishing and so on. Why is this such a good idea? Well, if we know that some IP is malicious, we don’t bother wasting our time and resources in figuring out what is going on – we simply drop all communication to that IP. Cisco is maintaining this database of known bad IPs and we should make sure we update as often as possible.

Ok, that is a recap from the SI blog. Now we are going to talk about similar functionality, but on the DNS level. What does this mean? Well, Network Security Intelligence knows about bad IPs and block those. But DNS Security Intelligence does the same but instead of knowing about bad IPs and block them, it knows about bad names and block these names.

I believe that under the hood the Sourcefire is using OpenDNS database to make sure that bad domains get blocked. For those who don’t know, Cisco recently bought OpenDNS company for a boat load of money, in order to make a good product even better. OpenDNS is known for serving billions of DNS requests world wide and categorize these requests, similar to what network security intelligence does with IPs. This is a screen shot of the OpenDNS configuration web portal for home use:

15-Mar-16 10-00-26 AM

15-Mar-16 10-01-31 AM

We can see how easy it is to protect our home or small office from malicious content with just a few clicks and do that for free. Yes, for free! We need to register to OpenDNS and enlist our public IP address. If it is dynamic, there is a client that refreshes this entry when the address changes. The only thing left is making sure that our router serves OpenDNS DNS addresses to our clients, or clients are manually set to use those addresses. Now when a client resolves a name to an IP address, if the request contains malicious or otherwise forbidden name, the OpenDNS will return the IP address of one of its own web servers and we will be presented with a block page. How cute this is.

Guys from Cisco figured out that this concept could be applied to Sourcefire and corporate environments. How? Keep reading…

Now days, Security Intelligence or SI is divided into three categories:

  • Network Security Intelligence
  • DNS Security Intelligence
  • URL Security Intelligence

This time, we will discuss the DNS Security Intelligence. By default we have three objects and one policy pertaining to DNS SI. The objects are:

15-Mar-16 10-13-04 AM

  • Cisco-DNS-and-URL-Intelligence-Feed
  • Global-Blacklist-for-DNS
  • Global-Whitelist-for-DNS

First one is dynamic list maintained by Cisco. We can only choose how often we want this list to be downloaded:

15-Mar-16 10-17-50 AM

Second one is empty by default and is used for DNS names we don’t want ever to be resolved by our clients. This is something bad for us, but not for everyone else, and hence not in Cisco’s list. Or we are better in finding these names than Cisco 🙂

Third one is the list of names we don’t want to be blocked. Perhaps Cisco put something in dynamic list that we did not want to block.

The final piece of this puzzle is the DNS Policy. There is a default DNS policy called “Default DNS Policy” that is defined under “Policies->Access Control->DNS” and is ready to use. This policy by default uses only whitelist and blacklist and does not utilize any of dynamic bad categories:

15-Mar-16 10-29-06 AM

There are two rules in this policy. One rule with action Whitelist, which allows listed names to be resolved, and another rule with action “Domain Not Found“. If a DNS query is seen by Sourcefire with a name contained in this list, the Sourcefire will make the DNS response to be “Domain Not Found“. This action is exactly what we are going to setup for dynamic list. We click “Add DNS Rule“, give it a name and select the action:

15-Mar-16 10-34-17 AM

There are several options we can use for action:

  • Whitelist: allows matching traffic to pass and no log entry is generated
  • Monitor: don’t white/black list the traffic, just log an event
  • Drop: drop the traffic
  • Domain Not Found: return DNS not found response message to clients
  • Sinkole: return the IP address of a sinkole server we configured

Now we chose Zones, Networks, VLAN Tags as appropriate, and within the DNS tab, we select categories we want this action to apply to:

15-Mar-16 10-36-55 AM

Once we are done, a third rule within the policy appears:

15-Mar-16 10-38-00 AM

The rules have orders by which they get applied. So, white list is evaluated first, then black list and finally the dynamic feed.

Now we have to edit our Access Policy to make sure that the right DNS policy is applied. This is done under “Security Intelligence” tab:

15-Mar-16 10-41-59 AM

We could easily miss the option for logging DNS blocking events, that’s why I marked the log options icon.

After applying Access Control policy, we are ready to test this feature out. Under “Analysis->Connection->Security Intelligence Events” we can see that our policy is actually intercepting DNS requests and returning error messages to clients on behalf of DNS servers:

15-Mar-16 10-50-46 AM

If we click one specific event and scroll to the right, there should be a column called “DNS Query“, we can see what query looked like:

15-Mar-16 12-12-01 PM

If we want this name to be white listed or black listed, we right click it and select appropriate action:

15-Mar-16 12-14-18 PM

We don’t have to reapply any policies when adding something to the list, but we have to, when removing an entry.

If we now try to resolve the name, it will be successful and we can see that this name is actually white listed:

15-Mar-16 1-03-35 PM

To answer the question do we need DNS SI besides IP SI? Well, perhaps. It is possible that the IP address is not known at the time or is changing often, but the DNS name remains the same. So I guess this is another security tool under our security tool belt.

The URL Security Intelligence uses the same principle, but instead of working with IPs or DNS names, it uses URL links instead.

Thanks for reading.


This entry was posted in Cisco, FirePOWER, FireSight, IPS, Security, Sourcefire. Bookmark the permalink.

12 Responses to Sourcefire Security Intelligence – DNS Policy

  1. deadbeef says:

    thanks again for this great tutorial! just enabled this!… Please keep ’em coming!
    i’ve updated to 6.0.1 yesterday 🙂 but not the FTD image yet 🙂 ASA OS is going to retire soon. When they get all ASA OS features into FTD image,

    • Boyan Kurtev says:

      Keep in mind that migrating to FTD will force you switch to Smart Licensing ( according to documentation ) so before you do it make sure you have properly setup Smart Licensing.

      • deadbeef says:

        I won’t migrate for a long time… until they get all features from ASA OS to FTD.

  2. I always look forward to your posts and I always learn something (more like many things). This time around, I learned that the DNS feed list is not configured by default. Seems like a glaring omission at Cisco’s part but I suppose there would be some upset admins. Thanks again and I look forward to your next post!

  3. Meysam says:

    Hello & thanks for tutorial
    can you help me with this problem?
    I have ASA5525-X with SFR module and for testing sinkhole action,I made my own DNS list and add this to current lists (put test domain names on file and upload it)
    then on the DNS policy add new rule , select my list and add sinkhole action with my defined sinkhole ip address
    my problem is that domains on my list blocked but no ip returned to clients. I am expecting when the clients request domains on my list the ip of sinkhole returned to them.
    also on my default access control policy on Security Intelligence tab choose syslog as Action Alerts but on Action Alerts page indicates that alert is Not used by any policy and I receieve no syslog when client request blocked domain name.
    I manage the Firewall through ASDM rather than FMC

  4. Ahmed says:

    Can Anyone tell me some Blacklisted DNS names for testing this? you have grayed out the queries 😦

  5. Pingback: DNS Sinkhole with Sourcefire | popravak

  6. Asad says:

    I have Cisco ASA-5545-X with SFR module, DNS inspection is being done on SFR do i still need to enable DNS guard on Cisco ASA-5545-X

  7. evan says:

    anything ending in .pw Cisco don’t seem to approve of, for eg

  8. Excellent article. I will be experiencing some of these issues as

  9. Emmanuel says:

    Hi, good article.
    Do you know what “DNS Response” category blocks?
    I can’t find a description in the documentation.


  10. You’ve made ѕome go᧐d points there. I looked on the web for mοгe informɑtion ɑbout tһе issue and found mⲟst individuals will go along
    witһ your views οn thіs website.

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