Use DNS Whitelists To Stop Malware In Its Tracks

In a nutshell: configure your DNS servers to only resolve addresses for the top (most popular) 1 million domain names. Any request for a domain that is in the top 1 million names gets resolved. If the domain isn’t among the top 1 million, the request is blocked and the user is redirected to a help page (more about that later).

To explain how this idea protects your users, let me describe the problem we’re trying to solve:

Most kinds of malware infect PCs by one of three methods.

1. The user is enticed to open an email attachment (“Look at this funny video of Justin Bieber and adorable kittens, plus a delicious chocolate cookie recipe. And everybody’s naked!),
2. The user is enticed to click on a link and download an executable file (click here for free beer!),
3. Or the user’s browser is hijacked via a browser vulnerability at a legitimate, but compromised, site.

I know I’m making a little fun satirizing email and web scams here, but in all seriousness I want to point out that everyone, including you, can be fooled by a legitimate-looking but phony email or website. Even with the best security awareness training, at some point your users are going to click on those links or open those attachments. Eventually, your users PC will be compromised. Like death and taxes, it’s an eventual certainty.

When they do click on the link or open the attachment, here’s what (usually) happens. The malware executes and installs itself on the PC so that it always runs when the PC boots up. If it’s a spambot or DOSbot or any other sort of bot, the malware will connect to a control server somewhere on the Internet to receive instructions. If the malware’s job is stealing information, it uploads the stolen data to another site on the internet. In either case, the malware has to send a message to the control site letting it know that the malware is active.

Typically, the malware does a DNS query for the control site, and then makes a connection over port 80 (‘cuz port 80 is always open). Some malware actually uses the DNS query/response mechanism as the control channel. Under the guise of making DNS requests, the malware communicates to the control server using query/response messages.

Malware operators use DNS instead of hard-coded IP address because it is easy to change the IP addresses of their control servers. They can stand up a new server if their malware site gets shut down and simply change the DNS entry. Some malware uses multiple DNS names in case their DNS servers get shut down. Still others use what is called fast-flux DNS, where the IP address changes frequently (within minutes) to avoid detection and maintain a connection to the control server.

So to summarize: the user invokes the malware loader which then downloads the actual malware. The malware installs itself on the PC and connects to the control server by resolving the DNS name, then opens the connection to the server on port 80.

So if we can block the DNS query, we can stop the malware dead in its tracks. Yes, the PC is still infected with the malware loader, but it can’t download the actual malware, or the malware can’t do anything because it can’t resolve the address to contact the control site.

Malware control sites are fleeting entities – here today, gone tomorrow. They never stay around long enough, nor do they ever receive enough traffic to get into the top 1 million sites. So when the malware tries to resolve the name of the control server, it doesn’t get an answer, and fails to make a connection.

This technique is called whitelisting – where you only allow queries to known good sites and block everything else. This is opposed to blacklisting, where you block queries to known bad sites and allow everything else.

Here’s how to do it:

You need two components in addition to your existing DNS server: a new proxy server and a webserver to handle blocked domains.

Note: I’ve used the term “DNS server” rather loosely so far. From now on, I’ll be more precise and refer to your server as a “caching name server” which answers queries on behalf of your PC clients. If you have your own domain name (like netcraftsmen.net), you may also have an authoritative name server that answers queries from other Internet users. Often these two server functions reside on the same server.

Since most of you already have a working caching name server, we’ll set up a new server that will act as a proxy name server. This new server will be configured with a list of the top 1 million domain names and will forward requests to an external name server (like Google, or any one of your choice), which in turn will resolve the name for your users.

If the requested domain is not in the top 1 million sites, the server will return the address of an internal webserver that you’ll set up.  This server presents a web page to the users telling them that the domain they wanted is blocked. You can set up this page to automatically generate a helpdesk ticket or email so that legitimate sites can be added to the list.

This diagram may help make things clearer:

This is how it works: Your existing caching server is now set up to forward all requests to the new proxy server. When a client requests a name resolution, your caching server first looks in its cache for the answer. If it’s not there, the server forwards the request to the proxy.

The proxy looks in its zone file and finds the requested domain. Each domain entry in the zone file tells the server to forward the request to Google’s public servers (or someone else’s). Google will answer with the IP address, which will be sent back to your client. Your name server will also cache the answer, so the next request can be answered immediately.

If the proxy does not have a zone entry for the domain, it returns the IP address of an internal server you’ve set up to display a page to the user.

Here’s an example of how to set up the proxy server using BIND, a popular name server that runs on Windows and Linux.

You create a configuration file that lists the top 1 million domain names with forwarding information. You can get a downloadable list of the names here. Then, for each of the domains, you will put the following information in the configuration file:

zone "example-domain.com" {
       type forward;
       forwarders { 8.8.8.8; 8.8.4.4; };
};

You can use any text editor with search and replace functions to generate this file. You only need to do it once.

Then, you add a wildcard entry at the bottom of the list:

*      A      -ip address of your domain-denied webserver-

When the proxy receives a domain query, it looks in its configuration file and finds the zone entry. The zone entry specifies that the server should forward the query to another server (in my example, Google). That server will reply with the answer, which the proxy will return back to the caching server.

Any query that doesn’t match any of the zone entries will match the wildcard entry, which will return the address of the “denied domain” web page. This web page can be hosted on an internal server and can do any or all of the following:

• Display a message to the user informing them that the domain is blocked
• Create a helpdesk ticket so that the domain can be added to the approved list
• Send an email to an administrator so that the domain can be added (after verifying its legitimacy)

Admittedly, I’m not much of a web programmer, so I’ll just wave my hands and say this part magically happens. But I’m sure with a few minutes of web browsing, you can find some sample CGI scripts to get you started.

Now you have a DNS infrastructure that will protect your users against the vast majority of malware attacks, even previously unknown ones. This is important, because if you’re up against a very sophisticated malware attack based on, say, a Flame variant, you probably won’t be able to (initially) detect the malware. But, it’s extremely unlikely that the malware’s command servers are in the top 1 million domains. So the malware will not be able to phone home and will not be able to execute its attack.

But wait! There’s more! This DNS system also helps you detect attacks, even ones no one has seen before. If your “domain denied” server logs all requests, you have an excellent record of possible malware. If you are getting DNS requests that your users didn’t knowingly generate, it’s a very good indicator that there’s malware on that PC. Needless to say, any unknown domain should be thoroughly investigated before being added to the list.

Armed with your new DNS whitelist proxy, you will be able to stop malware in its tracks and even detect future, unknown malware. I think this is a valuable tool for protecting your networks.

I’m planning some actual implementations at a few of my clients, and I will report on the real-world outcome in a future blog post.