NIST NTP servers

Baldur Norddahl baldur.norddahl at gmail.com
Wed May 11 11:46:51 UTC 2016


But would you not need to actually spend three times $300 to get a good 
redundant solution?

While we are there, why not go all the way and get a rubidium standard 
with GPS sync? Anyone know of a (relatively) cheap solution with NTP output?

https://en.wikipedia.org/wiki/Rubidium_standard

Regards,

Baldur

On 2016-05-11 09:24, Mel Beckman wrote:
> Regarding Roland’s reference to time and position spoofing via a hacked GPS signal, the hacker has to get physical line of sight to the victim’s antenna in order to succeed with this attack. That’s likely within a few blocks, if not within a few feet. And a rooftop antenna might require a drone attack. And how does the drone get guidance without a reliable GPS signal? :)
>
> Eric, I agree that sometimes a site can’t get a GPS signal, but in my experience designing data centers, that’s still pretty rare. Many NTP systems use an active GPS antenna that can be hundreds of feet away. But you can always put the $300 NTP server in an outdoor enclosure and power it with PoE.
>
> There’s always CDMA, GSM, and even WWV for a less-accurate plan B time source.  Here’s a somewhat pricey ($700) CDMA gizmo I haven’t investigated yet:
>
> http://www.beaglesoft.com/celsynhowworks.htm
>
> And their $400 WWV-based Stratum 1 time server:
>
> http://www.beaglesoft.com/radsynreceiver.htm
>
> So if you want non-Internet clock diversity, you can have clock diversity. You just have to pay for it.
>
>   -mel
>
> On May 10, 2016, at 9:18 PM, Eric Kuhnke <eric.kuhnke at gmail.com<mailto:eric.kuhnke at gmail.com>> wrote:
>
> 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
> for redhat/centos.
>
> In the event that one out of four sources is wildly wrong the ntpd will
> ignore it.
>
> 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<mailto: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
> 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<mailto: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<mailto:cma at cmadams.net>> wrote:
>
> Once upon a time, Mel Beckman <mel at beckman.org<mailto: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<mailto:cma at cmadams.net>>
>
>
>



More information about the NANOG mailing list