default ntp.conf should use pool.ntp.org servers

If this change was going to be made, the NTP pool operators must be asked to create a vendor-specific pool for Ubuntu. Then ntp must be configured to query {0,1,2,3}.ubuntu.pool.ntp.org.

More information at <http://www.pool.ntp.org/vendors.html#vendor-zone>, including:

"You must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance."

Sam Morris <email address hidden> writes:
> If this change was going to be made, the NTP pool operators must be
> asked to create a vendor-specific pool for Ubuntu. Then ntp must be
> configured to query {0,1,2,3}.ubuntu.pool.ntp.org.
>
> More information at <http://www.pool.ntp.org/vendors.html#vendor-zone>,
> including:
>
> "You must absolutely not use the default pool.ntp.org zone names as the
> default configuration in your application or appliance."

I think that is implicitly understood that one should follow the
rules the pool.ntp.org people have listed.

The pool.ntp.org people will happily set up a vendor pool for Ubuntu
-- it is just a matter of sending them an email message and putting
into the Ubuntu documentation a note encouraging people to join the
server pool if they can.

In any case, setting up a pool will be a big win. (I also think an ntp
client should be configured in Ubuntu by default, as is done in
Windows and OS X, but that's another story.)

Perry

I agree that ntp should be setup by default, but but one has to keep in mind setups that are not connected and offer a sensible fall back.
The first thing I do when I install ubuntu is install ntp nad add eu.pool.ntp.og as my default server.

But this can be probably arranged (in the shot term?) without updating the package by having ntp.ubuntu.com set up as an alias to ubuntu.vendor.pool.org.
It would also be nice to have region specific settings (eu.ntp.ubuntu.com etc ..) that are chosen automatically when you chose your time zone.
as it would help load distribution. AFAIK pool.ntp.org does not use geolocation to try and provide severs closer to you.

The only problem with pool.ntp.org is the severe lack of ntp servers in Africa (just 1 as i write :-( )

Philip

root@venus:/etc# ntpq -p ntp.ubuntu.com
europium.canonical.com: timed out, nothing received
***Request timed out
root@venus:/etc#

http://www.pool.ntp.org/

several of my machines were off, some by minutes

I'm concerned with the security implications of using a pool of unknown time servers per default. If I understand correctly, anyone can volunteer to participate in the pool. If the end user's ntpd is started with the -g option, overriding the 1000 seconds sanity check (as was the default in Ubuntu 7.10), and the server selects only one time server from the pool to synchronize from, an attacker who controls a single server in the pool can set the time of many Ubuntu hosts over the world. Also, he will know the IP addresses of the victims. If any of them happen to be interesting targets for the attacker, he can then mount further attacks on all cryptographic protocols that depend on correct time-keeping (for example, to prevent replay attacks). That would be a serious security threat for the users.

Alexander Konovalenko <email address hidden> writes:
> I'm concerned with the security implications of using a pool of unknown
> time servers per default.

Most other OSes out there do this or variations on it now, so it would
hardly be an Ubuntu specific problem.

There are only security problems for Kerberos based services. If
you're using Kerberos, you had better be set up to use NTP one way or
another anyway, and probably a custom setup. If you're not already
using ntp, your kerberos setup won't work at all.

> If I understand correctly, anyone can volunteer to participate in
> the pool. If the end user's ntpd is started with the -g option,
> overriding the 1000 seconds sanity check (as was the default in
> Ubuntu 7.10),

The default can always be changed, of course, but I think it hardly
matters.

> and the server selects only one time server from the pool to
> synchronize from,

That's a big if. If you have three servers in your list, the odds of
all three being suborned are minimal. The odds of an attacker being
able to influence which clients end up getting pointed to them in the
DNS are also minimal. Beyond that, there is the fact that there are
generally no real security implications to having your clock altered.

> an attacker who controls a single server in the pool can set the
> time of many Ubuntu hosts over the world.

Yes. That's hardly a problem.

> Also, he will know the IP addresses of the victims.

Not really. He'll only know they asked his machine for time -- he has
no way of knowing if they actually set the time (especially if they
have other servers giving different numbers) and he has no real way to
exploit any of this anyway.

> If any of them happen to be interesting targets for the attacker, he
> can then mount further attacks on all cryptographic protocols that
> depend on correct time-keeping

Which protocols would those be? I don't think Ubuntu ships with any
kerberos enabled apps, and even for kerberos the attacks are minimal,
since the clock is only used for ticket expiry.

> (for example, to prevent replay attacks).

TLS and IPsec use entirely different mechanisms to prevent
replay. There are no clock dependent security protocols in real use
that I'm aware of other than Kerberos. Even for Kerberos, trying to
set a clock far off is only going to allow an attacker to extend a
ticket, it won't actually allow important remotely exploitable
attacks. I can post references on this if needed.

> That would be a serious security threat for the users.

I do security for a living. I see no threat here, and certainly no
serious threat.

If you are really concerned about security, worry about real problems
in the default Ubuntu config, like turning zeroconf on by default,
which expose people to actual problems. This "threat" you are worried
about in setting a default ntp.conf is not real.

Perry

Consider also that NTP servers that serve the wrong time are ejected from the pool.

While it is true that NTP servers that serve the wrong time are ejected
from the pool, the default ntpd only resolved DNS at startup.

In any case the concern with anonymous servers is not dissimilar from that
wit anonymous mirrors.
If you are willing to risk downloading ubuntu over, say, bittorrent I can't
see why you wouldn't risk
your clock being a few ticks off.

If your security requirements are that stringent, you should be running your
own stratum 1 ntpd (a gps reciever does not cost that much).

Currently most people trust Ubuntu (or microsoft, or the U.S. gov with GPS)
for their timekeeping. While all of these are
theoretically more trustworthy then a pool of volunteers, there are no
guarantees.

Philip

On 07/02/2008, Sam Morris <email address hidden> wrote:
>
> Consider also that NTP servers that serve the wrong time are ejected
> from the pool.
>
> --
> default ntp.conf should use pool.ntp.org servers
> https://bugs.launchpad.net/bugs/104525
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Inkwina <email address hidden> writes:
> In any case the concern with anonymous servers is not dissimilar from that
> wit anonymous mirrors.

It is quite dissimilar, in that an anonymous mirror (where you didn't
check the signatures) could take over your machine. There is no
evidence an anonymous bad actor controlling one of several clocks you
are reading could take over your machine -- even if he controlled all
the clocks, he could probably not take over your machine.

> If your security requirements are that stringent, you should be running your
> own stratum 1 ntpd (a gps reciever does not cost that much).

GPS signals can be externally corrupted with an appropriate
transmitter as well. There is no actual way to prove you have the
correct time. (This is one reason very few protocols require accurate
timekeeping for security.)

--
Perry E. Metzger <email address hidden>

I must add that it seems that the ntp.ubuntu.com server doesn't work at all:

   it happened that this morning, the time on my laptop was 10 minutes late
   after 1 hour, it was still 10 minutes late
   I replaced ntp.ubuntu.com by another ntp server, and 2 minutes later,
   the time became correct.
   I checked also on another desktop: same result

The problem with ntp.ubuntu.com seems to be related to its load:
  this morning(UTC +2), the time was not updated after 2 hours
  this afternoon, the update arrives after about 10 minutes

anyway, I put now:
   server 0.fr.pool.ntp.org
   server 1.fr.pool.ntp.org
   server 2.fr.pool.ntp.org

  which seems more reliable

Thank you for taking the time to report this bug and helping to make Ubuntu better. I have tested using pool.ntp.org and it works well. This should be technically easy to implement, if it's decided this feature is worthwhile.

Hew <email address hidden> writes:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. I have tested using pool.ntp.org and it works well. This
> should be technically easy to implement, if it's decided this feature is
> worthwhile.
>
> ** Changed in: ntp (Ubuntu)
> Importance: Undecided => Wishlist
> Status: New => Triaged

I don't understand why "Triaged" was needed for a problem that could
have been fixed by replacing one line in a file. Why is this is a
"Wishlist" item? It seems a) pretty important and b) pretty trivial to
fix.

Perry

You can read the status and importance guidelines at https://wiki.ubuntu.com/Bugs/Status and https://wiki.ubuntu.com/Bugs/Importance .

Hew <email address hidden> writes:
> You can read the status and importance guidelines at
> https://wiki.ubuntu.com/Bugs/Status and
> https://wiki.ubuntu.com/Bugs/Importance .

I'm aware of them. The designation you've made makes no sense. I think
it is based on the fact that you don't understand the bug and are more
focused on trying to clear things out of the bug database than on
fixing them.

The fix here is very straightforward.

Perry

Thank you for your bug report. To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/community/conduct/ . Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind.

I am not a developer, but a triager. I marked this bug as Triaged, as I believe it is ready to be looked at by a developer. I marked the importance as Wishlist, as it is a request for new functionality, rather than reporting a crash or other problem. This makes more sense than New/Undecided which has been its status for over a year.

If the fix is straightforward, you may submit it yourself. To get your fix included in Ubuntu, it would help if you tried transforming it into a debdiff (http://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff) and submit it for review (http://wiki.ubuntu.com/SponsorshipProcess). If you prefer somebody else to do that, that's fine - please just indicate if you're available to do that.

Please don't accuse me of malicious triaging :P. Marking a bug as Triaged is hardly clearing it out; it is the status that is most likely to get the attention of a developer. Lets keep comments relevant to the original report now. Thanks.

Hew <email address hidden> writes:
> If the fix is straightforward, you may submit it yourself.

I did. Read the bug report. It is editing two lines in a file (or
restoring the file with the two lines edited if it was removed in
Intrepid).

--
Perry E. Metzger <email address hidden>

A complete fix is more than you've submitted so far. It should use the user's time zone to set the proper sub-pool, e.g.:

0.north-america.pool.ntp.org
1.north-america.pool.ntp.org
2.north-america.pool.ntp.org
3.north-america.pool.ntp.org

Normally you set 3 or 4 servers, so no one bad server can result in incorrect time.

The current ubuntu ntp server could then be recycled to become part of a regional pool, and no longer have high load to contend with.

I believe that this bug should not be marked as 'Wishlist" because using single NTP server is entirely unacceptable.

1) At least three NTP servers must be configured in ntp.conf to choose best of them and detect single outlayer
2) Routing problems are possible
3) Server failures are even more possible

Two possible solutions of the problem:

1) Use pool.ntp.org by default.
2) Provide our own pool of NTP servers.

#1 takes much less effort. Of course, fine tuning of this (i.e. using country-specific pools) can be added to Wishlist.

It would be useful to have multiple servers listed.

Here is a machine, over in Australia.

ntpq> peers
     remote refid st t when poll reach delay offset jitter
==============================================================================
*europium.canoni 193.79.237.14 2 u 49 64 377 331.811 -207.01 36.624

The impact of the significant delay and jitter is that ntp will prefer to step the time rather than slew it.

This means that I get dovecot (and other things) complaining about time moving backwards (http://wiki.dovecot.org/TimeMovedBackwards) fairly regularly.

It would be useful if Canonical could have a second, or third, machine in a different data centre also configured to provide NTP service and then have the default configuration updated to reduce the occurance of this problem.

Thanks,
Anand

On Fri, Feb 27, 2009 at 01:30:14PM -0000, Anand Kumria wrote:
> This means that I get dovecot (and other things) complaining about time
> moving backwards (http://wiki.dovecot.org/TimeMovedBackwards) fairly
> regularly.

BTW, this is the reason why I have created NTP check script (see attachment).

>
> It would be useful if Canonical could have a second, or third, machine
> in a different data centre also configured to provide NTP service and
> then have the default configuration updated to reduce the occurance of
> this problem.

NTP pool can be used for this...

--
Dmitry Ivanov "A mouse is a device used to point
Network engineer at the xterm you want to type in"
+371 67788235

I've unsubscribed from the bug report. It could have been fixed in a few minutes one way or another at any time over the last few years but no one did, which is a sad commentary on the management of the project. Anyway, after years of this bug report remaining in limbo I've ceased to care what happens.

FWIW, pool.ntp.org does geolocation nowadays, so it's not necessary to use the regional zones. Which is good, cuz it would be pretty complicated: Some don't have enough servers, or even have none at all, so you need to fall back to nearby countries or the continental zone.

I fully agree with comment 6 by Perry E. Metzger. Switching to ntp pool should not be a security issue as bad servers are automatically filtered from the pool. Additionally, bad servers are detected by the NTP algorithm if enough servers are selected (they are called "falsetickers", see <http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3.>). 4 servers should be enough for most cases.

To push it a bit I requested a vendor zone in the pool. I should get an answer within 3 days and will let you know.

I hope it will help this bug forward.

I got this answer today:

> Sorry about the late response. I really wanted someone from the ubuntu project to set it up -- but I guess that's not forthcoming, so I approved the zone anyway and we'll see what happens.

And in another email:

> Your vendor pool zone "ubuntu" has been setup. The
> hostnames are below. They will be active within a few hours.
> 0.ubuntu.pool.ntp.org
> 1.ubuntu.pool.ntp.org
> 2.ubuntu.pool.ntp.org
> 3.ubuntu.pool.ntp.org
>
>
>
> Please subscribe to the (announce-only, very low traffic)
> ntppool-vendors list at Google Groups. We recommend everyone in your
> organization involved with this is subscribed there.
> http://groups.google.com/group/ntppool-vendors
>
> If you are a commercial organization/product/company consider
> contributing back to the pool so we can keep the service sustainable
> even with the commercial usage:
> http://www.pool.ntp.org/vendors/contribute.html
>
> If you do not, you seriously diminish the chances that we can continue
> to offer this service to you.
>
>
>
> Kind regards,
>
> Ask Bjoern Hansen

So we just have to change that in ntp.conf. I guess it could greatly simplify the GUI, too...

I think it could be a good idea to put a note in the conf file to recommend people to join the pool. Maybe ntp.ubuntu.com could be included?

Finally, the developer of the pool mentioned wishing a contact from the Ubuntu project to be involved… who should be contacted?

See if you can contact someone from the Canonical server team. Personally I'd also try to contact the ntp maintainer via IRC too.

Here is a proposal patch for ntp.conf. I left the ntp.ubuntu.com server...

I also contacted the server team admin, but I don't know who is the ntp maintainer exactly.

/src/time/ntp-servers-list.c from the gnome-system-tools package also needs to be patched.
Currently the time-admin config tool hard codes the ntp servers (seems like a list of stratum 0 servers).
Minimally the ubuntu.pool.ntp.og servers should be added, but Ideally no servers should be hard-coded.

I had nearly forgotten about ntp-servers-list.c. Here is a patch, but I don't know how to format it best…

Thanks for subscribing the Technical Board to this bug.

Please add discussion of the default NTP Servers to the agenda for the
next Technical Board meeting that you are able to attend, and we will
discuss it with you there.

Scott

On Sun, Jan 23, 2011 at 2:21 AM, Xavier Robin <email address hidden> wrote:
> I had nearly forgotten about ntp-servers-list.c. Here is a patch, but I
> don't know how to format it best…
>
> ** Patch added: "patched ntp-servers-list.c"
>   https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/104525/+attachment/1803799/+files/ntp-servers-list.c.diff
>
> --
> You received this bug notification because you are a member of Ubuntu
> Technical Board, which is a direct subscriber.
> https://bugs.launchpad.net/bugs/104525
>
> Title:
>  default ntp.conf should use pool.ntp.org servers
>
> --
> technical-board mailing list
> <email address hidden>
> https://lists.ubuntu.com/mailman/listinfo/technical-board
>

I've added this bug to https://wiki.ubuntu.com/TechnicalBoardAgenda for the next meeting, which is tomorrow, 25 Jan at 1500 UTC. The issues seem pretty clear from the comments, so I think we can discuss it regardless of who shows up. Folks who are interested in this issue are encouraged to attend, but I don't think we need to block on someone stepping forward to represent at the meeting.

Was discussed and approved in current TB meeting, will sponsor the g-s-t patch.

I will sponsor ntp patch.

This bug was fixed in the package gnome-system-tools - 2.32.0-0ubuntu5

---------------
gnome-system-tools (2.32.0-0ubuntu5) natty; urgency=low

  * Add 96_ubuntu_ntp_pool.patch: Offer Ubuntu specific NTP servers;
    pool.ntp.org offers geolocation and automatic QA. Thanks Xavier Robin for
    coordinating the setup of the Ubuntu ntp.org pool and preparing the patch!
    (LP: #104525)
 -- Martin Pitt <email address hidden> Tue, 08 Feb 2011 16:46:57 +0100

This bug was fixed in the package ntp - 1:4.2.6.p2+dfsg-1ubuntu4

---------------
ntp (1:4.2.6.p2+dfsg-1ubuntu4) natty; urgency=low

  * debian/ntp.conf: adjust to use X.ubuntu.pool.ntp.org in addition to
    ntp.ubuntu.com (LP: #104525)
 -- Jamie Strandboge <email address hidden> Tue, 08 Feb 2011 10:03:19 -0600