>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 06 Oct 2020 19:39:54 -0700
> From: Kenneth Porter <[email protected]>
> To: bloat <[email protected]>
> Subject: Re: [Bloat] netperf server news
> Message-ID: <38F0B196CFEA470FEEBE0520@[172.27.17.193]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> --On Tuesday, October 06, 2020 7:52 AM -0400 Rich Brown
> <[email protected]> wrote:
>
>> 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
>
> A couple of alternatives to custom scripts are fail2ban and the
> rate-limiting modules available for iptables such as hashlimit and recent.
> I haven't used fail2ban for rate-limiting so I'm not sure if it's the right
> tool for that but it monitors log files to add iptables rules for
> short-term banning. It's not hard to add your own log monitoring rule. I
> haven't used the iptables modules but they look like a natural solution for
> this.
>
> <https://poorlydocumented.com/2017/08/understanding-iptables-hashlimit-module/>
>
> <https://serverfault.com/questions/682045/source-ip-rate-limiting-in-iptables-hashlimit-vs-recent>
>
> Instead of using a unique iptables rule for each blocklist member, I
> suggest using an ipset. (I use firewalld as a front-end to iptables so I
> let it manage my ipsets, but you can also install ipset's service for use
> with raw iptables to save and restore the sets across boots.) Your block
> rule could be as simple as this:
>
> iptables -I INPUT 1 -p tcp --dport netperf -m set --match-set
> NetPerfAbusers src -m conntrack --ctstate NEW -j DROP
Thanks for these thoughts. I looked briefly at rate-limiting schemes, but
didn't see a good way for them to distinguish good users from bad:
- Good users (who are setting up their SQM, or testing various algorithms) run
a test (that creates 10 connections in ~10-60 seconds), tweak a parameter, then
re-run that test, repeating until they're happy.
- Bad users who test every five minutes 24x7 create 10 connections every 300
seconds - a slower "rate" of establishing new connections than the good guys.
The primary characteristic that distinguishes the good guys from the bad is
that good guys *stop.*
So, my reasoning goes, I need to look at a longer time window and set a limit
on the number of connections over the course of a day or two (not minutes or
hours). And that's the genesis of my question to the group:
What is *your* pattern of testing? How many successive tests are you
likely to make over the course of a day?
I'm also aware of ipset, which I take to be an optimized alternative to
searching a long set of iptables rules (true?) I don't believe that my OpenVZ
VPS has kernel support for this, so as long as the long-list-of-rules seems to
work well, I'm going to leave it alone.
That's my thinking, but please let me know if I'm missing something. Thanks
again.
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
