search

mitchellkrogza / Fail2Ban.WebExploits

This custom Fail2Ban filter and jail will deal with all scans for common Wordpress, Joomla and other Web Exploits being scanned for by automated bots and those seeking to find exploitable web sites.
Other
169 stars 36 forks source link

Look at return code in addition to request path #13

Open yitzhaq opened 3 years ago

yitzhaq commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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...