Directory

⚓ T354599 [EPIC] Provide IP reputation variables in AbuseFilter
Page MenuHomePhabricator

[EPIC] Provide IP reputation variables in AbuseFilter
Open, Needs TriagePublic

Description

Context

In T354597: Record IP reputation data for account creations and edits we'll likely discover that there are combinations of IP reputation data that usually result in unwanted edits or account creations. We should allow AbuseFilter maintainers to be able to create filters targeting traffic using a subset of labels in the IP reputation data.

Proposal

Introduce IP reputation AbuseFilter protected variables for things like risks (callback proxy, VPN), tunnel types, client concentration count, or simply being present in iPoid-Service's database. Based on spur.us documentation, some possibilities for variables:

  • client.behaviors
  • client.count
  • client.countries
  • client.proxies
  • infrastructure
  • risks
  • services
  • tunnels.anonymous
  • tunnels.operator
  • tunnels.type

Consequences

We would be able to define mitigations in AbuseFilter based on edits from IPs matching specific IP reputation variables.

Notes from L3SC discussion

Copying over some requirements from L3SC discussion:

[,,,] variables like tunnels.operator could narrow down user identification, especially if the VPN service is uncommon and the Abuse Filter has some overly narrow combinations of conditions. Even in that case, the risk would still be low since Abuse filters are under tight community scrutiny and filter maintainers are highly trusted volunteers who exercise care when crafting filter conditions. Additionally, with the guarantee, IP reputation AbuseFilter variables will only be restricted to AF maintainers, rather than making them visible to the wider public, there is an extra layer of precaution.

want to reiterate that we build in the right measures/controls to mitigate false positives, for eg editors from some countries often. use open proxies/shared ip addresses and may not necessarily have malicious intent and could be wrongly tagged in the abuse filter.

Conclusion:

  • The variables need to be treated in the same way as user_unnamed_ip, in that they are considered "protected variables" and the filters and logs where they are used are accessible only to users with the right to view filters with protected variables.

Related Objects

Event Timeline

We may also want to have T360195: Analyze IP reputation data and how it maps to on-wiki editing and account creation activity done first, to better guide people who create filters using facets of IP reputation data as AbuseFilter variables.

Legal, Safety & Security Service Center approval is tracked internally in https://app.asana.com/0/1201516671270795/1208282856628615/f.

One thing to note regarding consequences/use cases is that implementing these variables to would likely mean that admins and stewards pivot from preventing edits from commercial VPN and open proxy IPs by blocking individual IPs and ranges associated with these networks towards preventing them via filters that target service attributes. This would overall be a good thing, because it would (1) allow for better targeting, (2) reduce collateral, and (3) drastically reduce the time investment required. So it wouldn't just enable us to better handle potentially problematic IPs (specifically those associated with botnets and residential proxy networks), but also enable us to mostly automate NOP enforcement in the area of commercial VPNs, which Spur identifies extremely well.

kostajh renamed this task from Make IP reputation available as a variable in AbuseFilter to Provide IP reputation variables in AbuseFilter.Nov 1 2024, 3:01 PM
kostajh updated the task description. (Show Details)
kostajh changed the task status from Stalled to Open.Nov 21 2024, 10:21 AM

We have L3SC approval.

I'll turn this into an epic, where we can track individual variables as subtasks.

kostajh renamed this task from Provide IP reputation variables in AbuseFilter to [EPIC] Provide IP reputation variables in AbuseFilter.Nov 21 2024, 10:37 AM
kostajh updated the task description. (Show Details)