Friday, March 11, 2011

Preventing DHCP Starvation Attacks

Wireless expert, and fellow Wireless Tech Field Day delegate, Steve Williams recently blogged about DHCP starvation attacks using a tool called Yersinia.

I thought the topic was very pertinent as a security topic that is often overlooked in modern networks. In particular, the mobile nature of wireless clients makes DHCP pool scalability and stability of paramount concern. In this post, I'd like to address what options are available for network administrators on both wired and wireless networks to mitigate DHCP starvation attacks.

DHCP Starvation Overview
DHCP starvation attacks are designed to deplete all of the addresses within the DHCP scope on a particular segment. Subsequently, a legitimate user is denied an IP address requested via DHCP and thus is not able to access the network. Gobbler, Yersinia, and Metasploit are public domain hacking tools that perform automated DHCP starvation attacks. DHCP starvation may be purely a DoS mechanism or may be used in conjunction with a malicious rogue server attack to redirect traffic to a malicious computer ready to intercept traffic.

Attack Mitigation on Wired Networks
For wired access, port security can currently prevent a DHCP starvation attack launched from a PC connected to a switch that is using a tool such as Gobbler. The inability of the attack to succeed is due more to a limitation of the tool than the mitigation offered by port security. The only reason such an attack fails is that Gobbler uses a different source MAC address to generate a different DHCP request and can be mitigated by port protection.

However, if an attacker is able to use their MAC address in the Ethernet packet and simply changes the MAC address in the DHCP payload (the field is called chaddr), port security would not stop the attack. In this case, DHCP snooping must be enabled and configured to verify the source MAC address in the frame matches the client address field in the DHCP packet payload.

Here is an example configuration for port security on ports 1-48 for end-users, and DHCP snooping on VLANs 1-10 with trusting of DHCP information on port 49 for the uplink to the server:
3750(config)#interface range GigabitEthernet1/0/1 - 48
3750(config-if)#description Access Ports
3750(config-if)#switchport port-security
3750(config-if)#switchport port-security maximum 4
3750(config-if)#switchport port-security aging time 5
3750(config-if)#switchport port-security aging type inactivity
3750(config-if)#switchport port-security violation shutdown
3750(config)#interface GigabitEthernet1/0/49
3750(config-if)#description Uplink to DHCP Server
3750(config-if)#ip dhcp snooping trust
3750(config)#ip dhcp snooping
3750(config)#ip dhcp snooping vlan 1-10
3750(config)#ip dhcp snooping database t
3750(config)#ip dhcp snooping verify mac-address
DHCP Starvation in Unified Wireless Networks
In a Unified Wireless deployment, the vulnerability to perform a DHCP starvation attack depends on whether the WLC terminates the user traffic or an H-REAP AP terminates the user traffic.

Due to the 802.11 protocol definition, MAC address spoofing by wireless clients is prevented through the 802.11 association process. This prevents clients from spoofing the source address of the frame in addition to the DHCP client field in the payload.

The WLC protects the network from DHCP starvation attacks because it examines DHCP requests to ensure that the client MAC address matches the chaddr. If the addresses do not match, the DHCP request is dropped.

In the case of H-REAP, the user VLAN is terminated locally, the DHCP request does not go through the controller, and an analysis of the chaddr cannot be performed. In this case, the same security considerations apply for this method of access as they do for wired access. A smart (wireless) attacker uses the MAC address with which he or she is associated to the AP to generate the random DHCP requests, and then simply changes the requesting MAC address within the DHCP packet payload. To the AP, the packet looks valid because the originating MAC is the same as the MAC used to associate to the AP.

H-REAP can protect the network from DHCP starvation attacks when coupled with DHCP snooping on the switch.

Attack Mitigation on Wireless Networks
WLC Mitigation Steps:
  1. The 802.11 association process prevents MAC address spoofing.
  2. Verify DHCP Proxy is enabled on WLCs to prevent DHCP chaddr spoofing. This feature is enabled by default.
(Cisco Controller) >config dhcp proxy enable

(Cisco Controller) >show dhcp proxy

DHCP Proxy Behaviour: enabled

(Cisco Controller) >
H-REAP Mitigation Steps:
  1. The 802.11 association process prevents MAC address spoofing.
  2. Enable DHCP snooping on client VLANs on the switch to verify the source MAC address matches the chaddr address. Do not use DHCP rate limiting using the DHCP Snooping feature on switch ports connected to H-REAP APs because a violation will result in the switch port being shutdown.
Note – Do not enable port security on switch ports connected to H-REAP APs to prevent the switch from shutting down the port when a violation occurs due to wireless client roaming (MAC address seen on multiple ports) or excess MAC addresses (on a single port).

Armed with the proper tools, DHCP starvation can be prevented.



  1. Andrew: Magnificent post ! As we say, attacks often come from the inside. I've seen many customer networks without proper protection, "reaction mode" model. Hopefully, not all borrow that path. Keep on the good work !


  2. Andrew: is there a way to timeout clients which are associated but which do not proceed to webauth in an 'open' authentication like guest SSID using webauth ? If i leave the SSID 'open' in a crowded city office, i am afraid lot of unnecessary client associations will happen using up guest DHCP and also AP association table ?


  3. Hi Joe,
    The client idle timeout is the setting that you are looking for. The command is "config network usertimeout " which sets the amount of time a user is idle before the controller deletes their session. The default setting is 300 seconds (5 min).

    Be careful setting this too low, or may cause a bad user experience for all users on any SSID. If set too low (minimum is 90 sec), then the user session is deleted and they have to fully re-authenticate to get back on. This could cause a really bad user experience if they have to re-login all the time after just a short idle time.

    I think what would be more appropriate for you would be to set a low DHCP lease time. Even if you kick idle clients off the controller, the DHCP lease is still active on the server until it expires. For guest networks it is not uncommon to have DHCP lease timers as short as 2 hours, 1 hour, or 30 minutes, depending on the expected usage behavior by guests in your environment.


  4. Hi Andrew,
    I think usertimeout will affect my legitimate user also. I dont mind if a webauthenticated client remains idle, what i want to restrict is unwanted clients from automatically associating to my open guest ssid and not 'proceeding' to do webauth and remaining idle with just being associated to the AP. Is there any way to achieve this ?


  5. Hi Andrew,
    I dont mind my legitimate user from being idle after association and getting IP. But i am worried about the clients from nearby buildings, parks etc associating to our guest SSID and using up IP address and association table thus preventing 'our own' legitimate guests from getting wireless access. got my point ? So i want to know if there is an option in webauth or any other open L2 authentication method wherein i can specify timeout between 'association' and the client proceeding to 'authenticated' status ?

  6. Hi Joe,
    Guests connecting to an open Wi-Fi network with web-authentication are assigned an IP address prior to web authentication due to web-auth being performed at the application layer, they require an IP address and DNS resolution / redirection prior to authenticating.

    Your best option is to have a short DHCP lease time.