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

Martin Burnicki martin.burnicki at meinberg.de
Thu Jan 16 10:00:20 UTC 2014


Harlan Stenn wrote:
> Greg Troxel writes:
>> 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.
>
> We do supply some sample config files in the conf/ directory.
 >
> I don't know that anybody is really happy about them.

I've just looked at these in current ntp-dev and found that there are 
only config files from some test machines at udel, with very specific 
configuration options. So these are not good examples for

> I am disinclined to distribute files like that because they "stick
> around" for far too long.

I don't even believe those config files are still appropriate for 
current versions of ntpd and real configurations of current test 
machines, so I think they could simply be removed, at least from the 
published tarballs.

On the other hand, if I look at the ntp.conf files shipped e.g. with 
different Linux distros I can see that most configurations try to 
achieve the same goal, e.g. make information available via mode 6 or 
mode 7 packets only available to localhost.

As mentioned in some other post here, the task to set up a "safe" 
default configuration has to be done multiple times by different folks 
at different OS vendors.

In fact the maintenance effort for OS vendors would be much easier if 
the original NTP tarball was shipped with a "safe" configuration.

Otherwise the "safety" of a default configuration depends strongly on 
the level of knowledge the NTP package maintainer of a particular OS 
vendor has.

So if ntpd should not be shipped with a sample config file then I agree 
the default config file to be maintained by the OS vendors should be as 
simple as possible to yield a "safe" configuration, as someone else has 
already mentioned.

For example, if the default restrictions built into ntpd would be to 
allow monitoring requests only from local host then no "restrict" 
statements might be required in a simple default configuration file. OS 
vendors could just provide a file with some default servers, like it is 
actually common practice for some Linux distros.

E.g. Fedora and Debian use pool configurations like

server 0.fedora.pool.ntp.org iburst

or

server 0.debian.pool.ntp.org iburst

with current stable ntpd.


Sophisticated users who want some "extra" configuration could add some 
lines similar as they already have to do right now, e.g. if they want to 
use some specific refclock.

It should not be too hard to change ntpd such that the default 
restrictions match what most admins would set up anyway.

And 4.2.8 would be a good step for such change, similar as the default 
logging has changed from 4.2.4 to 4.2.6.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list