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 http://isc.sans.org/diary.html?storyid=6025, 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. 

 

Mark