[ntp:questions] Thoughts on KOD

detha detha at foad.co.za
Sun Jul 6 18:08:53 UTC 2014


On Sun, 06 Jul 2014 16:29:27 +0000, 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.

Agreed, not core functionality for ntpd; but it would be nice to have a
hook where one can 'vet' an incoming IP address, much like the RBL hooks
are implemented in mail agents.

> 
> 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 logfiles that fill up disks. This is one time where KOD packets come
in handy: it should be easy to construct a snort/whatever IDS signature
for KOD packets, and let the IDS take care of firewalling off the offender
as per site policy.

> 
> Cheers,
> Magnus



More information about the questions mailing list