Page MenuHomePhabricator

Create a special throttling class for "rogue proxies" IPs
Open, Needs TriagePublic

Description

With the cheap availability of "residential proxies", which are mostly people's homes computers who are either compromised and part of a botnet, or where people installed adware which runs a proxy, our traditional IP-based throttling of actions is becoming easier and easier to circumvent.

I propose we start creating a new class of throttling of critical actions (edits, account creations, ...) that allows us to limit/block actions based on the reputation of an IP.

So basically:

  • when checking if the user can perform an action, check the reputation of their IP with our ip reputation provider service, Ipoid
  • If we get a non-empty response within a short timeout (2 seconds), and the IP is part of a residential/callback proxy network, count it towards a special throttling rule counter dedicated to those
  • Otherwise apply our normal throttling

We should probably begin applying this to account creation specifically, but the mechanism should probably be more general.

Event Timeline

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/989728 takes a more extreme approach of denying account creation outright. It could be tailored to filter more narrowly to CALLBACK_PROXY types specifically.

@kostajh - Are you aware of any plans to incorporate other, perhaps more Wikimedia-specific, reputation data within iPoid? While Spur has proven extremely useful, it can be a bit of a hammer, especially when it comes to Western bias. So I'm wondering if perhaps some internal data (edit counts, edit quality, IP location, etc.) might be incorporated within iPoid as additional meta information to help alleviate concerns around false positives.

Throttling as in MediaWiki throttling ($wgRateLimits)? I think a <2 sec delay during account creation is not ideal but acceptable, but any call to the throttler potentially being able to incur a delay seems problematic.

Or is the task about throttling in the network layer? (Probably not related to CentralAuth then.)

Not related to CentralAuth anymore since the IPReputation code has been moved to a separate extension.