Page MenuHomePhabricator

Ability to configure a wiki to auto block open proxies
Open, Stalled, Needs TriagePublicFeature

Description

Why

  • Since ST47ProxyBot (userpage, block log) has stopped blocking open proxies on English Wikipedia, I assume the amount of LTA-related proxy vandalism and abuse has increased. In particular, I wonder if the MidAtlanticBaby LTA would be stopped if this bot were still running.

What

  • Pick a MediaWiki extension (AutoModerator? TorBlock?) or create an extension to add the following functionality to:
    • Config variable such as $wgBlockOpenProxies = true
    • When set to true on a wiki, duplicates the functionality of ST47ProxyBot, which checked some kind of third party open proxy list, then blocked IP addresses for 14 days, 1 year, 2 years, or sometimes a different duration, depending on whether or not they were on that list, what type of proxy they were, and maybe an additional factor
    • The algorithm appears to be "a combination of open-source intelligence, blocklist APIs, and port scanning/fingerprinting". (More details.)
  • Alternatively: use AbuseFilter variables based on IP reputation data T354599: [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter

Notes

  • cc @Samwalton9-WMF and @kostajh, since this overlaps with some of your work (AutoModerator, IPInfo). cc @ST47, original bot maintainer.
  • if we implemented this via a hook that stops the attempted action, we could avoid spamming the block log, which was a downside of ST47ProxyBot
  • search keyword: VPNGate

See also: T166817: Globally block identifiable open proxies

Related Objects

StatusSubtypeAssignedTask
StalledFeatureNone
ResolvedDreamy_Jazz
Resolvedkostajh
Resolvedsbassett
DuplicateDreamy_Jazz
DuplicateSTran
ResolvedSTran
DuplicateDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedSTran
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedSTran
ResolvedSTran
ResolvedSTran
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedDreamy_Jazz
ResolvedSecurityDreamy_Jazz
ResolvedSecurityDreamy_Jazz
ResolvedSecurityDreamy_Jazz

Event Timeline

Novem_Linguae renamed this task from Feature request: ability to configure a wiki to auto block open proxies to Ability to configure a wiki to auto block open proxies.Nov 26 2024, 8:27 PM
Novem_Linguae changed the subtype of this task from "Task" to "Feature Request".

I assume the amount of LTA-related proxy vandalism and abuse has increased

I am not sure about this assumption. It would be great to have some data on it. For example, we can see the number of blocks drop off when ST47ProxyBot goes offline in March:

image.png (944×954 px, 71 KB)

and the rate of reverts stays about the same

image.png (784×950 px, 66 KB)

as do page protections

image.png (784×950 px, 71 KB)


@Novem_Linguae for this task, my suggestion is that we solve it via T354599: [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter, especially as there is some work underway now for that feature as part of WE4.2 Anti-abuse work stream. If we then find that the AbuseFilter approach is not sufficient, we could look at achieving this task in a different way.

I certainly have felt like the bot's absence has had a negative effect on Wiki. One example is, during my NPP work, I patrol redirects. Every day this last week or two I'm finding at least 5-10 unreviewed redirects as the result of caste / clan related articles being redirected by IPs which have often ended up blocked as proxies by the time I find the redirect. I bet I'm missing quite a few as well with other editors marking those redirects as reviewed, whereas I'm reverting the BLARs which typically have very misleading edit summaries. Definitely some edits in contentious areas taking place that might not have otherwise.

@kostajh, FYI, the files you've linked to are currently showing as restricted.

edit: not any more :)

I certainly have felt like the bot's absence has had a negative effect on Wiki. One example is, during my NPP work, I patrol redirects. Every day this last week or two I'm finding at least 5-10 unreviewed redirects as the result of caste / clan related articles being redirected by IPs which have often ended up blocked as proxies by the time I find the redirect. I bet I'm missing quite a few as well with other editora marking those redirects as reviewed, whereas I'm reverting the BLARs which typically have very misleading edit summaries. Definitely some edits in contentious areas taking place that might not have otherwise.

Ack, thanks for this. We will hopefully have some mechanism in place to allow for mitigating actions from anonymous proxies and proxies by name via subtasks of T354599: [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter.

@kostajh, FYI, the files you've linked to are currently showing as restricted.

edit: not any more :)

Yeah, sorry about that!

$wgBlockOpenProxies

This is indeed a feature in older MediaWiki: https://www.mediawiki.org/wiki/Manual:$wgBlockOpenProxies (removed in T56597). A number of related settings still exists in master version of MediaWiki, such as $wgEnableDnsBlacklist and $wgProxyList (which provides indirect support of third party open proxy list). See also T76301: Remove all proxy blocking functionalities from mediawiki core

Note in Wikimedia it is much better that proxies be globally blocked.

@Novem_Linguae can we mark this as stalled while Trust and Safety Product Team is working on shipping T354599: [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter? If we find that AbuseFilters using IP reputation data are not sufficient for this problem, we could think about a dedicated extension.

Novem_Linguae changed the task status from Open to Stalled.Dec 2 2024, 9:11 AM

OK. Marking as stalled.

I definitely like having this ticket to centralize discussion. This will probably come up in the future. Thanks for your input so far.

@Novem_Linguae can we mark this as stalled while Trust and Safety Product Team is working on shipping T354599: [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter? If we find that AbuseFilters using IP reputation data are not sufficient for this problem, we could think about a dedicated extension.

This is now available: https://www.mediawiki.org/wiki/Extension:IPReputation/AbuseFilter_variables

That said, I would suggest not creating blocking actions based solely on these variables, but instead looking at ways to combine the IP reputation signals with other AbuseFilter variables to mitigate abuse as needed.

Thank you very much for you and your team's work on this. Should help a lot with LTAs using proxies.

Related: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Resurrect_ST47ProxyBot%3F

Some folks make good arguments to not bring back ST47ProxyBot, although a bot to block VPNGate is mentioned as a good idea.