Researchers Warn Computer Clocks Can Be Easily Scrambled Via NTP Flaws (networkworld.com)

alphadogg writes: Researchers at Boston University said this week that they've found flaws in the Network Time Protocol (NTP), a 30-year-old Internet protocol whose security shortcomings could undermine encrypted communications and even jam up bitcoin transactions. The importance of NTP was highlighted in a 2012 incident in which two servers run by the U.S. Navy rolled back their clocks 12 years, deciding it was the year 2000. Computers that checked in with the Navy's servers and adjusted their clocks accordingly had a variety of problems with their phones systems, routers and authentication systems. There is at least one alternative out there, and reason to use it.

Comments

Most NTP clients I've seen...

[Chris Mattern]

have an option for ignoring server updates if the time differential is too great.

Re:Most NTP clients I've seen...

[Penguinisto]

Not only that, but there are loads of other options, the most basic being that you can use your own personal stratum 1 device, and point all your servers to that. Hell, you can even build your own if you're truly paranoid.

IIRC by default the Windows AD infrastructure has member clients/servers using the Domain Controllers as their local source, and then you only need to re-point the DCs to whatever you want (the registry info documentation for NTP was a bit hinkey as late as Win7/Win2k8, so if you go mucking around in there, do it at your own risk). On the Linux/BSD/*nix side, there's a zillion options to beef up security, and they are drop-easy to enforce with any competent orchestration software (puppet, cfengine, chef, whatever). I only remember the Windows side because a previous employer had a distributed BI system that demanded that all component client devices (a mixture of Windows and Linux) must remain within 5 seconds of each other time-wise (else the whole thing threw an error and stopped).

Like sibling said though, most sysadmins don't dork around with NTP once they get a time source running - few will set up a local NTP relay of sorts, fewer still will have those sources use at least three different and vastly disparate sources to check against, and very few will set up a local authoritative stratum 1 box.

Lots of workarounds, and you really only have to set it up right once, with maybe an occasional (as in once-a-year-or-so) review and tuneup of the infrastructure.

Re:Most users I've seen...

[Anonymous Coward]

don't screw around with options once they get the thing initially functioning.

Synced clocks are necessary

[sjbe]

So design things to not require synced clocks.

They do when that is a sane thing to do. Sometimes a precise notion of time isn't important. But many activities are impossible without a rather precise determination of the time across multiple devices.

It's not like you couldn't include your idea of your local time (whatever it is) in your NFS requests, and then have the server take its idea of its local time, generate a delta, and apply that to all the timestamps that you are trying to set on a file.

The only way to ensure the local time on your clock is correct is to synchronize with another clock. A clock providing arbitrary time stamps is worse than useless. In fact for many activities what you suggest would lead to accidents, fraud and all sorts of confusion.

Any time you have a measuring device where you care about its accuracy you have to compare it to a reference standard. That's why we have highly accurate atomic clocks maintained by standards organizations to calibrate our clocks to.

Non-synchronized clocks are only a problem if you let them be a problem/make them a problem.

Sorry my friend but that's simply not true for a lot of problems.