From owner-freebsd-questions@FreeBSD.ORG Wed Oct 18 16:53:13 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B19E16A403 for ; Wed, 18 Oct 2006 16:53:13 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FD4D43D7B for ; Wed, 18 Oct 2006 16:53:04 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin05-en2 [10.13.10.150]) by smtpout.mac.com (Xserve/8.12.11/smtpout15/MantshX 4.0) with ESMTP id k9IGr3nF005122; Wed, 18 Oct 2006 09:53:04 -0700 (PDT) Received: from [17.214.13.96] (a17-214-13-96.apple.com [17.214.13.96]) (authenticated bits=0) by mac.com (Xserve/smtpin05/MantshX 4.0) with ESMTP id k9IGqwlb027288; Wed, 18 Oct 2006 09:53:02 -0700 (PDT) In-Reply-To: <4535C0EB.8000700@infracaninophile.co.uk> References: <20061018000853.O49453@192.168.11.51> <4535C0EB.8000700@infracaninophile.co.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 18 Oct 2006 09:52:58 -0700 To: Matthew Seaman X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: Zbigniew Szalbot , freebsd-questions@freebsd.org Subject: Re: ntpd not adjusting the clock? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2006 16:53:13 -0000 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