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: >> An attacker with sufficient bandwidth can flood your incoming pipe, but >> it seems desirable to switch from: >> >> - replying normally to source IP >> - replying with a KoD RATE reply, if source is sending requests too fast >> - 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 don't want to prevent the client from getting replies to spoofed requests, I'd like to prevent a client from getting replies from spoofed requests, but I can only enforce BCP 38 within the networks I manage. > we want to keep sending useful replies to some fraction of its requests when > an > attacker is sending spoofed requests, so the client can stay synchronized. A server under attack might want to keep sending useful replies to client requests if they don't seem malicious per rate-limiting criteria. > 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. >> 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." ...? Regards, -- -Chuck _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
