Has anyone ever plugged a Cable/DSL router into your network without authorization? Those things have DHCP servers on by default, you probably know that. And you want DHCP at home, and for that matter at work, too. But only one per network, or things get nasty really fast! (There are some legitimate redundant DHCP configuration options but never involving a consumer appliance!)
But how do you stop these “rogue” DHCP servers from accidentally or intentionally wreaking havoc on your network if plugged in? There are a couple of options, all of which involve managed switches and I’m going to talk in particular about HP ProCurve switches since that’s what I have (and love). I know at least some Cisco and Dell switches have similar functionality, and likely others.
You could do something as extreme as locking down every port with MAC address security so the entire port will shut down if anyone plugs an unauthorized computer in. This isn’t a bad method, if you have your network fully documented, don’t make changes often, and want the extra management overhead. I have a Church IT friend here in Indianapolis who I know does just that…awesome! I lock down some ports like this–nursery checkin stations or public internet terminals primarily. But for the rest of the network, I finally got around to implementing something I knew existed but never had time to research until now: DHCP Snooping. The cool name is just a side benefit!
If your switch(es) support DHCP Snooping, it’s pretty easy to turn on, but you need to know a little about your network first. Specifically, you need to know:
- Which switch port(s) your valid DHCP server is connected to.
- Which switch port(s) are uplinks to other managed switches.
- What VLANs do you want DHCP Snooping protection enabled on?
- Optionally, what the IP address is of your DHCP server (or at least which IP is assigned to the server in each VLAN where you want DHCP Snooping enabled).
If you choose to configure the authorized DHCP server IP address(es) list, the switches will require the DHCP reply to come from one of the authorized IPs; if you don’t configure the list then only the switch port source matters.
Let’s review briefly how DHCP works at a high level. Computer or device is connected to the network and turned on. It sends a DHCP broadcast request to the local segment and a DHCP server that receives the request allocates an available IP address and replies with that IP to the requesting client device, which they has a “lease” on the IP until the expiration time defined by the server. At varying intervals before the lease expires, the client sends a renewal request to the originating DHCP server asking if it can keep the IP longer, and the server replies that (usually) yes it can and extends the expiration. The client has no idea what DHCP servers are available initially, hence the broadcast request. If there are multiple DHCP servers on the network that see the request, they will all respond, and the client just picks the one that responds fastest and discards the rest.
Because the client accepts the first DHCP reply it receives, a cable/DSL router will often “beat” the correct DHCP server to the reply in some percentage of cases, creating a difficult to troubleshoot problem (which can be subtle if the IP, subnet, DNS and gateway addresses issued by the rogue DHCP server are similar in many ways to the legitimate settings, and more pronounced if they differ entirely). Tracking down the source of an unknown rogue DHCP server usually involves digging into the switch address tables and mapping IPs to MAC addresses to switch ports–a fun exercise if you want to learn about how switches work and have plenty of free time, but otherwise quite annoying! Even if the rogue server is sending the correct IP/subnet/DNS settings, its list of “available IPs” to hand out is maintained separately from the valid DHCP server, and thus you will end up with two devices being issued the same IP at some point, causing an IP conflict which may lead you to discover the existance of the rogue DHCP device after you’ve finished pulling your hair out :-)
So what is DHCP Snooping? It’s just the switch forcing valid DHCP replies (not requests from clients–a DHCP reply is the server issuing an IP assignment to a client who requested one) to only come from valid DHCP servers that you specify and tell the switch about. Your DHCP server is plugged into a particular port on your switch. You configure DHCP Snooping to know that that port is “trusted” for DHCP replies. If a device is plugged into an untrusted port (all ports by default), if it tries to send a DHCP reply, the switch drops it, and it never goes anywhere! If all you have is one switch and one server, this is really simple. With multiple switches, it’s still simple but you do need to make the change on any switch where you enable DHCP Snooping. You’ll need to trust the port on a secondary switch that is the uplink to the switch where the DHCP replies will be coming from.
How about a brief example. Let’s say Switch 1 is your “core” network switch, and has your DHCP server plugged into port 1. Switch 2 is a secondary switch, and port 24 of Switch 1 is uplinked to port 24 of Switch 2. All the other ports on both switches have clients or other servers plugged into them, and let’s say you’re only using one flat VLAN (call it VLAN 1).
On switch 1, you need to tell it that port 1 is trusted so the DHCP server can send its replies on that port. You can optionally tell it port 24 is trusted since your other switch is connected to that port (and it’s a rogue DHCP server we hope!), but since it will only be sending DHCP replies out too the other switch and not have them coming back “in” the port, it’s not required. Switch 2 requires that you make port 24 trusted, since it will be receiving DHCP replies for its clients incoming on that port from the server that’s connected to Switch 1. In more complex networks, there may be reasons to have DHCP traverse both directions of an uplink port, and since switches are generally trusted to not randomly sprout internal DHCP servers, it’s probably easier to just make all uplink ports, regardless of direction, trusted for DHCP Snooping purposes. However, this only applies to uplinks to switches that support DHCP Snooping and have it turned on–don’t trust a port that has an unmanaged switch connected or one without DHCP snooping enabled, or any client on that switch can then send DHCP replies to any other client on the managed switch, defeating your entire protection! So only mark ports trusted if they are connected to a DHCP server or if they are connected to another switch which also has DHCP Snooping enabled.
Optionally, tell your switches the valid IP address(es) of the DHCP server so they can drop replies from invalid IP addresses, even on trusted ports. I did this only on my “core” switch rather than every one of my managed switches that supports snooping, just for ease of management.
Sounds great! How do you do it? Well I could post the mechanics but it’s been describe elsewhere very simply. You have to use the command line on ProCurve switches, not the command line menu or the web interface. Get to the command line, type “config” to enter configuration mode, and then follow the directions here (the article is good if you ignore the misspelled word “rogue” in the title):
Preventing Rogue DHCP Servers with HP Procurve Switches
Don’t forget to turn off option 82 per that article…I didn’t try leaving it on but it works for me with it turned off. You may need to check this out in more detail if you’re doing any sort of multi-VLAN setup with routing where you use DHCP Relay to get other subnets to the DHCP server, I haven’t tested that. And I’d run the first command last (just plain “dhcp-snooping”), it turns the filtering on but if you set the options first (and you did it correctly) you won’t prevent any good traffic by configuring first, then enabling!
Another excellent resource is from HP themselves, a four-page PDF titled, “How to configure DHCP Snooping on ProCurve switches.” Definitely read and understand both the above blog post and this PDF document before setting this up! And make sure to test during scheduled maintenance/downtime…if you get it wrong, your network will probably stop working :-) Also, there are additional options on some ProCurve switches called arp-protect that use the dhcp-snooping database to verify arp packets and prevent arp spoofing attacks. However, this is even easier to screw up and block even good stuff–I don’t recommend you play with it unless you really know what you’re doing :-)
Some of my ProCurve switches, namely the 2810-24G units and all of the 1800 series, don’t support DHCP Snooping. You can check the manual, or at the command line (except on the 1800 series which has no command line) type dhcp-snooping followed by a space and question mark (“dhcp-snooping ?”) to see if it provides you with help about the command. If the command doesn’t exist, your switch model doesn’t support it. It’s working for me on the 5304xl and the 2650s, but not the 2524 or the 2810-24G (the last one surprises me, the 2524 doesn’t). Switches that don’t support it are still going to be vulerable to rogue DHCP servers, but the damage will be limited to that segment at least and not your whole network!
Any comments? Are you using DHCP Snooping? Have you run into a situation where you wish you’d had it turned on but didn’t? (I have, fortunately few and far between. But at least once it was one of my servers that I had accidentally configured impoperly! “Rogue DHCP server” doesn’t mean malicious or even end-user created, it can just as easily be “the server admin messed up” :-)
Oh yeah, one more tip! On ProCurve switches at least, once you have DHCP Snooping set up, you can get a few details and stats about the assignments. Try these three commands to get a configuration report, view statistics, and view the current bindings databaes:
show dhcp-snoopingsnow dhcp-snooping statsshow dhcp-snooping binding
Tada! The End (you thought I’d never get here, didn’t you? :-)
UPDATE: Forgot to provide a link to this article for further reading about ARP Spoofing protection that I briefly mentioned. Good description and flowchart, but there are side-effects you may not realize at first so like I said, be careful with arp-protect :-) Exploiting arp is usually intentional, not accidental like rogue DHCP often is, so hopefully it will be less of a problem especially in churches!
UPDATE 2: Derek Schwab reminded me that the ProCurve switches that support DHCP Snooping are layer 3 switches, while the ones that don’t are layer 2 (and thus don’t function at the IP level where DHCP does). Thanks Derek, you’re right and I didn’t make the connection myself–that’s what friends are for!
Great detailed post! You can also set an ACL on the ports or vlans to prohibit dhcp traffic from other dhcp servers or devices with IP addresses different than your vlan IP address range. In some cases this might be easier. Also having proper vlan segregation helps a lot.
Thanks for the additional details Jeremy!
You can also use source port filtering (2600, 2610), protected ports (2510, 2520), or port isolation (2500) to prevent user ports from communicating with anything but the uplink port. This also stops rogue DHCP servers and works on L2 switches.
(Note port isolation doesn’t work with VLANs.)
Thanks Michael, that is a good idea, especially in an environment where there is no peer-to-peer connectivity required beyond server access. It would certainly be even more secure than just blocking DHCP. However, my guess is that in a church environment, or at least many I’ve seen, there are enough exceptions where users share directly computer-to-computer that it may not be the best solution for everyone. However, some Church IT folks are looking for ways to limit the often non-authorized direct-sharing, so perhaps server-only access could be a boon as well! I never really thought of using it, but there are a good number of systems I can think of that wouldn’t need access to anything but the uplink port…if I have some spare time I may examine this a bit more myself. Thanks again!
When switches do something they should not do they don’t do properly what normal switches must do. They are no more switches, but not yet neither routers, nor firewalls.
I mean all that HP strategy called “Fix problems” instead of “Go for the goal”. HP and Microsoft in technical terms are very alike, they both go for money fixing problems. Instead of getting money offering better designed and implemented products. As the result, for example, HP management software can’t run on Microsoft OS because HP did not expect Microsoft to fix new bugs in IE making HP Insight Manager incompatible.
It is bad solution when some problem created by messy network planning is “fixed” by the device that is not supposed to deal with such problems.
Anyway, thank you for the article, now we know what to do if some switch stops switching…
That comment seems a bit jumbled, but yes I have found it frustrating when something is written for Internet Explorer and subsequent versions of IE don’t work. Switch firmware is not immune from this. Fortunately, better companies’ newer products seem to be coming with much more cross-browser compatibility (especially as the last several releases of browsers gain more dynamic features and are a little more standardized in how they are implemented) which also tends to fix the “new browser doesn’t work” issue as a nice little side-effect.
Doesn’t help the old stuff that’s still poorly-written of course. But eventually (and in some churches, eventually is a long time!) this gear will be obsolete and will be replaced. It is a slow cycle.