NTP Reflection Amplification Attack Principles and Defense: Shut Down Amplifiers in 4 Steps

NTP reflection amplification attack principles and defense can be summarized in one sentence: the amplification happens on older ntpd versions that expose the monlist, and defense must be two-pronged—if you are a potential amplifier, immediately self-check and disable monlist; if you are a victim, accept that an origin firewall cannot save your ingress bandwidth, and move the mitigation to high-capacity edge nodes. The 2026 NETSCOUT threat report again lists UDP reflection amplification as a primary driver of high-volume network-layer DDoS attacks, with NTP being one of the easiest to self-diagnose and fix.

Principle Breakdown: How a Small Request Gets Amplified into a Large Traffic Flood to the Victim

The root of NTP reflection amplification lies in UDP's connectionless nature and spoofable source IP, combined with the monlist (Mode 7) management query enabled by default on older ntpd. An attacker spoofs the victim's IP and sends a small query to an NTP server with monlist enabled. The server responds with a list of the most recent up to 600 client IPs that have synchronized time, split into packets sent to the spoofed source IP. CERT/CC in VU#348126 explicitly notes that this single-packet amplification factor is commonly over 200, and some instructions have theoretical amplification factors in the thousands. CISA's 2014 advisory for CVE-2013-5211 named this mechanism. Attackers don't need to control a botnet; they just need to scan enough open NTP servers to create attack firepower.

What the Attack Traffic Looks Like: Identifying Features of Source Port, Packet Length, and Traffic Curve

If you are under an NTP reflection attack, traffic monitoring typically shows several features: a large number of inbound UDP packets with source port 123, packet lengths that are variable but mostly constant-length response fragments, bandwidth saturated within a second, but connection count barely moving. Many describe this as "bandwidth maxed out but connection count unchanged," which is typical of UDP reflection. Because UDP is connectionless, attack traffic doesn't go through the three-way handshake, so the TCP connection count in ss -s won't rise significantly, while the inbound/outbound bandwidth curve in ifconfig or cloud monitoring will flatten instantly.

Step 1: Determine Whether You Are the Victim or a Reflector

First, look at the traffic direction: if your bandwidth is consumed by inbound traffic and the source port is 123, you are the victim; if your ISP or peers complain about a large volume of outbound UDP 123 traffic, you are a reflector. To check if you are an open reflector, use a single command:

ntpdc -n -c monlist <你的服务器IP>

If it returns a list of client hosts, monlist is open and you are at risk; if it times out or indicates no data, monlist is not open or has been disabled. Note that ntpdc is provided by the main ntp package (sometimes ntp-utils on certain distributions); if the command is not found, install the corresponding package. If your system uses chrony, the monlist interface does not exist, and you can confirm via an external scan whether 123/udp responds to queries.

Step 2: Disable Amplification Capability — How to Close NTP monlist

Whether you are a victim or just want to avoid being used as a pawn, follow these three steps to shut down the amplifier. This is the standard answer to "how to disable NTP monlist":

1. Upgrade ntpd to version 4.2.7p26 or later; newer versions disable monlist by default.
2. Edit /etc/ntp.conf and add the following to the configuration:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
disable monitor

noquery will block all query-type commands (including monlist), and disable monitor completely disables monlist statistics.

3. Restart the ntpd service and re-check. The restart command varies by system:

systemctl restart ntpd    # RHEL/CentOS 系
systemctl restart ntp     # Debian/Ubuntu 系

For re-checking, run ntpdc -n -c monlist <你的服务器IP> from another external host; it is effective only if it returns "timed out" or "No data". Avoid verifying only from the local loopback.

Step 3: Should You Block UDP 123? Trade-offs on the Port Side

Operations often ask, "Should we block UDP port 123?" A blanket block will prevent your system from synchronizing time, causing clock drift and disrupting authentication and log timelines. A more reasonable approach: allow only upstream trusted NTP servers to query you, or allow only your own outbound connections to port 123, and set all inbound queries to noquery. But remember, origin firewall drops cannot solve the problem of the ingress link being saturated—the traffic saturates your ISP uplink before it reaches your firewall, so dropping packets later doesn't help. This point is especially critical when discussing UDP Flood Defense. To truly withstand reflection peaks, you need edge capacity.

Step 4: Move Mitigation to the Edge, Keep Origin as a Fallback

The final piece of NTP reflection amplification defense lies in link capacity. Why is it too late for iptables drops at the origin? Because reflection traffic converges on your physical data center ingress, saturating the uplink within seconds, and packets are dropped by the switch before reaching your server. The solution is to push the ingress outward: use Anycast to broadcast the same IP set from multiple geographic locations, so traffic is absorbed near the attack source. For specific routing mechanisms, refer to BGP Anycast in DDoS Scrubbing. At the origin, only keep access control, minimal exposure, and time service restricted to trusted sources.

Checklist for Other Reflection Sources Beyond NTP

NTP reflection amplification defense extends beyond NTP; services like NTP, DNS, and CLDAP can all be abused over UDP. The mitigation principle is the same: respond only to necessary queries, disable management commands, and restrict sources. Here's a self-check list:

Also note the traffic difference between NTP reflection and DNS reflection attacks: NTP amplification comes from a single management query returning a fixed-length client list (regular packets, source port always 123), while DNS amplification has a variable response size (source port 53, wide response length range). Thus, monitoring shows one as "regular fixed-length fragment flood" and the other as "large packets with scattered lengths." The defense for both is edge scrubbing plus origin hardening. For DNS-specific scenarios, see DNS Attack Protection.

RockCloud Edge Scrubbing and Global Nodes in UDP Reflection Scenarios

When your data center link is flooded by a multi-hundred-Gbps NTP reflection stream, the first step in DDoS Emergency Response is to divert traffic to edge nodes with high-capacity scrubbing. By moving the mitigation point forward, the origin's physical bandwidth is no longer the only absorbing surface. The actual capacity you can handle depends on the distribution of access nodes and business bandwidth planning, and must be evaluated through real-world tests. RockCloud's high-defense CDN and Anycast global network distributes and absorbs UDP reflection traffic across multiple nodes, scrubs illegal monlist responses at the edge, hides the origin IP, and reduces the chance of the origin being directly targeted.

FAQ

How large is the NTP amplification factor?

Single-packet amplification is commonly over 200 times. CERT/CC in VU#348126 notes that some NTP instructions have theoretical bandwidth amplification factors in the thousands. This means a modest number of requests can generate a return traffic volume far exceeding the attacker's own bandwidth, so they don't need a massive botnet.

Does disabling monlist affect client time synchronization?

No. monlist is a management query command; normal client time sync uses the NTP protocol itself, unrelated to monlist. Disabling monlist only stops exposing the list of recently synchronized client IPs; time sync remains fully functional.

My ISP notified me that my server is an NTP reflection source. How should I write the remediation report?

First, confirm and disable monlist using the commands in this article, and include the before-and-after configuration comparison and re-check results. Then state that you upgraded ntpd, added noquery and disable monitor, and record the ISP notification time and remediation completion time.

Can a single-host firewall withstand an NTP reflection attack?

No. Reflection traffic saturates the data center ingress bandwidth before reaching your server; the firewall only sees an increased packet drop rate due to congestion. The correct approach is to divert traffic to large-bandwidth edge nodes for scrubbing, with the origin keeping only basic access control. This is the core conclusion of NTP reflection amplification defense.