Re: [Full-disclosure] Re: recursive DNS servers DDoS as a growing DDoSproblem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Story wrote:
> Exactly. The attackers do use EDNS0 [RFC2671], which allows clients to declare
> the maximum size of UDP message they are willing to handle. So the spoofed
> packet sets this value to whatever they want.
>
> MS> So, you can send a bunch of source-spoofed requests that are under 100
> MS> bytes, and get a bunch of 512 bytes responses.
>
> In the most recent round of attacks, the attackers were using 4k TXT records,
> so a 100 byte request is hugely amplified...
Indeed, interesting. I was not aware of this feature.
But let's get to the point.. why is "recursive" in this email subject? It
doesn't need to have anything to do with recursive DNS.. you can exploit this
on normal public authoritative nameservers as well.
Take for example this:
a T_ANY request for microsoft.com's nameserver 65.55.238.126.53:
the request is 59 bytes, the response is 534 bytes, that's 9x amplification.
And you can flood with this completely anonymous (spoofed).. No need to set up
DNS yourself or take other extra risks.
Even better, spread it over multiple domains/NS's (a la smurf) to make sure
you get a good flood of replies (so not to have rate limiting or congestion at
the nameservers).
Now, you could block T_ANY requests or whatever, but even normal requests can
generate quite a big reply as well, something which you cannot really block.
The core problem is in using the UDP the protocol (or spoofing, depending on
how you look at it) and cannot really be solved.
Now some bright guy might come up with the wonderful idea of automatically
blocking IP's that flood, but this only introduces another attack by which you
can for example block AOL's nameservers to reach domain X's nameservers.
Like I said, DNS using UDP... it's full of holes (and we are not even
discussing the completely ridiculous *16 bit* ID field of DNS....).
What worries me is that thousands of people are aware of all I said above, yet
not much is actually happening about it.
- --
Bram Matthys
Software developer/IT consultant syzop@xxxxxxxxxxxx
PGP key: www.vulnscan.org/pubkey.asc
PGP fp: 8DD4 437E 9BA8 09AA 0A8D 1811 E1C3 D65F E6ED 2AA2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
iD8DBQFEG2/I4cPWX+btKqIRAqXHAJ9gVR71wX3V2bV5cRlgjyGJr9yfGACeKmpI
0jRIwO14jtJnIqARGA5DM+4=
=VeSY
-----END PGP SIGNATURE-----