Seven best practices to keep your NTP resilient
When NTP, which synchronizes network clocks, gets off-kilter, DNS and other network disruptions follow. Keep your NTP in shape with BlueCat’s expert tips.
Read moreNetwork Time Protocol (NTP) is a network protocol that synchronizes computer system clocks across networked devices using hierarchical time sources and timestamped message exchanges, as specified in RFC 5905. Accurate time is critical for incident investigation, security functions like TLS certificate validation and Kerberos authentication, and operational reliability, as clock drift can cause authentication failures and audit evidence corruption. Organizations should implement NTP security best practices including multiple trusted internal time sources, firewall restrictions on UDP port 123, authentication mechanisms, and monitoring to prevent drift and protect against reflection attacks and clock spoofing.
NTP clients estimate how far their local clock differs from one or more reference servers, then gradually adjust the clock. Servers are organized into levels called strata, where stratum 1 servers connect directly to a reference clock such as GPS.
The exchange repeats continuously, and the polling interval lengthens as the clock stabilizes. NTP does not authenticate servers by default, so optional mechanisms such as symmetric keys or network time security are used where source trust matters.
An NTP daemon may refuse to correct a clock that is off by more than its panic threshold, which is 1000 seconds by default in the reference implementation. A device with a dead battery or wrong date then stays wrong until an administrator sets the time manually or starts the daemon with a step option.
Configuring only one server leaves clients with no way to detect a faulty source. If that server drifts or is wrong, every client follows it. Using several independent sources lets the selection algorithm discard an outlier.
Firewall rules that allow DNS and web traffic but drop UDP port 123 leave clients unsynchronized with no obvious error. Symptoms include a growing offset, a stratum 16 status or a peer that never becomes reachable. Check both outbound requests and return traffic through stateful devices.
A server that answers monitoring or control queries from any address can be used in reflection attacks against third parties. Restrict query and control access to trusted networks and keep the software patched.
Guests can drift or jump after a pause, snapshot restore or host migration. Running a guest NTP client alongside a hypervisor time sync feature can cause the two to fight over the clock, so choose one method deliberately.