DHCP Security

The DHCP protocol is effectively insecure. There is no way to determine if a request from a client is legitimate or is malicious. Users who have evil intentions can conduct denial-of-service attacks against the DHCP server by simply requesting all available IP addresses in a range, effectively disallowing legitimate users from being granted IP addresses. For this and other reasons, it is important to keep wire security as a high priority. Although this point may seem obvious, keeping potential intruders physically off a network is a must, not only for DHCP but for other network services prone to denial-of-service attacks. This includes auditing the security of wireless networks, such as 802.11b, which can (and often do) provide unrestricted access to malicious users.

In addition to physical and wire security, several security considerations and mechanisms should be examined to provide for a better understanding of the vulnerabilities and capabilities of DHCP.

DHCP Authorization

DHCP in and of itself is an unauthenticated service, which means that anyone can establish a DHCP server on a network and start to accept clients and assign them erroneous addresses or redirect them for malicious purposes. Consequently, since Windows 2000, it has become necessary to authorize a DHCP server that is running in an Active Directory domain. After the DHCP server is authorized by the proper domain administrative authority, that server can then accept client leases.

The downside to this approach is that a Windows NT 4.0 or Linux server could still be added, unauthenticated, to a network. In this situation, it would become necessary to pull out a network analyzer to determine the location of rogue DHCP servers.

Authorization of a Windows Server 2003 DHCP server is straightforward, as long as the server is a member of an AD domain and the user logged in has proper DHCP privilege in the domain. Authorization can be accomplished by following these steps:

1.	Open the DHCP Manager (Start, All Programs, Administrative Tools, DHCP).
2.	Right-click the server name and choose Authorize, as illustrated in Figure 10.13. Figure 10.13. Authorizing a DHCP server.
3.	In a few minutes, the DHCP should be authorized, and the scopes can be activated.

DHCP and Domain Controller Security

If at all possible, the DHCP service should not be run on an Active Directory domain controller because the security of the SRV records generated is lost. The reasons for this are as follows.

DNS entries in an Active Directoryintegrated DNS zone are "secure," which means that only the client that originally created the record can subsequently update that same record. This can cause problems if the DHCP server is automatically updating client records, however, as the client no longer performs this function and cannot have security applied to a record.

DHCP in Windows Server 2003 overcomes this limitation by placing all DHCP servers in a special group in Active Directory, called DNSUpdateProxy. Members of this group do not have any security applied to objects that they create in the DNS database. The theory is that the first client to "touch" the record will then take over security for that record.

The problem with this concept is that the records created by DHCP servers possess no immediate security and are consequently subject to takeover by hostile clients. Because domain controllers are responsible for publishing SRV DNS records, which indicate the location of domain controllers, Kerberos servers, and the like, this leaves a gaping security hole that users could exploit. Consequently, it is preferable to keep DHCP off domain controllers. If this cannot be avoided, it is recommended to not place the DHCP server into the DNSUpdateProxy group so as to avoid the security problems associated with it.