Hello, Scott and all,
this is a (slightly streamlined) version of my setup
on iptables-based NTP rate limiting.
planning rate limiting
======================
I set up an IP-tables list which has slots for 80000 unique clients.
When all is normal, an individual client drops out of that
list after some three or four hours of inactivity. So this gives me
not only rate limiting, but also a nice bunch of data material
to analyse.
One of these days, I will have an analysis showing whether, e.g.,
requests peak at the start of the minute, or start of the hour.
My rate limiting provides the raw data to do such analysis,
but I have not yet bothered to write the code.
If I understand correctly, an ntpd - client could legitimately send
a burst of 8 requests every 64 seconds, if configured with "burst".
So I decided to rate limit at 10 requests every 50 seconds.
With that rate limiting, I duplicate results other people
have also found: I have found misbehaved clients _increase_
their knocking at my door after I have shut it into their face.
As a consequence, my server presently drops roughly 19 %
of all packets it receives (long term). Paradoxically,
I could probably reduce the load on my server by allowing
a higher request rate. If my clients are stubborn,
I can be stubborn to, so I don't do that.
For the record: I also decided against using the "time to
live" of the incoming requests in my rate limiting. Doing so would
make it a little harder for someone rogue to forge parcels that cause
my server to ignore the legitimate (victim's) request. So far, so
good - but doing so would also make it easier for a rogue botnet to
launch a distributed reflection attack against a single victim's
computer.
Installing rate limiting
========================
I wanted to use iptables rate limiting via the "recent" module.
I wanted 80000 slots (unique clients tracked).
As I limit at 10 requests, I need at least that many per client. Many
client seem to send out requests in bursts of 4. So 20 seemed like a
reasonable number, that allowed some insight into what clients are doing.
You might want to use lower numbers.
This boils down to the following modprobe configuration line:
options xt_recent ip_list_tot=80000 ip_pkt_list_tot=20
On my box, I added a file /etc/modprobe.d/xt_recent.conf with that
line. That might also work on your box, consult "man modprobe.conf".
In passing: These numbers are compatible with all other xt_recent uses
on that box (namely, none).
At this point, I checked xt_recent was not yet on the list of loaded
modules, as displayed by lsmod .
Next, I added a couple of IP-tables firewall rules:
iptables -A INPUT -p udp --dport 123 -m recent --name toomuchntp --set
iptables -A INPUT -p UDP --dport 123 -m recent --name toomuchntp \
--rcheck --seconds 50 --hitcount 10 -j DROP
testing rate limiting - does it work?
=====================================
This automatically loads the xt_remote kernel module. I checked via
lsmod.
After a cup of tea, the customary
iptables -vnxL INPUT
gives some initial staticstics.
Does it work as intended? For one more final test,
I go to a different Linux box and issue,
in more or less rapid succession, several
ntpdate -qv -p 1 myserver
Higher values for "-p" (parcels per burst) can also be used.
Food for reports
=============
Back on the ntp server machine, looking at
/proc/net/xt_recent/toomuchntp
yields some interesting per-client information.
The timestamps are in Kernel jiffies from some point
in the past, apparently the time of the most recent boot.
There are 250 such jiffies per second on my machine.
Regards, Andreas
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
