Nmap Development mailing list archives

Re: [PATCH] Add the ability to generate quality random IPs without any duplicates


From: Fyodor <fyodor () insecure org>
Date: Sun, 23 Aug 2009 22:48:55 -0700

On Sat, Aug 22, 2009 at 01:31:23AM +0000, Brandon Enright wrote:

Hey all, it's Friday and this week has burnt me out on "work things" so
I decided to tackle something fun.

Neat!

Q: Why not just replace -iR with this new -iU option instead of having
both?

A: Sometimes I want *really* high quality IPs.  Sometimes I don't want
to be bothered with duplicates. This patch is small, I think there is a
place for both.

I think supporting both for your initial patch is a great idea, as it
makes it easy to test the different strategies and compare.  But Nmap
itself only needs one random IP generation mechanism (whatever one we
think is best).  If someone wants a different approach, nothing stops
them from generating random IPs however they like and feeding them to
Nmap with -iL.

So the next question is: which mechanism is best?  Avoidance of
duplicates is a useful property.  I often pass my IP lists to sort and
uniq for this very reason.  The number of duplicates aren't material
unless you are scanning a huge number of IPs (your example of 10
million IPs shows about 0.15% duplicates).  But they are still
annoying.

So I'm in favor of a no duplicate approach for Nmap *if* there aren't
any significant downsides.  Does anyone see any problems in using this
approach?  The code is small and doesn't appear computationally
intensive.  I haven't evaluated the quality of randomness, though
Brandon's graphs look promising.  Perfect randomness isn't critical
here anyway.  Brandon: have you tried generating billions of these to
verify that the period is as large as you expect and that the full
group doesn't have holes in it (besides the expected ones from
ip_is_reserved())?

Cheers,
-F

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


Current thread: