Brian Utterback <brian.utterb...@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.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
