[GRASS-dev] impending wiki spam bombing

GRASS GIS GRASS GIS developer
1

Hi,

I notice over the last day or two a high number of seemingly randomly
generated new user accounts on our wiki site. We can ban these fake
users as they come and hope we don't hit anyone real, but at 10/day
it becomes an ugly chore, time sink, and demotivator. Up til now we've
been getting a few suspect accounts at the rate of around 1/week but no
automated spam.

We are up to 908 users registered, most appear to be spambot accounts,
but only 41 have been manually blocked.

There are apparently plans afoot to upgrade the wiki software on the
server, hopefully the new version will contain stronger capcha mechanisms
to weed out the jerks and we can spend more time on useful work.
Hopefully it can easily rank and remove bogus accounts instead of just
blocking them.

to combat wiki spam we need to keep an eye on the recent changes page,
  http://grass.gdf-hannover.de/wiki/Special:Recentchanges

thanks,
Hamish

2

Hamish wrote:

I notice over the last day or two a high number of seemingly randomly
generated new user accounts on our wiki site. We can ban these fake
users as they come and hope we don't hit anyone real, but at 10/day
it becomes an ugly chore, time sink, and demotivator. Up til now we've
been getting a few suspect accounts at the rate of around 1/week but no
automated spam.

We are up to 908 users registered, most appear to be spambot accounts,
but only 41 have been manually blocked.

There are apparently plans afoot to upgrade the wiki software on the
server, hopefully the new version will contain stronger capcha
mechanisms to weed out the jerks and we can spend more time on useful
work. Hopefully it can easily rank and remove bogus accounts instead of
just blocking them.

to combat wiki spam we need to keep an eye on the recent changes page,
  http://grass.gdf-hannover.de/wiki/Special:Recentchanges

over the weekend there were 56 new spambot accounts opened in the wiki. I
am now working through the wiki's web interface to ban these one by one,
but it is a big drain of time which I would much prefer to spend on more
productive tasks. the sooner we get this situation fixed the better.

Hamish

3

Hamish wrote:

over the weekend there were 56 new spambot accounts opened in the wiki.
I am now working through the wiki's web interface to ban these one by
one, but it is a big drain of time which I would much prefer to spend
on more productive tasks. the sooner we get this situation fixed the
better.

oops I counted wrong, make that 68 new accounts to ban.

Hamish

4

Hamish,

2007/10/1, Hamish <hamish_nospam@yahoo.com>:

Hamish wrote:
> over the weekend there were 56 new spambot accounts opened in the wiki.
> I am now working through the wiki's web interface to ban these one by
> one, but it is a big drain of time which I would much prefer to spend
> on more productive tasks. the sooner we get this situation fixed the
> better.

oops I counted wrong, make that 68 new accounts to ban.

hm, too bad. Not sure how to avoid this situation. To allow creating
new accounts only for sysops is maybe too restrictive...

Martin

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

5

Martin Landa wrote on 10/01/2007 08:14 AM:

Hamish,

2007/10/1, Hamish <hamish_nospam@yahoo.com>:
  

Hamish wrote:
    

over the weekend there were 56 new spambot accounts opened in the wiki.
I am now working through the wiki's web interface to ban these one by
one, but it is a big drain of time which I would much prefer to spend
on more productive tasks. the sooner we get this situation fixed the
better.
      

oops I counted wrong, make that 68 new accounts to ban.
    
hm, too bad. Not sure how to avoid this situation. To allow creating
new accounts only for sysops is maybe too restrictive...
  

Once Martin arrives in the office, we'll schedule an update of\
MediaWiki (hopefully later today).

Would it help to enable a captcha?

Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

6

Hamish wrote on 10/01/2007 07:57 AM:

Hamish wrote:
  

over the weekend there were 56 new spambot accounts opened in the wiki.
I am now working through the wiki's web interface to ban these one by
one, but it is a big drain of time which I would much prefer to spend
on more productive tasks. the sooner we get this situation fixed the
better.
    
oops I counted wrong, make that 68 new accounts to ban.

Some news:
* Martin and me have updated Mediawiki to 1.6.10-SVN.
* I have removed all above mentioned bad users from the DB (they all
  subscribe from the *same* email address for verification - how to block
  that?).
* I have added that if "User-Agent" is empty, the user will be rejected
  (let me know if you have problems with that).
* Bonus: thumbnail creation now works :slight_smile: using something like
    [[Image:wxgrass-gis-manager-layer.png|350px]]

Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

7

Hamish wrote:

> > over the weekend there were 56 new spambot accounts opened in the
> > wiki

..

> oops I counted wrong, make that 68 new accounts to ban.

Martin Landa:

hm, too bad. Not sure how to avoid this situation. To allow creating
new accounts only for sysops is maybe too restrictive...

We tried this for the GpsDrive wiki. IMO (as a wiki admin there
validating accounts) it IS too restrictive and a big mistake. It means
that just the usual core contributors contribute, the casual contributors
(ie potential future core contributors) don't bother. We were forced to
do it to stop the spamming though. :-/ I will push for captcha +
reopening it there if we find a good solution here. (both use MediaWiki)

Markus:

Would it help to enable a captcha?

Yes. It would help solve our current problem of creation of fake accounts.

Markus:

What about http://www.mediawiki.org/wiki/Extension:ConfirmEdit ?

Looks good! For ConfirmEdit I wouldn't like to turn on the captcha for
"all edits" as that would be too much of a burden, but apparently you can
do it for all edits which include external URLs and for new accounts,
which is an ok compromise.

And it seems those are the ConfirmEdit defaults already:
  $wgCaptchaTriggers['edit'] = false;
  $wgCaptchaTriggers['create'] = false;
  $wgCaptchaTriggers['addurl'] = true;
  $wgCaptchaTriggers['createaccount'] = true;
  $wgCaptchaTriggers['badlogin'] = true;

Here is another MediaWiki captcha plugin to look at:
  http://recaptcha.net/plugins/mediawiki/

The official MediaWiki page uses a couple of plugins: ("Other" section)
  http://www.mediawiki.org/wiki/Special:Version
  (ConfirmEdit, Newuserlog, and SpamBlacklist)

as does Wikipedia:
  http://en.wikipedia.org/wiki/Special:Version

Here is the MediaWiki Combating_spam man page:
  http://www.mediawiki.org/wiki/Manual:Combating_spam

Google found this page which mentions a MediaWiki plugin called "Bad
Behavior":
  http://meredith.wolfwater.com/wordpress/index.php/2006/01/04/wiki-spam-begone/
  http://www.bad-behavior.ioerror.us/2007/01/27/bad-behavior-2010/
  http://www.homelandstupidity.us/software/bad-behavior/installing-and-using-bad-behavior/on-mediawiki/

(shrug)

Markus:

* Martin and me have updated Mediawiki to 1.6.10-SVN.

thanks guys.

* I have removed all above mentioned bad users from the DB (they all
  subscribe from the *same* email address for verification - how to
  block that?).

(still 21 new ones today.. grrr) tricks in the mailer or /etc/ are
probably too invasive, it really needs to be stopped by the wiki software
somehow. Maybe some PHP hack? Unless there is an easy to edit email domain
blacklist for that, by hardcoding a solution we just solve today's
problem, not tomorrow's.

* I have added that if "User-Agent" is empty, the user will be rejected
  (let me know if you have problems with that).

I guess someone will one day complain, or worse go away without
complaining. no idea what the spambot pretends to be. The spam accounts
keep coming in today, so I guess that didn't stop it. :frowning:

* Bonus: thumbnail creation now works :slight_smile: using something like
    [[Image:wxgrass-gis-manager-layer.png|350px]]

nice to gain something positive out of this.

So can we try installing ConfirmEdit on the currently installed MediaWiki?

thanks for spending the time on this,
Hamish

8

On Tue, Oct 02, 2007 at 09:18:35AM +0200, Hamish wrote:

Markus:
> Would it help to enable a captcha?

Yes. It would help solve our current problem of creation of fake accounts.

Markus:
> What about http://www.mediawiki.org/wiki/Extension:ConfirmEdit ?

Looks good! For ConfirmEdit I wouldn't like to turn on the captcha for
"all edits" as that would be too much of a burden, but apparently you can
do it for all edits which include external URLs and for new accounts,
which is an ok compromise.

And it seems those are the ConfirmEdit defaults already:
  $wgCaptchaTriggers['edit'] = false;
  $wgCaptchaTriggers['create'] = false;
  $wgCaptchaTriggers['addurl'] = true;
  $wgCaptchaTriggers['createaccount'] = true;
  $wgCaptchaTriggers['badlogin'] = true;

We tried it yesterday, but it enabled only the Chinese version.
We didn't manage to enforce English or even what the browser
says (mine definitely doesn't send "zh"). So we had to remove it.

Here is another MediaWiki captcha plugin to look at:
  http://recaptcha.net/plugins/mediawiki/

"(note that this plugin only works with MediaWiki 1.8 or newer)."
-> we have 1.6.x.

The official MediaWiki page uses a couple of plugins: ("Other" section)
  http://www.mediawiki.org/wiki/Special:Version
  (ConfirmEdit, Newuserlog, and SpamBlacklist)

SpamBlacklist we also use.
ConfirmEdit fails...

Not sure how much Newuserlog helps if it isn't automated.
but it would be easier to trac the subscriptions. OK, added:

http://grass.gdf-hannover.de/wiki/Special:Log/newusers
(maybe sysop only)

Additionally:
I have now added a test to enforce 5 chars minimum length passwords.
Before it was 0 length minimum :-((

> * I have removed all above mentioned bad users from the DB (they all
> subscribe from the *same* email address for verification - how to
> block that?).

(still 21 new ones today.. grrr) tricks in the mailer or /etc/ are
probably too invasive, it really needs to be stopped by the wiki software
somehow. Maybe some PHP hack? Unless there is an easy to edit email domain
blacklist for that, by hardcoding a solution we just solve today's
problem, not tomorrow's.

I am rather surprised not to be able to simply block certain email
addresses from ever subscribing. Mailman does have this feature ("ban").
Strange. Banning by IP isn't really helpful here.

Anyway, I can wipe out this subscribe bot easily now (and regularly do).

> * I have added that if "User-Agent" is empty, the user will be rejected
> (let me know if you have problems with that).

I guess someone will one day complain, or worse go away without
complaining. no idea what the spambot pretends to be. The spam accounts
keep coming in today, so I guess that didn't stop it. :frowning:

I have disabled the "User-Agent"-is-empty test.

Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

9

Markus:

> > Would it help to enable a captcha?

Hamish:

> Yes. It would help solve our current problem of creation of fake accounts.

M:

> > What about http://www.mediawiki.org/wiki/Extension:ConfirmEdit ?

H:

> Looks good!

M:

We tried it yesterday, but it enabled only the Chinese version.
We didn't manage to enforce English or even what the browser
says (mine definitely doesn't send "zh"). So we had to remove it.

?! hmph.
An idea- my Debian/sarge box once installed a bunch of Chinese versions
automatically. It turned out the problem was that the package relied on a
meta-package which could be fulfilled by a number of language specific
packages. So it installed the first language package on the list, which was
Chinese, and hilarity ensued.

IIRC we had a similar problem with the Debian GRASS package which depends on
"xterm | x-terminal-emulator". In the past we just depended on
"x-terminal-emulator" which could pull in something other than xterm that
provided x-terminal-emulator, and hilarity ensued. (?)

also for ConfirmEdit "The current version(s) require PHP5; for PHP4-compatible
versions, use an older version available in the SVN." ?

taken from SVN? I see that ConfirmEdit.i18n.php has had many edits in the last
3 weeks.

too late for me tonight, but they have an IRC channel for support-
http://www.mediawiki.org/wiki/Manual:FAQ#I_have_a_question_not_answered_here._Where_do_I_go_next.3F

I would like to keep working on this problem.

H:

> Here is another MediaWiki captcha plugin to look at:
> http://recaptcha.net/plugins/mediawiki/

M:

"(note that this plugin only works with MediaWiki 1.8 or newer)."
-> we have 1.6.x.

ah.

> The official MediaWiki page uses a couple of plugins: ("Other" section)

..

Not sure how much Newuserlog helps if it isn't automated.
but it would be easier to trac the subscriptions. OK, added:

nice.

I am rather surprised not to be able to simply block certain email
addresses from ever subscribing. Mailman does have this feature ("ban").
Strange. Banning by IP isn't really helpful here.

I guess a request upstream is in order. It must happen to others sites too.

Anyway, I can wipe out this subscribe bot easily now (and regularly do).

Yea, but it is still an unneeded waste of time & energy so finding an automated
solution would be better in the long run.

cheers,
Hamish

____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/

10

On Tue, Oct 02, 2007 at 11:01:43AM +0200, Hamish wrote:

M:
> > > What about http://www.mediawiki.org/wiki/Extension:ConfirmEdit ?
H:
> > Looks good!
M:
> We tried it yesterday, but it enabled only the Chinese version.
> We didn't manage to enforce English or even what the browser
> says (mine definitely doesn't send "zh"). So we had to remove it.

?! hmph.
An idea- my Debian/sarge box once installed a bunch of Chinese versions
automatically. It turned out the problem was that the package relied on a
meta-package which could be fulfilled by a number of language specific
packages. So it installed the first language package on the list, which was
Chinese, and hilarity ensued.

Maybe you could guide me offlist how to verify that? I think that
the machine is a rather minimalistic (sarge) installation.

also for ConfirmEdit "The current version(s) require PHP5; for PHP4-compatible
versions, use an older version available in the SVN." ?

taken from SVN? I see that ConfirmEdit.i18n.php has had many edits in the last
3 weeks.

Of course we took an older release from SVN :slight_smile:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ConfirmEdit/ConfirmEdit.php?view=log#rev19995
Revision 19995
PHP 4 / MW 1.6 compat

too late for me tonight, but they have an IRC channel for support-
http://www.mediawiki.org/wiki/Manual:FAQ#I_have_a_question_not_answered_here._Where_do_I_go_next.3F

I would like to keep working on this problem.

Me, too, but I also need to do my regular work.
Will try again later...

cheers,
Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

11

HamishB wrote:

Hi,

I notice over the last day or two a high number of seemingly randomly
generated new user accounts on our wiki site. We can ban these fake
users as they come and hope we don't hit anyone real, but at 10/day
it becomes an ugly chore, time sink, and demotivator. Up til now we've
been getting a few suspect accounts at the rate of around 1/week but no
automated spam.

We are up to 908 users registered, most appear to be spambot accounts,
but only 41 have been manually blocked.

I have now deleted around 400 suspicious users (like "WkkYbe", "FwfNv7" etc)
which were registered without email address. :slight_smile:

Thanks to SQL no big deal once you know what you are looking for.

Markus
--
View this message in context: http://www.nabble.com/impending-wiki-spam-bombing-tf4527023.html#a13001944
Sent from the Grass - Dev mailing list archive at Nabble.com.

12

The GRASS Wiki is now protected by a captcha. I have deleted all translations
of the help text to avoid below mentioned problem.

Please try and report...

Markus

Markus Neteler wrote:

On Tue, Oct 02, 2007 at 11:01:43AM +0200, Hamish wrote:

M:
> > > What about http://www.mediawiki.org/wiki/Extension:ConfirmEdit ?
H:
> > Looks good!
M:
> We tried it yesterday, but it enabled only the Chinese version.
> We didn't manage to enforce English or even what the browser
> says (mine definitely doesn't send "zh"). So we had to remove it.

?! hmph.
An idea- my Debian/sarge box once installed a bunch of Chinese versions
automatically. It turned out the problem was that the package relied on a
meta-package which could be fulfilled by a number of language specific
packages. So it installed the first language package on the list, which
was
Chinese, and hilarity ensued.

Maybe you could guide me offlist how to verify that? I think that
the machine is a rather minimalistic (sarge) installation.

also for ConfirmEdit "The current version(s) require PHP5; for
PHP4-compatible
versions, use an older version available in the SVN." ?

taken from SVN? I see that ConfirmEdit.i18n.php has had many edits in the
last
3 weeks.

Of course we took an older release from SVN :slight_smile:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ConfirmEdit/ConfirmEdit.php?view=log#rev19995
Revision 19995
PHP 4 / MW 1.6 compat

too late for me tonight, but they have an IRC channel for support-
http://www.mediawiki.org/wiki/Manual:FAQ#I_have_a_question_not_answered_here._Where_do_I_go_next.3F

I would like to keep working on this problem.

Me, too, but I also need to do my regular work.
Will try again later...

cheers,
Markus

--
View this message in context: http://www.nabble.com/impending-wiki-spam-bombing-tf4527023.html#a13071467
Sent from the Grass - Dev mailing list archive at Nabble.com.