I used to have a fail2ban filter etc setup to look for POST requests to wp-login.php; but the size of the Apache log files on one server made this infeasible (it took fail2ban too long to parse/process the files). Also, doing a filter on the Apache log file looking for POST /wp-login … means you are also catching someone successfully logging in.
Perhaps this is a better approach :
Assumptions
- You’re using PHP configured with an
error_log = /var/log/php.log- If this isn’t configured, PHP will probably log to the webserver’s error log file (/var/log/apache2/error.log perhaps).
- The Apache/PHP processes are able to write to the error_log file.
- You’re using Debian or Ubuntu Linux
Add a ‘must use’ wordpress plugin
Put this in … /path/to/your/site/wp-content/mu-plugins/log-auth-failures.php
(It must be wp-content/mu-plugins … )
<?php
add_action( ‘wp_login_failed’, ‘login_failed’ );
function login_failed( $username ) {
error_log(“WORDPRESS LOGIN FAILURE {$_SERVER[‘REMOTE_ADDR’]} – user $username from ” . __FILE__);
}
(Yes, obviously you don’t have to use error_log, you could do something else, and there’s a good argument not to log $username as it’s ultimately user supplied data that might just mess things up)
Fail2ban config
Then in /etc/fail2ban/jail.d/wordpress-login.conf :
[wordpress-login]
enabled = true
filter = wordpress-login
action = iptables-multiport[name=wp, port="80,443", protocol=tcp]
logpath = /var/log/php.log
maxretry = 5If you have PHP logging somewhere else, change the logpath appropriately.
Finally in /etc/fail2ban/filter.d/wordpress-login.conf put :
[Definition]
# PHP error_log is logging to /var/log/php.log something like :
#[31-Jan-2024 20:34:10 UTC] WORDPRESS LOGIN FAILURE 1.2.3.4 - user admin.person from /var/www/vhosts/mysite/httpdocs/wp-content/mu-plugins/log-auth-failures.php
failregex = WORDPRESS LOGIN FAILURE <HOST> - user
ignoreregex =Extra bonus points for making the failregex stricter, or stop including $username in the log output (which perhaps makes it vulnerable to some sort of injection attack).
There’s probably a good argument for using a different file (not the PHP error_log) so other random error messages can’t confuse fail2ban, which might also allow you to specify a more friendly date format for fail2ban etc….
Finally …
Restart fail2ban and watch it’s log file (and /var/log/php.log).
service fail2ban restart