Harden against what? An external adversary (ie one who ccan capture one or two external servers an internal one, who could change that that internal file? The lattr is of course much harder to protect against. Note that chrony already can use internal files to set the intial times of chrony as I recall (for example looking at the timstamps of its log files) Note that an internal enemy could alter those. Note also that I would not call guarding against a many many month or year problem. Why would an adversary do that? Externally, it would seem that using many independent servers would be the best defence (which chrony and nptd alredy allow. Of course many do not make sure that the servers are independent-- eg, all depend on one single root server).
William G. Unruh __|__Hagler Fellow, Distinguished |_Tel:UBC +1(604)822-3273 Physics&Astronomy _|__ Research Prof, IQSE |__ US +1(979)7399950 UBC, Vancouver,BC _|_ TAMU4242, 578 University Dr |_ [email protected] Canada V6T 1Z1 ____|__College Stn, Tx, USA 77843 _|_www.theory.physics.ubc.ca I cannot reply to emails from outlook or hotmail or other microsoft domains. ---------- Forwarded message ---------- Date: Wed, 4 Feb 2026 08:25:26 From: Holger Hoffstätte <[email protected]> To: Bernd Brandstetter <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [chrony-users] Chrony and NTP hardening [CAUTION: Non-UBC Email] On 2026-02-04 16:57, Bernd Brandstetter wrote:
Hello, I'm supposed to implement a couple of NTP security requirements as suggested by RFC8633. Specifically, the NTP daemon shall be prevented from accepting dates that set the clock to a time earlier than the build date of the system or a last-known-good time, which will be saved to a file once a day. I'm wondering how this could best be achieved with Chrony. My main problem is that I can see no way to reliably detect if the time is acceptable before Chrony has already synchronized. Moreover, since we would also like to use rtcsync, this would mean that then also the RTC could be set to the wrong time and we'd therefore have no means to recover, and activating rtcsync only afterwards is unfortunately not supported.
It's not clear to me whether you want to do this only at startup or continously at runtime. For the former you will have to write your own pre-start script where you can check for "the current offset" without setting the clock with: chronyd -x -Q 2>&1 | grep "System clock" | cut -d ' ' -f 6 which will give you something like: -0.000211 You can then compare this with the checkpoint time and do whatever is necessary. Does that help? cheers Holger -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
