On this page
Key points
- Separate time and control trafficOrdinary client/server time exchange and administrative queries do not serve the same purpose.
- Verify the actual implementationHistorical monlist behavior is not a description of every current NTP server.
- Check synchronization after filteringA reachable application does not prove that the host still has working time sources.
Reflection uses a forged source address
An NTP reflector replies to the source address in a request. If that address was forged, a target unrelated to the time service can receive the replies. Amplification occurs when the response is larger than the triggering request; the exact traffic pattern depends on the implementation, query and configuration.
The historical monlist abuse affected older ntpd behavior. It should not be presented as a feature enabled on every current NTP deployment. Identify the implementation and supported release in use: ntpd, NTPsec and chronyd are not interchangeable configuration targets.
NTP reflection path
- Forged request
The source address points at the victim.
- Exposed time server
An allowed query produces a response.
- Victim’s ingress
Replies consume link and packet-processing capacity.
Time synchronization and control queries are different
In the usual client/server exchange, NTP mode 3 is a client request and mode 4 a server reply. Mode 6 is used for control messages; mode 7 is a private, implementation-specific category associated with older tooling. Do not classify every packet from UDP source port 123 as the same operation.
A machine that does not serve time publicly may still need inbound replies from its configured time sources. Filtering every UDP/123 packet can therefore break synchronization while appearing to solve a traffic spike. Capture the expected peers and the normal communication pattern before choosing exceptions.
Build an incident view that includes direction
Locate the bottleneck
Compare provider-facing, tunnel and server counters with loss and service failures. A downstream capture cannot measure traffic already discarded upstream. Keep bandwidth and packet-processing pressure as separate observations.
Inspect the packet context
Record source and destination ports, NTP mode where decodable, destination role and packet sizes. Replies commonly come from source port 123; looking only at destination port 123 can miss replies to a client’s other local port.
Check what your host actually requested
Compare authorized time peers and recent client activity. Missing requests in a sampled or one-way observation are not conclusive evidence of reflection. The network path may be asymmetric, and flow records need not include the NTP mode.
Measure legitimate operations
Check application transactions and the time daemon’s synchronization health. Monitor offset and source reachability over a suitable interval; the system clock may not show an immediate error when replies first stop.
Restrict control access without disabling time service
Keep the time daemon on a supported release and limit administrative queries to the intended management audience. Public time service and public remote control are different requirements. Apply the rules appropriate to the actual daemon, including IPv4 and IPv6 exposure.
For the documented ntpd 4.2.8 access controls, noquery denies ntpq/ntpdc queries without denying the time service. nomodify alone still permits read-only queries. These are explanations of those flags, not a complete configuration to paste into a different implementation.
Review the effective access list and test from an authorized management host and a normal time client. Preserve required peers, pool behavior and monitoring. Schedule any restart or reload according to your operational procedure; weakening authentication or disabling all monitoring is not an appropriate shortcut.
Place victim-side filtering before the exhausted resource
If reflection fills the customer handoff, filtering behind that handoff cannot recover its lost capacity. Work with the upstream network on a destination-scoped, verified pattern. If bandwidth remains available and the pressure is local, a suitable local rule can still protect host resources.
Preserve expected time replies and unrelated UDP traffic. A source-port rule does not inspect every fragment or prove a response is unsolicited. Confirm the receiving device’s match semantics, allowed exceptions, rate-limit behavior and rule withdrawal before relying on it.
If traffic is diverted through a protected path, validate the routing and clean delivery as well as the rule. Adding encapsulation does not supply extra receiving capacity. Keep an owner for both the temporary filtering policy and the return to normal routing.
Example: a game server that is also an NTP client
A game server may expose no public time service while its operating system synchronizes with remote peers. During a suspected reflection incident, a blanket UDP/123 block can remove the unwanted replies and the required time replies together. This is an illustrative failure mode, not a report of a measured customer incident.
The acceptance test must therefore include player connections, normal traffic on the protected path and time-source reachability. Record the selected peer, synchronization state and offset after filtering, then after emergency-rule withdrawal. A successful ping is insufficient for either application or clock validation.
Mistakes that hide an incomplete recovery
- Treating historical monlist amplification as the behavior of every modern time daemon.
- Confusing source and destination ports or assuming every response targets local port 123.
- Applying another daemon’s configuration syntax without checking its version and access model.
- Declaring recovery from a smaller attack graph while time synchronization remains broken.
- Leaving a broad emergency rule in place after the attack without retesting legitimate traffic.
Questions and answers
Can reflection target a host that does not provide NTP?
Yes. Replies can be sent toward its forged address. That host may nevertheless require legitimate NTP replies as a client.
Does noquery disable clock synchronization?
In the referenced ntpd 4.2.8 access controls, it restricts administrative queries rather than the time service. Other rules and implementations must be checked separately.
What demonstrates that mitigation worked?
A reduced unwanted load, recovered legitimate transactions, acceptable loss and functioning time sources on the actual delivery path. No single port counter establishes all of these.
