[security at ntpsec.org] Bug#964395: Does CVE-2020-13817 affect ntpsec?
jamesb.fe80 at gmail.com
Thu Aug 13 12:49:44 UTC 2020
On Wed, Aug 12, 2020, 8:28 PM Richard Laager via devel <devel at ntpsec.org> wrote:
> I don't think I ever got an answer on this one.
flattened from listed website:
>> Have enough trustworthy sources of time.
>> If you are serving time to a possibly hostile network, have your system get its time from other than unauthenticated IPv4 over the hostile network.
>> Use NTP packet authentication where appropriate.
>> Pay attention to error messages logged by ntpd.
>> Monitor your ntpd instances. If the pstats command of ntpq shows the value for "bogus origin" is increasing then that association is likely under attack.
>> If you must get unauthenticated time over IPv4 on a hostile network:
>> Use restrict ... noserve to prevent this attack (note that this is a heavy-handed protection), which blocks time service to the specified network.
>> Upgrade to 4.2.8p14, or later, from the NTP Project Download Page or the NTP Public Services Project Download Page, and appropriately use some or all of the following in your ntp.conf file:
>> server ... xmtnonce
>> pool ... xmtnonce
>> restrict ... serverresponse fuzz
>> pollskewlist default 6|6 (for example)
Defaults to no servers, but supports draft NTS instead of autokey,
does not enforce authentication or operator attention, does not
support random nonce instead of 4.2.8p14 'features', supports
refclock-only time setting for some refclocks.
I think we could do more to address this 'client-side' issue. Possible
mitigations would include the new features from 4.2.8p14, defaulting
to larger minsane, minclock and maxclock values, as well as defaulting
to "pool 2.ntpsec.pool.ntp.org" for time. Also, moving the client-side
listener  might make it harder to spoof answers to the client-side.
I am probably wrong about much of this though.
More information about the devel