Home page logo

Nmap Announce mailing list archives

Re: distrbuted nmap?
From: Lorell Hathcock <lorell () hathcock org>
Date: Mon, 20 Mar 2000 21:55:18 -0600


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.


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

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).

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]