Logging posts where captcha was not solved

Logging brute force attempts by IP is outside the scope of the plugin, but there are a number of other solutions that can help here, including Limit Login Attempts (which blocks by IP after too may failed attempts), web application firewalls like WordFence (which also log and block, among other things), and solutions at other layers besides the WordPress layer (such as upstream in firewalls, or at the web server level).

Of course, you use any of these at your own risk. Good luck!

Also @jdelisle the Google Captcha console will give you aggregate reports (not at the IP level) of how many successes and failures over what period of time.

Thanks @robertpeake for the quick reply.

I was hoping something would be logged in /var/log/messages or /var/log/httpd/* logs, as I’d like to integrate this with Fail2Ban to dynamically block these IPs. They’re obvious bad-actors.

Any chance you’d be interested in adding logging as a feature request? (assuming it’s possible)

• This reply was modified 5 years, 9 months ago by jdelisle.

With a reasonable threshold level for failed login attempts, it shouldn’t matter too much whether the failures were due to captcha or incorrect guesses of login/password details, since most real users will only guess so many times before using the “forgot password” feature. As a result, blacklisting at the WordPress level (via Limit Login Attempts, WordFence, etc.) with a good threshold should achieve a similar result as fail2ban (though I recognise fail2ban can block other connection attempts by the same IP, such as ssh, whereas WordPress plugins can only block web requests).

Also, whether or not PHP applications generate log entries in Apache depends on the server configuration, and can have unintended results when e.g. using user-generated warnings that could show up on the pages of some sites whereas others will log this result. And we should not assume all instances of WordPress are running under Apache anyway. So, it makes more sense to log IPs at the WordPress/MySQL level, which is another reason to consider a plugin.

Hope this helps!

@robertpeake Unfortunately it’s not that simple.

I’m experiencing a distributed slow brute force attack. So far, it’s from over 2,500 source IPs. Each source address makes an attempt every day or so. It’s coordinated, as they all seem to use the same user ID, and cycle through IDs simultaneously. It seems to be a targeted attack – they’ve identified several potentially valid user IDs to use in their attack, including the first and last names of many staff.

As a result of the above, plugins that look for e.g. 10 bad attempts from any single IP address are defeated.

Because the requests are legitimate requests, WAF is defeated. There’s nothing unusual about the request from the WAFs perspective – it’s just another login attempt, and the source IP isn’t doing anything that would trigger a WAF to block it.

I’m integrating with upstream firewalls, but the challenge here is separating the wheat from the chaff. I have to block the attack, and not block legit users who occasionally incorrectly key their ID or password.

I’m using WordPress plugins that logs failed authentication attempts, and use Fail2Ban to block IPs that fail to authenticate X times per day. However, as described above, this is defeated by using 2,500+ source addresses and slowing the attack down. One failed login attempt occurring every day or so makes it difficult to say “that’s a bot”. It could just as well be staff.

What I’m looking for is log output that indicates there’s been a failed login, the ID they submitted, the source IP, and the state of the captcha response (e.g. captcha solved or captcha unsolved). With this information, I could block source IPs with login failures where the captcha was unsolved, as it’s entirely likely that it’s a bot.

Hope that makes sense, and I’d love to hear any suggestions you may have. This has been a particularly difficult attack to stop.

With the constant changing of IPs, this sounds like a classic definition of DDoS. Even fail2ban probably won’t help you here, unless this is a simple attack using e.g. Tor exit nodes (which you can block as these are all published). However, if these are “zombie” machines or reverse/amplification attacks, trying to identify the correct “signatures” for attacks that rotate through IPs can be a complicated task.

I suggest looking into a sophisticated upstream tool like Cloudflare or Google Cloud Armor. If it is a personal site, Cloudflare will be free.

Again, all of this information is to be used entirely at your own risk and does not constitute legal advice.

Good luck! Sounds awful. :/

Yea it’s not a good thing, that’s for sure. The IPs are not TOR exit nodes, but they are mostly from outside north america (though not entirely). I suspect it’s someone’s army of compromised systems.

I’ll take a look at Cloudflare/ Google Cloud Armor and see how that may help.

On the bright side, if they’re failing to submit a solved captcha they won’t ever succeed in logging in, even with a valid credential, right?

Correct. Even if the login credentials are valid, if the captcha is not answered properly the login will fail and return the login page with an error message. Again, this only applies to wp-login.php and WooCommerce login pages. Custom login pages from third-party plugins and themes are not supported.

Good luck!

I’ve added code to your plugin to log failed captcha attempts via syslog. This should help considerably with my problem, and for others who use tools like Fail2Ban to dynamically manage firewall rules that protect their systems.

If you’re interested, let me know.

If this is a configurable option and well-tested, we’d gladly consider a pull requests: https://github.com/cyberscribe/login-recaptcha

Thanks!