On Wed, 18 Aug 2004, Roy Badami wrote:

> >>>>> "Bill" == Bill Sommerfeld writes:

> Bill> Outline of an algorithm:
> Very neat. So lets think of what countercountermeasures at attacker
> might take.
> Assume for sake of argument a single client performing the scan.
> Instead of performing a single scan, it performs many scans in
> parallel, round robbining between them. eg do 1000 scans in parallel,
> each staring at different points in the namespace. So now each of my
> scans is 1000 times slower, to give the names time to decay back to
> green.
> You increase your decay timeout in response; I respond by increasing
> the number of parallel scans. Who will win? I fear you may hit the
> limit of how large you can set the decay timeout without seriously
> impacting name resolution performance long before I hit the
> implementation limits of this approach, although it's not clear.
> Of course, in reality scans by the bad guys are going to be done not
> by a single machine, but by armies of zombies each scanning a small
> portion of the namespace. But I don't think that makes much
> difference to the analysis; each machine is scanning a portion of the
> namespace, and it can split that portion into 1000 subportions and
> round-robin between them.

Oh boy, this is fun, how about this one:

setup a zone, say gotcha.example.com, create a nameserver, delegate your
targets as cnames under gotcha.example.com.

Quickly scan a class B for resolvers, take the bulk (say 2000), and ask
them for stuff under gotcha.example.com. Ofcourse, depending on the result
of one query, you'd enter the target name (as cname) under gotcha.

If 2000 is not enough, scan class A. If example.com becomes to visible,
buy some new.

So, as a defense, why not try to prevent before trying to setup detection ?


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.