The reference ntpd implementation exposes many of its implementation variables via the programs ntpq (and ntpdc which is something only its author appreciates). These make use of a control protocol in special NTP packets. It is possible the control channel can change ntpd configuration, although this is rarely used in the modern era where you can automate deploying configuration files to any number of hosts.
Risks of maintaining ntpd are primarily preventing IP amplification to spoofed addresses, and protecting your time sync configuration against change from unauthorized IP addresses on the networks.
As always, keeping patched mitigates some flaws. An amplification attack via the "monlist" function resulted in CVE-2013-5211. This should have been an update years ago, but check that all of your hosts are on a supported distro, and receive attention from a maintainer.
All the attention to monlist resulted in some tools to easily scan for it. For example, nmap script ntp-monlist.
The full list of functions is the commands documented for ntpq. Those lines in the wiki's choose-your-own-configuration differ by noquery, which denies all ntpq queries entirely. Keeping time service running. For example, that nmap script would not return anything. Contrast to nomodfy is an access rule controlling only the commands that change the configuration. Clearly nomodify should be heavily restricted, possibly to only localhost.
Compare to example configurations elsewhere, such as from your favorite disto's package. RHEL 7's ntp.conf suggests this as a starting point for access control:
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default nomodify notrap nopeer noquery
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict ::1
# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# Disable the monitoring facility to prevent amplification attacks using ntpdc
# monlist command when default restrict does not include the noquery flag. See
# CVE-2013-5211 for more details.
# Note: Monitoring will not be disabled with the limited restriction flag.
disable monitor
Note monlist mitigation even though ntpd is patched by now. Further, the default for remote hosts cannot query or modify. With light modification, this could make for a NTP host ready to serve the public internet.
Naturally once you know what ntp.conf you want, deploy that. Automate the configuration of NTP servers, get a reasonable config in the template images of all hosts.
All this monlist discussion doesn't cover your original question about OS and platform identification via ntp. Per ntpq docs, that build information may appear in system variables via the readvar control command. As in, to a remote server: ntpq -c readvar time.example.net. Although there are some implementation details to decode here, like which association ID is the NTP host in question.
Personally, I am not very concerned about exposing build information about ntpd. Someone learns my ntpd is up to date, and some of the state machine, not much they can do with that. An attacker would spray forged NTP packets to every host they can, in the hopes of amplification.
