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

Steve Kostecke kostecke at ntp.org
Sun Dec 29 02:20:01 UTC 2013

On 2013-12-28, Greg Troxel <gdt at ir.bbn.com> wrote:

> Steve Kostecke <kostecke at ntp.org> writes:
>> On 2013-12-27, detha <detha at foad.co.za> wrote:
>>> A first step would be to have a default configuration where any
>>> functionality that can be used for reflection attacks with more than a say
>>> 2:1 ratio needs to be explicitly enabled, with warnings about this in the
>>> sample config file(s).
>> The NTP Reference Implementation has no default use case. So there is no
>> "baked-in" sensible default configuration. Some view this as a feature.
> I think that's a bug.  There are in my view two default cases:

There can only be one, unless ntpd can be started with a command line
switch to chose the case.

>   setting up the local machine to synchronize from organization/local s3
>   or so servers.
>   setting up a few machines to be the above s3ish servers

The default use case (i.e. the baked-in configuration) ought to support
the lowest common denominator: a pool client. Something like this would

restrict default ignore
restrict localhost
pool pool.ntp.org
restrict source

These configuration directives should be selectively overridden by

In the case of an ntpd operating as an NTP client polling one or more
arbitrary time servers (as in your second case) it should be sufficient
to merely specify a server line, or lines, which would override the
baked-in pool directive.

In the case of an ntpd operating as an NTP server (as in your first
case) there could be a command line switch and/or ntp.conf directives to
clearly define authorized clients. e.g.


-client localnet
-client aaa.bbb.ccc.ddd/mm
-server or -client {all|global|*} to globally enable time service

conf file:

client localnet
client aaa.bbb.ccc.ddd/mm
client hostname.or.ip.address

> In both cases, there is no need to allow monlist-or-equivalent from
> other than localhost, and no real harm in answering time queries.

There are some who object to allowing there ntpd to respond to external
time polls. We see this periodically in the news-group and on irc.

If we start from the position that ntpd is by default only a client then
configuration becomes a simple matter of enabling desired functionality.

> The other significant use case is running a s1, but a) those people are
> expected to be more clueful and b) the above rules don't hurt that case
> either.

s/s1/public time server/

This usage ought to require some configuration but could still
benefit from sensible defaults.

Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/

More information about the questions mailing list