1

I am trying to install a time server on a local Ubuntu machine, so other servers in my network would sync with it. We have decided to install our own time server, rather than letting each server update from an external server, to minimize the security risk.

  • Any ideas what's the best server to install?
  • Are there any known security issues?
  • Where should the server update from? Is there a well-trusted time server out there?

I would appreciate any help or reference links!

Thanks,

Udi

Adam Matan
  • 12,504
  • 19
  • 54
  • 73
  • 2
    If security is critical (e.g. you can't connect the servers to another device that has internet access) then you could consider using a radio broadcast time source, e.g. the MSF signal from NW England and the DC signal based in Frankfurt. Both cover a radius of about 1500km. Devices that use these range from a simple clock-like device to a rackmount NTP server that can also synchronis wallclocks on the site. – mas Aug 02 '09 at 19:30
  • Wow. That's interesting... sounds like residue from the cold war. I am not in such need now, but I will keep this option in mind. – Adam Matan Aug 03 '09 at 07:34
  • @mas: there is another radio broadcast time source which should work in most of the world: GPS – CesarB Aug 03 '09 at 11:25

3 Answers3

9

The standard ntp (may also be ntp-server or ntp-simple) package on any physical linux machine is fine. Don't use a VM.

Many people will claim that there's information leakage when others can know what time you have, however many other services leak the time, and you get a benefit when all logs are syncronised in case of any issues. The default debian configuration locks remote users from doing anything but time syncronisation and is enough.

As for what to update from pool.ntp.org is the answer, use the appropriate pool for your country if possible. This is also almost always the default configuration for linux ntp's.

LapTop006
  • 6,466
  • 19
  • 26
3

Some guides I use when setting up NTP networks:

  • It is a very good idea to configure at least two time-servers on your network. Set them up as peers (the line "peer [ipaddress]" in the ntp.conf), and if possible give them different external NTP hosts to sync from.
  • Configure your clients to use all of your time-servers. In case one goes away, they'll still have good time and won't go out of sync during the outage of the one.
  • Use either Autokey or symmetric key crypto between your peer servers.
  • Set up appropriate acl lines in your ntp.conf file, allowing the peers to talk to each other, but all other clients only get NTP information and no control data.

The first point is to give your network resilience in the face of internet outages. When the internet connection goes out, your peer servers will maintain a consensual time between themselves and never go out-of-sync. Which means that your clients will not go out-of-sync. If time is important to you, this is a very good thing.

As for the ACL options, setting reasonable defaults will help prevent evil happening:

restrict default ignore #deny access to general internet, just 'cause
restrict 192.168.0.0 255.255.0.0 nomodify nopeer # allow restricted access to internal
restrict 192.168.202.202 #allow TimeHost1 full access
restrict 192.168.202.203 #allow TimeHost2 full access
restrict 192.168.200.158 nopeer #allow the admin workstation to make changes

This will allow clients the ability to use tools like ntpq to diagnose NTP problems, but won't allow it to change anything.

As for autokey vs. symmetric key, that depends on how robust you want your network. Setting appropriate ACL values should provide resistance to evil, but this would provide an added layer of protection against spoofing. Of the two, autokey is easier to set up, but symmetric is newer and more robust.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
  • I have just leaved "restrict default ignore" on one of the machines, but it still listens to some non-localhost interfaces. Any Ideas? – Adam Matan Aug 03 '09 at 08:51
  • I believe what restrict default ignore does in this instance is still open the port on the interface, but tells anything connecting to it to shove off. If you really want to prevent anything from opening a connection to the local ntp-daemon, I suggest using the firewall to restrict it. – sysadmin1138 Aug 03 '09 at 14:38
0

I'd recommend OpenNTPd (portable).

From their manifesto:

Current NTP daemons are complex and difficult to configure and/or have questionable licenses. Because of this, only a limited number of systems run NTP, resulting in many machines that are off by months and even years. Our goal is to make NTP ubiquitous by providing a free simple implementation that is secure and easy to configure.

  • Be as secure as possible. Code carefully, do strict validity checks especially in the network input path, and use bounded buffer operations. Use privilege separation to mitigate the effects of possible security bugs.
  • Provide a lean implementation, sufficient for a majority. Don't try to support each and every obscure usage case, but cover the typical ones.
  • Try to "Just Work" in the background.
  • Work with just a minimum of configuration.
  • Reach a reasonable accuracy. We are not after the last microseconds.
Dan Carley
  • 25,189
  • 5
  • 52
  • 70