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
monlistcommand 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: disablemonlist(default since ntp-4.2.7p26), restrict query access withrestrict 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 serverAttacker → NTP Server: MON_GETLIST request (~8 bytes, src IP = victim's IP)
Step 2: The NTP server looks up its recent client history and respondsNTP 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 simultaneously1,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 fragmentationThe 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
| Protocol | Query Size | Typical Max Response | Amplification Factor |
|---|---|---|---|
| NTP (monlist) | ~8 bytes | Up to ~4,460 bytes (multi-packet) | ~200x–556x |
| DNS (ANY/EDNS0) | ~60 bytes | ~4,000 bytes | ~28x–70x |
| CLDAP | ~52 bytes | ~1,068 bytes | ~56x–70x |
| SSDP | ~110 bytes | ~750 bytes | ~7x–30x |
| Memcached | ~15 bytes | Up to ~134 MB | Up to ~50,000x |
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
| Signal | What to observe | Tool |
|---|---|---|
| Inbound UDP/123 traffic with no matching outbound NTP query | Response-sized NTP packets arriving without the victim having sent a corresponding time-sync request | NetFlow/IPFIX, sFlow |
| High volume of ~468-byte UDP packets from source port 123 | Packet size consistent with monlist response fragments | Packet capture, tcpdump -n udp port 123 |
| Source IP diversity across many distinct NTP servers | Attack traffic converging from numerous unrelated NTP server IPs simultaneously | Flow analysis |
| Sudden bandwidth saturation with UDP/123 as dominant protocol | Uplink or interface utilization spike attributable overwhelmingly to port 123 traffic | SNMP/RMON, interface counters |
# Inspect for NTP mode 7 (monlist-style) traffic on the wiretcpdump -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 queriesnfdump -r flows.nf 'proto udp and src port 123' -o extendedIf 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 nopeerrestrict -6 default noquery nomodify notrap nopeerRestrict 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 noqueryrestrict 127.0.0.1restrict ::1Migrate 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
| Mistake | Impact | Correct solution |
|---|---|---|
| Assuming monlist is disabled by default on all deployed NTP servers | Many long-lived, unpatched, or embedded NTP implementations (routers, IoT devices, appliances) still ship with monlist enabled or outdated ntpd versions | Explicitly audit and test exposure with ntpdc -c monlist against your own infrastructure; do not assume patching status |
| Blocking all inbound UDP/123 as an incident response | Blocks legitimate time synchronization for the organization’s own systems, which can cause certificate validation failures, log timestamp drift, and Kerberos authentication issues | Use response correlation and rate limiting rather than a blanket protocol block |
| Treating NTP hardening as a one-time task | New devices, appliances, and legacy systems are continually added to networks, some shipping with vulnerable default NTP configurations | Include NTP configuration review in routine infrastructure audits and asset onboarding checklists |
| Relying solely on the victim-side firewall to stop amplified floods | Amplified NTP traffic can exceed the victim’s own uplink capacity before any on-premise device gets a chance to filter it | Combine server-side hardening (prevent your own servers from being reflectors) with upstream absorption capacity for traffic directed at you |
| Ignoring embedded/IoT devices running bundled NTP daemons | Consumer routers and IoT devices sometimes bundle outdated NTP implementations with monlist enabled, contributing to the pool of internet-wide reflectors | Ensure embedded device firmware is updated and audit default NTP configurations exposed to the public internet |
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).”