New set of user registrations getting through

Hi @davidborrink, thanks for your message and sorry to see you’re having trouble with this.

There are a couple of things you can try to stem the flow of spam registrations. I have seen rogue users potentially trying to come through XML-RPC, which can be disabled. “Disable XML-RPC authentication” appears in Wordfence > Login Security > Settings. You can also block this route entirely using .htaccess, provided you don’t use the WordPress app or a plugin that requires it such as Jetpack:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

You could also enable reCAPTCHA for registration/logins using our Login Security module to ensure humans are able to complete the form, but it should block automatic bot registrations as these appear to be from the usernames.

Let me know how you get on!
Peter.

Thanks, Peter. I set that setting in WF and they were still getting through. I tracked the traffic in the Tools panel and kept seeing the various attempts, and the email notes just kept coming with new users, but I deleted them within minutes. The locations and IPs in the Tools window were lining up with times that the new users were showing up and I did take their IPs and put them in my server’s firewall rules for WordPress. But still they kept coming.

I took another tactic. I went to my server access logs and matched the times that WordPress notes were saying the user was added, and then I was able to find them on the access logs, right down to the second. I could see that the same IP address was doing the actual registration moments, and it was NOT on WordFence’s traffic list. All fifteen incidents were located on my log file that way and the IPs all matched, to someone in Kiev. Ukraine was nowhere to be seen on the WordFence traffic list.

So, I put his IP address, and the entire block from the last set of numbers on a server ban.

The rest of the day has been quiet. Hopefully this will be the end of him

add_filter( 'registration_errors', 'deny_sibbnk_usernames', 10, 3 );

function deny_sibbnk_usernames( $errors, $sanitized_user_login, $user_email ) {
    if ( false !== strpos( $sanitized_user_login, '@sibbnk' ) ) {
        $errors->add( 'username_not_allowed', __( 'Sorry, usernames containing "@sibbnk" are not allowed.', 'textdomain' ) );
    }
    return $errors;
}

Put this on functions.php on your theme or on the snippets plugin =).

Was having the same issue just now.

Hi jrubimf, thank you for sharing that. Maybe I’ll use that if I have the problem again. I’m not having the problem anymore because the second day started with a new set of names and I traced the IP address on the first instance to another location different than the previous day. My guess is that the person doing this was using a proxy IP address and maybe realized I had figured out how to stop them at server level and gave up. I’ve had no problem since then.