NIST NTP servers

Wed May 11 11:24:43 UTC 2016

Building a S1 system with RaspberryPis would not fly in most of the
corporate/enterprise environments I've worked in (random 'appliances',
non-uniformity, and lack of support are all glaring issues).

Get a PCIe card with a BNC connector and dual power supplies for life in a
data center.

For home/hobby use a Garmin 18x LVC and any spare compute is a great
project: http://www.catb.org/gpsd/gpsd-time-service-howto.html

On Wed, May 11, 2016 at 6:47 AM, Dovid Bender <dovid at telecurve.com> wrote:

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

-- 
Miano, Steven M.
http://stevenmiano.com