Ntp - Learning Module | OneNoughtOne

Loading content...

0/228

NTP Security

Time as an Attack Vector

For decades, NTP was designed for a more trusting internet. The original protocol included virtually no security mechanisms—servers broadcast time, clients accepted it, and the assumption was that everyone was cooperating in good faith. That assumption no longer holds.

Time manipulation is a potent attack vector. An adversary who can shift your clock can:

Force acceptance of expired or not-yet-valid certificates
Break cryptographic protocols that depend on time (TOTP, Kerberos, JWT)
Enable replay attacks by shifting time windows
Cause distributed system failures (consensus algorithms, cache invalidation)
Facilitate regulatory violations (timestamped financial transactions)

This page examines the threats facing NTP, legacy authentication mechanisms, and modern solutions like Network Time Security (NTS) that bring cryptographic protection to time synchronization.

What You Will Learn

By the end of this page, you will understand the threat model for NTP and the attacks that can compromise time synchronization, legacy NTP authentication using symmetric keys and Autokey, the modern Network Time Security (NTS) protocol that provides authenticated, encrypted NTP, best practices for securing NTP deployments, and monitoring and detection strategies for time-based attacks.

NTP Threat Model

Understanding NTP security requires understanding the adversaries and their capabilities. The threat model ranges from accidental misconfiguration to sophisticated nation-state attacks.

NTP Threat Actors and Capabilities
Threat Actor	Capabilities	Goals
On-Path Attacker	Can observe and modify traffic between client and server	Manipulate time responses, drop packets, delay traffic
Off-Path Attacker	Cannot see traffic but can send spoofed packets	Inject fake NTP responses, DDoS amplification
Malicious Server Operator	Controls an NTP server the client trusts	Provide false time to targeted or all clients
BGP Hijacker	Can redirect internet traffic through their network	Become on-path attacker for arbitrary client-server pairs
Compromised Infrastructure	Controls DNS, routing, or network equipment	Redirect NTP traffic, respond to queries with false data
Insider Threat	Has administrative access to client or server	Misconfigure NTP, disable authentication, install malicious software

Attack categories:

1. Time Shifting Attacks

Goal: Move the victim's clock forward or backward
Impact: Certificate validation failure, authentication bypass, log manipulation

2. Denial of Service Attacks

Goal: Prevent synchronization or exhaust resources
Impact: Clock drift, service degradation, amplification attacks

3. Traffic Analysis Attacks

Goal: Learn about victim's network topology and timing characteristics
Impact: Reconnaissance for further attacks

4. Man-in-the-Middle Attacks

Goal: Intercept and modify NTP traffic
Impact: Complete control over victim's time perception

NTP as Infrastructure

NTP is foundational infrastructure—like DNS and BGP. Attacks on NTP don't just affect time; they cascade into authentication systems, logging, databases, and any system that depends on accurate timestamps. The impact of a successful NTP attack is almost always broader than it first appears.

Specific Attack Vectors

NTP's design creates several specific vulnerabilities that attackers can exploit. Understanding these vectors is essential for both defending and detecting attacks.

ntp_attacks.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
NTP Attack Vectors
══════════════════════════════════════════════════════════════════════════
 
1. PACKET SPOOFING (Off-Path Attack)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Attack:
  Attacker sends forged NTP responses claiming to be from trusted servers
  
Prerequisites:
  - Know the client's IP address
  - Know the server's IP address
  - Predict or guess the origin timestamp (T1)
  - Beat the legitimate response (race condition)
 
   Client         Attacker         Server
      │               │               │
      │───Request───────────────────►│
      │               │               │
      │◄──Fake Response─┤             │
      │   (spoofed src IP)            │
      │               │               │
      │               │◄──Real Response (arrives second, ignored)
      
Defense:
  - NTS authentication (cryptographic binding)
  - Origin timestamp validation (unpredictable T1)
  - Multiple diverse sources (consensus detection)
 
──────────────────────────────────────────────────────────────────────────
 
2. DENIAL-OF-SERVICE AMPLIFICATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Attack:
  Use NTP servers to amplify and reflect DDoS traffic
  
Technique: NTP "monlist" command (mode 7, now disabled by default)
  - Small query (234 bytes) → Large response (up to 100× amplification)
  - Source IP spoofed to victim's address
  - Thousands of NTP servers flood victim simultaneously
 
   Attacker                NTP Servers              Victim
      │                        │                        │
      │──monlist──────────────►├───────────────────────►│
      │   (src=victim IP)      │     (100× data)        │
      │──monlist──────────────►├───────────────────────►│
      │   (src=victim IP)      │     (100× data)        │
      │         ...            │         ...            │
      │                        │                        │◄─FLOODED
 
Impact: Massive DDoS attacks (2014 NTP amplification attacks peaked at 400 Gbps)
 
Defense:
  - Disable monlist (restrict queries to local)
  - Rate limiting
  - BCP38 source address validation
 
──────────────────────────────────────────────────────────────────────────
 
3. KISS-OF-DEATH (KoD) DENIAL OF SERVICE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Attack:
  Send forged KoD packets to make clients stop querying legitimate servers
  
Technique:
  - Spoof packets from server IP with stratum 0
  - Include DENY or RSTR kiss code
  - Well-behaved clients will stop using that server
 
   Attacker                Client              Server
      │                        │                  │
      │──Fake KoD (DENY)──────►│                  │
      │   (src=server IP)      │                  │
      │                        │───X───X───X───   │
      │                        │  (stops queries) │
 
Defense:
  - Authenticated NTP (NTS)
  - Multiple sources (single KoD doesn't disable all)
  - KoD rate limiting and validation
 
──────────────────────────────────────────────────────────────────────────
 
4. TIME SHIFTING (On-Path MITM)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Attack:
  Modify NTP packets in transit to shift the client's clock
  
Technique:
  - Intercept and delay packets to skew time
  - Modify timestamp fields directly
  - Gradually shift time to avoid detection
  
Gradual shift (more stealthy):
  - Introduce small offset per poll (e.g., 10ms/hour)
  - Stay under NTP's panic threshold
  - Accumulate significant shift over days
  
Immediate shift:
  - Modify timestamps aggressively
  - May trigger detection but achieves immediate effect
 
Defense:
  - NTS (cryptographic message authentication)
  - Physically diverse network paths
  - Out-of-band time verification (GPS receiver)
 
──────────────────────────────────────────────────────────────────────────
 
5. STRATUM MANIPULATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Attack:
  Manipulate stratum values to influence source selection
  
Technique:
  - Advertise artificially low stratum to become preferred source
  - Raise legitimate sources' apparent stratum
  - Once selected as system peer, provide malicious time
 
Defense:
  - Don't trust low stratum alone
  - Multiple diverse sources
  - Authenticated time sources

Diversity Is Defense

The single most effective defense against many NTP attacks is diversity: multiple servers, multiple network paths, multiple providers, potentially multiple protocols (NTP + PTP + GPS). An attacker who must compromise multiple independent sources faces a much harder challenge than one who only needs to compromise a single server.

Legacy Authentication: Symmetric Keys and Autokey

NTP has included authentication mechanisms since the 1990s, but the legacy options have significant limitations.

Symmetric Key Authentication:

The original NTP authentication uses pre-shared symmetric keys. The server and client both know a key ID and secret; the client includes a MAC (Message Authentication Code) in its request, and the server validates it before responding.

Advantages:

Simple to understand and implement
No public key infrastructure required
Minimal computational overhead

Disadvantages:

Key distribution problem: how do you securely share keys?
Same key shared between server and client (no non-repudiation)
Keys must be manually managed on each system
Doesn't scale (N² keys for full mesh)
Old configurations may use weak algorithms (MD5)

symmetric_key_auth.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Symmetric Key Authentication Configuration
══════════════════════════════════════════════════════════════════════════
 
SERVER CONFIGURATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# /etc/chrony/chrony.conf (server)
keyfile /etc/chrony/chrony.keys
allow 192.168.1.0/24
 
# /etc/chrony/chrony.keys
# Format: keyid algorithm secret
1 SHA256 HEX:4e544b9c81f0a7e23a6d47c5f9b8e234a1b2c3d4e5f6a7b8c9d0e1f2
2 SHA256 HEX:a1b2c3d4e5f607890abcdef0123456789abcdef0123456789abcdef0
 
CLIENT CONFIGURATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# /etc/chrony/chrony.conf (client)
keyfile /etc/chrony/chrony.keys
server 192.168.1.1 key 1 iburst
 
# /etc/chrony/chrony.keys (same as server!)
1 SHA256 HEX:4e544b9c81f0a7e23a6d47c5f9b8e234a1b2c3d4e5f6a7b8c9d0e1f2
 
KEY FILE PERMISSIONS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
$ chmod 400 /etc/chrony/chrony.keys
$ chown root:root /etc/chrony/chrony.keys
 
# Keys must be protected - anyone with the key can impersonate!
 
VERIFICATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
$ chronyc ntpdata
Authenticated        : Yes   ← Successful authentication
TX key ID            : 1
RX key ID            : 1
 
$ chronyc authdata
Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
=========================================================================
192.168.1.1                  NTP     1  SHA2  256  43m    0    0    0    0

Autokey (deprecated):

Autokey was NTPv4's attempt to solve the key distribution problem using public key cryptography. Each server has a public/private key pair, and clients can verify responses without pre-shared secrets.

However, Autokey has been deprecated due to:

Multiple cryptographic vulnerabilities discovered
Complex protocol with large attack surface
Difficult to configure correctly
Never achieved widespread adoption

Do not use Autokey for new deployments. Use NTS instead.

Autokey Is Deprecated

Autokey has been removed from modern NTP implementations due to security vulnerabilities. If you find Autokey in a legacy configuration, plan to migrate to NTS (Network Time Security) or fall back to monitored unauthenticated NTP with multiple diverse sources.

Network Time Security (NTS)

Network Time Security (NTS), specified in RFC 8915 (2020), is the modern solution for authenticated NTP. It provides:

Authentication — Clients can verify responses came from the expected server
Integrity — Responses cannot be modified in transit without detection
Confidentiality — Timestamp data is encrypted (prevents traffic analysis)
Scalability — No pre-shared keys needed; uses TLS for key exchange
Privacy — Cookie mechanism prevents tracking clients across sessions

nts_protocol.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
Network Time Security (NTS) Protocol
══════════════════════════════════════════════════════════════════════════
 
NTS consists of two sub-protocols:
  1. NTS Key Establishment (NTS-KE): TLS handshake to exchange keys
  2. NTS Extension Fields: Authenticating subsequent NTP packets
 
══════════════════════════════════════════════════════════════════════════
 
PHASE 1: NTS KEY ESTABLISHMENT (NTS-KE)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  Client                                              NTS-KE Server
     │                                                      │
     │  ────────── TLS 1.3 Handshake ──────────────────────►│
     │                                                      │
     │    Server authenticates via TLS certificate          │
     │    Client verifies against trusted CA roots          │
     │                                                      │
     │  ◄─────────── TLS Established ──────────────────────│
     │                                                      │
     │  ────────── NTS-KE Request ─────────────────────────►│
     │    • Requested AEAD algorithms                       │
     │    • NTP version                                     │
     │                                                      │
     │  ◄─────────── NTS-KE Response ──────────────────────│
     │    • Selected AEAD algorithm (e.g., AES-SIV-CMAC)    │
     │    • NTP server address (may differ from KE server)  │
     │    • Cookies (usually 8)                             │
     │    • End of message                                  │
     │                                                      │
     │  ────────── TLS Close ──────────────────────────────►│
     │                                                      │
 
Keys derived from TLS:
  C2S: Client-to-Server key (for authenticating requests)
  S2C: Server-to-Client key (for authenticating responses)
 
These keys are used for subsequent NTP exchanges.
 
══════════════════════════════════════════════════════════════════════════
 
PHASE 2: AUTHENTICATED NTP PACKETS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  Client                                              NTP Server
     │                                                      │
     │  ────────── NTP Request ────────────────────────────►│
     │    Standard NTP header                               │
     │    + Unique Identifier Extension (random nonce)      │
     │    + Cookie Extension (opaque blob from NTS-KE)      │
     │    + Cookie Placeholder (empty, for new cookies)     │
     │    + AEAD Authentication Tag (C2S key)               │
     │                                                      │
     │  ◄─────────── NTP Response ─────────────────────────│
     │    Standard NTP header with timestamps               │
     │    + Unique Identifier (echoed from request)         │
     │    + New Cookie(s) for future use                    │
     │    + AEAD Authentication Tag (S2C key)               │
     │                                                      │
 
Client verification:
  1. Verify AEAD tag using S2C key
  2. Verify Unique Identifier matches request
  3. If valid, accept timestamps and store new cookie
  4. If invalid, discard response (possible attack)
 
══════════════════════════════════════════════════════════════════════════
 
COOKIE ROTATION AND PRIVACY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
• Client uses one cookie per NTP request
• Server returns new cookies in each response
• Cookies are opaque; server decrypts to recover client keys
• Cookie rotation prevents tracking clients across sessions
• If cookies run out, client re-runs NTS-KE
 
Cookie lifecycle:
  [NTS-KE] → 8 cookies
     ↓
  [NTP #1] uses cookie 1 → receives 2 new cookies (total: 9)
     ↓
  [NTP #2] uses cookie 2 → receives 2 new cookies (total: 9)
     ↓
  ... continues, cookies always replenished ...
 
══════════════════════════════════════════════════════════════════════════

Configuring NTS with chrony:

nts_configuration.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
NTS Configuration (Chrony)
══════════════════════════════════════════════════════════════════════════
 
CLIENT CONFIGURATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# /etc/chrony/chrony.conf
 
# NTS-enabled servers (use 'nts' keyword)
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts
server ntppool1.time.nl iburst nts
pool nts.pool.ntp.org iburst nts
 
# Trust store for NTS-KE TLS certificates (usually system default)
# ntstrustedcerts /etc/pki/tls/certs/ca-bundle.crt
 
# NTS key/cookie storage (survives restarts)
ntsdumpdir /var/lib/chrony
 
# Standard options continue...
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
 
VERIFICATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
$ chronyc -N sources
MS Name/IP address               Stratum Poll Reach LastRx Last sample
==============================================================================
^* time.cloudflare.com               3   6   377    25   +234us[+567us] +/-  15ms
^+ nts.netnod.se                     1   6   377    24   -123us[ -12us] +/-  22ms
^+ ntppool1.time.nl                  1   6   377    26   +345us[+678us] +/-  25ms
 
$ chronyc authdata
Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
==============================================================================
time.cloudflare.com          NTS     1 AEAD  256  25s    0    0    8  100
nts.netnod.se                NTS     1 AEAD  256  24s    0    0    8  100
ntppool1.time.nl             NTS     1 AEAD  256  26s    0    0    8  100
 
Legend:
  Mode: NTS = NTS authentication active
  KeyID: Key identifier
  Type: AEAD = Authenticated Encryption with Associated Data
  KLen: Key length in bits
  Cook: Number of cookies available
  CLen: Cookie length
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
SERVER CONFIGURATION (to serve NTS)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
# /etc/chrony/chrony.conf (server)
 
# Enable NTS-KE server on port 4460
ntsserverkey /etc/chrony/nts.key
ntsservercert /etc/chrony/nts.crt
ntsprocesses 1
 
# Certificate must be trusted (Let's Encrypt works)
# Key/cert permissions: readable only by chrony daemon
 
# Allow NTP queries (authenticated via NTS or not)
allow 0.0.0.0/0
allow ::/0

NTS Adoption

Major NTS providers include Cloudflare (time.cloudflare.com), Netnod (nts.netnod.se), and increasing numbers of pool.ntp.org servers. Check nts.pool.ntp.org for pool servers with NTS support. Always prefer NTS-capable servers when available—the security benefits are significant.

NTP Hardening Best Practices

Whether or not you use NTS, there are many measures to harden your NTP deployment against attacks.

NTP Hardening Checklist

•Use 4+ diverse NTP sources — Different organizations, different network paths, different geographies. Consensus-based falseticker detection requires multiple sources.
•Enable NTS where available — Cryptographic authentication protects against spoofing and MITM attacks.
•Restrict query access — If your server shouldn't serve time publicly, restrict who can query it. Use allow/deny directives.
•Disable monlist/mode 7 — The monlist command enables amplification attacks. Modern installations have it disabled by default, but verify.
•Rate limit queries — Protect against resource exhaustion. ratelimit in chrony, restrict options in ntpd.
•Use a local stratum server — Point clients at internal NTP servers, not directly at public servers. Reduces exposure and provides a control point.
•Monitor stratum and offset — Alert on stratum increases (synchronization problems) and large offsets (possible attacks).
•Consider GPS/PPS for critical systems — Out-of-band time verification via GPS is immune to network-based attacks.
•Firewall NTP appropriately — Allow UDP/123 inbound only to your NTP servers, and outbound from NTP clients to configured servers.
•Keep software updated — NTP implementations have security fixes; stay current.

hardened_chrony_config.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
Hardened Chrony Configuration
══════════════════════════════════════════════════════════════════════════
 
# /etc/chrony/chrony.conf
 
# Use diverse NTS-enabled sources (4+ for Byzantine fault tolerance)
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts  
pool nts.pool.ntp.org iburst nts maxsources 4
 
# Non-NTS fallbacks (diverse geographical locations)
pool pool.ntp.org iburst maxsources 2
 
# Store NTS keys and drift across restarts
ntsdumpdir /var/lib/chrony
driftfile /var/lib/chrony/drift
 
# Allow step only at startup (first 3 updates)
makestep 1.0 3
 
# Sync RTC on kernels that support it
rtcsync
 
# Logging for security monitoring
logdir /var/log/chrony
log tracking measurements statistics
 
# ═══════════════════════════════════════════════════════════════════════
# ACCESS CONTROL (for NTP servers)
# ═══════════════════════════════════════════════════════════════════════
 
# Default: deny all
deny all
 
# Allow local network to query time
allow 10.0.0.0/8
allow 192.168.0.0/16
 
# Allow localhost (for chronyc)
allow 127.0.0.1
allow ::1
 
# Rate limit queries to prevent abuse
ratelimit interval 1 burst 16
 
# ═══════════════════════════════════════════════════════════════════════
# COMMAND INTERFACE SECURITY
# ═══════════════════════════════════════════════════════════════════════
 
# Only allow local commands (no network control)
bindcmdaddress 127.0.0.1
bindcmdaddress ::1
 
# Require authentication for modify commands
cmdallow 127.0.0.1
cmddeny all
 
# ═══════════════════════════════════════════════════════════════════════
# ADDITIONAL HARDENING
# ═══════════════════════════════════════════════════════════════════════
 
# Lock memory (prevent paging secrets to disk)
lock_all
 
# Privilege separation (chrony drops root after startup)
# (This is default behavior on most distributions)
 
# Maximum source distance - reject sources with high uncertainty
maxdistance 3.0
 
# Minimum number of sources before accepting time
minsources 2

Firewall Considerations

NTP uses UDP port 123. Stateful firewalls should allow outbound NTP (to configured servers) and track responses. Avoid allowing inbound UDP/123 from the entire internet unless you're intentionally running a public NTP server—and if you are, implement rate limiting and monitoring.

Leap Second Handling

Leap seconds are a security-adjacent concern because incorrect handling can cause system failures. Understanding how NTP handles leap seconds—and the alternatives—is important for reliable operations.

What are leap seconds?

Earth's rotation is gradually slowing, while atomic clocks maintain constant rate. To keep UTC aligned with solar time, the IERS (International Earth Rotation and Reference Systems Service) occasionally adds a "leap second"—an extra second at the end of June 30 or December 31.

During a positive leap second:

23:59:58 UTC
23:59:59 UTC
23:59:60 UTC  ← The leap second (60 seconds in the minute!)
00:00:00 UTC  ← Next day

Leap Second Handling Strategies
Strategy	How It Works	Pros/Cons
Step (traditional)	Clock shows 23:59:60, then 00:00:00	True to UTC; but some software crashes on :60 second
Repeat (ntpd default)	Clock shows 23:59:59 twice	Some software sees time go backward briefly
Smear (Google/AWS)	Distribute extra second over hours	No discontinuity; but clock disagrees with UTC during smear
Ignore (not recommended)	Pretend it doesn't exist	Clock drifts 1 second from UTC; dangerous

Leap second smearing (Google's approach):

Google, AWS, and other cloud providers implement "leap second smearing," where the extra second is gradually applied over typically 12-24 hours around the leap second event. During this period, their clocks run very slightly slow or fast, but there's no discontinuity.

Important: Don't mix smearing and non-smearing sources! If you use time.google.com (smearing) and pool.ntp.org (stepping), NTP may detect them as falsetickers during the smear window because they disagree by up to 500ms.

Leap Seconds May Be Eliminated

The ITU voted in 2022 to eliminate leap seconds by 2035, allowing the difference between UTC and UT1 (solar time) to grow. This will eventually require a larger correction, but removes the ongoing operational risk of leap second handling. Until 2035, leap seconds remain a concern.

Monitoring and Attack Detection

Proactive monitoring can detect NTP attacks before they cause damage. Here are key metrics to monitor and alert on:

NTP Monitoring Metrics

•Stratum — Should be stable. Alert on increase (losing sync sources) or decrease (new low-stratum source appearing—could be attack).
•Offset — Should be small (<100ms typically). Large or sudden offset changes may indicate attack or infrastructure failure.
•Reachability — Should be high (377 = all recent polls successful). Declining reachability indicates connectivity problems or DoS.
•Root delay/dispersion — Should be stable. Large increases indicate network problems or hierarchy issues.
•Number of valid sources — Should match configuration. Declining count indicates source failures.
•Falseticker detection — Alert when sources are marked as falsetickers—may indicate attack or misconfiguration.
•NTS authentication failures — Alert on authentication failures (NAK count in chronyc authdata).
•Step events — Clock steps are abnormal in steady state. Alert on any step after initial sync.

ntp_monitoring.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
NTP Monitoring Script Example
══════════════════════════════════════════════════════════════════════════
 
#!/bin/bash
# ntp_check.sh - Monitor NTP health metrics
 
# Get chrony tracking data
TRACKING=$(chronyc tracking)
 
# Extract key metrics
STRATUM=$(echo "$TRACKING" | grep "Stratum" | awk '{print $3}')
OFFSET=$(echo "$TRACKING" | grep "System time" | awk '{print $4}')
ROOT_DELAY=$(echo "$TRACKING" | grep "Root delay" | awk '{print $4}')
LEAP_STATUS=$(echo "$TRACKING" | grep "Leap status" | cut -d: -f2 | tr -d ' ')
 
# Count reachable sources
SOURCES=$(chronyc sources | grep -E "^^" | wc -l)
REACHABLE=$(chronyc sources | grep -E "^^[*+]" | wc -l)
 
# Alert thresholds
MAX_STRATUM=5
MAX_OFFSET=0.1  # 100ms
MIN_SOURCES=3
 
echo "NTP Health Check - $(date)"
echo "================================"
echo "Stratum:        $STRATUM (max: $MAX_STRATUM)"
echo "Offset:         $OFFSET seconds"
echo "Root Delay:     $ROOT_DELAY"
echo "Sources:        $REACHABLE / $SOURCES reachable"
echo "Leap Status:    $LEAP_STATUS"
echo ""
 
# Check for alerts
ALERT=0
 
if [ "$STRATUM" -gt "$MAX_STRATUM" ]; then
    echo "⚠️  ALERT: Stratum $STRATUM exceeds threshold $MAX_STRATUM"
    ALERT=1
fi
 
if [ "$REACHABLE" -lt "$MIN_SOURCES" ]; then
    echo "⚠️  ALERT: Only $REACHABLE sources reachable (min: $MIN_SOURCES)"
    ALERT=1
fi
 
if [ "$LEAP_STATUS" != "Normal" ]; then
    echo "⚠️  ALERT: Leap status is $LEAP_STATUS"
    ALERT=1
fi
 
# Check for falsetickers
FALSETICKERS=$(chronyc sources | grep -E "^^x" | wc -l)
if [ "$FALSETICKERS" -gt 0 ]; then
    echo "⚠️  ALERT: $FALSETICKERS sources marked as falsetickers"
    chronyc sources | grep -E "^^x"
    ALERT=1
fi
 
exit $ALERT
 
══════════════════════════════════════════════════════════════════════════
 
PROMETHEUS/GRAFANA METRICS (node_exporter + chrony)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
Useful metrics from chrony_exporter:
  chrony_tracking_stratum              - Current stratum
  chrony_tracking_system_time          - Offset in seconds
  chrony_tracking_root_delay_seconds   - Delay to root
  chrony_tracking_root_dispersion      - Dispersion to root
  chrony_sources_count                 - Number of configured sources
  chrony_tracking_last_offset_seconds  - Last measured offset
 
Alert rules (PromQL):
  # Stratum too high
  chrony_tracking_stratum > 5
 
  # Large offset
  abs(chrony_tracking_last_offset_seconds) > 0.1
 
  # Lost sources (assuming 4 configured)
  chrony_sources_count < 4

Defense in Depth

Combine multiple layers: use NTS for authentication, monitor for anomalies, use diverse sources for consensus, and for critical systems, deploy an independent GPS/atomic reference that can detect if all network time sources are being manipulated.

Summary: NTP Security

Time security is critical infrastructure security. As we've seen, attacks on NTP can cascade into authentication failures, data corruption, and system-wide outages. Let's consolidate the key security concepts:

Key Takeaways

•Time manipulation is a potent attack vector — Attackers who control your clock can break certificates, authentication, logging, and distributed systems.
•NTP faces multiple attack vectors — Spoofing, MITM, amplification DDoS, kiss-of-death abuse, and stratum manipulation all threaten unprotected NTP.
•Legacy authentication is limited — Symmetric keys require manual distribution; Autokey is deprecated and insecure.
•NTS is the modern solution — Network Time Security provides authenticated, encrypted, scalable protection using TLS for key establishment.
•Diversity is defense — Multiple sources from different providers, networks, and geographies enable consensus-based falseticker detection.
•Hardening includes many layers — NTS plus access control, rate limiting, monitoring, and potentially out-of-band verification (GPS).
•Monitor actively — Track stratum, offset, reachability, and falseticker events to detect attacks early.

Module Complete

Congratulations! You've completed the NTP module. You now understand:

Why time synchronization is fundamental to distributed systems
How NTP's hierarchical architecture distributes time globally
The meaning and mechanics of stratum levels
The algorithms that measure, filter, select, and discipline clocks
The security threats facing NTP and how to defend against them

This knowledge equips you to design, deploy, secure, and troubleshoot time synchronization in any environment—from small offices to global-scale distributed systems.

Module Complete

You've mastered the Network Time Protocol—from the physics of clock drift through the elegance of the selection algorithms to the cryptographic protections of NTS. Time synchronization may be invisible to most users, but you now understand the sophisticated infrastructure that makes distributed computing possible.