SMB: Tracking down a rogue DHCP server

Rogue DHCP servers can be a real pain to track down on an SMB LAN. You’d think that with a small network you’d be able to readily identify just about any unknown devices on a LAN, right? It’s just a matter of wandering around the office, maybe? In my experience that ceases to be the case as a network grows… at 50 or so employees and maybe 80 or so devices things tend to get a bit harder to track down.

Real-life example:

So an email alert pops up on my cell last night indicating that the DHCP service had stopped on one of our client’s systems. Because they’re a new client, I make sure that I get copied on all of these alerts regardless of who is actually on-call at the time. So we called the client and left them a message to make them aware of the issue, and then followed-up this morning.

The system log on the SBS server revealed event IDs 1053 and 1054, with 1053 being as follows:

The DHCP/BINL service on this computer running Windows Server 2003 for Small Business Server has encountered another server on this network with IP Address, 192.168.2.1, belonging to the domain:

Unfortunately we didn’t have a way to talk to 192.168.2.x remotely, so I went on-site to track this down (yes, we probably could have done most of this remotely, but you’ll see why it was beneficial to be on-site in this case). After firing up my laptop I received a 192.168.2.x address – which was wrong; it should have been something in the 192.168.1.50-200 range.

So the next thing I did was ping what appeared to be a rogue gateway.

c:\>ping 192.168.2.1

I received responses, so that’s a good starting point.

c:\>Tracert 192.168.2.1

No hops… so nothing was between myself and the device.

>arp –a

So IP is a layer 3 protocol, and it doesn’t know what’s going on at the physical level. Using the Address Resolution Protocol (ARP) we can get the physical address of the destination host once we’ve sent a ping and the ARP has cached the results of its broadcast. Thus, “ARP –a” showed me the MAC address of the rogue device.

Once we had the MAC address, it was just a matter of finding it on the managed switch.
So I telneted to the managed switch (after configuring the switch, but that’s a different story… just remember that they’re a new client).

# sh ?

This displayed help for the show command.

#sh mac-address

This displayed a list of MAC addresses that the switch has learned. From there, I could tell that the MAC in question was associated with the physical port number 1 on the switch.

Port 1 was uplinked to a 48-port unmanaged switch. My first thought was great… now I’ve got to trace all of these active connections. But before doing that I figured it would be worth trying try to talk to the rogue device… so after connecting to the IP via telnet and web browser it turned out to be a cheap router, with the default admin password configured.

Well, that’s an improvement. So I logged in and turned off DHCP. Next it’s was just a matter tracing the connections. The downside was that there wasn’t much of an up-to-date wiring diagram, so it took some time to figure out exactly where the box was located.

After tracking the device down to the particular drop and removing it (it was located under and behind a desk), I talked to our client. No one was able to pinpoint just exactly how this device ended up on the network. It was connected to a printer, so my guess is that someone had tried to use it as a switch. It wasn’t configured to do anything particularly malicious – beyond handing out IP’s that were inappropriate, and that was just a side effect.

The client was pleased with our responsivness and approach. So with that issue resolved, it’s time to start talking to the client about a network upgrade project that will bring them up to spec with our support-matrix.