Since we're on the topic of this, I figured I would release my
updated changes that I've done recently to nmap. Those include:
a) scripting language addition to nmap, so that (with the -z
<scriptname> flag) nmap will process <scriptname> after
each IP scanned. The scripting language supports loops,
conditional statements, functions, variables, opening/closing
connections, reading/writing to sockets and files, etc...
b) -l <portnum> flag so that nmap will act in a server mode
accepting connections on <portnum> in a multithreaded fashion.
commands are: help, exit and nmap; nmap followed by parameters.
the stdout of nmap is dumped to the socket.
There is by default password authentication on the socket, which
is a flag and can be turned off. The implementation of this
is sort of similar to --interactive.
As far as making nmap distributed, its trivial to write to a client
program that could act upon multiple servers via a config file,
and so to spread its workload across multiple nmap servers. I
haven't done this, however.
They are available at http://www.mobis.com/ajax/projects/
Cheerz,
Brian
ajax_at_mobis.com | The skill of accurate perception
| is called cynicism by those who
| don't possess it.
On Mon, 20 Mar 2000, Lorell Hathcock wrote:
> 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_at_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_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
> >
>
>
> --------------------------------------------------
> For help using this (nmap-hackers) mailing list, send a blank email to
> nmap-hackers-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
>
Received on Mar 20 2000
Intro
