Skip to Content.
Sympa Menu

perfsonar-announce - Re: [perfsonar-user] Re: Information on NTP Amplification Attacks

Subject: perfSONAR Announcements

List archive

Re: [perfsonar-user] Re: Information on NTP Amplification Attacks

Chronological Thread 
  • From: Joseph Bernard <>
  • To: "" <>
  • Cc: "" <>, "" <>, perf-node-users Users <>, "" <>, perfsonar-announce <>, "" <>, " Club" <>, "" <>, Science DMZ List <>, "" <>
  • Subject: Re: [perfsonar-user] Re: Information on NTP Amplification Attacks
  • Date: Tue, 11 Feb 2014 13:44:48 +0000
  • Accept-language: en-US

As someone that had all their perfSONAR boxes, even the ones I forgot about,
used last night as part of an NTP attack, don't wait on fixing this.

Joseph B.

On Feb 11, 2014, at 8:36 AM, Jason Zurawski

> Greetings;
> As a followup to this issue, we would like to remind all users of older
> pSPT installations (e.g. 3.3.1 and below) that the latest version of the
> software is available, and has automatic fixes to address the concerns with
> NTP. We would strongly encourage everyone to upgrade as soon as possible,
> as the publicity surrounding this vulnerability is still resulting in
> attacks within the community.
> Thanks, and feel free to pass along any questions you might have to
> .
> -jason
> On Jan 9, 2014, at 10:05 AM, Jason Zurawski
> <>
> wrote:
>> Greetings;
>> Apologies if you receive duplication of this notice.
>> Some of you may be aware of a recently highlighted risk of NTP
>> amplification
>> (,
>> and in some cases others may have already had a host that was used in an
>> attack. A sample notice received may look something like this:
>>> You are running a public NTP server that participated a very large-scale
>>> attack against a customer of ours today, generating UDP responses to
>>> spoofed requests with bogus timestamps that claimed to be from the attack
>>> target. Your server was particularly active in the attack, sending a
>>> significant percentage of the attack traffic we saw.
>>> Please consider reconfiguring your NTP server in one of these ways:
>>> - To only serve your customers and not respond to outside IP addresses.
>>> If your NTP server runs as a standalone installation, setting the service
>>> to ignore all queries would work well for this. With ntpd, that can be
>>> done with "restrict default ignore" in /etc/ntp.conf; other servers
>>> should have a similar configuration option. A firewall rule to block UDP
>>> to the public IP address on port 123 would also work for this.
>>> - To rate-limit responses to individual source IP addresses
>>> - To limit queries to TCP-only
>>> - To ignore particularly unlikely queries, such as those representing
>>> dates far in the future or past
>>> - To limit the size of allowed responses
>> For those that are running perfSONAR Performance Toolkit software, the
>> development team will have an updated version out this month to restrict
>> the NTP daemon to local queries by default. In the meantime, it is
>> possible to make manual modifications to the local /'etc/ntp.conf' file to
>> accomplish the same goal:
>>> # by default act only as a basic NTP client
>>> restrict -4 default nomodify nopeer noquery notrap
>>> restrict -6 default nomodify nopeer noquery notrap
>>> # allow NTP messages from the loopback address, useful for debugging
>>> restrict
>>> restrict ::1
>> Additional restrict lines can be added to allow trusted subnets, e.g.:
>>> restrict a.b.c.d mask nomodify notrap nopeer
>> More information on protection for hosts (and routing devices) can be
>> found here:
>> Please relay any questions as they come up.
>> Thanks;
>> -jason

Archive powered by MHonArc 2.6.16.

Top of Page