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-if)#exit
3750(config)#interface GigabitEthernet1/0/49
3750(config-if)#description Uplink to DHCP Server
3750(config-if)#ip dhcp snooping trust
3750(config-if)#exit
3750(config)#ip dhcp snooping
3750(config)#ip dhcp snooping vlan 1-10
3750(config)#ip dhcp snooping database tftp://remotehost.company.com/3750dhcpsnoop.txt
3750(config)#ip dhcp snooping verify mac-address
3750(config)#end
3750#

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.

Cheers,

Andrew