Re: [NSE] NTP info gathering script...

[David Fifield <david () bamsoftware com>]

On Sat, Dec 12, 2009 at 06:49:54PM +0100, Richard Sammet wrote:
> Hi David,
>
> thanks a lot for your valuable input.

Thanks, Richard, for your script. I have committed it, with some
modifications. Here's a summary of my changes. Some more comments are
below that.

* Removed findINtable, replaced with a make_set function.
* Removed script args.
* Used a simpler method of getting the timestamp fraction.
* Removed try exception handling and replaced it with a check on the
  status returned by comm.exchange. This way one of the queries can fail
  and the other may still succeed.
* Removed length requirements from the comm.exchange calls; these were
  making the queries hang when responses were not long enough. (For
  example waiting for 16 lines when only 4 were available.)
* As a consequence of the above, short timeouts are no longer required,
  so I removed the timeout code to just use the defaults.
* Did more careful parsing of responses, by parsing the data length
  field and making sure start and end quotes match.

About that last one, I left this comment in the script:
    -- This parsing is not quite right with respect to quoted strings.
    -- Backslash escapes should be interpreted inside strings and commas should
    -- be allowed inside them.
    for k, q, v in string.gmatch(data, "%s*(%w+)=(\"?)([^,\"]*)%2,?") do
The parsing code is probably adequate, but it's going to be fooled by
strings like
    var="a \"quoted\" string"
    var="Sat, Dec 12"
I invite you to improve the parsing if you wish. I thought about it, and
I don't think it's possible with Lua patterns. You might be able to do
it conveniently with the pcre library.
http://nmap.org/nsedoc/lib/pcre.html

> I tried to follow all of your hints but for the one about testing an
> array/table for an element I was not able to implement it like you
> noted. It looks like this only works for "hashes" but not for
> "arrays":
>
> [quote]
> > t = {"test1", "test2", "test3"}
> > if t["test2"] then print "foo" end
> > t = {test1="test1", test2="test2", test3="test3"}
> > if t["test2"] then print "foo" end
> foo
> >
> [/quote]

I'm sorry, that was my mistake. You're right. I changed the code to
transform the array into a table mapping strings to true so the shorter
syntax can be used.

> I also added to the script that it fetches the time from the server -
> well, this is most obvious when testing a NTP server, isn't it? ;)

Thanks, that's a good idea. From appendix A of RFC 1305 I see that there
are several timestamps that come back in the response: reference
timestamp, originate timestamp, receive timestamp, and transmit
timestamp. From reading the descriptions, it seems that the reference
timestamp is the most appropriate value. Is that true, or is there a
reason to use the receive timestamp as the script does?

> For the variables argument - As the variables available really depends
> on the implementation of the NTP service (depending on the vendor
> there might be some variables we are not aware of yet) I think its a
> very useful thing to have the option to print all variables received.

I changed the script to show all the variables when verbosity is used or
the script is called by name on the command line (just like you had it
with "any"). There is some good information in there. I think if anyone
is looking for extra information they can just turn on verbosity and
sift through all the fields.

When you use script arguments, you have to give them names that relate
to the name of the script, to avoid conflict with other scripts.
"variables" is too broad a name.

Thanks again; this is a nice script. It was pretty surprising to me that
NTP advertises the processor type and operating system of the server, as
well as its upstream time provider.

|   version: ntpd 4.2.4p4@1.1520 Thu Oct 25 11:17:57 UTC 2007 (3)
|   processor: i686
|   system: Linux/2.6.30
|   refid: 207.171.7.152

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