DHCP Server Security (Part 2)

If you missed the first part of this series click here to read “DHCP Server Security (Part 1)”.

As we discussed earlier in Part 1 of this article, DHCP is inherently insecure and your first line of defense for protecting yourself from rogue DHCP servers and clients is rigorous physical security for your network. Fortunately Windows 2000 and Windows Server 2003 do support some features you can use to enhance DHCP security, and there are some tools you can use to detect rogue DHCP servers on your network so you can eliminate them. Let’s look at each of these features and tools now.

DHCP Server Auditing

Auditing the DHCP database on your DHCP servers lets you determine which DHCP clients on your network are leasing addresses from your server. Auditing also lets you look for BAD_ADDRESS entries in the database and see where they originate, and this is important because such entries can indicate address conflicts arising when rogue DHCP servers assign addresses that are already in use. Such address conflicts can also arise if a rogue client has a static address that is within the scope of a legitimate DHCP server, or when you accidentally configure two DHCP servers to have overlapping scopes. Whatever the cause, BAD_ADDRESS entries indicate some kind of problem, whether misconfiguration or a security hole, that needs to be addressed.

To enable auditing on your DHCP servers, open  the DHCP console and connect to a DHCP server on your network. Then right-click on the server node and select Properties, and on the General tab make sure the checkbox labeled “Enable DHCP audit logging” is enabled:

Figure 1: Enabling DHCP audit logging

DHCP audit logs are stored by default in the %windir%\system32\dhcp directory, but this can be changed using the Advanced tab of the DHCP server’s properties sheet. DHCP audit logs are created or appended on a daily basis and are named DhcpSrvLog-Mon.log, DhcpSrvLog-Tue.log, and so on. Each log entry begins with an event ID, and the header of the log contains a list of possible event IDs together with an explanation of each one. Further configuration can be performed using the HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters key in the Registry where the following keys control how DHCP logging works:

  • DhcpLogFilesMaxSize specifies a maximum file size for all DHCP log files (default is 7 MB)
  • DhcpLogDiskSpaceCheckInterval specifies how frequently DHCP checks disk space usage (default is every 50 minutes)
  • DhcpLogMinSpaceOnDisk specifies the free space threshold below which logging becomes temporarily disabled (default is 20 MB)

DHCP Administrators Group

While members of the Domain Admins group obviously have full power to configure DHCP on the server, you can also delegate limited power to users whose job is to manage DHCP servers on your network. To do this, open Active Directory Users and Computers and add the name of the user to the DHCP Administrators domain local group:

Figure 2: Adding user Bob Smith to the DHCP Administrators group

This gives the user the ability to manage DHCP servers on your network without giving him any unnecessary authority to perform other administrative tasks, which is an example of the well-known security best practice of least privilege. The problem however is, how do you monitor membership in the DHCP Administrators group to make sure no unauthorized users are accidentally (or maliciously) added to the group? 

You can monitor membership of critical groups like DHCP Administrators using the Restricted Groups feature of Group Policy. To do this, first use Active Directory Users and Computers to open your Default Domain Policy (or some other GPO if the computer accounts for your DHCP servers were placed in some OU in your domain) and navigate to Computer Configuration\Windows Settings\Security Settings\Restricted Groups:

Figure 3: Restricted Groups

Now right-click on the Restricted Groups node and select Add Group, and specify DHCP Administrators as the group whose membership you want to monitor:

Figure 4: Monitor membership in the DHCP Administrators group

Click OK and use the Add button in the next properties sheet to specify which users are allowed to be members of this group. Note that even if the group already has members in it, you still have to perform this step and identify them again:

Figure 5: Bob Smith is the only user allowed to be a member of the DHCP Administrators group

Now click OK and membership in the DHCP Administrators group is restricted to only Bob Smith as desired:

Figure 6: Membership in DHCP Administrators has been restricted to Bob Smith

What happens now is that when Group Policy refreshes on your domain controllers (typically every 5 minutes) membership in the DHCP Administrators group is checked, and if by accident (or malicious intent) some other user like Mary Smith has been added to the group then she will automatically be removed and an ID 637 event will be logged to the Security log if you have auditing of account management events enabled. Membership in the DHCP Administrators group is thus monitored and controlled as desired.

NOTE: Windows 2000 also includes another group called DHCP Users which can be used to grant users read-only access to the DHCP console, and membership in this group can be similarly controlled using Restricted Groups.

DNSUpdateProxy Group

On Windows-based networks, DHCP and DNS can work together to simplify the configuration and operation of your network. Normally what happens is a DHCP client register its A (host) record directly with the DNS server, while the PTR (pointer) record is instead registered on behalf of the client by the DHCP server. This means an attack on a DHCP server could compromise control over records registered with your DNS server and be used to redirect traffic to a hostile site or cause denial of service. If you make a DHCP server a member of the DNSUpdateProxy group however, your DHCP server will not take ownership of any resource records it registers on behalf of clients. This approach is typically used when upgrading from Windows NT to ensure downlevel clients that do not support DDNS can take ownership of their own resource records when they are upgraded to Windows 2000 or Windows XP.

The point is that you should only add the computer accounts for your DHCP server to the DNSUpdateProxy group if you are going to be upgrading pre-Windows 2000 computers to Windows 2000 or Windows XP. And you should never add your DHCP server to this DNSUpdateProxy group if your DHCP server is running on a domain controller.

Detecting Rogue DHCP Servers

Finally, there are a few tools you can use to detect the presence of rogue DHCP servers on your network so you can get rid of them. These include both tools from Microsoft and from third-party sources, and we’ll end by examining two of these tools.


Dhcploc.exe is a command-line tool that is part of the Windows Support Tools found in the \Support\Tools folder on your Windows XP product CD and it can be used to display all DHCP servers that are active on the local subnet. Dhcploc.exe has been around since Windows NT 4.0 and it works by sending out DHCPREQUEST messages and displaying the IP addresses of the DHCP servers that responded with DHCPACK. You can find the syntax of this tool in the Help file that is installed when you install the Support Tools on your machine.


The Network Systems Group at Princeton University’s Office of Information Technology has developed a tool called dhcp_probe that tries to discover DHCP and BOOTP servers on a directly-attached Ethernet network. The existing build runs on Solaris 8 on SPARC with gcc and there is patch for it to work on Linux also, so if you have either of those platforms you can try using this tool to detect any rogue DHCP servers that might be running on your network. You can find the Network Systems Group’s tools page here and can download dhcp_probe directly from here.


In this article and the previous one I’ve examined why DHCP is intrinsically an insecure protocol and what you can do to secure it on Windows-based networks. Even if you implement the best practices I’ve suggested for securing DHCP, review your DHCP audit logs regularly, run Dhcploc.exe or other tools regularly to locate rogue servers, restrict membership in the DHCP Administrators group, and make judicious use of the DNSUpdateProxy group, it’s pretty clear that DHCP still remains a weak point in your network’s overall security landscape. What does the future hold then for DHCP security?

Since 2003 the Internet Engineering Task Force (IETF) is working on this problem, and is working on a proposed standard, RFC 3118 Authentication for DHCP Messages. This RFC suggests a couple of extensions for DHCP to provide for authentication of DHCP messages on your network using either a token-based exchange of messages or a shared symmetric key. The problem with these extensions however is that they require some additional initial configuration of the DHCP client, and the whole point of why DHCP was developed in the first place was to get away from having to pre-configure clients before they can participate on the network. So this solution would probably only be acceptable to enterprises if vendors could pre-configure machines at the factory level, and so far no vendors have taken on the task of implementing this solution.

On the other hand, IPv6 may offer a simpler solution to the problem of DHCP security. Since IPv6 is designed with end-to-end security from the ground up, it can protect DHCP traffic and make it more difficult for attackers to spoof DHCP messages or hijack DHCP traffic. Since the U.S. Department of Defense (DoD) is mandating use of IPv6 on all their networks in the near future, vendors are scrambling to make their hardware and software support IPv6 and this may drive enterprise adoption for IPv6 sooner than previously anticipated. When that happens, network security experts will probably have to revisit the whole question of DHCP security all over again and develop tools and best practices to ensure 21st century networks remain secure in an increasingly hostile cyberworld.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top