Dealing with Rogue DHCP Servers

You’ve probably happened across this little conundrum at least once or twice—troubleshooting a network issue where users are connecting to the network, but they aren’t able to access any resources or the internet.

You start going through your troubleshooting workflow: check the physical layer, data link layer, network layer… and there’s the problem. The device has an IP address, but it’s not an IP address you’d expect to see on your network.

Did someone set this IP address up manually? Maybe it was a “helpful” user, who knows just enough to get into trouble?

That’s not it. Turns out to be an invalid IP address from a DHCP. Congratulations, you have a rogue DHCP server on your hands!

What is DHCP, and how does it work?

Before diving into Rogue DHCP, let’s do a quick review of what DHCP actually is. DHCP, or the Dynamic Host Control Protocol, was established to automate the process of adding new IP addresses to the network. In the early days, networks had a limited number of workstations, and each one was given a hard-coded IP address when added to the network. This simple process was quickly outgrown because of the difficulty and resource-intensive nature of doing IP address assignments by hand. Network managers were keeping lists of IP addresses on spreadsheets. Multiple network technicians would assign the same address to different devices on the same network, causing IP address conflicts everywhere. DHCP was developed to allow a dedicated server to be set up to assign IP addresses to all devices connecting to the network, automating what used to be a very manual process.

How it works is pretty straightforward. As a device enters the network, it tells every device it needs (broadcasts a request for) an IP address. A dedicated DHCP server, listening for kinds of requests, responds with a DHCP response: assigning an IP address to the device from its pool of addresses. DHCP can also be used (and is most often used) to assign a default gateway and a DNS server to a device. This keeps the information centralized, reduces the use of resources, and greatly increases the efficiency of standard network operations.

So what’s a rogue DHCP Server?

Simply put, a rogue DHCP server is one that is not authorized to provide IP addresses to devices on your network. Rogue DHCP servers can be malicious, like in a man-in-the-middle attack, or simply inconvenient, as in the case of a user connecting an unauthorized home router to their work network.

In other words, a rogue DHCP server is simply a server not under the management or even the awareness of network management staff. Either way, they can be quite a pain. If a rogue DHCP server gets to your devices first, it can wreak all kinds of havoc on your network: performance or seed issues, inability to reach needed resources and connectivity problems. And because the misconfigured DHCP server is just sitting out there waiting to be used, it becomes a prime target for malicious actors. Here’s how they work, step by step:

1. A device enters the network, running an unauthorized DHCP service.
2. A new device is added to the network, or an existing device is switched on. This device, if configured to acquire a dynamic address, makes that DHCP request
3. Both the rogue DHCP server and your approved DHCP server respond to the request with their own IP.
4. There’s now a “race condition”: whose DHCP reply will reach the device first! If the rogue DHCP reply wins, the device will be unable to communicate with other legitimate devices on the network.

If it’s a malicious DHCP server, this is where bad things can start to happen. The rogue DHCP server can start to assign malicious default gateway information that can redirect legitimate devices to an unauthorized default gateway. Or it can act as the unauthorized default gateway itself, routing all traffic through that malicious device.

In my experience, it’s far more common to have an unintentional rogue DHCP server on your network, the result of misconfiguration or a “helpful” employee. That doesn’t mean that malicious DHCP servers never occur but don’t assume that it’s malicious right out of the gate.

How do you identify a Rogue DHCP server, and how do you resolve it?

There are a variety of ways to detect a rogue DHCP server. One common way is through general troubleshooting. For example, a specific workstation is having problems connecting to network resources. On investigation, you find that the workstation is not within the scope of IP addresses assigned for the segment it’s supposed to be in. This is a definite red flag that a rogue DHCP server is on your network. At this point, you’ll immediately want to start tracking it down.

If you’re looking to be more proactive in your search for rogue DHCP servers, use a network (packet) sniffer or look in the sFlow data collected by your network traffic analysis tool for packets coming from UDP port 67 (the standard DHCP port) on servers other than your approved DHCP server.

You can also leverage your syslog tool to check server logs for certain events. A few event terms to look out for include, “server upgraded,” “unreachable domain,” and “the server found in our domain.” On networks where you’d expect all devices to be domain-joined, “Microsoft-windows-DHCP-server, DHCP/BINL” is a big event to watch out for, as this means a server does not belong to any domain, because the domain field is empty.

If any of these are found, it’s an indicator that there’s likely a rogue DHCP server hanging around. Once a rogue DHCP server is discovered, speedy resolution is critical. The opportunity for havoc, or even a man-in-the-middle attack, is possible at any time. The best way to mitigate these rogue DHCP incidents is to remove the rogue DHCP devices from your network or shut down the switch ports they are connected to.

What about preventing rogue DHCP servers?

DHCP server issues can lead to very serious problems, especially if an attack is launched. That’s because it can be a long time before a rogue DHCP server is discovered, and an attack may not occur immediately. A malicious rogue DHCP server may spend days or even months servicing DHCP requests and at the same time collecting all types of sensitive information from your network before an attack is actually launched. You’ll be in a zero-day situation (a vulnerability that’s exploited before it’s discovered) and scrambling to recover. On the flip side, you can also discover rogue DHCP servers very quickly if it’s unintentional, as many (but probably not all) of your users will suddenly not be able to connect to the network.

As with all network security issues, prevention is the best protection. Let’s look a few basic steps you can take to find and prevent rogue DHCP servers.

Look for IP address conflicts.

One of the most effective ways to prevent rogue DHCP servers is to look for address conflicts and misconfigured IP addresses. This involves employing an actively monitored and effective IP address allocation and control system. There are many ways to do this. You can do it manually, or use network management tools to take control of the process.

This article goes into detail on how to find and fix IP address conflicts. I strongly suggest reviewing these techniques to further understand the process and how to find these types of address conflicts, because conflicts can cause many other problems beyond just helping you identify rogue DHCP servers.

Keep a properly documented network.

As with many networking issues, proper network documentation is key to preventing problems. You should know your DHCP servers, where they are, and what configuration details you have on them.

Use Active Directory to authorize DHCP servers.

The process of using your Microsoft Active Directory to provide authorization for DHCP servers can be a lot of help in the prevention of rogue DHCP servers. The domain controller keeps a secure database of active authorized DHCP resources. And if the DHCP server is not authorized, it won’t be added to the network.

Use DHCP snooping and trusted ports on your switches.

The best and most proactive configuration change you can make to prevent rogue DHCP servers on your network is to enable DHCP snooping on your managed network switches. Most modern switches have DHCP snooping built in, which means that they are actively looking for DHCP response packets within a specific VLAN or on a specific interface, and will notify you or lock down a port when DHCP responses are detected. By default, these switches will block DHCP replies coming in from a specific port—typically referred to as “untrusted interfaces.” You’ll want to configure the port your legitimate DHCP server is plugged into as a “trusted” interface, so it can reply to DHCP requests. This is the most effective way to prevent rogue DHCP servers from being added to a segment.

Bonus: Four steps for great DHCP management

Just like steps to prevention, best practices come down to documentation and maintaining network visibility. Here’s a process you can incorporate into your routines (automated or otherwise) to keep your DHCP management in the best possible shape.

1. Start with a complete inventory of all resources on your network from one end to the other. Keeping track of all DHCP requests and DHCP offer packets.
2. Once this is done, add these to your network map or network drawing. Now you can see exactly where DHCP is occurring. Are there any additional DHCP servers that are unnecessary? Are there any that you don’t recognize?
3. Next, look for any unauthorized routers on your network. Many times, bad actors will surreptitiously add an unauthorized router to a network. And this will cause many problems, including rogue DHCP servers.
4. After you have a good map and documentation of all authorized DHCP servers, go into Microsoft Active Directory and create an AD DS authorization of all good DHCP servers. Now, when a new or rogue DHCP server attempts to add itself to your network, it’ll be blocked by default.

Good security requires active, ongoing prevention. What happens when some other network manager turns off AD DS authorization when troubleshooting a problem, and forgets to turn it back on? It happens all the time. If you are not performing the correct maintenance and preventative steps, you will miss it.

---