Fw: NIST NTP servers

[Gary E. Miller]

Yo All!

FYI, There has been an interesting discussion of NTP on NANOG today.

The usual and expected ignorance, but a surprising number of clueful
posts as well.  See below for one of the good comments.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588


Begin forwarded message:

Date: Wed, 11 May 2016 00:05:31 -0400
From: Joe Klein <jsklein at gmail.com>
To: Mel Beckman <mel at beckman.org>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: NIST NTP servers


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.
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>  
>  




RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160510/ad7b5d26/attachment.bin>