[GRASS-dev] Re: impending wiki spam bombing

[Markus Neteler]

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. :(

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