How can I protect against time attacks when using NTP in an infrastructure?

@damien commenge  That can work for the hardened repository. Local generate time can be off a few secs to minutes but wouldnt break or expose security there. One question I do have though: does your customer have no compliance needs around time? For example: 

• Compliance: Many regulations and standards, such as the Payment Card Industry Data Security Standard (PCI DSS), require accurate time synchronization for compliance. Organizations that fail to comply with these regulations may face penalties and damage to their reputation.

Hi @Viperian, other than that, I’ll add:

• Configure to ignore panic threshold when a large time shift lead to reboot a NTP server
  https://www.bodet-time.com/time-servers/articles-and-resources/1755-maintaining-network-security-when-using-ntp-time-synchronization.html#:~:text=If%20an%20incoming,often%20occurs%20next.
• Authentication + Encryption 
  https://www.ntp.org/ntpfaq/NTP-s-algo-crypt.htm

That’s all. But the most important thing is the ACL list :)

Hello @Viperian, I think you have covered this topic above and beyond and did not restrict your solution to a specific technology. Here I would like to discuss some scenarios :-)

• Point 4 mitigates against attacks relating to NTP vulnerabilities (weakness). 

This scenario also prevent “Replay attack” which you have mentioned above. In my case, I will be a bit specific to an Active Directory Environment and this is also applicable to network appliances as time is one of the important settings in a domain.

Since it is vital for all clocks to be within 5 minutes by default due to the implementation of the Kerberos protocol for authentication. For time stamps to work properly, the clocks of the client and the Domain Controller need to be in sync as much as possible!

By default, Network Time Protocol (NTP) is the time synchronisation protocol used by the Windows Time Service (WTS) in Windows. All Domain Controllers (DC) should get their time from the DC holding the PDC Emulator FSMO role (time master), and this time should be accurate as possible. To maintain the accuracy, the root domain PDC emulator must be configured to synchronise its time with an external time source which is reliable

• Therefore, all DC member server/workstations MUST synchronise time from their respective DCs as the correct time is needed from Kerberos authentication as mentioned in “Point 1” above to prevent a replay attack.

Recommendation! This behavior does not need to be reconfigured. However, if you want to ensure that the default behavior would not be overridden by someone on the client side, you can force a Group Policy to push the configuration.

Here are some Time Service Policy that should be adhered to in a domain environment

• Disable Virtual Machine Time Sync from host (If enabled, guest machines will draw time from the physical host they are running on): https://kb.vmware.com/s/article/1189#:~:text=To%20disable%20periodic%20time%20synchronization,the%20checkbox%20Synchronize%20time%20periodically.
• DHCP scope option should be used to push NTP server settings to a non-windows device
• For devices that do not support NTP server, they must be statically. 
• Since NTP can be used to manipulate logs by altering sequence of events, Point 2 should be strictly adhered to.
• Lastly, poor NTP configuration should be avoided by all means. Recent DDOS attack on NTP was not as a result of security weakness (vulnerability), but due to some poor configuration.

This is not a comprehensive piece as it does not discuss all points, but does cover some vitals points.