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...
--
-Chuck
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
