Registration Form Timer 2.0

[0ptima]

The larger your database is the larger your backup will be. And backup space and backup time (first and foremost) is a premium if you take backups seriously.

I take backups very seriously and perform daily off site backups plus they are tested on a weekly basis.

You're making it sound like each additional user takes up megs of space. Will the few extra bytes added per user really make a difference on backup time (mysql dump + gzip)?

 

[Walter]

Will the few extra bytes added per user really make a difference on backup time (mysql dump + gzip)?

I get hundreds of new spam registrations daily. Multiply that with 3 years. Thats a few 100,000 records that simply make no sense.

 

[Biker]

The larger your database is the larger your backup will be. And backup space and backup time (first and foremost) is a premium if you take backups seriously.

Don't forget bandwidth. My backups are counted towards my monthly allotment of bandwidth as they're immediately shot over to a remote FTP server upon completion each night.

 

[Chris D]

Just to put an end to this, I am not going to be implementing the suggestion so I would recommend making a request in the appropriate forum

 

[MikeK]

This is the capability that convinced me to try XenForo as a replacement for our aging vBulletin 3.8 platform. The spam attacks were getting to be such an nuisance, with over 100 per day, that I went to manual verification for all new members.

I installed the spam blocker for vBulletin (I am not the developer), which appears to be similar to this product, and nearly all of the bot spammers were stopped at the gate. I modified the original code to add a logging feature so my inbox wasn't clogged with the results and set the registration time to 30 seconds. This time was based on several trial periods to determine the best trip point to block most spammers and not block any real users.

If anyone is interested in the results of the vBulletin product, this graph represents about 18,000 blocked attempts from November 2012 through May 2013.



Based on this, I am moving forward with the migration from vBulletin to XenForo.

 

[MattW]

That's pretty much what I'm seeing on my forum

 

[The Sandman]

Is there a way to use the Stopbotters API to filter existing users for banning or deletion using the batch user processor to weed out some of the spammers already registered before the addon was installed?

 

[Chris D]

That's a question for @tenants

 

[The Sandman]

That's a question for @tenants

I think I will ask tenants then.

Thanks!

 

[whynot]

Using XF 1.2.1

If enabled, attempts will be logged in the database. This log can be viewed here.

Error

The requested page could not be found.

What can be problem?

 

[Chris D]

I think it's just a typo in the link to be honest

I thought I had sorted it a LONG time ago. Clearly not.

The actual log can be accessed from Admin CP > Tools > Reg Form Timer log.

 

[whynot]

The actual log can be accessed from Admin CP > Tools > Reg Form Timer log.

Thank you, Chris! 5 stars!

What??? 7 pages in a few hours?
I'll need another server just for this addon...
(Joking only)

 

[whynot]

Some funny results:

Yesterday at 6:15 PM - :108.178.48.187 - 1378282558 seconds
StopBotters found the following param in their database ip_address: 108.178.48.187

aalexxxvls Yesterday at 6:14 PM - aaallleeexxx2233@gmail.com:31.170.174.170 - 1 seconds
StopBotters found the following param in their database email_address: aaallleeexxx2233@gmail.com

StopBotters found the following param in their database username: aalexxxvls

Yesterday at 6:03 PM - :192.184.92.26 - 1378281784 seconds
StopBotters found the following param in their database ip_address: 192.184.92.26

Yesterday at 6:03 PM - :192.184.92.26 - 1378281781 seconds
StopBotters found the following param in their database ip_address: 192.184.92.26

Yesterday at 6:02 PM - :192.184.92.26 - 1378281778 seconds
StopBotters found the following param in their database ip_address: 192.184.92.26

Yesterday at 6:02 PM - :192.184.92.26 - 1378281775 seconds
StopBotters found the following param in their database ip_address: 192.184.92.26

 

[Chris D]

Some funny results:

The length of time?

Yeah. It seems like they've been attempting to register for nearly 44 years.

@tenants might be interested in it from a StopBotters point of view.

 

[tenants]

They're taking their time

Its a dedicated box (possibly set up as a proxy host, to use their bot with thousands of proxy addresses.. or just a XRumer box, which seems a bit silly if they aren't going to use multiple proxies)
192.184.92.26

The IP address is found in various spam databases
https://www.google.co.uk/?gws_rd=cr&ei=LXUoUr7sMqKR0AWmxoCQDw#q=192.184.92.26

The timing issue: It looks like they could be using a man in the middle approach to fake parsing your time param ... or just passing it in ... but, they can't do either with the core timer (so no need to worry) Interesting that it looks like they targeting timers, I think this is just a custom XRumer, someone looking for any params with "time" or something similar as a name, and then passing in a very high value (this is the most basic way of getting around some of the timers)... script pausing will come (but they wont wait 40 odd years )

 

[The Sandman]

I've gotten about a dozen of these errors in the past couple of weeks:

Server Error Log

Error Info

ErrorException: Fatal Error: Maximum execution time of 30 seconds exceeded - library/RegFormTimer/Model/StopBotters.php:146

Generated By: Unknown Account, Sunday at 2:24 AM

Stack Trace
#0 [internal function]: XenForo_Application::handleFatalError('http://www.stop...')
#1 {main}

Request State

array(3) {
  ["url"] => string(39) "http://adminextra.com/register/register"
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(18) {
    ["username"] => string(13) "biagmagliliex"
    ["email"] => string(22) "zkfpps@nikejashoes.com"
    ["password"] => string(8) "********"
    ["password_confirm"] => string(8) "********"
    ["dob_month"] => string(1) "7"
    ["dob_day"] => string(1) "6"
    ["dob_year"] => string(4) "1977"
    ["gender"] => string(4) "male"
    ["custom_fields"] => array(3) {
      ["interested"] => string(4) "Golf"
      ["software_used"] => array(8) {
        [1] => string(0) ""
        [2] => string(0) ""
        [3] => string(0) ""
        [4] => string(0) ""
        [5] => string(0) ""
        [6] => string(0) ""
        [7] => string(0) ""
        [8] => string(0) ""
      }
      ["whatdoyouwant"] => string(0) ""
    }
    ["custom_fields_shown"] => array(3) {
      [0] => string(10) "interested"
      [1] => string(13) "software_used"
      [2] => string(13) "whatdoyouwant"
    }
    ["timezone"] => string(10) "Asia/Seoul"
    ["captcha_question_answer"] => string(0) ""
    ["captcha_question_hash"] => string(40) "f7fb1c8ddee10348a93edd1eef0b19bf2f7b0c20"
    ["agree"] => string(1) "1"
    ["submit"] => string(7) "Sign Up"
    ["_xfToken"] => string(8) "********"
    ["reg_key"] => string(32) "988c1197b63c231ce160dbb5e904b0b8"
    ["time"] => string(10) "1379226280"
  }
}

 

[Chris D]

@tenants is the author of that particular piece of code.

Maybe there were some issues on his end.

 

[tenants]

That implies the StopBotter API took longer than 30 seconds to respond... It shouldn't be throwing this even so (if the server is down, it's caught and ignored, and the API is skipped)

I use this API on 4 of my board (some hit by bots regularly), and I haven't seen this oO

It's a warning (not an error), which I didn't catch...

All you need to do to prevent getting this warning is edit this file
library/RegFormTimer/Model/StopBotters.php

at line 146, where you see:

$jsonResponse = file_get_contents($jsonRequest);

put an @ in front of the file_get_contents, like this:

$jsonResponse = @file_get_contents($jsonRequest);

That will prevent the warning propagating (and the API will be skipped when it's slow)

- Why the API is running slow is another matter... (I did move it do a different box about 3 weeks ago, but it should have been faster, I can look at improving performance of the API)

 

[Chris D]

OK. Thanks @tenants.

I will be releasing a 1.2 update of this eventually, I think. (If that's ok with you). That removes my registration timer, uses the default one, but still interrogates StopBotters.

Will probably have to rename it as it won't really be a Reg Form Timer anymore!

 

[The Sandman]

Thanks tenants! I modified the file as shown.