Detecting a Rogue DHCP Server

Win2K's DHCP service protects your network from imposters

DHCP server is a useful tool that automates the assignment of IP addresses to hundreds of workstations in your network. The server maintains a pool of IP addresses that you use to create scopes. (A DHCP scope is a collection of IP addresses and TCP/IP configuration parameters that are available for DHCP clients to lease.) Then, the server automatically allocates these IP addresses and related TCP/IP configuration settings to DHCP-enabled clients in the network. The DHCP service leases the IP addresses to clients for a period that you specify when you create a scope. A lease becomes inactive when it expires. Through the DHCP server, you can reserve specific IP addresses permanently for hardware devices that must have a static IP address (e.g., a DNS server).

An advantage of using DHCP is that the service assigns addresses dynamically. The service returns addresses that are no longer in use to the IP address pool so that the server can reallocate them to other machines in the network. If not for this service, you would have to manually configure IP for new computers, keep track of IP addresses so that you could reassign addresses that clients aren't using, and reconfigure computers that you move from one subnet to another.

An authorized DHCP server can save you a lot of time and effort by eliminating the need to manually track and assign IP addresses for each client on your network. (Administrators of small networks can enjoy the benefits of DHCP through Windows 2000's Automatic Private IP Addressing—APIPA—service. For information about this feature, see the sidebar "Automatic Private IP Addressing.") But beware—an unauthorized (aka rogue) DHCP server can cause problems on your network by assigning incorrect IP addresses, incorrect lease terminations, missing or incorrect DHCP options, or duplicate IP addresses. A rogue DHCP server is a misconfigured or unauthorized server that is usually introduced to the network accidentally by a user experimenting with a DHCP server. However, a malicious operator can also introduce a rogue DHCP server.

When a rogue DHCP server leases incorrect IP addresses to clients, the clients can fail to locate valid domain controllers (DCs), which prevents the clients from successfully logging on to the network. In addition, a rogue server might turn down DHCP clients' requests to renew their current leases. Under usual circumstances, the DHCP service grants renewals when clients request them.

To prevent rogue DHCP servers from infiltrating your network and causing these types of problems, the Win2K DHCP service includes a conflict-detection feature. To comprehend how a Win2K DHCP server detects rogue DHCP servers, you must be familiar with how transactions pass between the client and server, as well as understand the server authorization process.

Client and Server DHCP Transactions
The first time that a DHCP client attempts to log on to the network, it initiates a request for an IP address by broadcasting a DHCPDiscover message to locate a DCHP server. The client doesn't have an assigned IP address, so the client sends an IP address of 0.0.0.0 with the DHCPDiscover packet.

All the DHCP servers in the network, including rogue DHCP servers, reply to the DHCPDiscover message with a DHCPOffer message that contains an unleased IP address and IP configuration information, such as the subnet mask. To accept the settings that the first server to reply offers, the client broadcasts a DHCPRequest packet to the DHCP server.

To acknowledge the client's acceptance of the IP address, the selected DHCP server responds with a DHCPAcknowledge packet (aka a DHCPAck packet). After the client receives this packet, it can participate in the TCP/IP network.

If a problem exists with the assigned IP address (e.g., the IP address is no longer available because another client is using it), the DHCP server sends the client a DHCPNak packet. When a client receives a DHCPNak packet, it must begin again the process to locate an available IP address. If a rogue DHCP server has leased the client an incorrect IP address or subnet mask, the DHCP client won't be able to successfully log on to the network.

A DHCP client can send two additional packets to DHCP servers. If a client determines that the offered configuration parameters aren't valid (e.g., if the client discovers that another client has the IP address that the DHCP server has offered), the client sends the DHCP server a DHCPDecline packet. The client then starts at the beginning of the IP address location process. To release its current IP address and cancel the remaining lease, a client sends a DHCPRelease packet to the server. For more information about DHCP messages, scopes, and the lease process, see "Related Articles in Previous Issues."

Detecting Address Conflicts
By default, the Win2K DHCP service doesn't perform conflict detection because each conflict detection attempt adds time to the IP address lease negotiation between clients and servers. In addition, conflict detection is usually not necessary. However, if you suspect that DHCP servers are assigning duplicate addresses on your network (e.g., if clients can't log on to the network for a time and are later able to log on with no problems), you might want to enable conflict detection for troubleshooting purposes.

If you enable conflict detection on a Win2K DHCP server, the server pings an IP address before offering that address to a client. If a computer in the network responds to the ping, the server detects a conflict and doesn't offer the address to another client in the network. In addition, the server attaches a BAD_ADDRESS value to that IP address, then attempts to lease the next available address after checking for a conflict. The server removes the BAD_ADDRESS value from the IP address when the address becomes available again. DHCP servers don't ping IP addresses for clients requesting a renewal of their IP address leases.

To enable conflict detection, right-click the DHCP server in the console tree of the Microsoft Management Console (MMC) DHCP snap-in, and select Properties. On the Advanced tab of the server's properties dialog box, which Figure 1 shows, input a number greater than 0 in the Conflict detection attempts box. This number specifies how many times the DHCP server will ping an IP address to determine whether a conflict exists before the server offers the IP address to a client. Each ping delays the DHCP server response by 1 second. Microsoft recommends that you input a value of 2 or less.

Win2K clients can also check for IP address conflicts. If a client detects a conflict, the client sends a DHCPDecline packet to the DHCP server. As occurs in server-side conflict detection, the server then attaches a BAD_ADDRESS value to the IP address in the scope.

Authorizing a Win2K DHCP Server
When you're planning your DHCP server, you must consider which name-resolution service to implement. For Win2K networks, the DNS service is necessary for general name resolution and Active Directory (AD) support. Windows NT 4.0 and earlier clients must use WINS servers for this support. If your network supports a combination of Win2K and NT 4.0 clients, you must implement both DNS and WINS.

You must authorize DHCP servers in the directory service before they can provide DHCP services to clients. For authorization to take place on your network, you must ensure that the first DHCP server that you introduce to the network participates in AD. Thus, you must install this DHCP server in a domain—not a workgroup—on either a Win2K member server or DC. This setup causes AD to create DHCP as an object (i.e., the DhcpServer object). After you define a scope, you can authorize a Win2K DHCP server by selecting Activate from the Action menu of the DHCP snap-in, which Figure 2 shows. You must have enterprise administrator rights to authorize a DHCP server in AD.

The DhcpServer object provides two functions: This object maintains the list of your network's authorized DHCP servers by IP address, and it detects rogue Win2K DHCP servers and prevents them from participating in your network IP address allocation transactions. This built-in integrity security support, called Rogue DHCP Server Detection, is automatically enabled as long as AD is in place. Thus, if you forget to activate a new DHCP server, an authorized DHCP server will report the new server as a rogue.

Detecting Rogue Win2K DHCP Servers
The Win2K DHCP service uses the following process to detect DHCP servers running in the network and determine whether AD has authorized the servers to provide DHCP services. When you first start the DHCP service, the service uses the local limited broadcast address (i.e., 255.255.255.255) to broadcast a DHCPInform message to the network. This action locates the enterprise root directory of the other DHCP servers in the network. They acknowledge the query and reply to the initializing DHCP server (e.g., the first DHCP server that you install in the network) with a DHCPAck message that contains enterprise root directory information. The initializing DHCP server uses the information in the DHCPAck messages to compile a list of the active DHCP servers in the network as well as the root of the directory service enterprise that each of the servers uses. If the initializing DHCP server detects more than one enterprise root, the server queries each of the additional roots to check for DHCP service authorization in the other enterprises.

After the initializing DHCP server builds a complete list, the server determines whether AD is available on its local computer. If the service is available, the server determines whether you have authorized the server to run in the network. If the directory service isn't available, the server provides DHCP services as long as it doesn't discover another DHCP server in the network.

After the DHCP server starts, it sends DHCPInform messages every 5 minutes to collect information about other Win2K DHCP servers in the network. Each time the server sends the DHCPInform message, the server also determines whether the AD service is available.

If a DHCP server is running on a member server or DC, the server queries the AD service for the authorized list of DHCP server addresses. If its IP address is on the authorized list, the server begins providing DHCP service to clients. If the server doesn't find its IP address on the authorized list, it shuts itself down (i.e., the DHCP service shuts down automatically).

If the DHCP server is running on a standalone server, the server queries each of the DHCP servers in the network for their enterprise roots. The server then queries the directory service and includes in the query the enterprise root that each DHCP server in the network returned. If the DHCP server on the standalone system discovers its IP address in each of the enterprise roots that the other DHCP servers return, it begins providing DHCP service to clients. If not, the DHCP server shuts down.

When an unauthorized or rogue Win2K DHCP server shuts itself down, the Event Viewer on the local server lists event ID 1051. In the event's properties dialog box, which Figure 3, page 95, shows, Event Viewer provides the following event description: "The DHCP/BINL service has determined that it is not authorized to service clients on this network for the Windows domain: name of Windows domain."

Sniffing Out a Rogue
Microsoft designed unauthorized Win2K DHCP servers to shut down to prevent rogue servers from participating in Win2K network transactions. However, this functionality doesn't safeguard mixed networks from rogue DHCP servers. If your network includes NT Server systems or third-party DHCP software, the potential for a rogue DHCP server to infiltrate your network still exists.