What Is an NTP Amplification Attack? | Monlist Abuse and Defense

An NTP amplification attack is a reflection-based DDoS technique that abuses the Network Time Protocol’s monlist command — a diagnostic feature of older NTP server implementations — combined with IP spoofing to send small forged queries to NTP servers, which respond with disproportionately large data sets sent directly to a spoofed victim, producing amplification factors historically as high as ~556x.

TL;DR: NTP amplification exploits the monlist command in NTP daemon versions prior to 4.2.7, which returns a list of up to the last 600 clients that queried the server. An 8-byte spoofed request can trigger a response of up to roughly 4,460 bytes per NTP packet, split across multiple response packets that together reach amplification factors around 200x–556x. The 2014 wave of NTP amplification attacks, which reached 400+ Gbps against some targets, was one of the largest DDoS campaigns of its era. Mitigation is straightforward: disable monlist (default since ntp-4.2.7p26), restrict query access with restrict noquery, and apply BCP38 upstream to prevent spoofing at the source.

Last updated: 2026-08-27

NTP amplification surged into prominence in early 2014, when a wave of attacks using the technique produced some of the largest volumetric DDoS attacks recorded up to that point — including a widely reported attack exceeding 400 Gbps against a CDN customer, and numerous attacks in the 100–300 Gbps range against gaming, hosting, and financial targets. US-CERT issued Alert TA14-013A in January 2014 specifically addressing NTP amplification, and the incident drove rapid, coordinated patching of exposed NTP servers across the internet. Despite that response, NTP amplification remains relevant today because a meaningful population of unpatched or unhardened NTP servers persists, and open, misconfigured NTP infrastructure continues to be periodically re-scanned and re-weaponized by attackers.

How NTP Amplification Works

NTP (Network Time Protocol) runs over UDP port 123 and is used to synchronize clocks across networked systems. The monlist command, formally the MON_GETLIST request in NTP’s mode 7 (private/control mode), was a diagnostic feature that asked an NTP server to return a list of the last clients that had communicated with it — intended to help administrators debug and monitor server usage.

Step 1: Attacker sends a small, spoofed monlist request to an open NTP server
Attacker → NTP Server: MON_GETLIST request (~8 bytes, src IP = victim's IP)

Step 2: The NTP server looks up its recent client history and responds
NTP Server → Victim: MON_GETLIST response(s)
  [Each response packet lists up to 6 client records, ~468 bytes per packet;
   an active server may need multiple packets to return up to 600 records]

Step 3: The attacker repeats via many open NTP servers simultaneously
1,000 servers × steady query rate × ~4,460 bytes aggregate response per query
  = large volumetric flood converging on the victim

Attacker's own bandwidth used: 1,000 × 8 bytes per query (negligible)
Amplification: response bytes / query bytes ≈ 200x–556x depending on server
  history size and response fragmentation

The amplification factor is unusually high for two reasons: the query itself is extremely small (a bare 8-byte request with no payload beyond the command), and a busy NTP server can accumulate up to 600 client records in its monitoring buffer — meaning a single query can trigger dozens of maximum-size UDP response packets in sequence, not just one.

Why UDP and Connectionless Design Enable the Attack

Like DNS, SSDP, and CLDAP, NTP runs over UDP, which requires no handshake to establish a session before data is exchanged. The server processes and responds to whatever source IP address the request claims, with no verification step. Combined with IP spoofing, this means the NTP server never learns it is being used as a reflector — from its perspective, it is answering a legitimate diagnostic query from what appears to be a normal client.

Amplification Factor Comparison

NTP’s monlist-based amplification factor is among the highest of the “classic” reflection vectors, second historically only to Memcached, which was discovered and abused later, in 2018. NTP’s combination of a trivially small query and a large, multi-packet response made it especially attractive to attackers building large-scale volumetric campaigns cheaply.

The 2014 NTP Amplification Wave

Public incident reporting from early 2014 documented a sharp spike in NTP amplification attacks, driven largely by the wide availability of scanning tools and lists cataloging NTP servers with monlist still enabled. Attacks in this period reached peak volumes exceeding 400 Gbps against some targets — among the largest DDoS volumes publicly documented up to that time — and drove a rapid community response: NTP pool operators, hosting providers, and OS distributions pushed patches and configuration guidance to disable monlist by default. NTP daemon version 4.2.7p26, released in response, disabled monlist by default going forward, and this default has persisted in subsequent releases.

Detection Signals

# Inspect for NTP mode 7 (monlist-style) traffic on the wire
tcpdump -n 'udp port 123' -v

# Check whether your own NTP server responds to a monlist-style query (from an authorized test host)
ntpdc -c monlist <ntp-server-ip>

# Correlate NetFlow for UDP/123 responses without matching outbound queries
nfdump -r flows.nf 'proto udp and src port 123' -o extended

If ntpdc -c monlist against your own server returns a client list, the server is exposed and should be hardened immediately (see below). Running this command against a server you do not control or administer, purely to test exposure, should only be done with explicit authorization, since even a diagnostic query contributes trivially to a target’s request volume and legal considerations vary by jurisdiction.

Mitigation Techniques

Disable monlist on NTP servers

The single most direct fix. NTP daemon versions 4.2.7p26 and later disable monlist by default; administrators running older versions should either upgrade or explicitly disable the mode 7 private/control interface:

# In ntp.conf, explicitly disable monitoring and mode 7 queries:
disable monitor

# Alternative / complementary restriction:
restrict default noquery nomodify notrap nopeer
restrict -6 default noquery nomodify notrap nopeer

Restrict query access with restrict noquery

Even where monlist itself is disabled, restricting who may issue any NTP control/query request (as opposed to legitimate time-sync requests) reduces the server’s exposure as a reflector for any future diagnostic-command vulnerabilities:

restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1

Migrate to modern time-sync implementations

Modern implementations such as chrony do not implement the legacy mode 7 monlist interface at all, removing the vulnerable surface entirely rather than requiring it to be explicitly disabled. Many current Linux distributions default to chrony over the classic ntpd for this and other reasons.

BCP38 / Ingress Filtering (RFC 2827)

Because NTP amplification depends entirely on IP spoofing, BCP38 (RFC 2827) ingress filtering at the attacker’s network would prevent the spoofed query from ever reaching the NTP reflector. As with all reflection attacks, this defense must be applied upstream by networks that originate traffic — a victim organization cannot enforce it directly.

Rate limiting and response correlation

Network operators can rate-limit inbound UDP/123 traffic and correlate incoming NTP responses against previously sent outbound queries, discarding unsolicited responses without blocking legitimate time synchronization entirely.

Upstream scrubbing and distributed absorption

Because amplified NTP floods can exceed a target’s own uplink capacity by orders of magnitude, absorption typically needs to happen upstream — at a scrubbing provider or distributed network with sufficient aggregate capacity. See Blackhole Routing vs. Scrubbing for a comparison of approaches.

Common Mistakes

How to Implement on Azion

Azion’s distributed network can help absorb and filter NTP-amplification traffic before it reaches an origin, while server-side hardening against being used as a reflector remains the responsibility of whoever operates the NTP service itself:

• DDoS Protection provides always-on detection and mitigation for volumetric UDP traffic, including amplified NTP floods, absorbing it across Azion’s distributed infrastructure rather than at your origin.
• Network Shield can apply network-level rules to identify and filter anomalous UDP/123 traffic patterns consistent with NTP reflection, depending on configuration.
• Firewall enables custom rules for rate limiting and protocol-based filtering at the network layer.
• WAAP combines network and application-layer protections for organizations facing multi-vector campaigns that pair volumetric amplification with application-layer abuse.

If your own infrastructure runs an NTP service, hardening it against monlist abuse (disabling the legacy mode 7 interface, applying restrict noquery, or migrating to chrony) is a configuration task independent of any edge or DDoS protection provider, since it addresses whether your server can be weaponized against others rather than whether your applications are protected from incoming attacks.

Related Resources

• What Is a DDoS Attack?
• DDoS Attack Types
• What Is IP Spoofing?
• What Is DNS Amplification?
• Azion DDoS Protection

Frequently Asked Questions

What is an NTP amplification attack? An NTP amplification attack sends a small, spoofed query — typically the monlist command — to an open NTP server, which responds with a much larger data set sent directly to the spoofed victim address instead of the attacker. This lets an attacker generate volumetric traffic against a victim far exceeding their own bandwidth.

What is the monlist command? Monlist, formally the MON_GETLIST request in NTP’s mode 7 private/control protocol, is a diagnostic feature that asks an NTP server to return a list of up to the last 600 clients that communicated with it. It was intended for legitimate server monitoring but became the primary vector for NTP amplification because its response is disproportionately large compared to the request.

What is the maximum amplification factor for NTP amplification? Publicly documented amplification factors for NTP monlist attacks range from roughly 200x up to approximately 556x, depending on how many client records a given server had accumulated and how the response was fragmented across multiple UDP packets. This makes NTP one of the highest-amplification classic reflection vectors, behind only Memcached.

Is NTP amplification still a threat in 2026? The threat is reduced but not eliminated. NTP daemon versions since 4.2.7p26 (released in response to the 2014 wave) disable monlist by default, and modern implementations like chrony do not implement the vulnerable interface at all. However, unpatched legacy systems, embedded devices, and misconfigured appliances continue to expose monlist-enabled NTP servers that periodic internet-wide scans continue to find and catalog.

How do I check if my NTP server is vulnerable to monlist abuse? Run ntpdc -c monlist <your-server-ip> from an authorized test host against your own server. If it returns a list of recent clients, the server is exposed and should be hardened immediately by disabling monitor mode, applying restrict noquery, upgrading to a patched ntpd version, or migrating to chrony.

Can a firewall stop an NTP amplification attack against me? A firewall can filter or rate-limit inbound UDP/123 traffic once it arrives, and can correlate responses against previously sent outbound queries to discard unsolicited ones. It cannot prevent the attack from being generated — that requires the NTP servers being abused as reflectors to be hardened, which is outside the victim’s control unless the victim also happens to operate NTP infrastructure.

How does NTP amplification differ from DNS amplification? Both are UDP-based reflection attacks that depend on IP spoofing, but NTP amplification specifically exploits the legacy monlist diagnostic command, which historically produced a higher amplification factor (up to ~556x) than typical DNS amplification (~28x–70x). DNS amplification abuses open resolvers answering standard DNS queries, while NTP amplification abuses a specific, now largely disabled, diagnostic feature.

Does disabling monlist eliminate all NTP-based DDoS risk? Disabling monlist removes the primary and most severe NTP amplification vector, but administrators should still apply restrict noquery broadly and keep NTP software current, since other NTP control-mode requests or future vulnerabilities in the protocol implementation could theoretically be abused similarly if the diagnostic/control interface remains open to arbitrary sources.

What role does IP spoofing play in NTP amplification? IP spoofing is the mechanism that redirects the NTP server’s response to the victim instead of the attacker. Without spoofing, the amplified monlist response would return to whoever actually sent the query — the attacker — providing no benefit against a third party. See What Is IP Spoofing? for the underlying technique.

Can NTP amplification attacks be mitigated without BCP38 adoption by every network? Yes, partially. Server-side hardening (disabling monlist, restricting query access) removes individual servers from the pool of usable reflectors regardless of whether the attacker’s network filters spoofed traffic. Upstream scrubbing and distributed absorption capacity can handle volumetric floods that do occur. BCP38 remains the only fix that prevents the spoofing itself at the source, but it is not the only layer of defense available.

Sources:

• US-CERT. “Alert TA14-013A: NTP Amplification Attacks Using CVE-2013-5211.” January 2014.
• IETF. “Network Time Protocol Version 4: Protocol and Algorithms Specification.” RFC 5905. 2010.
• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP38). 2000.
• NTP.org. “NTP Security Notice: Vulnerabilities in ntpd prior to 4.2.7p26 (monlist).” 2014.
• CISA. “UDP-Based Amplification Attacks.”
• NIST SP 800-94. “Guide to Intrusion Detection and Prevention Systems (IDPS).”