NIST NTP servers

Laurent Dumont admin at
Thu May 12 20:07:03 UTC 2016

I did and it works! But as other mentioned, using a passive antenna 
means that you are very limited in where you can actually use the NTP 
server. The device failed to acquire a GPS lock with it was 2-3 feet 
away from a window. But when it did acquire a signal, it happily worked 
as a Stratum 1 device servicing what felt like all the CPE devices 
around Montreal.

It's definitely not something that can be massively deployed to data 
centers where the physical layout can change a lot. It might be worth 
looking into an active antenna but I would also have doubts over running 
anything business critical on a RP2.



On 5/11/2016 6:47 AM, Dovid Bender wrote:
> What about something like this?
> Has anyone used a Pi to create their own server?
> On Wed, May 11, 2016 at 3:24 AM, Mel Beckman <mel at> 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:
>> And their $400 WWV-based Stratum 1 time server:
>> 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<mailto:
>> eric.kuhnke at>> 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<mailto:
>> jsklein at>> wrote:
>> Is this group aware of the incident with &
>> 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<mailto:
>> mel at>> 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<mailto:
>> cma at>> wrote:
>> Once upon a time, Mel Beckman <mel at<mailto:mel at>>
>> 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<mailto:cma at>>

More information about the NANOG mailing list