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

Brian Utterback brian.utterback at oracle.com
Thu Jan 16 00:37:34 UTC 2014

On 1/15/2014 7:18 PM, Greg Troxel wrote:
> [invalid William has been trimmed from the cc list]
> Harlan Stenn <stenn at ntp.org> writes:
>> William Unruh writes:
>>> I do not mean the default in the config file, I mean the default if
>>> there is no config file or if nothing is set in the config file.
>> Then ntpd won't connect to anything and there will be no data to report.
> This is a ridiculous strawman.   The ntp project is abdicating its
> responsibility to provide sane default behavior by claiming that no
> default behavior can make everyone happy and therefore it's not their
> fault.  The notion that OS packagers somehow have a better idea of usage
> is also specious.
> Really, ntpd should, when run with a config file of only
>    server 0.pool.ntp.org
>    server 1.pool.ntp.org
>    server 2.pool.ntp.org
> behave relatively sanely, including declining to respond to packets that
> could be amplification attacks, while being usable as a s2/s3 to other
> nearby nodes.  This notion of good behavior under minimal config seems
> really obvious to me, yet there is a huge resistance to it, with the
> notion that every end user should invest the time to be an expert.
> And, as far as I can tell, seems to be as simple as 'restrict noquery'
> as a compiled-in default before any restrict statements are given.  Yet
> that does not happen.

By default, the dev branch software doesn't respond to mode 7 packets 
and even if mode 7 packets are enabled it still doesn't respond to 
monlist requests. So, if it is as simple as you say, then you've got 
your wish already.

Brian Utterback

More information about the questions mailing list