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

Brian Utterback brian.utterback at oracle.com
Fri Dec 27 14:17:41 UTC 2013

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

More information about the questions mailing list