Page MenuHomePhabricator

Retroactive autoblocking needed
Closed, ResolvedPublic

Description

Author: mapellegrini

Description:
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)

  1. (cur) (last) 03:05, March 3, 2006 SUckit@excite.com
  2. (cur) (last) 03:04, March 3, 2006 Titoxd m (Reverted edits by Jayjose (JJ)

(talk) to last version by Shanel)

  1. (cur) (last) 03:04, March 3, 2006 Jayjose (JJ)
  2. (cur) (last) 03:04, March 3, 2006 Shanel m (Reverted edits by Bereavedheroz

(talk) to last version by Shanel)

  1. (cur) (last) 03:04, March 3, 2006 Bereavedheroz
  2. (cur) (last) 03:01, March 3, 2006 Shanel m (Reverted edits by MShariat (talk)

to last version by Titoxd)

  1. (cur) (last) 03:01, March 3, 2006 MShariat
  2. (cur) (last) 03:01, March 3, 2006 Titoxd m (Reverted edits by Xiao Mai Chung

(talk) to last version by Shanel)

  1. (cur) (last) 03:00, March 3, 2006 Xiao Mai Chung
  2. (cur) (last) 03:00, March 3, 2006 Shanel m (Reverted edits by AckJohn (talk)

to last version by Titoxd)

  1. (cur) (last) 03:00, March 3, 2006 AckJohn
  2. (cur) (last) 02:59, March 3, 2006 Titoxd m (Reverted edits by Ninjachu (talk)

to last version by Shanel)

  1. (cur) (last) 02:59, March 3, 2006 Ninjachu
  2. (cur) (last) 02:59, March 3, 2006 Shanel m (Reverted edits by Argentinian

jackalope (talk) to last version by Titoxd)

  1. (cur) (last) 02:59, March 3, 2006 Argentinian jackalope
  2. (cur) (last) 02:58, March 3, 2006 Titoxd m (Reverted edits by Sheeyeung (talk)

to last version by Titoxd)

  1. (cur) (last) 02:58, March 3, 2006 Sheeyeung
  2. (cur) (last) 02:57, March 3, 2006 Titoxd m (Reverted edits by Fastnaturedood

(talk) to last version by Titoxd)

  1. (cur) (last) 02:57, March 3, 2006 Fastnaturedood
  2. (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.


Version: unspecified
Severity: normal

Details

Reference
bz5149

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 9:08 PM
bzimport set Reference to bz5149.
bzimport added a subscriber: Unknown Object (MLST).

Alkivar wrote:

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

Wiki.Melancholie wrote:

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?

grmwnr wrote:

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

mapellegrini wrote:

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?

brian0918 wrote:

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

robchur wrote:

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

mapellegrini wrote:

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.

mapellegrini wrote:

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.

herostratus wrote:

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.

mapellegrini wrote:

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

mapellegrini wrote:

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.

robchur wrote:

*** Bug 3590 has been marked as a duplicate of this bug. ***

mapellegrini wrote:

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

robchur wrote:

(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
Patch, which, as a bonus, makes CheckUser faster, too.

attachment retroblockpatch ignored as obsolete

Created attachment 2659
Revised patch - for final review before commit.

attachment retroblockpatch ignored as obsolete

Created attachment 2660
Revised patch - for review; with refactoring as suggested by Brion.

Attached:

ayg wrote:

*** Bug 6931 has been marked as a duplicate of this bug. ***