Bugtraq mailing list archives
Re: Thoughts about DNS...
From: vermont () GATE NET (Illuminati Primus)
Date: Sun, 27 Apr 1997 13:08:08 -0400
On Sun, 27 Apr 1997, Thomas H. Ptacek wrote:
Its more dependable than trying to depend on some type of cookie hidden in areas that arent guaranteed to come back unmangledPerhaps 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?
Ah, I had believed you were trying to piggy back the query in the same packet as the first one. If they are sent separate, and your cookie is set nonrecursive, then you are right, it should return unmangled, unless the packet gets lost along the way somehow. The reason I say this will introduce latency is because obviously to accept a response you must wait for the second query to return, which first of all gives two packets we must wait for the return of, on top of a slightly extra amount of traffic... And for busy nameservers that are ALWAYS sending out cookies, this can add up, causing some serious speed problems (ie. any busy ISP/WPP)
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).
From the comp.protocols.tcp-ip.domains FAQ available via www.isc.org:
Q: Does anyone out there have any information/experience on exactly which TCP/UDP ports DNS uses to send and receive queries ? [..nice chart, etc..] Also, ALL versions of BIND use TCP for queries in some cases. The original query is tried using UDP. If the response is longer than the allocated buffer, the resolver will retry the query using a TCP connection. If you block access to TCP port 53, you may find that some things don't work. So, as you can see, if you HAVE been configuring your firewalls to block tcp port 53, you are breaking bind. If you are doing that to prevent zone transfers, then you are doing it wrong, since that can be sent over UDP as well. Besides, you can configure a list of IPs to allow zone transfers to in the config file. But I admit, not everyone who's setting up a firewall takes caution not to break inside services. In those cases we cant do anything about not reaching tcp port 53, and a udp type of authentication would be more favorable.. Perhaps your cookie method could be a fallback if the tcp connect fails.. That way we dont have to generate extra traffic unless we need to. And once an attempted spoof is noticed, it can flag those domain servers as dangerous, and use tcp/cookies for all subsequent queries to prevent any more chances for spoofing.
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?).
It will affect latency because you will have to wait for the second reply containing the cookie.. So it wouldnt be something you would want to configure on a very busy nameserver (especially one that's losing packets).
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?
Of course it will not prevent an attacker from continually bombarding us with spoofed replies.. But his only reward will be that we are forced to contact some DNS servers via TCP or with cookies.
TCP-ready BIND servers are probably 99% of the internet. However, if youI 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.
Yep. You shouldn't block access to a vast majority of ports and then expect all of the servers to function as expected. Sometimes it takes a little bit of reading and some tcpdump watching
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.
Well, you are using the packets for a purpose that bind was not built for. But once again, if it proves to be more reliable, then it is the superior solution (only testing will tell).. We also arent restricted from trying both safeguards.
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...
That would be a problem with the tcp/ip implementation. If connections can be spoofed to the target, then they have far worse problems.
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.
Same here.. There is nothing that we can do if the nameservers we are querying are dead, unless you want to make bind fax the domain owners a sheet that says they are under attack..
Again, we now have denial-of-service coupled with security; the attack only needs to work once.
Wrong: it will need to work each time someone queries for a hostname in that domain, since the server will be intelligent and not cache hosts as nonexistent if the nameservers are unreacheable. So the attacker would need to maintain a steady stream of packets to deny access to the nameservers, at which point we can try your cookie method. However, if someone wanted to deny access to a nameserver, all he would need to do is send several recursive queries to resolve addresses that belong to unreacheable name servers. DOS on the remote end is something we on the local end can't prevent, unless we force everyone on the internet to upgrade their servers. Hopefully though, the important domains will. All they have to do is block packets that appear to come from the inside from travel in through an outside gateway (hopefully this is standard practice by now), and not allow recursive queries from outside IPs. If we had totalitarian control over the internet, maybe we could do something about this. However, since we dont, all I'm worried about is maintaining security on the local end. And returning a failure because a server is indeed DOWN is something we can't prevent.
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.
"Our security" does not. The simple fact is we can't do anything about unreacheable nameservers. Unless you want to try the fax idea -vermont () gate net
Current thread:
- Re: Thoughts about DNS... Illuminati Primus (Apr 27)