[ntp:questions] better rate limiting against amplification attacks?
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
More information about the questions