skip to content

Why were NTP mode 6 and mode 7 queries usable for amplification, and how should a company's public NTP server be hardened against it?

level: seniorimportance: should knowfreq 15%

answer

  1. small request, large reply, spoofable UDP
  2. outside RFC 5905's time exchange
  3. one implementation's recent-client list
  4. block control queries from outside
  5. serve time and nothing else

basics

~20 s

Mode 6 control and mode 7 private queries answer a small, spoofable UDP request with a much larger reply, so forged requests turn the server into an amplifier. Refuse them from outside, serve only time requests, rate-limit, and filter spoofed sources.

solid answer

~50 s

NTPv4 (RFC 5905) defines the time exchange, client mode 3 and server mode 4, whose reply is the same 48-octet header as the request. Two side channels are not like that: **mode 6 control messages**, specified in an appendix of RFC 1305 (NTPv3, obsoleted by RFC 5905) and absent from RFC 5905, and **mode 7**, which RFC 5905 only reserves for private use. One widely deployed implementation used mode 7 for monitoring commands, including one known as monlist that answered a single small request with a list of recent clients. Over UDP with a forged source address, that size ratio makes an amplifier. RFC 8633 (BCP 223) says public-facing servers should block control queries from outside the organisation, limit anything beyond basic monitoring to authenticated sessions, and keep the implementation updated; operators add BCP 38 source filtering, per-client rate limits signalled with `RATE`, and NTS, whose replies are built to be no larger than requests.

go deeper

for a junior

Recall that NTP control and private-mode queries can return far more data than they receive, and that public servers should refuse them from outside.

for a middle

Explain which NTP modes a public server needs, which RFC defines each, and why only modes 6 and 7 have a large reply-to-request ratio.

for a senior

Lay out the hardening list: block control queries externally, authenticate peers and control, rate-limit with RATE, BCP 38 filtering and monitoring signals.

for a principal

Decide whether to run a public time service at all, and how its hardening, NTS offering and DDoS absorption are owned.

## What a public time server actually needs to answer A company's public NTP server, say `time.example.com` on 203.0.113.10, exists to answer one kind of packet: a client request. Everything else NTP can carry is optional, and much of it is risky to expose. | Mode | Defined by | Purpose | On a public server | |---|---|---|---| | 3 client / 4 server | RFC 5905 | the time exchange | answer mode 3 with mode 4 | | 1 / 2 symmetric active / passive | RFC 5905 | peers syncing each other | only with configured, authenticated peers | | 5 broadcast | RFC 5905 | one-to-many on a LAN | trusted networks only | | 6 control | an appendix of RFC 1305 (NTPv3, obsoleted by RFC 5905); not in RFC 5905 | monitoring and configuration | block from outside | | 7 private | reserved for private use by RFC 5905 | implementation-specific commands | block from outside, disable if possible | ## Why mode 6 and mode 7 amplify The time exchange is balanced: the reply is the same 48-octet header as the request. RFC 8633 (BCP 223) points out that **NTP control message responses are much larger than the corresponding queries**, which makes them attractive in distributed denial-of-service attacks, since UDP lets a requester forge its source address. Mode 7 was worse in practice. RFC 5905 defines nothing for it beyond reserving the value; one widely deployed implementation used it for monitoring and configuration commands, among them the query commonly called monlist, which returned a list of the hosts that had recently contacted the server. That query and its reply size are that implementation's behaviour, not an RFC's. A server answering such queries from anyone sends a large reply to whichever address a forged request names. Exposed control queries also leak information. RFC 8633 notes that they reveal values such as the reference ID and the expected origin timestamp, which help other attacks, so hosts SHOULD answer control queries only from authorised parties. ## Hardening the server 1. **Keep the implementation current** and choose one that is actively maintained (RFC 8633), and confirm that it does not answer mode 7 queries. 2. **Block mode 6 and mode 7 queries from outside the organisation.** RFC 8633 RECOMMENDS this for public-facing servers. Allow them only from internal monitoring hosts, by access list. 3. **Require authentication for control beyond basic monitoring.** RFC 8633 says such use SHOULD be limited to authenticated sessions, and access lists can restrict it further to approved addresses. 4. **Refuse symmetric associations from strangers.** A packet in symmetric active mode can make a server mobilise a passive association with any sender; RFC 8633 says each passive association SHOULD be cryptographically authenticated, under its own key. 5. **Rate-limit per client** and signal it with a `RATE` kiss-o'-death, while being ready to drop clients that ignore it with filtering outside NTP. 6. **Filter spoofed sources at the edge.** RFC 8633 RECOMMENDS ingress and egress filtering per BCP 38, so the company's own hosts cannot be used to send forged requests. 7. **Offer Network Time Security** (RFC 8915): its key establishment runs on TCP 4460, and its NTP replies are built to be no larger than the request, padding aside. ## Watching for abuse RFC 8633 suggests the signals an operator should log: - **Replies that match no request.** If a system receives NTP replies it never asked for, someone may be forging its address in requests to that server. - **Unexpected volumes of control queries** from outside, which should be zero once blocked. - **Clients far exceeding any reasonable poll rate**, the candidates for `RATE` and filtering. ## The hosts behind the server The same discipline applies to clients. RFC 8633 says a **leaf-node host**, one that only takes time, SHOULD drop all incoming NTP except mode 4 replies from known servers, and hosts that do not serve time should filter mode 3 queries from outside. RFC 9109 adds that clients should send from a randomised ephemeral port rather than port 123, making blind off-path spoofing harder. Absorbing a flood once it arrives, with scrubbing, anycast or upstream capacity, is a separate DDoS-defence question; hardening keeps the server from being the amplifier.

  • Is blocking all NTP from the Internet a reasonable fix for a public NTP server?
    No. A public server exists to answer mode 3 requests, and their replies do not amplify. The precise fix keeps client-server time open and refuses mode 6 and mode 7 from outside, plus per-client rate limits. For hosts that only take time, blocking is right: RFC 8633 says they should drop everything except mode 4 replies from known servers.
  • How can a host tell that someone is forging its address in NTP requests elsewhere?
    RFC 8633 says replies arriving from a remote NTP server that match no request the host sent indicate that an attacker is forging its address in requests to that server. The aim may be to make the remote server rate-limit or stop serving the victim, so unexpected replies and kiss-o'-death RATE packets it did not earn are both worth logging.

saying these in an interview costs you the question

  • The monlist query is part of the NTPv4 standard in RFC 5905.
  • A public NTP server should drop all mode 3 queries from the Internet.
  • Ordinary NTP time replies are much larger than their requests.
  • Enabling NTS on its own shuts off mode 7 amplification.
  • Symmetric passive associations from any sender are harmless on a public server.