[nsp-sec] 700K Open Resolver List

[Mike Lewinski]

Stephen Gill wrote:

> You are correct again, it was a very short window, not much more than 5
> minutes if I recall.  Also bear in mind the amplification factor in the
> subsequent packets not part of the tally.

Speaking of that amplification factor, I want to share a little of what 
I've learned.

We see ongoing apparent spoofed queries like this, all exactly 31 bytes:

10:58:03.898304 200.247.140.131.38648 > 206.168.219.99.53: 18446+ [1au] 
ANY ANY? um. (31)
10:58:04.017912 200.247.140.132.56696 > 207.174.72.220.53: 50112+ [1au] 
ANY ANY? um. (31)
10:58:04.018014 200.247.140.131.26854 > 207.174.201.189.53: 32067+ [1au] 
ANY ANY? um. (31)
10:58:04.018018 200.247.140.132.57955 > 207.174.202.18.53: 58262+ [1au] 
ANY ANY? um. (31)
10:58:04.018021 200.247.140.132.43144 > 207.174.72.211.53: 25259+ [1au] 
ANY ANY? um. (31)
10:58:04.018111 200.247.140.131.30270 > 207.174.72.216.53: 65238+ [1au] 
ANY ANY? um. (31)
10:58:04.300294 200.247.140.132.15830 > 208.139.195.126.53: 13725+ [1au] 
ANY ANY? um. (31)
10:58:04.300388 200.247.140.132.22468 > 208.139.202.246.53: 13608+ [1au] 
ANY ANY? um. (31)

I'm not sure why they aren't querying for a specific large TXT record. 
Maybe laziness, or maybe this is enough to get the job done?

Most of our customers have "fixed" their open recursion. I'm actually 
glad I have a couple still open because it allows me to compare the 
relative effects of the fix:

1) 208.139.195.126 applied the best resolution possible and provides no 
bandwidth amplification to the attackers at all, returning a 31 byte 
response back:
11:00:21.704330 208.139.195.126.53 > 200.247.140.131.36223: 38016 
Refused- 0/0/1 (31)

2) 207.174.72.216 is one of two that hasn't been fixed yet and provides 
~ 3.5x bandwidth amplification factor:
11:00:25.699523 207.174.72.216.53 > 200.247.140.131.30868: 60456 
NXDomain 0/1/1 (106)

3) 207.174.72.220 is the other one that hasn't closed recursion and also 
provides a 106 byte response:
11:00:25.699530 207.174.72.220.53 > 200.247.140.132.27439: 46012 
NXDomain 0/1/1 (106)

4) 207.174.72.211 no longer provides recursion, but gives a root server 
referral instead that causes a 20x amplification!
11:00:25.700320 207.174.72.211.53 > 200.247.140.132.47898: 28398- 
0/13/21 (646)

5) 207.174.202.18 also appears to return a referral but represents only 
a 9x amplification:
11:00:25.701827 207.174.202.18.53 > 200.247.140.132.44127: 53233- 0/13/3 
(286)


So my conclusion is that, by and large, we've actually increased the 
overall volume we're amplifying as a result of getting our customers to 
close recursion :(

I need to look more deeply at BIND's various versions and configuration 
options to see if we can come up with some specific configuration advice 
for our customers to bring everyone in line with the 31 byte response 
size given by 208.139.195.126.

Our own caching-only resolver IPs are ACL'd against all IP traffic at 
our borders so it is impossible to get packets to our anycasted resolver 
IPs. Their query-source IPs don't listen for traffic either so I believe 
they are useless for amplification.

Our authoritative nameservers are behaving just like 208.139.195.126 
does and all return a 31 byte response. I think this is a result of this 
combination of bind options:

   recursion no;
   additional-from-auth no;
   additional-from-cache no;

I'm thinking that additional-from-auth and additional-from-cache may not 
be available on some of the older BIND 8s that are out there? It may 
also not be advisable for people who are running combined auth/caching 
servers? Advice appreciated, TIA!

Mike