Forum spam - disabling profiles before approval?
Jubatian
New
Hi!
I just (about 2 weeks ago) opened up a Vanilla forum, no much stuff, and set Admin approval for registration. However nowadays spam is literally pouring in, I am battling with my web space provider's IP ban settings to gain some control over the situation. They don't get approved, but still leave a mess around until rejecting in their profile (also visible from the Activity tab), and put a considerable load on the web server.
Why I am slightly pissed about this is that I also run a Symphony based personal blog since years with open posting with hardly any spam problem. There no links are allowed, and this apparently does it quite well (it took some time to fine-tune this, nowadays I only get on average one senseless post per week causing no harm). I hope to get somewhere near this with Vanilla forum as well. Truly I would except that without my approval (that is the Admin Approval) users can not affect anything viewable to the public. But they can, and apparently for some reason this drives them to pour in in masses. While the site itself lacks any popularity.
What could be done about this if anything? I would like to leave the registration open to the public so if one is interested, he can enter without much hassle. OK, I know if one wants to DOS or DDOS me, he will do it, but if these are driven with the intention of populating the site with spam, it would give them considerably less motivation if their actions won't be visible to the public until I approve them (First my Symphony based blog also got some severe spam rushes as well, but after I tuned it so it is not possible to post links at all, they gone away).
Truly it's okay that I can simply reject them when I visit my admin panel, but it bothers me that they put a load on the server which may be avoidable (I am also worrying that where will this get if the site happens to get some popularity. I wouldn't want to pay more for my web space just to be able to service those masses of spambots).
Comments
That question has been discussed a lot and you can find good solutions in the plugin section. Here is a link to some discussions
http://vanillaforums.org/discussion/comment/199731/#Comment_199731
The answer did not quite help me as I never quite trust in any blacklist based solution which all of those answers are. I was looking for something inherent.
Finally and promptly I resorted to look around and settle with an another forum solution. Now after a month I can summarize the experience with what I got with Vanilla in about 3 weeks, and with the other forum starting out from the severe spambot-loaded site afterwards.
I set up the other forum for admin approval, and later I also changed from captcha to thematic questions. This forum with it's admin approval setting does not even allow logins until the admin approves (Vanilla allows, and also allows editing user profiles opening a severe possibility for profile spamming, see below!). Later with the thematic questions, with some very simple ones I entirely got rid even of those bots showing up in my approval list.
With Vanilla the spambot traffic was raising exponentially during the course of it's 3 weeks right until I erased the forum out of existence and installed the other on a different path. An important characteristic of this traffic was that apparently most bots [b]check for success[/b], and if they see so, they continue. So in turn I was getting thousands and thousands of requests to even those profile pages these bots created for the [b]unapproved[/b] users they registered.
When I changed of course on the main site I updated the links to the new forum. I found that most bots are capable to follow this transition. Their typical pattern was first requesting a page (they probably created) on the Vanilla forum, got a 404, then retried on the root domain, found the entry to the new forum, and attempted to register there (and succeed to register before the thematic questions, but of course were unable to affect the forum any way apart from generating an approval list entry for the admin).
During the course of the month these requests are slowly diminishing, but didn't go away entirely. I am still getting about 200 or so daily, about 80% of which starts with a request to a page on an old Vanilla forum path. Only the rest seem to target the new forum directly, so only a [b]very few[/b] (totally unsuccessful) requests daily even after a month.
The importance here is that there is no blacklist at all. It just works inherently. With Vanilla I believe the reason for the exponential growth was the fact the bots could alter the forum's contents successfully (despite the admin approval in place), which seems to be reinforced by the fact that a lot of spambots seem to attempt to revisit earlier created content (even after a month of it's deletion). If they couldn't create content the first place, I believe this situation wouldn't have risen. This again has some proof, by the access statistics of my blog. That blog supports anonymous posting, but with no links or link like content allowed, which I tuned according to spamming more than a year ago. I hardly ever get any bot generated content on that site, and it's traffic patterns neither indicate apparent high spambot loads, while legit comments seem to be able to pass. I don't say this is a way to follow by any means, just that it is probably not a coincidence that if the bots can't place content on the site, they won't swarm it (this even has some rationale as their goal is generating some revenue from clicks on the material they post - so they have to utilize their automation to maximize the output of this, not wasting resources on heavy loading a site which does not take content anyway).
Hope this post was not completely vain. I won't likely switch back from now, the other forum works fine for my purposes, but maybe you will see some reason behind this experience I shared here.
nice writeup @Jubatian
here are some counterpoints... (assuming you meant other fourm non-vanilla)
counterpoints using vanilla forum.
equivalent to approval process and using botstop approval plugin.
http://vanillaforums.org/addon/botstopapproval-plugin
unapproved applicants shouldn't show if you set permissions correctly.
there is no blacklist here.
a smarter blacklist...
http://vanillaforums.org/addon/registrationrestrictlogger-plugin
forum admins should promptly remove spam content.
this can be done with
http://vanillaforums.org/addon/preventweblinks-plugin
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Partly true. I mentioned the thematic questions for completeness since when I set it up (about a week after dropping the Vanilla installation) it popped in my mind that it might have helped there too to solve the problem for one part. Essentially with the new forum it only makes my life as admin easier (and to some extent, applicants since the captcha was both useless and completely inefficient).
I remember I tried juggling with the permissions, but I couldn't get what I wanted. The plain Vanilla installation didn't even have an easy access to user profiles which I wanted public, and planned to later theme the board so it works intuitively. I don't remember any permission combination which would have solved my problem with this requirement (that is disabling creating profile content without approval, so they may be made public, or at least disabling the public display of applicant profiles to limit the turd to the database only). With the other forum I can do this since applicants can not edit profiles "out of the box".
The registrationrestrictlogger plugin for me rather seems to be a customizable blacklist. It is true however that filtering the applicant's message may help a lot: the applicant message is a concept I liked in Vanilla which is not present in the other forum I changed to. With that I have no much information to decide on the applicant's intention (apart from checking the user name, email and probably searching around for the IP address).
The preventweblinks plugin might be a good suggestion to deal with the problem even if it is not technically possible to get rid of applicants creating profile content. It may depend on the plugin's flexibility though, combined with the ways Vanilla may let links "slip through" (whether tricky encoding may get past the filter and show up as a link). In my blog's case I went for a very simple and seemingly efficient solution by making the "http /whitespace/
/" and the "www" strings filtered out as a base (tricky bots even posted links as "http /newline/ 
/" - non-functional, but still garbage post), and maybe some other variations.
With Vanilla an other very annoying problem here is that if e-mail verification is combined with Admin approval, the system seems to have some kind of flaw. Until the e-mail verification is performed, the user is not an Applicant (I don't remember which role it had, but maybe the equivalent of a regular user!). Until I disabled the verification, it gave even more headache to delete those bot registrations one by one (like deleting ordinary users) with all the hassle since they didn't verify their e-mails. This (if I remember well) for me questions a little if any feasible solution is even possible which makes the profiles publicly viewable while getting rid of the spambots (If I wanted regular users be able to view profile contents, then this way I guess the bots would see them as well, so they get confirmed that their acts have results, and keep on flooding mess until I notice). Maybe with creating an additional regular user role and keeping the one offered by Vanilla having permissions matching a guest. (I might be incorrect here, after a month I can't remember exactly)
I think you have very valid points that should be taken to heart.
e.g.
not being able to share on activity wall controlled by profile.edit
Unconfirmed email role. - which is found in User Table Attributes. and roleid in UserRole Table.
permissions for Unconfirmed e-mail role and applicant can be limited in roles and permissions in dashboard.
the member's roles can be found out in dashboard, as well as by http://vanillaforums.org/addon/memberslistenh-plugin
you could also filter all unconfirmed email roles with several plugins (you could create role lists with
http://vanillaforums.org/addon/cleanser-plugin to find out who is unconfirmed.
A plugin could be made - but a few features and specificity would go along way being in the core with some of the following options:
you could also modify the edit profile to check for Applicant or Confirmed Role of the Sender (the user being viewed) and prevent the ability of these roles from editing profile. And it wouldn't be too hard to add an option to prevent these specific roles from being viewed in profile by anybody but admin and the particular user themselves.
essentially only showing profiles of valid actual members (as opposed to Applicant or Unconfirmed)
In that way Applicant or Unconfirmed don't have a public face on your forum.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Eh, wish you posted originally to my problem, maybe then I would still be using Vanilla.
A problem is that although I had deeper insight in web tech, I drifted away towards micro-controllers and neglected these. Now starting up a project I decided on setting up a site, which will eventually require these (at least they would be definitely beneficial), and Vanilla seemed to be something to work out well with these intentions (that is investing in deeper hacking around) later. But right now the project has far more importance than the look and usability of it's site, and I got the "Oh my God, just do something about it" state with the situation rising with my largely faded skills on this field.
Will see later. If I get to have more time to get involved in this before I get the project to a state which would bring some activity on the forum, I might switch back and solve these to fit my intentions, but otherwise I will stay with the other (it is not the best thing to discard people's post right away when a project would finally start to get momentum).
Thanks for help, after all I see my post was not without some result
The "unconfirmed email" is correct, now I remember, it is a pity that with admin approval it is a pain for the admin to discard those users who didn't even care to give a proper mail address, at least with the basic Vanilla installation.
The suggestion at the end of your post is almost what I was hoping to find. I wished to find a way to disable these roles editing profile content (or editing any content for that matter, maybe it is not specific to profile, plugins might supply additional possibilities, it depends on the underlying structure whether those may pose similar problems or not: is there any other area where there is no apparent way to alter write rights?). What you suggest, the ability to view these is also nice, after all the user name itself is also "created content without approval" (and may even contain spam, for that matter). It is a different matter to my expectations though since a registering user can not be restricted from creating an user name like he may be restricted from creating profile content (for example by permission).
regarding vanilla 2.1
yes via roles and permissions allowing only view and signin
would prevent editing any content but their own profile.
profile editing permission is a bit of a misnomer - because the applicant can still edit their own profile. But a mod could easily be made to prevent editing of profile as well.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
BTW. if you remove view permission from e-mail - they will still see the inbox messages they get but cannot pm other users.
BTW. if you remove view permission from activity - they will still see the activity.
of course you would want them to view discussions and comments in the same manner as guests.
you could also cut down permissions (as well as viewing certain areas) on guests (non-logged in users)
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.