[ntp:questions] Thoughts on KOD

Magnus Danielson magnus at rubidium.dyndns.org
Sun Jul 6 16:29:27 UTC 2014


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.


More information about the questions mailing list