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> 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> 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> wrote: > > > > > > Once upon a time, Mel Beckman <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> > > >
