mailing list archives
Re: [RFC] Default NSE Scripts
From: Kris Katterjohn <katterjohn () gmail com>
Date: Sat, 10 May 2008 17:02:06 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hey Jah, thanks for the detailed comments!
On 09/05/2008 23:17, Kris Katterjohn wrote:
Instead of NSE running "safe" and "intrusive" scripts by default, I'm
creating a "default" category for this purpose. This is important
because there are some safe and intrusive scripts that you wouldn't want
run by default (e.g. an obscure safe script or a slow intrusive script).
Definitely a good idea, but your list for Default includes scripts that
were never in Safe or Intrusive to begin with so I assume you're looking
at any script for possible inclusion in the default category. (Also,
That's my plan. It shouldn't matter which category it is in as long as
it is "good enough" to be in default (I'll try to discuss this in more
UPnP-info seems to have gone AWOL).
D'oh! Indeed it has. Sorry about that!
How to measure this? The only script I would call slow is bruteTelnet
which is "Vulnerability".
I suppose I should've just said "not slow" rather than the even less
precise "quick". Since this is all subjective, I would say that if a
script takes a very noticeably longer time than other "quick" scripts
then it probably shouldn't be in default, or if a script has a
noticeable effect on the overall scan's time.
2) Generally Useful
I reckon this is pretty subjective and I'd argue that it depends on the
purpose of a given scan and the environment of the target.
Well, by "generally useful" I mean that quite a bit of people will find
it useful. It produces interesting output for a protocol/service that's
not obscure so that it is /generally/ useful.
Take SNMPsysdesr, for example. It won't run on /every/ scan, but when
it does run it produces (what I think to be) interesting output. SNMP
is an example of a protocol that a lot of people recognize and will be
3) Not too intrusive
How to measure this? It could be "the likelihood of being logged" is a
good measure, but that would be somewhat dependant on the target
environment. Brute forcing is obviously very intrusive because it's
likely to be logged and there's multiple events from the same source in
a short space of time, but otherwise, what constitutes "too intrusive"?
I would say anything that can be perceived as truly unlawful, seen as a
"real hacking attempt", does an excessive amount of probing, etc.
Good examples are bruteTelnet and SQLInject.
Unfortunately, these three are all subjective. Especially #2.
* dns-test-open-recursion - Is this useful enough?
This is sometimes very useful, but is recursion found often enough to
warrant running what is, I think, an intrusive script?
Good question. I actually meant to ask "Is this useful often enough"
because I don't know how frequent it is.
Isn't finger a bit obscure now?
It is, but I see finger running often enough that I think it's a good
default (though it's not terribly popular either).
* HTTPAuth - Is this too intrusive?
It is intrusive, but it's always been run by default in the past, so why
not? But then again, it's not very often that it finds such weak
security, so what's the point?
Well, it does print more information than just possible successful
logins. One useful thing is that is tells that the server actually
requires authentication, and also things like the authentication type.
This is a safe script with regard to the target, but RIPE might think it
less so. Especially as it would query RIPE for every target regardless
of whether the target is in RIPE's allocation. I think it should stay
This is a script I kept switching between the lists. I think you may be
right in that it's not be default material. Anybody else want to chime
in on this one?
I think so too.
* HTTPpasswd - A bit too intrusive and probably not useful enough
I can't see that there's much difference between this and HTTPAuth in
Again, HTTPAuth does print more than information obtained from
* mswindowsShell - "backdoor"
My vote is to ditch it too.
* SMTPcommands - I want this to be default, but it usually has a lot of
This is currently run by default and I don't think the quantity of
output should be grounds for omission if it's perceived to be useful.
Good point, but I just don't think that a default script should produce
a large amount of output like this one tends to.
Does anyone have an opinion on this?
* SSLv2-support - Produces quite a bit of output, and doesn't seem
useful enough for default
I think this is quite useful and should remain default, but agree that
the output is often more than required - perhaps it could be improved
I think that with an nmap.verbosity() change it may be good for default.
* zoneTrans - Just doesn't seem like default material IMO
I think the argument for this is similar to the one for
I don't know from experience, but looking at Wikipedia makes me think
that it's not frequent enough.
Now in principle, I think it's a good idea to revisit the scripts that
run by default, but perhaps some firm decision should be made about the
level of intrusiveness permitted in a default scan, offset by the
possible benefits. In order to do that, there'd have to be some method
for measuring levels of intrusiveness. Not that I'm knocking the effort
being made in this regard, not at all, but I think it's kind of skimming
over a topic that probably needs looking at more deeply.
I think a complete review of the Category system is due and I'd like to
see some kind of Metrics system applied to scripts so that they can be
selected based of degrees of intrusiveness and on degrees of
usefulness. Usefulness is rather too subjective, so perhaps benefits
should be measured in probabilities of revealing meaningful information.
If we could construct a method whereby a user can select scripts based
on degrees of a various attributes they might themselves be able to
decide upon the usefulness of a script or how intrusive/fast/deep
they're willing to be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org
Re: [RFC] Default NSE Scripts jah (May 10)
Re: [RFC] Default NSE Scripts Diman Todorov (May 11)
Re: [RFC] Default NSE Scripts Fyodor (May 12)