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.
Cheers,
Magnus
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
