[Dnsmasq-discuss] DNSMasq and DNS reflection attacks

richardvoigt at gmail.com richardvoigt at gmail.com
Thu Oct 24 21:40:19 BST 2013


Sorry, I should mention only drop packets in state "NEW", you don't want to
drop replies to your own queries.


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>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20131024/2674c048/attachment-0001.html>


More information about the Dnsmasq-discuss mailing list