Last modified: 2006-12-13 15:57:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T7149, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 5149 - Retroactive autoblocking needed
Retroactive autoblocking needed
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: High normal with 10 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 3590 6931 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-03 03:24 UTC by Mark Pellegrini
Modified: 2006-12-13 15:57 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch, which, as a bonus, makes CheckUser faster, too. (5.29 KB, patch)
2006-11-08 08:20 UTC, Andrew Garrett
Details
Revised patch - for final review before commit. (5.28 KB, patch)
2006-11-08 08:45 UTC, Andrew Garrett
Details
Revised patch - for review; with refactoring as suggested by Brion. (6.92 KB, patch)
2006-11-08 09:31 UTC, Andrew Garrett
Details

Description Mark Pellegrini 2006-03-03 03:24:29 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.
Comment 1 Jon 2006-03-03 12:22:50 UTC
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
Comment 2 Melancholie 2006-03-03 14:23:36 UTC
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?
Comment 3 grm_wnr 2006-03-03 16:10:53 UTC
(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.
Comment 4 Mark Pellegrini 2006-03-18 02:05:46 UTC
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. 
Comment 5 Brion Vibber 2006-03-18 07:12:29 UTC
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?
Comment 6 brian0918 2006-03-18 07:15:45 UTC
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).
Comment 7 Rob Church 2006-03-18 16:19:32 UTC
(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.
Comment 8 Mark Pellegrini 2006-03-19 23:58:17 UTC
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. 
Comment 9 Rich Farmbrough 2006-03-20 09:37:49 UTC
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.
Comment 10 Mark Pellegrini 2006-03-21 00:54:27 UTC
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. 
Comment 11 Horsey Windpump 2006-03-21 04:34:19 UTC
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. 
Comment 12 Mark Pellegrini 2006-03-21 08:48:10 UTC
(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)
Comment 13 Mark Pellegrini 2006-04-04 08:20:36 UTC
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. 
Comment 14 Rob Church 2006-04-04 09:27:10 UTC
*** Bug 3590 has been marked as a duplicate of this bug. ***
Comment 15 Mark Pellegrini 2006-04-07 07:51:39 UTC
(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)
Comment 16 Rob Church 2006-04-07 14:31:08 UTC
(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.
Comment 17 Andrew Garrett 2006-11-08 08:20:10 UTC
Created attachment 2658 [details]
Patch, which, as a bonus, makes CheckUser faster, too.
Comment 18 Andrew Garrett 2006-11-08 08:45:49 UTC
Created attachment 2659 [details]
Revised patch - for final review before commit.
Comment 19 Andrew Garrett 2006-11-08 09:31:07 UTC
Created attachment 2660 [details]
Revised patch - for review; with refactoring as suggested by Brion.
Comment 20 Andrew Garrett 2006-11-08 10:07:13 UTC
Fixed in r17486.
Comment 21 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-13 15:57:08 UTC
*** Bug 6931 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links