Config file format - (Was: [ntp:hackers] FreeBSD serial ports)
kostecke at ntp.isc.org
Fri Feb 18 08:05:58 PST 2005
John Pettitt said:
>Harlan Stenn wrote:
>>I see no reason to lose the remote config stuff - it is mode7 and is
>I still question in-band config - it's just a security hole waiting to
Remote configuration is quite useful. I use it regularly and there are
a number of ntpd helper scripts in circulation which depend on remote
Remote configuration is not possible unless one of two conditions are
1. The keys are are configured _and_ the person performing
the remote configuration has the keys _and_ the originating
IP address for the remote configuration has not been blocked
with a "nomodify" restriction
2. ntpd is started with '-A' to disable authentication (you
will still be prompted for a keyID/password but any values
>Perhaps if there is a config from a url then in-band config could be
>limited to a "re-load" command that just causes the server to re-fetch
>it's out of-band config.
It seems to me that a complete configuration reload is tantamount to
restarting ntpd. This would cause a disruption of time service where
refclocks are involved. And
>That would effectivly be "dial back" security which would help.
Unless hihacked by DNS spoofing or a MITM attack.
>> ntpd -c http://ntpconf.my.dom.ain (get a conf file from a local
>I like the remote via url config idea
This adds more complexity to ntpd. And it introduces a single point of
>>I'd also like to have the ability for ntpd to write its current config
>I'd also vote against programs writing to their config file, it's a bad
>idea that also potentialy opens security holes.
It may be useful to have ntpd dump the configuration file to STDOUT. But
doing so will add more complexity to ntpd.
Steve Kostecke <kostecke at ntp.isc.org>
NTP Public Services Project http://ntp.isc.org/
Public Key at http://ntp.isc.org/Users/SteveKostecke
More information about the hackers