BulletProof Security Forum

It appears that on Host’s that have mod_security installed that there is a problem with this new Brute Force Login Protection code.

# BRUTE FORCE LOGIN PAGE PROTECTION
# Protects the Login page from SpamBots & Proxies
# that use Server Protocol HTTP/1.0 or a blank User Agent
RewriteCond %{REQUEST_URI} ^(/wp-login\.php|.*wp-login\.php.*)$
RewriteCond %{HTTP_USER_AGENT} ^(|-?)$ [NC,OR]
RewriteCond %{THE_REQUEST} HTTP/1\.0$ [OR]
RewriteCond %{SERVER_PROTOCOL} HTTP/1\.0$
RewriteRule ^(.*)$ - [F,L]

We will be releasing BPS .49.4 tomorrow that will have more generic code to accomodate Host’s that filter the question mark character in mod_security based on this particular type of conditional filter – ^(|-?)$.  This will allow for the widest possible range of compatibility.

# BRUTE FORCE LOGIN PAGE PROTECTION
# Protects the Login page from SpamBots & Proxies
# that use Server Protocol HTTP/1.0 or a blank User Agent
RewriteCond %{REQUEST_URI} ^(/wp-login\.php|.*wp-login\.php.*)$
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{THE_REQUEST} HTTP/1\.0$ [OR]
RewriteCond %{SERVER_PROTOCOL} HTTP/1\.0$
RewriteRule ^(.*)$ - [F,L]

Ongoing issues that occur with every BPS version release are these common issues:

Broken cPanel HotLink Protection Tool problem
http://forum.ait-pro.com/forums/topic/read-me-first-free/#cpanel-hotlink-protection

WordPress flush_rewrite_rules function problem
http://forum.ait-pro.com/forums/topic/read-me-first-free/#flush-rewrite-rules

Just upgraded to .49.4 and the issue is still there. This is across several servers, but they are all running Plesk 11.x on Media Temple.

Thanks,
Tim

I tried creating a fresh secure.htaccess and applying that, just to be sure. No luck. I get the 403 forbidden error until I comment out this code:

# BRUTE FORCE LOGIN PAGE PROTECTION
# Protects the Login page from SpamBots & Proxies
# that use Server Protocol HTTP/1.0 or a blank User Agent
RewriteCond %{REQUEST_URI} ^(/wp-login\.php|.*wp-login\.php.*)$
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{THE_REQUEST} HTTP/1\.0$ [OR]
RewriteCond %{SERVER_PROTOCOL} HTTP/1\.0$
RewriteRule ^(.*)$ - [F,L]

This happens in multiple browsers, on multiple computers, from multiple locations. It’s also multiple sites on multiple servers, but as I said before they are all Plesk 11.x / Media Temple servers, so the configurations are similar.

Here is an example of my User Agent as PHP sees it ($_SERVER[‘HTTP_USER_AGENT’]): Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36

Here’s a screenshot of apache modules running on the server: http: //cl.ly/image/1z3B2i0r3x2M

Any particular info that would be helpful?

Thanks,

Tim

Post a link to your site and I will check your Headers for HTTP/1.0.

Ok I did not think this would an issue, but apparently it looks like it might be a problem.  Will need to look into this some more.  The code is designed to only look at the login URI so not sure why this Header is being displayed on your login page???

HTTP/1.0 200 Ok
Last-Modified: Fri, 11 Oct 2013 00:09:19 GMT
Expires: Fri, 18 Oct 2013 00:09:19 GMT
Content-Type: application/ocsp-response
content-transfer-encoding: binary
Content-Length: 1443
Cache-Control: max-age=339854, public, no-transform, must-revalidate
Date: Mon, 14 Oct 2013 01:45:05 GMT
nncoection: close
Connection: Keep-Alive

Ok for anyone whose Server has issues with the new Brute Force Login Protection code then just remove it at this point.  We will gather additional information about these Servers to find out if this code can be adapted to work on these Servers, but most likely it will just not work for some folks.  This is still considered a fairly isolated issue that is occurring on a small percentage of Servers/Hosts/Environments/Websites so once we have full documentation of what is unusual or different about these cases then we can make a final determination on whether this code can or cannot be adapted to work on these Hosts/etc.  bear with us, but for now remove the new code.

All 3 resulted in the 403 error — I double checked each. Here’s the code I’m using that is currently allowing me access (the [OR] is removed). Does this not offer the same protection? My understanding of .htaccess rules is limited.

# BRUTE FORCE LOGIN PAGE PROTECTION
# Protects the Login page from SpamBots & Proxies
# that use Server Protocol HTTP/1.0 or a blank User Agent
RewriteCond %{REQUEST_URI} ^(/wp-login\.php|.*wp-login\.php.*)$
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteCond %{THE_REQUEST} HTTP/1\.0$ [OR]
RewriteCond %{SERVER_PROTOCOL} HTTP/1\.0$
RewriteRule ^(.*)$ - [F,L]