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

[Simon Kelley]

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
>