Can anyone think of a way of preventing an XP client from performing DNS lookups for external domains?

Question

As usual, we're trying to tighten security even further in our organisation. The current focus for me is the possibility of a compromised XP client from using DNS lookups as a command/control channel (Google "dns malware command control channel").

Of course, this presupposes that a client could be compromised in the first place; something that we believe very unlikely. That said...

We're currently a Windows Server 2003 AD shop, with all DNS zones stored in AD. The DNS servers are allowed to forward to our ISP's DNS serverz - something that is required by a number of servers, i.e.: we need to resolve external addresses for B2B stuff.

The XP clients and Windows servers are on the same domain, and therefore share the same DNS servers. The clients can therefore perform external address lookups.

If a client were to be compromised, it could before a lookup of whatsmynextmove.hacker.com, and the SOA for that domain could return a crafted reply which holds the control instruction.

So, the question is, can anyone think of a way of preventing the XP clients from performing DNS lookups for domains other than the local DNS domain (the one for the AD forest).

My thoughts so far:

1) Get some kind of proxy man-in-the-middle DNS product that the XP clients use. The proxy filter lookups for domains other than the internal domain.

2) Identify all the external domains that we need to resolve and configure conditional forwarders for each of them, e.g.: microsoft.com, verisign.com, redhat.com, Etc, Etc. I'm not sure how many conditional forwarders can be configured.

Any thoughts.... anyone?

Answer 1

What I did was use my firewall to block all LAN to WAN port 53 (DNS) traffic. Then I configure the firewall's DHCP to push out the DNS server of it's IP address (because it has a caching DNS proxy built in). Then I modified the DNS records to block some ad and marketing/tracking companies. Last I set the firewall to forward requests to OpenDNS and signed up for filtering and blocked content by group and added exceptions.

Actually when I said I blocked port 53, what I actually did to make bot's job a little harder is restrict out going traffic by port (i.e. 80, 443, ...) to only what I needed. When I get the IP address for email nailed down (because they seem to change every now and then) I will restrict them by port and IP so no other email will be allowed in/out.

Configuring your DNS requests down to the proxy IP and port and blocking all others would probably help some.

Of course don't forget to review the logs so you know if something did crawl in to a machine or if you are blocking something that should be unblocked.

Hope this helps.

Answer 2

Ever heard the phrase "Breached by Design"?

The DOE should wake up and realize that if you're using Windows on a network with any kind of outside access - no matter how many layers of protection you add on - you're already breached. Microsoft spent a fortune making their software able to phone home, and those methods are designed to get past any kind of defense you could set up.

Every single leaky channel - from security updates, to the 9,999,999 auto-updating software packages, to the insane ability of IE to rewrite your OS on the fly, to the amazing number of secret squirrel backwards communications channels (like DNS and their own little backspin on windows time server) and so on until you realize how futile it all is... Well, every channel is a potential entry point into your network.

This problem - which is becoming an issue of national security (now that the foxes have been roaming the hen house as they like ever since Balmer's boys scrambled to get Internet Explorer integrated into the OS) is that the use of Windows - and now dot Net - has become a "best practice". The problem is that it simply cannot be secured without using an air gap - meaning a network that isn't connected to any WAN or internet source. But even the brightest minds at the various TLA outfits are content to pretend that it'll never happen to their network.

The sad thing is that this is the same kind of thinking that made the Antivirus business a multi-billion dollar industry. If the management at MS hadn't decided that attempting to run/execute/evaluate every byte of data encountered was a good idea when DOS 3 appeared, we wouldn't be suffering from the headaches of AVG/McAffee/Norton/Windows Defender/etc. If you had a two year old, would you teach it to put everything it found on the sidewalk into it's mouth? Microsoft didn't invent the trojan/virus, but they did more to spread them than anyone could have dreamed of. But I digress.

In spite of this, the fix is easy. Almost. Put a linux or BSD unix box in. Disable all services except DNS and tell the DNS server it can only resolve for whatever you've put in the config, and maybe look upstream to the AD box for local or local domain addresses - using the linux box to filter out everything else. Then hard-code the DNS box in as the server for anything you want to lock down.

You'll pass your DOE audit with flying colors. The bad news is that the DOE audits are roughly as sophisticated and comprehensive as those other audit theatricals with catchy names like SAS-70. Like most security programs, they're more along the lines of security blankets than armed guards. If you run a windows network, and you have users using Internet Explorer, or Windows Search, or Chrome, or Google Desktop, or whatever else they managed to get installed - your security is entirely imaginary. Windows IS the primary vector - not because it's common, but because it's breached by design.

Answer 3

You need to implement something like split-brain DNS. For your setup you may begin getting ideas here.

Answer 4

The fact that this page now shows up second in Google for your proposed search phrase suggests that this is not a significant attack vector.

Thus far the most significant use of DNS per se has been as a pseudo C&C channel by the Conficker worm. In this case frequently changing domain names were however only used to permit the download of updates to the worm, and not to directly control it. Hence blocking web access to the clients was sufficient to thwart that vector.

If you really must do this, you might find what you need in the local-zone features of the Unbound recursive resolver to forward your local domain to the AD server and reject everything else. You'd need to configure your XP clients to use that server instead of your existing AD server.

Answer 5

joeqwerty - not quite. We're an American owned company, and have recently been audited by the "U.S. Department of Energy's Office of Nuclear Energy". This attack vector (Command and Control vector) is one of the "must fix" entries in the audit. But thanks for the response.