On Oct 17, 2006, at 10:51 PM, Matthew Seaman wrote:
This misconfiguration will also cause your ntpd to generate excessive
numbers of queries, rather than syncing up and reducing the NTP polling
interval from minpoll to maxpoll. [1]

Remove that line and restart ntpd.

That means that anyone can connect to your NTP daemon and poll it for time
service or use ntpdc to muck around with your configuration.

Setting up ntp.keys would let you control config changes via encryption and pre-shared secrets, if you care, or you can use ntp- genkeys to set up PKI using symmetric crypto. Unless you publish your IP address, it is unlikely that random requests, or even random people using ntpdc to poke at your ntpd, are going to be a significant concern.

(Oh, if someone deliberately wants to mess with your network, leaving NTPd's security completely unconfigured isn't a good idea, but neither is it going to be a significant problem; once NTPd has sync'ed the clocks, it will only skew the system time gradually no matter what a malicious intruder might try to change. The max skew permitted is less than one minute per day using -x or "tinker step 0".)

It's better to use at minimum:

    restrict default nopeer nomodify
    restrict localhost

(the 'restrict localhost' line actually removes all limitations on access
from localhost.  Ain't ntp.conf syntax wonderful.)

Ideally, you'ld be able to use 'restrict default ignore' then apply

   restrict 2.pl.pool.ntp.org nopeer nomodify
   server 2.pl.pool.ntp.org prefer

for each server you configure. That works well if you specify individual servers by name. Unfortunately the way NTP pool mechanism works makes that
approach unworkable.

You could actually use the pool via the combination of restrict and server entries, as NTPd will try to resolve the hostname once and then apply the security restrictions specified to whatever IP comes back from the pool.

However, specifying "nopeer" against all hosts, including the servers you are trying to sync against, may not be a great idea. NTPd is perfectly capable of figuring out the stratum of the timeservers as the communicate for itself, unless you fudge it or otherwise prevent it from doing so. Unless you are running a stratum-1 timeserver and know for certain that your GPS or other external timereference is more reliable than any network peer might be, using nopeer prevents NTPd from gaining a sanity check from the other timeservers it talks with...


freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to