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:
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:
First one is dynamic list maintained by Cisco. We can only choose how often we want this list to be downloaded:
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:
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:
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:
Once we are done, a third rule within the policy appears:
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:
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:
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:
If we want this name to be white listed or black listed, we right click it and select appropriate action:
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:
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.