Reply To: Protect Login Page from Brute Force Login Attacks

While I am working my way up the learning curve, I have very little understanding of exactly how BPS and the htaccess logs work. I know just enough to be dangerous. If this topic is discussed elsewhere, please point me in that direction.

I have BPS Pro with Brute Force Login Page Protection in the custom code in the .htaccess file.  JTC Anti-Spam is also set up. I have verified on my .htaccess file that the Brute Force Login Protection code is in the file.

The type of  Brute Force Login Page Protection used is the one that protects the Login page from SpamBots, HackerBots & Proxies that use Server Protocol HTTP/1.0 or a blank User Agent.

The logs are showing that one of my sites is having repeated break-in attempts averaging 14 per minute for the past few hours.

I have read the full 8 page post on “Protect Login Page from Brute Force Login Attacks.” On post #7032, it says,

“Automated Brute Force hacking scripts typically use cURL to GET your login page and then the script will start executing POST Brute Force password cracking.  So if GET is blocked based on the HTTP/1.0 Server Protocol then the cURL GET is blocked/Forbidden before POST ever comes into play.  In other words, this allows someone to prevent the first part (probe, recon, etc) of the automated Brute Force hacking method from even getting to the WordPress login page.”

Below is an example of one of the logged items. It shows REQUEST_METHOD: POST.

There is also an attempt at entering a username and password under REQUEST BODY.

[403 POST Request: January 17, 2016 - 12:59 pm]
Event Code: BFHS - Blocked/Forbidden Hacker or Spammer
Solution: N/A - Hacker/Spammer Blocked/Forbidden
REMOTE_ADDR: 104.131.177.67
Host Name: canadattatv.com
SERVER_PROTOCOL: HTTP/1.0
HTTP_CLIENT_IP:
HTTP_FORWARDED:
HTTP_X_FORWARDED_FOR:
HTTP_X_CLUSTER_CLIENT_IP:
REQUEST_METHOD: POST
HTTP_REFERER:
REQUEST_URI: /wp-login.php
QUERY_STRING:
HTTP_USER_AGENT:
REQUEST BODY: log=admin&pwd=pillow

Question 1: Is this just a log of a blocked event?
Question 2: With the JTC Anti-Spam in place how come some many rapid fire attempts can be made?
Question 3: is there any significance to the REQUEST_METHOD being POST?
Question 4: While it shows “Solution: N/A” is there anything else that should be done aside from whitelisting?

Thank you