On 2014-01-08 21:24, Harlan Stenn wrote:
William Unruh writes:
On 2014-01-09, A C agcarver+...@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
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
