On 24/10/13 23:03, /dev/rob0 wrote:
On Thu, Oct 24, 2013 at 05:28:29PM +0100, 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.
Good stuff here, as usual, but questions still exist.
Yes, I think of dnsmasq in its original mission mostly: as a DNS
forwarder and provider of internal DNS for [DHCP usually] LAN hosts.
That seems to be the gist of your response here: to keep dnsmasq safe
from Internet attackers, don't expose dnsmasq to the Internet.
However, in the coming age of IPv6 and [we hope] the decline of NAT,
users will be more likely to want to expose dnsmasq to the Internet
as an authoritative nameserver. I can see the potential need for
serving both ip6.arpa zones and a zone such as "dh6.example.com" (the
--domain in dnsmasq terms.)
I have reviewed the "AUTHORITATIVE CONFIGURATION" section as well as
all the --auth-* settings in the manual, and I still have two
concerns:
1. Is there a way to designate interfaces which ONLY respond to
queries for our authoritative names? (--auth-server looks like it
might do this, but it does not quite say so.)
It does do exactly this, is you didn't understand that, it's a
documentation bug.
If I'm acting as NS
host for dh6.example.com and<whatever>.ip6.arpa, I need to respond
to those queries to anyone, but I don't want to let them look up
google.com nor lists.thekelleys.org.uk. For that matter, they
shouldn't even be able to get any names from /etc/hosts UNLESS those
names are in my zone.
That's what happens. In addition, ANY queries are no responded to for
auth zones.
2. Is there a way to limit the response rate on these queries on the
external IP address[es]?
No. I'm watching and waiting on that, but I'm not sure it makes sense.
The DNS amplification attacks work by sending a pre-crafted query with a
forged source address which is the address of the victim. The query is
designed to produce the biggest possible answer for the smallest
possible query so that as much bandwidth lands on the victim as possible
for the smallest bandwidth use by the attacker. This only really works
for recursive nameservers In the case of an authoritative-only server,
this won't work, since a query will not be in the zone, and therefore
will get an empty answer. The only way to make it work is for the
attacker to somehow determine which zone the server is authoritative
for, and generate a suitable query on-the-fly.
A third concern, which isn't quite relevant to this thread, but I
might as well mention anyway:
3. what about DNSSEC signing, will dnsmasq ever be able to serve
signed data?
The first priority for DNSSEC, indeed the first priority period, post
2.67, is DNSSEC validation. Once that's done, I figure I'll have enough
knowledge to approach the problem of signing.
I'm a big fan of dnsmasq, BTW; it has made the jobs of SMB/SOHO
network administrators much easier. The features I mention would
improve safety while exposed to the Internet, but I am not sure
they're worth the added size and code complexity.
It could well be best that dnsmasq should stick to its original
mission. Those who want advanced features could use it as a hidden
master for BIND (or other nameservers.) That part can work safely,
and the slave server could do inline signing.
An valid point. There's an internet draft around at the moment that I've
had some input to which proposes more-or-less exactly that.
http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-03
Cheers,
Simon.
PS to Simon, a note on your manual: you should stick to example names
for zones, not "our.zone.com" or "secondary.myisp.com". Note that
both zone.com and myisp.com exist (the former being owned by
Microsoft.) I'd consider perhaps s/com/example/ for those. Reference:
RFC 6761.
Also in three places you make reference to "ipv6.arpa", which in
other placess is correctly called "ip6.arpa".
Another very minor nitpick: under --interface you mention "IP alias
interfaces (eg "eth1:0")". Those aren't interfaces at all; only the
brokenness of Linux ifconfig(8) displays them as such. Please
consider changing "interfaces" there to "labels". Help stamp out
ignorance ... and even Linux net-tools itself! :)
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.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
