UESPWiki:Administrator Noticeboard/Archives/Registered Spammers

This is an archive of past UESPWiki:Administrator Noticeboard/Archives discussions. Do not edit the contents of this page, except for maintenance such as updating links.

Registered Spammers

We've had two "users" in the last several days that have been blocked for spam: "795 buy celebrex" on the 26th and "385 buy propecia" just today. Our blocking policy doesn't really say what to do with registered spammers, but it seemed pretty clear to me that these accounts were created for no other purpose, which is why I've gone ahead with an immediate block in both cases.

I don't know if there's some kind of automated something-or-other making these accounts (it seems unlikely), but if someone more knowledgeable could look into it that would be great. If you look at their deleted page histories, you'll see they've been pretty much identical. I would also appreciate it if others could please be on the lookout for this kind of thing and at least replace the spam page with a speedy delete notice until I come along. Thanks! –Eshe^talk 15:56, 28 June 2009 (UTC)

I think it probably is an automated task: The Oblivion Mods Wiki has had "988 buy trileptal", "364 buy cardura‎" and "88 buy capoten‎" and both ours have come from the same ISP in Russia. We could slap a range block on the necessary IPs but that may be a bit extreme just yet. –Rpeh^{•T•C•E•} 16:12, 28 June 2009 (UTC)

To be fair, registered spammers are hardly new to the site, whilst they may not be as common as other types they normally seem to just get the same treatment as any other spammer. Looking over the section covering first offense blocks, i fell a little re-wording may be necessary where the first point states "Editors (or IP addresses)" whilst all other points simply state "An anonymous IP address" quite how having an account should affect a vandals block status i dont quite understand, any thoughts? --Volanaro ^Talk 16:40, 28 June 2009 (UTC)

The fact that these accounts are somehow being created automatically is a bit worrisome -- implying that a hacker has found a way to circumvent our Captcha system. It could mean that an algorithm has been found to crack the Captcha; or it could mean that a site has been set up where people are being asked to translate our Captchas (e.g., in exchange for a reward, or as part of a fake login process on another site).

Nevertheless, I'm thinking that we should be able to stop this, and simultaneously fix another issue, namely certain overly popular account names (e.g., Gray Fox variants): I could add a username blacklist to the site. A quick search shows at least one extension that provides such a feature. Entries on the blacklist would then be, for example, '^\d+ buy' and 'gr.y fox'; no accounts matching those patterns could be created any more. The list would be editable by admins, so if a new pattern for spambot account names emerges, any admin could add an appropriate new entry. I can't think of any reasons not to add the extension. --Nephele^Talk 17:08, 28 June 2009 (UTC)

Correction, admins who know regular expressions! That looks like a good idea. There have been a few other accounts (the M'aiq variants) that have several duplicates so it could be of use. Of course, we have to spot which ones are getting popular in time, but that should be easier now the User Creation log shows up too. –Rpeh^{•T•C•E•} 17:34, 28 June 2009 (UTC)

After a few botched attempts, the blacklist seems to be in place and working. The biggest problem appears to be getting any changes to MediaWiki:Titleblacklist to register on both content1 and content2. It seems that the page needs to actually be saved on each server in order for that server to load the new version. Long-term, I think we need to do some reconfiguration of our memcaches (IIRC, wikipedia only has a single memcache, used by all servers, not a separate memcache for each server), but I'll leave that issue for another day. In the meantime, we'll just need to remember to do a dummy edit or two. --Nephele^Talk 20:38, 28 June 2009 (UTC)