Is a pool list the right place for this discussion? I've added hackers@ to the thread.
Miroslav Lichvar writes: > On Wed, Oct 21, 2015 at 03:13:02PM -0400, Jared Mauch wrote: > > with this public disclosure: http://www.cs.bu.edu/~goldbe/NTPattack.html > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7705 > > Few more comments on this issue. > > The fix that was included in ntp-4.2.8p4 added a log message that > should warn that ntpd as a client is under attack. That can be helpful > for the user to know, but it doesn't really fix the issue on the > server which has enabled rate limiting. I'm not sure I agree that there is a "problem" on the server. 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. If the Pool project wants to make a policy choice about whether or not 'restrict kod limited' should be used or not, that's anaother policy choice. > 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. If the client sees these messages and they are because an attacker is forging packets to their server, they have a lot of options. If the client is really misbehaving, that's another story. 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. The client can also start using other time servers. Discussion and help appreciated. > 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 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 like the idea. The question is how restrict kod fits into this when > it's enabled. Maybe some percentage of the replies could be KoD > packets. For example, a client that is under the attack would get on > average one reply for eight requests and from that one in eight would > be a KoD RATE reply. > > Does that seem reasonable? KoD packets do not contain valid timestamps. Changing this will mean a change to the RFC, and I don't think it's a good idea to make this change. Changing the circumstances on when a KoD response is worth discussing. 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. It creates a *bigger* problem. NTF has plans for projects that we believe can make significant improvements here, though. But we don't have the resources to implement them. The current environment is driving things towards more anarchy. I think this is Bad. Really Bad. And there are people out there who seem to actively *want* this to happen. I've been asking for more support for years. I've been very slowly getting it, and the level of support we have is still nowhere near enough. We need AT LEAST 10x more financial support than we are currently getting before we can provide the bare minimum level of effort that is needed for NTP alone. It's time for folks to decide what they want to see for the future. Unless you've already made your decision, in which case you're getting what you want. -- Harlan Stenn <[email protected]> http://networktimefoundation.org - be a member! _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
