NIST NTP servers
eric.kuhnke at gmail.com
Wed May 11 04:18:34 UTC 2016
For quite some time, in debian the default configuration for the ntpd.conf
that ships with the package for the ntpd is to poll from four different,
semi-randomly assigned DNS pool based sources. I believe the same is true
In the event that one out of four sources is wildly wrong the ntpd will
If people have routers/networking equipment inside their network that only
supports retrieving ntp from one IP address (or hostname) and have manually
configured it to request time from a single external source, not their own
internal ntpd that is <10ms away, bad things could definitely happen.
It is worthwhile to have both polling from external sources via IP as well
as GPS sync. Many locations in a network have no hope of getting a GPS
signal or putting an antenna with a clear view to the sky, but may be on a
network segment that is <4ms away from many other nodes where you can
colocate a 1U box and GPS antenna.
On Tue, May 10, 2016 at 9:05 PM, Joe Klein <jsklein at gmail.com> wrote:
> Is this group aware of the incident with tock.usno.navy.mil &
> tick.usno.navy.mil on November 19. 2012 2107 UTC, when the systems lost 12
> years for the period of one hour, then return?
> The reasons were not fully explained, but the impact was global. Routers,
> switches, power grids, phone systems, certificates, encryption, Kerberos,
> logging and any tightly coupled transaction systems were impacted.
> So I began doing 'security research' on the topic (don't confuse me with
> joe hacker), and discovered both interesting and terrifying issues, which I
> will not disclose on an open forum.
> Needless to say, my suggestions are:
> 1. Configure a trusted time source and good time stratum architecture for
> your organization.
> 2. When identifying your source of time, the majority of the technologies
> can be DDOS'ed, spoofed or MITM, so consider using redundant sources and
> 3. For distribution of time information inside your organization, ensure
> your critical systems (Encryption, PKI, transactions, etc) are using your
> redundant sources and authentication.
> 4. Operating systems, programming languages, libraries, and applications
> are sensitive to time changes and can fail in unexpected ways. Test them
> before it's too late.
> 5. Disallow internal system to seek NTP from other sources beyond your edge
> 6. All core time systems should be monitored by your security team or SOC.
> One question, is this a topic anyone would find interested at a future
> NANOG? Something like "Hacking and Defending time?".
> Joe Klein
> "Inveniam viam aut faciam"
> PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8
> On Tue, May 10, 2016 at 9:59 PM, Mel Beckman <mel at beckman.org> wrote:
> > 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
> > behind a firewall. Every ntp response lists the current reference ntp
> > server in the next higher stratum. There are many ways that process could
> > harvest all ntp servers over time, and then pass the public IP back to a
> > mother ship controller. It could be going on right now.
> > My point is, when the fix is so cheap, why put up with this risk at all?
> > -mel beckman
> > > On May 10, 2016, at 5:18 PM, Chris Adams <cma at cmadams.net> wrote:
> > >
> > > Once upon a time, Mel Beckman <mel at beckman.org> said:
> > >> Boss: So how did a hacker get in and crash our accounting server,
> > our VPNs, and kill our network performance?
> > >>
> > >> IT guy: He changed our clocks.
> > >
> > > So, this has been repeated several times (with how bad things will go
> > > your clocks get changed by years). It isn't that easy.
> > >
> > > 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.
> > >
> > > Second, he'd have to guess at least three to "win".
> > >
> > > 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
> > > or Jan 1, 1970 mentioned in this thread.
> > >
> > > 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.
> > > --
> > > Chris Adams <cma at cmadams.net>
More information about the NANOG