Closed Bug 832642 Opened 9 years ago Closed 9 years ago
.mozilla .org spam flood, 1000+ new accounts today
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20130119 Firefox/20.0 Build ID: 20130119042019 Steps to reproduce: https://wiki.mozilla.org/Special:Log/newusers https://wiki.mozilla.org/Special:RecentChanges https://wiki.mozilla.org/Education/index.php https://wiki.mozilla.org/index.php?title=Education/index.php&action=history https://wiki.mozilla.org/Special:Contributions/NellaHurtado1 Actual results: Spam Expected results: Delete, throttle, etc.
Coincidental? "Gavin Sharp (away Jan 16-23)"
Severity: normal → major
I see now 500+ new zombie accounts per day is a trend that has been increasing from about 500 per month a few years ago. Are there templates to request blocking on specific pages? *Some* of the newer accounts are creating spam on their Talk pages and other pages.
Assignee: nobody → server-ops-webops
Component: wiki.mozilla.org → Server Operations: Web Operations
Product: Websites → mozilla.org
QA Contact: nmaul
Version: Trunk → other
I do agree that this is an important issue, but it seems to be happening for a while now and I don't think I'd want to get webops to work on this over a long weekend. I'll hang on to the Bug until Tuesday and pass it off to someone from Webops to fix.
changed the status to new,
Status: UNCONFIRMED → NEW
Ever confirmed: true
See also Bug 780482, a proposal to use a Captcha.
i agree there are a lot of "bot" users being created, but i don't see evidence we're getting more than a usual number of accounts at the moment (or when this bug was reported) - see below. i would agree tho, we should add some sort of human challenge to the user account registration. this might fit nicely into the wiki upgrade word we're already in the middle of. *=> new user accounts on Jan 19, 2013: mysql> select count(user_id) from user where user_registration like '20130119%'; +----------------+ | count(user_id) | +----------------+ | 420 | +----------------+ 1 row in set (0.11 sec) *=> new user accounts on Dec 19, 2012: mysql> select count(user_id) from user where user_registration like '20121219%'; +----------------+ | count(user_id) | +----------------+ | 415 | +----------------+ 1 row in set (0.09 sec) *=> new user accounts on Nov 19, 2012: mysql> select count(user_id) from user where user_registration like '20121119%'; +----------------+ | count(user_id) | +----------------+ | 422 | +----------------+ 1 row in set (0.10 sec)
How does one request a lock on a page like https://wiki.mozilla.org/Education/index.php or will that just cause more probing? Seems bad to leave it up. I think the wiki situation is bad enough that editing on the wiki should be disabled except for users with more than 5 edits and 30 days age.
(In reply to kitchin from comment #7) > I think the wiki situation is bad enough that editing on the wiki should be > disabled except for users with more than 5 edits and 30 days age. I don't know how we can do this... for one thing, as stated, it effectively prevents new users from ever editing (if you can't edit, how can you get the 5 edits necessary to be allowed to edit?). I'm with Chris on this... a captcha (or similar bot-preventing system) seems like the most direct and obvious way. If there is something better, that might work too. http://www.mediawiki.org/wiki/Manual:Combating_spam seems like a great resource for precisely this problem.
Sorry for jumping in, but doesn't enabling BrowserID eliminates all the bot registrations, as it requires some custom coding on their side?
http://www.mediawiki.org/wiki/Extension:Persona is the most prominent attempt at this that I found with brief searching. It's an experimental plugin, not release-quality. This extension does not handle new user registration at all... it merely allows existing users to log in with Persona rather than the stock MW auth. It sounds to me like it still allows normal MW auth, and still requires normal MW account creation, so this wouldn't have any effect on spam accounts. That said, I'm not opposed to allowing Persona auth... I just don't think this implementation would fix this particular problem. :)
Add the conform edit plugin http://www.mediawiki.org/wiki/Extension:ConfirmEdit This article is good
I'm not a MW expert or on webops (obviously), but I do have a few suggestions for a temporary fix, at the least. I think one easy change would be installing AbuseFilter; You can write regex filters to block based on a user's age, number of links in an edit, etc.  A second extension that might be useful is SpamBlacklist. WMF has a huge list of sites globally blocked on their sites, and it tends to be pretty useful.  Nuke lets admins mass-delete pages, making cleanup a bit easier.  SimpleAntiSpam just adds a form in the signup page that users don't see, but blocks registration if a bot were to add text to it.  One change that doesn't require an extension is to add something like this bit of code in LocalSettings.php: [snip] $wgAutoConfirmAge = 86400*5; //Set autoconfirmed age to 5 days... $wgAutoConfirmCount = 5; //...and 5 edits $wgGroupPermissions['*']['createpage'] = false; //Don't allow new users to create pages $wgGroupPermissions['autoconfirmed']['createpage'] = true; //Allow autoconfirmed users create pages $wgGroupPermissions['*']['upload'] = false; //Don't allow new users to upload $wgGroupPermissions['autoconfirmed']['upload'] = true; //Allow autoconfirmed users upload files [/snip] Again, no expert but I think that these changes along with a few filters on AbuseFilter would block a lot of the spam. I'd be happy to help take care of what exists now if there's no better way to do it (via the database or something).  http://www.mediawiki.org/wiki/Extension:AbuseFilter  http://www.mediawiki.org/wiki/Extension:SpamBlacklist  http://www.mediawiki.org/wiki/Extension:Nuke  http://www.mediawiki.org/wiki/Extension:SimpleAntiSpam
The situation is pretty bad. The user accounts I care less about, but the amount of spam... The fact that I can search wikimo for "cialis" and get so many results is a serious problem. Any update from server ops here?
Viewing legitimate authentic recent changes from the past hour today is nearly impossible https://wiki.mozilla.org/index.php?title=Special:RecentChanges&limit=500
Does anyone process the List on https://wiki.mozilla.org/Report_Spam ?
Another spam account: https://wiki.mozilla.org/Special:Contributions/OliverBro I noticed because of a spam page that happened to be named: https://wiki.mozilla.org/Index.php
If you want a list of spam accounts, I am sure they won't be hard to find... Listing one or two in this bug likely isn't useful when there are literally hundreds of them and (probably) hundreds of pages of spam, some under user pages, some on the main site, like, I dunno: https://wiki.mozilla.org/Cialis
I installed the ConfirmEdit extension and set it up to use ReCaptcha for account creation (among other things). This should hopefully fix the issue of large numbers of spam accounts getting created.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
More info: We also updated the SpamBlacklist (:Callek did this a month ago, so it wasn't *too* out of date, at least compared to before). This denies edits that add a link to anything in the blacklist. We also set up the "Nuke" extension, which makes cleanup a bit easier. If you have the appropriate access permissions, you can use it here: https://wiki.mozilla.org/Special:Nuke. My experience has been that the best way to get a wide swath of spam deleted is to: 1) Search by page title, using terms that are likely to give you a lot of spam 2) For each page result, the user that created it is shown... search for each of those users 3) So far in my testing, when I identify a spam page, *all* the pages created by that user are spam... so I can nuke all of them. 4) Optionally block the user- be careful not to block by IP though, as this can sometimes block the load balancers by accident. :) Also, we confirmed that you do have to "confirm" your email address before you can create/edit pages. That was already in place, just fleshing out some details for those reading along. :) ConfirmEdit/ReCaptcha is set up to do captchas on: 1) new users account creation 2) new page creation 3) editing a page to add an external link We can tweak these, but this seemed like a reasonable starting point.
In the future, wiki.m.o might consider using Marketplace's PotatoCaptcha implementation, which does not require user interaction. It's effectively a reverse CAPTCHA, which means there's no user interaction. We haven't had a single spammy submission since we implemented it. https://github.com/mozilla/zamboni/blob/master/mkt/site/forms.py#L20
(In reply to Matt Basta [:basta] from comment #21) > In the future, wiki.m.o might consider using Marketplace's PotatoCaptcha > implementation, which does not require user interaction. It's effectively a > reverse CAPTCHA, which means there's no user interaction. We haven't had a > single spammy submission since we implemented it. > > https://github.com/mozilla/zamboni/blob/master/mkt/site/forms.py#L20 We could turn this into a MediaWiki plugin fairly easily if there is interest in doing so!
that might be a good idea laura with that plugin for wiki.mozilla.org
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.