NTP, PTP, NTS Chrony and NTPsec
Time synchronization is a critical aspect of system reliability. Understanding the right tools and protocols—like NTP, PTP, Chrony, and NTPsec—can significantly impact accuracy, security, and performance. Here is a recent play around I did in Linux.
Time Synchronization Matters For:
- Log Consistency: Accurate timestamps are essential in log analysis and triaging threat.
- Application Performance
- Security
By default most Linux host systems implements a lightweight version of NTP like systemd-timesyncd.
┌──(kali㉿kali)-[~]
└─$ systemctl list-unit-files | grep time
dbus-org.freedesktop.timedate1.service alias -
systemd-fsck-root.service enabled-runtime disabled
systemd-remount-fs.service enabled-runtime disabled
systemd-timedated.service static -
tor @ default.service enabled-runtime disabled
Installed NTPsec which all production environment should be using by now if not using chrony instead of the tradition NTPd with vulnerabilities.
Trying to implement NTS which is an authentication protocol for NTP. Commented out the pool serves in the configuration file and added two NTP complaint servers.
# Public NTP servers supporting Network Time Security:
server time.cloudflare.com iburst nts minpoll 4 maxpoll 6 prefer
server nts.netnod.se iburst nts minpoll 4 maxpoll 6
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool:
pool 0.debian.pool.ntp.org iburst
# pool 1.debian.pool.ntp.org iburst
# pool 2.debian.pool.ntp.org iburst
# pool 3.debian.pool.ntp.org iburst
Restarts the NTPsec service checked for connectivity but after about 30min none of the servers will be promoted even after weaking min max polls, frustrating a bit.
┌──(kali㉿kali)-[~]
└─$ ntpq -p
remote refid st t when poll reach delay offset jitter
=====================================================================================
+time.cloudflare.com 10.120.8.5 3 8 - 16 1 22.8112 -524.264 13.1607
+mmo2-ts.nts.netnod.se .PPS. 1 8 1 16 1 57.0464 -523.899 10.7168
Until after uncommenting one pool of servers, then the magic happened.
Confirmed NTS is working meaning server is authenticated and the preferred server is selected indicated by the asterisk sign.
┌──(kali㉿kali)-[~]
└─$ ntpq -p
remote refid st t when poll reach delay offset jitter
=======================================================================================================
time.cloudflare.com .NTS. 16 u - 16 0 0.0000 0.0000 0.0001
nts.netnod.se .NTS. 16 u - 16 0 0.0000 0.0000 0.0001
0.debian.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0001
└─$ ntpq -p
remote refid st t when poll reach delay offset jitter
=======================================================================================================
*time.cloudflare.com 10.21.8.14 3 8 8 16 1 21.0205 7.8437 44.4693
+gbg2-ts.nts.netnod.se .PPS. 1 8 5 16 3 52.5317 -3.9851 65.3577
0.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0001
slideaway.preshweb.co.uk .STEP. 16 u - 64 0 0.0000 0.0000 0.0001
+183.ip-51-89-151.eu 85.199.214.101 2 u 15 64 1 20.0521 36.2712 55.5101
ntp2.as200552.net .STEP. 16 u - 64 0 0.0000 0.0000 0.0001
2.125.2.81.in-addr.arpa .STEP. 16 u - 64 0 0.0000 0.0000 0.0001
Lessons:
- NTP is easy to implement and old so its susceptible to spoofing and not precise compared to PTP.
- NTPsec is a modernized secure implementation of NTP
- NTS provides encryption between a client and a server over NTP using TLS
- Chrony is the go to because its support PTP
- Best use case will be chrony with NTS
Finally: I thought of this. If PTP is that fast over NTP, in the world
of trading imaging an organization with PTP implementation and the
advantages it will have on one that doesn’t.
The financial market operates with lightening speed so I bet
a nanosecond could mean lose or win.
Note: NTS was published in RCF 8915 in October 2020 chances are not all organisation
have implemented it yet.
Time Synchronisation on Windows
Quick one I was looking at time sync on windows, my system was configured to synchronize with time. windows.com, but the time service (w32tm) reported it wasn’t synchronized and was relying on the local CMOS clock instead.
C:\Windows\System32> .\w32tm.exe /query /status
Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0000000s
Root Dispersion: 0.0000000s
ReferenceId: 0x00000000 (unspecified)
Last Successful Sync Time: unspecified
Source: Local CMOS Clock
Poll Interval: 10 (1024s)
Despite correct configuration
NtpClient (Local)
DllName: C:\WINDOWS\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
AllowNonstandardModeCombinations: 1 (Local)
ResolvePeerBackoffMinutes: 15 (Local)
ResolvePeerBackoffMaxTimes: 7 (Local)
CompatibilityFlags: 2147483648 (Local)
EventLogFlags: 1 (Local)
LargeSampleSkew: 3 (Local)
SpecialPollInterval: 32768 (Local)
Type: NTP (Local)
NtpServer: time.windows.com,0x9 (Local)
and network connectivity to the NTP server, the system wasn’t syncing.
PS C:\Windows\System32> w32tm /stripchart /computer:time.windows.com /dataonly
Tracking time.windows.com [51.145.123.29:123].
The current time is 24/11/2024 18:00:41.
18:00:41, +00.0132955s
18:00:43, +00.0132997s
18:00:45, +00.0136077s
18:00:47, +00.0133050s
After a quick search, it likely a “Time drift” which windows
by default does not correct large time difference automatically.
A quick: Forcing resync and restarting the w32time service worked.
PS C:\Windows\System32> w32tm /resync
Sending resync command to local computer
The command completed successfully.
PS C:\Windows\System32> .\w32tm.exe /query /status
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0292832s
Root Dispersion: 7.8120910s
ReferenceId: 0x33917B1D (source IP: 51.145.123.29)
Last Successful Sync Time: 24/11/2024 18:08:33
Source: time.windows.com,0x9
Poll Interval: 10 (1024s)