Best practices for NTP

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux (RHEL)
    • 6
    • 7
    • 8
    • 9
  • ntp
  • chrony

Issue

  • Best practices for NTP (Network Time Protocol)
  • How many time sources should be used for NTP?
  • How many NTP servers should be configured?
  • What is the recommended number of NTP servers?

Resolution

There is no pre-defined solution for this question available as every industry and each customer does have different requirements.

There are many variations to setup a service accordingly to the environment, such as:

  • hardware specifications,
  • the amount of users on this server,
  • amount of load (memory-specific; processor-specific),
  • applications using service,
  • organization policies (security related, administration related), etc.

We don't have a best practice manual in just one document. Each environment can have a combination of documents in order to setup an NTP server/client such as man pages, Knowledge Base, or official Red Hat documentation.

Following are some documentation links for the configuration of ntpd/chronyd service:

General recommendations

Using Enough Time Sources

   An NTP implementation that is compliant with [RFC5905] takes the
   available sources of time and submits this timing data to
   sophisticated intersection, clustering, and combining algorithms to
   get the best estimate of the correct time.  The description of these
   algorithms is beyond the scope of this document.  Interested readers
   should read [RFC5905] or the detailed description of NTP in
   [MILLS2006].

   o  If there is only one source of time, the answer is obvious.  It
      may not be a good source of time, but it's the only source that
      can be considered.  Any issue with the time at the source will be
      passed on to the client.

   o  If there are two sources of time and they align well enough, then
      the best time can be calculated easily.  But if one source fails,
      then the solution degrades to the single-source solution outlined
      above.  And if the two sources don't agree, it will be difficult
      to know which one is correct without making use of information
      from outside of the protocol.

   o  If there are three sources of time, there is more data available
      to converge on the best calculated time, and this time is more
      likely to be accurate.  And the loss of one of the sources (by
      becoming unreachable or unusable) can be tolerated.  But at that
      point, the solution degrades to the two-source solution.

   o  Having four or more sources of time is better as long as the
      sources are diverse (Section 3.3).  If one of these sources
      develops a problem, there are still at least three other time
      sources.

   This analysis assumes that a majority of the servers used in the
   solution are honest, even if some may be inaccurate.  Operators
   should be aware of the possibility that if an attacker is in control
   of the network, the time coming from all servers could be
   compromised.

   Operators who are concerned with maintaining accurate time SHOULD use
   at least four independent, diverse sources of time.  Four sources
   will provide sufficient backup in case one source goes down.  If four
   sources are not available, operators MAY use fewer sources, which is
   subject to the risks outlined above.

   Operators are advised to monitor all time sources that are in use.
   If time sources do not generally align, operators are encouraged to
   investigate the cause and either correct the problems or stop using
   defective servers.

server 0.rhel.pool.ntp.org iburst
server 1.rhel.pool.ntp.org iburst
server 2.rhel.pool.ntp.org iburst
server 3.rhel.pool.ntp.org iburst

The NTP Pool Project is a group of volunteers who have donated their computing and bandwidth resources to freely distribute time from primary time sources to others on the Internet.

If there is a need to synchronize many computers, an operator may want to run local NTP servers that are synchronized to the NTP Pool Project. NTP users on that operator's networks can then be synchronized to local NTP servers.

NTP server was not designed to run inside of a virtual machine. It requires a high resolution system clock, with response times to clock interrupts that are serviced with a high level of accuracy. 
NTP client is ok to run in some virtualization solutions.

   When using servers with attached hardware reference clocks, it is
   suggested that different types of reference clocks be used.  Having a
   diversity of sources with independent implementations means that any
   one issue is less likely to cause a service interruption.

   Are all clocks on a network from the same vendor?  They may have the
   same bugs.  Even devices from different vendors may not be truly
   independent if they share common elements.  Are they using the same
   base chipset?  Are they all running the same version of firmware?
   Chipset and firmware bugs can happen, but they can be more difficult
   to diagnose than application software bugs.  When having the correct
   time is of critical importance, it's ultimately up to operators to
   ensure that their sources are sufficiently independent, even if they
   are not under the operator's control.

   Operators SHOULD use their NTP implementation's remote monitoring
   capabilities to quickly identify servers that are out of sync and
   ensure correct functioning of the service.  Operators SHOULD also
   monitor system logs for messages so that problems and abuse attempts
   can be quickly identified.

   If a system starts to receive NTP Reply packets from a remote time
   server that do not correspond to any requests sent by the system,
   that can be an indication that an attacker is forging that system's
   IP address in requests to the remote time server.  The goal of this
   attack is to adversely impact the availability of time to the
   targeted system whose address is being forged.  Based on these forged
   packets, the remote time server might decide to throttle or rate-
   limit packets or even stop sending packets to the targeted system.

   If a server's system log shows messages that indicate it is receiving
   NTP timestamps that are much earlier than the current system time,
   then either the system clock is unusually fast or somebody is trying
   to launch a replay attack against that server.
  • Reference: RFC 8633 Network Time Protocol Best Current Practices

Disclaimer: Links contained herein to external website(s) are provided for convenience only. Red Hat has not reviewed the links and is not responsible for the content or its availability. The inclusion of any link to an external website does not imply endorsement by Red Hat of the website or their entities, products or services. You agree that Red Hat is not responsible or liable for any loss or expenses that may result due to your use of (or reliance on) the external site or content.

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.