[ntp:hackers] Cumulative Use Controls as a next addition for the LISTEN ON feature proposed.

Hal Murray 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 mailing list