Fyodor,
Good points, and given that definition of the scope of nmap, adding
service detection makes a lot of sense. I look forward to seeing
the integration .. I hope good OO is used to keep this
component as isolated as possible .. this brings back another question
that has gone around this list before for me .. I haven't looked at
the nmap source in a while, and I will, but is any thought being
given to whether or not a common interface for add on, but included,
components, like this one, can be used in the code to make addition
of new features as component-based and clean as possible? Just
curious .. with nmap using more C++ this would seem like a reasonable
next architectural step. I think it would be cool to be able to do
updates to this version scanning component without having to download
and compile the whole distro. Maybe 'cool' isn't enough of an
argument to warrant time for this kind of internal, non-user visible
project? :P Maybe I should just shut up and look into it myself! :)
Regards,
Max
On Tue, 02 Sep 2003 16:23:16 PDT, Fyodor wrote:
> I believe that Nmap's core competency is "network mapping", and not
> just "port scanning".
> 1) I feel it is a natural extension of port scanning (see above)
> 2) Service detection needs to get port scan results anyway so it knows
> which ports/boxes to probe. By integrating with Nmap, the service
> scan logic is able to benefit from network latency calculations and
> similar data. It is also able to share and honor many Nmap options
> such as timing aggressiveness (-T), host timeouts, verbosity, etc.
> For example, Nmap 3.40 will service_scan more hosts in parallel if
> you have a higher -T value.
> 3) Service scan data can affect port scan results (like changing
> "open/filtered" to "open" as discussed above).
> 4) Creating a separate tool would be more work, and they would share
> significant amounts of code and some data files. So it could be
> argued that this approach increases bloat. It can also be harder
> to use, as users would have to learn a whole new command syntax
> rather than just adding -sV (or whatever) to their normal Nmap execution.
> 5) Nmap can merge the output nicely into one report. If you scan
> 30,000 hosts with both tools separately, you have to deal with merging
> the two reports.
> 6) Even with service detection "bloat", the Nmap tar.bz2 source
> distribution is barely over a megabyte. So it still fits on an
> ancient floppy and can transfer over ethernet in a fraction of a
> second. Your average crappy-bitrate .mp3 song is far larger.
---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
Received on Sep 03 2003
Intro
