Rogue DHCP Servers
On occasion you may be consulted about network issues which suggested a rogue or unknown DHCP server present on the network. This can show up is several ways including the discovery of a PC with incorrect IP addressing, most often the wrong DNS server, or in an SBS environment the SBS DHCP service has shut down due to the presence of another DHCP server. The dilemma is how to locate it. There are a few tools that can be helpful with the process.
You may also have a case of an unknown device in the DHCP management console under address leases. Some of these tools can be useful in isolating those as well.
Determine the DHCP server’s IP:
The first step is to locate the DHCP server’s IP. You may be fortunate and have discovered the incorrect addressing on a PC. In this case the DHCP server will be listed in the IPconfig /all results. Alternatively you can use two different tools.
The first is Microsoft’s DHCPloc.exe (DHCP locator). It can be downloaded as an individual executable from http://www.petri.co.il/download_free_reskit_tools.htm or as part of the Server Support Tools on the server’s installation CD.
Warning: DHCPloc should not be run on the DHCP server itself. Doing so can cause the DHCP server to stop responding to DHCP requests.
At a command line, from the directory where you have saved DHCPloc enter
DHCPloc.exe <the workstation’s IP>
You may have to hit enter twice. You will be prompted to enter d, q, or h. Enter d for discover, and again you may have to hit enter twice. It should return the IP of the DHCP server, or servers, and an offered DHCP address.
DHCPloc syntax:
http://technet.microsoft.com/en-us/library/cc778483.aspx
You may want to temporarily disable the network’s default DHCP service while running these tests.
The second method is to use Wireshark, from http://www.wireshark.org, a network packet analyzer and a much a more powerful tool. Install Wireshark on a workstation, start a scan, and run an ipconfig /release and /renew to force a DHCP request. Once complete you can filter the log by protocol and locate the DHCP related packets. Do this quickly as Wireshark collects a substantial amount of data very quickly. There are tutorials available to become familiar with Wireshark.
Find the MAC Address:
With any luck you now have the IP of the DHCP server. Next is to find the device’s MAC address. By now it should have been recorded in the arp table, but if not try pinging the IP. Then from a command line run arp –a or arp –a |find “IP address” to recover the MAC address of the device.
Determine the Manufacturer:
The fist 6 characters of the MAC address are assigned to the manufacturer, therefore we may be able to determine the make of the device in question. In the example above we would use 00-15-5d in conjunction with a site such as http://standards.ieee.org/develop/regauth/oui/public.html and determine the registered manufacturer/vendor was Microsoft Corporation. This may or may not be helpful since in this case it simply indicates it is a Virtual machine. Often it will provide results such as Cisco-Linksys, D-Link Corp., Apple Inc. which may give you a better indication as to the type of device, perhaps a Linksys router installed by an employee to add wireless to his or her office.
Locate the device:
Physical location is much harder to establish, especially if it has been intentionally hidden. It is always best practice to keep a floor plan with all network drops and to disconnect any unused network drops at the patch panel, but it doesn’t do much to protect you. If you have managed switches you can locate the port to which the IP or MAC address is connected and start tracing from there. However, if you do not have managed switches you are best to run a continuous ping (ping –t 192.168.19.21) and start unplugging cables at the patch panel until you have dropped packets . A little crude, but effective.
I will publish an article in the near future to more proactively address this issue using DHCP filtering.
LAN-Tech Network Management 