On Sat, Oct 24, 2015 at 01:09:06AM +0000, Harlan Stenn wrote: > Is a pool list the right place for this discussion?
Yes, there are people who are running public NTP servers and have a lot of experience with abusive clients, rate limiting etc. They may have feedback on the proposed changes and test them before they are included in the ntpd code. > It may be that the server operator should stop using 'restrict kod > limited'. But it's their choice to use it, and it was the client's > choice to use that server. Are you saying clients should be able to detect if the server is vulnerable to this attack and avoid it? That doesn't seem right to me. If the rate limiting as currently implemented is vulnerable, I think it should be either removed or fixed. It seems in DNS they were able to fix it. > > I think it also creates a new problem that an attacker could spam the > > client's syslog with these messages and fill the disk. Harlan, could > > you please consider adding a rate limit for the message to prevent > > that? > > How far do we go? syslogd already has code for clogging attackss. Which is used on all systems supported by ntp and the rate limiting is enabled by default there? Wouldn't this be useful for an attacker to hide important information, like clock being stepped or peers becoming unreachable? The point is that as far as I know it wasn't possible to trigger a log message with a spoofed packet before and now it is. The users should at least be warned about this. > If the client is the victim of a DoS attack from forged sources, that's > something to report to the server operator and network operators. Realistically, what they can do about it? > > As for fixing the CVE, the NTPattack paper suggests to not drop all > > packets from rate limited clients, but reply randomly (similarly to > > RRL in DNS) to some percentage of the requests that appear to be > > coming from the client, so it will not be completely starved. > > KoD packets do not have valid time stamps, so this won't work. What > might work is to have a % of these KoD RATE response get answered. But > there are problems with this too, if the source IP is being forged. The proposal is to reply only to a fraction of the requests (chosen randomly) if restrict limited is enabled and the limit is reached. If also restrict kod is enabled, the fraction of the replies (chosen randomly) would be KoD RATE packets, but most of the replies the client would get would still be useful for synchronization. There would be a change in the case of abusive clients though. Currently, if a client is always sending its requests too frequently and it doesn't fall off the monitoring list, it will get only KoD replies, which don't have the server's time. I think the intention was to let such clients drift away from true time, the user notice the clock is wrong, investigate the problem and get the implementation fixed. I'm wondering if that ever happened. > The best idea I've had is that if a client is getting unexpected replies > from a server that it send a query packet before the server might start > to send KoD responses, as there's a decent chance that the server might > soon stop responding to packets claiming to be from the client/target IP. I'm not sure how would that help. When the client gets a reply to a spoofed request, it may already be blocked and it won't get any further replies to its own requests. Also, couldn't be this behavior (sending new request when a bad reply is received) exploited for some other attacks? > Also think about the consequences of what you are proposing - the > suggestion is that if a KoD RATE is received, there's a chance that if > we just ask often enough, we'll eventually get a valid response. This > will *encourage* more traffic to a server for non-compliant NTP clients. Yes, that is a possibility. It would definitely need to be tested first on a public server to see how the clients react when they are under the attack and get responses only to a fraction of their requests. -- Miroslav Lichvar _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
