NTP Explained: RFC 5905 Packets, Modes and How to Harden Time Servers

NTP, the Network Time Protocol, is the application protocol that keeps computer clocks synchronised to UTC across a network. It runs over UDP port 123 and is defined today by RFC 5905 (NTP version 4, June 2010), which replaced the NTPv3 specification (RFC 1305) and the separate SNTP specification (RFC 4330). Almost every server, laptop, phone, router and container host you run asks an NTP server what time it is.

Time looks like plumbing until it breaks: certificates, Kerberos, one time passwords and incident logs all depend on it. This post explains what an NTPv4 packet carries, how the client/server, symmetric and broadcast modes differ, which weakness classes the standards themselves describe, what the operational best practice RFC 8633 (BCP 223) recommends, and how to check your own chrony, ntpd and Windows Time hosts. The offset and delay maths has its own post, NTP stratum, offset and delay explained, and so does authenticated time, Network Time Security (NTS) for NTP explained, so this one stays on the packet, the modes and server hardening.

Key takeaways

• RFC 5905 (June 2010) is the NTPv4 specification. It obsoletes RFC 1305 (NTPv3) and RFC 4330 (SNTPv4) and has been updated by RFC 7822, RFC 8573 and RFC 9109.
• An NTP packet is a UDP datagram with a 48 byte header: leap indicator, version, mode, stratum, poll, precision, root delay, root dispersion, reference ID and four 64 bit timestamps, optionally followed by extension fields and a MAC.
• The mode field says who is talking: 1 and 2 symmetric, 3 client, 4 server, 5 broadcast, 6 control, 7 private. Most hosts only need modes 3 and 4.
• Plain NTP has no confidentiality and no authentication by default. NTS (RFC 8915, September 2020) adds authentication for client/server mode.
• The weakness classes are off-path spoofing, control message (mode 6 and 7) exposure and reflection, time shifting through restarts, broadcasts or rogue peers, delay manipulation and information leakage. The monlist reflection attacks in CISA's January 2014 alert on CVE-2013-5211 are the best known example.
• Hardening is mostly about modes: serve modes 3 and 4 only where needed, refuse control queries from outside, keep broadcast and symmetric modes on trusted networks with keys, use four or more diverse sources, rate limit, and patch. chronyc, ntpq and w32tm show whether that is true.

What NTP is for, where it sits and which standard defines it

Every computer clock drifts. NTP lets a client exchange timestamps with several servers, estimate its offset and the round trip delay, and steer the local clock towards the consensus of good sources.

NTP is an application layer protocol that runs over UDP. RFC 5905 is explicit that this is deliberate: the on-wire protocol "does not require reliable message delivery", and reliable delivery such as TCP "can actually make the delivered NTP packet less reliable since retries would increase the delay value". IANA lists port 123 for both UDP and TCP against RFC 5905, but NTP itself is a UDP protocol; only NTS key establishment uses TCP, on port 4460.

RFC 5905 describes a hierarchy. Primary servers are synchronised to a reference clock traceable to UTC, such as a GPS receiver or a national radio signal, and sit at stratum 1. Secondary servers synchronise to them over NTP at stratum 2 and below, and clients sit at the leaves. Time, and in the RFC's words trust, "flow from the primary servers at the root through secondary servers to the clients at the leaves." How stratum and synchronisation distance are calculated is covered in our stratum, offset and delay post.

What RFC 5905 replaced and what has updated it since

Why security depends on correct time

It is easy to treat time as an availability concern. It is a security control in its own right, which is why frameworks such as NIST SP 800-53 carry a dedicated control for it (see our post on SC-45 system time synchronization). Four dependencies matter most:

• Certificates. RFC 5280 path validation checks that "the certificate validity period includes the current time". A clock set in the past can make an expired certificate look valid; a clock set in the future breaks every TLS connection.
• Kerberos. RFC 4120 (July 2005) requires every host to have a clock that is "loosely synchronized", typically to within 5 minutes, and says that if clocks are synchronised over the network, "the clock synchronization protocol MUST itself be secured from network attackers." Outside the skew window, authentication simply fails.
• One time passwords. TOTP under RFC 6238 (May 2011) derives the code from the current time in steps, with a recommended default of 30 seconds. Drift turns into rejected logins.
• Logs. Correlating logs across systems during an incident depends on them agreeing on time.

RFC 5905 names the circular problem: keys are valid only over a time interval, but "time intervals can be enforced only when participating servers and clients are reliably synchronized to UTC."

How NTP works on the wire

The packet header, field by field

RFC 5905 section 7.3 defines the header as twelve 32 bit words in network byte order, followed by optional extension fields and an optional message authentication code. The basic header, up to the end of the Transmit Timestamp, is 48 bytes, and it is identical in layout to the NTPv3 header.

The destination timestamp (T4, when the reply reaches the client) is not in the packet. The client records it on arrival.

NTP timestamps are 64 bits: 32 bits of seconds and 32 bits of fraction, which resolves 232 picoseconds. The epoch is 0 h on 1 January 1900 UTC. The seconds field covers 136 years, so era 0 ends in 2036 when the field wraps and era 1 begins. RFC 5905 handles this with era arithmetic, but it also notes a hard limit: with 64 bit integer arithmetic a client must start within 34 years of the server's time, or 68 years if differences are computed in floating point. The root delay and dispersion fields use a 32 bit short format, 16 bits of seconds and 16 of fraction.

The client/server exchange

The client/server mode is what nearly every host uses. The client sends a mode 3 packet; the server answers with mode 4 and keeps no state about the client.

Client (mode 3 association)                      Server (no state kept)
---------------------------                      ----------------------
T1: stamp local clock
    send mode 3 packet
    (transmit timestamp = T1)   ---------------->
                                                 T2: stamp arrival
                                                 copy client's transmit
                                                 timestamp into origin field
                                                 T3: stamp departure
                                <----------------  send mode 4 packet
                                                 (origin = T1, receive = T2,
                                                  transmit = T3)
T4: stamp arrival
check origin field == T1 (else "bogus", discard)
check transmit field != last T3 (else duplicate or replay, discard)
offset = ((T2 - T1) + (T3 - T4)) / 2
delay  = (T4 - T1) - (T3 - T2)

Those two checks are RFC 5905's built-in defence against stray and replayed packets. A reply whose origin timestamp does not match what the client sent is "bogus" and discarded; a reply whose transmit timestamp matches the previous one is a duplicate or replay. Because the client's transmit timestamp acts like a 64 bit nonce, an attacker who cannot see the request has to guess it. RFC 5905 also notes the opposite gap: the exchange does not resist replay of the client's request, which is why the client zeroes its stored transmit value after a successful exchange.

A real client polls several servers and runs filtering, selection and clustering to separate "truechimers" from "falsetickers"; those algorithms are covered in the offset and delay post.

A note on the standard: RFC 5905's Figure 1 and the paragraph after it say clients send mode 4 and servers mode 3. Erratum 3126, held for document update, corrects this to clients sending mode 3 and servers mode 4, as the rest of the RFC says.

Association modes: client/server, symmetric and broadcast

RFC 5905 defines three protocol variants, plus a discovery scheme.

Persistent associations come from configuration; ephemeral ones are mobilised when a packet arrives. Symmetric passive and broadcast client associations are ephemeral, so a stranger's packet can try to create one, which is the basis of two RFC 8633 recommendations.

IANA has allocated the IPv4 multicast group 224.0.1.1 and IPv6 multicast addresses ending in :101 for NTP broadcast and manycast.

Kiss-o'-Death packets

When the stratum field is 0, the reference ID carries a four character "kiss code" instead of a clock identifier. These Kiss-o'-Death (KoD) packets let a server tell a client to change behaviour. RFC 5905 requires clients to stop sending to a server that returns DENY or RSTR and to reduce their polling rate when they receive RATE. Other codes, such as INIT or AUTH, are informational, and IANA keeps the registry.

KoD is useful and also a lever an attacker would like to pull, which is why RFC 8633 says a client "MUST only accept a KoD packet if it has a valid origin timestamp" and must not blindly accept a huge poll interval from one.

Extension fields and MACs

NTPv4 added optional extension fields between the header and the MAC, each with a 16 bit type, a 16 bit length, a value and padding. RFC 7822 tightened the rules: minimum lengths so a parser can tell an extension field from a MAC, a 24 octet cap on a MAC without extension fields unless negotiated, and firewalls "MUST NOT filter NTP packets based on their extension fields", since new ones will appear. NTS is built entirely from extension fields.

The original symmetric key MAC is a 32 bit key ID followed by an MD5 based digest. RFC 5905 itself admits "the security shortfalls of the MD5 algorithm are well-known". RFC 8573 deprecated MD5 for this purpose and recommends AES-CMAC.

Control messages: mode 6 and mode 7

Mode 6 is the control message format from Appendix B of RFC 1305, used by ntpq to read and optionally change ntpd's state; RFC 8633 notes it is absent from RFC 5905 but still used. Mode 7 is "reserved for private use"; ntpd used it for the older ntpdc utility and the monlist command. chrony speaks neither: its FAQ says its monitoring protocol "is not compatible with the mode 6 or mode 7 protocol supported by ntpd", and chronyc uses UDP 323 or a Unix socket.

Ports and IANA

Versions and history

NTPv3 (RFC 1305, March 1992). Written by David Mills at the University of Delaware, it obsoleted RFCs 1119, 1059 and 958, formalised the error analysis and the clock filter and selection algorithms, carried the symmetric key MAC, and defined in its Appendix B the mode 6 control messages that ntpq still uses.

SNTP. SNTPv4 (RFC 4330, January 2006) described a subset for clients with one upstream server and primary servers with one reference clock. RFC 5905 section 14 folded it back in: SNTP is "completely interoperable" with NTP, and a client may use as little as the server's transmit timestamp. NIST's service page likewise calls a client that sets its clock from a single request an SNTP client.

NTPv4 (RFC 5905, June 2010). Per its abstract: a header change for IPv6 (the reference ID becomes the first four octets of an MD5 hash of the IPv6 address), better mitigation and discipline algorithms reaching tens of microseconds on fast LANs, manycast server discovery, fixes to NTPv3 design errors and the extension field mechanism. The maximum poll interval grew from 1024 seconds to about 36 hours, and the wire format stayed backwards compatible. Autokey (RFC 5906) shipped alongside it and was later deprecated by RFC 8633.

What is deployed today. NTPv4 is what modern daemons speak. The Network Time Foundation's ntpd is in the 4.2.8 series; the newest release in its download archive when this post was written is ntp-4.2.8p18, dated May 2024. chrony's documentation page lists version 4.9 as current, and it supports NTS. Windows uses its own Windows Time service (W32Time). RFC 8633 section 6 singles out embedded devices, whose owners often cannot update the NTP code themselves.

Security properties: what NTP does and does not guarantee

RFC 5905 says its built-in checks are "inherently resistant to spoofing, packet-loss, and replay attacks" but "do not securely identify and authenticate servers to clients". RFC 8633 adds that none of NTP's security mechanisms "can prevent packet delay manipulation attacks", which can target cleartext packets or packets "within an encrypted tunnel."

Weakness classes, described as concepts

This section describes what goes wrong and why the design allows it, drawing on the Security Considerations of RFC 5905 and the best practice in RFC 8633. It does not describe how to carry out any of these attacks.

Off-path spoofing

UDP has no handshake, so an attacker off the path can send forged replies and hope one is accepted. RFC 9109 explains that "many of these attacks require the attacker to guess or know" the association's addresses, ports and key ID. A client that always uses source port 123 gives one away. The origin timestamp check is the main defence; RFC 8633 lists zero or mismatched origin timestamps as attack signatures and cites CVE-2015-8138 as an implementation flaw in that check.

RFC 8633 also describes forged requests in a victim's name that make servers rate limit the victim, cutting it off from time.

Control message exposure and reflection

RFC 8633 says control message responses "are much larger than the corresponding queries" and "can be abused in high-bandwidth DDoS attacks." With forged UDP sources, a public server becomes a reflector that sends large answers to a victim.

The best known case is monlist. CISA's alert of 13 January 2014 on CVE-2013-5211 describes how the monlist command in older ntpd versions returned a list of up to the last 600 addresses that had contacted the server, which made it an amplifier when queried with a spoofed source. CISA noted that ntpd versions before 4.2.7 were vulnerable by default and recommended upgrading or adding noquery to the default restriction. RFC 8633 also notes that control queries leak internal state such as the reference ID and expected origin timestamp, which makes spoofing easier, citing CVE-2015-8139.

Information leakage from ordinary replies

Even a normal mode 4 reply reveals the reference ID and reference time, which RFC 8633 section 5.1 says "may be used in attacks". It recommends ACLs for control queries and says a "leaf-node host", one that only sets its own clock, "SHOULD drop all incoming NTP packets except mode 4 response packets that come from known sources."

Time shifting through modes that create associations

Two modes let an unsolicited packet create state.

• Symmetric passive. A mode 1 packet with no matching association mobilises a passive one, so per RFC 8633 section 5.6 "an arbitrary attacker can attempt to change Bob's time". Accept symmetric peers only when authenticated, each with its own key.
• Broadcast. Every client shares the server's key, so per RFC 8633 section 5.5 any client could send valid broadcasts to the others. Broadcast belongs only on trusted networks.

Time shifting through restarts and the panic threshold

RFC 5905 tells clients to exit rather than accept an offset above the panic threshold of 1000 seconds. RFC 8633 section 5.2 explains the failure: if a supervisor restarts the daemon and the daemon ignores the threshold on every start, one large offset causes an exit and the restarted daemon accepts it. The advice is not to ignore the threshold on every cold start, to log panic exits, and to require more agreeing sources.

Rate limiting and KoD abuse

A client that accepts an unauthenticated RATE packet with an enormous poll value may effectively stop asking for time. RFC 8633 caps the poll value after a RATE at 13, about two hours.

Delay manipulation

An attacker on the path can hold packets in one direction to skew the offset calculation, since NTP assumes the outbound and return delays are equal. No MAC or encryption prevents this. Using several diverse sources over different paths, and watching for sources that disagree, is the defence.

Implementation bugs in the daemon

Many published NTP vulnerabilities are bugs in a specific daemon rather than in the protocol. RFC 8633's first configuration practice is to "select an implementation that is actively maintained" and deploy security fixes "as soon as it is practical."

What RFC 8633 (BCP 223) recommends

RFC 8633 is the operator's checklist. The points that matter most for hardening:

1. Filter spoofed traffic with BCP 38 ingress and egress filtering, which removes the forged sources reflection depends on.
2. Run a maintained implementation and patch it.
3. Use at least four independent, diverse sources where accuracy matters, with diverse reference clocks, because clocks from one vendor "may have the same bugs."
4. Block control queries from outside the organisation, and require a control key or an ACL for anything beyond basic monitoring.
5. Monitor for out of sync sources and for replies to requests you never sent.
6. Drop MD5 and Autokey. Use AES-CMAC (RFC 8573); NTS was still in progress then and is now RFC 8915.
7. Minimise leakage, and have leaf hosts accept only mode 4 replies from known servers.
8. Do not ignore the panic threshold on every restart, and validate KoD packets before obeying them.
9. Keep broadcast mode on trusted networks and symmetric mode for authenticated peers.
10. Never mix leap smearing and non smearing servers, and only preconfigure servers you have permission to use.

What RFC 9109 changes

RFC 9109 updates a single definition in RFC 5905. The original text said the client's port was "ordinarily" 123. The new text says broadcast server mode and symmetric modes should use 123, but in client mode the port "SHOULD contain a randomized port number" as described in RFC 6056, and should not be shared with other associations. Clients that randomise per request should close the socket after each exchange.

An off-path attacker now has to guess a port as well as the origin timestamp, and firewalls can tell requests from responses because only servers use 123 as a source. The trade-off RFC 9109 discusses is path stability: a new source port can change the ECMP path and add measurement noise, so implementations may randomise per association instead of per request.

In practice, chrony's acquisitionport documentation says it already uses a random source port per request by default, while Microsoft's documentation says the W32Time client "can only use UDP 123 as the source port".

Secure configuration, with defender-side check commands

Every command below comes from the official documentation of the implementation, linked in the sources. Only run them against systems you own or are authorised to test.

Step 1: decide what each host should be

Most hosts are leaf clients: outbound UDP to a few servers and nothing listening on port 123. A few hosts are internal time servers that answer mode 3 only from your own networks. Very few need symmetric peering, broadcast or remote control access, and every mode you do not need is one you can turn off.

On Linux, check whether anything is listening for NTP or chrony monitoring traffic. The ss manual page documents -u for UDP sockets, -l for listening sockets, -n for numeric output and -p for the owning process:

ss -u -l -n -p

Look for port 123 and port 323. On a leaf client running chrony, port 123 should not appear at all, and 323 should be bound only to 127.0.0.1 and ::1.

Step 2: harden chrony

The chrony 4.9 chrony.conf documentation describes these defaults and directives:

• allow: by default "no clients are allowed access, i.e. chronyd operates purely as an NTP client." Add allow only for the subnets that should get time from this host.
• port 0: chronyd "will never open the server port and will operate strictly in a client-only mode." This is the clearest setting for a leaf host.
• bindcmdaddress and cmdallow: by default the monitoring socket binds to 127.0.0.1 and ::1, which "blocks all access except from localhost." cmdport 0 disables the UDP command port entirely; configuration commands still go over the Unix domain socket.
• ratelimit: limits responses per client address (default interval 3, one response per 8 seconds, burst 8); leak keeps some responses flowing so a forged victim address cannot be fully blocked.
• minsources: the minimum number of selectable sources that must agree before the clock is updated. The default is 1; raising it means "the clock will not be updated when only one source (which could be serving incorrect time) is reachable."
• maxchange rejects large offsets after the first update (documented example maxchange 1000 1 2), and makestep 0.1 3 allows a clock step only in the first three updates.
• nts on a server or pool line enables NTS, and ntsserverkey and ntsservercert turn a chronyd host into an NTS server; the key file "should not be readable by other users."
• keyfile holds symmetric keys, including AES128 and AES256 types.

A leaf client configuration built from those directives might look like this:

# /etc/chrony/chrony.conf on a leaf client
server time1.example.net iburst nts
server time2.example.net iburst nts
server time3.example.net iburst nts
server time4.example.net iburst nts
minsources 2
makestep 0.1 3
maxchange 1000 1 2
port 0
cmdport 0

And an internal server that serves one subnet:

# /etc/chrony/chrony.conf on an internal time server
server time1.example.net iburst nts
server time2.example.net iburst nts
server time3.example.net iburst nts
server time4.example.net iburst nts
allow 192.0.2.0/24
ratelimit interval 1 burst 16
ntsserverkey /etc/chrony/nts.key
ntsservercert /etc/chrony/nts.crt

chronyd -p prints the effective configuration, including included files, and exits.

Step 3: verify chrony with chronyc

chronyc -n sources -v
chronyc sourcestats
chronyc tracking
chronyc authdata
chronyc ntpdata
chronyc serverstats

What to look for, using the field meanings from the chronyc 4.9 documentation:

• sources: ^ is a server, = a peer, # a local reference clock. A * marks the selected source and + sources combined with it. An x means chronyd "thinks is a falseticker", inconsistent with the majority. Reach is an octal register; 377 means the last eight polls all got valid replies. If you see only one usable source, you do not meet RFC 8633's four source guidance.
• tracking: the current reference ID and stratum, the offset of the system clock, root delay and dispersion, and the leap status. A reference ID of 7F7F0101 with no name means the host is serving its own local clock, not real time.
• authdata: one line per source with the mode, where NTS means Network Time Security, SK a symmetric key and - that "authentication is disabled". With NTS, Cook below 8 or Atmp above 1 points to a network or server problem.
• ntpdata shows each source's port, version, mode and stratum; serverstats counts received and dropped NTP packets, NTS-KE connections and authenticated packets on a server.

Step 4: harden and verify ntpd

The ntp.org access control page describes the restrict flags, notably noquery (deny ntpq and ntpdc queries; time service unaffected), nomodify (deny run time reconfiguration), notrap (decline the mode 6 trap service), nopeer (deny packets that might mobilise an association unless authenticated), limited with kod (rate limit and send KoD to violators), and ignore (deny everything). The documentation warns that the default entry otherwise has no flags, meaning "everything besides your own NTP server is unrestricted." CISA's 2014 alert recommends this default for servers that cannot be upgraded:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

Note that nopeer also blocks pool associations, so a pool directive needs a restrict source line without nopeer.

To check an ntpd host from the host itself, the ntpq documentation describes -p (list peers and their state), -n (numeric addresses) and -c to run an interactive command such as rv (read variables) for association 0, the system variables:

ntpq -p -n
ntpq -c "rv 0"

In ntpq -p output, the t column shows the association type (u unicast or manycast client, b broadcast client, p pool, s symmetric peer, l local reference clock), and reach, delay, offset and jitter give the health of each source. An s or b entry you did not configure deserves an explanation, and from an outside host you control, ntpq queries to your public server should get no answer once noquery is set.

For keys, the ntp.org authentication page documents keys and trustedkey; use a non MD5 key type, per RFC 8573.

Step 5: check Windows Time

Microsoft's Windows Time service documentation lists the w32tm /query options /source, /configuration, /peers and /status, plus /stripchart to compare against a target:

w32tm /query /status /verbose
w32tm /query /source
w32tm /query /peers
w32tm /query /configuration
w32tm /stripchart /computer:time1.example.net /samples:5 /dataonly

/status shows stratum, root delay and dispersion, reference ID, last sync and source; /configuration shows whether the NtpServer provider is enabled. Microsoft notes the client and server can be enabled independently but share UDP 123, so keep NtpServer off on machines that should not serve time.

Step 6: restrict exposure at the network edge

• Allow inbound UDP 123 only to the hosts that serve time, and only from the networks they serve.
• Block mode 6 and mode 7 queries from outside, either through daemon configuration as above or by not exposing management at all.
• If you run NTS, open TCP 4460 to the NTS-KE server and keep its certificate current.
• Do not filter on NTP extension fields; RFC 7822 forbids it and it will break NTS.

Step 7: keep the daemon itself current

Patch the daemon through your distribution or vendor, and rebuild container images that bundle it.

NTP vs NTS vs PTP: when to use which

PTP, the Precision Time Protocol, is defined by IEEE 1588. The current base edition is IEEE 1588-2019, board approved on 7 November 2019 and published on 16 June 2020, and the IEEE page describes it as enabling synchronisation "in the sub-microsecond range". IANA registers ports 319 (PTP event) and 320 (PTP general) for it, and the IEEE page notes it applies to networks "including Ethernet".

A sensible default is client/server NTP with NTS where servers support it, four or more diverse sources and a small internal server tier. PTP is a specialist choice where sub-microsecond sync matters and you control the network. Symmetric and broadcast NTP are legacy choices that need keys and trusted networks.

Common mistakes

• Treating NTP as "just UDP 123". A host answering mode 6 or 7 to the internet is a reflector and an information leak.
• Leaving the ntpd default restriction empty. The ntp.org documentation is clear that the default entry allows everything unless you add flags.
• One or two time sources. One cannot be checked and two cannot be arbitrated; use four diverse sources.
• Assuming a MAC means correct time. RFC 5905 notes that "authentication in the context of NTP does not necessarily imply the time is correct", and RFC 8633 notes delay attacks work even through encryption.
• Still using MD5 keys or Autokey. RFC 8573 deprecated MD5 for NTP and RFC 8633 says Autokey should not be used.
• Accepting symmetric or broadcast associations from anyone. Use nopeer, keys and trusted networks.
• Ignoring the panic threshold on every restart.
• Firewalls that filter on extension fields or that block NTS-KE. Both quietly break authenticated time.
• Forgetting embedded devices and containers, where outdated NTP code tends to live longest.

FAQ

What port does NTP use?

UDP port 123. IANA also registers TCP 123 for NTP, but the protocol runs over UDP. NTS key establishment uses TCP port 4460, and chrony's local monitoring channel uses UDP 323 bound to localhost.

Is NTP encrypted?

No. Plain NTP has no encryption and, unless configured, no authentication. Symmetric keys add a MAC but not encryption, and RFC 8633 notes the time payload "is not considered to be confidential". NTS adds strong authentication for client/server mode, but the time values themselves are still visible on the wire.

What is the difference between NTP and SNTP?

SNTP is a subset of NTP for clients with a single server and no dependents, and for primary servers with one reference clock. It uses the same packet format and is interoperable, but skips the filtering, selection and discipline algorithms, so it cannot detect a bad source.

What are the NTP modes?

The 3 bit mode field holds 1 symmetric active, 2 symmetric passive, 3 client, 4 server, 5 broadcast, 6 NTP control message and 7 reserved for private use. Clients send mode 3 and servers reply with mode 4.

What is NTP monlist and why is it dangerous?

A monitoring command in older ntpd that returned up to 600 recent client addresses, abused for reflection per CISA's January 2014 alert on CVE-2013-5211. ntpd 4.2.7 disables it, and noquery blocks it on older versions.

How do I check NTP synchronisation on Linux?

With chrony, run chronyc sources -v and chronyc tracking; with ntpd, run ntpq -p. On systems you own, also run ss -u -l -n -p to see whether the host is listening on port 123 when it should not be.

How do I check NTP on Windows?

Run w32tm /query /status /verbose for the current source, stratum and last sync, w32tm /query /peers for configured peers and w32tm /query /configuration for provider settings.

NTP vs PTP: which is more accurate?

PTP under IEEE 1588-2019 targets sub-microsecond synchronisation on networks built for it. NTP reaches tens of microseconds on a fast LAN and milliseconds across the internet, without special hardware.

Does NTS replace NTP?

No. NTS (RFC 8915) adds a TLS 1.3 key establishment on TCP 4460 and then authenticates ordinary NTPv4 packets with extension fields; see the NTS explainer.

Where Safeguard fits

Safeguard does not configure, monitor or filter NTP traffic, and it does not tell you whether your clocks are correct. Nothing in the hardening steps above depends on it. The honest connection is the software that implements NTP and NTS.

chrony and ntpd ship in OS packages, images and appliances, and NTS depends on a TLS library. Safeguard's container visibility and scanning, generally available as part of its software supply chain management, shows which images carry which daemon and library versions. Software composition analysis, generally available, builds a full transitive dependency inventory of the libraries in your own applications, including TLS implementations, and SBOM generation and analysis, also generally available, records that inventory in SPDX or CycloneDX so you can answer "where do we ship this version" quickly. Vulnerability management with EPSS and KEV enrichment and reachability analysis, both generally available, help you decide which findings to fix first, and policies and gates, generally available, can stop a build that pulls in a known vulnerable version. See using SBOMs to find affected products fast.

Fix it without waiting for upstream

Most NTP vulnerabilities are bugs in a daemon or library rather than in the protocol, and the fix arrives through your distribution, your appliance vendor or the image you rebuild. The parts you build and ship yourself, including container images that bundle a time daemon and the TLS libraries NTS relies on, are where you can act today.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not time synchronisation or network monitoring. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at an image that bundles a time daemon or TLS library, the scan lists its packages, versions and known vulnerabilities, so you know which images to rebuild.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and push nothing. The same flow applies to bumping a TLS library in a service you build.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification, June 2010
• RFC Editor errata for RFC 5905, including erratum 3126
• RFC 1305: Network Time Protocol (Version 3), March 1992
• RFC 4330: Simple Network Time Protocol (SNTP) Version 4, January 2006
• RFC 5906: Network Time Protocol Version 4: Autokey Specification, June 2010
• RFC 5907: Definitions of Managed Objects for NTPv4
• RFC 5908: Network Time Protocol (NTP) Server Option for DHCPv6, June 2010
• RFC 7822: Network Time Protocol Version 4 (NTPv4) Extension Fields, March 2016
• RFC 8573: Message Authentication Code for the Network Time Protocol, June 2019
• RFC 8633: Network Time Protocol Best Current Practices (BCP 223), July 2019
• RFC 8915: Network Time Security for the Network Time Protocol, September 2020
• RFC 9109: Network Time Protocol Version 4: Port Randomization, August 2021
• RFC 4120: The Kerberos Network Authentication Service (V5), July 2005
• RFC 6238: TOTP: Time-Based One-Time Password Algorithm, May 2011
• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• IANA: Service Name and Transport Protocol Port Number Registry
• IEEE SA: IEEE 1588-2019, Standard for a Precision Clock Synchronization Protocol
• NIST: Internet Time Service (ITS)
• CISA: NTP Amplification Attacks Using CVE-2013-5211, 13 January 2014
• chrony documentation index
• chrony 4.9: chrony.conf(5)
• chrony 4.9: chronyc(1)
• chrony 4.9: chronyd(8)
• chrony FAQ
• ntp.org: Access Control Commands and Options (4.2.8 series)
• ntp.org: ntpq, standard NTP query program (4.2.8 series)
• ntp.org: Authentication Commands and Options (4.2.8 series)
• ntp.org: ntpd, Network Time Protocol daemon (4.2.8 series)
• Network Time Foundation download archive
• Microsoft Learn: Windows Time service tools and settings
• ss(8), Linux manual page

Last reviewed: 23 October 2026. Daemon versions and defaults change between releases; check the documentation for the chrony, ntpd or Windows build you actually run.