• Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring.
    We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design.
    If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
  • (Plesk for Windows):
    MySQL Connector/ODBC 3.51, 5.1, and 5.3 are no longer shipped with Plesk because they have reached end of life. MariaDB Connector/ODBC 64-bit 3.2.4 is now used instead.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

fail2ban: plesk-wordpress jail is to restrictive

Jens Johansson

Basic Pleskian
Username:

TITLE

fail2ban: plesk-wordpress jail is to restrictive

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.61.5,
CloudLinux 8.9

PROBLEM DESCRIPTION

The fail2ban plesk-wordpress jail catches in an edge case a legitimate login and bans the IP. This happens, when there is a wordpress interim login (wp-login.php?interim-login=1).

STEPS TO REPRODUCE

Let's say you edit a wordpress page and get logged out while doing so, because the session time is short. In this case, wordpress shows a window to re-login. If you log back in, a POST request is sent to "example.com/wp-login.php?interim-login=1". Fail2ban bans that as a malicious login.

ACTUAL RESULT

The IP of the user, who is re-logging in, is banned.

EXPECTED RESULT

There should be no ban for wordpress interim login.

ANY ADDITIONAL INFORMATION

Therefore I suggest adding the following to the ignoreregex by default:

ignoreregex = \/wp-login\.php\?interim-login=1

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
Thank you for your report. As you've already pointed out this would be an edge case; both the default Wordpress login session expiration time (by default 48 hours) and the fail2ban maxretry value have be lowered substantially before any legitimate user would get banned. Nonetheless, it's an valid case.

I've discussed your proposed custom ignoreregex with our engineers. We feel that adding this ignoreregex would make WP sites susceptible to brute force attacks, because any attacker could simply add the ?interim-login=1 query string to the login URL. Which would make the proposed solution just as bad (if not worse) as the initial issue.
 
Back
Top