From owner-svn-src-all@FreeBSD.ORG Sat Dec 28 01:55:27 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BA7A2E2; Sat, 28 Dec 2013 01:55:27 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A1651319; Sat, 28 Dec 2013 01:55:27 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vwj7d-000Mh0-UY; Sat, 28 Dec 2013 01:55:26 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rBS1tMFS009853; Fri, 27 Dec 2013 18:55:22 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18+E5N4i40p5y76OuY9jYNa Subject: Re: svn commit: r259973 - head/etc From: Ian Lepore To: d@delphij.net In-Reply-To: <52BE28ED.8080401@delphij.net> References: <201312272306.rBRN6GON067322@svn.freebsd.org> <1388186184.1158.156.camel@revolution.hippie.lan> <52BE28ED.8080401@delphij.net> Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Dec 2013 18:55:22 -0700 Message-ID: <1388195722.1158.173.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Xin LI X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 01:55:27 -0000 On Fri, 2013-12-27 at 17:27 -0800, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 12/27/13 15:16, Ian Lepore wrote: > > On Fri, 2013-12-27 at 23:06 +0000, Xin LI wrote: > >> Author: delphij Date: Fri Dec 27 23:06:15 2013 New Revision: > >> 259973 URL: http://svnweb.freebsd.org/changeset/base/259973 > >> > >> Log: Tighten default restrictions for ntpd(8) server and provide > >> a link to NTP access restriction documentation. > >> > >> The new default restrictions would allow only time queries from > >> a remote system and will KoD all other requests, but still allow > >> localhost to do make all requests. > >> > >> These restrictions are also recommended for all Internet-facing > >> public NTP servers. > >> > >> This changeset is intended for an instant MFC to stable/10 and > >> releng/10.0. > >> > >> Modified: head/etc/ntp.conf > >> > >> Modified: head/etc/ntp.conf > >> ============================================================================== > >> > >> > - --- head/etc/ntp.conf Fri Dec 27 23:00:56 2013 (r259972) > >> +++ head/etc/ntp.conf Fri Dec 27 23:06:15 2013 (r259973) @@ -17,7 > >> +17,7 @@ # users with a static IP and good upstream NTP servers > >> to add a server # to the pool. See > >> http://www.pool.ntp.org/join.html if you are interested. # -# The > >> option `iburst' is used for faster initial synchronisation. +# > >> The option `iburst' is used for faster initial synchronization. > >> # server 0.freebsd.pool.ntp.org iburst server > >> 1.freebsd.pool.ntp.org iburst @@ -35,21 +35,37 @@ server > >> 2.freebsd.pool.ntp.org iburst # server 2.CC.pool.ntp.org iburst > >> > >> # -# Security: Only accept NTP traffic from the following hosts. > >> -# The following configuration example only accepts traffic from > >> the -# above defined servers. +# Security: +# +# By default, only > >> allow time queries and block all other requests +# from > >> unauthenticated clients. +# +# See > >> http://support.ntp.org/bin/view/Support/AccessRestrictions +# for > >> more information. +# +restrict default kod nomodify notrap nopeer > >> noquery +restrict -6 default kod nomodify notrap nopeer noquery > >> +# +# Alternatively, the following rules would block all > >> unauthorized access. +# +#restrict default ignore +#restrict -6 > >> default ignore +# +# In this case, all remote NTP time servers > >> also need to be explicitly +# allowed or they would not be able > >> to exchange time information with +# this server. # > > > > This comment is incorrect. To quote the ntpd docs for nopeer: > > > > Deny packets that might mobilize an association unless > > authenticated. This includes broadcast, symmetric-active and > > manycast server packets when a configured association does not > > exist. > > > > In other words, peer relationships which are explicitly configured > > in the ntp.conf file(s) are not affected, the nopeer option only > > prevents *packets* that would create a new peer association. > > > >> # Please note that this example doesn't work for the servers in # > >> the pool.ntp.org domain since they return multiple A records. -# > >> (This is the reason that by default they are commented out) # > >> -#restrict default ignore #restrict 0.pool.ntp.org nomodify > >> nopeer noquery notrap #restrict 1.pool.ntp.org nomodify nopeer > >> noquery notrap #restrict 2.pool.ntp.org nomodify nopeer noquery > >> notrap > > > > The foregoing implies that these lines aren't needed. > > I'm not sure if I get what you said. Did you mean these restrict > lines are not needed when "restrict default ignore" is present? (My > test suggests they are needed, this is also what the NTP documentation > said: a 'server' line needs a 'restrict' line when the default is set > to 'ignore'). Could you please use a patch to demonstrate how we can > improve the comment? Ooops, my bad, I misread the diff. I just saw the -default ignore line, not that it had moved up a few lines. My remark was in the context of not needing to "undo" the effect of the nopeer option. -- Ian