[Bloat] netperf server news

[Rich Brown]

> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 06 Oct 2020 19:39:54 -0700
> From: Kenneth Porter <shiva at sewingwitch.com>
> To: bloat <bloat at lists.bufferbloat.net>
> 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 
> <richb.hanover at gmail.com> 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.