>>>> The NTP pool also is not a mechanism for handholding sites with >>>> incompetent IDS monitoring.
>>>> I think the pool should do nothing here. [...] > It looks like you still don't get it. > It is not "my IDS" or the IDS of a user that is causing this problem. > It is the IDS deployed by an ISP or university or whatever supplier > of network bandwidth that is triggered, and an innocent user that is > disconnected "because of malware". In English, there is a tendency to use "you" to refer to a generic third party. If I write "if your IDS is alerting, you need to apply intelligence before cutting anyone off", the "you" and "your" do not necessarily actually refer to the person I'm responding to; they refer to a hypothetical affected user. If a connectivity provider imposes an IDS on users, that is between the two of them. Again, it is not something for the pool to meddle in. > We can protect those innocent users by not supplying the address of > C&C systems via the DNS. Not really. We cannot protect users from incompetent IDSes they are behind; whether the IDSes are provided and run by the users or by their upstreams is not relevant to that. > [...]. So it is very reasonable to alert when there is any > communication with a C&C server. It is. In most circumstances, however, it is not reasonable for the IDS admins to take further steps (such as disconnecting) when the traffic shows no other signs of malice. (Those circumstances where it is reasonable are generally paranoid enough that using the pool is not acceptable to begin with.) An IDS that does that - and I'm including the human layer as part of the IDS - is incompetently run, and _will_ cause trouble; the very most the pool can do is hide that incompetence from the affected user a little bit longer. And I believe that is no service to anyone. Furthermore, I think doing this would set a very bad precedent. I think the pool should not be in the business of determining what kind of behaviour is bad enough to merit being boycotted - except for behaviour directly related to the pool's mission (ie, serving bad time), and that, we have the monitoring system for. If we do C&C today, what next? Compromised software distribution hosts? Botnet members? Anyone connected by a provider someone doesn't like? It's a slippery slope that I think the pool should not go near. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
