Rogue DHCP server fun

Published: 2010-02-14
Last Updated: 2010-02-14 12:17:37 UTC
by Mark Hofman (Version: 1)
8 comment(s)
As part of the day job we are often asked to look at "weird" things for clients. Earlier this week at a remote client site we had one of these "weird" things, although I guess the title gives it away. The machines at that location were all showing DNS settings for DNS servers that did not belong to the organisation.  The default gateway was also changed to an IP address in a different subnet than was being used. The first thought was that junior had botched the DHCP settings on the server.  A quick check on the server, that according to the misconfigured workstation provided the information, let him off the hook. 
The second thought was malware, we've come across that in the past, but we haven't seen much DHCP malware lately so we went for the, at this stage, more obvious option of a rogue DHCP server. To find it we sniffed the DHCP traffic and the cause was quickly clear.  A DHCP server on the local network was responding faster than the corporate server which is at the other end of slowish link.  Not all settings though, the IP address and domain name details were still from the corporate DHCP server. 
After finding the MAC address of the device and having a look through the MAC tables on the local switches, the device was found and disconnected.  Turns out it was an unauthorised ADSL modem with DHCP configured. It did get me thinking about how do we detect or prevent rogue DHCP servers on the network? 
In Windows world DHCP servers need to be authorised.  This will prevent a Windows server from accidentally handing out DHCP information until it is authorised, but it won't prevent a non Windows DHCP server from doing the same.  With the audit logging switched on you may, in the eventlog and DHCP log files, be able to identify other devices that are performing a DHCP functions. There are also two windows tools that will identify rogue DHCP servers. dhcploc.exe from the Windows XP support tools is a CLI based tool. roguechecker is a more recent GUI tool (make sure you download them from the microsoft website).  NMAP since version 5.10 has a script that may help as well.  Running the dhcp-discover script should provide you with information on any DHCP servers. A final method is your trusty IDS who should be able to detect rogue DHCP servers on the network. 
Preventing them in the first place seems to be trickier. RFC 3118 outlines an authentication mechanism for the protocol. DHCP packets are authenticated and only authorised packets are accepted by the client.  However I could not find any information on the practical implementation of this (if you do, please let me know).  
A second prevention mechanism is the use of DHCP snooping capabilities on switches. Essentially it only allows DHCP information to be provided by certain servers on certain ports.  Each vendor will have documentation  on how to implement it on their devices. 
Network Access Protection (NAP) or control (NAC) will help by forcing all devices to authenticate to the network. Devices that do not meet the criteria or can't authenticate correctly are segmented on specific subnet or VLAN.
Each of these methods has its challenges.  DHCP snooping on switches must be implemented correctly on each and every switch otherwise clients will not get their information.  NAC/NAP can be complicated as many of you will know and may only work with certain operating systems, supplicants, etc.  
Rogue DHCP servers can be a big issue.  Make sure you have something in place to prevent or detect them in your environment. 
Keywords: DHCP
8 comment(s)


Seems to me the greater concern was the rogue ADSL modem--did it have an external connection?
This should cover a good chunk of the folks out there.
To clarify Jeremy's comment, most managed switches support some sort of DHCP filtering specifically to prevent the operation of rouge DHCP servers.

Generally speaking, the feature is called "DHCP snooping". Any enterprise switch worth having will support that feature.
We actually covered DHCP Snooping, along with some other layer 2 protections in a recent ISC diary ==>

Look for more on Layer 2 network protections, probably later this month !!
@JeremyI. Turns out it was a known ADSL connection. Still not good, but at least no surprise
I'm guessing that ADSL modem was a back up connection in the case of the T1 going down or something, right? We have a number of branch offices that require high up time (banks) so each one is provided with a slower back up link. What type of connection it is depends on the ISP in the area.

I find that these back up connections are not nearly as managed as the primary ones yet are just as prevalent. Lack of management = security nightmares!

A nessus scan found an odd device with a fixed IP that was not in the database. It responded to DHCP and forwarded DNS requests to Sprint's PCS network... guess what? It was a 3G MiFi hub (how could a branch with 10+ employees possibly operate over a 3G connection anyway?!) that network ops had thrown into a branch because the local DSL and cable providers were too expensive. And of course they neglected to change any of the default SNMP settings which Nessus kindly made me aware of.

Moral of the story, back up lines are security risks waiting to happen and Nessus scans of your entire network can yield scary/interesting results.
I've experienced similar but far worse situations at several hotels... DHCP assignments from the guest network handing out overseas DNS servers; can you guess where traffic to many common social networking and financial web sites actually went to?
Another tool that I didn't see mentioned is DHCP Sentry. It is written specifically to detect rogue DHCP servers and alert administrators.

You can find out more here:

Diary Archives