Perhaps we're not in sync with each other. I get the impression that my
"cookie" idea (probably because I use the term "cookie" to describe it) is
being assumed to be something more complicated than it is.
All the "cookie" consists of is a totally standard DNS query. It could
just as easily be an A record query for SPLOITS.CERT.ORG as it could be a
type 212, class 13 query for DF97H37F74H4H3778FGH3F747.74TF784GF84GF4. The
point, of course, is simply that it's not trivial to guess, and we'll only
get a response back if the server we query is alive.
Under what circumstances would a 1 question nonrecursive query ever be
"mangled"? Is there a nameserver out there that destroys the question
section of DNS packets?
> Well, if the tcp connection also fails, we can return failure and try
> again later.. So each lookup request that the attacker generates will give
If the TCP connection fails, it will never work. There's a chance that it
will fail, because servers don't necessarilly *have* to allow TCP DNS
(firewall configurations, for instance, might make this impossible).
On the other hand, nothing should cause a simple UDP query to fail. It
also doesn't require connection setup (how will this affect latency?).
> sysadmin noticing all of the logs spewing out.. Again, the best protection
> would be cryptography
Yes, this is of course true, but it's probably not reasonable to expect
the entire Internet to switch to a cryptographically secure DNS protocol
overnight.
> > That doesn't work. This is a blind attack; I can make the queries come
> You can probably configure what addresses you'll accept recursive queries
> from in the bind config also.. Ill check it out
That doesn't work. This is a blind attack. I can make the queries come
from wherever I want them to. Eliminating recursive queries is not, from
what I can see, a valid solution to this problem. Am I wrong?
> TCP-ready BIND servers are probably 99% of the internet. However, if you
I don't set firewalls up to accept incoming TCP connections to port 53. At
the very least, every firewall I've configured is now broken.
> find that cookies work more reliably, then that would be the superior
> solution. It certainly has more room for strange failures though
You seem to think that there's alot of weirdness happening here. I don't
think there is. Can you come up with some specific things that can cause
weird failures? I'm not doing *anything* weird with DNS packets - I'm just
sending queries for information I don't care about.
> The same with the cookies, except over a larger range of ID space. Also:
That larger range of DNS space is how many bits of random data, now?
=)
If the DNS cookie solution works reliably, guessing cookies is no longer a
feasible attack, nor is brute-forcing cookie-space. The only attack
remaining is the race condition against the 16 bit ID.
However, I have to grant you that if a TCP connection is successful,
you've eliminated the problem entirely - you just finish the request over
TCP, and you know that you're getting reasonably authentic information
back.
Unless, of course, I can predict the sequence numbers involved in setting
up the connection, or otherwise subvert the connection to fail or be
spoofed...
> what do you do if a server doesnt return your cookies? Return a failure?
If a server doesn't return my cookies, it's dead. Try the next server.
Continue until SERVFAIL.
> Well, with the method I am proposing, a DOS attack will only be possible
> if port 53 is unavailable on the authoritative nameservers for the domain
How hard is that? SYN SYN SYN SYN SYN SYN SYN SYN *cough* *gag*
Again, we now have denial-of-service coupled with security; the attack
only needs to work once.
> that is being blocked. So the problem no longer lies in your nameserver,
> it is now a problem of the site being blocked for whatever reason, and
> would have to be fixed on that end. What else can be done on our end?
Our security shouldn't rely on any site's servers working.
----------------
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com]
----------------
"If you're so special, why aren't you dead?"