[Dnsmasq-discuss] DNSMasq and DNS reflection attacks

[Simon Kelley]

On 24/10/13 17:46, Brian Rak wrote:
>
> 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?

Yes, use --interface to enable that interface for DNS and DHCP, and 
DON'T use --bind-interfaces. As long as you're not using bind 
interfaces, DNS requests which arrive via other interfaces won't be 
answered, even if they have destination addresses for the enabled interface.

An example:

You have a router with two interfaces, internal and external. Internal 
is where you're doing DHCP and DNS: it's connected to an ethernet with a 
load of hosts. Internal has a globally routable address (and so, 
presumably do the hosts on the ethernet). External also has a globally 
routeable address and is connected to internet. Attack packets therefore 
arrive on external. Setting --interface=internal means that attack 
packets which arrive via external will NOT be answered, ever. The 
exception to this if they are addressed to the IP address of internal 
AND --bind-interfaces is set.

So, don't use --bind-interfaces. If you're on Linux, you can use 
--bind-dynamic instead if you're running multiple dnsmasq instances.

Cheers,

Simon.

>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>