11.1 DHCP

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.

11.1.1 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.

11.1.1.1 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.

11.1.1.2 DHCP security

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.

DHCP and 802.1x

802.1x is a protocol gaining popularity in secure environments. Originally designed to improve on the security flaws of other protocols, 802.1x is used to authenticate clients to network servers before they communicate. This is port-based security, which means that every network port connected to a switch (Ethernet) or access point (wireless) must be authenticated and authorized before any network traffic is passed from that port to another.

802.1x works at a lower layer than DHCP. Therefore, 802.1x can help protect against attackers by requiring authentication before a DHCP lease is obtained.

The problems with 802.1x deployment are simple:

It requires expensive hardware. 802.1x-compliant switches are not the norm and demand a premium price.
It requires expensive software. Backend network client software such as RADIUS or Internet Authentication Service (IAS) must be deployed. In addition, because 802.1x uses certificates, most scenarios call for a PKI.
It requires lots of configuration and management. Clients must be configured with a certificate and the proper settings before they can successfully communicate on the network.

These problems usually outweigh the benefits of deploying 802.1x on a wired network. Therefore, I do not recommend 802.1x as a mitigation for the threats discussed in this chapter.

11.1.2 Using DHCP Securely

There is no such thing as secure DHCP. You'll see it over and over again in this chapter. However, there are ways to make a DHCP-based network a little more resistant to attack. There are several keys to doing this.

First, we must examine the common attack vectors against DHCP. Then we'll examine the countermeasures. And finally, we can look at the system overall and determine whether it's secure enough for our specific needs. If not, there is one simple answer: do not use DHCP. Manually configuring TCP/IP on client computers remains a viable option, and many companies throughout the world do it today. Although it incurs a fairly high TCO and requires a significantly larger IT staff, manual configuration is not without its place.

Overriding all our concerns about DHCP is one basic assumption. To mount a DHCP-based attack of any type, an intruder must have initial access to your network. That is, to hijack clients by sending DHCP Offers, the attacker must put his own computer with a DHCP server on your network. The same is true for all other attack vectors. So one way to help thwart DHCP-based attacks is to tightly control network access. This is discussed throughout the book, but especially in Chapter 14.

All the procedures listed here assume DHCP is already installed on the computer. Installation and normal operation of DHCP are beyond the scope of this book.

11.1.2.1 Configuring DHCP for proper administration

Windows Server 2003 provides a user group called DHCP Administrators. This group contains all user accounts that are authorized to modify DHCP settings. The membership for this group should be tightly controlled and audited to ensure that no unauthorized users are added to it. This will help prevent both accidental and intentional misconfigurations and help prevent security incidents and denial-of-service occurrences.

11.1.2.2 Monitoring DHCP for DOS attack

The first and simplest attack against DHCP is to lease all the addresses in its database. As discussed earlier, leasing all the addresses is a fairly simple attack that causes a denial of service by stopping legitimate computers from obtaining DHCP addresses.

A DHCP denial-of-service attack cannot be truly prevented. However, it can be detected early and stopped in its tracks. To do this, you must monitor DHCP. Monitoring DHCP can show you how many leases have been issued over time and can indicate an attack by showing a massive spike or prolonged above-average lease requests. You can also monitor servers to determine when their percentage of available addresses falls below a determined criteria, perhaps 5%. Either of these statistics could indicate a DHCP-focused attack.

To monitor DHCP, you can use the DHCP MMC snap-in, the System Monitor tool, or the Performance Logs and Alerts snap-in. Both the DHCP and System Monitor tools give great snapshots of what's happening with the server at that moment. However, they're not as useful for gathering data over time and identifying trends. To do that, we'll need to use Performance Logs and Alerts.

Knowing what we do about DHCP, we can assume that a denial-of-service attack will take the form of continuous DHCP Discover and DHCP Request messages being received. We can create an administrative alert to tell us when an abnormally high number of DHCP Requests are received on a server.

Before we begin, we must baseline the DHCP traffic. Baselining is, simply put, observing the normal operation of the server to see what it does. In our example, we must baseline the DHCP traffic coming into the server. There are many ways to baseline, but for this book, we'll keep it simple. We'll baseline the DHCP Request traffic over three normal workdays to determine the average traffic that we should expect.

To do this, we follow this procedure:

Click Start Run, type Perfmon.exe, and then press Enter. This brings up the Performance snap-in which is a combination of System Monitor and Performance Logs and Alerts.
Double-click Performance Logs and Alerts, and then double-click Counter Logs.
Right-click Counter Logs, and then click New Log Settings.
Type a name for the log, such as DHCP Offer traffic. Then click Enter.
Click Add Counters.
Under Performance Object, select DHCP Server. Then under Select Counters from List, select Requests/sec. Click Add to add this counter. Then click Close.
Click the Schedule tab to configure the schedule for monitoring this counter. Because we want to set it for three days, choose beginning and ending times similar to those in Figure 11-2.

Figure 11-2. The counter is scheduled to be monitored every 15 seconds for three days
Click OK. If the folder for the performance log does not exist, you will be prompted to allow its creation. Click Yes.

Once the three days have elapsed, you will be able to view the counter log and determine what the average DHCP Offer traffic is for this computer. Let's assume for brevity that you determine from this log that the maximum DHCP Offers per second the server encountered was 15. This helps us determine when an attack might be taking place.

There is no exact science to determining a number that indicates a problem. You need to decide whether you want more false positives or false negatives. In this case, let's assume a safe number is 20. If your DHCP server encounters more than 20 DHCP Requests per second, you want to know so you can examine the situation and determine whether an attack is taking place.

You can do this by setting up an administrative alert. as shown here:

Click Start Run, type Perfmon.exe, and then press Enter. This brings up the Performance snap-in which is a combination of System Monitor and Performance Logs and Alerts.
Double-click Performance Logs and Alerts, and then double-click Alerts.
Right-click Alerts, and then click New Alert Settings.
Provide a name for this alert, such as DHCP DOS attack. Then click Enter.
Click Add.
Under Performance Object, select DHCP Server. Then under Select Counters from List, select Requests/sec. Click Add to add this counter. Then click Close.
Configure the alert to alert when the counter exceeds 20 by typing 20 in the Limit box as shown in Figure 11-3.

Figure 11-3. This alert will be triggered when 20 or more DHCP Requests are made per second
Click the Action tab. This is where you tell the alert what to do when the threshold is met.
Click Send a Network Message To, and then type the administrator's login name. Although this works in only limited scenarios, it often helps. You can also configure numerous options to alert you of a problem as shown in Figure 11-4. The application log entry, which is selected, is effective if you have a centralized log management strategy in place.
Click OK.

Figure 11-4. This alert logs an event and sends a network message to the author

You now have a tool in place that will help you identify DHCP denial-of-service attacks. There are other tools and processes you could use, to be sure, but this one is included in Windows Server 2003, takes very little time to set up, and is reasonably effective.

11.1.2.3 Auditing DHCP

Auditing DHCP is, from an attack detection perspective, essentially the same as monitoring the DHCP performance counters. You collect statistical data and determine whether an attack is occurring based on that data. However, auditing DHCP activity can give us more specific information and allow us to examine attacks in greater detail.

Enabling auditing for DHCP is a simple task. Use the following steps:

Click Start All Programs Administrative Tools DHCP. This opens the DHCP Management MMC snap-in.
Double-click the name of your DHCP server to select it.
Click Action, and then click Properties.
On the General tab, ensure that the Enable DHCP Audit Logging option is selected as shown in Figure 11-5.

Figure 11-5. The DHCP audit log is enabled

Now the DHCP server will log all tasks that it performs. The log is a text file stored in the %SystemRoot%\System32\dhcp directory by default. You can change this directory by modifying the path under the Advanced tab in the previous dialog box. The files are stored with the filename of DhcpSrvLog-day.log where day is a three-letter abbreviation for the day of the week, such as Mon, Tue, and so on.

11.1.2.4 Analyzing DHCP logs

For our purposes, DHCP logs become interesting only when we see some type of attack occurring. Here's an example portion of a DHCP log showing the beginning few entries in a denial-of-service attack:

ID,Date,Time,Description,IP Address,Host Name,MAC Address

24,02/13/04,11:34:07,Database Cleanup Begin,,,,

25,02/13/04,11:34:07,0 leases expired and 0 leases deleted,,,,

25,02/13/04,11:34:07,0 leases expired and 0 leases deleted,,,,

30,02/13/04,11:55:31,DNS Update Request,5.1.168.192,ALICE.contoso.com,,

10,02/13/04,11:55:31,Assign,192.168.1.5,ALICE.wingroup.contoso.com,000BDBD1784E,

32,02/13/04,11:55:31,DNS Update Successful,192.168.1.5,ALICE.contoso.com,,

30,02/13/04,11:55:32,DNS Update Request,6.1.168.192,BOB.contoso.com,,

10,02/13/04,11:55:32,Assign,192.168.1.6,BOB.contoso.com,000BDBF43A0B,

32,02/13/04,11:55:32,DNS Update Successful,192.168.1.6,BOB.contoso.com,,

30,02/13/04,11:55:33,DNS Update Request,7.1.168.192,CAROL.contoso.com,,

10,02/13/04,11:55:33,Assign,192.168.1.7,CAROL.contoso.com,000BDB191D0B,

32,02/13/04,11:55:33,DNS Update Successful,192.168.1.7,CAROL.contoso.com,,

30,02/13/04,11:55:34,DNS Update Request,8.1.168.192,DOUG.contoso.com,,

10,02/13/04,11:55:34,Assign,192.168.1.8,DOUG.contoso.com,000BDBD00B1E,

32,02/13/04,11:55:34,DNS Update Successful,192.168.1.8,DOUG.contoso.com,,

30,02/13/04,11:55:35,DNS Update Request,9.1.168.192,EVAN.contoso.com,,

10,02/13/04,11:55:35,Assign,192.168.1.9,EVAN.contoso.com,000BDBC2929A,

32,02/13/04,11:55:35,DNS Update Successful,192.168.1.9,EVAN.contoso.com,,

30,02/13/04,11:55:36,DNS Update Request,10.1.168.192,FRAN.contoso.com,,

10,02/13/04,11:55:36,Assign,192.168.1.10,FRAN.contoso.com,000BDB42189A,

32,02/13/04,11:55:36,DNS Update Successful,192.168.1.10,FRAN.contoso.com,,

30,02/13/04,11:55:37,DNS Update Request,11.1.168.192,GEORGE.contoso.com,,

10,02/13/04,11:55:37,Assign,192.168.1.11,GEORGE.contoso.com,000BDBBEDEBE,

32,02/13/04,11:55:37,DNS Update Successful,192.168.1.11,GEORGE.contoso.com,,

The scenario is that this particular DHCP server serves several client subnets in a moderately sized company. It's one of three DHCP servers. The server is configured to provide 12-hour leases. Its normal baseline (mentioned earlier) usually shows a spike between 8 a.m. and 10 a.m., Monday through Friday, as employees come in and turn their computers on. The load on the DHCP servers is then light throughout the day, mostly consisting of renewals and the occasional new client computer powering up.

At 11:55:31 on Friday the 13^th, this server began receiving numerous DHCP requests, of which a small set is shown here. Prior to this time it was relatively idle, occasionally maintaining its leases and leasing new addresses. But all of a sudden, a large number of lease requests began flooding the server. If you notice, the hostnames are all relatively similar and the MAC addresses all share the same prefix. If the names and MAC addresses matched the common host configuration on a network, it might not cause alarm. However, between the massive lease onslaught, the sequential hostnames, and the oddity of the MAC name pattern, it is a distinct possibility that the DHCP server is being attacked.

The other important entry to notice in this log is that the DHCP server is updating the DNS records for its leases. This means that the DHCP denial-of-service attack will cascade into a DNS server denial-of-service attack. On top of that, from the DNS server's perspective, the attack is coming from the DHCP server. So if you noticed the activity on the DNS server first, you might suspect one of your own servers!

This scenario is relatively common, and getting to the root cause is key. When such an attack is detected and is still taking place, you should decide whether your priority is capturing the attacker or ending the attack. Each requires you to perform separate tasks, but in either case you must act quickly. While stopping the attack is usually a simple matter of disconnecting network segments or the DHCP server itself, capturing the attacker is a much more convoluted scenario involving evidence preservation, passive tracing, and data capturing. This falls under the category of incident response and is not covered here. You can refer to many resources for information on incident response, but my favorite is the United States' Computer Emergency Readiness Team (CERT) web site at http://www.us-cert.gov.

Catching an attack in this way while it's still occurring is a very rare occurrence. Don't expect it to ever happen to you. But be prepared if it does.

11.1.2.5 Monitoring the network for unauthorized DHCP servers

So far we've seen how to protect your authentic DHCP servers from attack?or, more precisely, how to detect an attack as quickly as possible. But there is another common attack that these defenses do not protect against?when an intruder gains physical access to your network and brings up her own rogue DHCP server. That's generally referred to as a DHCP server spoofing attack and can be very harmful on your network.

Once an attacker can lease IP addresses and configuration information to network clients, she essentially owns all network communication with that client. The client uses the DHCP configuration information to determine default gateway and DNS or WINS information, so all communication must go through servers that the rogue DHCP server has identified. This means that the client may be communicating entirely with servers that the attacker owns, and all the network traffic may be either monitored or entirely fabricated.

Windows 2000 and Windows Server 2003 have some basic protection against this type of occurrence. When you install a DHCP server on either operating system, the DHCP server will not start until it is authorized in Active Directory. This is a good basic level of protection against innocent misconfiguration or low-skilled attackers who don't know better.

Most attackers are aware of this authorization requirement. They wouldn't use a Windows-based DHCP server for this type of attack. Numerous DHCP server software packages are available, including several that are free and many that run on non-Windows operating systems. These servers cannot be stopped by Windows Server 2003, as they do not check for authorization before leasing addresses.

To detect when an attacker has introduced a rogue DHCP server to the network, you must use an automated network monitoring package. This package should be configured to search for DHCP Offer packets on the network that originate from a network address that's not on your list of approved DHCP servers. Currently, Microsoft doesn't offer such an automated package. Microsoft's Network Monitor does allow network monitoring capabilities, but it does not have the ability to intelligently monitor for specific events and notify an administrator when those events occur.

Microsoft also provides a little-known tool, Dhcploc, to help identify DHCP servers. It is not installed with Windows Server 2003 but can be found on the installation CD in the \Support\Tools directory. It is a simple command-line tool that periodically sends out DHCP Discover packets and compares all DHCP Offers it receives against a list of authorized DHCP servers. If an offer comes from a server not on the authorized list, Dhcploc sends a network pop-up message to a specified user or computer. Although limited in its use and scalability, this tool can be useful for spot-checking your network.

The best prevention against attacks based on unauthorized DHCP servers is to ensure the physical security of your network. I discussed physical security earlier in the book in Chapter 3 as an essential foundation to any secure network. In this case, physical security is really the only significant prevention against the rogue DHCP server.

Shortening the DHCP lease times on your authentic DHCP servers does not help prevent or recover from this type of attack. The attacker configures the lease time for her rogue DHCP server leases, which may cause the clients to hold those bogus leases for a long time. The best way to recover clients with rogue leases is to use IPConfig /release and IPConfig /renew to obtain a new DHCP lease (or have them reboot).

11.1.2.6 Eliminating DHCP

I would be remiss if I didn't present the notion of eliminating DHCP from your network. There are three ways client computers can obtain IP addresses:

DHCP
Static TCP/IP configuration
APIPA

The only option I haven't discussed so far is Automatic Private IP Addressing (APIPA, often called Autonet). When a Windows client computer fails to obtain a DHCP lease and has no static or alternate TCP/IP configuration, APIPA takes over. It assigns an IP address in the 169.254.x.y range, where x and y are random numbers. Windows then ARPs for the address to ensure it's not in use before allowing TCP/IP to begin communication with this address. No configuration information is obtained from the network, so external communication is usually unavailable.

APIPA is obviously not a great option for any but the smallest of organizations, and even then it's usually not functional enough to be a viable option because it cannot configure client options such as default gateways and nameservers. Static configuration is, as discussed earlier, an option but has significant drawbacks in cost and scalability. So in most cases DHCP must be used to administer network addresses.