DNS attacks evolve

Sat Aug 9 21:02:35 UTC 2008

It's usually interesting to be proven wrong, but perhaps not in this case.

I was among the first to point out that the 11-second DNS poisioning claim 
made by Vixie only worked out to about a week of concentrated attack after
the patch.  This was a number I extrapolated purely from Paul's 11-second
number and the factor-of-65000x introduced by port randomization.

I am very, very, very disheartened to be shown to be wrong.  As if 8 days
wasn't bad enough, a concentrated attack has been shown to be effective in
10 hours.  See http://www.nytimes.com/2008/08/09/technology/09flaw.html

With modern data rates being what they are, I believe that this is still a
severe operational hazard, and would like to suggest a discussion of further
mitigation strategies.

On my list of concepts:

1) Use of multiple IP addresses for queries (reduce success rate somewhat)

2) Rate-limiting of query traffic, since I really doubt many sites actually
   have recursers that need to be able to spike to many times their normal
   traffic,

3) Forwarding of failed queries (which I believe BIND doesn't currently
   allow) to a "backup" server (which would seem to be interesting in
   combination with 2)

4) I wonder if it wouldn't make sense to change the advice for large-scale
   recursers to run multiple instances of BIND, internally distribute the
   requests (random pf/ipfw load balancing) to present a version of 1) that 
   would render smaller segments of the user base vulnerable in the event of
   success.  It would represent more memory, more CPU, and more requests,
   but a smaller victory for attackers.

5) Modify BIND to report mismatch QID's.  Not a log report per hit, but some
   reasonable strategy.  Make the default installation instructions include
   a script to scan for these - often - and mail hostmaster.

6) Have someone explain to me the reasoning behind allowing the corruption
   of in-cache data, even if the data would otherwise be in-baliwick.  I'm 
   not sure I quite get why this has to be.  It would seem to me to be safer
   to discard the data.  (Does not eliminate the problem, but would seem to
   me to reduce it)

7) Have someone explain to me the repeated claims I've seen that djbdns and
   Nominum's server are not vulnerable to this, and why that is.

It would seem that the floor is wide open to a large number of possibilities
for mitigating this beyond the patch.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.