NIST NTP servers

Scott Whyte swhyte at gmail.com
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 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
> 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: 
http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/
> 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 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 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, 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 cmadams.net>




More information about the NANOG mailing list