[ntp:questions] Thoughts on KOD

Danny Mayer mayer at ntp.org
Mon Jul 7 14:10:25 UTC 2014


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



More information about the questions mailing list