[Dnsmasq-discuss] Restrict dhcpd listening interfaces.

[Simon Kelley]

On 27/03/12 15:18, Mark Wu wrote:
> Hi Simon,
>
> It seems that dnsmasq always listen on wildcard network interfaces for
> dhcp services even with the option "--interface" or "--listen-address"
> specified. And you gave the following explanation for that:
>
> Because a DHCP server has to cope with "strange" packets from
> unconfigured and half-configured clients, it's not possible always to
> bind the DHCP listening socket to an IP address.
>
> It's copied from:
> https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/307328/comments/1
>
> Could you please elaborate more about the "strange" packets ? Actually,
> the listening interface is configurable in the command line of dhcpd
> daemon (http://www.isc.org/software/dhcp) I think it could help avoid
> security risk and/or data privacy breach. Especially, when dnsmasq is
> used by libvirt, it doesn't make sense that dnsmasq listens on anly
> physical network interface. So do you think we could make the options
> "--listen-address" and "--interface" applied to dhcp service too like
> dns service in dnsmasq?


First, don't think that because dnsmasq binds the wildcard address, it 
will provide service on any interface. If you run dnsmasq with 
--interface=eth0, then any DHCP requests which arrive via other 
interfaces will be discarded at the first stage of packet processing in 
dnsmasq.

The strange packets have source address 0.0.0.0 and/or destination 
address 255.255.255.255. When an socket is bound to a particular 
address, it may not receive these packets. Some kernels work fine, but 
it's really moving into undefined territory and portable code which 
works everywhere is much easier when binding the wildcard.

Beware of comparisons with ISC dhcpd. It binds individual interface 
addresses, as you suggest, but it only uses those for the non-"strange" 
packets exchanged with fully configured hosts. dhcpd also opens the BPF 
or LPF raw packet socket for the "strange" packets. So in fact, far from 
limiting itself  to the packets from a single interface, dhcpd (with the 
help of BPF filters) is receiving and inspecting every single packet 
which arrives at the host. That's probably a bigger attack surface than 
dnsmasq has: it only needs to filter based on interface.

As to which approach is best, that's debatable. Dnsmasq's approach 
doesn't make the host inspect and demultiplex every packet twice (one in 
the IP stack and once in the packet filter) and it's more portable. (the 
ISC method needs different raw-packet access code for each platform) On 
the other hand, to be safe it needs binding the wildcard interface, 
which can cause problems, especially trying to run multiple daemons 
which listen on the same port.

This is something that was got right in DHCPv6. It's all done via 
multicast using well-defined portable APIs.


HTH

Simon.