DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

The time server answers control queries: locking down NTP mode 6

#ntp #network #hardening

The time server answers control queries: locking down NTP mode 6

A host that runs ntpd or chrony answers two kinds of traffic. One is the timestamp exchange that clients need. The other is a management protocol that nobody remembers enabling, and it usually arrives from the same unauthenticated network path. If your time infrastructure sits in a management VLAN that is reachable from user subnets, that second channel is worth a look this week.

What the control channel actually is

NTP has a mode field in every packet header. Client-server time exchange uses modes 3 and 4. Mode 6 carries control and monitoring queries, and mode 7 carries the older private queries implemented by some vendors. The daemon answers mode 6 queries such as readvar, peers and, on older releases, monlist.
On a server without access restrictions, a single UDP packet returns a list of every host that recently synchronised. That list is an inventory of your network, produced by a device whose job is to hand out time. The same query surface exposes stratum, reference clock, uptime and the addresses of configured peers.
The query does not require a shared secret. In practice it requires nothing beyond a routable path to port 123, which is why the restriction rules matter more than the version number.

Check what your daemon exposes

For ntpd, ask the daemon itself. From a host that can reach the server:

ntpq -n -c readvar 203.0.113.10
ntpq -n -c peers    203.0.113.10
Enter fullscreen mode Exit fullscreen mode

If the daemon answers without restrict rules in place, those commands work from anywhere the port is open. A refusal such as Connection refused or a timeout is the expected result on a correctly restricted server.
For chrony, the equivalent surface is configured rather than implicit. cmdport 0 disables the command interface entirely, and bindcmdaddress 127.0.0.1 limits it to loopback. Check both in chrony.conf and confirm the running service matches the file.

The restriction line that does the work

NTP access control is expressed as a set of restrict statements evaluated most-specific first. A baseline that keeps time serving working while shutting the control surface looks like this:

restrict default kod nomodify notrap nopeer noquery limited
restrict 127.0.0.1
restrict ::1
restrict 10.20.30.0 mask 255.255.255.0 nomodify notrap nopeer
Enter fullscreen mode Exit fullscreen mode

noquery is the flag that blocks mode 6 and mode 7 queries from the matched range. nomodify stops runtime reconfiguration through the same interface. nopeer prevents an unknown host from forming an association and using the server as a peer. limited applies a rate limit to hosts that exceed the packet threshold.
The order matters. A broad noquery default with a narrower allow line for the monitoring host is the shape you want, not the reverse. Writing the allow line first and the restrictive default afterwards produces a server that appears locked down in review and answers queries in production.

What an exposed server is worth to an attacker

The direct value is reconnaissance, and reconnaissance is cheap. A single query returns the address space that trusts this server, which is a shortlist of internal subnets and their naming conventions. Query responses also confirm which hosts are alive without sending traffic to each one individually.
The second value is reflection. A forged source address turns the query into an amplifier, and the victim receives the response. Historic amplification abuse led vendors to remove the largest response, monlist, from later ntpd releases and to ship restrictive defaults. Servers built from old images, appliances frozen at an old firmware level, and containers assembled by hand still answer the wide queries.
The third value is integrity. If nomodify is missing and the query interface is reachable, a host with a shared key may be able to push configuration changes. Verifying that path is a legitimate reason to test your own server, and it is also the reason the check belongs on a schedule rather than in a one-off audit.

A verification sequence that produces evidence

  1. From an unauthorised network segment, run ntpq -c readvar against each time server and record the output. A timeout or refusal is the passing result.
  2. From the authorised monitoring host, run the same command and confirm the daemon still answers, so you know the restriction did not break legitimate monitoring.
  3. Confirm UDP 123 is not reachable from the internet with a packet capture at the border, rather than relying on firewall rule review.
  4. Compare the running configuration to the file on disk. Appliances with a web console often keep a separate copy of access rules.
  5. Record the daemon version and whether the vendor backported the noquery default. The fourth item catches the common failure. Someone adds the restriction to a template, the template is applied to new builds, and the fleet of older servers never receives it.

Where the check belongs in the change process

Time infrastructure rarely changes, which is exactly why its configuration drifts out of review. Add the access-rule check to the same review that covers DNS resolvers and management interfaces: a short list of services that answer unauthorised queries and hold a map of the network.
The payoff is modest but reliable. You remove an inventory leak, you close a reflection path, and you keep the timestamp exchange that everything else depends on. If the check also turns up an appliance whose console cannot express noquery, that is a procurement note for the next refresh cycle.

References

Top comments (0)