DDOS prevention - how to restrict queries to hint (root) zones?

[Mark Andrews]

In message <alpine.LFD.2.00.0902031018440.20200 at maplepark.com>, David Forrest writes:
> On Tue, 3 Feb 2009, Mark Andrews wrote:
> 
> >
> > In message <1233658532.12933.42.camel at muccalla.uninsubria.it>, MAtteo HCE Valsa
> > sna writes:
> >> hi all,
> >>
> >> We run BIND 9.3.4-P1.1 on Debian GNU/Linux 4.0 (using the distribution's
> >> package), that do both recursive queries for internal clients (with
> >> proper allow-recursion clause) and authoritative servers for the
> >> institution's domain.
> >>
> >>
> >> There are reports of DDOS attacks based on DNS requests for the root
> >> zone with spoofed source IP address:
> >> * the attacker sends a request for the root zone with spoofed source
> >> address to a DNS server
> >> * The intermediate victim (DNS server) sends the reply packet -
> >> significatively larger than the request - to the ultimate victim (the
> >> owner of the spoofed source IP address in the request packet).
> >> * the ultimate victim connection is flooded
> >>
> >> http://isc.sans.org/diary.html?storyid=5773
> >>
> >>
> >> I verified that our servers reply when queried from a non-trusted source
> >> address for the root zone. (and we must also notice that the
> >> "non-trusted source address" argument is pretty pointless when dealing
> >> with spoofed source addresses: if a query with a spoofed internal source
> >> address could reach the server, the server would just DDOS an internal
> >> machine. But we do discard inbound packets with internal source IP
> >> addresses on the network border).
> >>
> >> The first answer to this threat would be to disallow queries for the
> >> root zone would for any client (the root zone is used only by the server
> >> itself, right?).
> >>
> >> * Do you think there is any reason NOT do do this?
> >>
> >> * Do you know a simple way to do this?
> >>
> >>         the trivial solution of adding an allow-query clause to the root
> >>         zone definition is refused by the server, as hint type zones
> >>         cannot have an allow-query clause - see
> >>         https://lists.isc.org/pipermail/bind-users/2006-January/061077.html
> >>
> >>         there is possibly a way to do this using views, but...
> >>         anything simpler?
> >
> > 	options {
> > 		allow-query { recusrsive-clients; };
> > 		allow-recursion { recusrsive-clients; };
> > 	};
> >
> > 	zone {
> > 		type (slave|master);
> > 		...
> > 		allow-query { any; };
> > 	};
> >
> > 	Or upgrade to BIND 9.4 or later and use allow-query-cache,
> > 	BIND 9.3 is past end-of-life.
> >
> > 	Mark
> >
> >> best regards and thanks for any answer
> >>
> >>
> >> MAtteo Valsasna
> 
> Using allow-query to deny some queries still takes time and resources from 
> your server as it then sends a "denied" message back to the query source. 
> As the source is spoofed it then contributes in a small way to the DDoS 
> attack.  I think it is better to just drop the queries on your firewall. 
> I found this entry for iptables on the list a while back and it works 
> well and drops around a thousand queries a day.
> 
> iptables -A INPUT -i $LOCALIF -j DROP -p udp --dport domain -m u32 --u32  "0>>22&0x3C at 12>>16=1&&0>>22&0x3C
> @20>>24=0&&0>>22&0x3C at 21=0x00020001"

Well you opinion does not match the collective wisdom of dnsop and
dnsext working groups.  These working groups looks at the issue a
while ago and concluded that sending REFUSED was the best response
overall.  Unless you know the packet was forged then dropping it
does additional damage.  Send REFUSED turns you from a amplifies
into a obscurer.

The best thing you can do is make sure that you have deployed BCP
38 on your network.  This will prevent you being a source of spoofed
traffic.

The next best thing you can do is track or get your ISP to track
the offending traffic back to its source and request the BCP 38 be
deployed there.

That way everybody in the world is in a better position.  You can't
detect all reflection attacks at the reflector.  This one is a easy
one to detect.  You can however work to close down the holes in the
global BCP 38 defences.  This attack provides a perfect opportunity
to chase down those holes.

Mark

> -- 
> David Forrest 
> St. Louis, Missouri
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org