wiki.mozilla.org spam flood, 1000+ new accounts today

RESOLVED FIXED

Status

--
major
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: bugz-moz, Assigned: jd)

Tracking

Details

(Reporter)

Description

6 years ago
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.
(Reporter)

Comment 1

6 years ago
Coincidental? "Gavin Sharp (away Jan 16-23)"
Severity: normal → major
(Reporter)

Comment 2

6 years ago
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
Assignee: server-ops-webops → shyam
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
(Reporter)

Comment 5

6 years ago
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)
Assignee: shyam → cturra
(Reporter)

Comment 7

6 years ago
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.
Depends on: 839743

Updated

6 years ago
Depends on: 780482

Updated

6 years ago
Duplicate of this bug: 780482

Updated

6 years ago
Blocks: 668704

Updated

6 years ago
No longer blocks: 668704
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. [1]

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.  [2]

Nuke lets admins mass-delete pages, making cleanup a bit easier. [3]

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. [4]

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).

[1] http://www.mediawiki.org/wiki/Extension:AbuseFilter
[2] http://www.mediawiki.org/wiki/Extension:SpamBlacklist
[3] http://www.mediawiki.org/wiki/Extension:Nuke
[4] 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 ?

Comment 17

6 years ago
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
Assignee: cturra → jcrowe
(Assignee)

Comment 19

6 years ago
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
Last Resolved: 6 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

Updated

6 years ago
Depends on: 860214
(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
You need to log in before you can comment on or make changes to this bug.