[189191] in North American Network Operators' Group
Re: NIST NTP servers
daemon@ATHENA.MIT.EDU (Mel Beckman)
Tue May 10 21:59:59 2016
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Chris Adams <cma@cmadams.net>
Date: Wed, 11 May 2016 01:59:55 +0000
In-Reply-To: <20160511001750.GA6228@cmadams.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
I don't pretend to know all the ways a hacker can find out what nap servers=
a company uses, but I can envision a virus that could do that once behind =
a firewall. Every ntp response lists the current reference ntp server in th=
e next higher stratum. There are many ways that process could harvest all n=
tp servers over time, and then pass the public IP back to a mother ship con=
troller. It could be going on right now.
My point is, when the fix is so cheap, why put up with this risk at all?=20
-mel beckman
> On May 10, 2016, at 5:18 PM, Chris Adams <cma@cmadams.net> wrote:
>=20
> Once upon a time, Mel Beckman <mel@beckman.org> said:
>> Boss: So how did a hacker get in and crash our accounting server, break =
our VPNs, and kill our network performance?
>>=20
>> IT guy: He changed our clocks.
>=20
> So, this has been repeated several times (with how bad things will go if
> your clocks get changed by years). It isn't that easy.
>=20
> First, out of the box, if you use the public pool servers (default
> config), you'll typically get 4 random (more or less) servers from the
> pool. There are a bunch, so Joe Random Hacker isn't going to have a
> high chance of guessing the servers your system is using.
>=20
> Second, he'd have to guess at least three to "win".
>=20
> Third, at best, he'd only be able to change your clocks a little; the
> common software won't step the clock more than IIRC 15 minutes. Yes,
> that can cause problems, but not the catastrophes of years in the future
> or Jan 1, 1970 mentioned in this thread.
>=20
> Is it possible to cause problems? Yes. Is it a practical attack? I'm
> not so sure, and I haven't seen proof to the contrary.
> --=20
> Chris Adams <cma@cmadams.net>