DHCP Snooping Lab: Easy setup, Intermediate skill

Started by deanwebb, January 14, 2016, 07:42:14 AM

Previous topic - Next topic

deanwebb

DHCP snooping is an important security measure. Basically, it keeps unwanted DHCP servers off the network and protects the DHCP servers that you have. You need to know how to do it. Here's what you'll need:

1. 2 DHCP servers. These can be PCs running DHCP or network devices running DHCP.
2. A DHCP client. Again, any device that can get a DHCP address. A PC is easiest here.
3. A managed switch.

The above can be real or virtual, or if you're really skilled with GNS3, both.

You'll also need to know how to set up a VLAN and a DHCP server - if you don't, those are some great topics for self-study in advance of this exercise.

Here's the lab steps:

1. On the managed switch, set up a VLAN that will include the ports that the client and DHCP servers will be connected to.
2. Plug in the client to one of those VLAN ports. Verify that the client has no IP address (other than a default Windows IP address).
3. Configure the first DHCP server with an IP address of 10.0.0.1 and a DHCP pool of 10.0.0.100-10.0.0.200. Plug it into the VLAN.
4. Verify that the client can now get an IP address. Either do an ipconfig release-renew on the client, shut/no shut the port, or unplug its cable and plug it back in. Wait a while and check to see if it's got an IP address from that pool.
5. Configure the other DHCP server to offer up IP addresses from the pool 10.0.0.50-10.0.0.99. Give it an IP address of 10.0.0.254. Plug it in.
6. With both DHCP servers active, perform multiple releases of the client IP address and see what addresses it gets. It should be messy.
7. On the managed switch, define 10.0.0.1 as an ip-helper address.
8. Next, configure DHCP snooping for that VLAN. Commands will vary according to the type of switch you use and what level of code it is running.
9. Now, try the multiple releases and renewals of IP addresses for the client. It should only be getting IP addresses from the 10.0.0.100-200 pool.
10. Now, set things up so that the 10.0.0.254 server is the active DHCP server and 10.0.0.1's DHCP traffic is blocked.

Ask yourself after this lab, how would DHCP snooping protect against accidental mistakes in setting up networks?
Why would an intruder want to offer other DHCP addresses?
Why would an intruder want to flood a legitimate DHCP server?
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

EOS

Excellent!  These tidbits are great for the forum.    :thankyou:

SimonV

Me and my colleague (he's on this forum but he's a lurker) were setting this up today, but the results and show outputs were very dependant on the IOS version.

We had two 2960S, one 3750 and one 3560G but none of them logged any alerts when a DHCP server was connected to an untrusted port. It did stop the Discovery broadcasts from being sent to the untrusted port, with drop counters increasing, so it was effective in preventing rogue DHCP but still, it feels like being blind without any alerting.

I could swear that it was like this when I was studying for SWITCH. Or I could be mistaken as my Juniper definitely does it. Any one that can shed some light on this? Ideally we would have a Syslog alert generated to be picked up by Graylog with e-mail alerting.