Distributing accurate time is a vital part of sustaining network infrastructure. It’s also a critical element of network security, both when it comes to the expiry dates on certificates and timestamped system logs used for troubleshooting.
Malicious online activity has increased over the last few years, and since NTP (Network Time Protocol) can be specifically targeted, there has been much analysis into how to protected it from cyberattacks. A simple way for hackers to affect your NTP synchronization is to utilise spoofing. This involves finding a method of supplying your network with the incorrect time.
The most direct route for such a spoofing attack is to gain access to the NTP server itself, and then simply change the time being distributed. However, merely protecting your server isn’t enough. If they have network access, hackers will be able to monitor any NTP traffic. This allows them to glean credentials such as the NTP server’s IP address, and then forge data packets to try and dupe NTP clients into accepting the incorrect time.
Spoofing attacks can be even harder to protect against if you use an external source of time synchronization, such as an internet time server. Although you can take steps to both detect and secure against malicious activities on your own network, using NTP from another source means that you have no idea about its validity. Whilst an ISP might be able to take actions to prevent spoofing, there is no substitute for using local NTP servers and having your own stringent network security practices in place.
The following steps are some of the current best practice measures for maintaining network security when using NTP synchronization.
Multiple NTP Time Servers
NTP can be configured to utilise multiple time sources. If one source differs vastly from the others, that time source will be disregarded. Using multiple NTP time servers is a simple and effective way to increase network security, making it much more difficult for hackers to dupe NTP clients. Instead of just compromising one server or forging its data packets, they will now have to complete this process for the majority of servers to avoid their incorrect time being rejected.
NTP Encryption
Although an integral part of time synchronization, NTP data packets are a goldmine of sensitive information which, in the wrong hands, could be used to further breach your network. That’s why it’s vital for network administrators to prevent this data being accessed by unauthorised users. Recommended measures include using NTP encryption options such as symmetric keys. Protecting data packets in this way increases the likelihood that spoofing attacks will fail.
NTP Service Restarts
If an incoming NTP data packet indicates a large time shift, the client would usually assume something has gone wrong and reject it as part of the automated NTP synchronization process. The time shift necessary to trigger this process is referred to as the ‘panic threshold’. It is usually recommended that the NTP service should shut down if this happens, after noting the event in the system log. The real danger lies in what often occurs next.
When a vital service shuts down, the default behaviour of most operating systems is simply to restart it. However, many NTP services are configured to disregard the panic threshold following a restart. If those two things happen, it makes a spoofing attack almost guaranteed to succeed. All anyone wishing to spoof a client needs to do is continually send data packets to it with time information indicating a large time shift. The NTP service will shut down and be restarted by the OS. It will then accept the time supplied in that forged data packet because it now temporarily ignores the panic threshold.
There are several actions which can be taken to avoid this series of events including monitoring of System logs. This is where any event of an NTP service shutting down due to the panic threshold will be recorded, suggesting possible malicious activity.
The final provision reinforces the importance of using multiple NTP servers in maintaining network security. It involves increasing the number of servers an NTP client needs to receive data from before time is adjusted. Without the majority of data packets agreeing on the same time, a forged data packet won’t be considered a genuine source. In that instance, the process for updating time on the client will never begin, and the panic threshold will never be consulted.
By taking all these steps to ensure best practice, you can protect your network from NTP attacks and rely on all connected devices having the correct time.