And you know what? I'll give you the *NEXT* evolutionary steps, which
could make you want to cry.
If the old code system could result in an infected name server in 11
seconds, this "fix" looks to me to be at best a dangerous and risky
exercise at merely reducing the odds. Some criminal enterprise will
figure out that you've only reduced the odds to 1/64000 of what they
were, but the facts are that if you can redirect some major ISP's
resolver to punt www.chase.com or www.citibank.com at your $evil server,
and you have large botnets on non-BCP38 networks, you can be pumping
out large numbers of answers at the ISP's server without a major
commitment in bandwidth locally... and sooner or later, you'll still
get a hit. You don't need to win in 11 secs, or even frequently. It
can be "jackpot" monthly and you still win.
Which is half the problem here. Bandwidth is cheap, and DNS packets are
essentially not getting any bigger, so back in the day, maybe this wasn't
practical over a 56k or T1 line, but now it is trivial to find a colo with
no BCP38 and a gigabit into the Internet. The flip side is all those nice
multicore CPU's mean that systems aren't flooded by the responses, and they
are instead successfully sorting through all the forged responses, which
may work in the attacker's advantage (doh!)
This problem really is not practically solvable through the technique that
has been applied. Give it another few years, and we'll be to the point
where both the QID *and* the source port are simply flooded, and it only
takes 11 seconds, thanks to the wonder of ever-faster networks and servers.
Whee, ain't progress wonderful.
Worse, this patch could be seen as *encouraging* the flooding of DNS
servers with fake responses, and this is particularly worrying, since
some servers might have trouble with this.
So, if we want to continue to ignore proper deployment of DNSSEC or
equivalent, there are some things we can do:
* Detect and alarm on cache overwrite attempts (kind of a meta-RFC 2181
thing). This could be problematic for environments without consistent
DNS data (and yes, I know your opinion of that).
* Detect and alarm on mismatched QID attacks (probably at some low
threshold level).
But the problem is, even detected and alerted, what do you do? Alarming
might be handy for the large consumer ISP's, but isn't going to be all
that helpful for the universities or fortune 500's that don't have 24/7
staff sitting on top of the nameserver deployment.
So, look at other options:
* Widen the query space by using multiple IP addresses as source. This,
of course, has all the problems with NAT gw's that the port solution
did, except worse.
This makes using your ISP's "properly designed" resolver even more
attractive, rather than running a local recurser on your company's
/28 of public IP space, but has the unintended consequence of making
those ISP recursers even more valuable targets.
Makes you wish for wide deployment of IPv6, eh.
every time some blogger says "this isn't new", another five universities
and ten fortune 500 companies and three ISP's all decide not to patch.
that means we'll have to wait for them to be actively exploited before they
will understand the nature of the emergency.
While I applaud the reduction in the attack success rate that the recent
patch results in, I am going to take a moment to be critical, and note that
I feel you (and the other vendors) squandered a fantastic chance. Just
like the Boy Who Cried Wolf, you have a limited number of times that you can
cry "vulnerability" and have people mostly all stand up and pay attention in
the way that they did.
Hardly the first (but possibly one of the most noteworthy), RIPE called
for signing of the root zone a year ago.
I note with some annoyance that this would have been a great opportunity
for someone with a lot of DNS credibility to stand up and say "we need
the root signed NOW," and to force the issue. This would have been a lot
of work, certainly, but a lot of *worthwhile* work, at various levels.
The end result would have been a secure DNS system for those who chose to
upgrade and update appropriately.
Instead, it looks to me as though the opportunity is past, people are
falsely led to believe that their band-aid-patched servers are now "not
vulnerable" (oh, I love that term, since it isn't really true!) and the
next time we need to cry "fire," fewer people will be interested in
changing.
The only real fix I see is to deploy DNSSEC.
I've tried to keep this message bearably short, so please forgive me if
I've glossed over anything or omitted anything.
... 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.