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.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
See ConfiguringNTPDev for discussion of this topic.
6. Configuring NTP
6.10. Simple Client Configuration
6.10.1. 4.2.7 and Later Simple Client Configuration, Visible on the Internet
This is the minimum configuration for an
NTP Client running 4.2.7 or later which just needs "good enough" time.
# NTP 4.2.7 or later, visible to the Internet
restrict default -4 nomodify nopeer noquery notrap
restrict default -6 nomodify nopeer noquery notrap # if your machine has IPv6 connectivity
restrict source nomodify noquery notrap # Don't use nopeer with pool servers
restrict 224.0.1.1 mask 255.255.255.255 nomodify # if you are using multicast (most folks are not)
restrict 127.0.0.1
restrict ::1
restrict 192.168.0.0 mask 255.255.255.0 # Use your network address and mask
driftfile /var/db/ntp/ntp.drift
pool 0.pool.ntp.org iburst
- This configuration uses the Global NTP Pool. Please visit the NTP Pool web-site to learn about the Pool Zones which may be used to choose servers in your geographical area
- The drift file must in a directory writable by the ntp user
6.10.2. 4.2.6 and Later Simple Client Configuration, Visible on the Internet
This is the minimum configuration for an
NTP Client running 4.2.6 which just needs "good enough" time.
# NTP 4.2.6, visible to the Internet
restrict default -4 nomodify nopeer noquery notrap
restrict default -6 nomodify nopeer noquery notrap # if your machine has IPv6 connectivity
restrict 224.0.1.1 mask 255.255.255.255 nomodify # if you are using multicast (most folks are not)
restrict 127.0.0.1
restrict ::1
restrict 192.168.0.0 mask 255.255.255.0 # Use your network address and mask
driftfile /var/db/ntp/ntp.drift
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
- This configuration uses the Global NTP Pool. Please visit the NTP Pool web-site to learn about the Pool Zones which may be used to choose servers in your geographical area
- The drift file must in a directory writable by the ntp user
6.11. Important Notes
First,
ntpd needs a majority of servers to agree on the time before it can sync. If you only have one server, that server WILL be believed. If you have two or three servers and they disagree, no majority will be found.
If you are going to have
server or
peer lines in
ntp.conf I recommend having at least four or five of them, and use
iburst for each. See
SelectingOffsiteNTPServers for more.
Be
very careful with
burst as it is only rarely needed and will significantly increase the traffic. Do not use
burst unless you have a very good reason for doing so. (I'd like to have a URL to the pages that describe the rare cases where
burst is appropriate.)
6.12. DHCP Auto-configuration
6.12.1. ISC dhcp 3
ISC's dhcp is able to automatically configure the servers used by
ntpd. Here's how to get it working:
- The dhcp server you are using must be configured to provide the
ntp-servers option
- Configure your
dhclient to request ntp-servers (it doesn't by default). To do this add ntp-servers to the default request line in /etc/dhcp3/dhclient.conf
- Create an
/etc/ntp.conf with all of the other settings that you wish to use. This file will be used to create /etc/ntp.conf.dhcp, it won't be over written.
- Your
ntpd must be told to use /etc/ntp.conf.dhcp if it exists. This is usually accomplished in the ntp init script (e.g. /etc/init.d/ntp).
6.13. How dynamic IP addresses affect ntpd
Currently,
ntpd does not rescan the network interfaces after it has started. If you are have a dynamic IP (use DHCP), this means
ntpd will no longer be able to communicate with "outside" sources after your IP changes.
The script in
Bug #51 will not help you unless it's the remote site's IP address that has changed.
6.14. Using the NIST Leap Second File
The U.S.
National Institute of Standards and Technology (NIST) is publishing a file which contains a table of past and upcoming leap seconds. This file can be used by
ntpd to become aware of leap second announcements and thus be able to handle leap seconds gracefully.
Graceful handling of leap seconds implies applying the leap second locally at the appropriate time, rather than having the clock off by one second until the discrepancy witih sources is noticed and corrected at a later time. ntpd will gracefully handle leap seconds which it knows about in advance, via one of two means. If a leap second file is configured in ntp.conf or acquired via autokey, ntpd will inform clients of the pending leap for one day in advance via the leap field of the NTP packet, and it will be applied locally. Lacking a leapfile, ntpd is at the mercy of its sources to inform it of the pending leap second.
In the case of network sources, this means ntpd is at the mercy of the Stratum 1 sources at the top of its synchronization chain either having a current leapfile installed, or using a reference clock driver which provides advance notice of pending leap seconds. While some reference clocks do provide this information, many do not. For example, GPS provides notification to receivers of pending leap second insertions. That does not imply all stratum 1 servers using GPS will receive that notification. The popular NMEA reference clock driver does not, as the NMEA sentences its decodes do not carry advance notification of leap seconds.
Past experience has shown many stratum 1 servers do not advertise pending leap seconds during the day prior to the event. Installing a leapfile on your NTP server ensures it will notify its clients of the pending leap as well as handle the event gracefully. If you operate a stratum 1 server, your downstream clients are depending on your server to notify them, so it is best practice to download and configure the leapfile at least one day in advance of the scheduled insertion or deletion. The only exception is if you know all your reference clocks and their ntpd drivers will provide notification at least one day in advance.
The way to configure ntpd to use this file has changed with version 4.2.6 of ntpd.
The file is available available at
ftp://time.nist.gov/pub/ as well as
ftp://tycho.usno.navy.mil/pub/ntp/
The file name is:
leap-seconds.nnnnnnnnnn where
nnnnnnnnnn is a time the file was updated expressed as an NTP timestamp rounded to whole seconds, that is, the number of seconds since the start of the year 1900 (ignoring leap seconds).
As of this writing the name of the current leap second files are:
leap-seconds.3676924800 (NIST) or
leap-seconds.3676752000 (USNO):
As of early 2012, the USNO tycho FTP server is accessible to some clients which cannot access the NIST time FTP server, possibly related to an inferior NAT ALG for FTP and/or the server load balancer involved.
The file can also be obtained from
http://www.ietf.org/timezones/data/leap-seconds.list
6.14.1. NTP Versions 4.2.6 and newer
Copy the leap seconds file onto your system running ntpd and add a line to your ntp.conf:
leapfile "/path/to your/leap-file"
You need to restart ntpd to apply your configuration changes.
6.14.2. NTP Versions before 4.2.6
Pre-4.2.6 versions of
ntpd evaluates the leap second file only if the
autokey feature has been enabled. The
autokey feature also provides a mechanism to forward the information from the leap second file to clients which are using autokey authentication of the server, that is, clients which have the autokey keyword on the server directive in ntp.conf.
The leap second file must be copied to the
crypto directory configured for ntpd, and inside that directory a
link must be created which points to that file. The standard name for the link is
ntpkey_leap. However, this can be overridden by a configuration parameter.
So assuming the name of the leap second file as mentioned above, the standard link to the leap second file inside the NTP crypto directory should look like this:
ntpkey_leap -> leap-seconds.3676924800
You need to restart ntpd to apply your configuration changes.
6.15. NTP over cellular - a brief study
6.15.1. Background
A customer asked to study how good relative time sync can be achieved, when the connection is over cellular packet networks, which are characterised by long, variable, asymmetric delays. The delays are due to the state transitions between the cell states in 3G networks. They are discussed e.g. in
http://www.pasieronen.com/publications/haverinen_siren_eronen_vtc2007.pdf , from the mobile device power consumption point of view.
6.15.2. Environment
The units used for this test were Raspberry Pi (RPi). NTP package were from the Raspbian repository and version 1:4.2.6.p5+dfsg-2. Various USB 3G modems directly connected to the RPi were tested and they behaved in the same way - excluding longer term stability.
In other HW platforms the HW clock is likely more stable and does not drift as extensively as RPi does and thus, likely tolerates lower frequency NTP polling.
However, the optimal keep-alive period is depending on the cellular network and targeted accuracy. Here the target relative time sync accuracy was 10ms and it seems to be achievable most of the time.
6.15.3. Configuration
To achieve reasonable timing performance over 3G cellular network, there has to be enough traffic to keep the cellular radio on CELL_FACH as much as possible, but preferably avoiding unnecessarily transitions to CELL_DCH.
Generating periodic ping packets parallel to a traditional NTP daemon configuration was also tested, but it didn't provide any measurable benefit; NTP packets are small enough.
Since even with the ignored (noselect) keep alive packets there is quite a lot of jitter in the packet delays, the number of the servers, which the NTP daemon can utilise, has to be higher than in normal (from the NTP point of view much better) access networks.
# Keep the cellular modem on CELL_FACH with this, do NOT poll pool server with this frequency.
server server1.mydomain.com iburst minpoll 3 maxpoll 3 noselect
# obtain the time
server 0.xxx.pool.ntp.org iburst maxpoll 9
server 1.xxx.pool.ntp.org iburst maxpoll 9
server server2.mydomain.com iburst maxpoll 9 prefer
server 2.xxx.pool.ntp.org iburst maxpoll 9
server 3.xxx.pool.ntp.org iburst maxpoll 9
Replace xxx with a suitable pool.
6.15.4. Disclaimer
This sample configuration was published in the hope that it could be useful, butwithout any warranty of any kind.
The configuration has been tested just in one network (Sonera Finland) and only in one physical location. Other networks may behave in different way.
Setup own stratum 3 server to receive the keep-alive traffic. For wider usage it's a good idea to setup a pool of own NTP servers for this purpose. The cellular network causes
in any case much more jitter than using dedicated higher stratum servers instead of the public NTP pool.
The keep-alive generates quite a lot of traffic (several MBs weekly), so the cellular subscription fee should be flat rate i.e. paid for the speed, not for the data.
6.16. Third-party HOWTOs and guides
Support Web
png 
Copyright &© 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback