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

Greg Troxel gdt at ir.bbn.com
Sat Dec 28 14:56:51 UTC 2013


Harlan Stenn <stenn at ntp.org> writes:

> Greg Troxel writes:
>> Are you saying that a server (with the latest code) configured as
>> 
>>   server host1.example.com
>>   server host2.example.org
>>   server host3.example.net
>> 
>> and nothing else in the ntp.conf will behave under current guidelines
>> for best practices in terms of avoiding participating in DOS?
>
> No, because that's not "without a conf file".
>
> If you are going to create a config file that allows arbitrary hosts to
> request query responses (which is, in general, a good thing) then that's
> what you'll get.

You're assuming that people really understand all the subtleties and
handing them the chain saw equivalent of a red chain.  NTP culture has
resulted in overly complicated configuration based on a
belief/assumption that everything must be done inside the daemon, for
various reasons/justification.  (Few other programs have the complexity
of "restrict".)  While there are reasons for a lot of that, the result
is basically a bug (or an unfortunate necessity to be minimized) - which
is why I'm focusing on what happens to users who are not spending extra
hours digging in.

> I do want to discuss this and get a consensus for how to proceed.
>
> I'm not sure how much we'll actually "win" by changing the default to:
>
>  restrict default ... noquery ...
>
> because people will just as easily create a new ntp.conf line that adds
> overrides to either particular hosts/nets (which is good) or they may
> just as easily remove the "restruct default noquery" and we're back in
> the same place.

I don't understand the focus on query, perhaps because I'm unclear on
the threat model.  As I see it there are two things going on (focusing
on DOS attacks, assuming spoofed source addresses):

  1) packets that provide amplification, such as monlist, or anything else
  where significantly more bytes are returned than requested.

  2) same-sized responses, such as the normal protocol operation

I don't consider answering type 2 queries from the general internet to
be a real bug; it's not that different from ICMP echo, a TCP RST, or an
ICMP port unreachable or admin prohibited.  But type 1 is a bug.  So if
the example config above (as might be written by someone who is fairly
clueful but not paying attention to the details to set up a pair of
roughly-s3 systems to sync their entire local infrastructure to) results
in:

  attackers cannot succeed at amplification attacks

  random hosts can query time

then I think all is well.

I don't see any reason to permit administrative-style queries from other
than localhost (both 127.0.0.1 and ::1, of course) by default.

I think it would be unfortunate if security hysteria led to everyone's
organizationl servers being firewalled from the internet and therefore
unuseful to the community.  (You said this, basically.)

It seems monlist is going away in favor of mrulist (which is probably
returning the same information, but in a way which requires returning a
nonce and limits amplification even if nonces can be guessed), and it's
not clear to me there are other amplification mechanisms.  So perhaps
that's the real fix, and nothing else is needed.

There's a separate question about remedial configuration for software
that isn't updated, and I wonder if that's just blocking monlist from
other than localhost.


So my big questions are:

  Of all the attacks actually happening, what mechanisms are they using,
  precisely?  Is is just monlist?

  What other mechanisms are believed usable for attacks (with
  amplification, that are significantly more effective than ICMP Echo)?

  Do people think that simply replying to the basic time measurement
  protocol exchange is a security bug?  If so, why?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.ntp.org/pipermail/questions/attachments/20131228/5fbf8045/attachment.sig>


More information about the questions mailing list