Feed

BH DNS White Paper

Posted on November 25th, 2007 in by dglosser

BlackHole DNS for Malware and Spyware

by David Glosser

.
Summary
Introduction
Internal DNS
Configuring your DNS server: Bind format
Configuring your DNS server: Microsoft’s DNS
Testing the New Zone
Adding Additional Zones:
Download the Malware-Blocking Zone File
Secondary DNS Servers
Caveats/Warnings
Resources

Update

Please view this paper for how to use a free PowerShell script to manage blackhole DNS domains using Microsoft’s Windows Server DNS

Summary

A list of domains that are known to be used to propagate spyware and malware are listed in Bind and Windows zone files. The domains are loaded onto an internal DNS server. When a computer requests a URL or file from one of these domains, a fake reply is sent, thus preventing many malware installs from occurring.


Introduction

We all have had problems with machines being overrun by malware: taking 20 minutes to startup, constant popups, hijacking of the home and search pages, bookmarks being added, etc.

Malware can even turn a machine into a “zombie”, and be an unwilling participant spam sending or relaying, address harvesting, or DDOS attacks against other computers.

One of the more popular techniques for fighting malware among home users is through the use of a host file for DNS redirection.

A host can be used to maps hostnames associated with malware to a different IP address (such as a loopback address, 127.0.0.1). This will prevent connections to those malicious sites from ever taking place. (There is an irony here, as some of the more “evil” malware hijacks your host file to prevent their removal or to redirect search queries).

Unfortunately, there are several problems with using host files, especially in a corporate environment:

  • There needs to be an exact entry in the hosts file for each malware host/domain combination.
    Even within the same domain, there must separate host entry.
    For example, there must be individual entries
    for www1.malwaresite.com, www2.malwaresite.com, www3.malwaresite.com,
    www4.malwaresite.com,
    etc. A host not listed (such as www5.malwaresite.com) will continue to
    be resolved to the actual malware-associated site.
    (This is a major problem with pattern-matching spam filters, and will become
    even more of a problem as “wildcard dns” continues to increase in popularity.). Major malware
    players may have dozens of hosts per domain. This causes the host file to become quite
    large.
  • While a small hosts file will speed up browsing (since anything listed in the file
    are not downloaded to the desktop, some
    issues have
    been reported with very large host files.
  • Updating multiple host files on a corporate LAN can quickly become unwieldly.
    Because there is no centralized administration point,
    a single change must be pushed to every client. (If the host file is copied via a login script,
    the network admin would have to ensure that user logs into the domain on a daily basis
    to receive the latest file). Also, copying host files via a login script may be problematic if the
    user does not have permissions to overwrite their local host file.
  • Many of the host files available on the internet include adservers, which may
    not be appropriate to block in corporate
    environments or for users who wish to see the ads.
  • Some of the “anti-adware” host files and utilities are not free for corporate environments.

As an alternative to host files, there are several desktop-based DNS software packages
available which are designed for use on a single desktop. These packages
were originally designed as a substitute for a large host file in order to speed up browsing by having
a local name server available to cache domain queries such as
DNSKong. These programs
can also be used to block domains associated with malware. However, they only work on the local
machine or perhaps a home network.

Internal DNS

Many corporations deploy an internal DNS server for use on their Local Area Network, usually to
provide name resolution for internal hosts
or to speed up browsing by locally caching DNS queries .

Such a server could also be configured as a “primary” or “master”
resolver for domains associated with malware and spyware. The DNS server,
beleiving it is an “authority” for the
that zone, will answer the query instead of querying
another dns server for the answer.
The desktop receiving the answer doesn’t know that the ip
address received is not “valid”.
The resolved address could be 1) a loopback address or 0.0.0.0;
2) a local internal web server configured to “answer” all image requests mapped to a single pixel
image file, and all text pages mapped to a warning message page; or 3) a machine with a personal firewall.
The last two configurations have the added advantage of
generating log files for inspection as well as enable a snort or other IDS system to continue to
see traffic.
An internal DNS server configured to answer for malware domains has several advantages over a host file,
including:

  • No slowdown due to large number of domains and host entries.
  • Centralized control and administration point for configuration modifications.
    Any additions or modifications are almost immediately available to all users.
  • No need to continue to add individual host entries when a malware site modifies
    the hostname portion of the domain. If the domain is configured for “Wildcard DNS”, then
    it will answer for any and all host requests with a single domain.
    Host file entries for www1.malwaresite.com, www2.malwaresite.com, www3.malwaresite.com,
    www4.malwaresite.com
    are now replaced by a single domain entry malwaresite.com).
    This eliminates having to list multiple hosts within the same domain in a local hosts file.
  • OS independent: the local DNS server will work for all clients (XP, W2K, 98, Linux, *nix, MacOS, etc. ).


Configuring your DNS server: Bind format

The following assumes you already have a familiarity with DNS and bind.
A brief background and introduction to bind can be found at the end of this document..

A standard format for DNS entries is called “Bind Format”. In most instances of bind, there
are two files of interest: the
master config file (called named.conf on most machines) and the “zone” file associated with each
administered domain (usually called something like “domainname.zone.dns“).

There is usually one zone file per domain, but
for the purposes of blocking malware,
a single zone file can be associated with multiple malware-associated domains.

While you could add domains directly into the named.conf, an include statement
lets you place all of the blocked domains in a single file, which will make the file
portable and easier to replace. It also keeps the named.conf file safe from accidental corruption.

Debian and other Linux distros already have a file called “named.conf.local” so we’ll use that as an
example. Make sure the file is located in the same working directory as the named.conf file or add
the full path to the file (such as /etc/namedb/named.conf.local or /etc/bind/named.conf.local).

For example, the following entries in the named.conf.local will add the domains “coolwebsearch.com” and
“gator.com” to the local DNS server (The full list can be downloaded HERE):

    named.conf.local file :

       zone "coolwebsearch.com" { type master; file  "/etc/namedb/blockeddomain.hosts"; };
    
       zone "gator.com" { type master;  file "/etc/namedb/blockeddomain.hosts"; };
      ; BIND db file for ad servers - point all addresses to localhost
      ;
      ; Originally for use with the list of ad server hostnames at:
      ;
      ;       http://pgl.yoyo.org/adservers/
      ;
      ;  - pgl@yoyo.org
    
      $TTL    86400   ; one day
    
      @       IN      SOA     ns0.example.net.
      hostmaster.example.net. (
                              2004061000       ; serial number YYMMDDNN
                              28800   ; refresh  8 hours
                              7200    ; retry    2 hours
                              864000  ; expire  10 days
                              86400 ) ; min ttl  1 day
                      NS      ns0.example.net.
                      NS      ns1.example.net.
    
                      A       127.0.0.1
    
      *               IN      A       127.0.0.1

The * in the line * IN A 127.0.0.1
is a wildcard, which means
that 127.0.0.1 will be returned for any hostname within that domain:
www1.coolwebsearch.com, www2.coolwebsearch.com,
ihatemalware.coolwebsearch.com, anythinghere.coolwebsearch.com will all
be resolved to 127.0.0.1.

This single file will be used for all malware-associated domains. Most of the actual content of this file is not important,
as it is not serving up information for a “production” domain. (You need to be much more careful with an
actual domain!) You should probably change the “ns0.example.net.” and “ns1.example.net” to your own
information.
You may need to change the 127.0.0.1 to 0.0.0.0 or to an internal server, as discussed above.

Instead of querying an upstream DNS server for
the answer, your local DNS server believes it is a “master” for the “coolwebsearch.com” domain.
It will therefore “answer” any queries for a host within that domain with 127.0.0.1 or whatever IP
address you placed in the zone file.

In “production” domains, the values for TTL, refresh, retry, etc. may need to be
tweaked for your configuration. In addition, when a change is made (such as adding or modifying a host),
the serial number needs to be incremented. However, since this “dummy” file should never change,
the serial number is not important.

Several LiveCD distributions (such as Knoppix-STD a
and NST) contain the named program (which is
used to start up the BIND daemon)
and can be used for testing.
More information on testing the new zones is located later in this paper.


Configuring your DNS server: Microsoft’s DNS

If you are running Microsoft’s DNS, please consider
switching to a DNS server which recognizes “bind” formatted files.
There are several highly-rated DNS server packages which run on a
Windows Server. JH Software also has a small utility
which was written to create a standard boot file from a NT4 DNS server.
I don’t know if it will work on a W2K DNS server. (I’ve never used
their software but it consistentenly has received good reviews). You
can always run Microsoft’s DNS server as a secondary or caching name
server.

If you insist on keeping Microsoft’s DNS server, I believe I have found the least painful way to
add many zones at once. (Another way, which involves importing entries into the registry,
is described here.

By default, Microsoft’s W2K DNS uses the registry to load up the boot
information that instructs the DNS server on which zones to load at
startup (as well as other parameters). Adding additional domains must
be done via the GUI, which makes it cumbersome if many domains are to
be added. In addition, a “wildcard DNS” entry cannot be added via the
DNS GUI.

There is a simple workaround,
which is to
configure DNS to use a text file instead of the registry to load the
zones at startup. This has the added advantage of making Microsoft DNS
more compatible with Bind format, as well as making it easier to
migrate DNS to other machines. The boot file’s default name in Windows
2000 is boot (without any extension), and is located in the
%SystemRoot%\System32\DNS
folder (usually c:\windows\system32\DNS, it may be different in Win2003
Server or for sites running Active Directory. If this is the case,
please let us know so we can update this document.)

After some experimentation, the easiest way I have found to create a blackhole
zone file which can be used for multiple zones is: 1) create a single
blackhole zone via the MS DNS console; 2) reconfigure the MS DNS server to load it’s
zones via a boot file (instead of the registry), and 3) add additional malware zones
to the boot file.

1. Create a single blackhole zone file
From within the MS DNS
Console, select “Forward Lookup Zones” and select
action –> New Zone. Create a “Standard Primary” zone, and call the
zone something like “blockeddomains.com” and press Next twice. This
will create a file called “blockeddomains.com.dns”. Double-click on the
new entry, which should be
listed under “Forward Lookup Zones”. Add a single host called “www” to
the file with an IP address of 127.0.0.1 (or, as discussed earlier,
0.0.0.0 or an internal server). Then under “Actions”, select “Update
Server Data File.”

The Microsoft blockeddomains.com.dns zone file will look something like this:

    blockeddomains.com.dns file:

    ;
    ;  Database file blockeddomains.com.dns for blockeddomains.com zone.
    ;      Zone version:  4
    ;
    
    @                       IN  SOA nameserver.blockeddomains.com.  admin.blockeddomains.com. (
                            	4            ; serial number
                            	900          ; refresh
                            	600          ; retry
                            	86400        ; expire
                            	3600       ) ; minimum TTL
    
    ;
    ;  Zone NS records
    ;
    
    @                       NS	nameserver.blockeddomains.com.
    
    ;
    ;  Zone records
    ;
    
    www                     A	127.0.0.1

The lines referring to the domain (blockeddomains.com) and
nameserver (nameserver.blockeddomains.com) will be specific to your
domain.

Open the file in Notepad or another text editor, and add these lines to the bottom
of the file:

    Additional Lines:

    ; wildcard dns
    *                    	A	127.0.0.1
    ;

If you are using Notepad, then please remember to save files
without the “.txt” extension. The file should now be configured for
“Wildcard DNS”.

2. Configure the DNS server to load it’s zones via the boot file instead of
the registry

To create a boot file, all you need to do is reconfigure the MS DNS
server to load it’s zones
from the boot file instead of the registry. That will automagically
create the boot file for all of the existing zones. (This is roughly
equivalent to the named.conf file.)
From the MS DNS console, right-click the local DNS server, select
“Properties”, select the “Advanced” tab, and change the “Load zone data
on startup:” setting to “From File”.
This will create (or update) the existing sample boot file.

According to this source,
If you are using Active Directory, you may need to check the properties
of each zone and change zones of type “Active Directory-integrated” to
“Standard…”, and then repeat above.

You can still manage zones from Microsoft’s DNS Manager even when you start from the boot file, and
the registry is still used for parameters which cannot be specified in the boot file.
The “boot” file should look something like this:

    Microsoft "boot" file:

    ; Boot file generated from registry at 2/20/2000 11:36:22 AM
    PRIMARY    blockeddomains.com	blockeddomains.com.dns

There will be lines in this file referring to your specific domain(s).

As you can see, the syntax in the Microsoft boot file is not 100% compatible with the bind named.conf file :(

In the file above, the line PRIMARY blockeddomains.com blockeddomains.com.dns refers to the new domain which the DNS server will be answer quesries for as a “master” or “primary”.

3. Add additional malware zones to the boot file.

Since the zones are loaded via the boot file, you can now add additional “Black-Hole” malware zones
to that file.

Open the file in Notepad or another text editor, and add these lines to the bottom
of the file:

    Additional Lines:

    PRIMARY	   coolwebsearch.com   blockeddomains.com.dns
    PRIMARY    gator.com	blockeddomains.com.dns

If you are using Notepad, then please remember to save files
without the “.txt” extension. The file should now be configured to be a
“master” for the “coolwebsearch.com” and “gator.com” domains. Any
queries for a host in that domain will be “answered” by your local DNS
server as “127.0.0.1″ or whatever IP address you assigned.

Blockeddomains.zone.dns is the file containing information about the
hosts in the “coolwebsearch.com” and “gator.com” domains. Of course, in
our case, the information in this file will not contain the information
placed there by the owners
of the domains. Rather, it contains the information we placed there.

Instead of querying an upstream DNS server for
the answer, your local DNS server believes it is the “master” and
“authoritative” for the “coolwebsearch.com” and “gator.com” domains. It
will therefore “answer” any queries for a host within that domain with
127.0.0.1 or whatever IP address you placed in the zone file and will
not query to see if it can find a record on an upstream DNS server with
better credentials.

Testing the new zone

Start (or stop/restart the DNS server). Once DNS is running, change a desktop’s DNS settings to use this server.
If DNS is configured correctly, then, due to the wildcard entry (*) above,
any and all queries to the
“coolwebsearch.com” domain (such as www1.coolwebsearch.com, xyz.coolwebsearch.com,
etc) will resolve back to 127.0.0.1 or watever you changed it to.
You can test this with tools such as “ping”, “dig”, or “nslookup” (from
the command line):

    Testing the new zone:

       ping www.coolwebsearch.com
       ping anyrandomstring.coolwebsearch.com
       ping hsdsdshgdhsgd.coolwebsearch.com
       nslookup www.coolwebsearch.com
       nslookup ihatebrowserhijackers.coolwebsearch.com

All of the above should reply with 127.0.0.1, or
whatever address you placed in the blockeddomains.zone.dns file You can
also attempt to reach the sites through a web browser (with sufficient
precautions, such as making sure the sites you are testing are in your
restricted zone, or use firefox with the all scripting disabled via the
Web Developer Extension.)


Adding Additional “Malware” zones

Once you have added a dozen or so test zones yourself and feel comfortable
with the workings of DNS,
you may wish to load up a file containing a list of malware-associated domains.

Unfortunately, there seem to be very few “black-hole” or “null” zone files available for download, with the exception
of Peter Lowe’s
site.(You may have to modify the file to match the file name of your
black-hole zone file, as well as convert the file to Microsoft’s
format.)

Another way to create a zone file is to convert one of the more popular host files.
One of the better programs to convert host files to BIND format is also located on
Peter Lowe’s site. Sites with host files are listed at the end of this paper.

However, these host files include the domain names of adservers, such as doubleclick, which may
not be appropriate to block in corporate environments or for users who wish to see the ads. Also, with the
recent exception of MVPS, these
files are not designed with the prevention of malware in mind.

Bleeding Snort has made available a “black hole” DNS zone files
in both “Bind” format and “Microsoft” format. We’ve made every attempt
to only include domains associated with malware.

The files containing these malware-associated domains can be downloaded HERE.


Secondary DNS Servers

You will have to also modify your secondary DNS
servers to let them know about the new zones. It is probably easiest to
copy the files over from the primary, and let your secondaries continue
to be a secondary DNS server for your production “valid” zones, and let
them believe they are a master for the “blocked” zones.

You should also test the secondary by pointing a
test desktop to it and performing “pings”, “nslookups”, etc from that
test box.

Caveats/Warnings

  • Using a host file or DNS server does not prevent malware or spyware which uses an IP address from connecting.
    Blocking by IP address is a better job for firewalls and routers, which usually do not
    block by domain name. Of course, you may have to constantly update the the ip addresses or
    block entire netblocks.
  • Try this on a test server first!
  • Start slow; point one desktop to this server at first!
  • If you are doing this on an existing DNS server, then back up all files first!
  • It may be best to point users to a secondary server and make all
    changes to the primary (to avoid loss of services when you stop and restart the server).
  • ONLY DO THIS ON INTERNAL SERVER. You shouldn’t be doing this on a public dns
    server, unless perhaps you are going to offer it as a service as an *option*
    or *added value* for users to point to.
  • If you are using a proxy server, then be careful about using 127.0.0.1, which may overload the proxy.


Resources

Information on DNS:

Host files, Tutorials and Utilities:


Comments are closed.