Last modified: 2006-12-13 15:57:08 UTC
The english wikipedia has, for the last 4 weeks, been experiencing a severe rash of vandalism from people who have determined how to do a maximum amount of vandalism possible while staying unblocked (At least some of it is attributable to the GNAA) A vandal will register the maximum number of usernames registerable from an IP address (currently set at 10 usernames per IP per day). He will then use each username to vandalize exactly once, log out, log back in with a new fresh username, and vandalize again. Because he never attempts to edit from a blocked account, he never trips the autoblocker. The targetted articles tend to be linked prominently - featured articles and 'in the news' items. Admins can only block the throw-away accounts after each vandalism, but are powerless to prevent new vandalisms. Semi-protecting all the targetted articles is an option, but not a particularly good one - there's nothing to stop them from moving from one target to the next. Here is one recent example from [[Triumph of Will]]: # (cur) (last) 03:05, March 3, 2006 Shanel m (Reverted edits by SUckit@excite.com (talk) to last version by Titoxd) # (cur) (last) 03:05, March 3, 2006 SUckit@excite.com # (cur) (last) 03:04, March 3, 2006 Titoxd m (Reverted edits by Jayjose (JJ) (talk) to last version by Shanel) # (cur) (last) 03:04, March 3, 2006 Jayjose (JJ) # (cur) (last) 03:04, March 3, 2006 Shanel m (Reverted edits by Bereavedheroz (talk) to last version by Shanel) # (cur) (last) 03:04, March 3, 2006 Bereavedheroz # (cur) (last) 03:01, March 3, 2006 Shanel m (Reverted edits by MShariat (talk) to last version by Titoxd) # (cur) (last) 03:01, March 3, 2006 MShariat # (cur) (last) 03:01, March 3, 2006 Titoxd m (Reverted edits by Xiao Mai Chung (talk) to last version by Shanel) # (cur) (last) 03:00, March 3, 2006 Xiao Mai Chung # (cur) (last) 03:00, March 3, 2006 Shanel m (Reverted edits by AckJohn (talk) to last version by Titoxd) # (cur) (last) 03:00, March 3, 2006 AckJohn # (cur) (last) 02:59, March 3, 2006 Titoxd m (Reverted edits by Ninjachu (talk) to last version by Shanel) # (cur) (last) 02:59, March 3, 2006 Ninjachu # (cur) (last) 02:59, March 3, 2006 Shanel m (Reverted edits by Argentinian jackalope (talk) to last version by Titoxd) # (cur) (last) 02:59, March 3, 2006 Argentinian jackalope # (cur) (last) 02:58, March 3, 2006 Titoxd m (Reverted edits by Sheeyeung (talk) to last version by Titoxd) # (cur) (last) 02:58, March 3, 2006 Sheeyeung # (cur) (last) 02:57, March 3, 2006 Titoxd m (Reverted edits by Fastnaturedood (talk) to last version by Titoxd) # (cur) (last) 02:57, March 3, 2006 Fastnaturedood # (cur) (last) 02:57, March 3, 2006 Titoxd m (Reverted edits by Freedigger1 (talk) to last version by Titoxd) Here's the user creation log for one of the above users (IP 67.180.114.100) +- 02:16 (User creation log) [Smoovejohnson; Noname 88; LAndrew; TwoRaider; Wolfnissy; Dancing babies; XxX MKD XxX; Oh yeah thats it] All of those were registered the same minute, and all of them used to vandalize within another two or three minutes. The autoblocker needs to be modified so that it retroactively blocks recently used IP addresses (where recent can be as short as 10 minutes). Reducing the number of IP addresses that can be registered per IP per day would also help. As it now stands, only users with checkuser can combat this type of vandalism, and there simply aren't enough to do the job.
This would effectively turn AOL into a 100% of the time autoblock. Since some vandals know that by using AOL if they vandalize they can intentionally deny service to other AOL users. - Alkivar
But reducing the amount of user names per IP per day is a good idea, I think. Who needs more than one (maybe two, if something went wrong) user accounts per day? Or does AOL sometimes assign the same IP address to two different people within one day? Isn't there an exposure time?
(In reply to comment #2) > But reducing the amount of user names per IP per day is a good idea, I think. > Who needs more than one (maybe two, if something went wrong) user accounts per > day? Or does AOL sometimes assign the same IP address to two different people > within one day? Isn't there an exposure time? biggest part of AOL is basically using a giant proxy. It assigns the same IP adress to two different people not only on the same day, but as close to simultaniously that it doesn't make a difference.
Numerous high profile articles, including virtually every featured article, have been hit by this kind of attack in the last couple weeks, and it's getting worse. People are getting frustrated at their inability, and it's clear there are not nearly enough people with checkuser to combat this (nor are there every likely to be). [Also note - getting a user's IP addresses based on username is a *slow*. I've often noticed that by the time I'm done getting them, he's already used all 10 accounts to vandalize and has moved onto a different IP] A technical solution is needed (soon). As such, I'm increasing the priority.
I doubt there would be significant benefit to this; surely it's trivial to switch open proxies if you're already going to this kind of trouble?
Most of the regular, high profile vandals go through open proxies. The vandal has no intention of using the same IP more than once; instead, he moves on to another open proxy, with an all new IP. This would do nothing to stop the high profile vandals, such as the one who regularly attacked [[George W. Bush]], or the one who went after [[Triumph of the Will]] when it was on the main page (probably the same person).
(In reply to comment #2) > But reducing the amount of user names per IP per day is a good idea. We already do. (In reply to comment #0) > The autoblocker needs to be modified so that it retroactively blocks recently > used IP addresses (where recent can be as short as 10 minutes). Could use the IP address information in the recent changes table, I suppose. Might want to consider making this optional at block time, however; it has the potential to do a lot of collateral damage. Having said that, I'd prefer to just rewrite the bloody blocking mechanism.
With all due respect to Brian, I think he's wrong. Based on my experience with checkuser, I would surmise that roughly half of the vandals exploiting this bug are home DSL or cable modem users who are doing this for kicks. (And, based on teh coordinated timing of the attacks, I suspect here are multiple people doing it in tandem). As I said in my initial message, at least one attack was from the GNAA. So I think the claims about openproxies are exagerrated.
As well as the 10 accounts per day, could we impose a 1 account per minute, 3 accounts per hour? Or look at multiple acount creation in batches of 10, and test for open proxy, or connect them in a "virtual" account which gets banned together (or both)? All this merely raises the bar, but that is a good thing.
Another thing - significantly increasing the speed a checkuser (getting the IPs used by a username) can be run at (by a factor of 10 or more) would help during those attacks where someone with checkuser access is available.
FWIW, Squidward has a link to this bug report page on his website (http://www.geocities.com/georgereevesproject), and posts that URL about Wikipedia in edit summaries, in order to disseminate that tactic described as widely as possible. So this page itself is a potential security problem.
(In reply to comment #11) > FWIW, Squidward has a link to this bug report page on his website > (http://www.geocities.com/georgereevesproject), and posts that URL about > Wikipedia in edit summaries, in order to disseminate that tactic described as > widely as possible. So this page itself is a potential security problem. Security through obscurity is none at all (not to mention the fact that people were exploiting this bug for weeks before this bug report was filed)
I gave some thought to this tonight and I think I have a viable solution which I think should solve a number of blocking related problems. I propose that when blocking, the blocking admin be given the choice of 3 block classes: * Throttle - (Can only be applied to an IP address) That IP address is prohibited from anonomyous editing or registering new usernames. Logged-in editing from that address is still permitted. * Block - Similiar (identical?) to current block system. If applied to an IP address, no editing (anonomymous or logged-in) from that IP is permitted; no registration of new usernames from that IP is permitted. If applied to a username, any attempted-edits will trigger a block on the current IP. * Retroactively block - Same as block, except at block-time it is applied retroactively any accounts used during hte previous X minutes/hours/days. Should only be used in the case of the log-in-lot-out vandalism described in this bug report. Throttling could be a much more palatable alternative to destructive range blocks (which are the only solution in some of these cases). Combine these changes with a faster checkuser (getting IPs recently used bya username; comment #10 in this thread) and I think this problem will be significantly reduced.
*** Bug 3590 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > * Throttle - (Can only be applied to an IP address) That IP address is > prohibited from anonomyous editing or registering new usernames. Logged-in > editing from that address is still permitted. "Logged-in editing from that address is still permitted. " -- I put some further thought into this. The blocking admin should have the option of allowing all accounts to edit, or just 'established' accounts (the same way semiprotection stops edits from nonestablished users)
(In reply to comment #15) > "Logged-in editing from that address is still permitted. " -- I put some further > thought into this. The blocking admin should have the option of allowing all > accounts to edit, or just 'established' accounts (the same way semiprotection > stops edits from nonestablished users) Makes sense. I have to admit, I mentally changed that to "autoconfirmed accounts" when I read it the first time.
Created attachment 2658 [details] Patch, which, as a bonus, makes CheckUser faster, too.
Created attachment 2659 [details] Revised patch - for final review before commit.
Created attachment 2660 [details] Revised patch - for review; with refactoring as suggested by Brion.
Fixed in r17486.
*** Bug 6931 has been marked as a duplicate of this bug. ***
