On 10/24/2013 4:40 PM, [email protected] 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, [email protected]
<mailto:[email protected]> <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
--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).
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
configuration is.
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
