Page MenuHomePhabricator

$wgApplyIpBlocksToXff feature should ignore local IPs from remote proxies
Open, MediumPublicFeature

Description

Author: Innocenti.Maresin

Description:
Blocking IPs from RFC1918 networks can be useful for MediaWiki installations that have routing to such networks (Wikimedia with its WMLabs is an example), but using the $wgApplyIpBlocksToXff feature, introduced by id=23343, leads to a bug that appeared, for example, at
https://en.wikipedia.org/w/index.php?title=Special%3ALog&page=User%3A10.68.0.0%2F16
Namely, MediaWiki blocks users from unrelated networks that use same IPs and edit through proxies. Since there is no practical possibility to distinguish local IPs from various networks over the world, all non-global IPs mentioned by remote proxy servers should be ignored. Namely, well-known “non-global IPs” are:
• IPv4, those of RFC1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/8
• IPv4, miscellaneous: 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, and possibly others
• IPv6: fc00::/7, fe80::/10, and possibly others
See https://en.wikipedia.org/wiki/Reserved_IP_addresses for reference.
This list can be hard-coded because it is rather stable for many years, if not decades.

A robust implementation will be somewhat difficult, because it must distinguish “local” and “remote” proxies. If there is a local HTTP proxy, routed to RFC1918 networks to which IP blocks should be applied (as in the case of Wikimedia), then such local proxy may say:
X-Forwarded-For: 10.68.16.32
, and IP blocks must be applied then.

But if a user from another planet, that uses the same IP in a LAN, makes a request though a proxy in his/her LAN, then MediaWiki gets either
X-Forwarded-For: 10.68.16.32 [from proxy.lan.Mars]
or
X-Forwarded-For: 10.68.16.32, proxy.lan.Mars [from local proxy]
, and in both cases IP blocks may not be applied.
This can be implemented like:
apply all IP blocks to the TCP connection source
connection is local ∧ leftmost XFF entry ⇒ apply all IP blocks to the XFF entry
connection is local ∧ other XFF entry ⇒ apply only global IP blocks to the XFF entry
connection isn’t local ∧ any XFF entry ⇒ apply only global IP blocks to the XFF entry
This set of rules ignores the case of a chain of two local proxies, but this is unlikely to happen.

See https://www.mediawiki.org/wiki/Manual:$wgApplyIpBlocksToXff for reference about the current implementation.


Version: 1.24rc
Severity: enhancement

Details

Reference
bz64530

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:10 AM
bzimport set Reference to bz64530.
bzimport added a subscriber: Unknown Object (MLST).

Related to bug 42438.

Also of note is that 100.64.0.0/10 is now technically private address space for the sole purpose of carrier-grade NAT and so should be included there.

Also, I will note that blocking based on a combination of both the NAT'd and public addresses would be useful when carrier-grade NAT becomes more prevalent.

Innocenti.Maresin wrote:

Erratum: “leftmost XFF entry” is a mistake, should be “rightmost”: see https://en.wikipedia.org/wiki/X-Forwarded-For#Format

This only happens if one manually blocks 10.68.0.0/16, not with autoblocks, right?

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:23 PM