[189198] in North American Network Operators' Group
Re: NIST NTP servers
daemon@ATHENA.MIT.EDU (Dovid Bender)
Wed May 11 06:47:26 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <38EBEB09-09BD-4C96-BCD1-312CB7ED6079@beckman.org>
Date: Wed, 11 May 2016 06:47:20 -0400
From: Dovid Bender <dovid@telecurve.com>
To: Mel Beckman <mel@beckman.org>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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@beckman.org> wrote:
> Regarding Roland=E2=80=99s reference to time and position spoofing via a =
hacked
> GPS signal, the hacker has to get physical line of sight to the victim=E2=
=80=99s
> antenna in order to succeed with this attack. That=E2=80=99s likely withi=
n 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=E2=80=99t get a GPS signal, but i=
n my
> experience designing data centers, that=E2=80=99s 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=E2=80=99s always CDMA, GSM, and even WWV for a less-accurate plan B=
time
> source. Here=E2=80=99s a somewhat pricey ($700) CDMA gizmo I haven=E2=80=
=99t 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@gmail.com<mailto:
> eric.kuhnke@gmail.com>> wrote:
>
> For quite some time, in debian the default configuration for the ntpd.con=
f
> 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 onl=
y
> supports retrieving ntp from one IP address (or hostname) and have manual=
ly
> configured it to request time from a single external source, not their ow=
n
> internal ntpd that is <10ms away, bad things could definitely happen.
>
> It is worthwhile to have both polling from external sources via IP as wel=
l
> 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@gmail.com<mailto:
> jsklein@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 1=
2
> 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 ed=
ge
> 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@beckman.org<mailto:
> mel@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@cmadams.net<mailto:
> cma@cmadams.net>> wrote:
>
> Once upon a time, Mel Beckman <mel@beckman.org<mailto:mel@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@cmadams.net<mailto:cma@cmadams.net>>
>
>
>
>
