[Dnsmasq-discuss] DNSMasq and DNS reflection attacks

Fri Oct 25 10:55:08 BST 2013

On 24/10/13 21:40, richardvoigt at gmail.com wrote:
> Sorry, I should mention only drop packets in state "NEW", you don't want to
> drop replies to your own queries.

Dropping replies to your own queries shouldn't be a problem. The queries 
originate from ports other than 53 (normally, a newly randomly-chosen 
port for each query) so the replies will not have destination port 53, 
whilst incoming queries will.

Simon.

>
>
> On Thu, Oct 24, 2013 at 3:39 PM, richardvoigt at gmail.com<
> richardvoigt at gmail.com>  wrote:
>
>> Your case should be easy to stop with a firewall rule.  Just block all
>> packets matching the dns listen port (53 usually) in the INPUT chain, where
>> the source address is outside your block.
>>
>> Optionally (this prevents reflection attacks against your own network
>> which you said is not required), configure your router to drop packets
>> arriving on its external interface where the source IP is within your
>> internal network.  This is called a reverse route check.
>>
>>
>> On Thu, Oct 24, 2013 at 12:11 PM, Brian Rak<brak at gameservers.com>  wrote:
>>
>>>
>>> On 10/24/2013 1:00 PM, Simon Kelley wrote:
>>>
>>>> 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://openresolverproject.org/>,
>>>>>>> http://www.team-cymru.org/**Services/Resolvers/<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.
>>>>
>>>
>>> Ah, but that's the problem.  The machines I'm referring to only have one
>>> interface.  So, I'm primarily running this on virtual machine hosts.  They
>>> have one connection to the internet, and no internal network.
>>>
>>> So, for example we have a virtual machine host running with eth0 being
>>> 198.51.100.10.  DNSMasq is configured to listen on eth0 and provide
>>> 198.51.100.11-198.51.100.15 for any virtual machines that start up (virtual
>>> machines are recognized by preconfigured static leases, all other DHCP
>>> requests are ignored).  The virtual machines are all bridged to the eth0
>>> interface, and have no other connectivity.
>>>
>>> I should also note that my primary concern is preventing my machines from
>>> being abused to attack other people's machines.   Cases where someone would
>>> abuse my DNS server to attack my own machines are not currently a concern
>>> (as they're significantly easier to block).
>>>
>>>
>>>
>>> ______________________________**_________________
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss at lists.**thekelleys.org.uk<Dnsmasq-discuss at lists.thekelleys.org.uk>
>>> http://lists.thekelleys.org.**uk/mailman/listinfo/dnsmasq-**discuss<http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>
>>>
>>
>>
>
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss