[ntp:questions] better rate limiting against amplification attacks?

Charles Elliott elliott.ch at verizon.net
Sat Dec 28 14:39:33 UTC 2013

I looked up "amplification attack."  Such an attack occurs when an attacker
can send a small UDP packet with a spoofed source address and elicit a many
times larger response sent to the spoofed source.  Doesn't that describe
NTPD almost perfectly, considering what ntpdc and ntpq can do?  But the same
website that defined amplification attack also described the solution: Use

Is not that just one more reason to switch ntpd, nptq, and ntpdc from UDP to
TCP for query processing?

Charles Elliott

-----Original Message-----
From: questions-bounces+elliott.ch=verizon.net at lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon.net at lists.ntp.org] On Behalf Of
Sent: Friday, December 27, 2013 11:50 AM
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] better rate limiting against amplification

Brian Utterback <brian.utterback at oracle.com> wrote:
> On 12/27/2013 5:24 AM, Rob wrote:
>> What is the NTP developers position on implementation of better rate 
>> limiting options in ntpd?
>> There are more and more amplification attacks against ntp servers, 
>> similar to those against open DNS resolvers.  A small packet sent 
>> with a spoofed source address (allowed by a lame ISP) results in a 
>> large reply from ntpd, sent to the victim of the attack.
>> Possible candidates are of course the commands to retrieve the list 
>> of clients (similar to "ntpdc -c monlist") and and the list of 
>> associated servers ("ntpq -p").
> In the current code monlist is replaced by mrulist. The mrulist 
> command requires a handshake, so a spoofed address would not be possible.
> However, it might be wise to limit the number of packets sent per 
> exchange. Currently the client sets the number but a man in the middle 
> attack would still be possible. We could set the maximum number of 
> packets sent per return packet to relatively small. The current 
> implementation on the client sets it to 32, but we could allow a 
> maximum of 4 or 8.
> Is a peer list really a big problem? It generally doesn't make sense 
> to have much beyond 10 peers. Are there really a lot of servers with a 
> lot of peers?
> Brian Utterback

Are you doubting the fact that NTP is used for amplification attacks?
It is a fact...  and many ntp pool members have faced the consequences

I think what has to be discussed is the countermeasures, not the fact.

questions mailing list
questions at lists.ntp.org

More information about the questions mailing list