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,184.108.40.206,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,220.127.116.11,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,18.104.22.168,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,22.214.171.124,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,126.96.36.199,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,188.8.131.52,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 13th, 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!
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:
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.
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.
TIP: 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.
Monitoring the network for unauthorized DHCP servers
So far we've seen how to protect your authentic DHCP servers from attackor, more precisely, how to detect an attack as quickly as possible. But there is another common attack that these defenses do not protect againstwhen 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.
TIP: 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 /renewto obtain a new DHCP lease (or have them reboot).
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:
Static TCP/IP configuration
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.
Mike Danseglio is a program manager in the Security Solutions group at Microsoft Corporation.
View catalog information for Securing Windows Server 2003
Return to the Windows DevCenter.