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.8p15
was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
See AccessRestrictionsDev for discussion of this topic.
6.5. ntpd access restrictions
Restrictions are used to control access to your
ntpd
and are, unfortunately, one of the most misunderstood parts of
ntpd
configuration.
You must use IP addresses on restrict statements.
6.5.1. Configuring your ntpd restrictions
Follow these steps to set up your restrictions:
- Remove, or comment out, the vendor supplied
restrict
lines from your ntp.conf
- 6.5.1.1. Choose the right default restriction
- 6.5.1.2. Add exceptions for specific hosts/subnets
6.5.1.1. Choose the right default restriction
The default restriction tells
ntpd
how to handle packets from hosts (including remote time servers) and subnets that do not otherwise have a specific restriction. Choosing the correct default restriction can simplify your
ntpd
configuration while providing the security you need.
Consider the following questions before you start:
6.5.1.1.1. NAT or Firewall?
Are incoming connections to your ntpd blocked by NAT or a stateful inspection firewall?
6.5.1.1.2. Blocking Unauthorized Access
If your ntpd is publicly accessible do you really need to block all connections, including time polls, from unauthorized hosts?
IPV4: restrict default ignore
IPv6: restrict -6 default ignore

Skip to
6.5.1.2. Add exceptions for specific hosts/subnets if you selected a default restriction in this section.
6.5.1.1.3. Allow Queries?
Users of NTP versions prior to 4.2.7p26 should either use noquery
or disable monitor
to ensure their ntpd is not used in a DRDoS Amplification Attack
Since you are willing to allow others to get the time from your ntpd, will you allow them to see your server status information (even though this can reveal information about your OS and ntpd version)?
- If the answer is "No" use the following default restriction:
IPV4: restrict default limited kod nomodify notrap nopeer noquery
IPv6: restrict -6 default limited kod nomodify notrap nopeer noquery
- If the answer is "Yes" use the following default restriction:
IPV4: restrict default limited kod nomodify notrap nopeer
IPv6: restrict -6 default limited kod nomodify notrap nopeer

Skip to
6.5.1.2. Add exceptions for specific hosts/subnets if you selected a default restriction in this section.
6.5.1.1.4. Local Network Threat Level
How much protection do you need from clients on your internal network?
- If you feel that you need more than the built-in authentication (for on-the-fly reconfiguration) to protect your ntpd from the hosts on your LAN you may wish to consider the following default restrictions:
IPV4: restrict default limited kod nomodify notrap nopeer
IPv6: restrict -6 default limited kod nomodify notrap nopeer
6.5.1.2. Add exceptions for specific hosts/subnets
Once you have set your default restriction you may need to add exceptions, in the form of additional restriction lines, to allow your remote time servers and client hosts/subnets to contact your
ntpd
.
6.5.1.2.1. If you used 'restrict default ignore'
Add the following line to allow unrestricted access from the localhost (so that you may monitor
ntpd
and perform on-the-fly configuration changes with
ntpdc
):
IPv4: restrict 127.0.0.1
IPv6: restrict -6 ::1
Repeat the following two lines for each remote time server:
IPv4: server x.y.z.w
IPv4: restrict x.y.z.w [nomodify notrap nopeer noquery]
IPv6: server -6 v:u:t:s::
IPv6: restrict -6 v:u:t:s:: [nomodify notrap nopeer noquery]
You may use either a hostname or IP address on the server line. You
must use an IP address on the restrict line. There is no harm in adding the restrictions shown in brackets but keep in mind that if you are accepting time from someone it may be considered courteous to allow them to see a bit of information about their client.
Add the following line to allow unrestricted access by a specific host (e.g. the sysadmin's workstation):
IPv4: restrict 192.168.1.10
Add the following line to allow a subnet to receive time service and query server statistics:
IPv4: restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap nopeer
IPv6: restrict 2001:838:0:1:: mask ffff:ffff:ffff:ffff:: nomodify notrap nopeer
(the '-6' option leads to a syntax error. It is working without '-6' as shown above)
6.5.1.2.2. Other default restrictions
The other default restrictions presented in
6.5.1.1. Choose the right default restriction should allow enough access to your
ntpd
that you will not need to create any other
restrict
lines for specific hosts/subnets.
You may need to add the following line to allow unrestricted access from the localhost (so that you may monitor
ntpd
and perform on-the-fly configuration changes with
ntpdc
):
IPv4: restrict 127.0.0.1
IPv6: restrict -6 ::1
6.5.2. Access Control Options

Official documentation of the current implementation of the
restrict
statement in an
ntp.conf
file is on the
Access Control Options page.
There are numerous Access Control options which may be used on the restrict lines in your
ntp.conf
. Some of the more commonly used options are described in detail here.
- nomodify -- "Do not allow this host/subnet to modify the ntpd settings even if they have the correct keys." By default ntpd requires authentication with symmetric keys for modifications made with ntpdc. So if you don't configure symmetric keys for your ntpd, or keep them properly safeguarded, you don't need to use 'nomodify' unless you are concerned that the NTP authentication scheme might be compromised.
- noserve -- "Do not serve time to this host/subnet." This option is really intended to be used when you want to allow a host/subnet to access your ntpd only for monitoring and/or remote configuration.
- notrust -- "Ignore all NTP packets that are not cryptographically authenticated." This option tells ntpd to ignore all packets which are not crytographically authenticated (note that this is a change from ntp-4.1.x). DO NOT use "notrust" unless ntp crypto (i.e. symmetric keys or autokey) has been properly configured on "both ends" of an ntp association (e.g. your ntpd and a remote time server, your ntpd and a client). See 6.5.3.1.
notrust
changed between versions 4.1 and 4.2 for more information.
- noquery -- "Do not allow this host/subnet to query your
ntpd
status." The ntpd status query features provided by ntpq/ntpdc will reveal some information about the system running ntpd (e.g. OS version, ntpd version) that you many not wish others to know. You need to decide if concealing this information is more important than the possible benefits of allowing your clients to see synchronization information about your ntpd.
6.5.3. Important Notes
6.5.3.1. notrust
changed between versions 4.1 and 4.2
The behavior of
notrust
changed between versions 4.1 and 4.2.
- In 4.1 (and earlier)
notrust
meant "Don't trust this host/subnet for time".
- In 4.2 (and later)
notrust
means "Ignore all NTP packets that are not cryptographically authenticated." This forces remote time servers to authenticate themselves to your (client) ntpd
. See ConfiguringAutokey for information about configuring NTP Authentication.
6.5.3.2. Nessus identification and ntpd
Nessus (
http://www.nessus.org) may be able to identify a system based on information returned by status queries to
ntpd
. The use of
noquery
(
6.5.2. Access Control Options) can prevent this.
6.5.3.3. DRDoS / Amplification Attack using ntpdc monlist command in NTP < 4.2.7p26
Unrestricted access to the monlist feature in ntp_request.c in ntpd in NTP before 4.2.7p26 allows remote attackers to cause a denial of service (traffic amplification) via forged (1) REQ_MON_GETLIST or (2) REQ_MON_GETLIST_1 requests, as exploited in the wild in December 2013.
Please visit our
Security Notice for more information, links, and mitigation information.