Manual talk:Combating spam

Pages on meta.wikimedia.org
Were you not aware of these pages? :
 * Anti-spam Features
 * Wiki Spam

Seems like a lot of duplicated effort creating this explanation.

Could move those onto MediaWiki.org ?

-- Halz 10:11, 9 October 2007 (UTC)


 * By the way I am responsible for writing most of the text on those pages, and would be delighted if more people read them and linked to them (not because I wrote them, but because I want to increase awareness of the issues/remedies). So if they're more likely to be found on here, lets move them here.
 * I am also very happy for people to redistribute that content, so if we wanted move those pages into the Public Domain Help Pages that would be fine by me. I'm not the sole contributor. Others made various minor tweaks, so maybe there's legal problems with stripping the license.... but I did write the bulk of the text.
 * -- Halz 10:55, 26 March 2008 (UTC)


 * It's a nice thought, but anti-spam information is probably out of the public domain help pages' scope (considering their target audience). Would other wikis really benefit from duplicating that content (though they still can under the GFDL)? —Emufarmers(T 02:21, 27 March 2008 (UTC)

Anti-spam features is on this wiki now and yes, its content is highly duplicative of information which is also on this page. I'm also tempted to remove much of the commentary on "rel=nofollow" as (1) it is already 'on' in standard MediaWiki installations by default (and there's no useful purpose served by instructing on how to turn it off here) and (2) it doesn't stop spam. --Carlb 05:31, 8 September 2009 (UTC)

Edit Filtering
With refference to the section on edit blocking, is there a way to block a specific string inside new page titles? For instance, I'm getting a lot of spam that has "jobs" or "job" in the title. Can I block new pages with this specific text in the title? FrankCarroll 05:57, 6 February 2011 (UTC)

Importing the spam list
There's a little hitch with the described process. I followed the process to the letter and uploaded it to my wiki, though there still seemed to be bots registering from ip's banned with that extension. After some searching, the only thing i can find is that php.net mentions that require and include need a 'proper' php file to work, and the described process doesn't mention the trailing ?> that i would assume should be added.

Does the wiki just skip incomplete extensions in such cases and is that why bots can still register, or is there something else going on? Reiisha 05:07, 15 March 2011 (UTC)


 * No, ?> is not required; only  is. What makes you think bots are registering with IPs you've blocked?  Have you used CheckUser to check? —Emufarmers(T 06:29, 15 March 2011 (UTC)


 * I did use CheckUser and looked up the IP's in the php. They're still registering with them. Reiisha 13:25, 15 March 2011 (UTC)
 * Since i added in the closing ?>, the extension started working correctly... Reiisha 23:07, 18 March 2011 (UTC)


 * I'm using MW 1.18, and tested things by blocking my own IP address. It turns out that I could still register, but that I only had read access.  Once I took my IP address out of $wgProxyList and refreshed the page, I could edit again.  Mr3641 19:32, 13 September 2011 (UTC)


 * There's a known bug where $wgProxyList has not been working since MW 1.18. What I've noticed on my own site is that blocked IPs can create accounts, but these accounts don't have permissions to edit and they pile up on your Recent Changes.  If you look at the bug report, you can see an initial patch that I submitted.  There may be a better way to fix this, but this has at least got things working for me again.  --Mr3641 (talk) 09:04, 12 September 2012 (UTC)

combating human spammers who create accounts
I run a mediawiki site and require users to create an account, and used a basic captcha and did the various blacklist techniques listed on this website. I still get some new users that take the effort to create an account and then make spam pages, so perhaps these are people who manually operate and not just automated spambots. If these indeed are live people, then other than IP blacklists, which are not perfect, it is hard to catch them. But I've noticed that their account names are always ending in a number, like Mira2025 or Alina1917 or Vikulay2039 or Maryinkina1996. Therefore, one idea is to create an extension that doesn't allow users to create usernames that have numbers. Of course, you need to explain this clearly on the new account creation page, and it is a slight inconvenience to legitimate users (on my wiki, this is no problem, since the number of legitimate users is right now about 10, and will never grow beyond 100 or 1000 at most, so there is no shortage of usernames; obviously, for wikipedia, allowing numbers in the username is essential). This might make it more difficult for spammers. It would also be possible to collect a list of blacklisted usernames.

Clearly, not a perfect solution, but just an idea to toss around.


 * There are already extensions to do so, and they're mentioned in the page. You can blacklist such usernames with Titleblacklist; you can do all sorts of checks over them with the abusefilter. Before doing so, try simpler solutions explained on this page and which you didn't mention. Nemo 20:02, 25 January 2012 (UTC)

I had this issue. AkismetKlik resolved it. I use 1.18, so as long as your install is current, you should be good to go for it. 68.191.162.116 18:16, 19 September 2012 (UTC)

Spam in wiki
Our wiki citywiki is being thoroughly spammed, despite using RECAPTCHA and other extensions. Could anyone please give some advice? Thanks!
 * There's some more advice on Manual:Combating vandalism. You could try and add Extension:SimpleAntiSpam to see if it has any effect on bots, as it's completely harmless for humans. Nemo 11:19, 16 February 2012 (UTC)
 * I've had the same experience with spammers getting through RECAPTCHA. What has surprisingly worked (so far) is that I use the QuestyCaptcha feature of Extension:ConfirmEdit.  To make things unambiguous for my users, I show them a word in all caps and tell them to type in the box.  Compared to RECAPTCHA, this seems like something that spammers could easily figure out, but this has cut off the torrent of spam I was getting.  I'm also able to leave my wiki open to anonymous edits since the spammers seem to all want to create accounts.  I'm not sure how long this situation will last, but this strategy has worked quite well. --Mr3641 (talk) 12:09, 16 February 2012 (UTC)
 * I'm also using the same catchpa plus most of the anti-spam extensions we could get to work on my wiki. The thing is these guys are just walking on past all that. We're getting between 8-15 spammers signing up and posting their spam to their user pages, they make an article with the same title of their username and post the same message, and sometimes they post to their talk pages.  I've noticed they all seem to use long usernames which usually have two names and a bunch of numbers.  Something too long or complicated for a regular user to create.  What I think is causing the rapid increase is that I've heard that someone created a wiki spamming program that goes by the name of Extreme Wiki Poster which seems to have become rather popular within the spammer community.  Popular enough that there are others who are selling wiki website links to be uploaded to the program for spamming purposes.  Is anyone coming up with something to defeat this?  Is there something that can be coded or could we hack the program and find something we can use to block it?  (Please note: like I said, my wiki is running the majority of anti-spam extensions, blacklists, and also regenex anti-spam word blocker from the localsettings.php file.)  Brothejr (talk) 22:11, 22 February 2012 (UTC)
 * Wow, Extreme Wiki Poster is indeed pure evil. We really need to do something about this. --Mr3641 (talk) 06:42, 23 February 2012 (UTC)
 * One way to deal with these guys is to read their FAQ's. From http://www.deathbycaptcha.com/user/faq:

Q: Can I upload CAPTCHAs in Russian, or not in English in general? A: Better not to, we don't have solvers able to read non-English CAPTCHAs yet.
 * That sounds nice. However, one main problem with that: the vast majority of my editors don't read or type in Russian or other non-Latin letters.  So switching to Russian catchpas would keep regular people from logging in.  Maybe if someone created an anti-spam feature simular to Stopforumspam's addon for the SMF forum.  When a user creates an account, their username, email, and IP address are compared to stopforumspam's database.  If there is any match to their database or the user is doing something questionable when creating their accounts, the user is flagged and unable to do anything until the admin approves their account.  Plus the addon make it easy for the admin to spot the spammer and delete the account before it even has a chance to spam.  Plus, it has a reporting feature to help the database grow and makes the spammer's life all that much more painful.  Very rarely a regular user is flagged by this feature, but even that it's easy to rectify.  About the only way I've seen spammers get past the addon is if they are using brand new usernames, emails, and IP.  But even then it isn't long before those things are flagged.  Maybe we should create an extension that does something simular for wikis.  (The one stopforumspam is not that heavy on on server processing and runs quite smoothly.)  This would be very helpful for a lot of wikis and would improve their battle against spammers.  Brothejr (talk) 11:29, 23 February 2012 (UTC)
 * Just as an update, a month ago I mentioned above how I was using the QuestyCaptcha feature of Extension:ConfirmEdit to prevent spam bots. It's still working incredibly well, and I get maybe one spam edit per week, and still allow people to edit without creating a user account.  This is a significant improvement from the 10+ spam edits per day I was getting.  If you look on youtube, you can find some videos of Extreme Wiki Poster in action.  It seems that the key is to adjust your wiki slightly so that their automated scripts fail to create an account.  These guys seem to be interested in spamming the most amount of wikis with the least amount of effort, and it doesn't seem to be worth their time to check why they weren't able to write to a particular wiki when they've already spammed hundreds of others.  --Mr3641 (talk) 08:21, 15 March 2012 (UTC)
 * Yea, just added the Extension:ConfirmEdit and set up QuestyCaptcha. I took some fooling around to get the settings right to achieve what I was looking for.  Works quite well at slowing these guys down.  Another thing I added as an extra layer that also seems to block some of them is this: Extension:RudeProxyBlock.  I installed it and then once a week I download the latest spammer proxy IP list from StopForumSpam along with a couple other anti-spam sites and update RudeProxiBlock with those proxy IP's.  I can see that a bunch of spammers have been blocked by that extension.  Worth a try too as an extra layer of protection.  Brothejr (talk) 13:59, 17 March 2012 (UTC)
 * The problem with QuestyCaptcha is that the number of questions it offers is so small it's easy for spammers to construct a complete database. Extension:Asirra's database is much larger and more dynamic which makes it better. My wiki was getting human-assisted spam (farming CAPTCHAs out to humans), so none of these solutions were sufficient, but Extension:AbuseFilter was highly effective because the automated part of the spam consistently used usernames or article titles fitting a unique pattern. Dcoetzee (talk) 01:45, 12 April 2012 (UTC)
 * You can add or change the questions all you want. I generally shift them every so often to keep the spammers guessing.  Plus, while they may be able to use humans to get around the catchpa during user creation, they are too lazy to create/edit the pages themselves and resort to using their spam programs.  So if you also attach the catchpa to every edit, you'll stop them dead in their tracks as all the spamming programs they use are not able to handle catchpas during the edit process, only during the user creation process.  Since I started using questycatchpa not only for user creation but also for all edits too, I saw a dramatic decrease in spammer activity.  Heck, because of attaching catchpa's to edits, I can still allow anon editing.  About the only spammer activity I still see now are the ones using humans to get past the user creation catchpa, but they are still stopped by the edit catchpa. It's to the point that I don't even need to use Extension:AbuseFilter.  Brothejr (talk) 12:04, 28 May 2012 (UTC)

I've been flooded with Chinese spam that evades CAPTCHA by including no links, which is bizarre as I can't see any reason for the spam without them, and text is random phrases. It also somehow evades SpamRegex: "gucci", "bottega" and "jimmy choo" (amongst others) are banned but somehow still get through. Hogweard (talk) 13:08, 20 July 2012 (UTC)

massively blocking or removing user accounts
Hello,

I used several solutions proposed here, with IP blacklisting and regular expression filtering. Nevertheless, spammers created a lot of user accounts and continue to use them. What I would like is a way to block edition for this accounts (there are several thousands of them, so manual blocking isn't usable). Do you know some scripts or extensions to do that ? --Psychoslave (talk) 12:03, 10 April 2012 (UTC)
 * Use Extension:CheckUser to hard-block the underlying IP addresses. CheckUser can also accomplish mass-blocking.--Jasper Deng (talk) 17:40, 10 April 2012 (UTC)

Merge with Anti-spam features?
This page has quite a lot of overlap with Anti-spam features, and probably even more now that I expanded that page (not sure why I didn't expand this one instead). Could we consider replacing this page with that page, based on the current version, or merging them in some fashion? Dcoetzee (talk) 19:21, 10 April 2012 (UTC)


 * Yes, they should be merged. I think the resulting page should probably be in the "Manual" namespace, regardless of which title you choose. —Emufarmers(T 05:52, 18 April 2012 (UTC)

Tornevall
Is tornevall even being updated anymore? I have checked their forums and it's filled with spam, latest IP removal request being responded to months ago. --Sovereign92 (talk) 19:43, 2 July 2012 (UTC)

',\n'
The separation of the IP's with  doesen't work. You must replace  with , so the IP-Banlist works. Best Regards 217.5.205.2 10:08, 21 October 2012 (UTC)

CPU usage; IP blacklists
Spambots can sometimes affect performance a lot, if countermeasures are too weak or too expensive. Should be considered somehow in the page. --Nemo 16:44, 19 May 2013 (UTC)
 * An answer I got: «It seems that the DNS blacklists are probably fine. They will introduce some delay but largely your name resolver will cache that information so performance really shouldn't be that problematic. I was using the method of downloading the Stop Forum Spam database and then turning that into a call in LocalSettings.php and after looking into it I really wouldn't recommend that approach.» --Nemo 08:16, 24 May 2013 (UTC)