Question Why isn't xmlrpc.php monitored by the WordPress jail in Fail2Ban?

[brother4]

Server operating system version

Ubuntu 22.04

Plesk version and microupdate number

Plesk Obsidian 18.0.64 Web Host Edition

Hello!
I've been using the WordPress jail in Fail2Ban to protect my WordPress installations from brute-force attacks. While I appreciate the protection it offers, I recently noticed a significant gap in its coverage that raises some concerns regarding security.

Specifically, I’ve observed thousands of POST requests targeting xmlrpc.php on several WordPress instances. These frequent requests are often used for brute-force attacks, exploiting the system.multicall method to test multiple login credentials in a single request.

While it’s good practice to disable or block xmlrpc.php via .htaccess, this isn’t commonly done by default, especially for less experienced users. Therefore, I believe the WordPress jail in Plesk should extend its monitoring to include suspicious activities related to xmlrpc.php as well. As it stands, this critical file seems to be outside the scope of the current jail filter, which primarily focuses on /wp-login.php attacks.

Given that Fail2Ban suggests it protects against brute-force attacks for WordPress, shouldn't this protection encompass xmlrpc.php, given its known vulnerabilities? I think this poses a major security risk, especially for users who trust Plesk's default protections to keep their sites safe without further customization.

Is there any plan to enhance the filters to cover attacks on xmlrpc.php? It seems essential, considering how common these attacks are.

Looking forward to hearing your thoughts on this!

 

[brother4]

Acutal /etc/fail2ban/filter.d/plesk-wordpress.conf:

failregex = ^<HOST>.* "POST .*/wp-login.php([/\?#\\].*)? HTTP/.*" 200

Suggestion /etc/fail2ban/filter.d/plesk-wordpress.conf:

failregex = ^<HOST>.* "POST .*/wp-login.php([/\?#\\].*)? HTTP/.*" 200
failregex = ^<HOST>.* "POST .*/xmlrpc.php([/\?#\\].*)? HTTP/.*"

 

[Maarten]

You don't need to create a Fail2ban rule to block xmlrpc.php attackers. The xmlrpc.php protection is already included in the WP Toolkit:

WP Toolkit

WP Toolkit is a single management interface that enables you to easily install, configure, and manage WordPress. It i...

docs.plesk.com

To enable this protection, follow these steps:

1. Ensure the WordPress website is managed by the WordPress Toolkit.
2. Click on Fix Vulnerabilities next to the Status label.
3. Go to the Security Measures tab.
4. Check the box for Block access to xmlrpc.php.
5. Click the Secure button.

 

[brother4]

@Maarten But not every WordPress instance is managed with WP Toolkit. That's what the Fail2bBan jails are for.

So it doesn't change the actual point that many brute force attacks on servers are not recognized, but this is suggested with the jail.

But thanks for the info anyway. I wasn't aware that there was an option there.

 

[Maarten]

I understand your concerns regarding WordPress security—it's an inevitable part of running one of the most widely used CMS platforms, which makes it a popular target for attacks. Plesk has integrated several security measures through the WordPress Toolkit that help mitigate many vulnerabilities, reducing the attack surface significantly.

When it comes to xmlrpc.php, I’m personally cautious about using Fail2Ban for these attacks, especially on busy servers. The IP blocklist can quickly fill up, causing performance issues without necessarily solving the problem long-term. For WordPress sites not managed by the WordPress Toolkit, I would recommend installing a dedicated security plugin like WordFence, which provides more targeted protection for xmlrpc.php attacks, including rate-limiting and blocking malicious traffic more efficiently than Fail2Ban can in this case.

 

[brother4]

You can also simply prevent it via .htacesss or nginx directive. But with all these questions, one thing is paramount: inexperienced users do not know this. However, Plesk suggests on the help page that the WordPress Plesk jail protects against brute force. I also assumed this at first: But then not for all login areas.

The fact that the xmlrpc protection ensures that several IPs are blocked - i.e. the protection does what it is supposed to do - cannot really be an argument for saying: Burglars, the door in the garden is open, we are only guarding the main entrance.

The attackers have long known what they can attack because Plesk, a widely used solution, does not secure this by default. They cleverly surf around the other areas where the Plesk jails are not effective.

Protecting Your WordPress Installations With Fail2ban

There is no two ways about it: having your server compromised sucks. Seeing your website defaced or infected with malicious scripts feels like a punch in the gut. Did you know that modern brute force tools can test millions of passwords per second? It takes around 15 minutes to crack an average...

www.plesk.com

Luckily, the answer is yes. Plesk 12 comes with a comprehensive set of security tools. We have got the ModSecurity support to protect web applications, and the automatic security hardening for WordPress. But today I would like to tell you about a different tool called Fail2ban. Fail2ban is effective against brute force attacks, and can be used to protect any service running on your server.

(Plesk for Linux) Protection Against Brute Force Attacks (Fail2Ban)

IP address banning (or Fail2Ban) is a tool protecting your server and the hosted websites from brute-force attacks.

docs.plesk.com

• plesk-wordpress looks for WordPress authentication failures and bans attackers for 10 minutes.

The documentation and announcements suggest to users: We have a complete solution that automatically secures you. No reference to the xmlrpc.php. I find this really fatal and dangerous.

 

[Maarten]

I get where you're coming from, and you make a good point about the visibility of the protection and vulnerability statuses in the WordPress Toolkit. I’ve taken your suggestion and posted it on the Plesk forum as a feature request. I’m asking them to separate the links for the Vulnerability and Protection Status, so it’s easier to find the protection info.

Additionally, I think the documentation around the WordPress Toolkit security features can be overwhelming for beginners. It would be great if Plesk could simplify the explanation or provide clearer guidance, especially for those who might not be familiar with all the technical details.

Hopefully, this will improve the user experience and make the security features clearer, especially for those who might not be as experienced.

I've created a corresponding UserVoice request:

Enhancing visibility of protection status in WordPress Toolkit

Recently, Plesk added a vulnerability status feature to the WordPress Toolkit, which is a great step forward. However, both the vulnerability status and the protection status are currently accessed through the same link, making it harder to quickly find the protection details. It would benefit...

plesk.uservoice.com

 

[Mark_NLD]

Acutal /etc/fail2ban/filter.d/plesk-wordpress.conf:

failregex = ^<HOST>.* "POST .*/wp-login.php([/\?#\\].*)? HTTP/.*" 200

Suggestion /etc/fail2ban/filter.d/plesk-wordpress.conf:

failregex = ^<HOST>.* "POST .*/wp-login.php([/\?#\\].*)? HTTP/.*" 200
failregex = ^<HOST>.* "POST .*/xmlrpc.php([/\?#\\].*)? HTTP/.*"

We use this combined fail2ban filter:

failregex = ^<HOST>.* "POST .*(wp-login.php|xmlrpc.php)([/\?#\\].*)? HTTP/.*" 200|401
ignoreregex =

as suggested in this post from 2017: Resolved - custom Fail2ban Login Wordpress not working

 

[Maarten]

I've removed the original UserVoice request regarding the Security Status in the WP Toolkit and replaced it with an enhanced version. You can check out the updated suggestion here:

Enhancing the visibility of protection status in WordPress Toolkit

Recently, Plesk added a vulnerability status feature to the WordPress Toolkit, which is a great step forward. However, both the vulnerability status and the protection status are currently accessed through the same link, making it harder to find the protection details quickly. It would benefit...

plesk.uservoice.com

If you find this suggestion helpful, please consider voting for it.