version detection guideline

[Toni Ruottu <toni.ruottu () iki fi>]

  hey

I am a bit lost when it comes to version detection and version
detection scripts. Could we have some kind of guideline somewhere? At
the moment I feel I am spending 90% of my time trying to figure how
version detection should be done, and 10% doing version detection
probes/scripts.

I try to list some key questions here, analyse them, and propose some
guidelines that might seem controversial. Please, bare with me. I am
open to discussion.

When do we want probes, and when do we want scripts?

Developing version scripts is easier because writing them is straight
forward. You just do what ever it takes to talk the protocol, and
record the results. Creating probes is hard because the probes are
expected to irritate services in clever ways to produce output that
reveal differences between services. I think this is important because
nmap may only try a few top priority probes if scanning is slow. Thus
adding a huge amount of trivial probes is considered bad.

I think we do not want to have a huge amount of trivial version
scripts that could be easily turned into probes. The reason for this
is that scripts have much more bloat, and might be slower to execute.
It is ok to target a probe to a large range of ports, and then just
stop sending probes if it seems to take too long.

I think the best solution would be to write non-clever probes that are
able to match the general protocol, and then write scripts that do
more advanced things to figure out the product, and version. However
this philosophy is not in line with the policy that the probes need to
be clever. Trying to write clever probes is boring, because it is
really hard to estimate if you are being clever enough.

Should all scripts do version detection?

At some point I was told that any script that runs into version
information should record that information. There are somethings here
too that are unclear to me. If I write a script that produces serious
output but also records version information, should I then include
that script to the version category. I have understood that you should
not, because the version scripts get enabled automatically when the
user executes a service scan, and the user is not expecting to see
script output. Some scripts that produce output seem to currently be
in the version category, but maybe this is an error.

On the other hand if those scripts are not supposed to be in the
version category, then the problem is that the user does not see the
version results when he does a version scan. Thus to achieve best
results for version scanning the user always needs to do script scans,
and then remove the script output from the results, if he is not
interested in them.

> From this I would say that one should never include version detection
in a non-version script. The problem in this is that the script
writers may need to write two scripts that are almost identical. The
other one just does outputting and the other one does version
detection. I think this is a good model, and should be encouraged.
Code duplication is a bit boring, but consistent user experience seems
more important to me. It is always possible to have the common parts
in a library, if it is a huge amount of code and might be useful for
other scripts as well.

This all sums up to four policies I would like to have:
1) probes do not need to be clever
2) version scripts should not typically target large port ranges
3) non-version scripts should never do version detection
4) version scripts should never produce output

I realize that I might have missed something critical, and I would
like to people discus this further rather than simply rubber stamp it.

  --Toni
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/