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.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

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.

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:

1. Remove, or comment out, the vendor supplied restrict lines from your ntp.conf
2. 6.5.1.1. Choose the right default restriction
3. 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?

• If the answer is "No", skip to 6.5.1.1.2. Blocking Unauthorized Access

• If the answer is "Yes" you may not need any restrictions, skip to 6.5.1.1.4. Local Network Threat Level.

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?

• If the answer is "No", skip to 6.5.1.1.3. Allow Queries?

• If the answer is "Yes" use the following default restriction (and keep in mind that you will have to add restrict lines for every authorized server and client host/subnet as described in 6.5.1.2.1. If you used 'restrict default ignore'):

         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.