[Dnsmasq-discuss] DNSMasq and DNS reflection attacks
brak at gameservers.com
Thu Oct 24 23:41:09 BST 2013
On 10/24/2013 4:40 PM, 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.
> On Thu, Oct 24, 2013 at 3:39 PM, richardvoigt at gmail.com
> <mailto:richardvoigt at gmail.com> <richardvoigt at gmail.com
> <mailto: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
> <mailto: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://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
> 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
> 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.
> 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).
Yep, currently we just block all incoming DNS unless it's from the
upstream resolvers or any of the configured DHCP ranges. We try to
avoid state tracking whenever possible, because it's really easy to fill
up the state tables on big web servers.
I was hoping there was a DNSMasq option that would address this issue,
just as an added layer. It's very easy for iptables rules to get
removed or disabled, but it's less likely that someone would unknowingly
remove a configuration option.
A configuration option to only respond to DNS from hosts with a valid
DHCP lease would help with my setup, but I'm not sure how common my
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dnsmasq-discuss