Look at return code in addition to request path

[yitzhaq]

Currently, the strategy to handle false positives seems to be to "make sure you stop using such plugins or themes and rename any folders or files to something more suitable".

Wouldn't it be better if instead the regex was updated to take return code into consideration? Like, say the entry for wp-login.php - this makes the filter unsuitable for any site actually powered by WordPress (or at least which uses WordPress at root level). To stop using WordPress, or renaming wp-login.php, will not be practical for most users.

If the regex was instead updated to take the return code into consideration, no such adjustments would be required. A 200, 301 or similar would not match, whereas a 404, 403 etc would match. That way, any site which does run WordPress would be excluded, and requests against a site not powered by WordPress, where one can reasonably assume that such requests are indeed just probing, can match and trigger.

[yitzhaq]

I am getting much better results with this (which I'm sure could be further improved):

^<HOST> -.*(GET|POST|HEAD).*(\/wp-login\.php.*\ (403|404)\ )

[yitzhaq]

Actually, for WordPress, this works better:

^<HOST> -.*POST.*(\/(wp-login|xmlrpc)\.php.*\ (200|403|404)\ )

Limited to POST since a GET or HEAD against these endpoints can't really do any harm. And 200 included because a successful auth (with POST) will result in a redirect, whereas a failed one will return a 200.

(Some inspiration borrowed from https://graspingtech.com/using-fail2ban-protect-wordpress-blog-brute-force-attacks/)

Just a moment...