vb.org Archive

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   vBulletin 3.6 Add-ons (https://vborg.vbsupport.ru/forumdisplay.php?f=194)
-   -   Administrative and Maintenance Tools - vbStopForumSpam - known spammer lookup for new registrations (https://vborg.vbsupport.ru/showthread.php?t=176481)

pedigree 06-10-2008 09:21 AM

Quote:

Originally Posted by allenelson (Post 1545380)
installed / tested. awesome mod, exactly what i was looking for when searching for spam. kudos to you


Thanks :) Now click Installed :cool:

Thomas P 06-10-2008 10:29 AM

@pedigree: I just checked, the last NN spammers weren't clever enough to use a proxy. Mayber they are even in countries where they cannot/must not use proxies...

pedigree 06-10-2008 01:15 PM

Quote:

Originally Posted by Thomas P (Post 1545753)
@pedigree: I just checked, the last NN spammers weren't clever enough to use a proxy. Mayber they are even in countries where they cannot/must not use proxies...

Thank you Great Firewall of China.... Adding a check box to "Block anonymous proxies" isnt a huge code change with all of the code rewrites Im doing. Ill add it, you never know, it might get a spammer

skippybosco 06-10-2008 10:02 PM

My weekly praise to pedigree and the amazing work on this mod.

Just took a look at the last few days activity:

Out of 6740 attempted registrations:
  • 1850 of them were valid users
  • 100 were blocked due to email
  • 3200 were blocked due to IP
  • 1590 were blocked due to username

Quote:

Thank you Great Firewall of China.... Adding a check box to "Block anonymous proxies" isnt a huge code change with all of the code rewrites Im doing. Ill add it, you never know, it might get a spammer
For what it is worth, I use a real time analytic tool GetClicky. One thing that I do when determining if a user was improperly rejected is to check the IP address and see if there is activity on my site. 100% of the time so far they do not show up, most likely indicating that they are blocking javascript from executing. I'm not sure if this is helpful information as a secondary check or not as it seems that it may catch users with outdated browsers as well, but so far is a good canary for me.

Twin_Turbo 06-10-2008 11:10 PM

PHP Code:

$bbuserinfo[ipaddress

That gives me my own IP address instead of the users (in userinfo template), what's the correct var for the members ip addy?

Wired1 06-11-2008 05:11 AM

I realize a lot of these suggestions are dependent on a better API / submission system from StopForumSpam.com :)

Suggestion: Once a submission function is built in, perhaps add an additional layer of analyzing to it? Example:

User1 / Email1 / IP1 was found to be a spammer via IP today. 3 hours later, they attempted to register again. User1 / Email1 / IP2.

So, if someone that's attempting to join passes, a last check would compare their user name and/or email and/or IP to previously blocked registrations. This way, they could be shut down from registering under slightly different credentials. An option in the adminCP could be added so the Admin can say how many days back in the log file to check (if not the whole thing).

Suggestion: If a submission is blocked, grab the rest of the offending info from the StopForumSpam site, and compare against the suggestion. If it doesn't all match, submit the submission's info so the StopForumSpam site is more complete.

Suggestion: Also, perhaps a function that would compare only allowed registrations to the StopForumSpam site. After all, some spammers make a login, and then don't spam for days. If another forum has caught them and flagged them, now you can be aware of this "sleeper" member and ban them. Notice could come via PM or New Thread post (akin to the Multiple Login AE mod here).

Not sure what would be best: checking on a CRON (or something similar), or only checking via a manual button. Perhaps an additional table column, so that if an allowed registration was checked 3 times after the account was created, it won't be checked again (so as to limit bandwidth and resources, both on the forum and StopForumSpam's site). Also, an option for the admin to manually OK an account, so it's bypassed in this check (or automatic, e.g. 20 posts in the forum, or in a certain group, or whatever).

Suggestion: A search for the log would be nice as well :)

Suggestion: Once the manual / auto submission tool (and possibly some of the others I've suggested) are in place, color code (or whatever) the log? Example: Spammers I've submitted in red, (easily customizable by admin via FFFFFF), or mark by symbols (searchable of course), ones thoroughly checked in green, etc.

skippybosco 06-11-2008 05:31 AM

The obvious risk is that users that were originally flagged incorrectly that you manually approved would get caught. If this kind of checking happened it would need to only affect users of a certain user group(s).

My vote would be to tie the "re-check" to an activity that would warrant concern (posting, PMing, etc)..

Scenario being a "Registered" group and a "Promoted Registered" group. Users in registered group are checked against StopForum before being allowed to post. Failures can either be quarantined or prevented.

Set up a promotion schedule (time, # posts, whatever) to move users to Registered so your trusted users don't pay performance penalties.

Wired1 06-11-2008 05:50 AM

You're talking about the comparison down the road? It doesn't have to auto-ban them or anything, just notify the admin of this new information. They can decide depending on the user's posting habits, the frequency that they showed up on the list (that's already part of the API), a simple google check, etc.

pedigree 06-11-2008 09:16 AM

Quote:

Originally Posted by Wired1 (Post 1546399)
I realize a lot of these suggestions are dependent on a better API / submission system from StopForumSpam.com :)

Suggestion: Once a submission function is built in, perhaps add an additional layer of analyzing to it? Example:

User1 / Email1 / IP1 was found to be a spammer via IP today. 3 hours later, they attempted to register again. User1 / Email1 / IP2.

So, if someone that's attempting to join passes, a last check would compare their user name and/or email and/or IP to previously blocked registrations. This way, they could be shut down from registering under slightly different credentials. An option in the adminCP could be added so the Admin can say how many days back in the log file to check (if not the whole thing).

Suggestion: If a submission is blocked, grab the rest of the offending info from the StopForumSpam site, and compare against the suggestion. If it doesn't all match, submit the submission's info so the StopForumSpam site is more complete.

StopforumSpam.com doesnt have the functionality to pull all the other details for spammers based on just one field. We cant get a list of IPs that SpammerX has logged in from. I can however, put all the details for a failed registration into the database. To be useful over a 24 hour period, I might think about changing the local cache from 90 minutes to 24 hours.


Quote:

Suggestion: Also, perhaps a function that would compare only allowed registrations to the StopForumSpam site. After all, some spammers make a login, and then don't spam for days. If another forum has caught them and flagged them, now you can be aware of this "sleeper" member and ban them. Notice could come via PM or New Thread post (akin to the Multiple Login AE mod here).
When I get all the template code working, there will be options for mods to examine users, refresh SFS.com data and act on that. In order to run proactive scanning against all the users against all SFS.com data, would require more work both on my time (I have a baby due in 6 weeks) and in cron execution time. Unless you have the Ajax cron mod installed, running a job like that would kill so poor users session. Maybe in v1+ Ill be able to add an automated pull from SFS.com of their IP lists. Anything more would be a lot more code. I want to get the next version out, working before baby is born because after that, well, I wont have much more time until I go back to work.

Quote:

Not sure what would be best: checking on a CRON (or something similar), or only checking via a manual button. Perhaps an additional table column, so that if an allowed registration was checked 3 times after the account was created, it won't be checked again (so as to limit bandwidth and resources, both on the forum and StopForumSpam's site). Also, an option for the admin to manually OK an account, so it's bypassed in this check (or automatic, e.g. 20 posts in the forum, or in a certain group, or whatever).

Suggestion: A search for the log would be nice as well :)
Ill add a search to the logs after I get all the new code working

Quote:

Suggestion: Once the manual / auto submission tool (and possibly some of the others I've suggested) are in place, color code (or whatever) the log? Example: Spammers I've submitted in red, (easily customizable by admin via FFFFFF), or mark by symbols (searchable of course), ones thoroughly checked in green, etc.
Auto submit can be sorted and logs updated to reflect that, its not a big, as long as you have cURL installed. Without cURL, automated submission will be extremely difficult, something that can be done but something that Im not really wanting to code for.

main goals for the next couple of weeks, is to get the core rewrite sorted, the 2.6 and 3.7 template changes sorted so that they rewrite templates on the fly, allowing mods to view all the data about the user, do whois/google searches, updating SFS.com data and submitting them manually, better loggind support and statistics reporting. Auto submitting user data to SFS.com might sneak in there but any companion, posting, PM etc will have to wait until all that is stable.

I spend 4-5 hours a day on a train to/from work so my time is a bit limited but Im trying to get it all sorted and out asap.

pedigree 06-11-2008 09:25 AM

Quote:

Originally Posted by Twin_Turbo (Post 1546223)
PHP Code:

$bbuserinfo[ipaddress

That gives me my own IP address instead of the users (in userinfo template), what's the correct var for the members ip addy?

Yeah, thats why I posted an update to v0.61 saying that you should remove the template changes. In the next version, all the templates changes will be automatically made. Ill have a couple of people who said they will help me in the testing, which will ensure I dont make some an awful screwup again :)

I think it might be $userinfo[host] but Im not on my machine, that could be wrong.


All times are GMT. The time now is 10:14 PM.

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01942 seconds
  • Memory Usage 1,789KB
  • Queries Executed 10 (?)
More Information
Template Usage:
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (2)bbcode_php_printable
  • (8)bbcode_quote_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)pagenav
  • (1)pagenav_curpage
  • (4)pagenav_pagelink
  • (3)pagenav_pagelinkrel
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (10)printthreadbit
  • (1)spacer_close
  • (1)spacer_open 

Phrase Groups Available:
  • global
  • postbit
  • showthread
Included Files:
  • ./printthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/class_bbcode_alt.php
  • ./includes/class_bbcode.php
  • ./includes/functions_bigthree.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • printthread_start
  • pagenav_page
  • pagenav_complete
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete