Re: Google/Nmap SoC 2009 Project Ideas?

[Daniel Roethlisberger <daniel () roe ch>]

David Fifield <david () bamsoftware com> 2009-03-14:
> On Mon, Mar 09, 2009 at 11:42:03PM +0100, Daniel Roethlisberger wrote:
> > o Efficient network topology mapping.  Give Nmap (or Zenmap or even a
> >   separate tool) a large network range or multiple ranges, and it will
> >   automatically and intelligently determine the network topology
> >   with a minimal number of probes / in minimal scan time, i.e. don't
> >   do a full traceroute on each and every IP address.  There are many
> >   ways to cut down the number of probes required versus the naïve
> >   approach, including making educated guesses at subnetting, and
> >   intelligently verify those using a minimal number of probes (think
> >   binary search through possible/likely subnet layouts).
>
> Vladimir Mitrovic, a Summer of Code student last year, wrote a prototype
> that I think matches what you describe.
>
> http://seclists.org/nmap-dev/2008/q1/0409.html
> http://seclists.org/nmap-dev/2008/q1/att-0409/samplescan_gif
>
> The original idea was to build it into Zenmap, but it was never
> implemented owing to time constraints with other projects. Is this the
> kind of thing you were thinking of?

Pretty much, yes, except that this prototype runs a full
traceroute for each IP address in the range, which is what I'd
like to see optimized.

For instance, the traceroutes can be done backwards, in order to
be able to skip pointless probes to routers already in the
topology graph.  From the TTL on received response packets, we
know the distance of the target, and then traceroute back until a
node is found which is already in the node graph.

Other idea: If the two addresses a.b.c.2 and a.b.c.254 share the
same intermediate hops, there is a high probability that the
addresses in between are routed the same way.  So the target
network address range could be probed in the order most likely to
give good results fast, i.e. given a /16 net, assume it is split
up into two /17 and verify by tracerouting the second and
second-last address in each subnet.  And so on for /18, /19 etc.
This might be most effective when displaying real-time results.

I haven't verified how well these ideas work in practice and I
don't know how feasible the required graph algorithms are for
large networks, but I think it would be an interesting thing to
tinker with.

-- 
Daniel Roethlisberger
http://daniel.roe.ch/

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