DHCP Server Security

[patris1]

http://www.windowsecurity.com/articles/DHCP-Security-Part1.html

Mitch Tulloch

PART-1

Although DHCP servers are critical to the operation of most enterprise networks, DHCP server security is often one of the most overlooked areas of network security. One reason for this might be the simplicity of how DHCP works: DHCP clients broadcast discovery messages (DHCPDISCOVER) containing their MAC addresses and DHCP servers respond by offering (DHCPOFFER) to lease an IP address and other TCP/IP settings that the client can use to communicate on the network. The client responds (DHCPREQUEST) to the first lease offer it receives and the server acknowledges (DHCPACK) the request and marks the address as leased in its DHCP database. That's all there is to it—who needs to worry about security?
Attacking DHCP

Unfortunately it's the very simplicity of DHCP that's actually the problem as far as security goes. No authentication or authorization takes place during an exchange between a DHCP server and DCHP client, so the server has no way of knowing if the client requesting the address is a legitimate client on the network, and the client has no way of knowing if the server that assigned the address is a legitimate DHCP server. The possibility of rogue clients and servers on your network can create all kinds of problems.
For example, a rogue DHCP server could provide legitimate clients with bogus TCP/IP information that prevents the clients from communicating on the network. A denial of service (DoS) condition then results, and users are unable to connect to network resources to perform their work. Setting up a rogue DHCP server could be as simple as conducting a social engineering attack to gain physical access to your network and plugging in a laptop configured as a DHCP server.
Another scenario might involve an attacker compromising a client computer on your network and installing software that repeatedly requests new IP addresses using spoofed MAC addresses until the entire pool of addresses in your DHCP server's scope is leased. When this happens, legitimate clients that boot onto the network can't acquire an address and again users are unable to access the network and can't do their work.
A more sinister result happens when an attacker breaches network security and gains control of your own DHCP servers. At that point the attacker might proceed to modify the DHCP server to assign clients an incorrect subnet setting and thus create another DoS condition. Or they might modify the server to assign clients incorrect DNS settings and redirect clients to rogue or hijacked DNS servers, which could then redirect clients to hostile websites where they unknowingly download a trojan. Or they could modify the server to assign the address of the attacker's own machine as default gateway, which results in outbound client traffic being redirected to the attacker's machine which captures and reads the traffic and forwards it to the real default gateway. The result is exposure of sensitive business information without users even being aware of what's happening.
Worse yet, if you're running your DHCP server on a domain controller then an attacker who compromises your DHCP server gains access to your accounts database and can cause all sorts of further problems. The result is usually your worst nightmare. Fortunately, there are some measures you can take to protect your DHCP servers and avoid many of these scenarios, provided you're also following all the usual best practices for securing Windows-based networks. Let's look at some specific threats to DHCP on your network and the countermeasures you can take to mitigate these different threats.
Threats and Countermeasures

On the face of it, the requirement that Windows 2000 and Windows Server 2003 DHCP servers be authorized in Active Directory before they can start leasing addresses to requesting clients seems to mitigate the threat of rogue DHCP servers on your network. Authorization means that when a Windows 2000 or Windows Server 2003 DHCP server boots onto an Active Directory network it first contacts a domain controller to check if its own IP address is found on the list of authorized DHCP servers maintained by the domain controller. If the DHCP server determines that it is authorized to lease addresses to clients, it begins to do so. If it's not authorized, Windows shuts down the DHCP Server service on the machine so it won't be able to lease addresses.
The real benefit of this is to protect your network against legitimate DHCP servers that are badly configured, though it has the added side effect of guarding against accidental or rogue DHCP servers running Windows 2000 or Windows Server 2003. What happens though if an attacker compromises your network with a rogue DHCP server not running Windows 2000 or Windows Server 2003? In this case authorization won't help because non-Microsoft DHCP servers may not respond the same way as Microsoft ones to the DHCPINFORM messages Windows uses to check if DHCP servers are authorized. Even Windows NT DHCP servers fall under this category, so an attacker with a laptop running Windows NT as a rogue DHCP server gets away scott free. Fortunately there are other ways to detect rogue DHCP servers and we'll look at these in Part 2 of this article later. But making sure your DHCP servers are properly authorized is still an important first step in deterring rogue servers on your network.
Rogue clients is another problem entirely though, as DHCP is designed to make it easy for clients to obtain IP addresses so they can participate on a network. The obvious way of dealing with the problem of rogue clients would seem at first to be DHCP reservation, though on large networks this entails considerable administrative overhead. A reservation is a predefined setting that maps a MAC address to an IP address so that only a client with a particular MAC address can lease the IP address associated with that reservation. If security is critical an administrator could create reservations for each and every client machine on the network, and if unreserved IP addresses still remain in the DHCP server's cope then these could be reserved using invalid or non-existing MAC addresses. Then when a rogue client tries to boot on the network the result is that the DHCP server has no free addresses to lease and the client can't connect.
If only it were that simple. While this approach might foil a casual attack, sophisticated attackers have ways for circumventing DHCP reservations. The simplest approach is for the attacker to run a program that listens for DHCPDISCOVER broadcasts from clients and harvests their MAC addresses. Then when a legitimate client shuts down the rogue client can reconfigure its MAC address to match that of the legitimate client and hijack the legitimate client's lease or try to disrupt communications for the client. Considering this, security-conscious administrators might consider dropping DHCP entirely in favor of static addressing, but what's to stop an attacker who has physical access to your network from assigning a static address to their own machine and joining the network? One might go further and install a firewall on every client on your network and configure it to only allow communications with allowed IP addresses of legitimate clients, but imagine the administrative headache that would involve. So the bottom line is that the only way to really protect your network against rogue DHCP clients (and also rogue DHCP servers) is rigorous physical security i.e. no unsecured wall jacks, locked doors, staff trained to recognize social engineering attempts, and so on.
Even if your network is physically secure however, it also needs to be secure from a network entry point of view. If an attacker can penetrate your perimeter defenses and somehow compromise a DHCP server, then several kinds of exploits could be attempted including modification of DNS resource records when Dynamic DNS (DDNS) is being used, corrupting the DHCP database, and gaining access to sensitive information such as the details of your network's addressing scheme and reserved addresses of critical servers. Basic security best practices like perimeter firewalls and intrusion monitoring are clearly your front line in preventing your DHCP servers from being compromised, but there are also some DHCP-specific monitoring procedures you can follow which we'll look at in Part 2 of this article later.
Summary

Let's look at our list so far of best practices for ensuring DHCP security on your network. We'll add to this list further in Part 2 with some specific steps you can follow on Windows-based networks, but for now be sure to start at least with the following if you want to protect your network against DHCP exploits:

• Implement rigorous physical and perimeter security for your network and be vigilant in maintaining such security.
• Upgrade any lingering Windows NT domains so you can make use of the DHCP server authorization feature of Active Directory.
• Avoid using Windows 2000 or Windows Server 2003 domain controllers as DHCP servers.
• Use reservations for assigning addresses of critical servers on your network, or use static addresses for them instead.

In Part 2 of this article we'll continue by discussing how to enable auditing on DHCP servers, monitor membership in the DHCPAdministrators group using the Restricted Groups feature of Windows Server 2003, ensure that DNS works securely with DHCP, and use various tools to detect rogue DHCP servers on your network

---

موضوعات مشابه:

• راه اندازی dhcp server با تجهیزات سیسکو و تفاوت آن با dhcp مایکروسافت
• آموزش DHCP Server ( سرور DHCP چیست؟)
• How to Install and Configure Windows Server 2008 DHCP Server

---

[patris1]

http://www.windowsecurity.com/articles/DHCP-Security-Part2.html

PART-2

In Part 1 of this two-part article we looked at the different types of threats faced by DHCP servers and outlined some general countermeasures for mitigating these threats. Part 2 continues with a list of practical steps administrators can follow and tools they can use to help secure their Windows 2000 and Windows Server 2003 DHCP servers.
As we discussed earlier in Part 1 of this article, DHCP is inherently insecure and your first line of defense for protecting yourself from rogue DHCP servers and clients is rigorous physical security for your network. Fortunately Windows 2000 and Windows Server 2003 do support some features you can use to enhance DHCP security, and there are some tools you can use to detect rogue DHCP servers on your network so you can eliminate them. Let's look at each of these features and tools now.
DHCP Server Auditing

Auditing the DHCP database on your DHCP servers lets you determine which DHCP clients on your network are leasing addresses from your server. Auditing also lets you look for BAD_ADDRESS entries in the database and see where they originate, and this is important because such entries can indicate address conflicts arising when rogue DHCP servers assign addresses that are already in use. Such address conflicts can also arise if a rogue client has a static address that is within the scope of a legitimate DHCP server, or when you accidentally configure two DHCP servers to have overlapping scopes. Whatever the cause, BAD_ADDRESS entries indicate some kind of problem, whether misconfiguration or a security hole, that needs to be addressed.
To enable auditing on your DHCP servers, open the DHCP console and connect to a DHCP server on your network. Then right-click on the server node and select Properties, and on the General tab make sure the checkbox labeled "Enable DHCP audit logging" is enabled:

Figure 1: Enabling DHCP audit logging

DHCP audit logs are stored by default in the %windir%\system32\dhcp directory, but this can be changed using the Advanced tab of the DHCP server's properties sheet. DHCP audit logs are created or appended on a daily basis and are named DhcpSrvLog-Mon.log, DhcpSrvLog-Tue.log, and so on. Each log entry begins with an event ID, and the header of the log contains a list of possible event IDs together with an explanation of each one. Further configuration can be performed using the HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\ Parameters key in the Registry where the following keys control how DHCP logging works:

• DhcpLogFilesMaxSize specifies a maximum file size for all DHCP log files (default is 7 MB)
• DhcpLogDiskSpaceCheckInterval specifies how frequently DHCP checks disk space usage (default is every 50 minutes)
• DhcpLogMinSpaceOnDisk specifies the free space threshold below which logging becomes temporarily disabled (default is 20 MB)

DHCP Administrators Group

While members of the Domain Admins group obviously have full power to configure DHCP on the server, you can also delegate limited power to users whose job is to manage DHCP servers on your network. To do this, open Active Directory Users and Computers and add the name of the user to the DHCP Administrators domain local group:

Figure 2: Adding user Bob Smith to the DHCP Administrators group

This gives the user the ability to manage DHCP servers on your network without giving him any unnecessary authority to perform other administrative tasks, which is an example of the well-known security best practice of least privilege. The problem however is, how do you monitor membership in the DHCP Administrators group to make sure no unauthorized users are accidentally (or maliciously) added to the group?
You can monitor membership of critical groups like DHCP Administrators using the Restricted Groups feature of Group Policy. To do this, first use Active Directory Users and Computers to open your Default Domain Policy (or some other GPO if the computer accounts for your DHCP servers were placed in some OU in your domain) and navigate to Computer Configuration\Windows Settings\Security Settings\Restricted Groups:

Figure 3: Restricted Groups

Now right-click on the Restricted Groups node and select Add Group, and specify DHCP Administrators as the group whose membership you want to monitor:

Figure 4: Monitor membership in the DHCP Administrators group

Click OK and use the Add button in the next properties sheet to specify which users are allowed to be members of this group. Note that even if the group already has members in it, you still have to perform this step and identify them again:

Figure 5: Bob Smith is the only user allowed to be a member of the DHCP Administrators group

Now click OK and membership in the DHCP Administrators group is restricted to only Bob Smith as desired:

Figure 6: Membership in DHCP Administrators has been restricted to Bob Smith

What happens now is that when Group Policy refreshes on your domain controllers (typically every 5 minutes) membership in the DHCP Administrators group is checked, and if by accident (or malicious intent) some other user like Mary Smith has been added to the group then she will automatically be removed and an ID 637 event will be logged to the Security log if you have auditing of account management events enabled. Membership in the DHCP Administrators group is thus monitored and controlled as desired.
NOTE:Windows 2000 also includes another group called DHCP Users which can be used to grant users read-only access to the DHCP console, and membership in this group can be similarly controlled using Restricted Groups.
DNSUpdateProxy Group

On Windows-based networks, DHCP and DNS can work together to simplify the configuration and operation of your network. Normally what happens is a DHCP client register its A (host) record directly with the DNS server, while the PTR (pointer) record is instead registered on behalf of the client by the DHCP server. This means an attack on a DHCP server could compromise control over records registered with your DNS server and be used to redirect traffic to a hostile site or cause denial of service. If you make a DHCP server a member of the DNSUpdateProxy group however, your DHCP server will not take ownership of any resource records it registers on behalf of clients. This approach is typically used when upgrading from Windows NT to ensure downlevel clients that do not support DDNS can take ownership of their own resource records when they are upgraded to Windows 2000 or Windows XP.
The point is that you should only add the computer accounts for your DHCP server to the DNSUpdateProxy group if you are going to be upgrading pre-Windows 2000 computers to Windows 2000 or Windows XP. And you should never add your DHCP server to this DNSUpdateProxy group if your DHCP server is running on a domain controller.
Detecting Rogue DHCP Servers

Finally, there are a few tools you can use to detect the presence of rogue DHCP servers on your network so you can get rid of them. These include both tools from Microsoft and from third-party sources, and we'll end by examining two of these tools.
Dhcploc.exe
Dhcploc.exe is a command-line tool that is part of the Windows Support Tools found in the \Support\Tools folder on your Windows XP product CD and it can be used to display all DHCP servers that are active on the local subnet. Dhcploc.exe has been around since Windows NT 4.0 and it works by sending out DHCPREQUEST messages and displaying the IP addresses of the DHCP servers that responded with DHCPACK. You can find the syntax of this tool in the Help file that is installed when you install the Support Tools on your machine.
dhcp_probe
The Network Systems Group at Princeton University's Office of Information Technology has developed a tool called dhcp_probe that tries to discover DHCP and BOOTP servers on a directly-attached Ethernet network. The existing build runs on Solaris 8 on SPARC with gcc and there is patch for it to work on Linux also, so if you have either of those platforms you can try using this tool to detect any rogue DHCP servers that might be running on your network. You can find the Network Systems Group's tools page here and can download dhcp_probe directly from here.
Summary

In this article and the previous one I've examined why DHCP is intrinsically an insecure protocol and what you can do to secure it on Windows-based networks. Even if you implement the best practices I've suggested for securing DHCP, review your DHCP audit logs regularly, run Dhcploc.exe or other tools regularly to locate rogue servers, restrict membership in the DHCP Administrators group, and make judicious use of the DNSUpdateProxy group, it's pretty clear that DHCP still remains a weak point in your network's overall security landscape. What does the future hold then for DHCP security?
Since 2003 the Internet Engineering Task Force (IETF) is working on this problem, and is working on a proposed standard, RFC 3118 Authentication for DHCP Messages. This RFC suggests a couple of extensions for DHCP to provide for authentication of DHCP messages on your network using either a token-based exchange of messages or a shared symmetric key. The problem with these extensions however is that they require some additional initial configuration of the DHCP client, and the whole point of why DHCP was developed in the first place was to get away from having to pre-configure clients before they can participate on the network. So this solution would probably only be acceptable to enterprises if vendors could pre-configure machines at the factory level, and so far no vendors have taken on the task of implementing this solution.
On the other hand, IPv6 may offer a simpler solution to the problem of DHCP security. Since IPv6 is designed with end-to-end security from the ground up, it can protect DHCP traffic and make it more difficult for attackers to spoof DHCP messages or hijack DHCP traffic. Since the U.S. Department of Defense (DoD) is mandating use of IPv6 on all their networks in the near future, vendors are scrambling to make their hardware and software support IPv6 and this may drive enterprise adoption for IPv6 sooner than previously anticipated. When that happens, network security experts will probably have to revisit the whole question of DHCP security all over again and develop tools and best practices to ensure 21st century networks remain secure in an increasingly hostile cyberworld