DHCP Server Security (Part 1)

Although DHCP servers are critical to the operation of most enterprise networks, DHCP server security is often one of the most overlooked areas of network security. One reason for this might be the simplicity of how DHCP works: DHCP clients broadcast discovery messages (DHCPDISCOVER) containing their MAC addresses and DHCP servers respond by offering (DHCPOFFER) to lease an IP address and other TCP/IP settings that the client can use to communicate on the network. The client responds (DHCPREQUEST) to the first lease offer it receives and the server acknowledges (DHCPACK) the request and marks the address as leased in its DHCP database. That’s all there is to it-who needs to worry about security?

Attacking DHCP

Unfortunately it’s the very simplicity of DHCP that’s actually the problem as far as security goes. No authentication or authorization takes place during an exchange between a DHCP server and DCHP client, so the server has no way of knowing if the client requesting the address is a legitimate client on the network, and the client has no way of knowing if the server that assigned the address is a legitimate DHCP server. The possibility of rogue clients and servers on your network can create all kinds of problems.

For example, a rogue DHCP server could provide legitimate clients with bogus TCP/IP information that prevents the clients from communicating on the network. A denial of service (DoS) condition then results, and users are unable to connect to network resources to perform their work. Setting up a rogue DHCP server could be as simple as conducting a social engineering attack to gain physical access to your network and plugging in a laptop configured as a DHCP server.

Another scenario might involve an attacker compromising a client computer on your network and installing software that repeatedly requests new IP addresses using spoofed MAC addresses until the entire pool of addresses in your DHCP server’s scope is leased. When this happens, legitimate clients that boot onto the network can’t acquire an address and again users are unable to access the network and can’t do their work.

A more sinister result happens when an attacker breaches network security and gains control of your own DHCP servers. At that point the attacker might proceed to modify the DHCP server to assign clients an incorrect subnet setting and thus create another DoS condition. Or they might modify the server to assign clients incorrect DNS settings and redirect clients to rogue or hijacked DNS servers, which could then redirect clients to hostile websites where they unknowingly download a trojan. Or they could modify the server to assign the address of the attacker’s own machine as default gateway, which results in outbound client traffic being redirected to the attacker’s machine which captures and reads the traffic and forwards it to the real default gateway. The result is exposure of sensitive business information without users even being aware of what’s happening.

Worse yet, if you’re running your DHCP server on a domain controller then an attacker who compromises your DHCP server gains access to your accounts database and can cause all sorts of further problems. The result is usually your worst nightmare. Fortunately, there are some measures you can take to protect your DHCP servers and avoid many of these scenarios, provided you’re also following all the usual best practices for securing Windows-based networks. Let’s look at some specific threats to DHCP on your network and the countermeasures you can take to mitigate these different threats.

Threats and Countermeasures

On the face of it, the requirement that Windows 2000 and Windows Server 2003 DHCP servers be authorized in Active Directory before they can start leasing addresses to requesting clients seems to mitigate the threat of rogue DHCP servers on your network. Authorization means that when a Windows 2000 or Windows Server 2003 DHCP server boots onto an Active Directory network it first contacts a domain controller to check if its own IP address is found on the list of authorized DHCP servers maintained by the domain controller. If the DHCP server determines that it is authorized to lease addresses to clients, it begins to do so. If it’s not authorized, Windows shuts down the DHCP Server service on the machine so it won’t be able to lease addresses.

The real benefit of this is to protect your network against legitimate DHCP servers that are badly configured, though it has the added side effect of guarding against accidental or rogue DHCP servers running Windows 2000 or Windows Server 2003. What happens though if an attacker compromises your network with a rogue DHCP server not running Windows 2000 or Windows Server 2003? In this case authorization won’t help because non-Microsoft DHCP servers may not respond the same way as Microsoft ones to the DHCPINFORM messages Windows uses to check if DHCP servers are authorized. Even Windows NT DHCP servers fall under this category, so an attacker with a laptop running Windows NT as a rogue DHCP server gets away scott free. Fortunately there are other ways to detect rogue DHCP servers and we’ll look at these in Part 2 of this article later. But making sure your DHCP servers are properly authorized is still an important first step in deterring rogue servers on your network.

Rogue clients is another problem entirely though, as DHCP is designed to make it easy for clients to obtain IP addresses so they can participate on a network. The obvious way of dealing with the problem of rogue clients would seem at first to be DHCP reservation, though on large networks this entails considerable administrative overhead. A reservation is a predefined setting that maps a MAC address to an IP address so that only a client with a particular MAC address can lease the IP address associated with that reservation. If security is critical an administrator could create reservations for each and every client machine on the network, and if unreserved IP addresses still remain in the DHCP server’s cope then these could be reserved using invalid or non-existing MAC addresses. Then when a rogue client tries to boot on the network the result is that the DHCP server has no free addresses to lease and the client can’t connect.

If only it were that simple. While this approach might foil a casual attack, sophisticated attackers have ways for circumventing DHCP reservations. The simplest approach is for the attacker to run a program that listens for DHCPDISCOVER broadcasts from clients and harvests their MAC addresses. Then when a legitimate client shuts down the rogue client can reconfigure its MAC address to match that of the legitimate client and hijack the legitimate client’s lease or try to disrupt communications for the client. Considering this, security-conscious administrators might consider dropping DHCP entirely in favor of static addressing, but what’s to stop an attacker who has physical access to your network from assigning a static address to their own machine and joining the network? One might go further and install a firewall on every client on your network and configure it to only allow communications with allowed IP addresses of legitimate clients, but imagine the administrative headache that would involve. So the bottom line is that the only way to really protect your network against rogue DHCP clients (and also rogue DHCP servers) is rigorous physical security i.e. no unsecured wall jacks, locked doors, staff trained to recognize social engineering attempts, and so on.

Even if your network is physically secure however, it also needs to be secure from a network entry point of view. If an attacker can penetrate your perimeter defenses and somehow compromise a DHCP server, then several kinds of exploits could be attempted including modification of DNS resource records when Dynamic DNS (DDNS) is being used, corrupting the DHCP database, and gaining access to sensitive information such as the details of your network’s addressing scheme and reserved addresses of critical servers. Basic security best practices like perimeter firewalls and intrusion monitoring are clearly your front line in preventing your DHCP servers from being compromised, but there are also some DHCP-specific monitoring procedures you can follow which we’ll look at in Part 2 of this article later.

Summary

Let’s look at our list so far of best practices for ensuring DHCP security on your network. We’ll add to this list further in Part 2 with some specific steps you can follow on Windows-based networks, but for now be sure to start at least with the following if you want to protect your network against DHCP exploits:

• Implement rigorous physical and perimeter security for your network and be vigilant in maintaining such security.
  
• Upgrade any lingering Windows NT domains so you can make use of the DHCP server authorization feature of Active Directory.
  
• Avoid using Windows 2000 or Windows Server 2003 domain controllers as DHCP servers.
  
• Use reservations for assigning addresses of critical servers on your network, or use static addresses for them instead. 

In Part 2 of this article we’ll continue by discussing how to enable auditing on DHCP servers, monitor membership in the DHCPAdministrators group using the Restricted Groups feature of Windows Server 2003, ensure that DNS works securely with DHCP, and use various tools to detect rogue DHCP servers on your network.