DNS attacks evolve
jgreco at ns.sol.net
Sat Aug 9 16:02:35 CDT 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
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
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.
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.
More information about the NANOG