Re: Thoughts about DNS...

[tqbf () ENTERACT COM (Thomas H. Ptacek)]

> Its more dependable than trying to depend on some type of cookie hidden in
> areas that arent guaranteed to come back unmangled

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?"