Hoi,
A user of the nl:wikipedia who had the misfortune to be blocked on a proxy server, mentioned that many providers send a HTTP_X_FORWARDED_FOR header along. This she said could easily be retrieved using PHP with the variable $_SERVER["HTTP_X_FORWARDED_FOR"]. Now when this is true, it makes excellent sense to use this IP-adress for the registration of contributions but also for the use of blocking specific IP numbers.
I have no idea if our software uses this or not. I thought this a great idea so I move this remark to you in the hope that we can enhance our software and make our anti vandal solutions more accurate.
Thanks, GerardM
Gerard Meijssen wrote:
Hoi,
A user of the nl:wikipedia who had the misfortune to be blocked on a proxy server, mentioned that many providers send a HTTP_X_FORWARDED_FOR header along. This she said could easily be retrieved using PHP with the variable $_SERVER["HTTP_X_FORWARDED_FOR"]. Now when this is true, it makes excellent sense to use this IP-adress for the registration of contributions but also for the use of blocking specific IP numbers.
I have no idea if our software uses this or not. I thought this a great idea so I move this remark to you in the hope that we can enhance our software and make our anti vandal solutions more accurate.
In my experience, caching proxies from ISPs don't usually give an XFF header. It's only a squid extension anyway, not part of the HTTP standard. Open proxies give an XFF header maybe 50% of the time.
AOL, for example, gives no information in their HTTP headers which identifies a user. This is a deliberate policy aimed at protecting privacy.
-- Tim Starling
Tim Starling wrote:
Gerard Meijssen wrote:
Hoi,
A user of the nl:wikipedia who had the misfortune to be blocked on a proxy server, mentioned that many providers send a HTTP_X_FORWARDED_FOR header along. This she said could easily be retrieved using PHP with the variable $_SERVER["HTTP_X_FORWARDED_FOR"]. Now when this is true, it makes excellent sense to use this IP-adress for the registration of contributions but also for the use of blocking specific IP numbers.
I have no idea if our software uses this or not. I thought this a great idea so I move this remark to you in the hope that we can enhance our software and make our anti vandal solutions more accurate.
In my experience, caching proxies from ISPs don't usually give an XFF header. It's only a squid extension anyway, not part of the HTTP standard. Open proxies give an XFF header maybe 50% of the time.
AOL, for example, gives no information in their HTTP headers which identifies a user. This is a deliberate policy aimed at protecting privacy.
-- Tim Starling
If we can cut down on 50% of the inaccurate blocks and many of the blanket blocks when an XFF header IS given, we achieve a much more fine grained tool of hurting vandalism without having to resort to always removing the blocks because of good people being hurt by it. When it is not feasible because the chance of doctored information from malicious users is too great it is not possible. But 50% more accuracy when dealing with proxies sounds good to me.
Thanks, Gerard
On Mon, 08 Nov 2004 19:37:11 +0100, Gerard Meijssen gerardm@myrealbox.com wrote:
When it is not feasible because the chance of doctored information from malicious users is too great it is not possible. But 50% more accuracy when dealing with proxies sounds good to me.
The problem is, how do we know if a given proxy is giving out accurate information? All it takes is somebody faking the header while they vandalise, and they can choose who to take the blame, potentially deliberately blocking some valued user, or inflaming some quasi-political situation...
So, the most that would be sensible would be to have a list of "trusted proxies" from whom we took the XFF header to be a genuine record; though, the situations in which anyone would be behind a proxy and still have a valid IP of their own would seem to me to be rather limited, once you've discounted those deliberately hiding their identity...
Gerard Meijssen wrote:
If we can cut down on 50% of the inaccurate blocks and many of the blanket blocks when an XFF header IS given, we achieve a much more fine grained tool of hurting vandalism without having to resort to always removing the blocks because of good people being hurt by it. When it is not feasible because the chance of doctored information from malicious users is too great it is not possible. But 50% more accuracy when dealing with proxies sounds good to me.
I said 50% of open proxies, i.e. unsecured proxies. They're only used by vandals, Chinese people, and the occasional user who accidentally put one on their own computer. We already have a policy to block all such proxies on sight, except on zh. I've never seen an ISP proxy give a meaningful XFF header, although admittedly I haven't been looking too closely.
XFF headers have been useful to us in the past, for example they allowed us to prove that it was Wik who was running a vandalbot attacking meta. This allowed us to put together a solid complaint to his ISP. It wasn't a useful filter method, because he was using a combination of forwarding and non-forwarding proxies.
In a few percent of cases, this feature may allow discrimination between vandals and other users. But it also opens up a security vulnerability. It allows any blocked user with a basic knowledge of HTTP to block any IP address they wish, just by pasting things into a telnet window.
I think a much better tool to discriminate between vandals and other users would be a username whitelist or "trusted user" metric. This allows discrimination even in the more common cases of dynamic IP addresses and non-forwarding proxies. I'm not prepared to spent any time on a feature which will only be useful in a tiny fraction of cases, and will open up a security flaw.
-- Tim Starling
wikitech-l@lists.wikimedia.org