• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • 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

ESTUGO

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