On 7/6/2014 12:29 PM, Magnus Danielson wrote: > Detha, > > On 07/06/2014 03:23 PM, detha wrote: >> On Sun, 06 Jul 2014 12:28:09 +0000, Magnus Danielson wrote: >>> For cases like that, KOD won't help at all. >>> >> >> All the state table/KOD/filter rules mitigation approaches I have seen so >> far are limited to one server. Maybe time to take a look at a DNSBL-type >> approach for abusive clients; that way, once a client is labeled >> 'abusive', it will stop working with any of the pool servers that use the >> blacklist. >> >> Policies (for how long to auto-blacklist, how to prevent DoS by >> blacklisting the competition, how to 'promise to behave and >> express-delist' etc.) to be defined. > > Maybe. For the moment I think it is sufficient if we provide a mechanism > by which offenders gets reported to *some* system. > We *could* also provide a method by which white/black-list can be > dynamically set from an external source, so enough hooks exists, but I > do not think that NTPD should be burned with the rest of that system. > > Once NTPD can report it feels offended by a source, and beyond KODing it > also report to some external mechanism that could potentially block it > by any external means, NTPD does not have to do much more. > > My point being with this line of thinking is that KOD in itself makes > assumptions on the offending source actually respects it, and while KOD > rules probably can be improved, it does not provide a very effective > means of protection with sources not respecting KOD, and thus we also > needs to think i broader terms. > > In my mind, the defenses is according to these lines: > > 0) NTPD tolerates a source, packet approval checks > 1) NTPD does not tolerate a source, fires of KOD, source is expected to > shut up > 2) NTPD admin does not tolerate a source, blacklist it, NTPD will drop > the traffic > 3) NTPD admin does not tolerate a source, filters in in box firewall, > box firewall drops the traffic > 4) NTPD admin does not tolerate a source, filters in network firewall, > network firewall drops the traffic > > Notice how step 2-4 moves the traffic load further away from NTPD > process, interface and eventually subnetwork. What I proposed would > allow for automation of these steps. > > It is reasonable that escalation should be done when a source does not > respect KOD and keeps transmitting requests. > > It is also resonable that blocking times out, such that blocking is > removed after some reasonable time, as offenders can be on dynamic > addresses, and usually works over limited time when intentional. > > How to automate step 2-4 is however not a core concern for NTPD, but > feeding the data out of NTPD in a way that is handy for such a mechanism > is. Separate block-log file as I proposed is probably better than only a > syslog file, as it removes the need to parse syslog for matching blocks, > but rather can focus on changes in a dedicated file. >
The experience with blocking has actually being negative and we have seen traffic actually INCREASE after it is blocked because the client, not having received a response, tries more often. This has been observed in the wild. Danny _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
