Re: [NSE] Microsoft SQL Server (MSSQL) library and scripts

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/22/2010 03:45 PM, Fyodor wrote:
> The way you have done it now is actually very similar to how many of
> our other scripts work.  Particularly the SMB family
> (e.g. smb-enum-domains, smb-enum-groups, smb-enum-processes,
> smb-enum-sessions, smb-enum-shares, smb-enum-users, smb-server-stats,
> and smb-system-info), citrix-enum-*, mysql-{info,users,variables}, and
> snmp-win32-*.
>
> So this is a larger issue than mssql-*.  For scripts which gather
> information from a service, do people think we should generally have
> one gathering script controlled by --script-args, or have a separate
> scripts for gathering different pieces of information?
>
> My initial thought is that we might be better off just having
> citrix-enum, smb-enum, mssql-enum, and snmp-win32-enum scripts
> (perhaps -info rather than -enum in most cases) which print a
> condensed summary by default and have a common form of script arg you
> can use to print everything and also options for passing a list of
> information you want to retrieve (users, shares, databases, whatever).
>
> Of course some cases may necessitate separating scripts if we want
> them in different categories, if some require different sorts of
> authentication, etc.
>
> The Nessus approach is to allow plugin explosion and then brag about
> having tens of thousands of plugins.  But I'm not sure that is the
> best approach for Nmap NSE.
>
> I'm interested in what other people think, as these types of scripts
> are proliferating and so it gets harder to change things the longer we
> wait to decide on a standard.

OK, I guess I'll be the first to actually argue :)

I agree that the "Nessus approach" isn't best for Nmap.  However, I don't
think combining a bunch of scripts together to be controlled by script args is
all that much better, unless done very carefully.

You brought up the point of categories and I think that's important here;
below I have the categories listed for only 3 groups of scripts.  These are
*not* all of the scripts which share the same first part of their name; I have
manually removed scripts which shared categories with previous ones in the
list (do correct my list if I made a mistake!).

http-auth.nse:categories = {"default", "auth", "intrusive"}
http-date.nse:categories = {"discovery", "safe"}
http-enum.nse:categories = {"discovery", "intrusive", "vuln"}
http-iis-webdav-vuln.nse:categories = {"vuln", "intrusive"}
http-malware-host.nse:categories = {"malware", "safe"}
http-methods.nse:categories = {"default", "safe"}
http-open-proxy.nse:categories = {"default", "discovery", "external", "intrusive"}
http-userdir-enum.nse:categories = {"discovery", "intrusive"}
http-vmware-path-vuln.nse:categories = {"vuln", "safe", "default"}

mysql-brute.nse:categories = {"intrusive", "auth"}
mysql-databases.nse:categories = {"discovery", "intrusive"}
mysql-info.nse:categories = { "default", "discovery", "safe" }

smb-brute.nse:categories = {"intrusive", "auth"}
smb-check-vulns.nse:categories = {"intrusive","exploit","dos","vuln"}
smb-enum-domains.nse:categories = {"discovery","intrusive"}
smb-os-discovery.nse:categories = {"default", "discovery", "safe"}
smb-psexec.nse:categories = {"intrusive"}

I'm not sure how to go about sorting through this mess to combine the scripts
into one.  Only combine them if the categories are similar?  I don't know how
you can have a file with mixed categories, or how you could possibly call it
from --script.


Also, it's apparent that many sets of scripts are designed to use a library
for most functionality, leaving smaller scripts.  At first this sounds like a
pretty good reason to combine scripts together; however, it really depends on
how you look at it:

$ wc -l http-*

 1942 total
$ wc -l smb-*
 4780 total
$ wc -l snmp-*

 1495 total

Imagine the mess it will be to have these scripts merged together into one
file.  OK, not every script may be combined together, but you get the idea.

I seriously doubt these are all of the http, smb and snmp scripts that Nmap
will ever ship so the numbers above are just starting points, really.

That will be a lot of unrelated code being put into one file, making future
maintenance and development a pain.  If very much of it is related, then it
should probably be in the library already.

And yes, a lot of that is header comments like in some smb-* scripts, but
where would all of this documentation go if they were combined? How would the
NSEdocs look if the comments stayed and were somehow combined?

And keep this in mind compared to above (I found it interesting):

$ wc -l output.cc

2365 output.cc


Please note that I'm not saying don't combine any scripts!  Just that when you
ask "do people think we should generally have one gathering script controlled
by --script-args, or have a separate scripts for gathering different pieces of
information?" (which sounds to me like combining more than just a couple of
scripts together), all I have to say is that if you still want to do it, be
careful about what you combine and how you combine them ;)

> Cheers,
> Fyodor

Cheers,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJLr/pjAAoJEEQxgFs5kUfu0IkP/RMoFs+EcCR0a2NmCIlRdVNA
3Esb6SSzR5XSc2N0AkPH4F0Hn73xOPqbMWT/vSZDwa3U5M8SS8C/kptpi0qVvlcW
CQU0maLRAsbnPDV4swIRTRTg1gId5D40PgEHjoEW11/6Z5VMJc/BZYIg1DGSccgL
EPX4s9OXN6YJIDru8StIYj9yo6GQQhLcImWFODRWbXeLMUhaaMUQYCmBHE8gYQLR
DOUfEVOpswo7K3Is5tRWK46CP8V6fMD12ISNlKYwguQH8G+SYgmvqGST4NfB1yj1
GZOqK0p+9Ibry6Pf5rsJYhUC2KHIjNZGpzhkOFe9vA+yS3f4Co2CvdMYj+thjVfe
81/X+tp7nbAx6oEyseKfAKV4KeCg/yjjmpXUOn3OvNq/UwJKgCpjjC9nFiqaj/EO
+aySWMc/9WiTAolfDXRp1i9wL9JquqERTZwxLDQoX8vDq2anl0Er3uGFJGolaGWt
YEOtVTTsYchhnQDkRENmHtyTAXqaCB7D/C/2Ivxm3UY7UNBmgjGAx88LAC0EvCGW
NYwCaLfBtmD1VBbihmrJBGCcKUjoTpz0MLfBqwENXXk+BLA3MqHC/6fzKb93B7xr
28pVOx94JpoXa7PQ36KXcutw2uWQ6+oKk0OOrhwoAUfXvaZZGJns7hJf26cEj1lS
WdcE6+RufbhP+Z/Upj6z
=E/sF
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/