<div dir="ltr">In lieu of state tracking, I believe you can configure dnsmasq to use a different port when making requests of upstream servers, so replies don't match the "inbound to port 53" rule. Or just unconditionally allow upstream servers only as you mentioned.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 24, 2013 at 5:41 PM, Brian Rak <span dir="ltr"><<a href="mailto:brak@gameservers.com" target="_blank">brak@gameservers.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
On 10/24/2013 4:40 PM, <a href="mailto:richardvoigt@gmail.com" target="_blank">richardvoigt@gmail.com</a> wrote:<br>
<blockquote type="cite">
<div dir="ltr">Sorry, I should mention only drop packets in state
"NEW", you don't want to drop replies to your own queries.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Oct 24, 2013 at 3:39 PM, <a href="mailto:richardvoigt@gmail.com" target="_blank">richardvoigt@gmail.com</a>
<span dir="ltr"><<a href="mailto:richardvoigt@gmail.com" target="_blank">richardvoigt@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.
<div>
<br>
</div>
<div>
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.</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Oct 24, 2013 at 12:11
PM, Brian Rak <span dir="ltr"><<a href="mailto:brak@gameservers.com" target="_blank">brak@gameservers.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div><br>
On 10/24/2013 1:00 PM, Simon Kelley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 24/10/13 17:46, Brian Rak wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 10/24/2013 12:28 PM, Simon Kelley
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 24/10/13 17:03, Brian Rak wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We've recently undertaken a project to
clean up our network, and lock<br>
down all the open DNS resolvers. As
you may know, these are very<br>
frequently used for DDOS attacks: <a href="http://openresolverproject.org/" target="_blank">http://openresolverproject.org/</a>
,<br>
<a href="http://www.team-cymru.org/Services/Resolvers/" target="_blank">http://www.team-cymru.org/Services/Resolvers/</a>
.<br>
<br>
I haven't been able to find any sort
of configuration option that would<br>
prevent DNSMasq from being abused like
this, and I've had to resort to<br>
iptables rules instead. Is there a
configuration option that that would<br>
disable responding to DNS queries from
certain interfaces? The other<br>
option that seems handy would be one
to only reply to DNS queries from<br>
hosts that have a configured DHCP
lease.<br>
<br>
Are there any features of DNSMasq that
would prevent it from being<br>
abused to conduct attacks?<br>
<br>
</blockquote>
<br>
<br>
This is an important topic, and quite
difficult to understand, so I'm<br>
going to take this opportunity to try
and put a definitive statement<br>
on the record.<br>
<br>
First the simple stuff.<br>
<br>
Dnsmasq has --interface
--except-interface and --listen-address<br>
configuration options that disable
response to DNS queries from<br>
certain interfaces. The first thing that
has to be done is to use<br>
these. Mostly it's the only thing that
needs to done.<br>
<br>
<br>
Now, the complicated stuff.<br>
<br>
Under certain circumstances,
--interface=<interface> degrades
to mean<br>
the same as --listen-address=<address
on interface>. For instance if<br>
eth0 has address 192.168.0.1 and dnsmasq
is configured with<br>
--interface=eth0, then dnsmasq will
reply to any query which is sent<br>
to 192.168.0.1, no matter what interface
it actually arrives at. The<br>
circumstance under which happens is when
the --bind-interfaces flag is<br>
used.<br>
<br>
Now, in the above example, this isn't a
problem, since a botnet can't<br>
direct traffic to an RFC-1918 address.
If, on the other hand, the<br>
address of an internal interface (ie one
configured to accept DNS<br>
queries) is globally routable, then
queries which arrive via another<br>
interface (ie one linked to the
internet) with the destination address<br>
of the internal interface _will_ be
replied to, and a DNS reflection<br>
attack is possible.<br>
<br>
This has mainly been seen in libvirt and
OpenStack installations which<br>
use dnsmasq, since sometimes they are
provisioned with "real"<br>
addresses. I'd expect to see problems in
the future with IPv6, since<br>
far more people will be using globally
routable addresses with IPv6.<br>
<br>
The reason that this happens is that
--bind-interfaces uses the<br>
bare-minimum BSD sockets API only.
Detecting which interface a packet<br>
arrived on, rather than the address to
which it was sent, needs<br>
non-portable API, and is impossible on
some platforms (openBSD, for<br>
instance) --bind-interfaces is a "works
everywhere" least common<br>
denominator. It's also useful when
you're running multiple instances<br>
of dnsmasq on one host, which is why
most people use it.<br>
<br>
The fix is to use either the default
listening mode, or if running<br>
multiple instances, the new
--bind-dynamic mode. --bind-dynamic is<br>
only available on Linux, and
--bind-interfaces is the only mode<br>
available on openBSD, so BSD users have
rather more problems here.<br>
<br>
Summary. There's a problem is you want
to accept queries in an<br>
internal interface with a globally
routable address and use<br>
--bind-interfaces. The fix is to remove
--bind-interfaces and, if<br>
necessary, replace it with
--bind-dynamic. This fix is not
applicable<br>
on all platforms,<br>
<br>
The Real Soon Now 2.67 release logs a
very prominent warning if the<br>
dangerous combination is configured.<br>
<br>
Cheers,<br>
<br>
Simon.<br>
</blockquote>
<br>
Thanks for the detailed explanation! It
seems that for some of my<br>
servers I can resolve the issue by using
--interface and<br>
--except-interface.<br>
<br>
I do however have some DNSMasq instances
that are providing public,<br>
globally routable IP addresses via DHCP.
In order to do this, DNSMasq<br>
must be listening on an interface with a
public IP, so it ends up<br>
providing DNS on that IP as well. I'm not
sure if this is a common use<br>
case or not. For this setup, would there
be any other option aside from<br>
iptables rules?<br>
</blockquote>
<br>
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.<br>
<br>
An example:<br>
<br>
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.<br>
<br>
So, don't use --bind-interfaces. If you're
on Linux, you can use --bind-dynamic instead
if you're running multiple dnsmasq
instances.<br>
<br>
Cheers,<br>
<br>
Simon.<br>
</blockquote>
<br>
</div>
</div>
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.<br>
<br>
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.<br>
<br>
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).
<div>
<div><br>
<br>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote></div></div>
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.<br>
<br>
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.<br>
<br>
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.
</div>
<br>_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
<br></blockquote></div><br></div>