[ntp:questions] better rate limiting against amplification attacks?
detha at foad.co.za
Fri Dec 27 20:11:58 UTC 2013
On Fri, 27 Dec 2013 18:30:38 +0000, Rob wrote:
> Brian Utterback <brian.utterback at oracle.com> wrote:
>> Not at all. I am asking the parameters of the attack. Is the current
>> software solution sufficient to stop such attacks? If so, then the
>> solution is for the servers to upgrade. Indeed, no solution we craft for
>> the current software development will help sites that do not upgrade.
> When the problem of reflection attacks can be solved by an upgrade, that
> is a strong motive for people (and distributors!) to finally upgrade.
> But I am not aware of more finegrained rate limiting in the newest
> version. Is there any?
>> So, if the current software is subject to attack, is the attack always
>> via mrulist or does the peer command also cause a problem? If it is
> I don't know what methods exactly are used, I have not been a victim
> myself yet. But in principle any UDP protocol that replies with much
> larger packets than the request that triggers them is a potential victim,
> as has already been shown with DNS as well.
A first step would be to have a default configuration where any
functionality that can be used for reflection attacks with more than a say
2:1 ratio needs to be explicitly enabled, with warnings about this in the
sample config file(s).
Better would be a per-IP-address request or rate limit. I realize that on
a busy server this involves a huge chunk of memory to keep track of recent
requests, but (apart from redesigning the protocol, or plainly not
allowing anything but standard client traffic) it seems to be the only way
to mitigate the use of NTP in reflection attacks. Given enough servers, an
attacker could still mount an attack by staying just under the limit for
each server, but (especially if that limit could be different for each
server) it makes the attacker's task a lot harder.
If the limit should be 'no more than n requests per source IP per minute',
or 'not more than x kB/sec traffic to an IP' is another question. I'd say
the latter - there are valid cases with multiple clients behind a single
NATed IP, and a tight request limit could interfere with those.
More information about the questions