[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Page MenuHomePhabricator

Create mitigations for account creation spam attack [public task]
Closed, ResolvedPublic

Description

At this time we have a rogue external bot creating 10000 of accounts an hour, primarily at mediawikiwiki If we could see if we lower the throttle to one account per IP address to see if this reduces the impact. If there was a means to even turn off API creations for mediawikiwiki that would be helpful.

We have a temporary abusefilter in place that is inhibiting much account creation
https://meta.wikimedia.org/wiki/Special:AbuseFilter/195
though we are not able to write a really sweet filter for the usernames in use. We have edged back to a somewhat conservative filter that has a bit of leakage, though looks to be allowing the good accounts through.

I have a message about the abuse filter at https://meta.wikimedia.org/w/index.php?title=Stewards%27_noticeboard

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Without checking what IP addresses are being used, there is no reason to think this would help anything. From the looks of it, they have thousands of IP addresses to use for this.
https://grafana.wikimedia.org/d/000000004/authentication-metrics?orgId=1&from=1545955201000&to=1546041540000&var-entrypoint=*

A simple sysop-level range block may be more effective, and as a local administrator I would vastly prefer it.

Update: here are some example IP addresses, courtesy Billinghurst and abusefilter blocks:
https://www.mediawiki.org/w/index.php?title=Special:Log&offset=20181228134634&limit=200&type=block&user=

Mentioned in SAL (#wikimedia-operations) [2018-12-28T15:28:05Z] <bawolff@deploy1001> Synchronized private/PrivateSettings.php: Attempt to adjust captcha settings for T212667 (duration: 00m 46s)

Mentioned in SAL (#wikimedia-operations) [2018-12-28T15:28:05Z] <bawolff@deploy1001> Synchronized private/PrivateSettings.php: Attempt to adjust captcha settings for T212667 (duration: 00m 46s)

So it appears that the spammer is making many wrong guesses at captchas, before hitting the right one. So i tried to adjust captcha settings to be more strict. I'm not sure if that will really help anything though. Thought it was worth a shot.

The bot keeps trying hard at https://www.mediawiki.org/w/index.php?title=Special:AbuseLog. We should watch the filter so it doesn't get autothrottled and disabled for too many hits in a short timespan.

Mentioned in SAL (#wikimedia-operations) [2018-12-28T18:02:04Z] <bawolff@deploy1001> Synchronized private/PrivateSettings.php: T212667 - adjust account creation (duration: 00m 47s)

Change 481528 had a related patch set uploaded (by MarcoAurelio; owner: MarcoAurelio):
[operations/mediawiki-config@master] Temporary remove AbuseFilter autoshutoff for mediawikiwiki

https://gerrit.wikimedia.org/r/481528

Change 481528 merged by jenkins-bot:
[operations/mediawiki-config@master] Temporary remove AbuseFilter autoshutoff for mediawikiwiki

https://gerrit.wikimedia.org/r/481528

Mentioned in SAL (#wikimedia-operations) [2018-12-28T18:14:50Z] <bawolff@deploy1001> Synchronized wmf-config/InitialiseSettings.php: 97446843a27 T212667 - Temp increase abusefilter emergency cutoff on mw.org to deal with spam attack (duration: 00m 46s)

@Billinghurst To add subscribers to tasks in the future, I recommend going "Add Action" (above the comment box) -> "Change Subscribers", Instead of creating a whole comment.

Mentioned in SAL (#wikimedia-operations) [2018-12-29T12:34:57Z] <bawolff@deploy1001> Synchronized private/PrivateSettings.php: T212667 - make spam mitigation global (duration: 00m 49s)

Change 481543 had a related patch set uploaded (by MarcoAurelio; owner: MarcoAurelio):
[operations/mediawiki-config@master] Amend mediawiki AbuseFilter configuration

https://gerrit.wikimedia.org/r/481543

Change 481543 had a related patch set uploaded (by MarcoAurelio; owner: MarcoAurelio):
[operations/mediawiki-config@master] Amend mediawiki AbuseFilter configuration

https://gerrit.wikimedia.org/r/481543

This patch sets the same AF configuration used at Meta-Wiki. To be merged when it is safe to re-throttle filters again.

Mentioned in SAL (#wikimedia-operations) [2018-12-29T13:30:23Z] <bawolff@deploy1001> Synchronized private/PrivateSettings.php: T212667 - adjust spam block (duration: 00m 44s)

Bawolff renamed this task from Emergency measure: Set wgAccountCreationThrottle => 2 to Create mitigations for account creation spam attack [public task].Dec 29 2018, 2:03 PM
Bawolff added a project: Security-Team.

Change 481546 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[operations/mediawiki-config@master] Temporary increase account creation

https://gerrit.wikimedia.org/r/481546

Change 481546 merged by jenkins-bot:
[operations/mediawiki-config@master] Temporary make account creation limits more restrictive

https://gerrit.wikimedia.org/r/481546

Mentioned in SAL (#wikimedia-operations) [2018-12-29T14:30:23Z] <bawolff@deploy1001> Synchronized wmf-config/InitialiseSettings.php: T212667 fe72284c Adjust account throttle limits (duration: 00m 46s)

Change 481543 merged by jenkins-bot:
[operations/mediawiki-config@master] Amend mediawiki AbuseFilter configuration

https://gerrit.wikimedia.org/r/481543

Mentioned in SAL (#wikimedia-operations) [2018-12-29T14:53:50Z] <bawolff@deploy1001> Synchronized wmf-config/InitialiseSettings.php: T212667 218371fd35 - Adjust mw.org abusefilter emergency shutoff threshold down to 0.3 (duration: 00m 46s)

Mentioned in SAL (#wikimedia-operations) [2018-12-30T02:07:32Z] <bawolff@deploy1001> Synchronized private/PrivateSettings.php: fine-tune antispam measure T212667 (duration: 00m 47s)

Mentioned in SAL (#wikimedia-operations) [2019-01-04T15:42:14Z] <bawolff@deploy1001> Synchronized private/PrivateSettings.php: T212667 - More aggressive anti-spam measures for account creation on kowiki (duration: 00m 48s)

What the status of this problem? Can the account creation throttle be reset to the old value?

What the status of this problem? Can the account creation throttle be reset to the old value?

Hi, I still see users that ask questions about this limit change. Would it be possible to have more information?

Can someone tell us what is the status of the private task? Perhaps @Aklapper @MarcoAurelio ?

@Framawiki: Can someone please tell me first which specific "private task" you refer to? :)

@Framawiki: Can someone please tell me first which specific "private task" you refer to? :)

IDK the number, I suppose there is a private task as the title of this one contains [public task] :)

There are some links above which have custom policy, though I am unaware of any private tasks that were mentioned at that time.

@Framawiki: Can someone please tell me first which specific "private task" you refer to? :)

IDK the number, I suppose there is a private task as the title of this one contains [public task] :)

I suppose there is a private task as the title of this one contains [public task] :)

I don't :)

What the status of this problem? Can the account creation throttle be reset to the old value?

Ping @Bawolff

Value should be back to six due to the International Francophone Contribution Month coming soon.

Even if it isn't, you can request a custom throttle rule, see https://meta.wikimedia.org/wiki/Mass_account_creation.

Ping? When will the temporary changes be reverted?

@sbassett Does your comment apply to all projects or just enwiki? In other words, should fe72284c5920 be reverted or a patch made for just enwiki?

@JJMC89 - Given how this was done and @Bawolff's note about it only being a temporary mitigation to be reverted after a week (back when it was implemented on December 29th, 2018), I believe fe72284c5920 should be reverted. As for changing wgAccountCreationThrottle from 6 to 10 - the rate of 6 has been in place for quite a long time, it seems: 015f5b7131ee (I'm sure it actually predates this commit, somewhere in svn.) I have no idea what the wisdom was behind that change (long before my time), but IMO I'd think it better to be cautious and limit such a change to enwiki only, for now, if it were decided that a rate of 6 wasn't sufficient within the account creator rights discussion.

sbassett triaged this task as Medium priority.Jun 22 2019, 3:33 AM

Change 518350 had a related patch set uploaded (by JJMC89; owner: JJMC89):
[operations/mediawiki-config@master] Revert "Temporary make account creation limits more restrictive"

https://gerrit.wikimedia.org/r/518350

@JJMC89 - Given how this was done and @Bawolff's note about it only being a temporary mitigation to be reverted after a week (back when it was implemented on December 29th, 2018), I believe fe72284c5920 should be reverted.

I've created a patch to revert it; however, I can't deploy and am not available during SWAT.

@JJMC89 - The weekly security deployment window is Monday 21:00–23:00 UTC. If it can wait until then (I'd guess it could?) @Reedy or I can deploy it.

@JJMC89 - The weekly security deployment window is Monday 21:00–23:00 UTC. If it can wait until then (I'd guess it could?) @Reedy or I can deploy it.

That works. It's not urgent.

As for changing wgAccountCreationThrottle from 6 to 10 - the rate of 6 has been in place for quite a long time, it seems: 015f5b7131ee (I'm sure it actually predates this commit, somewhere in svn.) I have no idea what the wisdom was behind that change (long before my time), but IMO I'd think it better to be cautious and limit such a change to enwiki only, for now, if it were decided that a rate of 6 wasn't sufficient within the account creator rights discussion.

That's covered in T225984: Allow defining account creation limits for specific groups (e.g. extended-confirmed accounts) instead.

Change 518350 merged by jenkins-bot:
[operations/mediawiki-config@master] Revert "Temporary make account creation limits more restrictive"

https://gerrit.wikimedia.org/r/518350

sbassett claimed this task.

https://gerrit.wikimedia.org/r/518350 has been deployed, reverting https://gerrit.wikimedia.org/r/481546. I'm going to resolve this task for now since I don't believe there's any outstanding issues left to address.