Slashdot Mirror
OpenBSD Releases a Portable Version of OpenNTPD
Noryungi (70322) writes Theo De Raadt roundly criticized NTP due to its recent security advisories, and pointed out that OpenBSD OpenNTPD was not vulnerable. However, it also had not been made portable to other OS in a long time. Brent Cook, also known for his work on the portable version of LibreSSL (OpenBSD cleanup and refactoring of OpenSSL) decided to take the matter in his own hands and released a new portable version of OpenNTPD. Everyone rejoice, compile and report issues!
I won't even say 'anymore' - no one probably ever was doing it. But we need to learn. Because if we don't, at some point, the bad guys will own the world.
I'm led to believe that the reason we're using ntpd and not any of the other is that, although they are fine for getting your home machine to approximately the right second, they are damn-near useless for anything that you want real time-keeping for.
So if you want to interact with stratum-1's or be a stratum-2, then you'll be using ntpd. And, en-masse, NTP is not something as simple as just clock-skewing. That throws lots of things out of kilter. Granted, you may think you don't care, but these things can come back to bite you if you make a hasty decision now.
When someone like the NTP pool project (that I run a couple of serverse on) come to me and tell me that ntpd isn't secure enough, and that OpenNTP is good enough , then maybe I'll go over to them. Fact is, I haven't heard anything along those lines.
There's a lot of maths behind getting your clocks in sync quickly without going backwards in time, or slowing to a crawl, or messing up timestamps a lot. It's not as simple as "let's just drag the users clock closer to the reference one constantly". ntpd does a LOT that other NTP servers don't, and a lot of that is important for anything that you want to rely on a timeserver for.
Sorry, but this is just blatant "Look at us, we run an NTP project that's secure" when actually it does less than 10% of what ntpd does. And to make it do what ntpd does, presumably will take years of work to secure.
There are various "rewrite" projects at the moment, but all known holes with ntpd are closed. Until there's a compelling reason to move, don't. And by the time there is, you'll find properly-written, full-featured NTP projects being offered.
Nobody's talking about sub-millisecond accuracy here either. We're just talking not cocking up the one thing you plug in an NTP server to get right - the time.
Please read this article regarding security of NTP:
http://linux-audit.com/tlsdate...
Like chrony.
I wouldn't recommend openntpd because it isn't an implementation of ntp
*****: Builds clean! No warnings!
*****: Service starts and stops perfectly. No hangs so far.
*****: More timezone support than NTP. Includes Mars clock.
*: Does not actually set server time. :(
ntp is surprisingly complex to deal with a surprisingly complex thing. If tlsdate was a decent enough utility, then we'd still be using the time protocol of rdate as the go-to time sync strategy. Precision and quality is much lower.
There's also a couple of tricky things. One is that it could be dropped in TLS 1.3. Another is that it doesn't play with the concept of TLS certificate expiry.
Basically, this is a potentially handy utility to take the place of rdate, not something that begins to touch ntp.
XML is like violence. If it doesn't solve the problem, use more.
So totally secure, because of theo's openbsd special sauce. Now if only it could keep the time.
imo, when you go for that last nanosecond of accuracy as the highest priority
That's kind of the whole point of a timeserver. If you're just running a typical client that doesn't need precision there are a multitude of SNTP implementations that you can use, including the one built into Windows. If you're running something that demands precision or wish to share your time with others (random plug: NTP Pool) you're going to need a little bit more accuracy than that.
and lower the priority of writing secure software to the point where it is no longer a priority, then you have ntp.
ntpd has been around since the 80s. Contrast it against other system daemons that have been around that long (sendmail) and you'll see that it has a solid security record. The recent "exploits" only impacted a small subset of servers that were using the cryptographic functionality of ntpd, which is primarily used for remote management and peering relationships and was a non-issue for the lion's share of configurations. Configurations to work around the issues were released immediately and a patch to solve them entirely was available within days. What more do you want? This was all discussed on the NTP Pool mailing lists and the consensus was "meh." I'm not aware of any NTP server that has been compromised because of these exploits.
The biggest issue that's hit ntpd in the last year was the ease with which you could use the 'monlist' command for amplification attacks. This too was easily solved with a configuration change and in any event did not compromise the integrity of the servers running ntpd. It's symbolic of a larger problem that has hit other protocols (DNS) and which will never go entirely away until network operators get off their lazy asses and implement the recommendations of BCP38.
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
Took a look. Found a bug in 2 seconds. Theo is really quite full of himself.
For the bug take a look at the "host" function in parse.y. Who can spot what the function returns and what it's being tested against.
ntpdate on a cron is a nice alternative to running the full ntp server, if you just want accurate time.. I've had to set this up on a network wherein each server running ntp server created too much drift between them (all servers needed to be within 100 ms of eachother). Easiest solution is all servers run ntpdate every minute against a single host within the network. Drifting averaged about 20ms with that simple solution.
If OpenNTPD is so portable, where's the Windows port?
I'm tired of Delaware NTPD stepping the clock, and I want an NTP service for my Windows servers that slews the clock instead. Can OpenNTPD do that for me? Apparently not.
Wait, hold on, Delaware NTPD can.
C:\Program Files\NTP\bin\ntpd.exe -x
Never mind. Thanks for nothing.
DragonFly has had its own ntp-only client for years, dntpd. Not sure why this is suddenly becoming a topic now.
In terms of portability, every operating system has different sysctls or system calls for manipulating the clock. There is no single standard for setting the frequency drift correction, step, or slide operations to correct the time. And part of the problem is that most of these APIs are deficient in one way or another and make it difficult for the ntp client to run the corrections without generating feedback which messes up further corrections.
Beyond that, the code is fairly straight-forward.
-Matt
The likely cause of this problem is you've probably peered too many of your local machines with each other and they created a mutual appreciation society where they trust each other more than the external time source, or you've set up each server with an insufficient number of external sources. You do need 4 independent sources per server if you are using the ntp pool if you have critical synchronization needs. If you need to run ntpdate every minute to keep them within 20ms you really do need a full ntp installation. A properly running ntp server one it adjusts for clock drift only has to poll the server every 1024 seconds.
Then I recalled the last few bits he went on about. And yes, that should be his name.
More drivel from his tower under the sea. Theo we hardly knew you. Of course, we don't want to either.
Just a look at their ntpd.conf man page makes me want to switch to OpenNTPD yesterday.
Old ntpd man pages suck so hard that it's unbelievable.
As usual, OpenBSD documentation is a dream come true. Thank you, guys.
Knowledge is power; knowledge shared is power lost.
So it's fair to say that Chrony isn't suitable for running on stratum 1 servers, of which there are a few hundred, maybe up to at most a few thousand publically available in the world[1]. For the millions of Linux servers, laptops and desktops that aren't and will never be stratum 1 NTP servers Chrony should be just fine, shouldn't it?
Yes, I think Chrony is fine for most typical unauthenticated leaf-node (client-only) usage, but I still don't recommend it for the thousands of public stratum 2 or higher (see pool.ntp.org, most are stratum 2 or 3) servers, or the thousands of corporate and organizational NTP servers. For usage as a server, with a full-time network connection, I don't know of any compelling reason to use Chrony over NTPD or OpenNTPD.
Personally I can't see any reason to believe Chrony is more secure than either NTPD or OpenNTPD. Being new, or even saying that Chrony is secure, and programming really, really carefully, doesn't make it so.