Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I know there are a lot of solutions out there for mitigating DHCP starvation attacks. But wouldn't a really simple solution be to just set the DHCP address pool to 1.1.1.1 - 254.254.254.254 (or some other really large pool) so that the malicious entity cannot starve the entire pool within a practical time frame? Why is this not done?

Consider this in the context of a wireless network, with no encryption and no authentication (typical of free public wireless hotspots).

share|improve this question
3  
I thing that your example of 1.1.1.1-254.254.254.254 was a bad idea. Part of that isn't even valid since 127/8 is in there and the multicast range. You might want to consider updating the question to ask only about the 10/8 network which still provides you with ~2^24 addresses. –  Zoredache Oct 21 '09 at 0:26
    
Agree, but my main point is that a huge range is possible. –  TripShock Oct 21 '09 at 11:15
    
Last time I tried to set up a test DHCP server on Linux with a 10./8 block, the little box didn't have enough memory to deal with the bookkeeping involved for the leases, and the service would simply die due to a lack of memory (the box only had 256Mb). Unless you've got a beefy box, or you're recording things on disk (instead of in memory), I can only wonder if you could even get it running. –  Avery Payne Feb 24 '10 at 2:36

7 Answers 7

up vote 4 down vote accepted

Using the entire ip address space seems a bit excessive. Assuming you're talking about a contained environment (say behind a NAT) then you could use 10.0.0.0\8 without running into any routing related issues. Provided your actual network (ie the number of real machines) is small then the general problem of having a potentially huge broadcast domain is not really that relevant and if you set the lease time relatively low (a few minutes) you could ensure that it just wasn't practical for a single attacker to actually exhaust your range. However you would still have to fend off what might be a relatively large amount of traffic with millions of fake requests and it will be broadcast traffic remember so all the genuine devices on your network will see it too - so lots of spurious noise for everyone on the network to have to handle interrupts from. Your switches will start tracking all of these [fake] MAC\IP-address combinations now too so you're allowing your attacker to increase the amount of resources they consume, and those are finite too. For a serious attack I reckon DHCP exhaustion attack code probably push out requests faster than many DHCP servers can deal with if the scope is actually huge - the physical resources (CPU & RAM needed to handle the responses and tracking the table of active leases) on the DHCP server may eventually simply get consumed if the attacker can generate requests fast enough and the end result may be worse for you - you've now swapped a Denial of Service attack against new connections with an attack that might crash your DHCP server and Switches (and those might be exploitable).

If this is a valid concern, and you can't live with the possibility of DoS against clients you should use switches that have mechanisms to prevent this - there are specific DHCP starvation mitigation mechanisms like DHCP Snooping but just enabling controls to limit MAC address spoofing will generally help in this and also in CAM table flooding. The best approach is to enable port authentication but that is hard to implement in any large controlled environment and no use in an unmanaged scenario (such as a WiFi Hotspot). I don't believe there's a definitive general purpose solution, it's a case of balancing the risks of the various options available and selecting the one that works best in your environment.

share|improve this answer

There are many issues with this approach.

First of all, if you do what you expressed, you'll be effectively cutting yourself off from the internet, as that range includes (nearly) all possible IPv4 addresses.

Secondly, by doing this, you're setting yourself up for having to deal with a huge broadcast domain. Typical networking best practices recommend using small-ish subnets (say those having /22 or longer netmasks) to limit the size of your broadcast domains. With subnets larger than that, your routing and switchgear (depending on how robust they are), could get swamped with having to deal with that much broadcast traffic.

share|improve this answer
    
The broadcast domain point is interesting, but that doesn't seem like it would be an issue in the scenario described. a) There is no wireless hardware that could actually support enough clients for the broadcasting to be an issue (collisions are more likely issue since this is wifi). b) The OP is interested in DHCP starvation, once an address has been leased communication from that address would not continue, and only real devices will be broadcasting. –  Zoredache Oct 21 '09 at 0:39
2  
-1 - The size of a subnet has nothing to do with the size of a "broadcast domain". A "/24" being used in a given installation of access points and Ethernet switches has the same sized broadcast domain as a "/8" running on the same hardware. The number of physical ports / APs with which broadcast frames can be transmitted determines the size of the broadcast domain, not the number of bits in the subnet mask. –  Evan Anderson Oct 21 '09 at 1:30
1  
@Evan: thanks for saying what I wanted to say. The number of transmitting hosts determines the effective broadcast domain, not the subnet mask. If you've got 50 hosts then the broadcast domain is 50 hosts worth, regardless of the size of the subnet. The potential for a larger broadcast domain exists with a /8 or /16 subnet mask as the potential to have a larger number of hosts exists, but I suspect you wouldn't configure your network in such a way. –  joeqwerty Oct 21 '09 at 2:28
    
About the first point: The wireless router is probably connected to the internet through a wired interface, and clients are connected through a wireless interface. Isn't it possible for the router to distinguish between traffic coming from these two interfaces and route accordingly? The router can assume all traffic from the wireless interface needs to go to the wired interface and vice versa. This means cliens cannot comm. with each other but that is not required on a public wifi network anyways. Is it possible to implement this routing policy? –  TripShock Oct 21 '09 at 11:20
    
About the second point: Broadcast is scalable, that is its greatest strength. It does not depend on the number of hosts. For a broadcast, all that is needed is one packet. If you are talking about collision domain, that's a different story, but note that in a starvation attack, only one machine is spoofing all those extra packets, so the number of physical hosts associated with the network is still a manageable number. –  TripShock Oct 21 '09 at 11:22

Switch to IPv6!

Especially if you just use ICMP auto-negotiation without a DHCP server. :)

share|improve this answer
    
:D I'm not trying to find more solutions to this problem. I'm wondering why this solution is not valid! –  TripShock Oct 21 '09 at 11:23
2  
You'll break connectivity to the real servers that live at those IP addresses. –  MikeyB Oct 21 '09 at 14:37

Why not shorten the DHCP lease time so short as to frustrate the attacker with a losing battle :)

share|improve this answer
1  
Do you want all your valid clients to be renegotiating their lease frequently? Having to frequently renew will add more traffic to the wireless network. In an ideal world, I would imagine a smart dhcp server that will give a new client a very short lease, and each time it renews it gives out a longer lease. –  Zoredache Oct 21 '09 at 0:43
    
It depends how long it takes the attacker to negotiate a new address. If it takes 10 seconds then a 30 minute lease time will be little enough even if less than 200 addresses are available. As for extra traffic on the wireless network, most people don't spend much time in one public hotspot anyway. A compromise with a 4-hour lease time as well as more addresses might be best. –  simplr Oct 21 '09 at 10:56
    
Again, let's refrain from discussing other solutions, I know there are a zillion ways out there to tackle this problem. I'm just considering alternatives (or why they are not alternatives :) ) –  TripShock Oct 21 '09 at 15:29

There's no trivial solution because it's not a trivial problem.

At the heart of it, DoS attacks on a wireless Ethernet installation, be they something "intelligent" like a DHCP scope exhaustion attack, or something "brainless" like a transmitter flooding the spectrum used by the radios, can't be stopped because radios can't selectively ignore signals from any given transmitter. The air is a shared medium, and that's just physics.

In a wired Ethernet, you could turn off the port that excessive DHCP requests (or other types of DoS attacks) are being sourced from. Short of disabling the access point where the excessive DHCP requests are coming from (and disabling every mobile unit associated with that AP), there's nothing "trivial" you can do.

share|improve this answer

The best way to mitigate this is on the switch level - check this for a detailed explanation of the attack and the mitigation: dhcp-starvation-quick-and-dirty

share|improve this answer

If you did that then you'd introduce the need to set up a large number of routes, layer 3 switches, DHCP relay agents, access control lists, firewall rules, etc. Imagine my server is at 10.1.1.1, my gateway is at 10.1.1.2 and my DHCP client is at 167.10.1.250: now I need a way to route traffic from my client to my server and to the gateway, to other clients that get ip addresses on another subnet, etc. It would make the network practically unusable. The management of such a network would be practically impossible.

share|improve this answer
    
Hmmm... I don't get it. Why the downvote on my answer? –  joeqwerty Oct 20 '09 at 23:24
1  
Because your answer isn't really that well worded, and somewhat confusing. To clean it up, perhaps you should explain a bit more about why you would need multiple routes. –  Zoredache Oct 21 '09 at 0:21
    
Seriously, my answer was not meant to be a network tutorial. It was meant to be a quick and dirty "here's some of the issues you'd face" answer. I could write a book on why you wouldn't set up a network the way the OP described, but that wasn't the point of my answer. Do I have to write a complete, unabridged conpendium for every answer I post on this site. I don't have a problem with downvotes when I'm wrong but I get pretty tired of downvotes based on someone else's arbitrary judgement because they don't like my wording. My answer is technically accurate and that's what should count. –  joeqwerty Oct 21 '09 at 1:05
    
See my second comment on the first post and then come back to this comment. Is it possible to install a route like: "All traffic from wireless -> Wired port to internet" and "All traffic from internet -> Wireless". Assume the network is simple, just one wireless access point which has the DNS server, DHCP server running on it. No relays, etc. Bare minimum network. –  TripShock Oct 21 '09 at 11:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.