svn commit: r259973 - head/etc

[Xin Li]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/27/13 17:55, Ian Lepore wrote:
> 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.
> 
I see, that's okay.  Is there any other problem in the comment, etc.?
 Another pair of eye would always be helpful to catch errors :)

Cheers,
- -- 
Xin LI <delphij at delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJSvjAbAAoJEJW2GBstM+nsm94QAJ3Q5LUzrAl84bBHIEUyDXRv
Udk5w/ZS4hmzfsDHtDV3NCtDzSXuDXivAwmDfwguHjBALjuC3J/JkxU5SW6eFo0T
DZpoyCd2bMYfc2juzmA+Uvn3oY5Pz6WsBTUuJlBDLSfLPpUOjoR/tCTfSlhKlkmG
4FdFVgJAE9ZGJWRH7BMZ71ZGklqbMCDAUv0UAC5iEcXMkO9djcgMH8eRCt7QVnuj
j0tcqSLtrO07Nb5NoSBM8JI5A0quvjJTlv1EgmsrUG9rM5kzlw6Qf6tcZ/2l0ioF
Fqwd8cEES8S3dAjrb0AW2CS3T4Dr4ku1lp2VjXTmKysiZPpu7jS1KbYYp8IAlOa/
Wj2WK7ajdupGiBwa1H7vP4cm5L3qnNDz7ydeNgjEgfGJtBcNBCphL8D50/9S8Wir
iYC3G1zoUuVmIGsc7SxRZH86C80QDQe+9jqnasw43tc8HOcj4UKnkgkcuAoUNdQ5
o084D6uDJEG2gdh5Vlc4VApw1oBFzJT31nb5mUxsdws+8jmhGHlX72O/YCNYkM91
S0Z53syCjJC5L0UtWJT6AVWONpfM5zwBRGW8deU0UN1jwa3ZFH/QPIgR+rOAU3Cm
mRaIDzYyje/Dqs9PVsdShEPzsXkDzymUYFvXH+xqXu/o8Eizl7Rxvu0chfMwU2NJ
XMumWVC44tLEhOvC00wM
=2vkt
-----END PGP SIGNATURE-----