NIST NTP servers

Dovid Bender dovid at telecurve.com
Wed May 11 10:47:20 UTC 2016


What about something like this?
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
Has anyone used a Pi to create their own server?


On Wed, May 11, 2016 at 3:24 AM, Mel Beckman <mel at beckman.org> 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