NTP Amplification Attacks

An NTP amplification attack is a reflection DDoS attack in which an attacker sends small, spoofed queries to public Network Time Protocol servers, and those servers send far larger replies to the victim. US-CERT lists a bandwidth amplification factor of 556.9 for the NTP monlist command, which is why a modest pool of senders can produce floods above 100 Gbps. This guide covers how the attack works, how it compares with other UDP reflection attacks, what real incidents revealed, how to spot it on port 123, and how to stop it. The first fix most teams reach for is also the one that quietly breaks their own clocks.

Key Takeaways

• An NTP amplification attack forges the victim’s IP address in small queries to open NTP servers, which then flood the victim with much larger UDP responses from source port 123.
• The legacy monlist command (CVE-2013-5211) returns up to 600 recent client addresses, which gives NTP a listed bandwidth amplification factor of 556.9.
• About 1.4 million NTP servers answered monlist queries on January 10, 2014; by April 18, 2014 the count had fallen to 106,445, a 92% drop.
• NTP reflection is still active: NETSCOUT ASERT reported more than 45,000 DDoS alerts involving NTP reflectors between January and early November 2025.
• Victims cannot patch their way out of an NTP amplification DDoS; the flood has to be filtered upstream, before it saturates the link.
• Server owners stop being reflectors by blocking mode 6 and mode 7 queries from outside, adding noquery restrictions, and running ntpd 4.2.7p26 or later, chrony, or NTPsec.

What Is an NTP Amplification Attack?

An NTP amplification attack is a volumetric, reflection-based DDoS attack that turns publicly reachable Network Time Protocol servers into traffic multipliers aimed at a single target. The attacker never sends the flood directly; third-party time servers do it for them.

NTP runs over UDP port 123 and keeps clocks synchronized on servers, routers, and endpoints. UDP has no handshake, so an NTP server has no way to confirm that a request really came from the address in its source field. The attacker writes the victim’s IP address into that field, sends a small query, and the server delivers a much bigger answer to the victim.

Think of it as mailing hundreds of catalog request cards with someone else’s home address written as the return address. Each card costs a stamp. Each reply is a heavy catalog, and every one of them lands in the same mailbox.

The attack belongs to the family of volumetric DDoS attacks, which win by filling bandwidth rather than by exhausting application logic. That changes the defense math. When 100 Gbps arrives at a 10 Gbps uplink, nothing running on the server can help, which is why teams facing reflection floods rely on an upstream DDoS protection service with more capacity than the attack. Rules on a cloud firewall work for the same reason: they sit in front of the congested link, not behind it.

Why NTP Became a Favorite Reflection Vector

• Huge population. About 1.4 million NTP servers answered monlist queries on January 10, 2014, according to the University of Michigan and Merit Network study presented at ACM IMC 2014.
• Oversized answers. A single monlist reply can list up to 600 recent client addresses, spread across as many as 100 UDP packets.
• Trusted port. Firewalls often allow UDP 123 because every system needs accurate time, so the flood passes rules that block less familiar ports.
• Spoofing still works. Networks that skip BCP 38 ingress filtering (RFC 2827) let packets with forged source addresses leave their borders.

Knowing what the attack is only helps once you see the moving parts, and they all trace back to one old debugging command.

How Does an NTP Amplification DDoS Attack Work?

An NTP amplification DDoS attack works in five moves: find open NTP servers, forge the victim’s address, send queries at scale, let each server multiply the traffic, and let the replies converge on one target.

1. Scan for amplifiers. Attackers sweep the IPv4 address space for hosts on UDP 123 that answer mode 7 monlist queries. It is the same check defenders run with Nmap’s ntp-monlist script.
2. Spoof the source. Every query carries the victim’s IP address as its source, so every reply heads to the victim instead of the sender.
3. Send from many machines. Queries usually come from infrastructure behind botnet DDoS attacks or from rented booter services, which spreads the spoofed load across many senders.
4. Amplify. Each server answers with up to 600 client entries, split across as many as 100 packets, for a single small request.
5. Converge and saturate. Thousands of servers answer at once. The victim’s upstream link fills with UDP from source port 123, and legitimate traffic starts dropping.

The monlist Command Behind CVE-2013-5211

monlist is a mode 7 (private) diagnostic query in the reference ntpd implementation that returns the last 600 hosts that talked to the server. The National Vulnerability Database records CVE-2013-5211 against ntpd versions before 4.2.7p26, describing forged REQ_MON_GETLIST and REQ_MON_GETLIST_1 requests that cause traffic amplification “as exploited in the wild in December 2013.” The entry carries a CVSS v2 base score of 5.0.

Administrators can confirm whether one of their own servers still answers the query with two standard commands:

Mode 6 Queries and the Risk That Remains

Here is what most people miss: disabling monlist did not make it safe to expose ntpd’s control interface. Mode 6 control queries such as readvar still return responses larger than the request, just with a lower multiplier. That is why RFC 8633, the IETF’s NTP Best Current Practices document, recommends blocking control queries from outside the organization entirely. The newer mrulist command in ntpd uses a nonce exchange, which defeats spoofed requests because the attacker never sees the nonce.

With the mechanics clear, the next question is scale: how much traffic can one small query really turn into?

How Much Traffic Can NTP Amplification Generate?

On paper, a lot. US-CERT alert TA14-017A lists NTP’s bandwidth amplification factor at 556.9, meaning each byte an attacker sends can return about 557 bytes to the victim.

Among the protocols in the same alert, only memcached exceeds that multiplier, and only CharGEN comes close. For comparison, a classic DNS amplification attack tops out at a factor of 54, roughly one tenth of NTP’s multiplier.

Yes, the 556.9 figure is real, but it describes a server with a full monlist table. When researchers measured the actual amplifier population in early 2014, the median server returned only about 4 times the bytes it received. The danger sat in a small tail: six “mega amplifiers” returned more than 1 GB in response to a single probe, and one returned 136 GB.

The practical lesson is that the worst reflectors are a handful of misconfigured machines, not the average one. A few of those can outproduce thousands of typical servers, which is why removing even a small number of open amplifiers makes a measurable difference.

Size is only one way to classify this attack. The next section shows how it differs from other UDP floods and reflection attacks that look similar on a traffic graph.

NTP Reflection Attack vs Other UDP Reflection and Flood Attacks

An NTP reflection attack is one member of the UDP amplification family. It differs from a plain UDP flood in who sends the packets, and from DNS or ICMP reflection in the size of the multiplier and the port the traffic arrives from.

A UDP flood attack comes straight from attacker-controlled machines with no multiplier at all. A Smurf attack is the older ICMP ancestor of reflection, bouncing echo requests off broadcast networks. A carpet bomb DDoS attack often uses the same reflection vectors but spreads the flood across an entire IP prefix so no single address crosses a detection threshold.

Every amplification attack is a reflection attack, but not every reflection attack amplifies. The distinction matters in practice. NETSCOUT ASERT noted in November 2025 that the number of NTP-involved DDoS alerts it saw was out of proportion to the few thousand abusable NTP servers still online, and suggested that some of that traffic may be direct-path floods that simply use port 123. A defense keyed only on monlist response sizes would miss those.

Tables and factors are abstract until real networks go down, and NTP has a well-documented history of doing exactly that.

Real NTP Amplification DDoS Attacks and What They Showed

NTP amplification became a mainstream threat between December 2013 and February 2014, when monlist-based floods took down major gaming platforms and pushed reflection attacks past 100 Gbps.

• Gaming outages, late December 2013 to January 2014. A group calling itself DERP disrupted League of Legends, EA, and Battle.net, and reports at the time described NTP-driven floods of up to 100 Gbps against gaming servers.
• Government warnings. US-CERT published alert TA14-013A on January 13, 2014, advising operators to upgrade ntpd to at least 4.2.7 or disable monlist.
• Dominance at the high end. In the first quarter of 2014, 85% of attacks larger than 100 Gbps used NTP reflection, according to the ACM IMC 2014 paper on NTP DDoS attacks.
• Victim count. The same study counted 437,000 unique victim IP addresses across 184 countries and estimated about 1.2 petabytes of NTP attack traffic over 15 weeks.
• Research networks were hit too. An attack measured at Front Range GigaPoP (Colorado State University) on February 10, 2014 reached about 3 Gbps, showing that mid-sized reflection floods also landed on research and education networks.

An NTP amplification attack “relies on the use of publically accessible NTP servers to overwhelm a victim system with UDP traffic.”

The Cleanup That Worked, and the Pool That Stayed

Coordinated remediation worked unusually fast. Across the scans in the IMC 2014 study on the rise and decline of NTP DDoS attacks, open monlist amplifiers fell from about 1.4 million on January 10, 2014, to 106,445 on April 18, 2014, a 92% reduction in roughly three and a half months.

The pool never reached zero, though. NETSCOUT ASERT reported more than 45,000 DDoS alerts with NTP reflectors involved between January and early November 2025. Old servers, forgotten appliances, and embedded devices keep answering, which means NTP reflection remains a live vector for anyone running internet-facing services.

If the vector is still active, the next practical question is how you would know it is hitting you.

How to Detect an NTP Amplification Attack on Your Network

Look for a sudden surge of inbound UDP traffic with source port 123 that your systems never requested, arriving from thousands of different NTP servers at once.

Detection starts at the flow level rather than on the server, because the server is often the last component to notice. These are the indicators that separate an NTP reflection flood from normal time sync and from the general signs of a DDoS attack:

• Source port 123 dominates inbound UDP, while your own outbound NTP queries stay flat. Replies with no matching requests are the core signature of reflection.
• Packets are far larger than normal NTP. Standard client and server NTP packets carry a fixed 48-byte UDP payload. A monlist reply packet is about 468 bytes on the wire.
• Source diversity is extreme. Traffic arrives from thousands of unique IP addresses, most of them in networks you never exchange time with.
• Destination ports look random or popular. In the IMC 2014 data, UDP port 80 was the most targeted destination at 36.2% of victim traffic, even though no web server listens on UDP 80.
• The uplink saturates before CPUs spike. Interface utilization hits its ceiling while server load stays normal, which points to a volumetric problem upstream.

Two quick checks help confirm what flow dashboards suggest:

Detection buys you minutes. What you do with those minutes decides whether the service stays online.

How to Stop an NTP Amplification DDoS Attack

Stop an NTP amplification DDoS attack by dropping or rate-limiting UDP source port 123 traffic as far upstream as possible, then relying on filtering capacity larger than the flood itself.

Filter UDP Source Port 123 at the Edge

Allow NTP replies only from the specific upstream time servers you use, then drop or limit everything else arriving from port 123. Size-based rules help too, since normal NTP payloads are 48 bytes. Applying rate limiting per source catches leftover traffic without touching legitimate sync.

One caveat: Network Time Security (NTS, RFC 8915) adds extension fields that make packets larger than 48 bytes, so set length thresholds after checking your own traffic.

Push Filters Upstream With BGP FlowSpec

Host and edge rules fail once the link itself is full. BGP FlowSpec (RFC 8955) lets you signal a match such as “UDP, source port 123, packet length above 200” to your upstream provider, which then drops that traffic at its own edge before it crosses your transit link.

Use Blackhole Routing Only as a Last Resort

Remotely triggered blackhole routing drops all traffic to the attacked IP address, good and bad alike. It protects the rest of the network, but it also completes the attacker’s goal for that address, so treat it as an emergency brake rather than a strategy.

Absorb the Flood on a Distributed Network

The durable answer is capacity plus distribution. Anycast scrubbing networks split a reflection flood across many points of presence, so each location handles a fraction of the total and drops port 123 junk close to its source. The 85% share of 100 Gbps+ attacks that used NTP in early 2014 shows why this matters: few single sites can absorb that much. Our guide to DDoS mitigation techniques covers how these layers fit together.

Defending against incoming floods is half the job. The other half is making sure your own servers are not part of someone else’s attack.

NTP Server Security: How to Keep Your Servers From Becoming Reflectors

Disable mode 7 and remote control queries, restrict who can query your server, and run a modern NTP implementation. Those three steps remove a server from every attacker’s amplifier list.

1. Upgrade or replace ntpd. ntpd 4.2.7p26 and later disable monlist by default. chrony binds its command port to localhost by default, and NTPsec removed mode 7 support entirely.
2. Restrict queries in ntp.conf. Add noquery to the default restrict lines so the server keeps serving time but refuses status and control requests.
3. Block mode 6 and mode 7 at the network edge for any traffic that originates outside your organization, as RFC 8633 recommends.
4. Implement BCP 38. Source address validation on your own network stops your hosts from sending spoofed packets in the first place.
5. Scan yourself on a schedule. Run the ntp-monlist check against every public address you own, and subscribe to the free Shadowserver Foundation reports that flag accessible NTP services on your networks.

“It is RECOMMENDED that public-facing NTP servers block NTP control message queries from outside their organization.”

Even teams that follow this checklist tend to repeat a few predictable mistakes, and those are worth naming directly.

Common Mistakes in NTP DDoS Protection

Most failed defenses against NTP amplification come from four assumptions: that blocking the port is free, that patching ended the threat, that on-site hardware is enough, and that small organizations are not targets.

Blocking All UDP Port 123 Traffic

You might be thinking the simplest fix is to drop port 123 everywhere. That breaks your own time sync, and clock drift breaks more than logs. Kerberos rejects authentication when clocks differ by more than 5 minutes under its default settings, and TLS certificate validation depends on an accurate system clock. Allow your chosen time sources and filter the rest.

Assuming Patched Servers Mean the Problem Is Gone

The 92% cleanup in 2014 is often quoted as the end of NTP amplification. NETSCOUT’s 45,000+ NTP-involved alerts in 2025 say otherwise. The residual pool is small, but a few mega amplifiers are enough to hurt a target.

Relying on On-Premises Appliances Alone

An appliance behind a 10 Gbps link cannot drop traffic that never fits through the link. On-premises filtering is useful for cleanup, but the bulk of a reflection flood must be removed upstream.

Believing Small Networks Are Not Targets

You might be thinking your organization is too small to attract a 100 Gbps attack. The IMC 2014 data counted 437,000 unique victims, and at least 10 of the most targeted ports belonged to games such as Xbox Live, Minecraft, and PlayStation services. That pattern points to individual players and game servers as frequent targets, not only large enterprises.

Each of these mistakes shares one root cause: treating NTP amplification as a server problem when it is a network capacity problem.

Final Thought on NTP Amplification Attacks

NTP amplification attacks succeed because two old design choices meet: UDP accepts forged source addresses, and legacy NTP servers answer small queries with large replies. The monlist cleanup of 2014 proved that coordinated hardening works, yet thousands of reflectors still answer today, so the threat has shrunk without disappearing.

The most reliable defense is to split the job in two. Harden every NTP server you run so it cannot be used as an amplifier, and make sure incoming floods are filtered upstream, before they reach the link they are trying to fill. Keep legitimate time sync working throughout, because a defense that breaks your clocks creates its own outage.

Common Questions About NTP Amplification Attacks