Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

All this while, I assumed that switchport security is enough to prevent DHCP dos attack. If I set it maximum 1, there can be no more mac addresses packets.

But, a friend told me that using the tool, DHCPStarv, we can bypass that?

I want to know how it works?

I figured a way to prevent it by DHCP Snooping, but how does it bypass the switchport security? I don't see any logical answer. Please help me understand this. Thank you.

share|improve this question

1 Answer 1

up vote 1 down vote accepted

If you only allow ONE MAC through a port I can't see how DHCPstarv is going to work (unless it is some kind of distributed DHCPStarv attack).

DHCPStarv works by sending a lot of DHCP petitions so that the server doesn't have new IPs to provide to new clients. But if you can only ask for one a time it is not likely the attack is going to succeed.


After @RajesK comment (he has found the link answering his own question) I add the following:

Although one might think that countermeasures such as as Port Security would be more than enough to prevent such attacks, that is not true with tools like Yersinia or dhcpstarv. This is because Port Security only considers the MAC source of the frame to create filters and then set accordingly what MAC addresses are allowed on a specific port (useful against MAC flooding attacks). The problem here is that these tools do not change this MAC (as eg macof does), but randomize the field Client Hardware Address (CHADDR) inside the DHCP payload. This field, along with the client identifier, is of great importance as it will be used (see RFC 2131) by the server to distinguish between the various requests of different customers. Without that, it would be difficult to distinguish between the various users when using a DHCP Relay Agent.

This means that the problem is that the DHCP protocol itself rely not on the MAC of the client who ask for the new IP but for the CHADDR field inside the DHCP protocol so, in fact, from the very same MAC you can ask for thousands of petitions just changing the CHADDR field.

The solution is in the very same link:

Fortunately, DHCP Snooping is clever enough to read the payload of the DHCP protocol and verify that the source MAC address and CHADDR are the same (optional command ip dhcp snooping verify mac-address). It is also possible to set a “maximum threshold“, or number of packets per second that the switch can receive in a given port so, if the number of DHCP packets reaches this threshold, the port enters the shutdown mode (blocking) and it would generate a warning about the DoS.

Now, you are comparing the actual MAC address with the one inside the DHCP protocol so that when you find a different one you just discard the packet.


Saying this you should continue bear in mind the comments by @polynomial.

share|improve this answer
    
+1 on this. Often DHCP servers are reluctant to issue a new lease to a new MAC address when a DHCP release has just taken place. This is usually to help keep a device on the same IP if it just glitched out for a moment. By repeatedly cycling request/release across MACs your port only ever has one assigned MAC at any one point in time, but the IPs end up getting thrown into a temporary wait pool until they eventually dry up. It won't be 100% effective, but it'll probably mess the network up a bit. –  Polynomial Mar 4 at 12:00
    
@Polynomial Yeps, but the problem here is that usually, when you limit the MAC to one in a port you also give that MAC the very same IP so I don't think the DHCP server will run out of IPs, it will be just a matter of overloading the DHCP server (and I don't think it will succeed, but who knows... ) –  kiBytes Mar 4 at 12:09
    
The trick is to cycle MACs, so that you aren't using more than one at once, but get different leases. –  Polynomial Mar 4 at 13:13
1  
I know how DHCP Starvation attack works. Well, my "Friend" will not tell me how :/ Anyways, after searching alot, I found this. Even this states the same thing. Click Here Read the 9th para of that post. Either I understood things wrong, or there is a way to bypass it. Could someone please elaborate it for me? –  Rajesh K Mar 4 at 14:53
    
Oh, you just found your own answer, it is here: " The problem here is that these tools do not change this MAC (as eg macof does), but randomize the field Client Hardware Address (CHADDR) inside the DHCP payload. This field, along with the client identifier, is of great importance as it will be used (see RFC 2131) by the server to distinguish between the various requests of different customers. Without that, it would be difficult to distinguish between the various users when using a DHCP Relay Agent." –  kiBytes Mar 4 at 14:54

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.