NIST NTP servers

Scott Whyte swhyte at
Wed May 11 15:24:28 UTC 2016

On 5/10/16 21:05, Joe Klein wrote:
> Is this group aware of the incident with &
> 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
> authentication.
> 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
> routers.
I believe this will become a stronger need over time, and apply to more 
than NTP:
> 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> 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 once
>> 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> wrote:
>>> Once upon a time, Mel Beckman <mel at> said:
>>>> Boss: So how did a hacker get in and crash our accounting server, break
>> 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 if
>>> 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 future
>>> 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>

More information about the NANOG mailing list