Malicious DNS Traffic: Detection is Good, Proactivity is Better

It looks that our beloved DNS protocol is again the center of interest for some security $VENDORS. For a while, I see more and more the expression “DNS Firewall” used in papers or presentations. It’s not a new buzz… The DNS protocol is well-known to be a excellent vector of infection and/or data exfiltration. But what is a “DNS firewall” or “Strong DNS Resolver“?

It’s a fact: without DNS, no Internet! We have to life with DNS servers infrastructures. Most organizations have internal DNS resolvers. Their primary goal is to translate all FQDN (“Fully Qualified Domain Names“) into IP addresses (v4 or v6). This is a mandatory network service and attackers know this! If the registration of domain names was very expensive a few years ago, today it became very cheap (when not free!). Malware authors or attackers register thousands of domain name, usually based on random strings. Malicious DNS activity may occur at different steps to infect a computer. First, a user can be redirected to a malicious website which will send a payload to the browser (or any other application). Another step is, once the infection completed, the communication with a C&C to request actions to be performed or to exfiltrate data. The DNS protocol can also be used to transport other data. A DNS firewall will have a good knowledge of all those malicious domains and prevent users/applications to access them. Two actions are performed by those systems: To redirect the traffic to a black-hole (usually the loopback or 127.0.0.1) and to generate an alert to warn the security teams that a device tried to reach a blacklisted domain.

Do you know that this feature can be easily implemented? Here is a quick overview of my setup. First step, the detection! It is indeed critical to be notified in case of connectivity attempts with a malicious domain. To achieve this, I’m using OSSEC to collect bind logs and search for interesting domains. This can be achieved with the “CDB list” feature implemented into OSSEC. CDB is a convenient way to index constant databases and perform lookups on them. The classic types of information that can be found in CDB lists are: users, IP addresses, domains, ports, etc. By indexing a list of bad domains, it’s possible to detect suspicious DNS traffic with a simple rule like this one:

<rule id="100000" level="10">
  <list field="url">lists/bad-domains.txt</list> <description>DNS query for malicious domain!</description> </rule>

The “URL” field is extracted from the bind logs using the existing OSSEC decoder. Great! But when this rule will be fired, it will already be too late and the risk to have the user infected is still important. This is good for detection but what about adding some proactivity? What about configuring your local resolver to prevent it to resolve malicious domains? This can be also achieved using a simple configuration change. Include in your “named.conf” a list of malicious domains:

include "/etc/named/bad-domains.zones";

This file will have the following format:

zone domain1.com {
  type master; file "/etc/named/blackhole.hosts"; };
zone domain2.com {
  type master; file "/etc/named/blackhole.hosts"; };
zone domain3.com {
  type master; file "/etc/named/blackhole.hosts"; };
...
zone domainX.com {
  type master; file "/etc/named/blackhole.hosts"; };

Create a blackhole.hosts file that will look like a basic zone file:

$TTL 3600
@ IN SOA ns.rootshell.be hostmaster.rootshell.be. (
                         2013012801 ; Serial
                         28800      ; Refresh 8 hours
                         7200       ; Retry 2 hours
                         604800     ; Expire 7 days
                         3600 )     ; Minimum 24 hours
  IN NS ns.rootshell.be.
* IN A 127.0.0.1

The queries will be logged and fire the OSSEC rule described above but in parallel, all listed domains will resolve to the loopback IP address! This could be very efficient but the next question is: how to build the (good) list of malicious domains? Don’t panic! Internet is full of interesting resources. In our case, the site  http://www.malwaredomains.com/ will help us. They provide lists of malicious domain names and update them frequently. To implement the rules described here, two files will be required:

• http://mirror1.malwaredomains.com/files/spywaredomains.zones
• http://mirror1.malwaredomains.com/files/justdomains

Honestly, I did not invent anything. This technique is known for a while but it’s always good to remember it. The automatic update of those lists can be scheduled via a crontab (like once a week) and some system commands. There is a RSS feed available with all updates of above files. Finally, don’t forget to add a layer of reporting on top of this (example: by injecting all logs into a Splunk instance) and you will greatly reduce the surface attack opened by the DNS protocol… without spending huge amounts of money with $VENDORS solutions!

You don’t have (or you don’t want to manage) a local resolver? There are of course alternatives like opendns.com. They provide the same kind of protection but with a big limitation: you don’t control the list of blacklisted domains!