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 <[email protected]> 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 <[email protected]<mailto: > [email protected]>> 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 <[email protected]<mailto: > [email protected]>> 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 <[email protected]<mailto: > [email protected]>> 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 <[email protected]<mailto: > [email protected]>> wrote: > > Once upon a time, Mel Beckman <[email protected]<mailto:[email protected]>> > 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 <[email protected]<mailto:[email protected]>> > > > >
