[prev in list] [next in list] [prev in thread] [next in thread] 

List:       timekeepers
Subject:    [Pool]  4000 packets a second?
From:       Dave Hart <davehart () gmail ! com>
Date:       2010-08-31 2:21:36
Message-ID: AANLkTimXwdH-ADsLY=x+1bOJrTUQBxLZHAx-i0na+2re () mail ! gmail ! com
[Download RAW message or body]

I cc'd the wrong list on my response, I'm sorry.

Dave Hart


---------- Forwarded message ----------
From: Dave Hart <davehart@gmail.com>
Date: Tue, Aug 31, 2010 at 12:56 AM
Subject: Re: [Pool] 4000 packets a second?
To: Scott Baker <bakers@canbytel.com>, questions@lists.ntp.org


On Mon, Aug 30, 2010 at 20:12 UTC, Scott Baker <bakers@canbytel.com> wrote:
[...]
> My server was getting 4000 requests every 5 seconds from a 65.99.214.245.
[...]
> I was able to block that IP at our upstream router. Is there a better way
> (with NTPd) to block something like that?

A pool server I'm involved with uses:

discard minimum 0
restrict default limited kod notrap nomodify

With versions of ntpd older than 4.2.6, you should also add:

restrict -6 default limited kod notrap nomodify

to apply the same default restrictions to both IPv4 and IPv6 clients.
In any case, you will also want relaxed restrictions covering at least
localhost and possibly some local subnets:

restrict 127.0.0.1
restrict ::1

By default, ntpd enforces no rate limiting.  If the applicable
restrict line for a given client contains "limited", basic rate
limiting is enforced, controlled by the "discard minimum" and "discard
average" knobs [1].

Be aware that if you enable rate limiting, the default "discard
minimum 1" degrades service to ntpdate clients, which send the next
request as soon as they receive the prior response with no regard to
rate limiting.  The very newest 4.2.7 versions of ntpdate rate-limit
requests to stay under the ntpd defaults, but to provide better
service to older ntpdate, "discard minimum 0" lowers the minimum time
allowed between requests from a single IP to 1s from 2s default.
ntpdate can work with only one response out of four tries, but more
responses are better.

You can monitor the rate limiting in action using "ntpdc -c sysstats",
or, with a 4.2.7 ntpq and ntpd, "ntpq -c sysstats" which adds a KoDs
sent counter compared to its ntpdc equivalent.  "ntpdc -c monlist" (or
on 4.2.7 or later, "ntpq -c mrulist") might also provide insight.

Speaking of KoDs, they not sent by default.  The source IP's matching
restrict line must have _both_ "limited" and "kod" for Kiss-O'Death
responses to emit, as the KoD code is never reached unless
rate-limiting applies.

Cheers,
Dave Hart


[1] http://www.eecis.udel.edu/~mills/ntp/html/accopt.html#discard
_______________________________________________
pool mailing list
pool@lists.ntp.org
http://lists.ntp.org/listinfo/pool

[prev in list] [next in list] [prev in thread] [next in thread]