I have reCaptcha installed on my site and I also have the hack to prevent direct access to register.php, but I'm still getting a lot of spam registrations. Most of these are never activated so they can't do anything on the site. That suggests they are bot registrations.

Has anyone had a similar experience? Is there any way I can find the IP address of the machine registering when the "user" does not complete the confirmation step?

barryC

Search your Apache logs for register.php

I have done so and there are some corresponding entries that seem to be too fast for humans to do. I am getting hammered by these spam registrations at the moment, at least 6 ore more a day. All of them are using spoofed email addresses, sometimes from Russia (ending in .ru) sometimes gmail addresses. They are therefore not getting the confirmation emails and so far none have activated the account. I just got a bounce message from Google that one of those addresses did not exist.

I will search the logs again. Maybe you'd be willing to look at a log segment again for me Ghia to see if you agree that it looks as if someone has found a way around reCaptcha and the hack to prevent direct access to register.php.

At the moment they are just a bloody nuisance. They are pretty easy to spot as they usually use the same unlikely first name and last name, which are required on my site. As they haven't confirmed registration they can't do anything on the site. I hope they soon tire of the game. I know I have.

Ghia, if you are willing to look at a log segment, remind me of your email by PM. If I can be sure of the IPs that correspond to the spam registrations, from the logs, I can look into where they are coming from, as long as the IPs aren't spoofed. Thanks.

barryC

I am still getting hammered by these spam registrations, several a day. The IP address is different for each one so it is apparently being spoofed. I can't block the offending IP. Below is the log entry for one of these registrations. I have X'ed out my real site name.

This registration took 6 seconds. Another one a few minutes later took 9 seconds. The next one reported "Mozilla/4.76 [en] (Windows NT 5.0; U)" not Opera.

[Edit] I found a real registration for comparison, which appears to have taken the person about 2 minutes.

I'd be interested in opinions as to whether this looks like a bot or a person doing the registration. All so far are using spoofed email addresses so they never get confirmed. They are a damn nuisance, though.

barryC

199.15.234.20 - - [18/Jan/2011:14:21:46 -0700] "GET /xxx/modules/newbb/index.php HTTP/1.0" 200 67607 "http://www.xxxxx.org/xxx/modules/newbb/index.php" "Mozilla/5.0 (Windows NT 5.1; U; en) Opera 8.01"
199.15.234.20 - - [18/Jan/2011:14:21:47 -0700] "GET /xxx/register.php HTTP/1.0" 302 378 "http://www.xxxx.org/xxx/register.php" "Mozilla/5.0 (Windows NT 5.1; U; en) Opera 8.01"
199.15.234.20 - - [18/Jan/2011:14:21:48 -0700] "GET /xxx/modules/profile/register.php HTTP/1.0" 200 54826 "http://www.xxxx.org/xxx/modules/profile/register.php" "Mozilla/5.0 (Windows NT 5.1; U; en) Opera 8.01"
199.15.234.20 - - [18/Jan/2011:14:21:49 -0700] "POST /xxx/modules/profile/register.php HTTP/1.0" 200 64148 "http://www.xxxx.org/xxx/modules/profile/register.php" "Mozilla/5.0 (Windows NT 5.1; U; en) Opera 8.01"
199.15.234.20 - - [18/Jan/2011:14:21:51 -0700] "POST /xxx/user.php?op=login HTTP/1.0" 200 2872 "http://www.xxxx.org/aka/modules/profile/register.php" "Mozilla/5.0 (Windows NT 5.1; U; en) Opera 8.01"
199.15.234.20 - - [18/Jan/2011:14:21:51 -0700] "GET /xxx/index.php HTTP/1.0" 200 67602 "http://www.xxxx.org/aka/index.php" "Mozilla/5.0 (Windows NT 5.1; U; en) Opera 8.01"
199.15.234.20 - - [18/Jan/2011:14:21:52 -0700] "GET /xxx/modules/newbb/index.php HTTP/1.0" 200 67549 "http://www.xxxx.org/xxx/modules/newbb/index.php" "Mozilla/5.0 (Windows NT 5.1; U; en) Opera 8.01"

It is a typical bot registration sequence. The IP's seems random, but are mostly hacked PC's and servers, which are part of a botnet.
And yes, reCaptcha is not as strong as it was before.
Or in other words, it has become easier to crack them in an automated way by OCR.
Sometimes making additional registration pages may help also.
Try the Sexy Captcha or make a variation in the original XOOPS captcha configuration.
If you are not expecting Russian subscribers, ban the email .ru domain in the preferences.

ghia,

a question. In the profile module there is an option to "save after step". I have two steps but they are set to be saved. I THINK that setting save after step makes the additional steps unnecessary. Is that right? Would it be better to have the first step NOT saved so that the user has to complette both before the registration is accepted?

Is sexy captcha this one posted by frankblack? I just want to make sure I'm identifying the right one, but going back to the beginning of that thread, I assume it is.

I visited frankblack's web site and downloaded the files. So you recommend the version modified by culex rather than the original?

I want to try this for the registration page. However, it's not clear to me how to do this. Where does one insert the codes indicated on frankblack's web site?

Sorry if I seem dumb. I'm no programmer.

barryc

Quote:I think it is best to not save anything, until both steps were completed.
And Yes the checks in Profile are not advanced enough.
Also the required fields are only verified by the users side with Javascript and not on the server with PHP.

Quote:Yes, but you must have the one from here
Quote:If you have other JQuery things in your theme, it will give less problems. (see link above)
Quote: It is similar to the reCaptcha for install.

Thanks ghia. I'll see if I can install it this weekend. In the meantime I have set my site to require webmaster approval of new registrations so no spam gets through.

barryC

It would be great if new registrations ONLY happened if ..

1. They filled out the 'confirmation email', with a valid address (so mandatory)

2. If a bounce came back, then no registration.

Just my 0.001 cents worth,

Peter

The GET request for register.php is using register.php as referer, which is wrong. It should be any other page on your site except register.php.



So, we need to exclude that URL as a valid referer. I'll take a closer look at it as soon as I get some time.

To be honest, using register.php twice during the registration process (to register and to validate) and adding the profile module's own version of register.php has made this far more complicated than it ever used to be.