An NTS and NTP Hardening Runbook with chrony

In most environments, NTP gets reduced to “is UDP/123 open?” That framing misses how time has become a security and operational-correctness layer. chrony is a strong NTP option on modern Linux distributions, particularly when paired with NTS (Network Time Security).

This runbook collects practical steps to take chrony from “we installed it” to “we operate it.”

Target architecture

• Clients only talk to internal time servers.
• Time servers reach upstream sources (the internet or an external reference).
• Whenever feasible, NTS provides validation upstream.

1) Installation

The package name varies by distribution. The general approach:

sudo apt-get update
sudo apt-get install -y chrony

2) chrony configuration (client)

A sample /etc/chrony/chrony.conf approach:

• Use internal time servers instead of the internet
• Keep step behavior under control
• Make logs visible

Example:

# Internal time servers
server ntp-01.internal iburst
server ntp-02.internal iburst

# Controlled step on large drift (helpful at first boot)
makestep 1.0 3

# Source quality / statistics
rtcsync
driftfile /var/lib/chrony/chrony.drift
log tracking measurements statistics
logdir /var/log/chrony

3) chrony configuration (time server)

Two critical concerns on the time server:

1. Upstream source selection and redundancy
2. Who is allowed to consume the service (ACLs)

A basic example:

# Upstream (example)
server time.cloudflare.com iburst nts
server time.google.com iburst

# Allow client networks
allow 10.10.0.0/16
allow 10.20.0.0/16

# Don't serve everyone
deny all

rtcsync
makestep 1.0 3
driftfile /var/lib/chrony/chrony.drift
log tracking measurements statistics
logdir /var/log/chrony

4) Firewall / segmentation

• Client to time server: UDP/123
• Time server to upstream: UDP/123 plus TCP/4460 for NTS (varies by service)

The NTS port can vary with the provider; choosing a stable in-house upstream set keeps operations simpler.

5) Verification commands

On the client:

chronyc tracking
chronyc sources -v
chronyc sourcestats -v

The signs to look for:

• Leap status is normal
• System time offset is small and stable
• Reach value sits near 377 (consistent reachability)

On the time server, additionally:

chronyc clients
chronyc activity

6) Alarm thresholds (practical)

Reasonable starting points for general enterprise systems:

• Warning: offset > 50ms (sustained)
• Critical: offset > 200ms
• Reachability: critical when source reach values keep falling

Tighten these thresholds based on each service’s tolerance.

7) Incident triage: when you see “clock skew”

1. Use chronyc tracking to inspect offset and sources
2. Is there a reachability problem? (sources -v reach declining?)
3. Is the upstream broken on the time server? (Has only one source survived?)
4. Is there CPU steal or load pressure on the VM/host?
5. If necessary, perform a controlled step (mind the impact on services)

Closing

When chrony is paired with the right topology and monitoring signals, time synchronization stops being a “background service” and becomes a foundation layer for security and operational correctness. Putting NTS upstream and constraining access via an allow list delivers, in practice, the highest payoff with the least complexity.