[ntp:hackers] Cumulative Use Controls as a next addition for the LISTEN ON feature proposed.
hmurray at megapathdsl.net
Mon Sep 21 06:05:19 UTC 2009
Interesting topic. Thanks for bringing it up.
I don't see the connection with "LISTEN ON" or the recent interface/nic
additions to ntp.conf, but maybe I'm on a different wavelength.
> So... if we are going to place this type of control in the system we
> need to build a better tracking system for number of requests so that
> we can effectively shut down abusers. The question is whether that's
> a part of NTP or NTPQ as resident agent type addition.
I think there are two issues. One is collecting and analyzing the data. The
other is doing something with/about it.
> The idea is that throttling is available with most networking models
> and should be with NTP too. ...
I assume you are referring to mail and web services.
There is an interesting difference between them and ntp. A mail or web
transaction is many packets. That's a lot of work relative to a typical 2
packet exchange to get the time.
Hand waving ideas...
I suggest that we don't do anything until the current stuff gets released.
(Talk is fine, but I think we should avoid delaying the release by
introducing changes to the code base.)
ntpd could (optionally) log responses. For lightly loaded servers, one line
per request wouldn't be a big deal. It may be more than you want in normal
operations, but for something like a pool server on a DSL line, it's probably
good enough to find the bad guys.
For heavily loaded servers. I think it would be off scale. It might make
sense to log the info available via "ntpdc -c monlist" as the memory blocks
used to count requests get recycled. That would do some compression if a
block stayed around long enough to collect multiple hits. Would that happen
on busy servers?
If this is useful, I could easily imagine using lots of memory so that the
counters for bad-guys would stay around longer. Does anybody have any data
on this area?
Perhaps a filter on writing log entries would help: don't bother logging if
less than X hits, or less than X per minute.
There would probably need to be some hack to write stuff out occasionally so
you could spot the guys who were so bad that their block never got recycled.
The current statistics are per IP address. It might be interesting to
collect them per CIDR block. But how would we tell ntpd which CIDR blocks
are interesting? An entry per block in ntp.conf seems impractical, but it
might be good enough for collecting evidence in particular events. Maybe a
file/database that gets updated occasionally? Defaulting to /24 (or some
parameter) might be an interesting hack.
An alternative approach that seems better to me is to do all of this outside
ntpd. I'm thinking of tcpdump (or whatever you call it these days), possibly
running on another machine with help from a fancy smart switch that can be
programmed to send (copies of) packets to/from port/host X out port Y too.
These are my opinions, not necessarily my employer's. I hate spam.
More information about the hackers