On 10/24/2013 12:28 PM, Simon Kelley wrote:
On 24/10/13 17:03, Brian Rak wrote:
We've recently undertaken a project to clean up our network, and lock
down all the open DNS resolvers. As you may know, these are very
frequently used for DDOS attacks: http://openresolverproject.org/ ,
http://www.team-cymru.org/Services/Resolvers/ .
I haven't been able to find any sort of configuration option that would
prevent DNSMasq from being abused like this, and I've had to resort to
iptables rules instead. Is there a configuration option that that would
disable responding to DNS queries from certain interfaces? The other
option that seems handy would be one to only reply to DNS queries from
hosts that have a configured DHCP lease.
Are there any features of DNSMasq that would prevent it from being
abused to conduct attacks?
This is an important topic, and quite difficult to understand, so I'm
going to take this opportunity to try and put a definitive statement
on the record.
First the simple stuff.
Dnsmasq has --interface --except-interface and --listen-address
configuration options that disable response to DNS queries from
certain interfaces. The first thing that has to be done is to use
these. Mostly it's the only thing that needs to done.
Now, the complicated stuff.
Under certain circumstances, --interface=<interface> degrades to mean
the same as --listen-address=<address on interface>. For instance if
eth0 has address 192.168.0.1 and dnsmasq is configured with
--interface=eth0, then dnsmasq will reply to any query which is sent
to 192.168.0.1, no matter what interface it actually arrives at. The
circumstance under which happens is when the --bind-interfaces flag is
used.
Now, in the above example, this isn't a problem, since a botnet can't
direct traffic to an RFC-1918 address. If, on the other hand, the
address of an internal interface (ie one configured to accept DNS
queries) is globally routable, then queries which arrive via another
interface (ie one linked to the internet) with the destination address
of the internal interface _will_ be replied to, and a DNS reflection
attack is possible.
This has mainly been seen in libvirt and OpenStack installations which
use dnsmasq, since sometimes they are provisioned with "real"
addresses. I'd expect to see problems in the future with IPv6, since
far more people will be using globally routable addresses with IPv6.
The reason that this happens is that --bind-interfaces uses the
bare-minimum BSD sockets API only. Detecting which interface a packet
arrived on, rather than the address to which it was sent, needs
non-portable API, and is impossible on some platforms (openBSD, for
instance) --bind-interfaces is a "works everywhere" least common
denominator. It's also useful when you're running multiple instances
of dnsmasq on one host, which is why most people use it.
The fix is to use either the default listening mode, or if running
multiple instances, the new --bind-dynamic mode. --bind-dynamic is
only available on Linux, and --bind-interfaces is the only mode
available on openBSD, so BSD users have rather more problems here.
Summary. There's a problem is you want to accept queries in an
internal interface with a globally routable address and use
--bind-interfaces. The fix is to remove --bind-interfaces and, if
necessary, replace it with --bind-dynamic. This fix is not applicable
on all platforms,
The Real Soon Now 2.67 release logs a very prominent warning if the
dangerous combination is configured.
Cheers,
Simon.
Thanks for the detailed explanation! It seems that for some of my
servers I can resolve the issue by using --interface and --except-interface.
I do however have some DNSMasq instances that are providing public,
globally routable IP addresses via DHCP. In order to do this, DNSMasq
must be listening on an interface with a public IP, so it ends up
providing DNS on that IP as well. I'm not sure if this is a common use
case or not. For this setup, would there be any other option aside
from iptables rules?
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
