Andreas,
I really like what you've done here, using recent and that script. My
current set up uses the hashlimit extension, and it isn't nearly as easy
to obtain information on discarded requests. I can get a rough idea by
counting packets in vs. packets out, but that obviously has
limitations. Deeper analysis is rather time consuming, which is why I
rarely bother with it. If you don't mind, I'm going to shamelessly copy
what you've done when I get enough downtime to work on my ntp server.
I'll run it for a few hours and get you some hard numbers on my
discarded requests.
Concur with the thought on rate-limiting only being necessary because of
reflective attacks. I've been in the pool for many years and didn't
bother with rate-limiting of any sort until two years ago. My first NTP
server was on a 3mbit/s bonded T-1 connection, and for many years I had
never seen more than 20-30kbit/s of ntp traffic. Who cares about
abusive clients with such a low percentage of overall bandwidth used?
That changed when I saw what I can only assume was a reflective attack,
and a particularly aggressive (>1mbit/s of traffic!) one at that.
noquery helped a bit with that, but I still felt it necessary to impose
actual rate limits.
One bit I'll note, someone (you?) commented that ntpd only tracks 600
clients. The newer version tracks however many you provide it memory
for. I played with this version awhile ago and didn't have any issues
with it, though I ultimately went back to the older version included
with Slackware, which is 4.2.something if I recall correctly.
Tim
On 12/17/2013 9:26 AM, Andreas Krüger wrote:
Hello, Marc and all,
here's my 2c on NTP rate limiting.
planning rate limiting
======================
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
