Five Things to Know About DHCP Snooping

25 September 2012 by 7 Comments

This is a new format of blog post I’m trying out. The idea is to put key points about a technology into easily digestible bullet points. I’ll draw from textbook knowledge and real-world experience to sum up the “what” and the “why”. If you know “what” and “why”, the “how” becomes an exercise in syntax which you can look up, so I probably won’t belabor individual coding steps as much. I might also toss in a few things I learned from real-world deployments.

This overview of DHCP snooping is in the context of Cisco Catalyst switches running IOS, although I suspect DHCP snooping in other vendors’ switches will function similarly.

1. What is DHCP snooping? DHCP snooping is a layer 2 security technology built into the operating system of a capable network switch that drops DHCP traffic determined to be unacceptable. The fundamental use case for DHCP snooping is to prevent unauthorized (rogue) DHCP servers offering IP addresses to DHCP clients. Rogue DHCP servers are often used in man in the middle or denial of service attacks for malicious purposes. However, the most common DoS scenario is that of an end-user plugging in a consumer-grade router at their desk, ignorant that the device they plugged in is a DHCP server by default.

2. What traffic will DHCP snooping drop?

  • DHCP snooping will drop DHCP messages from a DHCP server that is not trusted. Trusted DHCP servers are identified by configuring a switchport’s DHCP snooping trust state. DHCP server messages can flow through switchports that have a DHCP snooping trusted state. DHCP server messages will be dropped if attempting to flow through a switchport that is not trusted.
  • DHCP messages where the source MAC and embedded client hardware MAC do not match will also be dropped, although this protection can be defeated; badly written vendor IP implementations can cause this to happen with a surprising amount of frequency, the most common scenario being a DHCP request for one interface being forwarded through another interface on that same device.
  • DHCP snooping will also drop messages that release a lease or decline an offer, if the release or decline message is received on a switchport other than the port that the original DHCP conversation was held. This prevents a third party from terminating a lease or declining a DHCP offer on behalf of the actual DHCP client.

3. How does DHCP snooping track information? DHCP snooping stores its observations in a database containing the client MAC address, DHCP assigned IP address, remaining lease time, VLAN, and switchport. The database is a simple flat-file that can be stored in device flash. However, flash is limited in size; as such, it’s considered best-practice to store the DHCP snooping off-box in a remote location, such as a TFTP server. Storing the DHCP snooping database off-box also guarantees that the DHCP snooping database would survive a catastrophic switch failure. In the Cisco IOS realm, note that other switch security services such as IP source guard and dynamic ARP inspection will use the DHCP snooping database, although it is possible to configure IPSG and DAI to function using static entries.

4. What happens when a DHCP snooping violation occurs? When the DHCP snooping service detects a violation, the packet is dropped, and a message is logged that includes the text “DHCP_SNOOPING”. If your switch is configured to send logs to a syslog server, you could consider escalating DHCP snooping alerts, as certain kinds of violations warrant further investigation.

  • %DHCP_SNOOPING-5-DHCP_SNOOPING_MATCH_MAC_FAIL messages are potentially safe to ignore. This message indicates that the source frame and embedded client hardware address in a DHCP request differ, and seems to be unfortunately common. If you see these, consider investigating a few of them to verify that the issue is indeed a poor vendor DHCP client or IP forwarding implementation, and determine your policy going forward.
  • %DHCP_SNOOPING-5-DHCP_SNOOPING_UNTRUSTED_PORT messages are, in my opinion, serious business. These messages indicate that a client is being spoofed, or worse (and more likely), a rogue DHCP server is in operation.

5. Where should I deploy DHCP snooping? From a network design perspective, DHCP snooping is an access layer security feature. Therefore, DHCP snooping’s most likely positioning is that of wiring closet switches or IDFs, but any switch containing access ports in a VLAN serviced by DHCP is a potential candidate. When deploying DHCP snooping, you need to set up the trusted ports (the ports through which legitimate DHCP server messages will flow) before enabling DHCP snooping on the VLAN you wish to protect. This is most often the uplink from the access layer switch to the next layer up, probably your core or aggregation layer if you’re still using the traditional layered design the vast majority of purposefully engineered campus networks have in place today. Note that if you are using layer 3 uplinks to your access layer as opposed to layer 2 802.1q trunks, the layer 3 uplinks will relay DHCP server messages without being defined as trusted.

Links

Filed Under: Blogs, Security, Switching Tagged With: ,
About Ethan Banks

Ethan Banks, CCIE #20655, is a hands-on networking practitioner who has designed, built and maintained networks for higher education, state government, financial institutions, and technology corporations. Ethan is a host of the Packet Pushers Podcast, which has seen over one million unique downloads, and today reaches a global audience of over ten thousand listeners. Also a writer, Ethan covers network engineering and the networking industry for a variety of IT publications. He is also the editor for the independent community of bloggers at PacketPushers.net. Follow @ecbanks.

  • http://twitter.com/tomcooperca Tom Cooper

    Great post Ethan, love the format too. Short and to the point :)

    I don’t know why I don’t see more customers using these features on their access layer. Maybe they’re worried about “potential risk” of having to configure something that could interrupt legitimate traffic? ie. someone setting a DHCP server-attached port to untrusted. Seems trivial to configure (trust, untrust and you’re done!) so I don’t understand why it isn’t as widely deployed…Maybe someone else can comment on their experiences with this?

    • http://packetpushers.net/author/ecbanks Ethan Banks

      Fear of disrupting legitimate traffic has been the bane of network security for a long time. The business is unimpressed when this happens, and a magnifying glass goes on the networking staff while the issue is resolved. IPS falls down quite notably in this way. So, I think folks just shy away…it’s safer, and sometimes perceived as less risky.

      How sad is it when not deploying a security feature is considered less risky than actually deploying the feature? Then again, vendors are somewhat to blame here.

  • JamesWGreene

    Be aware that DHCP servers such as Windows 2003 do not support option 82 and this will cause problems with snooping. We do not use it for this reason, though I have heard folks talk about disabling the snoop information option to get around it. I am not sure if that will actually work though.

    • http://packetpushers.net/author/ecbanks Ethan Banks

      Yes, I’m thinking about a “Five Things” to address Option 82 and its oddities, but need to read up on it more since I haven’t been in an environment where it needed to be deployed.

      • JamesWGreene

        Great! I look to reading it as I do with everything here. Even though I have been in the business over 20 years, I am guaranteed to a thing or two every I visit Packetpushers or listen to your podcasts. Thanks!

  • http://twitter.com/MrsYisWhy Mrs. Y.

    Really good post. We used DHCP snoop heavily in my former EDU environment. This is a great cheat sheet.

  • ChrisK

    Would love to see one on Dynamic Arp Inspection, has anyone had success with it? Our experience has not been good, notably Nortel closet switches that break their own management when it’s enabled, even when putting management on a separate VLAN with DAI turned off.