[ntp:questions] better rate limiting against amplification attacks?

Jochen Bern Jochen.Bern at LINworks.de
Sun Dec 29 02:52:31 UTC 2013


Brian Utterback wrote:
> On 12/27/2013 5:50 PM, Jochen Bern wrote:
>> On 27 Dec 2013, Brian Utterback wrote:
>>> Is a peer list really a big problem? It generally doesn't make sense to
>>> have much beyond 10 peers. Are there really a lot of servers with a lot
>>> of peers?
>> 
>> If you mean to ask whether such a setup exists at all, here's a real
>> world example:
>> # ntpdc -n -c monlist | wc -l
>> 602
> 
> But monlist doesn't work with the latest software. It was replaced by
> mrulist which requires a handshake at the beginning, so the request
> address can't be spoofed. That's what I meant by having to upgrade no
> matter what we do.

Well, in this specific instance, the use of "noquery" on our server
supposedly disables all problematic request types without disabling any
functionality that the appliances need to have available, so the
question remains somewhat academic in any case - for now.

Also, I don't see the appliances using any functionality beyond client
mode synchronization - a very small, well-tested, likely pretty
problem-free subset of the NTP protocol - anytime soon. (I'ld be
grateful if someone could point me to case studies on large-scale
autokey deployments, in particular using MV, though. Our server's *not*
forcing use of NTPv3 keys for auth because we would have risked problems
of scale with that.)

However, having that said:

Back when I was asked how we could provide out-of-the-box time sync for
our appliances, I remembered a couple horror stories and told R&D that
the company'd better be prepared to run the server(s) themselves, on IPs
as unchanging as possible (no re-resolving of FQDNs by the client 'til
restart), providing support (including backward compatibility, of
course) for *years* beyond the EOL of the relevant models/versions,
yadda yadda.

Now you tell me that, lest we become an unwilling contributor to online
attacks, we have no other choice than to keep(?) updating the entire
system to ntpd versions that are actually *ahead* of what the upstream
OS distrib hands us, dropping entire request types on the floor when
they're found to initially(!) have been implemented in an insecure manner.

In our ears, that translates to "much more QA effort with considerably
less-tested 3rd-party-software versions", "customers will complain about
us effectively throwing a kill switch on their not-quite-new but still
working appliances all the time", and "the newest and bestest version
will force customers to update even the most well-protected internal
servers of theirs accordingly before they can successfully configure our
appliance to use these instead of our default server".

We see local sysadmins flat out *refusing* to update their appliances
(sitting in well-protected internal networks) for fear of stumbling over
some incompatible change in the actual production process. You're saying
that if a problem-solving update is *available*, it's ipso facto the
only countermeasure *needed*? Well, you're betting your reputation on
*those* people updating faster than the security hole *on our server*
will get exploited, then. (Or at least faster than other effective
countermeasures.) My hopes would rather be on having fine-grained
control of what requests the server does or doesn't answer, beforehand.
And ideally a thought or two having been given about clients degrading
*gracefully* as I'm forced to cut down on their server-side support.

Kind regards,
								J. Bern


More information about the questions mailing list