RE: do we really need all these SNMP scripts?

["Rob Nicholls" <robert () robnicholls co uk>]

I suspect it's because there has traditionally been an emphasis on Nmap
output to be concise. If a script were to display the entire MIB this could
dramatically increase the Nmap output without giving much additional useful
information (compared to what's already displayed by the current scripts). 

What might be worth considering, which is similar to what you've proposed,
is an snmp-walk script that walks the entire MIB and stores it in the nmap
registry, so the other existing scripts could subsequently check the Nmap
registry for the information (much like how the http library caches data, I
believe) and display the requested information, or retrieve it if the data
hasn't been cached (in case people want specific scripts to run without
waiting for an entire walk to complete first). I suspect it's easier to get
all the snmp scripts to run with --script "snmp*" than ask users to add
multiple arguments to a single snmp script, although the new Zenmap
Scripting tab in the Profile Editor should help.

I agree that the Nmap output for such a script should display nothing unless
the verbosity has been raised (which should happen if the script is
specifically stated). I wouldn't generally want to see all of the returned
information on screen, but I'd quite like to have it stored in the XML
output (maybe it's just me?). More than likely, I'd look at the script
output for the specific snmp scripts first, as it's much easier to find the
interfaces in the output for that script than wade through the whole MIB
(plus it's probably easier to automate parsing the output of each script,
rather than parsing it myself).

It's already known that Nmap's script output is quite basic, and there are
plans to improve it in the future. I'd quite like to see elements for:

 - Error messages (in case errors are detected while the script runs)
 - Nmap output (as displayed on screen)
 - Raw data (e.g. the entire MIB could be stored here)

That would make it easier to let people know about errors without forcing
the error to be displayed during a default scan and becoming part of the
script output, like you get with the SMTP scripts, for example.

It could also be useful for scripts like snmp-ios-config script. Instead of
writing the entire config to screen it could perhaps store the config in the
XML output and only display the more interesting lines/information (unless
Nmap's verbosity is raised). For example, the default Nmap output could be
something like "Cisco IOS config file was successfully retrieved", with the
entire config stored somewhere in the XML output, and displayed on screen
when verbosity is 2 or more.

Just some random late night thoughts.

Rob

-----Original Message-----
From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org]
On Behalf Of mike bickett
Sent: 04 February 2011 20:54
To: nmap-group
Subject: do we really need all these SNMP scripts?


i was curious. i noticed there are now about 4 or 5 different scripts that
each dump different info related to SNMP. i was wondering why we needed to
go this route. it seems to me a tool like SNMP-utils (snmpwalk to be
specific) would simply be able to accomodate  what everyone was trying to do
with their scripts. why not have a complete NSE script like an SNMP walk
utility that dumps everything at once and walks all MIBS, instead of going
through and making each individual script for specific MIB info. you could
simply set a verbosity range and have flags for each output you wanted,
instead of a bunch of scipts that really all do the same thing, just dumping
different info. i hope this doesn't sound too confusing and i hope it makes
sense. it does to me anyway
 
m|ke                                      
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


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