ntpd not adjusting the clock?

[Chuck Swiger]

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