arronrouse

OK, looks like it was bad login attempts after all. Zero visitor count since adding the exclusion. Which leaves the question:

Is there any way to remove those false visitors from the database? Fine with doing it in SQL if needed.

Thanks for the help.

P.S. The login page wasn’t in the exclusions. Have switched it off. Will see if it makes a difference and keep you posted.

Hi Reza,

don’t think that’s it as thousands of visitors have been added to previous months and years!

“Last year” went from having a few thousand entries to 111,002. Don’t look at the stats that often so not sure when this started.

Happy to send you the table or tables if you want?

Hope you’re having a good day,

Arron

P.S. This isn’t happening on my other server which was built more recently. It has the same plug-ins and gets around the same number of crawlers/bad-login-attempts.

Problems seem to be fixed in v13.2.8 — WP Statistics now seems to work properly with WP Super Cache and the code looks like it should work with all other caches too.

Thanks Mostafa ??

OK, this AM there are loads of locked IPs in the Activity list. Phew! Thanks ??

It does leave some questions and thoughts though…

I run two different sites and one of them had ~2500 login attempts over the last two weeks (can provide a dump of the wp_login_fails table if you want) with most of the IPs repeating 5+ times. Alongside your Retry Time Period Restriction setting, would it be a good idea to have other settings to deal with that kind of distributed attack? E.g. instant lock out for a list of user names because no one trying to login in as “admin” has good intentions?

Would it be a good idea to show failed logins on the Activity tab even if they weren’t locked out? Just a simple last 30 days or last 50 entries from wp_login fails? I’m not comfortable with ~2500 login attempts but no heads up.

On the bright side, we now know Simple History is compatible with your plug in. (There’s my heads-up.)

Where are these attacks coming from? Almost all of them are from server hosts of one kind or another. I suspect the plugin installed before yours, Limit Login Attempts Reloaded, makes sure you get plenty of failed logins to encourage you to sign up for their paid service. Life is too short for me to do a code review and Wireshark it so I don’t have proof but let’s just say there were a lot of fingerprints ??

Anyway, the above are just suggestions/comments not expectations. Thanks again for the help and the plugin ??

• This reply was modified 2 years, 4 months ago by arronrouse.

That’ll be it. Looking through the data, the attack is spread across multiple IPs with each one being used less than once per hour. Presumably to dodge most time-based restrictions.

I’ve set it Max Login Retries to 1 so we’ll see what that does. About to clock-off for the day, will update you in the AM.

Thanks again for the help.

Rats, spoke too soon. Just got another few “Failed to login with username “xxxxxxxx” (username does not exist)” but Login LockDown shows zero activity when it should have locked them out.

Update: I put in an XMLRPC blocker and the login attempts have gone back down to zero.

According to the logs, the login attempts started up again right around the time you posted that response. What a strange coincidence… Maybe the attackers took a two month break until they saw your response… No smell of scammer at all about that at all, no siree.

Short history:
I installed the Limit Login Attempts Reloaded plugin many months back and got suspicious because it was recording hundreds of attempts a day — far more attempts than visitors — and there were several other signs it was a scam.

So I got rid of it and installed your plug in. Everything went to zero and all seemed good.

But there was never anything in the Activity tab and that eventually got the spidey senses tingling so I installed Simple History.

Stuff is still going into the wp_login_fails table (I assume that’s one of yours?) even with Simple History installed but no one is getting blocked and nothing is on the Activity tab.

Like I said, “Lockout Invalid Usernames” is set to Yes and all of the login fails are from invalid user names.

Obviously this isn’t an easy thing for me to test because I don’t want to block my own IP address. But I risked it anyway and a wrong user name just rolled me back to the login page with the standard WP error message.

P.S. Thanks for the quick responses!

I’ve been running Login LockDown for months. I only installed today Simple History because it seemed strange there was zero on the Activity tab after all that time. There are loads of failed attempts in the wp_login_fails table.

Maybe it’s a remnant of the weekend but the new issue is not clicking with me — as in I don’t get it, what’s the issue? (No need to explain unless you think I can help somehow.)

I don’t think the API needs to be completely headless, just that it needs to generate the server-side variables. Remember most of the variables will cache correctly. E.g. exclusion_match and exclusion_reason should be fine because the cached file will generate for the first visitor — logged in users normally bypass the cache. The only concern would be if you have code to exclude robots/spiders.

Guessed there must be plenty of extra parameters, e.g. I didn’t see where the user agent was coming in.

Speaking of user agent, a nice-to-have if you’re going with #1 would be for visits to be recorded as from the same visitor if there’s an IP/user agent match in the last 12 hours. That would be very little SQL and stop every visit being marked as a new visitor. But you probably already got that ??

Hi Mostafa,
I guess that means you’re using the nonce as a session id?

It’s a bit of a hairball because a lot of the decision belongs with the site owner — your customer — and not with the end user — the site owner’s customer. My take is to give the site owner as much of the decision as you can or at least give them the information they need.

The big problem here is you have no way to know if the site owner has asked the end user if cookies are allowed. Which means the options are:

1. No cookie (nor localStorage nor sessionStorage)
— do the fix I suggested above and generate a new nonce every time class-wp-statistics-api-hit.php gets a request
— every visit will appear in the stats as a new visitor. On high-traffic sites that won’t matter so much. (Maybe the stats could be sorted by IP/agent?)
— completely GDPR compliant

2. Use a cookie (or localStorage or sessionStorage)
— still needs the fix in the first post but with a check if the nonce exists
— Make the site owner confirm they get end user permission to store stats cookies
— completely GDPR compliant (because it’s the site owner who is liable not you)

3. Use a server-side PHP session
— I’m not a PHP dev so am not certain this would work
— still needs the fix from the first post but with a lot more in class-wp-statistics-api-hit.php
— completely GDPR compliant
— would need the site owner to confirm PHP sessions are acceptable

What would I do?
I’d go with the 1. No Cookie option and put a friendly warning next to the Enable Cache setting in WP Statistics. Something to let the site owner know. It’s the simplest option, requires the least coding on your part and means useful stats are collected. If your users want something better, it gives you time to think.

Hope this helps

BTW, I really like the API route for recording the stats. If you’re maintaining two different sets of code to record hits, I’d focus on this one and steadily sunset the other one.

I’m not a PHP coder so please forgive me if this is a dumb question…

Could you move the nonce and exclusion parameters into the API file — class-wp-statistics-api-hit.php?

Because the problem is both the nonce and the exclusion parameters are getting cached. But in my uneducated head, it should be possible to generate those parameters in the API PHP file instead. Which would fix the bug.