DNS Amplification attack?
Anyone else noticing "." requests coming in to your DNS servers? http://isc.sans.org/diary.html?storyid=5713 I'm seeing them coming from the following addresses in my ns server logs. 69.50.142.110 69.50.142.11 76.9.16.171 66.230.128.15 66.230.160.1 -wil
hi, On 20.01.2009 21:54, Wil Schultz wrote:
http://isc.sans.org/diary.html?storyid=5713
I'm seeing them coming from the following addresses in my ns server logs.
69.50.142.110 69.50.142.11 76.9.16.171 66.230.128.15 66.230.160.1
counting 319149 denied queries for './NS/IN' since 2008-01-01, i see roughly 96% "coming" from those ips:
1071 216.240.131.173 1183 74.86.34.144 3397 216.201.83.2 4526 216.201.82.19 13568 66.230.128.15 15487 69.50.142.110 17689 66.230.160.1 21987 69.50.137.175 52392 76.9.16.171 72591 76.9.31.42 113548 69.50.142.11
so "yes" :) please also see another thread titled "isprime DOS in progress". cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia@ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office@ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________
On Tue, Jan 20, 2009 at 12:54:32PM -0800, Wil Schultz wrote:
Anyone else noticing "." requests coming in to your DNS servers?
I was surprised to see 'amplification' in the subject line here, since on my nameservers my replies are of equal length to the queries. A little bit of asking around, and I see that it is an amplification attack, preying on old software. Let me sum up; If you're running 9.4 or later, you will reply to these packets with 45 octet RCODE:Refused replies. 1:1. 9.4 has an "allow-query-cache" directive that defaults to track allow-recursion, which you should have set appropriately. If you're running 9.3 or earlier, you will reply to these queries "out of cache" (the root hints), and those replies can be 300-500 octets I think. 1:6-11. So in lieu of keeping a new up-to-date list of IP addresses to filter, as it expands and shrinks, you can greatly reduce your own footprint in these attacks with a quick upgrade. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
In message <20090120233128.GI15562@isc.org>, "David W. Hankins" writes:
--J+eNKFoVC4T1DV3f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
On Tue, Jan 20, 2009 at 12:54:32PM -0800, Wil Schultz wrote:
Anyone else noticing "." requests coming in to your DNS servers?
I was surprised to see 'amplification' in the subject line here, since on my nameservers my replies are of equal length to the queries. A little bit of asking around, and I see that it is an amplification attack, preying on old software.
Let me sum up;
If you're running 9.4 or later, you will reply to these packets with 45 octet RCODE:Refused replies. 1:1. 9.4 has an "allow-query-cache" directive that defaults to track allow-recursion, which you should have set appropriately.
If you're running 9.3 or earlier, you will reply to these queries "out of cache" (the root hints), and those replies can be 300-500 octets I think. 1:6-11.
So in lieu of keeping a new up-to-date list of IP addresses to filter, as it expands and shrinks, you can greatly reduce your own footprint in these attacks with a quick upgrade.
--=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
--J+eNKFoVC4T1DV3f Content-Type: application/pgp-signature Content-Disposition: inline
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkl2XtAACgkQcXeLeWu2vmrR+wCePhZM2IrxV1mCKpnpsL6RDPIk KnoAnRyVJpYrlan65MYJF7LRJc8nXJuj =F1Dc -----END PGP SIGNATURE-----
--J+eNKFoVC4T1DV3f--
Or better yet trace the query traffic back to the offending source and implement BCP38 there. If the source won't implement BCP38 then de-peer them. It's time to take back the "commons". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Jan 20, 2009, at 6:31 PM, David W. Hankins wrote:
On Tue, Jan 20, 2009 at 12:54:32PM -0800, Wil Schultz wrote:
Anyone else noticing "." requests coming in to your DNS servers?
I was surprised to see 'amplification' in the subject line here, since on my nameservers my replies are of equal length to the queries. A little bit of asking around, and I see that it is an amplification attack, preying on old software.
Let me sum up;
If you're running 9.4 or later, you will reply to these packets with 45 octet RCODE:Refused replies. 1:1. 9.4 has an "allow-query-cache" directive that defaults to track allow-recursion, which you should have set appropriately.
After reading this thread, I decided it was prudent to test my authoritative nameservers & was surprised to discover I could retrieve cached records from my nameserver even though I have "recursion no;" in my options stanza in named.conf. Re-reading the ARM, I see that behavior is expected. But is there some reason not to set "allow- recursion { none; };" since I already have recursion disabled? Thanks, Dave Coulthart
Wil Schultz wrote:
Anyone else noticing "." requests coming in to your DNS servers?
http://isc.sans.org/diary.html?storyid=5713
I'm seeing them coming from the following addresses in my ns server logs.
69.50.142.110 69.50.142.11 76.9.16.171 66.230.128.15 66.230.160.1
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. -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821
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.
a point to bear in mind here is that... 'its working' is good enough for the bad folks :( no need to optimize when this works. Also, it's likely this isn't all of the problem the spoofed requestors are seeing these past few days :( -Chris
Christopher Morrow wrote:
a point to bear in mind here is that... 'its working' is good enough for the bad folks :( no need to optimize when this works. Also, it's likely this isn't all of the problem the spoofed requestors are seeing these past few days :(
Unfortunately, I can't restrict traffic to/from my authoritative nameservers like I can with my recursive ones, since it will break DNS resolution for outside visitors to domains we host. Fortunately, the spoofed queries are 60 bytes and my REFUSED responses are only 59, so it's a terribly inefficient way to DoS someone. However, I never said that the DDoS kiddies were smart - doesn't seem to be stopping them from trying. :( Thanks, -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821
On Tue, Jan 20, 2009 at 9:35 PM, Kameron Gasso <kgasso-lists@visp.net> wrote:
Fortunately, the spoofed queries are 60 bytes and my REFUSED responses are only 59, so it's a terribly inefficient way to DoS someone.
bind has a 'blackhole' capabilty... which doesn't seem to reply with anything (from my quick testing) -chris
Once upon a time, Kameron Gasso <kgasso-lists@visp.net> said:
Fortunately, the spoofed queries are 60 bytes and my REFUSED responses are only 59, so it's a terribly inefficient way to DoS someone. However, I never said that the DDoS kiddies were smart - doesn't seem to be stopping them from trying. :(
Well, it still makes a DDoS, since they can (theoretically) have a bunch of sources spoofing the IPs, and the packets to the targets have legitimate source addresses (so they can't easily be blocked by the target). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 2009-01-21, Kameron Gasso <kgasso-lists@visp.net> wrote:
Christopher Morrow wrote:
a point to bear in mind here is that... 'its working' is good enough for the bad folks :( no need to optimize when this works. Also, it's likely this isn't all of the problem the spoofed requestors are seeing these past few days :(
Unfortunately, I can't restrict traffic to/from my authoritative nameservers like I can with my recursive ones, since it will break DNS resolution for outside visitors to domains we host.
Fortunately, the spoofed queries are 60 bytes and my REFUSED responses are only 59, so it's a terribly inefficient way to DoS someone. However, I never said that the DDoS kiddies were smart - doesn't seem to be stopping them from trying. :(
Thanks,
For you, yes. In many cases, there's either no amplification or a small decrease in traffic (though it makes it hard to shut off the true source). In a few cases (e.g. tinydns), there's no response, so the attackers traffic is wasted. But what about the people that happen to have misconfigured their authoritative DNS servers so that they're answering recursive queries from the world? 60 -> 520 bytes isn't bad, and I bet it's not _that_ uncommon...
participants (9)
-
Chris Adams -
Christopher Morrow -
David Coulthart -
David W. Hankins -
Kameron Gasso -
Mark Andrews -
Raoul Bhatia [IPAX] -
Stuart Henderson -
Wil Schultz