[dns-operations] the mathematics of kaminsky spoofing probability
Paul Vixie
vixie at isc.org
Mon Aug 4 16:27:13 UTC 2008
> From: Otmar Lendl <ol at bofh.priv.at>
>
> Over the last days, I have been thinking about what can be done
> nevertheless, and my current idea is the following:
>
> Whenever we get a forged answer (qID, port, ...) we process the packet
> as usual, but instead of sending the reply and changing the cache,
> we just put a flag on all cached entries which would have been changed
> by this reply.
note that the application generally will not know when the port is mis-guessed
unless it opens an ICMP socket (in which case it still won't know which ICMPs
are bad guesses unless its upstream IP address is dedicated to RDNS). opening
a few hundred extra UDP sockets as an RDNS-level honeypot (as was described in
a NANOG posting last week) would help but unless you can open all UDP ports it
is still a statistical defense, and a scant one at that.
> Whenever a matching answer is received, it cannot change any cache
> entries where this flat is set.
>
> This isn't 100% effective (e.g. the target of the attack must be already
> in the cache to be protected), it should help quite a bit.
i've re-posted my "minimum entropy" proposal from namedroppers@ here, which i
think is a more effective solution than "always query twice" or "fallback to
TCP or query twice if a bad QID is tried", but in specific response to the
above "don't cache data after a suspicious transaction" proposal, i have two
concerns. first is that if you annoy bad guys they will do things that annoy
you back -- like flooding you with bad QID's just to put you in your slow mode
perhaps in hopes of discrediting this approach. second and more importantly
from a protocol point of view, no current RDNS forwards answers from authority
servers back to their stubs without first caching and then regenerating it,
and this is done in response to worse/older security problems than kaminsky's.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the dns-operations
mailing list