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