Similar, but not the same as proposed in https://plesk.uservoice.com/forums/184549-feature-suggestions/suggestions/46431970-add-rate-limiting-rules-to-fail2ban

Problem:
Scrapers and bad bots are reacting to an increased propagation of Fail2Ban bad bot rules. Their new tactic is to collect a number of domains hosted on the same ip address first, then to send burst style requests to all these domains "at once" so that they get a response before Fail2Ban rules kick in to ban the ip address of the requestor. Since 3/2025 in some cases it has been observed that these attack style bursts can be so massive that they drive up the cpu usage of a server to a point where it becomes unresponsive for minutes (5+ ... 30+) until it is able to process all the requests.

Solution:
A general rate-limiting for iptables. Add a rule in position (1) of iptables that limits the number of new connections from the same IP address, for example

# iptables -I INPUT 1 -p tcp --syn -m multiport --dports 80,443,8443,8447 -m connlimit --connlimit-above 30 --connlimit-mask 32 -j REJECT --reject-with tcp-reset

A feature in Plesk that could do this could do two things: For one it should be possible to add several entries to the top of iptables for different ports (dports parameter). For some users it will be important to also limit the rate of incoming connections to other ports such as 3306 but with a different connlimit. As the connlimit should be different for different services, it will be important to being able to add several such entries (like in the Firewall module you can add different rules for different services).

Second, the feature will need the connlimit number user configurable, because this strongly depends on how the server is used. VPS users will want to have a low number, users with a server mainly for their own office work will want to have a high number and virtual webhosting resellers will want to have a middle number like 50 etc., because the number of connections made depends on the usage scenario, and we don't want to block legitimate users.

Finally, this needs to become part of Plesk, because users won't want to set the rules themselves after each server restart, so they should be an integral part of what Plesk sets in iptables after a server restart.