Bind ANY ANY Query Denial of Service

[Mark Andrews]

> We are a large national ISP and we have a number of BIND DNS Caching
> servers around the country for our customers.
> 
> We've been victims of multiple Denial of Service attacks against our
> BIND DNS servers.  Now normally this isn't an issue because we do not
> allow Recursion for IP's we don't own, as well as we can make use of
> BIND's wonderful ability to blackhole IP #'s.
> 
> The problem comes from this.   We have out to our customer base a huge
> number of CPE routers deployed that contain a bug which allows any IP
> to query the CPE router for DNS and it will simply just forward the
> request off to it's primary DNS server.  The CPE is not smart, and the
> way it's configured we can not disable the DNS settings, as well as it
> is a massive undertaking to upgrade all the CPE in the field (tens of
> thousands of them) to the latest patch in any reasonable amount of
> time.
> 
> The DoS attacks are targeted at our entire IP blocks, and because of
> the above mentioned bug, any of these CPE that happen to get hit will
> forward the DNS request to our caching servers.  So it appears we are
> being attacked by our own customer base.   When this happens we get
> thousands of queries from thousands of our own IP's that are all
> querying for  ANY ANY.
> 
> To my knowledge ANY ANY is not a valid query and BIND simply returns a
> list of ROOT servers.
> 
> The problem now is that if we blackhole the IP's that this comes from,
> we are blocking our customers from using DNS and it's not even their
> fault.
> 
> We've been around a million ways to solve this problem but we need a
> fast way to make BIND not respond to this type of query, until we can
> fix the greater problem which is patching all of the CPE to a version
> that does not allow DNS forwarding from external interfaces.  (ya
> pretty dumb)
> 
> The simple solution from our stand point is to have BIND not respond to
> this type of query.  And rather, just ignore the ANY ANY query or
> blackhole it.   I've included a sample from the QUERY logs to show what
> we see when this happens.
> 
> SHould it even be responding to ANY ANY queries?  That seems invalid,
> maybe this is a bug?

	No, it is a legitmate query as far as the protocol is concerned.
 
> Thousands and thousands of these from thousands of IP's:
> 
> Aug  9 16:58:15 ns1.iad named[3718]: [ID 866145 local5.info] client
> 209.125.200.66#53: query: . ANY ANY +
> Aug  9 15:58:14 ns1.ord named[27662]: [ID 866145 local5.info] client
> 72.20.18.17#6442: query: . ANY ANY +
> Aug  9 15:58:14 ns1.pdx named[27662]: [ID 866145 local5.info] client
> 72.20.18.17#6442: query: . ANY ANY +
> Aug  9 15:58:14 ns1.sjc named[27662]: [ID 866145 local5.info] client
> 72.20.18.17#6442: query: . ANY ANY +
> 
> 
> Any help or direction you could provide is much appreciated.

	Modify the source to detect and drop it.  See bin/named/query.c

	Use a firewall which allows you to drop arbitary packets
	based on payload.  ./ANY/ANY is 0x00, 0x00, 0xff, 0x00,
	0xff starting at the 13th octet of the UDP payload add to
	that you servers IP address and destination port 53 you
	should be able to stop just these packets reaching named.

	Note there really is no way to prevent this attack other
	than fixing the CPE.  There are plenty of other query
	patterns that are just as effective.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org