Re: distrbuted nmap?

[Lorell Hathcock <lorell () hathcock org>]

Greetings!

Would nmap run across the "PVM'ed" network of machines transparently?  How
would one control which host in the PVM network would actually perform
which scan?  If granular control could be achieved, could one specify that
PVM Client #1 would scan Host X on port N and that PVM Client #2 would scan
Host X on port M?

I philosophically agree with the solution proposed by Thomas Reinke because
it is a more standard (in my little view) approach to a single distrubuted
process.  It coincides with my own proposed methods of solving the problem.  

Regardless of if nmap itself incorporates this functionality itself or if
"supplemental" programming is added, it seems the best model for solving
the problem would be a client/server model where the server is able to
distribute the jobs down to the port and ip so that a single host on the
target network is scanned on different ports from different hosts.  The
server would have to randomly hand out the assignments so that a look at
scan detection logs would not be able to establish a pattern (i.e. 25% of
63353 ports were scanned from host W, 25% of 65535 ports were scanned from
host X, 25% of 65535 ports were scanned from host Y, and 25% of 65535 ports
were scanned from host Z).  Certain hosts on the target network would not
be scanned at all by host W under this approach while other hosts on the
tergat network would be hit with it quite a bit.

Thoughts?

Lorell Hathcock

At 06:53 PM 3/20/00 -0500, Jose Nazario wrote:
> regarding the use of PVM, it was raised that PVM, MPI and other Beowulf
> solutions are fantastic for CPU intensive applications (like the molecular
> dynamics simulations i run from time to time) but would be overkill for
> something ike nmap.
>
> i quite disagree. i think that PVM actually provides a nice framework for
> what you would want to do with a distributed application like nmap. like
> TCP, PVM keeps track of connections and messages sent, it has very good
> error handling, dynamic group assignments and the like. it runs over TCP,
> so it provides a nice reliable data stream over the WAN. heck, it even
> works on NT (for the reportedly in the works nmap port to NT) these are
> all the kinds of things you would demand in a framework for a distrubuted
> application. just because it's not CPU intensive does not mean it's
> overkill, i'm just asking why reinvent the wheel? 
>
> parallelization points are readily seen in nmap, which is the trickiest
> point to porting an application to any parallel structure like MPI or PVM.
> as such, it shouldn't be a difficult undertaking for coding. the
> difficulty will be in design of the model for how this would be
> implemented. 
>
> PVM is described in detail at http://www.epm.ornl.gov/pvm/pvm_home.html
>
> jose nazario                                   jose () biochemistry cwru edu
> PGP fingerprint: 89 B0 81 DA 5B FD 7E 00  99 C3 B2 CD 48 A0 07 80
> Public key available at http://biocserver.cwru.edu/~jose/pgp-key.asc
>
>
> --------------------------------------------------
> For help using this (nmap-hackers) mailing list, send a blank email to 
> nmap-hackers-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).