DNS Amplification attack?

Wed Jan 21 22:49:26 UTC 2009

In message <497705BD.33E4.0097.0 at globalstar.com>, "Crist Clark" writes:
> >>> On 1/20/2009 at 7:23 PM, Mark Andrews <Mark_Andrews at isc.org> wrote:
> 
> > In message <20090121140825.xwdzd4p64kgwo4go at web1.nswh.com.au>,=20
> > jay at miscreant.or=20
> > g writes:
> >> > On Tue, Jan 20, 2009 at 9:16 PM, Kameron Gasso <kgasso-lists at visp.net>=
>  wro=3D
> >> te:
> >>=20
> >> > We're also seeing a great number of these, but the idiots spoofing =
> the
> >> > queries are hitting several non-recursive nameservers we host - and =
> only
> >> > generating 59-byte "REFUSED" replies.
> >> >
> >> > Looks like they probably just grabbed a bunch of DNS hosts out of =
> WHOIS
> >> > and hoped that they were recursive resolvers.
> >>=20
> >> First post to this list, play nice :)
> >>=20
> >> Are you sure about this? I'm seeing these requests on /every/ =3D20
> >> (unrelated) NS I have access to, which numbers several dozen, in =3D20
> >> various countries across the world, and from various registries (.net, =
> =3D20
> >> .org, .com.au). The spread of servers I've checked is so random that =
> =3D20
> >> I'm wondering just how many NS records they've laid their hands on.
> >>=20
> >> I've also noticed that on a server running BIND 9.3.4-P1 with =3D20
> >> recursion disabled, they're still appear to be getting the list of =
> =3D20
> >> root NS's from cache, which is a 272-byte response to a 61-byte =3D20
> >> request, which by my definition is an amplification.
> >=20
> > 	BIND 9.3.4-P1 is past end-of-life.
> >=20
> > 	You need to properly set allow-query at both the option/view
> > 	level and at the zone level to prevent retrieving answers
> > 	from the cache in 9.3.x.
> >=20
> > 		option/view level "allow-query { trusted; };"
> > 		zone level "allow-query { any; };"
> >=20
> > 	BIND 9.4.x and later have allow-query-cache make the
> > 	configuration job easier.  It also defaults to directly
> > 	connected networks.
> 
> Another BIND-specific question since we're on the topic. I see
> some of our authorative servers being hit with these spoofs, and
> yes, the 9.3.5-P1 (that's what Sun supports in Solaris these
> days) were sending back answers from the cache... but wait...
> what cache?

	Authoritative servers need a cache.  Authoritative servers
	need to ask queries.  The DNS protocol has evolved since
	RFC 1034 and RFC 1035 and authoritative servers need to
	translate named to addresses for their own use.

	See RFC 1996, A Mechanism for Prompt Notification of Zone
	Changes (DNS NOTIFY).
 
> The view the Internet gets only has our authorative zones. There
> is no declaration for the root zone, master, slave, or hints.
> How does BIND have the root cached in that view? Where did it
> get it from? I guess it's hard coded somewhere?
> 
> Blocking this in the firewall. 1:0 amplification better than the
> BIND fix, 1:1. But I'll get to the BIND fix anyway.

	The real fix is to get BCP 38 deployed.  Reflection
	amplification attacks can be effective if BCP 38 measures
	have not been deployed.  Go chase down the offending
	sources.  BCP 38 is nearly 10 years old.

	We all should be taking this as a opportunity to find where
	the leaks are in the BCP 38 deployment and correct them.

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