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 wired
security as a high priority. Although this point might 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.
When securing DHCP services
is required, link layer filtering should be enabled for both Allow and
Deny lists. This will ensure that only the desired and approved clients
can receive an IP address and all others will be ignored. Also,
deploying a Network Policy Server (NPS) and configuring an appropriate
health policy can be performed, and the DHCP server can be configured to
check a client’s health information with the NPS server and deny a lease if the system does not meet the health policy.
Examining DHCP Authorization
DHCP is an unauthenticated
service, which means that anyone can deploy 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 use a network analyzer to determine the location of rogue
DHCP servers.
Authorization of a Windows
Server 2008 R2 DHCP server is straightforward, as long as the server is a
member of an AD DS domain and the logged-on user has proper DHCP
privileges in the domain. Normally authorization occurs during the
installation of the DHCP Server role. However, a domain DHCP server that
has been unauthorized or a workgroup DHCP server that is joined to the
domain will need to be authorized. This can be accomplished by following
these steps:
1. | Open the DHCP console (Start, All Programs, Administrative Tools, DHCP).
|
2. | Right-click
DHCP in the console tree, and then click Manage Authorized Servers to
display the Manage Authorized Servers dialog box.
|
3. | In the Manage Authorized Servers dialog box, click the Authorize button, as shown in Figure 1.
|
4. | When prompted, type the IP address or name of the DHCP server to be authorized, and then click OK.
|
5. | Confirm
the DHCP server to be authorized in the Confirm Authorization dialog
box, and then click OK. In a few minutes, the DHCP should be authorized,
and the scopes can be activated. Click OK to close any remaining dialog
boxes.
|
Understanding 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
Directory–integrated 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
2008 R2 overcomes this limitation by providing 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 or to ensure that each scope on the
DHCP server is configured with a user account to use for Dynamic DNS
updates. To add a designated user account to perform Dynamic DNS
registration for the DHCP server, open the DHCP server console, and on
the desired DHCP server, expand and right-click the IPv4 node, select
the Advanced tab, and click the Credentials button. Enter the name,
domain, and password of the user account that will update and own the
Dynamic DNS entries related to DHCP leases. Ensure that this account is
just a standard user and not a domain administrator to ensure that it
can only manage records that it creates and will be denied the ability
to update or replace any existing records created by Windows clients or
DNS administrators.
