EN FR Home

NTP server security
Threats, hardening, and how to test it

NTP is unauthenticated by default and runs over UDP. Here is what actually threatens a time server, how to harden it, and how to check yours in minutes.

Published 21 September 2026 · Sources checked on 21 September 2026 · By Richard DEMONGEOT, RDEM Systems · About the author

1. NTP as a security surface

NTP exposes a time server on two counts. NTP is unauthenticated by default: a plain client accepts whatever a server sends, and an on-path or off-path attacker who can spoof the source can shift a victim's clock — which breaks TLS certificate validity, TOTP/MFA windows, Kerberos, and the timestamps every audit trail relies on. And NTP runs over UDP, which makes it usable for reflection/amplification against third parties: a small forged request draws a large reply toward the spoofed victim. The classic case is the monlist command of old ntpd (CVE-2013-5211), amplifying by hundreds of times.

2. The threats, concretely

  • Amplification / reflection — a server that answers legacy control queries (mode 7 monlist, mode 6 readvar) returns far more than it receives. Spoofing the source turns it into a DDoS reflector. This is the one check we only run with proof of ownership.
  • Time shifting — off-path or on-path manipulation moves a client's clock by seconds to years. Precise and wrong is worse than obviously broken: it silently invalidates certificates and tokens.
  • Kiss-o'-Death spoofing — a forged KoD packet tells a client to back off from a legitimate source, steering it toward an attacker's server.
  • False ticker — a source whose time disagrees with the majority; with too few sources it can win the vote (how selection works is covered on our diagnostic sister site).
  • Stratum-16 silent failure — a source that lost sync reports stratum 16; without monitoring, the operator believes time is flowing while it is frozen.
  • Pool pollution — a hostile volunteer server injected into a public pool; mitigated by choosing known operators and several independent sources, so selection can outvote a bad one. Authentication proves who answers, not that the time is right.

3. Hardening a time server

  • Authenticate the channel with NTS (RFC 8915): TLS-established keys, then authenticated NTP. It defeats spoofing for clients that use it. Modern chrony, ntpd-rs and NTPsec support it.
  • Disable or restrict legacy control: turn off mode 6/7 remote queries (chrony does not answer them at all; on ntpd, restrict ... noquery and drop monlist). This closes the amplification vector.
  • Rate-limit and KoD: cap per-client rates so your server cannot be used as a large reflector even if it answers.
  • Several diverse, authenticated sources (different operators and networks): resilience against one bad or captured upstream. Frameworks recommend at least two (what each one actually requires).
  • Monitor offset, reach and stratum, and alert on stratum-16 or false-ticker: a clock failure must be a detectable event.

4. How to test your NTP server

The validator on the home page queries any public server from our side and reports, in one measurement: whether it serves unauthenticated NTP (stratum, leap, round-trip); whether NTS works (handshake, TLS identity attested for the name, certificate days left); and its traceability (reference ID, stratum, offset from our reference with the uncertainty).

The reflection / amplification check is the one that could be abused against a third party, so it runs only on an address whose operator has proven control of it — a one-time curl challenge from the server itself, like a Let's Encrypt HTTP challenge. Prove it once, and the report comes back in your terminal:

$ curl -4 --interface 203.0.113.10 https://ntp.rdem-systems.com/verify/<token>
NTP validation for 203.0.113.10  (2026-09-21 10:20 UTC)
--------------------------------------------------------
ownership: proven for this address (source of your request matched)
NTS-KE: present (identity attested) - cert 56 d left
stratum 2 (refid 192.53.103.108) - offset vs our server +0.619 ms - leap 0
hardening: closed - no amplifying reply to a legacy control query (good)
--------------------------------------------------------
NTP works iff unauthenticated time is obtained; NTS iff authenticated time is.
The two verdicts are independent. Refid is the raw value the server announces.
One measurement from one vantage point - not an audit, not a certification.

For your own clock rather than a server, use ntp-tester.eu; to diagnose why a daemon will not sync, check-ntp.net.

Frequently asked questions

Is my NTP server an open amplifier?

It is if it answers legacy control queries (mode 7 monlist, mode 6 readvar) with a reply larger than the request, and does not rate-limit. chrony never answers them; a patched ntpd with "restrict noquery" does not either. Our validator runs an amplification hardening check, but only against an address whose operator proves control of it.

How do I test whether my NTP server is secure?

Check three things a normal client can see — does it serve unauthenticated NTP, does NTS authenticate the channel, is its time traceable — and one you must prove ownership for: does it amplify a legacy control query. The validator on our home page does all four; the amplification check needs a one-time curl challenge from the server itself.

Does NTP need authentication?

No standard mandates NTP authentication by name, but an unauthenticated time source can be spoofed, and spoofed time breaks certificates, MFA and audit trails. NTS (RFC 8915) is the standardised way to authenticate the channel and is the recommended control where integrity of time matters.

What is the monlist amplification attack?

monlist is an old ntpd mode-7 command that returns a list of recent clients — a small request draws a large reply. Spoofing the victim's address turns the server into a DDoS reflector (CVE-2013-5211). Disable mode 6/7 remote queries and rate-limit to close it.