​Network experts already know that distributing the correct time is key to maintaining their critical infrastructure programs. However, keeping accurate time is also fundamental to many cybersecurity applications. Certificates have an expiration date attached to them, and system logs frequently contain time stamps that operators rely on for diagnosing issues.

​Over the last few years, there has been significant research into ways that the NTP protocol (specified in RFC 5905) can be secured from malicious attackers. Attackers can target an NTP server and, after gaining access, alter the time that is being served. But attackers who have access to a network can also monitor NTP traffic, find out the credentials (such as IP address) of a good server and attempt to mislead NTP clients by forging packets from that server with bad time values.

​These common spoofing attacks can result in inaccurate time. And if you use time sources from outside your organization that rely on networks that are not under your control – such as internet time – it's even more important to ensure that you have accurate, consistent time on your server. Although there are steps that your ISP can take to prevent this type of spoofing, it is always better to take preventive actions wherever you can.

​The Internet Engineering Task Force (IETF) has released RFC 8633, "Network Time Protocol Best Current Practices", that includes several new security best practices. Among other things, it includes a discussion of how to mitigate against these types of cyberattacks. A few of these Best Practices are summarized here:

1. ​Use Multiple NTP Servers - The easiest thing for a network operator to do is simply configure their clients to use multiple NTP servers on the network.

This NTP configuration can process multiple time sources at the same time and discard one if it disagrees with the rest. This makes an attacker's job harder, because they will need to attack the NTP traffic from a majority of the servers to impact the NTP clients.

2. Monitor Servers From The Client's Perspective - Another Best Practice is to have NTP client nodes devoted to monitoring the health of the NTP servers on the network. Monitoring an NTP server directly is important, but it will only tell you if there is a problem with that particular server. If you monitor it from the client side, you can look at the time transfer process from the client's perspective and see whether there is anything suspicious happening after the packets leave the server.

3. Use NTP Encryption Options - The NTP peering packets (as well as the mode 6 "ntpq"-style queries) contain sensitive information that can be used in an attack. When using these services, operators are advised to either use NTP encryption options (such as symmetric keys) or use other means (such as access control lists) to control who can access these NTP queries. This will prevent this information from leaking out to unauthorized parties who could use them in a cyberattack.

4. Monitor Restarts - NTP clients do a good job at detecting and ignoring packets that indicate a large time shift. RFC 5905 calls this a panic threshold, which is set by default to 1000 s. However, the RFC also states that the NTP client should quit when it sees a large time shift like this.

The problem with this is that most modern operating systems will restart a vital service like NTP when it quits after a significant time shift. When the NTP daemon restarts, it may be configured to ignore this threshold. This means that an attacker who takes over an active NTP server might force clients to move to the wrong time simply by sending the wrong time consistently enough that clients will restart the system.

​Some steps that can be taken to mitigate this:

• Actively monitor system logs. Several NTP clients restarting at the same time may be an indication that a server is not being honest.
• Configure your NTP clients to ignore the panic threshold on restart. This may result in those clients not using the NTP service at all in the event of an attack, but at least they won't use the wrong time.
• If you're already using multiple NTP servers, increase the minimum number of servers required before the NTP clients adjust the clocks.
• These practices can be used by all NTP users in order to mitigate attacks on the service and ensure that their networks always have the correct time.

Thank you to Denis Reilly, of Orolia, for the article.