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

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Fri Jan 10 02:10:00 UTC 2014

On 2014-01-08 21:24, Harlan Stenn wrote:
> William Unruh writes:
>> On 2014-01-09, A C <agcarver+ntp at acarver.net> wrote:
>>> http://arstechnica.com/security/2014/01/dos-attacks-that-took-down-big-game
>> -sites-abused-webs-time-synch-protocol/
>>> Here's a live amplification attack at work.
>> ....
>>>> As I wrote in another post I believe the time is ripe for a sensible
>>>> default builtin configuration, which can then be overridden with ntp.conf.
>>>> You suggestion in your previous message is very similar to what I
>>>> wanted, i.e. the default is to have a pure client using the pool.
>>>> As soon as you start writing detailed ntp.conf options I want you to
>>>> have the ability to shoot yourself in the foot, if that is your wish.
>> But this sounds like it is shooting someone else in the foot. That is
>> more serious. Ie, the default is that you should have to work quite hard
>> to enable the system to run these amplification attacks (I assume that
>> this is using the control system to send control/info packets, rather
>> than ntp time protocol packets)
> I'm not seeing any new information here.
> For DECADES people did not take malicious advantage of things like this.
> Now some folks are.
> The root problem is not an issue for ntp-4.2.7, and there is a simple
> solution for earlier versions.
> How about we limit discussion on this thread to actual new information?

This looks like valuable configuration/operation advice easily found by searches,
which is not easily found on NTF, NTP, Pool, or other time server sites, or these
problems would not be occurring, and these discussions would not be required.

Given this attack is now active in the wild, it would be good to see prominent
notices on the above support sites linking to advice on how to deal with this threat:
upgrading to dev releases, where that is possible, or defensive measure for older
releases, where orgs can not upgrade from distro or vendor supported releases
because of software support policies.

Could you perhaps have someone state the simple solution for earlier versions
on the NTP support site where it can be easily found, and link to it here?
Future discussions could then be truncated by providing that link.

Saying upgrade, authenticate, or RTFM could lead to drastic responses like
firewall blocking by ISPs and orgs, because of financial and liability risks
to individuals and orgs currently allowing these services, with consequent
reductions of public and pool server availability, and higher loads on those
well known sources still accessible.

Take care. Thanks, Brian Inglis

More information about the questions mailing list