Administrative and Maintenance Tools - vbStopForumSpam - known spammer lookup for new registrations

vbStopForumSpam

This provides access to a RBL type system for forum admins, listing known spam IP / email / usernames. The RBL database is provided by www.stopforumspam.com. You do NOT need an API key from the website in order to access the database. only to submit data if you should wish to do so.

At the point of user registration, the mod checks if the IP number / provided username / email addresses appear on a block list and can block the registration.

Whilst this isnt the most perfect way to stop all forum spam, its another step that spammers have to overcome.

VB4 here https://vborg.vbsupport.ru/showthrea...hreadid=230921
Its the same code, it works in 3.54 to 4.0


What it does

It checks with a remote database of known forum spammers. Their IP number, email address and forum username are tested and based on your configuration, you can reject / log / accept user registrations based on what you get back.

This version doesnt have
- whitelisting or the ability to submit users to the database but it will within the next week.
- automatic user deletion / post / PM purging. There are good tools out there already, this does something else.

Instructions are included in the installation.txt file - PLEASE read it first and dont forget to actually upload the files in the upload folder, otherwise it WILL kill your registration progress and you wont see the log file options in admincp. You do not need to download the product-vbstopforumspam-3.54.xml file unless you are using a vBulletin version older than 3.6.0

Changes to vB
- 3 new database tables
- 2 database table alternations
- No new templates.
- 2 Hook (register_addmember_process & register_addmember_complete)

Ive tested it but had feedback that it works with versions as old as 3.6.2... Support should go back to older versions, as long as they have hook support for register_addmember_process / register_addmember_complete

Known to work - tested by me
- vBulletin 3.6.8 on Apache 2.2 / PHP 5.1.2 on Linux using cUrl
- vBulletin 3.7 Gold on Apache 2.0 / PHP 4.4.3 on Windows without cUrl (template changes wont work on 3.7 - thats in the next version with auto template changes)

For code to submit spammers to the database, check this post for code changes
https://vborg.vbsupport.ru/showpost....&postcount=288

Reported in the thread to work
- 3.6.1, 3.6.2, 3.6.9, 3.6.10, 3.7.0, 3.7.1, 3.7.2, 3.7.3, 3.74, 3.80, 3.81, 3.82, 3.83, 3.8.4, 4.0beta3

If you have 3.54, then you can use the product-vbstopforumspam-3.54.xml file attached instead of the one in the ZIP file, which will allow older vBulletin versions to access this mods' features. I personally havent tested this version, its a user contribution, thanks to Darrell Mobley, that changes the way the XML works when imported into older versions.

Installers should remember to refresh their ACP navigation window when they first install it so they can see the new log file menu item.

REQUIRES MySQL 4.1.1+

Future versions
- Automatic integration into vBulletin to add users to the stopForumSpam.com database from a form
- Whitelisting of username / IP / email addresses
- AJAX integration to allow for lookups from within the users profile
- Decreased remote query count from three per user to one per user.

Versions / Changes

0.1 Initial Release

0.2 pedigrees special brew birthday release.
- Small security update. If you have 0.1 installed, download 0.2 and replace your existing functions_vbsfs.php with the one in the archive. It just tests to see if its running inside the VB framework before anything else. This is what happens when you code at 2am after drinking wine

0.3
- stopped it processing valid registrations twice
- moved all non-function code into the plugin. Not a big one as 0.2 basically did that
- fixed a typo in the log pruner that stopped it working (404)
- removed unused fields from the database for people with mysql that doesnt support varchar > 255 (ie mySQL4). If you have 0.2 installed and dont need to prune your logs just yet, you dont really need to install this version but can instead wait for 1.0 unless of a massive security update.

0.4
- logs registrations that arent/wouldnt be blocked
- fixed XML errors when username has a space it in
- tightened up the cache so that it doesnt test a username against an email name to give a bypass result (for when a username is an email address that isnt banned where the email address is)
- fixed some basic logic errors in the PHP

0.6
- Should work on PHP 4.4 now - rewrote the XML with PHP4 in mind (tested on Apache2.0/PHP 4.4.3)
- Fixed a caching system where data wasnt being updated correctly which could cause a remote query when one wasnt needed
- Possible false negative situation when a spammer was blocked due to SFS.com being down who then visited again when it was up but within the cache expiry time
- Remote query failure when the result page isnt XML should work a bit better now. It does a very basic test for valid XML results.
- Fixed log purging (again) and it should actually work properly now.
- No longer requires PHP5
- The log viewer now links to a user profile when registration is allowed.

v0.61 - Removed a template change that was invalid vBulletin code. The package you download will still say its 0.60 however

NB : When upgrading from any version to 0.6, you must remove and then add the plugin due to changes in one of the database tables

You need to have an API key from www.stopforumspam.com in order to submit data, its free and easy to get... You DONT need an API key in order to use this mod however, only to submit spammer data.

Issues are
- The usergroup permissions / view details etc DONT work. I jumped the gun and put the permissions controls in there before I put the code in. Please delete the includes/xml/bitfield_vbstopforumspam.xml file and rebuild your postbit

Installation
- Follow the instructions in the zip file, that includes upload the correct folders
- ONLY download the 3.54 xml file if youre using a vbulletin version prior to 3.6.0. use this file to install the mod instead of the xml file in the zip file.

Please click Installed

[johnfl68]

Is there a problem with this plugin?? Did the Spammers find a way around??? I have been getting many registrations the last few days from spammers, and most of them are listed on the Stop Forum Spam site, but are still being allowed to register????

John

[cad2go]

Originally Posted by johnfl68

Is there a problem with this plugin?? Did the Spammers find a way around??? I have been getting many registrations the last few days from spammers, and most of them are listed on the Stop Forum Spam site, but are still being allowed to register????

John

There was some downtime on the sfs site which meant that if you had the mod set to allow registrations if the ip/name/email check timed out they'd get through.

Had a couple of nasties myself

[Barteh]

Where is the vBSFS cache stored by the way, in the vB SQL db or a separate file somewhere?

[pedigree]

vbstopforumspam_remotecache table in mysq

Ive got a small bug fix due for release shortly, that touches on the caching

[Floris]

the problem continues, dropped you PM with the IP of the server.

[websissy]

Originally Posted by ascender

Exact same problem I'm afraid. Sorry, no idea how I ended up in this thread, thanks for the heads-up.

Try downloading the patches from this site again, Then obviously, you'll want to unzip them and then upload them to your server again. Certainly sounds to me like something got glitched somewhere.

I'm only running vb 3.8.1 on the site where I'm using this addon; but I'm not seeing any issues of the type you describe at all.

I'd say roll back and start over from the very beginning (including the download and the extract from the ZIP file) and see if that doesn't solve it. Also please note this comment from the install instructions:

If you cant see the logs in ACP/ Statistics and Logs, then you didnt upload the contents of the "upload" folder.... Its there for a reason, upload its contents to the root of your forum. This isnt an issue, its just something that 99% of the "it doesnt work" issues arise from

I doubt that it applies in your case; but it's certainly worth checking.

Good luck. Hope this helps!

[pedigree]

Floris is all fixed so just ascender to go.

[eoc_Jason]

If those numbers are right, and based on my log file, they certainly seem to be, how can that 30 minute local cache be blocking very many bots?

Let me try to explain it from how I've looked over the code.

The main need for the local cache is because of where the hook location is in the registration code. Pretend a person (or bot) messes up their registration and the system throws an error (say they messed up the CAPTCHA, or forgot to fill out a required field). The hook to check SFS occurs after every "submit" is hit on the registration page, but before vB error checking and final user saving is done. Thus if a bot is pounding the registration with failed attempts it would in turn be pounding SFS with the same query over and over again. The local cache alleviates this problem since the Username/Email/IP should be the same through several attempts to get a successful registration.

I think it would be okay to cache the definite hits for the long-term, but usually after failing in that one short time-span, you won't see the same user/email/ip combo again. (especially if you already banned the user, which would also prevent the same email address from being used). And if it's a dynamic IP, eventually a legitimate user *could* get blocked because you cached results for several weeks (or are not checking how recent the last bot was seen).

But anyhow, I think having a short local cache is more than sufficient. I've seen bots pound the registration with failed attempts, but still the local cache is not allways effective since they sometimes will try different usernames/emails/IPs when the previous attempt is not successful. Fortunately for me there's tell-tale signs of being a bot (i.e. 10 registration attempts in one second) which gets them submitted to SFS. Also I have other checking that I do before querying SFS to tell if they are a bot, that helps Pedigree out in reducing load on his server.

[websissy]

Originally Posted by eoc_Jason

Let me try to explain it from how I've looked over the code.

The main need for the local cache is because of where the hook location is in the registration code. Pretend a person (or bot) messes up their registration and the system throws an error (say they messed up the CAPTCHA, or forgot to fill out a required field). The hook to check SFS occurs after every "submit" is hit on the registration page, but before vB error checking and final user saving is done. Thus if a bot is pounding the registration with failed attempts it would in turn be pounding SFS with the same query over and over again. The local cache alleviates this problem since the Username/Email/IP should be the same through several attempts to get a successful registration. Aha! As a 40 year coder, this explains a lot! Very helpful. Thanks!

I think it would be okay to cache the definite hits for the long-term, but usually after failing in that one short time-span, you won't see the same user/email/ip combo again. (especially if you already banned the user, which would also prevent the same email address from being used). And if it's a dynamic IP, eventually a legitimate user *could* get blocked because you cached results for several weeks (or are not checking how recent the last bot was seen).

But anyhow, I think having a short local cache is more than sufficient. I've seen bots pound the registration with failed attempts, but still the local cache is not allways effective since they sometimes will try different usernames/emails/IPs when the previous attempt is not successful. It's interesting that you say this. Having carefully studied my log file, that's not what I see at all. I see the same bot coming back time and again using the same email, IP address and username but over gradually longer time periods (wait 1 second, wait 10 seconds, wait 30 seconds, wait 2 minutes wait 5 minutes wait 10 minutes, etc.) as though it's deliberately TRYING to figure out how long my cache lasts. Then after an hour or so of failed attempts it goes away for several hours and comes back to try again later with all the same info. That's why I figured the longer-term cache would help keep these a-holes from loading down the central server. Fortunately for me there's tell-tale signs of being a bot (i.e. 10 registration attempts in one second) which gets them submitted to SFS. Also I have other checking that I do before querying SFS to tell if they are a bot, that helps Pedigree out in reducing load on his server.

Thanks, eco_Jason. This explanation was very helpful even though it doesn't quite fit the bot behaviors I've observed. One thing I have realized over the past 3 years is that if one works out a strategy that is highly effective in defeating these borg-beasts they soon begin to deliberately study you to figure out how you're defeating them and try to devise a strategy to work around your protection technique. For example, the appeal of one of my sites is primarily U.S.-Regional So 2 years ago I decided I could block 99.999% of bots just by blocking and/or removing all registrations from anywhere in the world outside the 7 major U.S. and Canadian time zones. This was virtually 100% effective for months. In fact it was so effective I eventually set the underlying mysql query up as a cron-ed script and ran it every 15 minutes 24 hours a day 7 days a week. Presto. NO more bots! It worked perfectly for months.

Then one day I noticed I had a new registered user whose name was "FigureOutTimeMachine" (I'm not kidding you. So help me God, that WAS it's name!). Then within a few days my "time zone defense shield" suddenly didn't work anymore because the bot authors had rewritten their code and were now deliberately lying to my server about what time zone they came from.

Frankly, I suspect we may be seeing different attack patterns and strategies because the bot-authors are using their tools to study how our defenses work in deliberate targeted efforts to figure out how to defeat them. If THAT doesn't increase your paranoia level, it sure should! It says our enemies are studying us and getting smarter about how to defeat our best defenses every day...

Thanks again for the explanation, Jason. I'm not afraid to say that even after 42 years in the IT field, I'm still learning. Anyone who doesn't believe we're fighting the skirmishes of the world's first cyber war should come spend a few months on the front lines with us. They'd learn they're wrong real fast.

[TMH63]

Just in the past few days I've had people contact me that are trying to register and they are not spammers.

I'm going to have to disable this and find something out it seems.