Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: Thoughts about DNS...Thomas H. Ptacek (tqbfENTERACT.COM)
Sun, 27 Apr 1997 00:24:24 -0500
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Illuminati Primus: "Re: Thoughts about DNS..."
- Previous message: Illuminati Primus: "Re: Thoughts about DNS..."
- In reply to: Illuminati Primus: "Re: Thoughts about DNS..."
- Next in thread: Illuminati Primus: "Re: Thoughts about DNS..."
> I think a temporary solution for the denial of service case is pretty > obvious. If someone is trying to brute force an entry into your > nameserver, the nameserver will first see a few hundred replies with There's a trivial and inexpensive denial of service attack associated with this method. I can prevent any nameserver employing this mechanism from ever being able to resolve "XXX.COM" by sending it a consistant stream of "XXX.COM" requests with random invalid query IDs. You mention this, but don't specifically state how it's done, so I'm simply clarifying. The attack is blind, doesn't require significant resources, and can be performed almost untraceably from any dialup connection on the net. Also, what does BIND do when it's caught up in a query->invalidate->retry loop? Does it eventually give up and return NXDOMAIN? Does it cache the NXDOMAIN (thus allowing for a far more severe denial of service attack)? Does it hang indefinitely, allowing us to trick resolvers into thinking the nameserver is dead? Can I tie arbitrary nameservers on the Internet up by employing this mechanism on multiple servers in parallel? What happens if I open up N recursive queries to a nameserver, following them up with a stream of invalid requests? Can I starve the nameserver of resources (some state is being allocated in BIND to cover each request)? If we're using nonrandom DNS ID's, can I try 65 thousand times to send a recursive request and then a stream of responses starting with an incrementing number and followed by random requests, so that if I don't win on the first try, at least I invalidate the legitimate request and have the opportunity to try again? My suggestion is to do as you state, and "notice" that we're receiving invalid IDs. However, instead of invalidating the request and trying the same insecure attempt again, the next thing we do is assert that the real authority servers have connectivity to us and are functioning. This rules out the combination of denial of service attacks and ID brute-forcing. The mechanism by which this is accomplished can be extremely simple - a flag set off by default that gets set on the first time an invalid query is received, and is turned off a configurable amount of time after the last invalid request is received. As long as the flag is set on, all requests must be completed with a "cookie" request to ensure the vitality of the queried servers. > (usually the attacker). Of course, this makes it possible to do denial of > service attacks if you can see where a nameserver is sending a request > to, but usually if they can see your network traffic youre screwed I don't need to see where requests are going. It will try one of the authority servers. Every authority server is an NS/A record pair in the tail of ever DNS packet concerning that domain, so most domains tend not to have too many. Typically between 2 and 6. I can easily forge 6 streams of packets in parallel. > Although its not good to have even a small window of opportunity, what > percentage of the ID space could someone cross by fully saturating a T1 > with forged DNS replies before the requesting server times out the Assume every response to be 100 bytes long. I need 65536 queries to completely span the ID-space. This is 6400k of network bandwidth. On a heavily loaded T1, I manage 110 kb/s FTP, or roughly a minute to complete the entire attack. Remember, though, that there is /no window/ involved in schemes that rely entirely on the ID to prove authenticity of responses. Figuring out how to restrain a nameserver for 58.18 seconds is not a difficult problem. Bugs in BIND may make it a trivial problem. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbfenteract.com] ---------------- "If you're so special, why aren't you dead?"