[ntp:hackers] 'noserve' etc. and the protocol response matrix

Brian Utterback brian.utterback at oracle.com
Thu Jan 30 13:14:40 UTC 2014


On 1/29/2014 10:14 AM, Miroslav Lichvar wrote:
> On Tue, Jan 28, 2014 at 06:48:39PM -0500, Brian Utterback wrote:
>> I think you are exactly correct. To that end, I would suggest that
>> either we remove noquery altogether or make it a synonym with my
>> proposed "nowrite" restrict option. Of course we can't do anything
>> about previous versions of NTP, but then if we strengthen the
>> security of the control commands they have an incentive to upgrade
>> and otherwise they really do need it, unless we can get "disable
>> monitor" as the preferred solution.
> Recommending "disable monitor" would be problematic as it effectively
> disables the restrict limited option.

I am not sure what you mean. What are the downsides to setting "restrict 
default noquery" vs. "disable monitor"? I thought disable monitor would 
just stop monlist/mrulist, right?

The way I see it, the "restrict" option says "everything works for me, 
nothing works for anyone else" while the "disable monitor" options says 
everything works for everyone, except monlist/mrulist which works for no 
one.

I would like to have everything works for everyone, which is why I want 
to get rid of all amplification possibilities.

Am I missing something else in the pros and cons?

>
> I agree the best option would be to fix the protocol so it doesn't
> allow any amplification, but it seems that's not possible without
> breaking compatibility with older versions.

Possibly. What I would like to see is that all write commands require 
the nonce dance just to verify that they really come from where we think 
they come from. Since we would fix ntpq with the protocol change at the 
same time, it just means that they would need a up to date version of 
ntpq. If I recall correctly, this isn't the first time we have said that 
you need a current version of ntpq to get some functionality. Besides, 
the number of users using ntpq to write is relatively small. I bet the 
number of uses of ntpq to read is thousands of times greater than to write.

If there is a read request that doesn't need multiple packets then the 
protocol doesn't change at all, so there is no backwards compatibility 
problem at all in that case. The mrulist command already requires the 
nonce, we just have to reduce the number of packets exchanged per 
request which I believe is already handled by ntpq. I think the only 
other command that can send multiple response packets is the peers list 
commands. We could change that in some way so that we could detect an 
old request and new request and if we get an old request, we still 
respond but with only the first packet's worth of data. That should 
minimize the number of instances of backwards incompatibility problems.

>
> I'm not sure I understand your proposal to split the commands in read
> and write groups and restrict them separately. Isn't that what noquery
> and nomodify already do?

Not quite. First, I am not sure that NOMODIFY really covers all of the 
cases where there is some kind of configuration change. It only stops 
save_config and :config. We would have to audit all of the commands to 
be sure that nothing else changes anything on the server.

The NOQUERY command stops all control packets, not just reads.
>
> How was this problem addressed in the DNS world?

Don't know. Does DNS have a problem with writing configurations? I think 
that multiple packet responses fall back to using TCP in DNS.
>


Brian Utterback


More information about the hackers mailing list