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

[Richard Sammet <richard.sammet () googlemail com>]

Hi David,

thanks for this great set of modifications. Thats exactly what I meant
when I asked for a detailed coding guideline ;)

About the choice for the time stamp: Well, the reference time stamp
you noted holds the time the local clock was last set or corrected. As
my intention is to get to the actual system time of the system I am
scanning I chose the receive time stamp as this is the server time
when our request arrives at the server. We could also use the transmit
timestamp - this one holds the time at the server when the response
was crafted for transmission.
We could use both and calculate the difference to get a clue about the
actual system load of the targeted system. Thats something I once used
for a demonstration on how to identify the actual spanning tree in a
network when the ntp server of the switches are reachable throughout
the network. By measuring the load of all components you are able to
get a clue about traffic flow in a network... This should also work
for routers...


Greetings,
Richard



On Sun, Dec 13, 2009 at 12:46 AM, David Fifield <david () bamsoftware com> wrote:
> 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/