[nsp-sec] DNS Reflection DDoS

[Brian J Smith-Sweeney]

On Wed, Mar 2, 2011 at 11:01 AM, Brian J Smith-Sweeney
<bsmithsweeney at nyu.edu> wrote:
> On Mon, Feb 28, 2011 at 11:26 PM, Nicholas Ianelli <ni at centergate.net> wrote:
>>
>> ----------- nsp-security Confidential --------
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> We have been getting hit with a DNS reflection attack. Here are the specs:
>>
>> It's currently hitting 204.74.115.1, though it's hit a few different IPs
>> of ours. It's an ANY query for isc.org with the EDNS option set to 4096.
>>
>> Looks like this:
>>
>> 23:55:09.105010 00:19:e2:2d:45:79 > 00:30:48:cb:86:f0, ethertype IPv4
>> (0x0800), length 78: (tos 0x0, ttl 235, id 50959, offset 0, flags
>> [none], proto: UDP (17), length: 64) 204.74.109.1.25345 >
>> 204.74.103.145.53: [no cksum]  10809+ [1au] ANY? isc.org. ar: . OPT
>> UDPsize=4096 (36)
>>
>> We've captured over 3400 IPs involved in the attack. Full list can be
>> found here. Not sure what if anything can be done.
>>
>> https://asn.cymru.com/nsp-sec/upload/1298951475.whois.txt
>>
>> Full list beneath my sig.
>>
>> Cheers,
>> Nick
>>
>> - --
>> Nicholas Ianelli: Neustar, Inc.
>> Security Operations
>
> (belated) ACK for AS12.  Looks like this stopped around 11:30pm last
> night from us, let me know if it kicks up again.  We're working on
> getting recursion disabled for these boxes.
>
So it turns out I spoke too soon - my DNS guys assert recursion had
already been disabled for these system via BIND ACLs.  Checking
netflow, I see records like the following:

0228.22:26:47.191 0228.22:31:51.575 217   204.74.115.1    25345 103
128.122.128.24  53    17  0  387403     24793792
0228.22:26:47.191 0228.22:31:51.575 103   128.122.128.24  53    217
204.74.115.1    25345 17  0  387429     24795456

Given the closely matching flow size in both directions, I'm inclined
to believe we were just answering with refusals rather than actually
amplifying.  The DNS folks are going to confirm this with some of
their own tools (we don't have query logging enabled, so there's a bit
of digging involved).

Recursion was in recent memory enabled for these systems.  Also I note
that not all of our DNS servers were part of the attack.  Assuming I'm
correct and these are just refusals, I'm guessing the attackers have a
static list of what they believe are open DNS recursion boxes they
feed this tool.  And they are a) not checking that list all that
often, and b) not verifying before they launch their attack.  Not sure
why - seems like this would be trivial to verify if you had control of
another ip address you didn't mind someone tracking down.  Perhaps
it's just not worth the effort.

Cheers,
Brian