Re: DNS Amplification attack?
On Tue, Jan 20, 2009 at 9:16 PM, Kameron Gasso <kgasso-lists@visp.net> wrote:
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.
First post to this list, play nice :) Are you sure about this? I'm seeing these requests on /every/ (unrelated) NS I have access to, which numbers several dozen, in various countries across the world, and from various registries (.net, .org, .com.au). The spread of servers I've checked is so random that I'm wondering just how many NS records they've laid their hands on. I've also noticed that on a server running BIND 9.3.4-P1 with recursion disabled, they're still appear to be getting the list of root NS's from cache, which is a 272-byte response to a 61-byte request, which by my definition is an amplification. Cheers, Jay
Once upon a time, jay@miscreant.org <jay@miscreant.org> said:
I've also noticed that on a server running BIND 9.3.4-P1 with recursion disabled, they're still appear to be getting the list of root NS's from cache, which is a 272-byte response to a 61-byte request, which by my definition is an amplification.
Add "additional-from-cache no;" to the options{} section of your named.conf. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Quoting Chris Adams <cmadams@hiwaay.net>:
Once upon a time, jay@miscreant.org <jay@miscreant.org> said:
I've also noticed that on a server running BIND 9.3.4-P1 with recursion disabled, they're still appear to be getting the list of root NS's from cache, which is a 272-byte response to a 61-byte request, which by my definition is an amplification.
Add "additional-from-cache no;" to the options{} section of your named.conf. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Thanks for the response Chris. I'm running higher versions of BIND, so don't see this behaviour. But I will pass it on to the ISP in question ;)
In message <20090121140825.xwdzd4p64kgwo4go@web1.nswh.com.au>, jay@miscreant.or g writes:
On Tue, Jan 20, 2009 at 9:16 PM, Kameron Gasso <kgasso-lists@visp.net> wro= te:
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.
First post to this list, play nice :)
Are you sure about this? I'm seeing these requests on /every/ =20 (unrelated) NS I have access to, which numbers several dozen, in =20 various countries across the world, and from various registries (.net, =20 .org, .com.au). The spread of servers I've checked is so random that =20 I'm wondering just how many NS records they've laid their hands on.
I've also noticed that on a server running BIND 9.3.4-P1 with =20 recursion disabled, they're still appear to be getting the list of =20 root NS's from cache, which is a 272-byte response to a 61-byte =20 request, which by my definition is an amplification.
BIND 9.3.4-P1 is past end-of-life. 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. option/view level "allow-query { trusted; };" zone level "allow-query { any; };" BIND 9.4.x and later have allow-query-cache make the configuration job easier. It also defaults to directly connected networks. Mark
Cheers,
Jay
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On 1/20/2009 at 7:23 PM, Mark Andrews <Mark_Andrews@isc.org> wrote:
In message <20090121140825.xwdzd4p64kgwo4go@web1.nswh.com.au>, jay@miscreant.or g writes:
On Tue, Jan 20, 2009 at 9:16 PM, Kameron Gasso <kgasso-lists@visp.net> wro= te:
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.
First post to this list, play nice :)
Are you sure about this? I'm seeing these requests on /every/ =20 (unrelated) NS I have access to, which numbers several dozen, in =20 various countries across the world, and from various registries (.net, =20 .org, .com.au). The spread of servers I've checked is so random that =20 I'm wondering just how many NS records they've laid their hands on.
I've also noticed that on a server running BIND 9.3.4-P1 with =20 recursion disabled, they're still appear to be getting the list of =20 root NS's from cache, which is a 272-byte response to a 61-byte =20 request, which by my definition is an amplification.
BIND 9.3.4-P1 is past end-of-life.
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.
option/view level "allow-query { trusted; };" zone level "allow-query { any; };"
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? 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.
Once upon a time, Crist Clark <Crist.Clark@globalstar.com> said:
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?
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?
BIND has had the hints compiled in for some time as a fall-back, but for an auth-only server, "additional-from-cache no;" will kill such responses. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
In message <497705BD.33E4.0097.0@globalstar.com>, "Crist Clark" writes:
On 1/20/2009 at 7:23 PM, Mark Andrews <Mark_Andrews@isc.org> wrote:
On Tue, Jan 20, 2009 at 9:16 PM, Kameron Gasso <kgasso-lists@visp.net>= wro=3D te: =20 We're also seeing a great number of these, but the idiots spoofing =
In message <20090121140825.xwdzd4p64kgwo4go@web1.nswh.com.au>,=20 jay@miscreant.or=20 g writes: 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@isc.org
Mark Andrews <Mark_Andrews@isc.org> writes:
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).
if i had RFC 1996 to do over again i would either limit outbound notifies to in-zone servernames, or recommend that primary server operators configure stealth slaves for servername-containing zones, or (most likely) i would point out that the need to look up secondary servernames requires that an authority-only nameserver be able to act as a stub resolver and that such a server much have access to an independent recursive nameserver. it's not too late to implement it that way. no authority-only server should need a cache of any kind. the above text from marka represents a BIND implementatin detail, not a protocol requirement, evolved or not.
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.
my agreement with this statement is tempered by the fact that BCP38 deployment cannot be continuously assured, nor tested. therefore we will need protocols, implementations, and operational practices that take account of packet source address spoofing as an unduring property of the internet.
We all should be taking this as a opportunity to find where the leaks are in the BCP 38 deployment and correct them.
Mark
yea, verily. and maybe track down rfc1918-sourced spew while you're at it. -- Paul Vixie
* Mark Andrews:
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).
Authoritative servers in typical configurations need a resolver (and with views, you might even need a very specific resolver). This does not mean that authoritative servers must be caches. It also does not mean that a resolver operated from the view which contains a particular authoritatively served zone picks up the correct data (in other words, there are configurations where the current BIND magic does not work). -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
participants (6)
-
Chris Adams -
Crist Clark -
Florian Weimer -
jay＠miscreant.org -
Mark Andrews -
Paul Vixie