Re: Re[2]: nmap+V

[Fyodor <fyodor () insecure org>]

On Tue, Sep 02, 2003 at 06:50:20PM +0500, Max wrote:
>     The point of all this, again, is:
>     *  Where is the line between core functionality and add-on functionality?
>     *  Is it better to add this kind of thing to the core of nmap or should
>        it be left for more RAD types of languages and output processors and
>        be kept out of the core?

This is an excellent point, and one that concerns me as well.  I have
worked pretty hard over the years to keep Nmap focused on its core
competency.  That means rejecting many ideas that I don't believe fit
in, even when the ideas are accompanies by a working patch.

I believe that Nmap's core competency is "network mapping", and not
just "port scanning".  That is why for the last few years I have
referred to it as the Nmap Security Scanner.  If it was just a port
scanner, OS detection would have no place.  In fact, several people
did complain that OS detection was unnecessary bloat back when I
added it.  I don't hear that anymore.  I believe that once people get
used to service/version scanning, they will recognize it as a
fundamental part of port scanning.  After all, you normally do a port
scan in order to determine what SERVICES are listening on the given
host.  The particular numbers are less important.  Nmap has always
tried to guess the services based on the nmap-services table, but that
is often misleading.  Anyone who simply trusts that mapping is being
negligent.  The mapping is becoming even less relevant as more and
more people choose ports base on "what will get through the firewall"
rather than using proper port.  The other day my cousin asked me to
telnet to his machine on port 22 (ssh).  He explained that this was
because telnet was banned for security reasons(!).  Even I changed the
port of one of my home web servers after my ISP banned 80 due to all
the IIS worms (argh!).

Right now many of us cope with that problem by running various tools
and custom probes against the ports discovered by Nmap.  Tools like
Amap and Nmap+V can be very helpful.  Integrating service detection
with Nmap should provide a fast, high-quality implementation to avoid
all this hassle.

Here is another good reason for port scanners to include service
detection: User Datagram Protocol.  As the years have gone by, UDP
scanning has become less and less useful.  Not only is it slow as sin
in many cases due to ICMP error rate limiting, but Nmap has no good
way to differentiate between open and filtered ports.  Service
detection offers a (partial) solution -- if we send our DNS server
status request and get a DNS reply, we KNOW the port is open.  I hope
to (eventually) add a OPENorFILTERED port state for UDP ports that are
unresponsive during the port scan.  Then if service scan is able to
coax out a response, the relevant port state would be changed to open.

I hope we can all agree that service/version detection can be highly
useful.  The question then is whether it should be in Nmap or split
into a separate tool.  I believe it should be integrated into Nmap for
these reasons:

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.

Hopefully the advantages of integrating service/version scanning into
Nmap will be clearer once I move beyond the vaporware stage and
release the next major version of Nmap next week.  I have been working
pretty hard on it for the last few months and think it works pretty
well.

Cheers,
-Fyodor

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