.49.3 mod_security issue – code mod pending for .49.4

Home Forums BulletProof Security Free .49.3 mod_security issue – code mod pending for .49.4

This topic contains 20 replies, has 5 voices, and was last updated by  AITpro Admin 3 years, 7 months ago.

Viewing 15 posts - 1 through 15 (of 21 total)
  • Author
    Posts
  • #10466

    Oscar Polat
    Participant

    I have been using Bulletproof free plug-in for some time without any problems and I upgraded this plug-in many times  without any problems but after upgrading to version .49.3, I am unable to log-in or log-out and I get 403 error. There is a lot of information about this error online, so I started reading about it, but I never had this problem before it has started after the latest upgrade. I restored my backup before the upgrade, I am not sure how i can upgrade now, or if I should upgrade.

    #10470

    AITpro Admin
    Keymaster

    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

    #10477

    Tim
    Participant

    Also ran into this problem, and the new version of the Brute Force protection that is posted here didn’t seem to fix the problem. I’ve removed it entirely for now.

    Thanks,
    Tim

    #10494

    Tim
    Participant

    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

    #10495

    AITpro Admin
    Keymaster

    The code has been changed, but since this was a very isolated issue that did not affect that many folks we decided not to automatically remove the older code that is problematic for a few people.  For the people this did affect they can click the activate root BulletProof Mode again to resolve the issue.  Anyone who is upgrading from .49.2 to .49.4 will automatically have the new code created instead of the older potentially problematic for some Servers.

    Sounds like you have a different issue going on.  Please provide as much details as you can of the issue that is occurring.

    #10499

    Tim
    Participant

    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

    #10500

    AITpro Admin
    Keymaster

    Hmm so when you remove this code then the 403 error no longer occurs anymore?  If that is the case then the other part of the code that could be an issue on your Server would be the Server Protocol HTTP/1.0 condition.  Are you using an older Proxy software?  Older versions of Proxy software still use the old HTTP/1.0 protocol that was phased out back in 1999 with the new protocol HTTP/1.1.  Older versions of Squid Proxy use HTTP/1.0.  Test this code below and let me know if you get a 403 error.

    # 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]
    #10501

    AITpro Admin
    Keymaster

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

    #10503

    Tim
    Participant

    Commenting those lines out does fix the problem, but also removing the [OR] from this line fixes the problem:

    RewriteCond %{HTTP_USER_AGENT} ^$ [OR]

    It’s not included in the example you just posted, but when I go and activate it, it is included.  kansascityrentahome.com is an example of a site having this issue.

    #10504

    AITpro Admin
    Keymaster

    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
    #10512

    Szabolcsx
    Participant

    Same problem with me too. 49.4 update did not correct it…

    http: //onlinekampanykeszites.hu/wp-login.php

    #10515

    AITpro Admin
    Keymaster

    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.

    #10526

    AITpro Admin
    Keymaster

    @ Tim – please test this code below and let me know the results.  The OCSP Header was not coming from your login page and was coming from another page on your site so this should not be a factor.

    # 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 %{SERVER_PROTOCOL} HTTP/1\.0$
    RewriteRule ^(.*)$ - [F,L]

    Next test this code and let me know the results.

    # 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 %{SERVER_PROTOCOL} HTTP/1\.0$
    RewriteRule ^(.*)$ - [F,L]

    Next test this code and let me know that results.

    # 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$
    RewriteCond %{SERVER_PROTOCOL} HTTP/1\.0$
    RewriteRule ^(.*)$ - [F,L]
    #10531

    Tim
    Participant

    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]
    #10534

    AITpro Admin
    Keymaster

    Oh well.  Thanks for trying.  We have conclusively found that the Server Protocol HTTP/1.0 condition just does not work on some Servers.  This code is primarily designed to block automated hacker bots and spam bots, but BPS does still offer protection from spam bots and hacker bots.  The nice thing about this code on Hosts that this code does work fine is that it gets rid of all the excess auto-posting attacks that go on.

    On our sites it filters out somewhere in the neighborhood of 300,000 spambot / hackerbot attacks per month.  😉

    http://forum.ait-pro.com/forums/topic/protect-login-page-from-brute-force-login-attacks/#post-7312

Viewing 15 posts - 1 through 15 (of 21 total)

You must be logged in to reply to this topic.