[ntp:hackers] Cumulative Use Controls as a next addition for the LISTEN ON feature proposed.
tglassey at glassey.com
Mon Sep 21 15:03:48 UTC 2009
Hal Murray wrote:
> Interesting topic. Thanks for bringing it up.
No problem - here is a little more in response to your commentary...
> 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.
The question becomes one of whether NTP as a package includes integrated
fw tools or relies on the underlying host environment for those. If NTP
is to be the point of control in the architecture lets say that in the
Standard. As to the issues
1) There has to be some way of selecting WHAT and WHICH. The WHAT
is what NTP Services (and I think that it makes sense to look at these
as 'totality transactions' so all of the networking is seamless with the
application) provide. Those would be TIME-TRANSFER EVENTS from which the
CLIENT makes up their mind as to what to do with the data, reset their
TOD, STEER, or just TRACK-AND-LOG for a 3rd party type control model.
Much of this is already done with the savvy set of RESTRICT controls in
place but these happen at the APP level in the NTP service. The LISTEN
controls and DONT-LISTEN variant of it are specific to more lower level
controls but they actually also happen at the Application Level so the
idea that they are somehow different from RESTRICT is not real I think.
In fact the LISTEN ON syntax could easily be integrated into the
existing RESTRICT framework...
perhaps something like:
RESTRICT [IFACE] LISTEN_ON [_IPADDR_] [NETMASK] [V4|V6]
RESTRICT [IFACE] NO_LISTEN [_IPADDR_] [NETMASK] [V4|V6]
Which to enable listening on the ETH0 Interface with a /24 IPv4 Address
of 192.168.10.10 would look like:
RESTRICT eth0 LISTEN ON [192.168.10.10][/24]
>> 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.
Only in that one is TCP and persistent and the other is UDP with its
byte limitations and non-persistent connection constraints. From a
policy or process control standpoint however they both represent digital
events which are consummated over a wire.
My intent is to get a control where we can set how many time settings
specified client's are entitled to per period and I wanted to be able to
control that from within NTP.
BTW - The same is also true for whether RESTRICT could be able to be
used to allow some client's to use iBurst mode and others not. Also to
change the polling-controls allowed on a per client model for push type
timesettings. Currently there isnt any way to really control that but
with some minor tweaking we can put these controls into NTP so that
Appliance NTP (the full stand-alone reference port) would have these
capabilities as well.
> 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.
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.110/2385 - Release Date: 09/20/09 17:51:00
More information about the hackers