Hunting a Rogue DHCP Server
As much as I hate the effects, I have to admit that I love the challenges presented when a user places a piece of unauthorized equipment on one of my networks. Only under this kind of pressure does one get to stretch the legs, and refine the hunting techniques. About a week ago my team was presented with several symptoms that indicated we had a rogue DHCP (Dynamic Host Control Protocol, for assigning IP addresses to hosts on a network dynamically) server somewhere in the enterprise. New machines, and laptop users were getting bad network configuration information, and our RAS services customers began complaining that they could not connect to resources on the network after successfully authenticating. That, in a word, sucked. I began my hunt for the naughty piece of equipment with the tools I had at my immediate disposal. Ordinarily, I try to use my Open Source tool kits, but being a pragmatist, I decided to use a tool found in the Microsoft Windows 2000 Resource Kit to find the IP address of the offending host. The tool is dhcploc.exe, and is run from the command-prompt. A screenshot shows the use of the tool and its output below:
The ‘-p’ switch suppresses output from authorized DHCP servers. The first IP address given with the command is the IP address of the host from which you are running the command, and any subsequent addresses are addresses of authorized DHCP servers you are suppressing with the ‘-p’ switch. The output is fairly self-explanatory. The first column shows the time-stamp for what is going on. The second column tells you what is going on (NACK, or request, and OFFER) with the packet flagged by the tool. The third column shows the IP address where the request is coming from (0.0.0.0), or the IP address being offered by the flagged DHCP server. The fourth column is the most important, as it identifies the IP address of our rogue. 10.0.1.1 is our little devil, so now we have to find out where on our network it is plugged in. In order to find the physical location of our rogue device, we have to find its MAC (Media Access Control) address, also known as a hardware address. To find this out, I used my favorite packet capture software, Ethereal (3/26/2014 update: this tool is now known as Wireshark) and the running dhcploc.exe software. By pressing ‘d’ in the command-prompt window where dhcploc is running, you force a discovery broadcast, which requests a DHCP address. Capturing this request and the response(s) with a sniffer, I can see the MAC address of the responding server. See the screenshot below:
The MAC address is listed under the Ethernet II, SRC address in the DHCP offer packet. Got it! Now, we have to find this MAC, starting at the core enterprise switch, tracing it all the way back to the closet switch and port where it is plugged into the network. ssh-ing to the core switch, we run the ‘show cam’ command to find the identified MAC address like so:
Core-switch> (enable) show cam 00-0d-93-22-c3-b4 * = Static Entry. + = Permanent Entry. # = System Entry. R = Router Entry. X = Port Security Entry VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 1 00-0d-93-22-c3-b4 5/10 [ALL] Total Matching CAM Entries Displayed = 1
This shows that the closet switch hosting this MAC is connected to port 5/10 on the core switch. Consulting my handy-dandy network map, I identified which switch this was, and ssh’d to it in order to run the ‘show mac-address-table’ command to find the port to which the rogue device was connected like so:
4-227#show mac-address-table address 000d.9322.c3b4 Non-static Address Table: Destination Address Address Type VLAN Destination Port ------------------- ------------ ---- -------------------- 000d.9322.c3b4 Dynamic 1 FastEthernet0/7
This shows me that the device is connected to port 7 on the closet switch. Now, I need to check to see if any other devices are connected to this port (like by an unauthorized switch or hub) with the following command:
4-227#show mac-address-table interface FastEthernet0/7 Non-static Address Table: Destination Address Address Type VLAN Destination Port ------------------- ------------ ---- -------------------- 000d.9322.c3b4 Dynamic 1 FastEthernet0/7
The output shows only this device on the port, so, to remedy our network troubles, I had to shutdown this port to stop the offending device from causing mischief with the following commands:
4-227#conf t Enter configuration commands, one per line. End with CNTL/Z. 4-227(config)#int FastEthernet0/7 4-227(config-if)#shut 4-227(config-if)#^Z
The easy part of solving the problem is done. At this point, the problem was turned over to management for “User Re-education” to prevent similar problems in the future. For now, my role is in enforcing the rules…not compromising, negotiating, or re-writing policy to accommodate stupidity. Oh, in case you were interested, the rogue device was an Apple Airport Extreme, which the user had plugged into the network using a LAN interface instead of the WAN interface. Never crossed his mind to inquire with us regarding the failure of his devices in connecting to the network…but that is probably another, longer issue with very scary roots. That’s it for now.
Categories
wittzend.com 