You don't have permission to access /wp-login.php on this server.

https://forum.ait-pro.com/forums/topic/protect-login-page-from-brute-force-login-attacks/

This will block/Forbid around 98% of automated Brute Force Login hacking attempts since typically Server Protocol HTTP/1.0 is used in these automated Brute Force Login Attacks. This code has a 95%/5% success fail ratio meaning that this code works on 95% of websites/Servers and does not work on 5% of websites/Servers.

The issue/problem is either that your host is using a Proxy/Load Balancer on your hosted site server that is using the HTTP/1.0 Server Protocol. You can confirm that by checking your BPS Security Log for the log entry that relates to this 403 error…

…Or something you have installed on your computer or inhouse server is using the older HTTP/1.0 Server Protocol.

If the issue/problem is on your host server then there is not much you can do about this or you could try and contact your host about this and see what they say.

I run my own servers, but we actually just switched over to a newer server, and also installed a Nginx plugin, which works in front of Apache.
Is there any way to know if that’s causing it?
Thanks for the help!

Look at your BPS Security Log and post one of the Security Log entries for this issue.

Oh I meant to point out that the 2 blocks of code that you posted are redundant. The first block of code looks like older Brute Force Login protection code and the second block of code is the newer Brute Force Login protection code.

Newest/latest/most current

# BRUTE FORCE LOGIN PAGE PROTECTION
# Protects the Login page from SpamBots, HackerBots & 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]

The log doesn’t have anything in it – is it disabled by default?
And I realized that the code looked similar, I guess I’ll fix that, if we can get the server protocol issue figured out…
Thanks a lot!

Actually the Security Log is enabled by default, but if your server does not allow ErrorDocument directive logging in an .htaccess file then your server will override/disallow logging and nothing will be logged.

I guess check your Server logs and look for any of the 403 errors and post one of them here.

The only error I’m seeing is this:

[error] [client x.x.x.x] client denied by server configuration: /home/stream/public_html/wp-content/plugins/bulletproof-security/403.php

Is there any other way to track this down?

Something tells me that it probably has something to do with installing the NginxCP plugin in cPanel – maybe it’s passing on the wrong protocol?

(EDIT: Originally had a problem with the latest version, that I kept getting prompted to upgrade the CUSTOM CODE BPSQSE BPS QUERY STRING EXPLOITS code, but I saw that I had the last 2 lines that were mentioned in the What’s New page there, and I replaced those with the new line. I didn’t have the first too lines anywhere for some reason, but it now seems to be working.)

Thanks a lot!

That looks like the standard mod_security logging format “[error][client x.x.x.x]…”. mod_security will override BPS Security Logging depending on mod_security settings/config/SecRules/SecFilters. What you can do is temporarily turn off mod_security to check if the root cause of the issue is actually mod_security itself or to temporarily allow BPS Security Logging to work.

How to turn Off mod_security temporarily for troubleshooting
https://forum.ait-pro.com/forums/topic/how-to-turn-off-mod-security-mod_security-secfilterengine-off/

Yep, we had to change a couple of the root and wp-admin security filters and that Custom Code check is just to let you know that the code you have saved in Custom Code is not the most current BPS security code/filters.

Ok here is another thought. Do you allow other people to register, login, post comments on this website? If not, then you can use “IP based Brute Force Login Protection code” instead of using the Server Protocol based Brute Force Login Protection code.

I tried overriding it, and also disabling it temporarily globally on the server, but for some reason, I’m not seeing anything different in the logs.
I’m the main one who logs in, but once in a while someone else logs in as well, and I am also not always in the same place.
Is there anyway to use hostnames (including dynamic hostnames) instead of IP addresses, so I can cover wherever I may be?
Thanks a lot for all the help!

I think the only way you could do an “Allow from hostname” is if you have mod_authz_host.

https://httpd.apache.org/docs/2.2/mod/mod_authz_host.html

A reverse lookup would be done on the hostname to get the IP address for that hostname so I am pretty sure that would not work.

Also the hostname that Apache is seeing is of course the hostname of your server. ??

Most ISP’s do not change the entire IP address and typically only change the last or last 2 octets of an IP address so you can do this…

Allow from 99.88.
Allow from 100.55.
etc.

I should have mod_authz_host on the server.
If this whole thing isn’t worthwhile, I can probably comment out that line for now, and try to see if there’s a way to have NginxCP pass in the correct protocol, assuming that’s the issue.
Or in truth, I can just keep it as is, which locks everyone out, and in case I have to re-log in from anywhere, I can quickly comment out that line in the htaccess file, log in, and then remove the comment to lock everyone (else) out again.

Well you could try to comment out this line RewriteCond %{HTTP_USER_AGENT} ^$ [OR] but I seriously doubt that would cause the problem. The security filter primarily blocks by Server Protocol HTTP/1.0 so logically that is the issue. hackers and spammers use HTTP/1.0 because it allows them to do things that the new Server Protocol HTTP/1.1 does not allow them to do. HTTP/1.0 was phased out in 1999, but older versions of Proxy software still use/work using the older Server Protocol.

Yeah that seems a little extreme and involves manual stuff that will become irritating after a while. Another option is to use the Simple Query String protection code: https://forum.ait-pro.com/forums/topic/protect-login-page-from-brute-force-login-attacks/ or to install this plugin: Stealth Login Page which does the same thing: https://www.ads-software.com/plugins/stealth-login-page/

At some point we will add the Simple Query String Protection code as an option in BPS. Probably next version of BPS.

Just checking in to see where you are at. Did you decide to use the IP blocking code or the Stealth Login Page plugin?

Assuming that this is taken care of. If you have additional questions about this specific issue then post them.