Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

dhcp startvation attack

This thread has been viewed 7 times
  • 1.  dhcp startvation attack

    Posted Oct 24, 2014 03:57 AM

    Hello,

    I'm researching some way to avoid dhcp startvation attack from wireless network, regarding to this post http://www.airheads.eu/t5/Controller-Based-WLANs/How-to-prevent-a-client-from-sending-multiple-DHCP-dicoveries/ta-p/180196  I have seen that Statefull Firewall can stop this attack when source MAC is different from client's hardware addres, but there is really known tools like yersinia that can start a startvation attack using lots of packets with the same spoofed MAC and client hardware address.

     In this case, the controller apparently couldn't stop the attack. Anybody know how to stop this attack at wireless controller??

     

    Thank you

     



  • 2.  RE: dhcp startvation attack

    Posted Nov 23, 2014 07:49 AM

    i don't think you can at the controller. at some point it will just have to trust that the requests are legal.

     

    you might be able to do something on your upstream devices, though that might be tricky also.

     

    anyway there is always a difference about what is possible and what is done. i haven't heard about any large scale dhcp starvation attacks.



  • 3.  RE: dhcp startvation attack

    Posted Nov 24, 2014 12:30 AM

     

    Starvation attacks that don't change the MAC are relying on the DHCP server to respond with different addresses for different DHCP client identifiers.  Unless you have a use case for multiple

    leases per MAC, you should look for ways to shut this down at the DHCP server.

     

    Assuming you are running ISC dhcpd, unfortunately the best way to shut it down ("ignore client-id")

    is too new to be available as supported packages in many distros yet.  If you have the leeway

    to use a newer version of dhcpd that has this option, it also fixes some issues where androids

    can unintentionally exhaust several addresses.

     

    Otherwise you can configure the DHCP server to cancel existing leases when the same MAC requests a new lease ("deny duplicates").  This isn't a perfect solution because of the abovementioned problem with Androids.

     

    Both options are standards violations, but necessary ones when you harden a network.

     

    Windows DNS admins may be able to point towards similar options if you do that instead of ISC.

     



  • 4.  RE: dhcp startvation attack

    Posted Nov 24, 2014 04:16 AM

    Usually, if you make this attack, you use tools like "yersinia" or "dhcpstarv" that flood for DHCP DISCOVER using random MAC address and the same fake MAC and hardware client address, so those huge packets seem legal for a DHCP Server (they come from different MAC) . The Server then sends "OFFERS" and block the ip offered from the pool. given that the transaction is not done for any DISCOVER received, then the pool is exahusted until the server reaches the limit threshold time for each transaction.

    So, the result is a DOS for DHCP.

    It's really true that this type of attack is not usual, but it's really easy to do from the wireless side, in our environnment (university), any student could do it and our responsability is avoid it.

    I was thinking in some sort of configuration at Firewall parameters like enabling "IP Session Attack" which can block UDP session per second coming from a wireless client.

     

    Anyone have checked it??



  • 5.  RE: dhcp startvation attack

    Posted Mar 05, 2015 02:58 PM

    ¬¬

     

    Any news?



  • 6.  RE: dhcp startvation attack

    Posted Mar 05, 2015 03:11 PM

    News for what?  The Firewall DHCP exhaustion prevention prevents spoofing MACs.  If the MACs cannot be spoofed, the attacks that use client IDs can be shut down with a new enough DHCP server, optioned correctly to prevent multiple leases per MAC.  Case closed.