DHCP Snooping

1. Introduction to DHCP Snooping

In this course you will discover a vital feature for securing your network: DHCP Snooping.

DHCP Snooping is used in order to protect our network from DHCP Attacks !

You likely already know that DHCP (Dynamic Host Configuration Protocol) plays a key role in your network.

DHCP Give IP Address

It automatically assigns devices essential configuration like:

  • IP addresses,
  • Subnet masks,
  • Default gateways,
  • DNS server

But let’s imagine a scenario. What if a malicious device pretends to be your network’s DHCP server?

Malicious DHCP Server

This can lead to attacks such as:

  • Man-in-the-Middle (MITM) attacks (intercepting your sensitive data) or
  • DHCP starvation (denying legitimate devices access to the network)

Sounds alarming, right? Don’t worry! Before we explain how DHCP Snooping solves these issues, first we’ll break down DHCP attacks: the Man-in-the-Middle attack and DHCP Starvation.

This will give you the context you need to see how DHCP Snooping protects your network.

Let’s dive into the details together!

2. Understanding DHCP Attacks

Man-in-the-Middle Attack

Let’s first take a closer look at how a Man-in-the-Middle attack happens !

Step 1

When your device connects to the network for the first time, it will request an IP address by using DHCP.

Client Send DHCP DISCOVER Message scaled

Our device first sends out a DHCP DISCOVER message. Think of this message as your device saying:

“Is there a DHCP server out there that can assign me an IP address?”

At this point, everything seems normal. Your device is simply broadcasting its request to all devices on the network.

Step 2

Now, your device’s DHCP DISCOVER message is sent to every device on the local network. This includes the legitimate DHCP server but also the rogue device pretending to be a DHCP server as you can see in the picture.

DHCP Discover is broadcast on LAN Switches scaled

You might be wondering: “What’s the harm in that?”

When the rogue DHCP Server will received the DHCP DISCOVER from the deivce, it will say “okay I need to send a DHCP OFFER to the device with incorrect parameters in order to redirect traffic !“

Step 3

Here’s where things start to go wrong ! Both the legitimate DHCP server and the rogue server reply with a DHCP OFFER message.

DHCP Server respond with DHCP OFFER scaled

Each one is offering an IP configuration, hoping your device will accept it.

But there’s a critical issue:

  • Your device usually accept the First DHCP OFFER it receives.
  • If the rogue server responds faster than the legitimate server, your device will accepts the malicious configuration.

Step 4

The DHCP OFFER from the Rogue DHCP Server is received first !

Client Received DHCP OFFER from Spurious DHCP Server scaled

The device will accept the accept the DHCP OFFER from the rogue DHCP Server !

Step 5

Your device sends a DHCP REQUEST message to confirm it wants to use the configuration from the rogue server.

It’s as if your device is saying: “Thank you! I’ll use these settings.”

Unfortunately, the device it has no way of knowing that it just accepted settings from a malicious server.

Client respond to Spurious DHCP Server scaled

At this point, the rogue server has successfully tricked your device with a malicous IP configuration.

Step 6

The rogue server sends back a DHCP ACK, giving incorrect ip configuration parameters.

DHCP ACK scaled

Now, your device has an IP address, subnet mask, default gateway and DNS server but the default gateway point to the attacker’s device (192.168.1.2) instead of the legitimate default gateway router.

Step 7

At this point, the attacker has successfully placed themselves in the middle of your network communications.

DHCP Man in the middle attack scaled

Every packet sent by your device now passes through the rogue server before reaching its destination.

From here, the attacker can:

  • Intercept your data: They can capture sensitive information like passwords.
  • Manipulate your traffic: For example, redirecting you to fake websites that look legitimate.

This is a classic example of a Man-in-the-Middle attack highlight how DHCP can be used to attack the network !

DHCP Starvation Attack

Let’s now explore another significant DHCP attack : the DHCP Starvation Attack. This type of attack isn’t about intercepting traffic like a Man-in-the-Middle attack; instead, it focuses on denying legitimate devices access to the network.

Imagine this: users on your network suddenly can’t connect because the DHCP server has no IP addresses left to assign. Why ? An attacker has drained the server’s entire IP pool.

How Does a DHCP Starvation Attack Work ?

  1. The attacker sends a flood of DHCP DISCOVER messages to the DHCP server.
DHCP STARVATION ATTACK
  1. In each message, the attacker spoofs a different client MAC address in the DHCP header (the chaddr field).
  2. The DHCP server treats each request as if it’s coming from a unique client and assigns an IP address for each fake request.
  3. Over time, the DHCP server’s IP pool is completely empty, leaving no IP addresses available for legitimate users.

A Closer Look at the Attack

To understand how the attacker accomplishes this, let’s focus on the MAC address manipulation:

  • The attacker’s device has a physical MAC address, let’s say MAC1.
  • In every DHCP DISCOVER message, the attacker keeps the source MAC in the Ethernet frame as MAC1 but modifies the chaddr field in the DHCP header to fake unique MAC addresses like MAC2, MAC3, MAC4, and so on.
  • The DHCP server doesn’t realize these requests are coming from a single device because DHCP server use the chaddr field to uniquely identify clients.

The Result of the Attack

When the attacker finish his attack, the DHCP server’s entire pool of IP addresses has been leased out to fake clients. Here’s what happens next:

DHCP SERVER dont have any IP Address left scaled
  • Legitimate devices attempting to connect to the network can no longer obtain an IP address.

Users experience disruptions and their devices are unable to join the network.

Now that you’ve seen how DHCP can be exploited, let’s explore how DHCP Snooping protects your network from these attacks.

3. DHCP Snooping Operation

With DHCP Snooping, we can protect our network by analyzing and filtering DHCP traffic.

Why Divide Trusted and Untrusted Areas?

To effectively filter DHCP traffic, we need to divide the network into two areas:

Trusted and Untrusted DHCP Snooping
  • Trusted Area: This is the safe zone in your network. Devices here such as routers, switches, and legitimate DHCP servers are trusted and controlled by the IT staff.
  • Untrusted Area: This is the more vulnerable part of your network where end-user devices connect. Devices in this area are treated cautiously to protect against potential rogue DHCP servers and other malicious activities.

DHCP Message Filtering on Ports

Once we’ve divided the network, DHCP Snooping applies specific rules to filter DHCP traffic based on the type of port. We have 2 types of ports.

Trusted and Untrusted Port DHCP Snooping

On Trusted Ports

Trusted ports connect to legitimate devices like DHCP servers or relay agents. These ports allow all types of DHCP traffic because the devices here are reliable.

  • What happens: All DHCP messages are allowed.
  • Why: We trust the devices connected to these ports to generate legitimate DHCP traffic.
Trusted Port DHCP Snooping

Examples of allowed messages:

  • Server messages: DHCP OFFER, DHCP ACK, DHCP NAK.
  • Client messages: DHCP DISCOVER, DHCP REQUEST.

On Untrusted Ports

Untrusted ports are where end-user devices connect. These ports are closely monitored to ensure rogue DHCP servers cannot operate.

  • What happens: Only DHCP Client messages are allowed and DHCP Server messages are blocked.
  • Why: To prevent unauthorized DHCP servers from sending malicious responses.

Examples of blocked messages:

  • Server messages: DHCP OFFER, DHCP ACK, DHCP NAK.
Untrusted Port with DHCP Snooping

This filtering mechanism ensures that DHCP server messages can only originate from trusted ports, protecting the network from rogue DHCP servers.

Preventing DHCP Starvation with Message Inspection

DHCP Snooping doesn’t just filter messages—it also actively inspects DHCP traffic on untrusted ports to prevent attacks like DHCP Starvation.

When an untrusted port receives a DHCP DISCOVER message, the switch compares:

  • The source MAC address in the Ethernet frame.
  • The client hardware address (CHADDR) in the DHCP packet.

If these two addresses don’t match, the switch discards the message, identifying it as part of a potential DHCP Starvation attack.

Preventing DHCP Starvation with Message Inspection

By performing this inspection, DHCP Snooping blocks fake DHCP requests and ensures that the server’s IP pool is reserved for legitimate devices.

Introducing the DHCP Snooping Binding Table

With DHCP Snooping enabled, the switch creates and maintains a DHCP Snooping Binding Table. This table acts as a database of legitimate DHCP clients and their associated information.

What Does the Binding Table Contain?

For each legitimate DHCP client, the table stores:

  • Client MAC address
  • Assigned IP address
  • Switch port and VLAN
  • Lease duration
DHCP Snooping Binding Table Overview

This is a cool feature in order to see the DHCP Client by using your switch.

Now that you understand the theory behind DHCP Snooping, it’s time to put it into practice. Let’s move on and configure DHCP Snooping step by step to see how it works in a real network setup!

4. DHCP Snooping Configuration

Our topology includes a router (R1) acting as the DHCP server and a PC connected through a switch.

DHCP Snooping Configuration

Enable DHCP Snooping

First, we need to activate DHCP Snooping on the switch. This enables the feature globally.

SW1#(config)# ip dhcp snooping

Define VLAN to Protect

Next, we specify the VLAN where DHCP Snooping should operate. By default, we’ll use VLAN 1.

SW1#(config)# ip dhcp snooping vlan 1

This ensures DHCP Snooping monitors and filters traffic only on the specified VLAN.

Mark Interfaces as Trusted or Untrusted

DHCP Snooping classifies interfaces into two categories: trusted and untrusted. By default, all interfaces start as untrusted.

  • Trusted Interface: These are typically uplinks to legitimate DHCP servers or relay agents. Trusted interfaces allow all DHCP messages to pass through.
SW1(config)# interface gigabitEthernet0/0
SW1(config-if)# ip dhcp snooping trust
  • Untrusted Interface: This is the default state for all ports not explicitly marked as trusted. Untrusted ports only allow DHCP client messages and block server responses.

Disabling DHCP Option 82

We need to disable DHCP Option 82 !

SW1(config)# no ip dhcp snooping information option

This topic will be explained in more detail later.

Verifying the Configuration

Once DHCP Snooping is configured, we can verify its status and operation using the following commands:

SW1#show ip dhcp snooping         
Switch DHCP snooping is enabled
Switch DHCP gleaning is disabled
DHCP snooping is configured on following VLANs:
1
DHCP snooping is operational on following VLANs:
1
DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is disabled
   circuit-id default format: vlan-mod-port
   remote-id: 50f6.1504.7a00 (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    Allow option    Rate limit (pps)
-----------------------    -------    ------------    ----------------   
GigabitEthernet0/0         yes        yes             unlimited
  Custom circuit-ids:

From the output, here’s what we can see based on our topology:

  1. DHCP Snooping is enabled on VLAN 1: This confirms that the feature is active on the correct VLAN, protecting the traffic in our setup.
  2. Option 82 is disabled: This matches our configuration, as we’ve chosen to disable Option 82 for now to simplify the setup and avoid potential issues with the DHCP server.
  3. Trusted Interface is configured correctly: The interface GigabitEthernet0/0, which connects to the DHCP server (R1), is marked as trusted. This ensures that legitimate DHCP messages from the server are allowed.
  4. Untrusted interfaces remain untrusted: All other ports not explicitly marked as trusted are untrusted by default. This prevents rogue DHCP servers from operating on the network.

Inspect the DHCP Snooping Binding Table

The DHCP Snooping Binding Table dynamically maintains a record of legitimate DHCP clients. Use the following command to view the table:

SW1#show ip dhcp snooping binding 
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:50:79:66:68:7B   192.168.10.10    86390       dhcp-snooping   1     GigabitEthernet0/1
Total number of bindings: 1

Here’s what we can confirm from this output:

  1. MAC Address of the client: The table shows the MAC address 00:50:79:66:68:7B, which matches the client device in our topology.
  2. Assigned IP Address: The client has been assigned the IP address 192.168.10.10 by the DHCP server, indicating proper DHCP communication.
  3. Interface and VLAN: The client is connected to GigabitEthernet0/1 on VLAN 1, which matches our topology setup.
  4. Lease Time: The lease duration for the assigned IP address is displayed, confirming that the binding is valid and actively tracked.

5. Rate Limiting

DHCP Snooping can limit the rate of DHCP messages allowed on an interface. If the rate of DHCP messages exceeds the configured limit, the interface is automatically placed in the err-disabled state.

Why Limit the DHCP Rate ?

Limiting the DHCP rate is essential to protect the network against specific threats, particularly attacks targeting DHCP Snooping. Attackers can exploit this feature by flooding the switch with DHCP DISCOVER messages, overloading the switch’s CPU.

DHCP Snooping Rate Limiting
  • Impact: When the CPU becomes overloaded, the switch may fail to process subsequent DHCP messages correctly. This failure can allow malicious traffic to bypass DHCP Snooping’s security filters and compromise the network.

By placing the interface in the err-disabled state, the switch prevents further malicious traffic from impacting the network.

How to Configure DHCP Rate Limiting

You can configure the DHCP message rate limit on an interface using the following commands:

SW1(config)# interface g0/1
SW1(config-if)# ip dhcp snooping limit rate 10

In this example:

  • The interface GigabitEthernet0/1 is configured to allow a maximum of 10 DHCP messages per second.
  • If the number of DHCP messages exceeds this limit, the interface will be disabled and placed in the err-disabled state.

Switch Logs for Exceeding Rate Limits

If an interface receives DHCP messages exceeding the configured limit, the switch generates logs saying the interface is now set to err-disabled (shutdown).

DHCP DISCOVER MESSAGE DHCP SNOOPING BLOCKED

You see see below the switch log saying the interface is now in Err-disabled state !

SW1#
*Jan 22 22:08:52.275: %DHCP_SNOOPING-4-DHCP_SNOOPING_ERRDISABLE_WARNING: DHCP Snooping received 11 DHCP packets on interface Gi0/1

*Jan 22 22:08:52.275: %DHCP_SNOOPING-4-DHCP_SNOOPING_RATE_LIMIT_EXCEEDED: The interface Gi0/1 is receiving more than the threshold set

*Jan 22 22:08:52.275: %PM-4-ERR_DISABLE: dhcp-rate-limit error detected on Gi0/1, putting Gi0/1 in err-disable state

*Jan 22 22:08:53.278: %LINEPROTO-5-UPDOWN: Line protocol on Interface Gi0/1, changed state to down

*Jan 22 22:08:54.277: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

The interface is now in the err-disabled state and cannot process traffic.

6. Re-Enable Interface

When an interface is placed in the err-disabled state due to DHCP rate limiting, it no longer processes any traffic. To manually re-enable the interface, you can use the following commands:

SW1(config)#interface g0/1
SW1(config-if)#shutdown
SW1(config-if)#no shutdown

These commands bring the interface down and back up, clearing the err-disabled state. However, performing this manually on multiple interfaces or during an active attack can be time-consuming and impractical.

To address this, Cisco switches allow automatic recovery from the err-disabled state through the Error Disabled Recovery feature.

Error Disabled Recovery

With Error Disabled Recovery, you can configure the switch to automatically re-enable the interface after a specified time interval. This reduces downtime and avoids the need for manual intervention.

Step 1: Verify Current Recovery Settings

Use the show errdisable recovery command to check the recovery status for various causes:

SW1#show errdisable recovery 
ErrDisable Reason            Timer Status
-----------------            --------------
arp-inspection               Disabled
bpduguard                    Disabled
channel-misconfig (STP)      Disabled
dhcp-rate-limit              Disabled
dtp-flap                     Disabled
gbic-invalid                 Disabled
inline-power                 Disabled
l2ptguard                    Disabled
link-flap                    Disabled
mac-limit                    Disabled
link-monitor-failure         Disabled
loopback                     Disabled
oam-remote-failure           Disabled
pagp-flap                    Disabled
port-mode-failure            Disabled
pppoe-ia-rate-limit          Disabled
psecure-violation            Disabled
security-violation           Disabled
sfp-config-mismatch          Disabled
storm-control                Disabled
udld                         Disabled
unicast-flood                Disabled
vmps                         Disabled
psp                          Disabled
dual-active-recovery         Disabled
evc-lite input mapping fa    Disabled
Recovery command: "clear     Disabled

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

In this output, dhcp-rate-limit recovery is currently disabled, and no interfaces are scheduled for recovery.

Step 2: Enable Recovery for DHCP Rate Limit

To enable automatic recovery for interfaces disabled by DHCP rate limiting, use the following command:

SW1(config)#errdisable recovery cause dhcp-rate-limit

You can also adjust the timer interval, which determines how long the switch waits before attempting recovery. By default, this is set to 300 seconds, but you can change it to a lower value if needed:

SW1(config)#errdisable recovery interval 60

This sets the recovery interval to 60 seconds.

Step 3: Verify Recovery Configuration

After enabling recovery, use the show errdisable recovery command again to confirm the settings:

SW1#show errdisable recovery 
ErrDisable Reason            Timer Status
-----------------            --------------
arp-inspection               Disabled
bpduguard                    Disabled
channel-misconfig (STP)      Disabled
dhcp-rate-limit              Enabled
dtp-flap                     Disabled
gbic-invalid                 Disabled
inline-power                 Disabled
l2ptguard                    Disabled
link-flap                    Disabled
mac-limit                    Disabled
link-monitor-failure         Disabled
loopback                     Disabled
oam-remote-failure           Disabled
pagp-flap                    Disabled
port-mode-failure            Disabled
pppoe-ia-rate-limit          Disabled
psecure-violation            Disabled
security-violation           Disabled
sfp-config-mismatch          Disabled
storm-control                Disabled
udld                         Disabled
          
Interface       Errdisable reason       Time left(sec)
---------       -----------------       --------------
unicast-flood                Disabled
vmps                         Disabled
psp                          Disabled
dual-active-recovery         Disabled
evc-lite input mapping fa    Disabled
Recovery command: "clear     Disabled

Timer interval: 60 seconds

Interfaces that will be enabled at the next timeout:

Interface       Errdisable reason       Time left(sec)
---------       -----------------       --------------
Gi0/1            dhcp-rate-limit          45

In this example:

  • dhcp-rate-limit recovery is enabled.
  • The interface GigabitEthernet0/1 is scheduled to recover in 45 seconds.

Recovery Process in Action

Once the timer expires, the switch automatically attempts to recover the interface. The following logs show the recovery process:

our interface g0/1 is waiting to be re-enabled after the timer left is gone (290 seconds)

*Jan 22 22:16:52.290: %PM-4-ERR_RECOVER: Attempting to recover from dhcp-rate-limit err-disable state on Gi0/1

*Jan 22 22:16:54.323: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up

*Jan 22 22:16:55.324: %LINEPROTO-5-UPDOWN: Line protocol on Interface Gi0/1, changed state to up

After the recovery is complete, the interface is fully operational again.

7. DHCP Snooping Option 82 (Information Option)

Option 82 is a field added to DHCP messages to provide details like the VLAN and port where a client is connected. This is typically added by a DHCP relay agent to help the DHCP server identify the origin of requests.

When DHCP Snooping is enabled on a Cisco switch, the switch automatically adds Option 82 to DHCP messages, even if it is not acting as a relay agent. Additionally, the switch will drop DHCP messages with Option 82 if they are received on an untrusted port.

Problem with Option 82

In this scenario, the switch adds Option 82 to DHCP DISCOVER messages sent by clients. Since the switch is not a legitimate DHCP relay agent, the DHCP server might reject these messages, considering them invalid.

DHCP Snooping Option 82

In this case:

  • The DHCP server rejects the request because it detects Option 82, but it wasn’t added by a real relay agent.
  • The server logs the message as inconsistent relay information and does not respond.

Solution: Disable Option 82

To ensure smooth DHCP communication, disable Option 82 on the switch using the following command:

SW1(config)#no ip dhcp snooping information option

With this command, the switch no longer adds Option 82 to outgoing DHCP messages, and the DHCP server accepts the requests as valid.

DHCP SNooping with option 82 Disabled

In this case:

  • The DHCP server processes the DHCP DISCOVER message without issues.
  • The server responds normally to the client.

8. Conclusion

In this course, we explored the importance of DHCP Snooping as a vital tool for securing your network. Here’s a quick recap of the key points:

  • Understanding the Threats: We learned how DHCP can be exploited through Man-in-the-Middle attacks and DHCP Starvation attacks, both of which can disrupt your network’s functionality and compromise security.
  • How DHCP Snooping Works: DHCP Snooping protects your network by dividing ports into trusted and untrusted zones, filtering traffic to block malicious DHCP messages, and inspecting packets to prevent fake DHCP requests.
  • DHCP Snooping Binding Table: This feature dynamically maintains a record of legitimate DHCP clients to ensure proper communication and security.
  • Configuration Essentials: We covered how to enable DHCP Snooping, define VLANs, mark ports as trusted or untrusted, and verify the setup.
  • Rate Limiting: By setting a rate limit on DHCP messages, we can prevent the switch from being overwhelmed during attacks.
  • Option 82: We discussed how and why to disable this feature to ensure smooth communication between DHCP clients and servers.
DAI (Dynamic ARP Inspection)