[Q] Why do many time servers time out on queriesfrom ntpq -p?

I've been trying the peers command in ntpq on a number of time
servers and finding that for as many that do respond, there are about
an equal number that do not. An example of a failing response is:

ntpq> host sundial.columbia.edu
current host set to hickory.cc.columbia.edu
ntpq> peers
hickory.cc.columbia.edu: timed out, nothing received
***Request timed out

I can reproduce identical successes and failures from 3 computers
running different OSs on independent networks.

These I've tried work just fine:
timex.cs.columbia.edu
time.euro.apple.com
lain.ziaspace.com
ntp.nblug.org
ntp1.cs.wisc.edu
clock1.unc.edu

But these time out:
sundial.columbia.edu
time.apple.com
morose.quex.org
ntp.sycharlutheran.org
ntp.bytestacker.com
ntp1.kansas.net

All of the above were tested and gave the same results on
kennedy1.aecom.yu.edu (Linux with ntpq 4.2.4p4@1.1520-o)
fluxsoft.com (FreeBSD with ntpq 4.2.0-a)
ool-45766590.dyn.optonline.net (Mac OS X with ntpq 4.1.1@.786)
--

Maurice Volaski, [email]mvolaski@aecom.yu.edu[/email]
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University

On 2008-04-09, Maurice Volaski <mvolaski@aecom.yu.edu> wrote:[color=blue]
> I've been trying the peers command in ntpq on a number of time
> servers and finding that for as many that do respond, there are about
> an equal number that do not. An example of a failing response is:
>
> ntpq> host sundial.columbia.edu
> current host set to hickory.cc.columbia.edu
> ntpq> peers
> hickory.cc.columbia.edu: timed out, nothing received
> ***Request timed out[/color]

The server operator has set a 'noquery' restriction.

--
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - [url]http://support.ntp.org/[/url]

Maurice Volaski wrote:[color=blue]
> I've been trying the peers command in ntpq on a number of time
> servers and finding that for as many that do respond, there are about
> an equal number that do not. An example of a failing response is:
>
> ntpq> host sundial.columbia.edu
> current host set to hickory.cc.columbia.edu
> ntpq> peers
> hickory.cc.columbia.edu: timed out, nothing received
> ***Request timed out
>
> I can reproduce identical successes and failures from 3 computers
> running different OSs on independent networks.
>
> These I've tried work just fine:
> timex.cs.columbia.edu
> time.euro.apple.com
> lain.ziaspace.com
> ntp.nblug.org
> ntp1.cs.wisc.edu
> clock1.unc.edu
>
> But these time out:
> sundial.columbia.edu
> time.apple.com
> morose.quex.org
> ntp.sycharlutheran.org
> ntp.bytestacker.com
> ntp1.kansas.net
>
> All of the above were tested and gave the same results on
> kennedy1.aecom.yu.edu (Linux with ntpq 4.2.4p4@1.1520-o)
> fluxsoft.com (FreeBSD with ntpq 4.2.0-a)
> ool-45766590.dyn.optonline.net (Mac OS X with ntpq 4.1.1@.786)[/color]

If the server operator has 'noquery' specified in the default restriction it
will prevent the server from responding to ntpq and ntpdc.

Interestingly, I actually wrote a script that uses 'ntpq -pn' to randomly
query client entries in my ntp_clients_stats log file. I've found that only
about one percent respond on average.

Dennis

--
Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com
NTP Server Information: \ [url]http://saturn.dennishilberg.com/ntp.php[/url]

On Apr 12, 12:29*am, Steve Kostecke <koste...@ntp.org> wrote:[color=blue]
> The server operator has set a 'noquery' restriction.[/color]

I'll try to pre-emptively answer the next question, whcih is likely to
be "why would they do that?"

The answer is security. On our network, we follow the principle of
least privelege. That is, we enable or allow only that which is
required to perform a particular function, and nothing else. Some
people call this a "default deny" permissions model.

ntpq can leak information about your internal network structure that
could be useful to an attacker. It is also another bit of network-
enabled code that could have buffer overflows or other vulnerabilites.
ntp (the protocol) functions just fine with without mode 6/7 queries
enabled, so they are disabled.

On 2008-04-12, Ryan Malayter <malayter@gmail.com> wrote:
[color=blue]
> On Apr 12, 12:29*am, Steve Kostecke <koste...@ntp.org> wrote:
>[color=green]
>> The server operator has set a 'noquery' restriction.[/color]
>
> I'll try to pre-emptively answer the next question, [which] is likely to
> be "why would they do that?"
>
> The answer is security.[/color]

It also denies the users of a time server potentially valuable
information about that server's time sources.

You may find it acceptable to use a block box time source with
un-auditable time sources. I do not.

--
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - [url]http://support.ntp.org/[/url]

On Apr 12, 7:23*pm, Steve Kostecke <koste...@ntp.org> wrote:[color=blue][color=green]
> > The answer is security.[/color]
>
> It also denies the users of a time server potentially valuable
> information about that server's time sources.
>
> You may find it acceptable to use a block box time source with
> un-auditable time sources. I do not.
>[/color]

There is nothing about the ntpq output that couldn't be trivially
faked by a malicious server operator. Mode 6/7 capability adds no true
security or assurance to the users of an ntp server. Authentication
does not solve this problem either.

In reality, all public ntp servers are "black boxes", because you
can't trust anything they tell you, including the time. This is why
you configure a diverse set of time servers.

--
RPM

Ryan Malayter wrote:[color=blue]
> On Apr 12, 7:23 pm, Steve Kostecke <koste...@ntp.org> wrote:[color=green][color=darkred]
>>> The answer is security.[/color]
>> It also denies the users of a time server potentially valuable
>> information about that server's time sources.
>>
>> You may find it acceptable to use a block box time source with
>> un-auditable time sources. I do not.
>>[/color]
>
> There is nothing about the ntpq output that couldn't be trivially
> faked by a malicious server operator. Mode 6/7 capability adds no true
> security or assurance to the users of an ntp server. Authentication
> does not solve this problem either.
>[/color]

That may be but mode 6/7 is used to also configure the server and for
DNS when necessary.
[color=blue]
> In reality, all public ntp servers are "black boxes", because you
> can't trust anything they tell you, including the time. This is why
> you configure a diverse set of time servers.[/color]

If you want to trust them you should use autokey.

Danny