On Nov 5, 2015, at 1:43 AM, Miroslav Lichvar <[email protected]> wrote: > 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
Yes. My primary concern is what ntpd should do on the server side, and not whether a client fails to get valid time during an attack window. > 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. There exists a certain VOIP PBX vendors' braindamaged ntp client implementation which handles a KoD DENY by repolling every second. It wouldn't stop even when all traffic was firewalled. One spoofed packet to one of those means the IP being spoofed gets an NTP packet every second until the PBX gets rebooted. My point is that you don't have to look very hard to find other S/NTP implementations which can be taken advantage of. Many of them result in more significant consequences than a client being blocked. > 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. The client freewheels for the day and maybe drifts by a few milliseconds. So? >>> 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. Yes and no. The format of a mode 3 UDP packet doesn't enable a larger reply, but spoofing the right NTP traffic can provoke many packets from a single attack packet. (See example above.) > 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. Yes. Well, it's becoming more common to firewall off NTP control traffic except between trusted networks. >>>> 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. Yes. If the client is sending and receiving polls from a valid server in addition to spoofed traffic, the origin timestamp check should allow it to distinguish forged traffic. Now, if the attacker can spy on traffic between the client and the upstream servers, and/or block the replies, then it can spoof traffic reliably and/or MITM the NTP traffic and skew time. Fortunately, the sanity limits built into ntpd, adjtime(), and the kernel time discipline should limit the potential for extreme time warps. Regards, -- -Chuck _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
