Brute-force protection stats

Hi @kcrawford25 –

This number is the number of attacks that we have logged on our end. These could include attacks against wp-login.php and over XML-RPC. We only log the number of attacks, not details about them.

In addition to requiring a client certificate to access the wp-login.php, I also have the following configuration in nginx to prevent access to xml-rpc:

	location ~* /xmlrpc.php$ {
		deny all;
	}

Looking at the number in the Brute Force Protection card today, it is up to 28,287 attempts blocked which is 910 more attempts than 4 days and 3 hours ago. This seems wildly inaccurate given the traffic this small site receives.

Hi @kcrawford25 –

I’m checking with our development team for more insight on this. We’ll let you know what we find out as soon as we hear from them.

Thanks for the update. For now I have disabled Brute Force Detection and plan to analyze the nginx logs.

Hi @kcrawford25 ,

Some additional information for you!

These stats specifically relate to blocked login attempts – when the login screen is loaded we first make a request to Protect to check the status of the current IP. If data is found, the API response should supply us detail on how to present the login (show a math auth, or a hard blocked notice). If the attempt subsequently fails, I?believe?that is where we log stats. At least at this point, I am not entirely aware of any other measures Brute force verifies that would add to this count.

In this case, it’s possible the custom rules you have in place might be interfering with process in some way since it seems like they already deny access to the login unless certain parameters are met. It could be that, or the site could actually be under attack and Brute force is just doing its job.

Without more information it’s hard to offer a clear answer and even with more information I am not sure we could offer a more certain answer.

I hope that helps!

Best,

Cena