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 <do...@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 <m...@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.kuh...@gmail.com<mailto: > > eric.kuh...@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 <jskl...@gmail.com<mailto: > > jskl...@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 <m...@beckman.org<mailto: > > m...@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 <c...@cmadams.net<mailto: > > c...@cmadams.net>> wrote: > > > > Once upon a time, Mel Beckman <m...@beckman.org<mailto:m...@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 <c...@cmadams.net<mailto:c...@cmadams.net>> > > > > > > > > > -- Miano, Steven M. http://stevenmiano.com