mailing list archives
Re: Question on --version-intensity and -sR interaction
From: Fyodor <fyodor () insecure org>
Date: Fri, 4 Mar 2011 14:55:00 -0800
On Fri, Mar 04, 2011 at 11:37:44AM -0600, Daniel Miller wrote:
Since I have run into custom services that crash on certain probes, I
would like a way to guarantee that only the explicit probes for each
port are run, and no RPC scan. I thought this would be the way to do
nmap -sV --version-intensity 0 example.com
But I am no longer sure. Any ideas?
When service detection is enabled, RPC scan (-sR) only runs against
ports which were determined (by service detection) to be "rpcbind".
This can only happen in response to three probes: tcp "RPCCheck", tcp
"NotesRPC", or udp "RPCCheck".
In addition to the RPC scan, version detection can enable the version
detection category of NSE scripts.
Neither of these cases directly deends on --version-intensity except
that unusual ports are less likely to be detected as the relevant
service if you have a a low version intensity set.
Does the "rpcbind" limitation resolve your issue, or is RPC scan still
likely to present a problem?
Have you also limited the probes in the file, or are you using the
file as is?
This could potentially relate to Patrik Karlsson's recent suggestion
for a named probes feature (http://seclists.org/nmap-dev/2011/q1/605).
One option would be to provide named probes and then skip
postprocessing (RPC scan or version detection NSE scripts) in that
case. But some people might want limited probes, but still want Nmap
to find out everything it can about those services.
Another option would be to say that "--version-intensity 0" (and maybe
other low numbers?) disables RPC scan and version detection NSE
scripts, unless those were requested explicitly with -sR or
Or rather than trying to make existing options "smarter", we could
have a new option which does nothing but omit enhanced version
For the people who would use this sort of feature, I'd be interested
in hearing how you'd like it to work. We'd probably want to hear from
at least a few people who want the feature before we'd add such a
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/