Securing Your Network From DHCP Risks
- 29 Oct 2018
- 2 Minutes to read
-
Contributors
-
Print
-
DarkLight
-
PDF
Securing Your Network From DHCP Risks
- Updated on 29 Oct 2018
- 2 Minutes to read
-
Contributors
-
Print
-
DarkLight
-
PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
Like many basic Internet protocols, DHCP was not originally designed with a robust security model, but was designed for simplicity of implementation and ease of deployment. Care should be taken in networks that use DHCP to avoid common security pitfalls.
Problem 1: Rogue DHCP Servers
A substantial part of the appeal of DHCP is that clients joining a network require no a priori knowledge of the network. They advertise (via a DHCPDISCOVER packet) to find a DHCP server and, assuming all goes well, receive their configuration information from that server and join the network as fully functioning clients. While this is very desirable behavior as far as ease of deployment is concerned, from a security standpoint it is problematic that client machines, having no pre-existing knowledge of the network, cannot distinguish between a response from a server which is authorized by the network's administrator and another machine which, for whatever reason, responds to their DHCPDISCOVER with a DHCPOFFER. Malicious servers can offer a client an invalid IP address that will not be properly routed, which amounts to an obvious denial of service against the client, or can instruct the client to use as its nameservers and default router machines which are controlled by the same entity, allowing that opportunity the possibility of scanning and/or capturing traffic that the client machine sends via the default route.
Solution: Use Switch-Based DHCP Control Mechanisms
There is essentially no remedy for this threat in the DHCP protocol, so mechanisms to prevent rogue DHCP servers are typically designed to operate at other layers of the network protocol stack. Protocol-aware managed ethernet switches from a number of manufacturers offer effective strategies to block DHCP responses from rogue servers. Feature names may vary from manufacturer to manufacturer, but they are sometimes collectively referred to as "dhcp snooping" features, after the name used by Cisco for its implementation.
Accidental Rogue ServersIt's not even necessary that a rogue server be malicious in intent to cause substantial disruption to a network. In fact, probably the most common rogue server scenario usually occurs accidentally. In networks where customers are allowed to connect their own equipment to the network, it is a relatively common occurrence to have an inexperienced user connect the wrong port of an appliance-type device, such as a home or small office router that has DHCP server functionality, inadvertently exposing the network to broadcast DHCP responses from the device which will interfere with other clients' use of the network unless steps are taken to block unauthorized DHCP servers at the switch.
Problem 2: Exposure to Constructed DoS Packets.
Although ISC goes to significant lengths to review its code for correctness prior to release, occasionally defects are found in dhcpd that allow a malicious party to crash the server with a specially-constructed request, or cause other undesirable behavior. Though one still remains exposed to such requests from clients operating within the subnets served by the DHCP server, exposure to such attacks can be limited by configuring firewalls to block inbound requests to the DHCP server except for those that come from authorized relay agents or directly-served subnets.