[Dnsmasq-discuss] DNSMasq and DNS reflection attacks

[Brian Rak]

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?