<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>