NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p11 was released on 27 February 2018. It addresses 2 low-/medium-, 1 informational-/medium-, and 2 low-severity security issues in ntpd, 1 medium-severity security issue in ntpq, and provides over 65 non-security bugfixes and other improvements over 4.2.8p10.

Please see the NTP Security Notice for vulnerability and mitigation details.

---

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

4. Installing NTP

NTP may be installed from the original source code, released by the NTP Project (which was originally from the University of Delaware starting in the 1980s, and was moved to Network Time Foundation in 2011) , or through pre-packaged or pre-compiled versions which may be available from your Operating System vendor/aggregator/distributor.

The instructions shown below for specific operating systems are presented as a courtesy and may not be up to date. These instructions presume that you have properly configured that operating systems package management infrastructure. Users are advised to consult their their operating system documentation for current installation instructions.

4.1. The NTP Project Reference Implementation Distribution

Users attempting to install NTP from source code should have some experience compiling software on UNIX or a Unix-like operating system.

The following software is used when installing NTP source code:

• A C compiler
• make (note that on some platforms, building outside of the main source directory requires GNU make.)
• tar
• gunzip
• libcap (note: needed for linux only if you wish to enable linux capabilities to drop root privileges and chroot ntpd)

4.1.1. Installing an ntp.org software release, and Getting Support

1. Download and unpack a tarball from SoftwareDownloads or The NTP Project Download Page
2. Read and follow the directions in the INSTALL file
3. See ConfiguringNTP for information about how to configure NTP
4. Add the init scripts, etc., to make NTP start at boot time

If you have any questions or problems installing NTP, the following resources are available:

• Community (free) support options:
  • There is a lot of support information available right here, in this wiki. There is a "Search" box on the top right-hand-side of the window.
  • Send an email to questions@lists.ntp.org
  • Ask on irc://irc.freenode.net/#ntp
  • Report a bug at https://bugs.ntp.org
• Support is available thru Network Time Foundation:
  • Via institutional membership
  • Support contracts - please send an email to info@nwtime.org

4.2. Debian GNU/Linux

4.2.1. NTP Pool Client

1. apt-get install ntp

4.2.2. Custom Configuration

1. apt-get install ntp
2. Edit /etc/ntp.conf (see ConfiguringNTP)
3. Create any required symlinks for your ref-clock if you are using one
4. Restart ntpd with /etc/init.d/ntp-server restart

4.3. FreeBSD

1. cd /usr/ports/net/ntp
2. make install clean
3. Edit /etc/ntp.conf (see ConfiguringNTP)
4. Edit /etc/rc.conf
5. Create any required symlinks for your ref-clock (if you are using one)
6. Start ntpd with /etc/rc.d/ntpd start

4.4. NetBSD

1. ...

4.5. OpenBSD

1. ...

4.6. Microsoft Windows

1. Instructions for installing on Windows
2. Read the next sections about PPS signals on Windows

4.6.1. Using PPS Signals On Windows

4.6.1.1. The Original PPS Support Using A Special Kernel Driver

A couple of years ago Dave Hart made the serialpps.sys driver available, which was based on a copy of the serial port example driver shipped with the Windows SDK, and extended to support the standard PPS API which is also available on many Unix-like systems. In addition there was a serialpps-ppsapi-provider.dll which could be used to let ntpd fetch PPS timestamps from the kernel driver:

• https://groups.google.com/forum/#!topic/comp.protocols.time.ntp/gkhvhF0oJhE

At least the 64 bit Windows versions which were released thereafter (Vista?) required that kernel drivers need to be signed to be loaded automatically at boot time. So Meinberg picked up Dave Hart's code, signed the kernel drivers with their key, and put the resulting binaries here:

• http://people.ntp.org/burnicki/windows/serialpps-20120321-signed.zip

so folks who want to play with it can do it. This sys/dll package was never included in the installer/setup program. The .zip file contains an install.bat script which copies the .sys file to its final location and prints some hints, but it doesn't copy the associated DLL to some predefined directory, so this was probably the original reason why the DLL path has to be specified via an environment variable, or with ntpd 4.2.8p10 or later using a registry key.

Many more hints on using this driver can be found on David J. Taylor's web page

These days PCs and laptops often don't provide a real serial port with a physical UART chip, so eventually this approach can't be used on these machines.

4.6.1.2. The PPS Hack

To work around the problem that there is no physical UART chip there has been something in ntpd that was known (alas, not widely known) as the PPS hack: Since ntpd anyway had to monitor the serial line for what WIndows calls COMM events, it also checked for level changes of the DCD line and used the time stamp of this change to supplant the receive time stamp for the next line of text. (E.g. the next NMEA record.) This works in user mode and needs no special driver, and it works for every serial interface known to Windows, but it gives reliable results only under tight constraints. (Having more than one NMEA record in the output cycle and selecting not the first after the PPS pulse completely defeats this!)

Whether the PPS Hack is to be used, or not, could be configured via an environment variable.

4.6.1.3. The PPS API Loopback Provider

The loopback-ppsapi-provider.dll came into existence as a means to get around the limitations of serialpps.sys without requiring a kernel mode driver. A kernel mode driver can (but not necessarily will) provide time stamps with less jitter than any user mode application, but loopback-ppsapi-provider.dll seems to do a very decent job here. In case you wonder about the name: This provider loops back into ntpd to tap into information already there.

This DLL is part of current versions of the normal NTP source code distribution.

4.6.2. Configuring PPS Support

PPS support configuration under Windows means specifying the PPS API provider DLL(s) to be used.

4.6.2.1. Specifying The PPS Provider Via A Registry Key

The original approach was to set up some environment variables to configure the way the PPS slopes were to be handled. However, specifying a DLL name in an evironment variable was found to be a potential security risk (see Bug #3384), so with ntpd 4.2.8p10 and later the path to the PPS provider DLL to be used should preferably be specified in the Windows registry.

When the instsrv.exe utility is used to install the NTP service then a registry key with loopback_pps_api_provider.dll is created automatically.

To set up the key manually, run the Windows regedit.exe utility, and open this registry path:

HkeyLocalMachine\SYSTEM\CurrentControlSet\services\NTP

Then create a new key as multipart string, with the name PPSProviders, and set the contents to loopback_pps_api_provider.dll or whichever PPS API provider you prefer.

4.6.2.2. Specifying The PPS Provider Via Environment Variables

This original approach can be insecure, so if ntpd 4.2.8p10 or newer is installed then preferably a registry key should be set up instead to specify the PPS API provider(s) to be used. See also the notes below.

There are two environment variables involved, and since ntpd is meant to be run as Windows service, these must be SYSTEM environment variables:

• PPSAPI_DLLS is a ';'-separated list of file names that should be tried in sequence to provide a PPS API for a device. For maximum interoperability between different versions of Windows the files should be given with absolute path, using standard Windows conventions (that is, use '\' as path separator).

• PPSAPI_HACK should be a boolean value (Yes/No/True/False/0/1) or be left unset, and controls the the PPS-hack operation.

When it comes to controlling the PPS hack, there is some dependency between those two settings. The decision is based on the principle of least surprise:

• If neither PPSAPI_DLLS nor PPSAPI_HACK is set in the environment, the PPS hack works as it has always done.

• If only PPSAPI_DLLS is set (and not empty) it disables the PPS hack, assuming that a better way of handling PPS signals is provided. (The interaction between the PPS API and the PPS hack is somewhat tricky. It's better to avoid this area where dragons are roaming unless you feel really adventurous.)

• The environment variable PPSAPI_HACK takes precedence over PPSAPI_DLLS : if it is set to Y[es], T[rue] or 1 it enables the PPS hack independently of any setting of PPSAPI_DLLS; any other value disables the PPS hack unconditionally.

So the cleanest setting that does not require kernel mode support is to have the following in your system environment:

PPSAPI_DLLS=C:\your\path\to\loopback-ppsapi-provider.dll
PPSAPI_HACK=No

Notes:

• In ntpd 4.2.8p10 and newer the environment variables are only checked for compatibility reasons, if no registry key can be found.

• If the DLL name is specified as file name only, without a path, then the DLL is assumed in the same directory as ntpd.exe.

• If the Meinberg installer is used then the loopback-ppsapi-provider.dll is installed in the NTP/bin directory where also ntpd.exe and the openSSL DLL normally reside.

• Please note there is a bug in ntpd 4.2.8p10 where the DLL name retrieved from the environment variable is not properly terminated, so garbage characters may be appended to the DLL name, and thus the DLL file may not be found. See Bug #3402 for details and a workaround.