DHCP starvation and DHCP spoofing attacks expose networks to denial-of-service and man-in-the-middle threats that can disrupt client connectivity and intercept traffic. DHCP snooping is a switch-level security feature that filters illegitimate DHCP messages by classifying ports as trusted or untrusted and validating message content against a binding database.
DHCP Security & Snooping
Dynamic Host Configuration Protocol, or DHCP, is a way for DHCP clients to get IP addresses from a DHCP server. DHCP has some inherent problems in it that an attacker can leverage to do harm to a network, but DHCP snooping allows us to mitigate against many of those issues.
A DHCP starvation attack is when an attacker asks for more and more IP addresses to the point where it uses up all of the available IP addresses on a network. The DHCP server has no more IP addresses to hand out, so new clients that access that network can no longer get IP addresses. It's a type of denial of service attack.
There are two ways to mitigate against that. One is port security, which we already covered. It mitigates it because the attacker client can only ask for so many IP addresses until it gets shut off, because it only has so many MAC addresses it can register on that port. The other way to mitigate against this is DHCP snooping.
The other thing an attacker can do is use DHCP spoofing. Spoofing means that it's mimicking a DHCP server. An attacker can get onto the network, create a rogue DHCP server — that's a DHCP server that's not supposed to be on the network — and do its own configuration on that network. It can then leverage that to either do a denial of service attack on the network, or use it to stage a man in the middle attack on the network.
When a client joins a local area network it needs some information on how to communicate with that local area network. It needs an IP address, a mask, a default gateway, a DNS server and possibly some other information. So it will send out a message asking for a DHCP server to give it some information so it can fill this in. This is a broadcast that goes to the rest of the network, and any DHCP server can respond to it. What an attacker can do is respond to it with its own information, giving the client bad information, and this does a couple of different things.
First of all, one reason why an attacker can get away with this is that a client machine usually responds to the first DHCP server that it receives an offer from. So as long as the attacker responds before a true, trusted DHCP server on the network responds, this client is going to get the information from the attacker instead.
The attacker could give a wrong IP address, a wrong mask, a wrong default gateway, and that could all lead to a denial of service — giving it the wrong information so that machine can't connect properly to that network. The other thing it could do is give it the wrong default gateway or the wrong DNS. In fact, it could give it the DNS or default gateway of the IP address of the attacking machine, and then all of the packets that are destined for the outside world would go to this attacker, or all DNS queries would go to this attacker. Rather than giving the correct information, what the attacker is going to do is be able to monitor that traffic that's going across it. For instance, if it's the wrong default gateway, all of that traffic will go to this attacking machine, and this attacking machine will go and get the correct information and pass it along, but is able to do a man in the middle attack, taxing all the traffic that's coming across that network to that client machine.
That is DHCP spoofing: a rogue DHCP server on the network, mimicking an actual DHCP server, to conduct either a denial of service attack or a man in the middle attack. The tools to use this really could be any DHCP server. In fact, I had launched a DHCP spoofing attack unknowingly on a network before — in fact I think I've done it multiple times, where I've connected a router up to a network where it wasn't supposed to be handing out IP addresses, and it did hand out IP addresses on that network, causing problems. So some of these could be unintentional: you have made a mistake on that network, made a configuration error, and caused problems on that network. DHCP snooping can not only address the internal attackers that are maliciously going after your network, but even sometimes when it's accidental as well.
DHCP is going to be what we're going to turn on in our network, so that way our network devices can start looking at messages — specifically DHCP messages — to find out if they should be getting rid of those messages or forwarding those messages.
In our example right here, this is our network, and we're going to say that this demo Pi 2 is going to be our DHCP server. What we're going to do is take a look at how DHCP snooping will allow things like this DHCP server to send out messages and allow clients to request information, but also get rid of the illegitimate DHCP messages that are on our network.
One thing that we'll have throughout this process is trusted ports and untrusted ports. Trusted ports are going to be those of our devices that are going to be legitimate sources for these DHCP messages. For instance, we said this demo Pi 2 is going to be the DHCP server, so we're going to want this to be on a trusted port on this switch, because it is acting as the DHCP server. If we were to have this untrusted, it would block those messages, and that's not going to be what we want.
By default, when we turn on DHCP snooping — and we'll turn that on on our switches — what will happen is that all of the ports on that switch are going to become untrusted when it comes to DHCP snooping. So then what we'll have to do is go back to the ports that we want to trust and mark them as trusted.
When we turn on DHCP snooping on our network, one thing that's going to be created is a DHCP snooping binding database. It's going to be one of the things that's going to help identify whether DHCP messages going across this network are legitimate or not. It actually plays a pretty small role; it doesn't play a big role in identifying these messages. We'll see how that plays out, but we'll actually use it more when we do things like Dynamic ARP Inspection. Know that this is an important database that gets created, although it's not going to be huge when it comes to DHCP snooping.
The DHCP snooping binding database is going to keep track of IP addresses, MAC addresses and ports on each of the switches. It keeps track of what these messages contain — the IP, MAC address and port — and if something doesn't jive, if something doesn't add up. For instance, let's say the MAC address and the port are accurate but the IP address is not, or the MAC address and the IP address don't line up. If there is some sort of inconsistency, then it will allow it to identify messages that are not legitimate messages on your network.
Here's a list of the DHCP snooping rules and how it's going to determine if it's a legitimate message or not.
First of all, what it's going to do is take a look at the port that it is coming in on and ask: is it a trusted port? If it's a trusted port, that DHCP message is going to go through. It's going to assume that the message is trusted because the port is trusted. So once again, if this demo Pi is our DHCP server and the server messages are coming in on this port, we're going to want to trust that port that that's coming in on, so that way those DHCP messages can go out.
If it's coming in on an untrusted port — so the client machine is connecting to the switch — it needs to legitimize the messages and make sure that they're legitimate. First of all, it's going to ask if this is a server message. That means the DHCP offer, the messages that you would see coming from the server. If it is the messages that you'd see coming from a server on an untrusted port, it's going to block those messages; it doesn't allow those messages to go through. So all DHCP servers need to be on a trusted port.
Next it asks, if it's not a server message, it is a client message — those like the discovery or the request. If it's one of those messages, then what it's going to do is measure it up against a few other items here in our rules.
First of all, is there a rate limit? There are rate limits that we can put on our different ports on our switches, and what that does is it allows for a single client to not over-ask, to not make too many DHCP requests, or to just overwhelm the network with all these DHCP responses. So it's going to rate limit it. Now, this is a setting that we can choose to implement or not implement.
The next thing is the type of message it is. Is it a discover or request message as part of the normal requesting of an IP address, or is it a release or decline, and it's sending out release and decline messages? If it's a discover or request message — the typical client is going to go out and make a discovery and a request for certain IP address information — then what it will do is take a look at the frames and make sure that inside the frame the layer 2 MAC address is going to line up with the information in the DHCP discovery or request. There is some information in the actual request that lists out the MAC address again. Does that MAC address line up with the frame MAC address, to make sure those are the same? The specific field is the chaddr field right there. If you look at the communication with this DHCP process, that's a field that's in there, making sure that field binds up with the actual frame. If those line up, then chances are it's more likely that that's going to be a legitimate request and not something that's illegitimate.
The next thing is this release and decline. What can happen is that if an attacker gets onto your network, it can make a release or decline for another client that's on the network. If it were to do that, then you would get some sort of denial of service attack, because this client could no longer access that network if that information is handed out to another device on the network. So in this case, if it's a release or decline message that's being sent out from the client, then it's going to match it against this DHCP snooping binding table. That's where that table comes into play: if it's a release or decline, it's going to take a look at that table and then make a determination. If it doesn't line up with the information in the table, then it's going to say this is not a legitimate request, and so we're going to drop that frame and not forward on that frame.
Once again, DHCP snooping is looking at DHCP messages, so it's mitigating attacks against DHCP messages and DHCP vulnerabilities specifically, although we are going to take a look at that binding table when it comes to other types of attack mitigation as well.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →