Keeping your computer's clock set correctly is important; otherwise, a number of bad things can happen. For example, on a server, the logs can become inaccurate and confusing (and therefore insecure and ineffective). Also, when all files on your server or your desktop are modified or accessed, the time is noted. For day-to-day tasks, this timekeeping is moderately important, but for security it can be key, as you might imagine, if an attacker changes files on a system.

Networking can become disorganized, too. You may find with older implementations of secure web pages (SSL, Secure Sockets Layer) that the time on your desktop machine must have the correct time for the connections to work as expected.

Moreover, many anti-spam email systems treat time-warped email sent from the future as unwanted spam by default. Some systems instantly and silently refuse to process the offending email in any way, shape, or form. Finally do not forget that scheduled tasks (e.g., downloading new packages) also get messed up if your system clock is skewed.

In this article, I show you a lightweight alternative to the long-residing champion of time synchronization ntpd, the network time protocol daemon. The excellent ntpd has been found on many a Unix-like operating system (OS) for decades. Another kid on the block, however, is called chrony [1], which has been around since dial-up modems were singing high-pitched cacophonies all over the planet. Rest assured, then, that it's a time-tested and trusted piece of software. I'll run through the basics of its installation and operation and how to secure it for servers and desktops alike.

What Time Is It?

The chrony package installed on my Debian derivative Ubuntu/Mint box offers the following additional packages: libtomcrypt0, libtommath0, and timelimit. Thankfully, they take up barely any disk space because the clever chrony is so lightweight and performant. At installation, the timely chrony managed to configure itself at lightning speed and then synchronize automatically with four remote time servers.

Two main binaries compose the chrony package: The daemon chronyd, which sits quietly running in the background, and chronyc (Listing 1), which is a command-line interface (CLI) program for adjusting an already running chronyd.

$ chronyc sources
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- time.shf.uk.as44574.net       3   6    17    32  +5747us[+5747us] +/-  113ms
^* ntp3.wirehive.net             2   6    17    32    +33ms[  +17ms] +/-   92ms
^- www.bhay.org                  2   6    17    31    +11ms[  +11ms] +/-   38ms
^- h37-220-20-12.host.redsta     2   6    17    31  +1181us[+1181us] +/-   72ms

If you've used ntpd before, the output looks familiar and is relatively easy to understand: The network is connecting to four clocks and tells where in the pecking order (Stratum) they are for accuracy, with the times presented relative to your network time. In super-simple terms, the higher the stratum the more accurate the clock. A stratum 1 server, for example, might be connected to a reference clock or some other type of atomic clock or similarly reliable device. You will not see a stratum 0 device connected to a network by design, because such a reference clock would need a time server to do its networking for it.

Just typing chronyc without arguments will offer you a familiar CLI prompt, from which you can type a number of native chrony commands (or you can enter them directly after the command, which I'll touch on in a moment). Table 1 shows the CLI commands available, as listed by chronyc help. As you can see, chrony is highly configurable.

You can run your commands of choice directly on the CLI or within the chrony shell. This flexibility could help with scripting. The tracking command, for example, offers a very useful summary of chrony's status (Figure 1) and can be achieved with either

$ chronyc tracking

or

$ chronyc
chronyc> tracking

Figure 1: The chrony tracking command offers a useful summary.

Next, I'll look at the config file that runs the super-slick chrony.

You're Late

The main file to read is located (on my Debian derivative) at /etc/chrony/chrony.conf. In the chrony directory, you'll also find the keys file if you want to change authentication options. A number of useful comments can help when you're unsure about an option in the main file. In a moment, I'll look at three areas you might want to consider altering.

Additionally, first have a look at the excellent logging found, unsurprisingly, under /var/log/chrony. In that directory, you'll find the statistics.log, measurements.log, and tracking.log files. As you'd expect, the considerate chrony drops a logrotate profile in place to keep your system sane and juggles your logs automatically once a week by default. I'd recommend having a rummage in those three logfiles if you're tuning your time server sources. More on that in a moment.

Even a Stopped Clock …

At least two or three worthwhile changes can help you take full advantage of the trimmed-down ntpd model offered by chrony to help limit your attack surface. I'd recommend exploring these yourselves, because differing versions of chrony might do things slightly differently. For example, I think some defaults were changed in version 2.0.

Although chrony is a feature-filled time server, it's safe to say that not all the features will be required in most cases. As I alluded to at installation time, it was up and running in a few seconds.

You might simply want to keep your local clock synced, rather than allowing other machines to ask your machine the time. The venerable chrony allows you to bind to your localhost (127.0.0.1) with the bindcmdaddress option, which you can add to the config file mentioned above. Of course, you'll need to bounce your chronyd daemon after making a change (most likely with the systemctl restart chrony command).

Adding the following option to your config file will ensure that the wider network to which your system is connected can't connect to chronyc:

bindcmdaddress 127.0.0.1

If you're using IPv6, make sure this option follows the above IPv4 option:

bindcmdaddress ::1

The well-written FAQ [2] provides much more information.

To disable all NTP client or peer connections completely, add

port 0

to the config file. This option stops requests ever even making it to the chrony daemon.

You can also consider this similar-looking option,

cmdport 0

with which you can switch off all access to chronyc (the CLI binary), outside of the local chrony user (which it runs under) and the machine's root user.