Re: do we really need all these SNMP scripts?

[Patrik Karlsson <patrik () cqure net>]

On 5 feb 2011, at 22.43, Rob Nicholls wrote:

> On Sat, 5 Feb 2011 22:10:06 +0100, Patrik Karlsson wrote:
> > I don't see the point of implementing a replacement of the snmpwalk
> > or osql commands as NSE scripts as I would much rather use the
> > original tools to perform their tasks.
>
> I'm lazy/efficient. If I can get Nmap to do everything (or at least most things), I don't have to worry about having 
> all of these disparate tools installed to do the same thing, or having to try and read/parse the output (Nmap's XML 
> output is valid, stable, reliable, useful).

Well, the everything part sounds appealing to me too :)

> Plus I can do things like use snmp-brute to identify the community string and then use the other scripts (including 
> potentially an snmp-walk script if one were developed) to grab the data without having to run separate programs and 
> manually (or write a script to) pass data between them. It's also typically easier to get output out of Nmap's XML 
> file than parse the output from these different programs (which could, although they typically don't, change).

I don't think it would be very difficult to add a snmp-walk script that would accept a MIB to walk, as most of the 
code, including the walk function, is in the SNMP library. 
However, in my opinion, I think that the purpose would be to get a more generic tool to extract the "raw" data from 
SNMP rather than replacing the other scripts with it.

Currently, the code in each script is mostly formatting the output so that it's easier/cleaner to read.
Unfortunately the formatting, sorting and other manipulations are a little specific for each extracted data.
For me this formatting code is useful, and in order to combine scripts that code would need to be lifted into the 
combined script.

> If you start going down the route of "use the original tools", then we could rule out several of the existing scripts 
> (http-enum.nse or nikto.pl; snmp-interfaces.nse or snmp_ifaces.nasl or Getif; ssl-enum.nse or thcsslcheck or 
> ssl_supported_ciphers.nasl; smb-* or enum.exe). I'm really glad we have them though (and in many cases they're more 
> reliable and can support IPv6). But on the flip side, I agree that we shouldn't focus on creating scripts when there 
> are already perfectly good alternatives. If someone happens to develop and submit them, or wants to, then great. I'm 
> not going to discourage them. But I'd still prefer to see NSE scripts that do things that aren't - or can't be - done 
> by anything else.

Point taken.

> Again, just my late night thoughts :)
>
> Rob
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/


//Patrik
--
Patrik Karlsson
http://www.cqure.net
http://www.twitter.com/nevdull77





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