Saturday, August 30, 2008

More DNS jiggery!

So here is a brain-fart that prolly' needs cleaning up and is awaiting moderation on Kaminsky's site! Challenge-response mechanism basically. A DNS tunnelled type of CHAP for DNS.. and I know, I know, separate DNS server functions and all that... however ideas are ideas...

"I’m afraid it’s always a computational cost or time trade-off. Essentially Penny Black project style challenge or LaBrea tarpitting is required.

What *DO* we own re: logical assets? RRs!!!!!

Could we ask the remote server somehow to lookup a temp record in our own domain, generate one(as we own our own servers hopefully) and then wait for the lookup from the remote NETBLOCK? Kinda like SMTP authentication for websites and mailing lists with an OTP. One would have to be in-path to know the variable or understand some characteristic of the remote network/domain.

Let’s use the attack in reverse to secure the attack? Use the attack to secure ourselves as we can generate an arbitrary RR in our own domain e.g. our resolver talks to our domain NS and tells it to inject a local variable/record… think of it as a magic number, assume the attacker is not in-path.. then force the remote domain to ask our domain about it, before they give us the original new query for a host… haven’t totally thought this through fully :) might be worse re: BW :(

Or maybe debounce but record “IP TTL” tolerance. Sure IP TTL’s can change with backbone routing updates but less likey in the course of lookups for random/new hosts not actually in local cache already.

Firewalls or any policy point invalidates host based rate limiting somewhat."

No comments: