Re: [RFC] Default NSE Scripts

[jah <jah () zadkiel plus com>]

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,
UPnP-info seems to have gone AWOL).
> Scripts run by default should pretty much satisfy these:
>
> 1) Quick
How to measure this?  The only script I would call slow is bruteTelnet
which is "Vulnerability".
> 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.
> 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"?
> 4) Not in "version" category since those are run with -sV
Agreed.  But wouldn't it be nice to run some of these version scripts
without version scanning.

So here's a few comments on individual scripts.
> Default:
>
> * anonFTP
> * 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?
> * finger
Isn't finger a bit obscure now?
> * ftpbounce
> * 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?
> * HTTP_open_proxy
> * MSSQLm
> * MySQLinfo
> * nbstat
> * ripeQuery
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
in discovery.
> * robots
> * rpcinfo
> * showHTMLtitle
> * showOwner
> * SMTPsysdesr
> * SSHv1-support
+ UPnP-info
> Not Default:
>
> * bruteTelnet - Too intrusive and slow
> * chargenTest - Obscure / "demo"
> * daytimeTest - Obscure / "demo"
> * echoTest - Obscure / "demo"
> * HTTPpasswd - A bit too intrusive and probably not useful enough
I can't see that there's much difference between this and HTTPAuth in
terms of usefulness and intrusiveness.
> * HTTPtrace - Not default material
> * iax2Detect - "version"
> * ircServerInfo - I don't think this is default material (but I'm also
> not an IRC user)
> * ircZombieTest - "malware"
> * kibuvDetection - "malware"
> * mswindowsShell - "backdoor"
My vote is to ditch it too.
> * netbios-smb-os-detection - I want this to be default, but it's "version"
> * PPTPversion - "version"
> * promiscuous - I don't think it's useful enough
> * RealVNC_auth_bypass - "backdoor"
> * showHTTPversion - Obscure / only category is ""
> * showSMTPVersion - Obscure / "demo"
> * showSSHVersion - Obscure / "demo"
> * skype_v2-version - "version"
> * SMTPcommands - I want this to be default, but it usually has a lot of
> output
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.
> * SMTP_openrelay_test - "demo" because of "real hostname" issue
> * SQLInject - Obvious reasons :)
> * 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
with nmap.verbosity().
> * strangeSMTPport - Obscure / "backdoor"
> * xamppDefaultPass - "vulnerability"
> * zoneTrans - Just doesn't seem like default material IMO
I think the argument for this is similar to the one for
dns-test-open-recursion.


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.

Best,

jah



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