Brute Force attack protection not working?

I’m also curious, since we also have the feature enabled, and the widget shows a count of 75,233, though I have no idea of the time period for that.

Our host provided us with this data, which happened within a 10-minute window and coincided with a spike in CPU and I/O on the site (causing it to go offline for 3 or 4 minutes). The first column is the number of attempts. There’s no way they should have been able to get off this many attempts.

20 103.210.32.6
20 115.31.148.235
20 178.222.227.196
20 187.95.111.135
20 213.159.45.55
20 75.88.185.144
20 85.85.77.83
21 178.152.103.217
21 39.36.52.24
21 91.124.237.172
22 213.233.96.128
22 2800:810:43f:80da:9861:7f7b:7b17:9a7f
22 79.118.49.222
24 1.0.153.130
24 37.231.101.54

Sorry about the delay in writing back to you.

@elvis1973 The Protect feature is definitely active and working on your site; I can see it in our logs.
@bjf2000 I don’t know your site URL so I can’t really tell you much about your site.

In any case, I’d love to know more about the data you provided. Are those IPs recorded when someone tries to use the default log in form on your site, or attempts to make an XML-RPC request? If the attempts / visits happen somewhere else (like in other log in forms, or even visits to your home page), Jetpack Protect won’t see or track them.

Thanks for all the extra info you may be able to provide! If you’d rather tell me more about your setup in private, you can use this contact form.

In our case, the site is behind CloudFlare. Does that skew things?

The data I posted was after an inquiry made to the host trying to understand why we’re having recurring, minutes-long outages. That data represents a 10-minute period, during which the outage occurred. The host described it as “Suspicious requests to your wp-login admin area,” and referred to the data as “Amount of request for admin area and xmlrpc file for mentioned period.”

In our case, the site is behind CloudFlare. Does that skew things?

It won’t, no. Some IPs will get blocked before they even reach your site, but that’s it.

The host described it as “Suspicious requests to your wp-login admin area,” and referred to the data as “Amount of request for admin area and xmlrpc file for mentioned period.”

Could you ask them if those were GET or POST requests?

Thanks!

This is their response:

As far as I see that data are GET requests:
###
181.90.182.148 – – [28/Sep/2017:18:58:01 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
177.13.235.144 – – [28/Sep/2017:19:06:51 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:22 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:25 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:27 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:28 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:29 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:30 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:31 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:31 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:32 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:33 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:34 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:40 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:41 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:42 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:43 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:44 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:45 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”
85.220.99.138 – – [28/Sep/2017:19:09:46 -0400] “GET /wp-login.php HTTP/1.1” 302 – “-” “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1”

As far as I see that data are GET requests

In this case I’m afraid Jetpack won’t be able to help with those. The Protect feature only monitors attempts to log in to your site or to send/request data to your site via the XMLRPC file. When someone accesses the log in page but does not submit the form, Jetpack does not see them. They are only visitors at this point.

Later on, if they actually enter data in the form and submit it to try to log in, Jetpack will see them; it they do it multiple times without using the right credentials Jetpack will then block them from doing any more attempts.

Does that clarify things a bit?

Yes, that makes sense.

I think ultimately what you say at the end must be happening, despite the few log examples I was given, since the JetPack Protect count is over 450 points higher today than it was close to a week ago. It wouldn’t make any sense if all of these visitors from very far-off lands were just showing up and doing nothing, unless, I guess, some are just interrogating the site looking to see what flaws might exist.

Thanks