O'Reilly Book Excerpts: Securing Windows Server 2003
DHCP and DNS Securityby Mike Danseglio
Lots of elements are involved in a healthy network. Many are provided by hardware, such as the routing and switching of data. Others are provided by software and are frequently based on the network protocols in use. These services are often overlooked by security administrators and implementers. But attackers can use these services to launch, support, or continue an attack. In fact, denial-of-service attacks can be very effectively carried out by just attacking these services alone. This chapter explores two important services that exist on most networks but get very little security attention.
Microsoft has recognized the lack of security in DHCP and DNS. As a result, Windows Server 2003 has several security technologies that are not necessarily standards-based or fully compatible with other operating systems; however, depending on your computing environment and need for security, these technologies can prove beneficial.
In this chapter, I'll explore the core network services of DHCP and DNS. These services are essential to most IP networks today in that they respectively provide automatic addressing and name resolution. However, their security considerations and safe operations are often neglected. I'll show you how these services work, how they're vulnerable to attack, and how to protect them against those attacks when possible.
The Dynamic Host Configuration Protocol (DHCP) is a service that most IP-based networks use to greatly simplify the daily management of IP addresses and configuration of client computers. The DHCP Server service is provided as an optional component in Windows Server 2003. Because of its integration with the operating system and the reliance of network clients on DHCP, it is critical to understand how DHCP works and how it impacts the security of the overall system.
What Is DHCP?
DHCP allows network clients using the TCP/IP protocol to automatically obtain an IP address and network configuration information. Two computers are involved in any DHCP transaction, a client and a server. The client computer requests DHCP information from a server, which stores information in a database. The server provides the requested network configuration information to the client, which then configures the TCP/IP protocol with this information and begins communicating on the network.
How DHCP works
Understanding how DHCP works is very useful to the security professional. Such knowledge will help in understanding points made later in this chapter about vulnerabilities and flaws in the protocol that often cannot be addressed. Although a complete academic discussion of DHCP would be overkill, the information provided here will ensure you understand the essential parts of DHCP.
DHCP is based on RFC 2131, "Dynamic Host Configuration Protocol." It defines how DHCP works by defining the interaction between a DHCP client and a DHCP server. This is a great way to look at how it works.
The normal flow of DHCP traffic consists of four separate messages, as shown in Figure 11-1.
Figure 11-1. The flow of a basic DHCP lease
The messages that make up the basic DHCP interaction are:
- DHCP Discover
This message is broadcast from the client to all hosts on its local subnet.
- DHCP Offer
DHCP servers that have available IP addresses to lease respond to a DHCP Discover with a DHCP Offer. The offer message contains one of the available IP addresses. Essentially, the servers are asking the client if it would like the offered IP address.
- DHCP Request
The DHCP client selects one of the received DHCP Offer messages and transmits a DHCP Request to that server. The request contains the information from the DHCP Offer so the server knows who it's talking to. The server identifies the request as a response to its own offer and updates its database to indicate that the offered address has been leased.
- DHCP Ack
The DHCP server then responds with the final message to the client, a DHCP Ack. This acknowledgment provides additional configuration settings, called options, for the client, such as DNS name and lease duration. The client uses this information to configure TCP/IP to communicate on the network.
The end result of this interaction is that the DHCP client leases an IP address from the DHCP server for a specified time and uses that information to send and receive network traffic. When the client is done communicating on the network (perhaps during shutdown), it sends a DHCP Release to the server. This message informs the server that the address can be made available to other clients on the network. This is normally the final network communication by the client, as it must discard its DHCP settings immediately.
All DHCP addresses are leased from the server by the client. This is because there are a limited number of DHCP addresses available on any given network, and even fewer are available on each DHCP server. To help conserve and reuse unused IP addresses, a specific lease duration is provided whenever a client leases an address. The client can renew its lease at any point during the duration, but per the DHCP standard, must do so after 50% of its lease duration. For example, if a DHCP lease was configured at 48 hours, a client would begin renewing its lease at 24 hours. This is a transparent process to the user.
You may have noticed that there is no security mentioned in the DHCP process. This is because there simply isn't any security built into DHCP. In fact, the author of RFC 2131, Ralph Droms, openly states this drawback in the RFC:
DHCP is built directly on UDP and IP, which are as yet inherently insecure. Furthermore, DHCP is generally intended to make maintenance of remote and/or diskless hosts easier. While perhaps not impossible, configuring such hosts with passwords or keys may be difficult and inconvenient. Therefore, DHCP in its current form is quite insecure.
An attacker gains numerous advantages when DHCP is used in an environment, such as:
It is nearly trivial for the attacker to get a valid network address. This provides her the ability to communicate on the network.
The attacker will get parameters from the DHCP server that identify network service locations, such as DNS and Windows Internet Naming Service (WINS) servers, which may be susceptible to specific attack vectors.
Because DHCP normally issues IP addresses sequentially, an attacker can identify other hosts on the network by examining her own IP address. Usually any number lower than the attacker's IP address will be leased by a host and active on the network. This is done without probing or even sniffing network traffic.
An attacker can create her own DHCP server that transmits DHCP Offers and Acks. This could configure the client as the attacker prefers, essentially hijacking the client's network communication. Without any authentication of DHCP, it is nearly impossible for the client to identify this type of attack.
Simple code can be written to lease DHCP addresses from servers until they run out of available addresses in their database. When this happens, legitimate hosts can no longer lease DHCP addresses, resulting in a denial-of-service attack.
Because security is omitted in the basic design of DHCP, it is hard for us to secure it afterward. I'll explore a few alternative configurations and operations that you can perform to help provide some security when using DHCP. But you should recognize that there is no reasonable way to secure the current version of DHCP.
The principal technology in this area is DHCP server authorization. This is a cooperative server-based scheme in which DHCP servers query Active Directory whenever they start to determine whether they're authorized by the network administrator. If they are authorized, they continue to function normally. If they aren't authorized, the DHCP service shuts down.
This sounds great on the surface. However, the concerns about the security of this technology include:
Only servers running Windows Server 2003 or Windows 2000 Server with Service Pack 2 or later can be authorized. Any other DHCP server running on any operating system cannot be authorized. This includes third-party DHCP servers running on Windows-based operating systems.
The DHCP server doesn't have to be authorized. If the DHCP software does not perform this voluntary check, it will begin functioning as normal. This means that an attacker could use another operating system and still launch a DHCP service.
You must use Active Directory in your network to authorize DHCP servers. If you don't use Active Directory, this feature simply doesn't work.
DHCP server authorization can be useful. It can help prevent misconfigurations on your network, such as when an administrator accidentally brings up a new unauthorized DHCP server. It is also useful for limited prevention against rogue DHCP servers. But it should not be relied upon to stop all attacks of this type.