On Wed, Nov 04, 2015 at 09:40:24AM -0800, Charles Swiger wrote: > On Nov 4, 2015, at 12:21 AM, Miroslav Lichvar <[email protected]> wrote: > > On Tue, Nov 03, 2015 at 01:41:57PM -0800, Charles Swiger wrote: > >> - replying with KoD DENY, if the source continues sending requests > >> - simply dropping future requests from that source for $LONGTIME ~= 1 day. > >> > >> This does the right thing for clients which want time but are being naughty > >> and querying too fast, as well as for full DDoS attacks where the source IP > >> is forged and might even be the intended target. > > > > Wouldn't that make the attack even worse? > > Not meaningfully. ntpd can handle thousands of legitimate clients polling at > normal intervals and only use a few kbits of bandwidth.
We are talking about fixing CVE-2015-7705. Here is a description if you didn't catch the beginning of the thread. http://www.cs.bu.edu/~goldbe/NTPattack.html The attacker now needs to keep sending one spoofed packet every 8 seconds (with default discard configuration) to each server the client is using to keep it permanently blocked, or at least send a burst of spoofed packets before each client request if their timing can be reliably tracked. If the rate limiting code was modified to respond to the client requests with KoD DENY (and the client actually supported the code as described in the RFC) or it completely blocked the client for one day, it would make the attack much cheaper. > > If the attacker wanted to flood the client's connection, s/he could > > send spoofed packets directly to it, no need to reflect from the > > server. > > As we should have learned by now, if an attacker can spoof small requests > and obtain large replies, that "amplification" factor is very useful for DDoS. That is a different issue. Client packets (mode 3) don't allow amplification. ntpq/ntpdc packets (mode 6/7) do allow amplification, but they are not subjected to the rate limiting. I guess they could be, but the limits would need to be adjusted as there are typically multiple packets exchanged in bursts. > >> I think ntpd should move from B to C to A, if the traffic rate continues > >> to exceed reasonable polling frequency. > > > > I think that's basically what ntpd currently does and what we want to > > prevent. > > Didn't I quote you saying: > > "Currently, if restrict kod is disabled, ntpd always does A. When > restrict kod is enabled, it selects between A and C, depending on how > long it was since last C. B is never used, which allows the attack we > are trying to prevent." Your suggestion was to move to A as the last step. As far as the attack is concerned, that's the same as switching between A and C. Unless there is some B included, the client can't stay synchronized to the server. -- Miroslav Lichvar _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
