[Dnsmasq-discuss] DNSMasq and DNS reflection attacks
brak at gameservers.com
Thu Oct 24 17:46:55 BST 2013
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
> 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.
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?
More information about the Dnsmasq-discuss