Nmap Development mailing list archives

Re: [NSE] NTP Peer Listing


From: Fyodor <fyodor () insecure org>
Date: Sun, 11 Apr 2010 13:47:00 -0700

On Sun, Apr 11, 2010 at 06:54:52PM +0100, jah wrote:
On 11/04/2010 02:14, Mak Kolybabi wrote:

I decided the four hundred plus IP addresses is too much output from a
script and so it dumps them to file.  It prints a summary instead:

Hi Jah.  It sounds like you have a lot of great NTP monlist ideas, and
an interesting script.  So pardon me for just focusing this mail on a
very minor portion (the file output idea).

I think we have many scripts which could benefit from a way to handle
a lot of output.  Right now then general approach for such scripts is
that they print a summary by default, print more to Nmap's standard (&
XML) output in a high verbosity mode or in some cases with a special
argument (e.g. mssql-config.showall ).

If we expand Nmap's system for NSE results in the Nmap XML output, we
might be able to have more scripts print a summary to normal output
and include all the data in the XML.

Your ntp-monlist script, on the other hand, opens its own file and
dumps the results there:

123/udp open  ntp     udp-response
| ntp-monlist: dumped 426 discovered IPv4 addresses to file:
| scripts/data/ntp-monlist-10.10.10.123.list

That is fine for a script which isn't (now) included with Nmap, but I
think it raises a bunch of potential issues:

o Where the file is stored.  Different operating systems have
  different default paths and different ways of specifying paths
  (e.g. c:\program files (x86)\nmap vs /usr/share/nmap).

o Permissions.  Even if the user did want the script to be in the
  scripts/data directory as shown above, they probably won't have
  permission if it is in /usr or /usr/local and they are not root.  It
  might even be on a read-only filesystem (e.g. a central fileserver
  or Linux live CD).

o As you noted, there is the issue of what to do if the file already
  exists.

Offering to write a file if the user passes the path as an argument
(as you suggested), sounds reasonable.  But by default I think it is
better to put the information in Nmap's normal and/or XML output.  I
kind of like the idea of putting a summary in normal Nmap output (and
in the XML), while also being able to provide larger results only in
the XML.  NSE doesn't currently support that, but maybe it should.

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


Current thread: