[Dnsmasq-discuss] no-ping option treats hosts as 'cannot ping'

[Joolee]

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.
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.

Thank you for your time.

On 12 February 2016 at 17:25, Simon Kelley <simon at thekelleys.org.uk> wrote:

> On 10/02/16 22:39, Joolee wrote:
> > I am currently doing some testing with DHCP Spoofing and DHCP Starvation
> > attacks. When performing the starvation attack with pig.py, I noticed
> that
> > dnsmasq keeps assigning the same IP addresses over and over again with
> > consecutive runs. That is potentially great from a security point of view
> > but not what I had in mind (I wasn't testing dnsmasq's resiliency)
> >
> > I was testing with this command line:
> > dnsmasq --no-daemon --dhcp-range=10.0.10.50,10.0.10.100,5m
> > --dhcp-option=option:router,10.0.10.1
> >
> > First thing you will think now is, dnsmasq does a ping check after
> > assigning an IP address and when no reply is received, the address goes
> > back to 'available'.
>
> No, you have it precisely backwards. The ping check is to make sure that
> the IP address is not in use by some other computer which is either
> static configured, or has a DHCP lease from another server, or has a
> DHCP lease but it's got lost due to a server reboot or similar. Dnsmasq
> picks an address for the new DHCP lease and sends a ping to it. The
> expected case is that no reply arrives, in which case the address is
> offered to the DHCP client. If there is a reply, then a different
> address is chosen, and the process repeats.
>
>
> > pig.py doesn't actually start listening on the
> > received IP addresses so no ping will ever be returned.
> > That's what I thought to, so I tried using the --no-ping option to try
> and
> > disable this behaviour. And started running pig.py in an endless loop.
> >
> > dnsmasq --no-ping --no-daemon --dhcp-range=10.0.10.50,10.0.10.100,5m
> > --dhcp-option=option:router,10.0.10.1
> >
> > This seemed to work, I got messages telling 'no address available' in the
> > dnsmasq log output. After a while though, IP addresses where assigned
> > again, and again, and again... No help there. Of course, I dove into the
> > dnsmasq source and found out that after assigning an addres via DHCP, the
> > address gets 'blacklisted' for thirty seconds, after which it
> automatically
> > becomes available again, unless a ping response has been received in the
> > mean time.
>
> There is a 30 second timeout, but it's not to do with addresses coming
> "available", it's an optimisation to avoid running the ping-check
> repeatedly for the same address, since it's a costly operation.
> >
> > The --no-ping option disables the actual pinging but doesn't disable the
> > thirty second timeout. Thus *all* assigned IP addresses become available
> > again after just 30 seconds using this option! Not only does this count
> as
> > unexpected behaviour (in my eyes), this also tells me that when my
> servers
> > won't respond to ping calls, their IP addresses will be free-for-all
> after
> > just thirty seconds!
> >
> > I don't know what to expect when a server doesn't reply to a ping using
> > normal dnsmasq options, but when the --no-ping option is set, I expect
> > dnsmasq to return to the default behaviour of expiring addresses only
> after
> > lease-time has expired. This sounds like a bug to me. Is this by design,
> am
> > I doing something wrong or is this really a bug?
>
>
> I think you're confusing ping replies with DHCP replies. The sequence is
> the a client sends a DHCPDISCOVER and dnsmasq replies with an address in
> a DHCPOFFER (if the ping-check succeeds, ie nothing reposonds) At this
> point, the address is NOT allocated, indeed no state has changed at all
> in dnsmasq.
>
> Normally, the client replies to the DHCPOFFER with a DHCPREQUEST.
> dnsmasq replies with DHCPACK and only  then is the address allocated. I
> don't know what your pig.py is doing, but it sounds like it may just be
> sending DHCPDISCOVER over and over again. In that case I'd expect
> dnsmasq to send the send reply to each DHCPDISCOVER.
>
> In the normal case that dnsmasq is getting DHCPDISCOVER reguests nearly
> simultaneously from many different clients, the addresses in the
> DHCPOFFERS will normally be different for different clients, not because
> an address gets reserved at OFFER time, but because they're generated
> using a hash of the client MAC address. In the event that two clients
> get OFFERed the same address because if a hash collision, then the first
> to send a DHCPREQUEST will get the address (and a DHCPACK) the second
> will get a DHCPNAK and have to go around again and get a different address.
>
>
>
> Cheers,
>
> Simon.
>
>
> >
> > Kind regards,
> > Peter Overtoom
> >
> >
> >
> > _______________________________________________
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss at lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160213/a381de6b/attachment-0001.html>