From: Rich Brown <richb.hanover@gmail.com>
To: bloat <bloat@lists.bufferbloat.net>
Cc: "Richard E. Brown" <richb.hanover@gmail.com>
Subject: [Bloat] netperf server news
Date: Tue, 6 Oct 2020 06:52:43 -0400 [thread overview]
Message-ID: <2F8AA6E5-93F7-4FB2-A57F-10F7642F3092@gmail.com> (raw)
To the Bloat list,
I had some time, so I looked into what it might take to keep the netperf.bufferbloat.net server on-line in the face of an unwitting "DDoS" attack - automated scripts that run tests every 5 minutes 24x7. The problem was that these tests would blow through my 4TB/month bandwidth allocation in a few days.
In the past, I had been irregularly running a set of scripts to count incoming netperf connections and blacklist (in iptables) those whose counts were too high. This wasn't good enough: it wasn't keeping up with the tidal wave of connections.
Last week, I revised those scripts to work as a cron job. The current parameters are: run the script every hour; process the last two days' of kern.log files; look for > 500 connections; drop those addresses in iptables.
There are currently 479 addresses blacklisted in iptables (that explains why the bandwidth was being consumed so quickly). There are only a few new addresses being added per day, so it seems that we have flushed out most of the abusers.
My questions for this august group:
1) The server at netperf.bufferbloat.net is up and running. I get full rate speed from my 7mbps DSL circuit, but that's not much of a test. I would be interested to hear your results.
2) The current threshold comes from this estimate: most speed tests use 10 connections: 5 connections up and 5 down. So 500 connections would permit about 50 tests over the course of two days. Is that enough for "real research"? (If you need more, I can add your address to my whitelist file...)
3) I would be pleased to get comments on the set of scripts. I'm a newbie at iptables, so it wouldn't hurt to have someone else check the rules I devised. See the README at https://github.com/richb-hanover/netperfclean
Thanks.
Rich
next reply other threads:[~2020-10-06 10:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 10:52 Rich Brown [this message]
2020-10-06 13:11 ` Sebastian Moeller
2020-10-06 19:18 ` Colin Dearborn
2020-10-06 20:40 ` Rich Brown
2020-10-07 0:42 ` Dave Collier-Brown
2020-10-07 2:39 ` Kenneth Porter
[not found] <mailman.3.1602086401.13868.bloat@lists.bufferbloat.net>
2020-10-07 18:23 ` Rich Brown
2020-10-08 1:39 ` Kenneth Porter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2F8AA6E5-93F7-4FB2-A57F-10F7642F3092@gmail.com \
--to=richb.hanover@gmail.com \
--cc=bloat@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox