Skip to content
AxonOps Documentation

AxonOps — AI-Native Control Plane for Open Source Data Platforms

Cassandra Time Synchronization Security

The Network Time Protocol (NTP) as normally deployed is unauthenticated User Datagram Protocol (UDP). A client accepts a reply that appears to come from its configured server, and an attacker able to spoof or intercept those replies can move the client’s clock. For a Cassandra cluster this is a data-integrity attack rather than a nuisance, because conflicting writes are resolved by comparing timestamps taken from those clocks, as How Cassandra uses time describes: moving a node’s clock forward makes its writes and tombstones shadow everything else in the cluster, and moving it backward makes its writes and deletes silently ineffective. Neither produces an error. Clock skew failure modes describes what the resulting data looks like.

The controls that follow from this:

  • Minimize exposure. Only the internal NTP tier should reach external time sources. Cassandra nodes and client application hosts should be restricted at the firewall to UDP 123 toward the internal tier only. The rule must permit both directions, because the reply arrives as an inbound UDP datagram; a rule that allows only egress leaves sources permanently unreachable, which appears as ^? in chronyc sources.
  • Permit tier-to-tier traffic where tiers peer. Symmetric peering between the tier members in one datacenter, and any optional cross-check peering between the tiers of different datacenters, both require UDP 123 to be open between those specific hosts in both directions across the datacenter boundary. This is a rule between named NTP servers, not a general cross-datacenter allowance, and it must not be widened to the Cassandra nodes.
  • Do not run an open NTP server. Internal tier servers must serve only the cluster and application networks. chronyd serves nothing unless an allow directive is present, so the risk there is a allow all misconfiguration. ntpd has historically been abused for reflection and amplification attacks through its monlist query (CVE-2013-5211); an ntpd tier must be configured with restrict default noquery nomodify notrap nopeer and explicit restrict lines for the permitted networks.
  • Authenticate where policy requires it. chrony supports symmetric key authentication: the tier and its clients share a key file (keyfile /etc/chrony.keys), and each server line names the key to use (server ntp1.internal.example.com iburst key 1). Keys must be distributed and rotated as secrets, and a strong hash (SHA-256 or better, subject to the chrony build’s crypto support) should be chosen over MD5.
  • Prefer Network Time Security for external sources. NTS (RFC 8915) is supported by chrony 4.0 and later. It performs a TLS handshake with the time server to establish keys, then authenticates the NTP packets themselves, which prevents an attacker from forging or modifying them. It is enabled per source with the nts option:
# On an internal NTP tier server, for an authenticated external reference
server time.cloudflare.com iburst nts
ntsdumpdir /var/lib/chrony

NTS validates the server’s TLS certificate, which requires the client’s clock to be approximately correct at the first handshake. A machine with no usable clock at boot may therefore need one unauthenticated source, or a correct hardware clock, to bootstrap. Where an internal tier is not feasible, public NTS-enabled servers are a better external choice than unauthenticated public pools.

Section titled “Related pages”