Question Managing Bot/Crawler Attacks on wp-login Across Multiple Plesk Servers - Your Solutions?

[danim]

Server operating system version

Almalinux 9

Plesk version and microupdate number

Plesk Obsidian 18.0.72 Update #3

Hi everyone,

I'm managing around 40 Plesk servers with multiple domains per server belonging to different customers and developers. I'm struggling to keep up with bots and brute-force attempts constantly hammering wp-login.php, xmlrpc.php, and similar endpoints.

Current Setup:

• Fail2ban with custom rules for bad bots and WordPress attacks
• Encouraging WP Toolkit security features (xmlrpc blocking, etc.)
• Pushing Cloudflare with Bot Fight Mode when possible (though not all customers use it)
• Tried BitNinja in the past, but false positives created a nightmare for our helpdesk team
• Despite all this, it's constant whack-a-mole - new crawlers, different servers, rotating IPs

My servers need near-constant supervision to avoid crashing under malicious traffic load. Even with fail2ban, IPs are often banned after they've already consumed resources.

How are you handling this at scale? Specifically interested in:

1. Crowdsourced solutions - CrowdSec or alternatives with better false-positive management than BitNinja?
2. Proactive blocking - Strategies that catch threats before they impact resources?
3. Customer compliance - Enforcing security practices across diverse customer bases?
4. Plesk-specific tools - Extensions or configs that actually make a difference?

Open to paid solutions if they work. The babysitting time is unsustainable.

What's working for you?

 

[finc]

Would help if PLESK could be set behind a real firewall I have a lot of this problems, too.

 

[Raul A.]

What do you consider a real firewall?

Did you try Imunify360?

 

[scsa20]

Would help if PLESK could be set behind a real firewall

Technically speaking you can put Plesk behind a firewall since you can tell Plesk what the public IP address is to the private IP of the Plesk server that's behind the firewall. Just saying.

As for OP's questions, you can look at using Imunify360 as suggested by @Raul A.

 

[Kaspar]

How are you handling this at scale? Specifically interested in:

1. Crowdsourced solutions - CrowdSec or alternatives with better false-positive management than BitNinja?
2. Proactive blocking - Strategies that catch threats before they impact resources?
3. Customer compliance - Enforcing security practices across diverse customer bases?
4. Plesk-specific tools - Extensions or configs that actually make a difference?

I am using a combination of all four:

1. CrowdSec
I've installed CrowdSec and run a minimum configuration, just using the default Apache parser. I am not sure how effectively it exactly is, but at any giving time it's blocking around 15k of IP's. Never ran into any problems with false positives and resources usage is pretty minimal too. I could probably run a tighter configuration to better utilize CrowdSec potential, but I haven't had the need to do so.

2. Proactive blocking
I am automatically blocking entire subnets if there are multiple IP's within a particular subnet already by fail2ban. To accomplish this I am using a tailored version of the script I posted here, which also checks AbuseIPDB for the the IP reputation before blocking the subnet. For me this really reduced the biggest load my server had to endure from bad bots and crawlers. I am also geo blocking a few counties (like China) on some servers, but not all.

When I stared blocking entire subnets I was afraid that this would also block legitimate services used by my customer. But so far there haven't had any reports of this.

3. Customer compliance
This is always tricky. I am trying to balance enforcing security practices without aggravating customers. I put a lot of effort in (gently) pushing my customers to make sure their websites/apps are up to date and, for customers using WP, actively try to get them familair with the avaible secutity options in the WP toolkit. Results are mixed.

4. Plesk-specific tools
Mod security and Fail2ban for the most part. With customized filters and jails to use ipset as much as possible.

With all of these measures I've been able to run a pretty stable environment. There still plenty of brute-force attempts and bots trying to scrape/crawl websites. But these attempts are not hogging up all resoucres or bringen down servers.

I haven't tried Imunify360 myself on any production server and would love to hear experiences from other forums user who do. @Raul A. and @scsa20 do you use Imunify360 to mitigate the ever growing brute-force, bot and scarping attempts?

 

[danim]

Thank you all for your input!

I wanted to share what we've implemented that's been working well for us:

CrowdSec DeploymentWe rolled out CrowdSec across all our Plesk servers with specific WordPress detection scenarios. So far, it's been quite effective at blocking attacks before they consume significant resources.

Monitoring & AlertingWe developed a custom script that sends brute-force attack data (specifically targeting WordPress) to our Zabbix monitoring server. This allows us to track attack patterns and proactively notify affected customers about security incidents on their sites.

Cloudflare MigrationWe've been aggressively migrating domains to Cloudflare with Bot Fight Mode enabled and custom WAF rules tailored for WordPress. This has significantly reduced the attack traffic reaching our origin servers.

Fail2ban TuningWe also customized our fail2ban rules to be more aggressive in blocking malicious traffic patterns.

ResultsWith all of these measures combined, we've finally gotten things under control - or at least to a point where resource consumption from attacks is no longer noticeable. The constant babysitting is now minimal.

Happy to share more details on any of these implementations if anyone is interested.

 

[pleskpanel]

Would definitely like to hear your steps/setup for CrowdSec along with any gotchas or potential conflicts with Plesk.

 

[danim]

Happy to share! Here's our CrowdSec setup for Plesk:

Note on Version
We're using the open-source version of CrowdSec, which is why whitelist management is manual (the paid version offers centralized whitelist management across servers). We also keep fail2ban enabled and running alongside CrowdSec and they work well together without conflicts.

Apache Log Configuration
The key step is configuring CrowdSec to monitor Plesk's log locations. Edit the Apache acquis file:

vi /etc/crowdsec/acquis.d/setup.apache2.yaml

Add these Plesk-specific log paths:

filenames:
- /var/www/vhosts/system/*/logs/access_log
- /var/www/vhosts/system/*/logs/access_ssl_log
- /var/www/vhosts/system/*/logs/error_log
labels:
type: apache2

This allows CrowdSec to monitor all virtual host logs and share detected attacks with the community.

IP Whitelisting
You may want to add your managment IPs to the whitelist to avoid locking yourself out:

vi /etc/crowdsec/hub/parsers/s02-enrich/crowdsecurity/whitelists.yaml

Bouncer Installation
We use the iptables bouncer to enforce blocks:

Firewall | CrowdSec

Documentation

docs.crowdsec.net

WordPress Protection
We used the WordPress collection for enhanced detection of brute-force attacks:

cscli collections install crowdsecurity/wordpress

Hope this helps! Let me know if you need any clarification.