<div dir="ltr"><div>You are quite right Simon. The mistake was on my part, I didn't think VMware ESXi Standard switches would protect against a DHCP Starvation attack from pig.py so I wasn't looking in the right direction. It seems the standard switches do protect, even with both "MAC address changes" and "Forged Transmits" options set to Accept. The DHCP requests reach the DHCP server running on dnsmasq but the offers never get back to pig.py that, obviously, can't send ACK packets back to the DHCP server. Having never received any ACK packets, dnsmasq correctly starts handing out these IP addresses again after 30 seconds. Some simple packet sniffing and comparing with promiscuous mode set to Accept, pointed this out to me.<br></div>Noteworthy is that on a vCenter Distributed switch, the DHCP requests from pig.py never even reach the DHCP server when you turn the "MAC address changes" option to Reject. This is different from the Standard switches where the requests themselves were never being blocked with any combination of options.<br><div class="gmail_extra"><br></div><div class="gmail_extra">Thank you for your time.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 February 2016 at 17:25, Simon Kelley <span dir="ltr"><<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/02/16 22:39, Joolee wrote:<br>
> I am currently doing some testing with DHCP Spoofing and DHCP Starvation<br>
> attacks. When performing the starvation attack with pig.py, I noticed that<br>
> dnsmasq keeps assigning the same IP addresses over and over again with<br>
> consecutive runs. That is potentially great from a security point of view<br>
> but not what I had in mind (I wasn't testing dnsmasq's resiliency)<br>
><br>
> I was testing with this command line:<br>
> dnsmasq --no-daemon --dhcp-range=10.0.10.50,10.0.10.100,5m<br>
> --dhcp-option=option:router,10.0.10.1<br>
><br>
> First thing you will think now is, dnsmasq does a ping check after<br>
> assigning an IP address and when no reply is received, the address goes<br>
> back to 'available'.<br>
<br>
</span>No, you have it precisely backwards. The ping check is to make sure that<br>
the IP address is not in use by some other computer which is either<br>
static configured, or has a DHCP lease from another server, or has a<br>
DHCP lease but it's got lost due to a server reboot or similar. Dnsmasq<br>
picks an address for the new DHCP lease and sends a ping to it. The<br>
expected case is that no reply arrives, in which case the address is<br>
offered to the DHCP client. If there is a reply, then a different<br>
address is chosen, and the process repeats.<br>
<span class=""><br>
<br>
> pig.py doesn't actually start listening on the<br>
> received IP addresses so no ping will ever be returned.<br>
> That's what I thought to, so I tried using the --no-ping option to try and<br>
> disable this behaviour. And started running pig.py in an endless loop.<br>
><br>
> dnsmasq --no-ping --no-daemon --dhcp-range=10.0.10.50,10.0.10.100,5m<br>
> --dhcp-option=option:router,10.0.10.1<br>
><br>
> This seemed to work, I got messages telling 'no address available' in the<br>
> dnsmasq log output. After a while though, IP addresses where assigned<br>
> again, and again, and again... No help there. Of course, I dove into the<br>
> dnsmasq source and found out that after assigning an addres via DHCP, the<br>
> address gets 'blacklisted' for thirty seconds, after which it automatically<br>
> becomes available again, unless a ping response has been received in the<br>
> mean time.<br>
<br>
</span>There is a 30 second timeout, but it's not to do with addresses coming<br>
"available", it's an optimisation to avoid running the ping-check<br>
repeatedly for the same address, since it's a costly operation.<br>
<span class="">><br>
> The --no-ping option disables the actual pinging but doesn't disable the<br>
</span>> thirty second timeout. Thus *all* assigned IP addresses become available<br>
<span class="">> again after just 30 seconds using this option! Not only does this count as<br>
> unexpected behaviour (in my eyes), this also tells me that when my servers<br>
> won't respond to ping calls, their IP addresses will be free-for-all after<br>
> just thirty seconds!<br>
><br>
> I don't know what to expect when a server doesn't reply to a ping using<br>
> normal dnsmasq options, but when the --no-ping option is set, I expect<br>
> dnsmasq to return to the default behaviour of expiring addresses only after<br>
> lease-time has expired. This sounds like a bug to me. Is this by design, am<br>
> I doing something wrong or is this really a bug?<br>
<br>
<br>
</span>I think you're confusing ping replies with DHCP replies. The sequence is<br>
the a client sends a DHCPDISCOVER and dnsmasq replies with an address in<br>
a DHCPOFFER (if the ping-check succeeds, ie nothing reposonds) At this<br>
point, the address is NOT allocated, indeed no state has changed at all<br>
in dnsmasq.<br>
<br>
Normally, the client replies to the DHCPOFFER with a DHCPREQUEST.<br>
dnsmasq replies with DHCPACK and only  then is the address allocated. I<br>
don't know what your pig.py is doing, but it sounds like it may just be<br>
sending DHCPDISCOVER over and over again. In that case I'd expect<br>
dnsmasq to send the send reply to each DHCPDISCOVER.<br>
<br>
In the normal case that dnsmasq is getting DHCPDISCOVER reguests nearly<br>
simultaneously from many different clients, the addresses in the<br>
DHCPOFFERS will normally be different for different clients, not because<br>
an address gets reserved at OFFER time, but because they're generated<br>
using a hash of the client MAC address. In the event that two clients<br>
get OFFERed the same address because if a hash collision, then the first<br>
to send a DHCPREQUEST will get the address (and a DHCPACK) the second<br>
will get a DHCPNAK and have to go around again and get a different address.<br>
<br>
<br>
<br>
Cheers,<br>
<br>
Simon.<br>
<br>
<br>
><br>
> Kind regards,<br>
> Peter Overtoom<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Dnsmasq-discuss mailing list<br>
> <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
><br>
<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div><br></div></div>