Re: Re[2]: nmap+V

["Max" <nmap () webwizarddesign com>]

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 () insecure org . List run by ezmlm-idx (www.ezmlm.org).