Going Deep With DHCP Snooping

• By Joe Astorino
• June 28, 2011
• 25 Comments

 

Introduction

DHCP snooping is a layer 2 security feature we can configure on our Catalyst switches that helps mitigate a number of different DHCP based network attacks. The basic concepts are easy to understand.  However, the biggest problem I personally found when learning this topic originally was that most of the information out there was incomplete.  It didn’t tell you the whole story about what exactly the technology did, or it didn’t tell you some of the little nuances that would completely break it you don’t watch out for them.

In today’s blog, we are going to examine what types of attacks DHCP snooping helps protect against, how it specifically protects against those attacks, and how to configure this feature on real equipment.  Using this methodology will allow us to first see what DHCP snooping is actually helping protect against and how before we jump into a configuration. I have always found that is the best way to learn for me personally.

DHCP Based Network Attacks

DHCP snooping is used to protect against three main types of network attacks as described below

• DHCP server spoofing attack — As the name implies, a DHCP spoofing attack is when an unauthorized machine becomes a DHCP server on your network.  Imagine what could happen in this situation.  An attacker could start handing out whatever DHCP based information he wants to clients and use that to gain valuable information.  For example, a rogue DHCP server could hand out default-gateway and DNS addresses pointing to a compromised machine set up with a sniffer to unsuspecting clients.  The compromised machine could take all information from clients, sniff it, and then forward the information on to the real default-gateway.  The information sniffed could be anything including usernames and passwords sent in plain text.  This is often referred to as a man in the middle attack

• DHCP address exhaustion attack — This type of attack focuses on depleting the address pool on the DHCP server, thus causing a denial of service attack.  In a DHCPDISCOVER message broadcast out from a client, there is a field called chaddr which is the client hardware address or MAC address. The chaddr field is set to the source MAC address of the client by default.  If an attacker constantly keeps changing his MAC address, he could keep requesting different addresses from the DHCP pool and eventually deplete it.  Fortunately, port-security helps mitigate this attack.  However, if a client keeps the same MAC address but simply changes the chaddr field to something unique on every request, an attacker could just as well exhaust all DHCP addresses in the pool without causing a port-security violation.  The pool could become depleted and legitimate users may not be able to obtain address leases.

• IP Address Hijacking — Normally, when a client is done with an address leased to it via DHCP, it sends a DHCPRELEASE to the server to notify the server that it can go ahead and add that IP address back into the pool of available addresses.  An attacker that has knowledge of an authorized IP addressed leased through DHCP could send a packet to the server with the DHCPRELEASE field set to that authorized IP address.  The attacker could attempt to release that IP address and then take over the IP address on the network. At a minimum, the attacker could be disrupting network communications.

DHCP Attack Mitigation Details

DHCP snooping mitigates the above attacks by doing a few different things as outlined below. First, understand that DHCP snooping works on a concept of trusted ports and untrusted ports. Trusted ports are generally interfaces on your switch that are connected to things under your administrative control like interfaces going to your authorized DHCP servers and switch uplinks. Untrusted ports typically lead to user access ports and things that you generally do not trust.

Secondly, understand that DHCP snooping works in part by building a DHCP snooping database. Basically, the switch inspects DHCP packets on untrusted ports and builds a database containing the information learned per port like the IP address assigned, mac-address, and VLAN.  For example, if the switch sees a DHCP packet going to a client on fa0/1 and the DHCP packet is assigning 10.1.1.1 to the client on that port now we know that port fa0/1 should always have IP address 10.1.1.1.  We should also know that 10.1.1.1 is associated with the mac-address and VLAN of port fa0/1. Keep in mind that the DHCP snooping database is a critical part of other technologies you might use later down the road.  Namely, dynamic ARP inspection (DAI) and IP source guard.

• If the switch receives any kind of DHCP message that could only ever be sent by a DHCP server on an untrusted port, it simply drops the packet (DHCPOFFER, DHCPACK, DHCPNAK, or DHCPLEASEQUERY).  This basically means you cannot have a rogue DHCP server on an untrusted port which is awesome, because that takes care of the DHCP spoofing attack. It also takes care of the schmuck that takes the network into his own hands.  Said schmucks have been known to plug in random home routers that have built in DHCP servers to the production network.  It is a bad day at work when half your production warehouse is down because they have 192.168.1.x IP addresses coming from under schmuck’s desk. There are probably more people using DHCP snooping for this reason alone than there are people using it for actual hack attack mitigation!

• If the switch receives a DHCP packet on an untrusted port and the address in the chaddr field of the packet does not match the actual source MAC address of the frame, the switch drops the packet.  Note, this feature is optional and you must have the mac address verification option turned on for this to work.  Enabling this feature would mitigate the DHCP address exhaustion attack. This option appears to be enabled by default on the 3560 running 12.2.50, but may not be on same other platforms and IOS versions.

• If the switch receives a DHCPRELEASE or DHCPDECLINE message on an untrusted port it examines the packet more closely. It looks at the IP address being released in the DHCP packet and looks into the DHCP snooping binding database table to see if it has a record of that IP address.  If there is a record of the IP in the database, but the interface sending the DHCPRELEASE or DHCPDECLINE message does not match up with that record, the switch will drop the packet. This mitigates the attack explained above where an attacker could release a legitimate IP address from the DHCP server.  For example, let’s say a legitimate host with mac address 0000.0000.1111 received the IP address 10.1.1.1 from the real DHCP server and said host is connected to fa0/1 on our switch.  Now, a DHCPRELEASE packet comes into port fa0/2 on our switch that is trying to tell the DHCP server to release 10.1.1.1 from the pool.  The switch will find that 10.1.1.1 is bound to the mac 0000.0000.1111 on port fa0/1.  The switch knows that 10.1.1.1 is located on port fa0/1 and there is no reason a release for that IP should be coming in a different port. The switch identifies this as a potential attack and drops the packet.

• If the switch receives a DHCP packet on an untrusted interface where the giaddr field is a non-zero value it drops the packet. The giaddr field in a DHCP packet is used for DHCP relay.  When a DHCP relay relays a DHCP packet to a server, it fills in the giaddr field with the IP address of the interface the request came in on. That way, the server knows what subnet to allocate an address from. An example would be a typical ip helper-address on a Cisco router.  This makes your Cisco router into a DHCP relay.  Imagine you had an interface configured with the command ip helper-address 1.1.1.1 on an interface with IP address 100.100.100.100/24.  When that router interface receives a DHCP request broadcast, it puts 100.100.100.100 into the giaddr field of the DHCP packet and unicasts it to the DHCP server at 1.1.1.1. The DHCP server would then know it needs to allocate an IP address to the client from the pool 100.100.100.100.0/24. This allows us to have DHCP servers on different layer 3 subnets than our clients and enables central control of our environment. This feature of DHCP snooping probably exists because we don’t want untrusted hosts going around claiming to be DHCP relays and directing DHCP packets to places they don’t need to be going.

• If the switch receives a DHCP packet with option 82 information inserted on an untrusted interface, it drops the packet. Discussing what exactly option 82 information is is a bit outside the scope of this article, but in summary it provides additional information to supported DHCP servers so that the servers can more precisely hand out IP addresses in specific ranges. Information in option 82 might include things like the client interface, client switch and client VLAN. This one causes all sorts of pain and suffering for CCIE candidates especially because by default when you enable DHCP snooping on a Cisco switch it will insert option 82 information and set the giaddr field to 0.0.0.0.  Guess what?  Cisco routers acting as DHCP relays or DHCP servers drop DHCP packets with the giaddr field set to 0.0.0.0 by default : )  Also, other switches configured for DHCP snooping along the path from the client to the server will drop packets with option 82 information set by default on untrusted interfaces. This makes sense because you don’t want to trust some random specific option 82 information injected into DHCP packets from an untrusted source that could effect how your DHCP server handles address allocation.  There are a few solutions to this problem we will get into later

Basic DHCP Snooping Configuration

A few simple commands can get you started with DHCP snooping.  It is somewhat scary that you can do SO much with so few commands.  Believe me, you want to be extremely careful with DHCP snooping in a production network.  You will want to take care to plan accordingly and really understand the technology because enabling certain features in the wrong places can break your network.  With that being said you need a few things to turn this on.  You enable it globally with the ip dhcp snooping command.  You then enable it per VLAN with the ip dhcp snooping vlan command. Thirdly, remember that by default all ports are in the untrusted state.  You will want to trust the interface connected to your real DHCP server with the ip dhcp snooping trust interface command. Best practice is also to trust your inter-switch uplinks.  That’s it.  Yeah, seriously that’s it for the basics.

Mucking around with option 82

As I said before, there are some interesting things that happen with DHCP snooping and option 82 insertion you need to be aware of in the real world and in things like the CCIE lab. Failing to understand these things can absolutely destroy you with regards to this topic. Let’s review some of the basic facts with regards to option 82

• DHCP option 82 is an option that can be inserted into a DHCP packet to provide a DHCP server with additional information about a client.  This is done so that a DHCP server can more precisely allocate IP addresses from specific pools for more specific reasons.

• By default, when you enable DHCP snooping on a Cisco switch it will insert option 82 information into DHCP packets. Additionally, the switch will set the giaddr field of the DHCP packet to 0.0.0.0.

• By default, Cisco switches enabled with DHCP snooping will drop DHCP packets with option 82 information coming in untrusted interfaces. Additionally, switches configured for DHCP snooping will drop DHCP packets with a non-zero giaddr address coming in untrusted interfaces

• By default Cisco routers acting as DHCP relays and DHCP servers will drop DHCP packets with the giaddr field set to 0.0.0.0

There are a few things we can muck around with here to fix potential issues

• Stop the switch from ever inserting option 82 information in the first place with the no ip dhcp snooping information option command

• If we want to continue to let the switch insert option 82 information and those packets will be passing through other untrusted switch interfaces configured for DHCP snooping upstream, they will be dropped.  We can configure the other switches to allow those packets with the ip dhcp snooping information option allow-untrusted command

• That just leaves our DHCP relays (routers configured with ip helper-address) which will drop DHCP packets with giaddr set to 0.0.0.0.  If we continue to allow the DHCP snooping switch to insert option 82 (we did NOT configure no ip dhcp snooping information option) we can instruct the router running as a DHCP relay to trust these packets with the ip dhcp relay information trust-all command

 

Labbing It Up

OK kids, here is the part where we jump on to the console of real Cisco switches and configure this beast.  As per usual, let’s see what we have gotten ourselves into today.

 

 

Where to begin…hmmmmm.  How about a brief introduction to the topology?  Sounds good!  OK, R1 will be acting as a DHCP server on VLAN 11.  R4 will be acting as a DHCP client on VLAN 10.  The two are obviously separated by three switches.  Cat1 and Cat3 both trunk up to Cat2.  Cat1 and Cat3 are purely acting as normal layer 2 switches with no routing capability whatsoever.  Cat2 handles all inter-VLAN routing and is thus configured for SVIs on both VLANs 1o and 11.  R1 will have a static default-route pointing to the VLAN 11 SVI.  Cat2 will be configured as a DHCP relay with ip helper-address on interface vlan 10.

Before we get into snooping, let’s do our basic configurations and make sure DHCP works at all.

 

Base Configurations

R1

interface FastEthernet0/0
 ip address 10.10.11.1 255.255.255.0
 duplex auto
 speed auto
!
ip dhcp excluded-address 10.10.10.22
ip dhcp pool VL10
   network 10.10.10.0 255.255.255.0
   default-router 10.10.10.22
!
!
ip route 0.0.0.0 0.0.0.0 10.10.11.22

Cat1

interface FastEthernet0/1
 switchport access vlan 11
 switchport mode access
 spanning-tree portfast
!
interface FastEthernet0/24
 switchport trunk encapsulation dot1q
 switchport mode trunk

Cat2

interface range Fa0/19 , Fa0/24
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface Vlan10
 ip address 10.10.10.22 255.255.255.0
 ip helper-address 10.10.11.1
!
interface Vlan11
 ip address 10.10.11.22 255.255.255.0

Cat3

interface FastEthernet0/19
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
interface FastEthernet0/4
 switchport access vlan 10
 switchport mode access
 spanning-tree portfast

R4

interface Ethernet0/1
 ip address dhcp

Base Verification

Let’s see how we did and make sure this actually works before configuring snooping.  We’ll bring up R4 E0/1.  Hopefully, it gets an IP address and we can ping R1.

R4(config)#int e0/1
R4(config-if)#no shutdown
R4(config-if)#
*Jul 10 04:16:33.151: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
*Jul 10 04:16:34.151: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
R4(config-if)#
*Jul 10 04:16:37.315: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/1 assigned DHCP address 10.10.10.2, mask 255.255.255.0, hostname R4

R4(config-if)#do ping 10.10.11.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.11.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms

DHCP Snooping Configuration

Excellent! Now, on to the fun stuff. Let’s begin configuring DHCP snooping. Here is what we are going to do to start with. We will configure DHCP snooping on every switch in our environment. Since R1 is the legitimate DHCP server we will trust Cat1 Fa0/1. We will also have to trust every interface that DHCP packets coming from the server need to traverse to reach R4. Those would include Cat2 Fa0/24 and Cat3 Fa0/19. That is as basic as it gets. We will also shut down R4 e0/1 while we work. Let’s get started

R4(config)#int e0/1
R4(config-if)#shutdown

Cat1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cat1(config)#ip dhcp snooping
Cat1(config)#ip dhcp snooping vlan 10,11
Cat1(config)#int fa0/1
Cat1(config-if)#ip dhcp snooping trust

Cat2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Cat2(config)#ip dhcp snooping
Cat2(config)#ip dhcp snooping vlan 10,11
Cat2(config)#int fa0/24
Cat2(config-if)#ip dhcp snooping trust

Cat3(config)#ip dhcp snooping
Cat3(config)#ip dhcp snooping vlan 10,11
Cat3(config)#int fa0/19
Cat3(config-if)#ip dhcp snooping trust

OK, we have a basic configuration let’s see what happens.

R4(config)#int e0/1
R4(config-if)#no shutdown

DHCP Snooping Troubleshooting

Hmmmmmm…after several minutes we still don’t have an IP address on R4. Let’s examine a few things. For starters, we are getting the following log message on Cat2 every so often.  The MAC address referenced in the error happens to be the MAC address of R4 e0/1.

%DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giaddr or option82 value on untrusted port, message type: DHCPDISCOVER, MAC sa: 00e0.1e62.9542

Indeed, the dreaded option 82 insertion is killing us. What is this really telling us? What is happening is this: R4 is sending broadcast DHCP requests. Since Cat3 is configured for DHCP snooping it goes ahead and inserts option 82 information and sets the giaddr field to 0.0.0.0 before forwarding the packet out fa0/19 up to Cat2. Cat2 is a DHCP relay and it sees a packet coming in with the giaddr field set to 0.0.0.0. This breaks the rules and Cat2 drops the packet. At this point we have a few options. We can configure no ip dhcp snooping information option on Cat3 to prevent Cat3 from inserting option 82 and setting giaddr to 0.0.0.0 in the first place OR we can do something on Cat2. If Cat2 were actually a router acting as just a DHCP relay and not a catalyst switch running DHCP snooping we could configure ip dhcp relay information option trust-all to fix this. However, even if we did that here, because Cat2 is also running DHCP snooping and because a switch running DHCP snooping will drop DHCP packets with option 82 information or giaddr set to 0.0.0.0 on untrusted ports we would need ip dhcp snooping information option allow-untrusted or we would have to trust the port. In a production network, the recommendation is to trust switch to switch trunks, but for the sake of learning and because I am partially insane we will configure ip dhcp snooping information option allow-untrusted instead. That and because it’s good to know every possible way to do something, especially in the lab : )

Cat2(config)#ip dhcp snooping information option allow-untrusted

Well, that fixed our issue on Cat2. We are no longer getting the error in the log! Hooray, we have saved the network!!!!….oh crap, we STILL don’t have an address on R4. Damn it all, back to the lab!

This time we see the same familiar message but on Cat1

%DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giaddr or option82 value on untrusted port, message type: DHCPDISCOVER, MAC sa: 00e0.1e62.9542

Why? Same reason. When Cat2 received the DHCP packet it went ahead and trusted the option 82 information, but then it forwarded it on to Cat1. Cat1 has DHCP snooping enabled and does not trust fa0/24 so it drops any packets with option 82 information inserted. What to do? Same concept. We can trust fa0/24 on Cat1. We can tell Cat1 that this is OK with the ip dhcp snooping information option allow-untrusted command. Since we already proved our point, let’s just be somewhat normal for a change and configure a trust relationship on Cat1 this time.

Cat1(config)#int fa0/24
Cat1(config-if)#ip dhcp snooping trust

After a few seconds over on R4, bickety bam we got an address

*Jul 10 05:01:24.635: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/1 assigned DHCP address 10.10.10.3, mask 255.255.255.0, hostname R4

DHCP Snooping Verification

Here are your basic show commands for verifying DHCP snooping.  We will just examine Cat3 for this purpose.

Cat3#show ip dhcp snooping

Switch DHCP snooping is enabled

DHCP snooping is configured on following VLANs:

10-11

DHCP snooping is operational on following VLANs:

10-11

DHCP snooping is configured on the following L3 Interfaces:
 

Insertion of option 82 is enabled

   circuit-id format: vlan-mod-port

    remote-id format: MAC

Option 82 on untrusted port is not allowed

Verification of hwaddr field is enabled

Verification of giaddr field is enabled

DHCP snooping trust/rate is configured on the following Interfaces:

Interface                    Trusted     Rate limit (pps)

------------------------     -------     ----------------

FastEthernet0/19             yes         unlimited

Cat3#show ip dhcp snooping binding

MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface

------------------  ---------------  ----------  -------------  ----  --------------------

00:E0:1E:62:95:42   10.10.10.3       85726       dhcp-snooping   10    FastEthernet0/4

Additional Configuration Options

There are a few more advanced configuration options you can look into for DHCP snooping.  Notably there is DHCP rate-limiting and the DHCP database agent. Rate limiting is pretty straight forward — You configure a set limit in packets per second for DHCP messages on a particular interface.  The DHCP snooping database agent has to do with how you store your DHCP snooping database.  By default, the DHCP snooping database is not stored anywhere permanently.  If your switch loses power or is reloaded all the information is lost and must be relearned.  Not THAT big of a deal if you are just running DHCP snooping.  However, if you are using the DHCP snooping database to basically power other advanced switch features like dynamic ARP inspection or IP source guard, you could find yourself with no connectivity pretty quickly if the database is lost.  To alleviate this, you can configure the DHCP snooping agent to store the database in a specific place. The specific place could be as simple as flash or as complex as on a remote TFTP or FTP server.  The best practice is to configure the agent to store the database on a remote server.  One reason is because everytime the database changes at all, it is re-written.  This can tax switch resources and possibly lock up your switch.  Another reason is that the constant writing to flash is not exactly healthy for the flash memory.

Since this blog is ridiculously long as it is, I am not going to get into the DHCP agent configuration today, but you can definitely find it in the configuration guides for your switch.

Hopefully, this has helped you out and tied together many of the concepts involved with DHCP snooping as a whole. I hope you enjoyed!