Last modified: 2014-04-29 03:10:35 UTC
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.
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.
Erratum: “leftmost XFF entry” is a mistake, should be “rightmost”: see https://en.wikipedia.org/wiki/X-Forwarded-For#Format
