Archive for March, 2009

Another Reason to Focus on DNS Security

Friday, March 27th, 2009

This week I found an instance of the Rogue DHCP Server malware that caused an outage on a segment of the network when systems starting getting their DHCP leases from it instead of the legitimate DHCP server. This was particularly nasty because the malware overrides your DNS entries with two external DNS servers (64.86.133.51 and 63.243.173.162). Now if you just have outboud DNS queries restricted to your known internal DNS servers (as you should), you should see failed entries in your firewall logs and those clients will fail to resolve any DNS names.

If you don’t have this in place, the client’s DNS resolution could be very easily poisoned. You send out a request to resolve www.bankofamerica.com to a malicious DNS server, and it could return any IP address it wants, even a fake banking site. I don’t think there have been any signs that these particular DNS entries are doing anything this specific, but the opportunity exists. The Internet Storm Center and others have been covering this latest instance of the malware:

ISC Diary: new rogue-DHCP server malware
Softpedia News: DNS Poisoning Malware Gets Upgrade

I recommend monitoring for any attempts to query DNS from the two ip addresses listed above. This may help you identify any instances of this malware that hasn’t been caught by your AV yet.

This once again highlights the need for strong DNS controls. You should restrict all DNS queries initiated from inside your network to centrally managed internal DNS servers. Those servers should then be configured for recursive DNS querying out the Internet as needed. These controls would not prevent an outage like the one the rogue DHCP malware can cause, but at least it is limited to a single segment and you won’t have to worry about DNS poisoning from unauthorized DNS servers on the Internet.

Another thing to consider is the affect this malware could have on servers that may use DHCP with reserved addresses as opposed to setting static addresses. Also keeping your client systems (workstations and laptops) which are most likely to get infected off the same layer 2 segment as any servers can help reduce your exposure. Ultimately, preventing a rogue DHCP server is very difficult, but you can limit the damage.