10-24-2014 12:57 AM
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/H
In this case, the controller apparently couldn't stop the attack. Anybody know how to stop this attack at wireless controller??
11-23-2014 04: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.
11-23-2014 09:29 PM
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.
11-24-2014 01: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??
03-05-2015 12: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.