Bug 1417031

Summary: [RFE] Package 'ntpsec' as an alternative to ntpd
Product: Red Hat Enterprise Linux 7 Reporter: Paul Wayper <pwayper>
Component: ntpAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: klotz.fla.n, thozza
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-07-11 11:37:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Paul Wayper 2017-01-27 03:25:55 UTC
Description of problem:
=======================

ntpd has lots of old, outdated code for unused protocols and ideas that make it less secure and harder to maintain.

The alternative:
================

ntpsec is a modern project that forked ntpd and removed the unused and unmaintained code.  This removed over 70% of the code while maintaining full client and server compatibility with ntpd.  It has also improved security by removing keywords and commands that did not contribute features but caused security problems.

Additional info:
================

https://gitlab.com/NTPsec/ntpsec
https://docs.ntpsec.org/latest/ntpsec.html

Comment 3 Miroslav Lichvar 2017-07-11 11:37:35 UTC
As I understand it, ntpsec removed support for some (less useful) modes of the NTP protocol and is not intended to be a fully compatible drop-in replacement for ntp. We already have an alternative NTP implementation in RHEL7 which doesn't support all NTP modes. It performs better and so far has been more secure than ntp.

As a maintainer of the two NTP packages, I'm not sure if adding and maintaining ntpsec as a third NTP package would make sense. That could change if it had some unique features and could replace one or both of the packages. In any case, this should probably not be discussed as a bug of the ntp component.

Comment 4 Nathaniel 2019-01-15 13:49:39 UTC
It's now 2019....considering the number of attacks against NTP has endured from when this RFE was posted until now that NTPSEC either was immune to by default (90% of the time) or responded to more quickly, I would consider ntpsec a viable option to be brought into the official repos. You will need ntp.conf and ntpd already on the system (installed via the ntp package) but you could bundle those into the ntpsec package if you wanted or just make ntp a pre-req and a quick how-to to remove the ntp package without removing the service daemon or configuration file before installing ntpsec. Or just automate the install by automatically installing ntp, then the dependencies brought in by ./buildprep, then removing everything from ntp other than the needed components already specified, then install ntpsec. It's not a very painful procedure when done manually but when wanting to implement on a number of systems across the network (all RHEL/CENT/FED), the use of a package performing the steps outlined would be a faster and preferred route. Debian already has a package if you want to see what they did in Testing and SID (same package, just different repo).

Comment 5 Tomáš Hozza 2019-01-15 16:43:39 UTC
Hello.

Your comment about immunity to ntp attacks applies also to chrony (https://www.coreinfrastructure.org/blogs/securing-network-time/), which is the default NTP client in RHEL-7. We are also concerned about the security issues in ntp and as a result, ntp has been removed from the distribution since RHEL-8.0 Beta and NTP client / server functionality is covered by chrony package.

Comment 6 Nathaniel 2019-01-15 17:32:16 UTC
I would like NTPSEC offered as an alternative. I understand it not being the default but the link you refer to contains severely outdated information. I question whether chrony still remains the best. Plus there are use cases in which chrony doesn't cover but ntpsec could (in lieu of ntp). In the environment I'm in, we use ntp not chrony. I could make the argument to switch to chrony but while better than ntp, would require more work as ntpsec can use currently existing configurations and services. Chrony will require more time and effort to implement. Due to the fast-pace we need to maintain for implementing new features for the network and addressing bugs for internal projects, having a quick means of deployment is a requirement. NTPSEC can address this better than Chrony at this point in time. More importantly, the decrease in time differentials between ntp and ntpsec (which chrony has also) would be appreciated for our security monitoring tool as we prefer to be as precise as possible with our real-time alerts.

Comment 7 Paul Wayper 2019-01-16 04:56:37 UTC
I'm not sure how you come to the conclusion that chrony takes more time to implement.  The config files are essentially compatible, so you can simply install the chrony package, copy the /etc/ntp.conf to /etc/chrony.conf and it basically works.  If you have something more complicated that requires conversion of config files, then I think that'll probably apply to the cut down features of NTPSEC as well.  If you could detail the specific problems you have with converting to using chrony, then we may be able to help you there.

I agree that it would be good to provide NTPSEC as an alternative to Chrony, but I don't think that's because NTPSEC is somehow easier to implement, whether coming from an existing NTP environment or if starting afresh.

Have fun,

Paul

Comment 8 Miroslav Lichvar 2019-01-16 08:34:38 UTC
There is also a script that can automatically convert existing ntp configuration to chrony, including files like /etc/ntp/step-tickers and /etc/ntp/keys.

https://github.com/mlichvar/ntp2chrony

Comment 9 Nathaniel 2019-01-16 13:57:20 UTC
Thanks for the clarification. None of the info I researched on chrony really mentioned simply taking the configuration from ntp.conf to chrony.conf. It's something I will need to consider. Though I've read each has their own particular platforms they work best on. It would be very helpful if somebody had benchmarks for time efficiency and pen test results comparing the two.

Comment 10 Nathaniel 2019-02-01 17:47:07 UTC
" We are also concerned about the security issues in ntp and as a result, ntp has been removed from the distribution since RHEL-8.0 Beta and NTP client / server functionality is covered by chrony package."

Is there an official notice or will there be an official notice sent out regarding the dropping of ntp classic from RHEL and Fedora? My organization would like to see this before considering making a switch to either chrony or ntpsec.

Comment 11 Miroslav Lichvar 2019-02-01 17:53:47 UTC
The removal of ntp is mentioned in the RHEL 8.0 Beta release notes:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html-single/8.0_beta_release_notes/index#infrastructure_services_2