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

Brian Utterback brian.utterback at oracle.com
Fri Dec 27 17:47:04 UTC 2013


On 12/27/2013 11:49 AM, Rob wrote:
> 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
> already.
>
> I think what has to be discussed is the countermeasures, not the fact.
>
>

Not at all. I am asking the parameters of the attack. Is the current 
software solution sufficient to stop such attacks? If so, then the 
solution is for the servers to upgrade. Indeed, no solution we craft for 
the current software development will help sites that do not upgrade.

So, if the current software is subject to attack, is the attack always 
via mrulist or does the peer command also cause a problem? If it is 
mrulist only, then scaling back the maximum packets should make it a 
less attractive vector. Indeed, you could easily make the amplification 
dynamic, scaling back to one or two packets per exchange when the rate 
is high.

If peers are a problem too, then a more general solution might be in 
order, such as the rate limit you mentioned. Unfortunately, the exchange 
is specific to mrulist. Perhaps an uprev of the protocol so that an 
exchnage is always required. I think I outlined a scheme such as that 
earlier.

Brian Utterback


More information about the questions mailing list