Talk:XFF project

Active discussions

Thank you for this excellent explanation of both the philosophical basis and technical application of this tool. Great work!--BradPatrick 14:46, 29 March 2006 (UTC)

In Italy we are suffering a major vandalism campaign from one or more users with IPs by TIM mobile GPRS. It is going on since weeks ago, and situation is becoming critical.
TIM uses a proxy system similar to the one listed in this page. Is it possible to have XFF check activated for TIM too?
It could be useful for italian Fastweb users, too. This ISP uses a proxy system (but I don't know details). Please leave feedback to it:Utente:Jollyroger - --Jollyroger 14:26, 16 June 2006 (UTC)
What are the proxy addresses? -- Tim Starling 06:34, 18 June 2006 (UTC)

XFF IP limitationsEdit

Does this system have a sort of safety feature in the event that someone misusing (think malicious person controlling a proxy server due to exploits or the like) one of these proxy servers in which their hidden XFF IP is limited to a range.

  1. To be clear, a limitation such as 212.113.164.97 (the first one on the list) can only forward IPs of 212.113.160.0/24, and nothing else. That way if one of these proxy servers is comprimised, which could happen, someone cannot just spoof the IP to anything they feel like, they'd be limited to a pre-determined range which could be blocked then traced back to the proxy server that is comprimised. 4.181.9.203 03:18, 12 July 2006 (UTC)
We have a log of X-Forwarded-For headers for POST requests which can be used to investigate any claim of IP address spoofing. -- Tim Starling 17:07, 20 February 2007 (UTC)

Qtel proxiesEdit

The Qtel proxy 82.148.97.69 was recently the subject of much controversy (see en:User talk:82.148.97.69). I notice that two other addresses from the same block appear to be on the XFF list

 82.148.97.67  proxy.qatar.net.qa
 82.148.97.68  proxy.qatar.net.qa

Both of these reverse-lookup to proxy.qatar.net.qa However, 82.148.97.69, although it is numerically the next IP address in sequence, does not have a PTR record at all.

If 82.148.97.69 is also XFF-enabled, and can be trusted as being run by the ISP itself, could it also be added to the XFF list? Perhaps this needs someone from the XFF project to get in touch with Qtel to confirm this, and Qtel themselves to set up a PTR record? -- The Anome 15:09, 8 January 2007 (UTC)

82.148.97.69 is not giving XFF headers. -- Tim Starling 19:52, 18 February 2007 (UTC)

TPG InternetEdit

I noticed that TPG Internet is on the trusted XFF list, however, some of their proxies are missing from the listing. A full list of their proxies is available at http://forums.whirlpool.net.au/forum-replies-archive.cfm/493725.html. These proxies all correctly send the X-Forwarded-For header. -- Daniel15 13:42, 10 April 2007 (UTC)

usageEdit

can mediawiki installations other than wikipedia check/block by XFF? if so, how is this achieved? --Hexvoodoo 06:46, 27 April 2007 (UTC)

There are no XFF blocks, you can only flag ISPs as trusted, which causes the XFF client IP (first of the chain) to be reported as the user's IP, allowing for it to be blocked normally. Voice-of-All 17:57, 29 May 2007 (UTC)

Question - website to show if XFF is enabled?Edit

My ISP's proxy server, proxy.idl.net.au (202.92.102.220) is, as far as I know, running squid. It actually appears to have a current block on en.wikipedia: block log for User:202.92.102.220

Is there a web site that can be used to show whether XFF is enabled or not? A link to such a site would seem useful to include in this article.

(Note that I configured privoxy to not use the proxy due to blocking problems, so log info from this edit wouldn't help.) --AtholM 12:02, 22 September 2007 (UTC)

I know a wayEdit

I think that http://whatismyip.com/ will tell you if you are showing the forwarding header. Also PHP's phpinfo() function will dump all HTTP Request headers. Try this google search: http://www.google.com/search?q=%2Bphpinfo+%2BSCRIPT_FILENAME+%2BZend ... Click any of the links in the google result page. Scroll down to "Apache Environment" and read all the headers starting with "HTTP_" and you can read all your headers. (Or of course just search in page for "X_FORWARDED_FOR", and if it doesn't come up then you're not sending that header). Another quick search gave me http://murl.mobi/headers.php - and finally, http://whatismyuseragent.com/ might show the XFF header when it's present. I'm not sure. But at least the raw header dumps from murl.mobi and phpinfo() will tell you. 222.153.223.45 22:43, 14 September 2011 (UTC)

Also interesting, but how to check someone else?Edit

http://www.ip.cc/check-proxy-basic.php and http://www.ip.cc/anonymity-test.php - although they basically told me that they were unable to detect a proxy on my ip (which is very wrong). So how do I find a place where SOMEONE ELSE has logged who is an isn't behind a proxy? 222.153.223.45 22:43, 14 September 2011 (UTC)

Opera MiniEdit

There's been some discussion about the Opera Mini mobile browser on the English Wikipedia. It seems that any edits made with that browser, including those using its online demo applet, go through a proxy network and come out of multiple IPs in the 195.189.142.0/23 range. However, the requests do seem to carry X-Forwarded-For headers, which, for the demo applet at least, point to a single host, demo.opera-mini.net (195.189.142.176). I suspect that, for actual mobile users, the headers will point to the address at which the request entered the proxy network, which may be more stable than the address at which they emerge.

Thus, adding the Opera Mini proxy network to the trusted XFF list should at least allow us to distinguish genuine mobile Opera Mini users from those (ab)using the demo applet. Does this seem like a good idea? Of course, it'd be even better if we could persuade the folks at Opera to provide a full chain of XFF headers pointing back to the user's actual IP address, for the demo interface at least. --Ilmari Karonen 16:15, 30 September 2007 (UTC)

Update: It seems that, for mobile users, the proxies do pass existing XFF headers; it's only the demo interface which cuts the list at the entry point. So I'd definitely support adding these proxies (which all seem to have hostnames of the form pNN-NN.opera-mini.net) to the trusted XFF list. Now if we could only get them to fix the demo interface...--Ilmari Karonen 21:46, 30 September 2007 (UTC)
I've compiled what may or may not be a complete list of the proxies at en:User:Ilmari Karonen/sandbox/Opera Mini. The range of the second number pair seems to be 01–16; the first number pair (currently?) goes from 01 to 11, with gaps at 02 and 06. Incidentally, the list shows that four of the proxies seem to be in a different IP range (80.232.117.0/24) than the others. --Ilmari Karonen 01:14, 1 October 2007 (UTC)
Bump - please can the list Ilmari has built above be added? The conversation at w:Wikipedia:Administrators'_noticeboard#Opera-Mini might be of interest. Proto 08:49, 2 July 2008 (UTC)
See the request on Bugzilla:14700 from yesterday. Raymond 09:00, 2 July 2008 (UTC)

Xxx Xxx~metawiki (talk) 06:48, 21 March 2016 (UTC)

Dynamic IP?Edit

In a split discussion at w:User_talk:Smartiger and w:User_talk:LeadSongDog, Smartiger asks if XFF can help with ISP's that allocate IP dynamically. The answer isn't obvious from the project page. LeadSongDog 15:45, 19 December 2009 (UTC)

If the editor's computer is using an ISP HTTP proxy that supports XFF (at least when editing Wikipedia), it should be handled correctly. It shouldn't matter whether the ISP assigned that computer a static or dynamic address, or even whether the editor's computer has an external IP. The questions of whether the ISP allocates IPs dynamically and whether a HTTP proxy is in use are separate. Superm401 | Talk 02:09, 9 February 2012 (UTC)
The part about private (non-external) IPs was incorrect. Private IPs are not currently handled; this is discussed here. Superm401 | Talk 02:17, 9 February 2012 (UTC)

210.55.215.173Edit

Hi project, I don't know how alive this project still is. I sent a mail to the address of the content page a while back, but never heard from that again - maybe the list is backlogged, or dead, but the project isn't so, I'm raising it here to. I think 210.55.215.173 is a caching server for telecom NZ. It looks like it's clients do receive public IP's. With that, it would be a good candidate to trust XFF headers from, if they are sent properly. Could someone check if this is an option? Cheers, Martijn Hoekstra (talk) 11:53, 15 March 2012 (UTC)

Starhub/MaxonlineEdit

It looks like the Maxonline proxy list is incomplete: en: Wikipedia have had a request for unblocking from 218.186.8.13, which has a reverse DNS lookup of 218.186.8.13.cache.maxonline.com.sg. See en:WP:AN today. -- The Anome (talk) 11:40, 24 June 2012 (UTC)

ClarificationEdit

Something that isn't clear from this discussion: if XFF headers are working properly, which IP shows up in a standard contributions log: the IP of the anonymous user, or the IP of the proxy that edits are coming through?Kww (talk) 21:30, 22 May 2013 (UTC)

You question is not clear from this discussion, but I'm confident recent updates to the page answered it. --Nemo 17:07, 25 May 2013 (UTC)

Process and speed of updatesEdit

To also answer your question on the XFF project and on-wiki lists, there's rarely urgency to mark proxies as trusted: you need it only when a lot of abuse is coming via the proxy but for some reason you don't want to block the whole proxy and then deal with individual exceptions (as we usually do). It's also something that must be done with care because it makes it hard for sysops to block the whole proxy if it happens to be abused, though in that regard perhaps mw:Manual:$wgApplyIpBlocksToXff would now allow to block the proxy if its IP is in the XFF headers. --Nemo 17:07, 25 May 2013 (UTC)

Google data compression proxiesEdit

It looks like Google is operating what are effectively open proxy farms for Chrome mobile users: these do not seem to be on the XFF list. For an example of such a proxy, do a PTR lookup on 66.249.93.191. I cannot find any list of these on the web, or any way of deriving that list other than brute-force techniques. See [1], [2] and this talk page for more details. Given that Chrome is a major browser, this could potentially become a major problem if not fixed. -- The Anome (talk) 15:56, 16 November 2014 (UTC)

Update: I've blocked 66.249.93.0/24 on enwiki, as the entire /24 appears to be nothing but these proxies. -- The Anome (talk) 19:55, 16 November 2014 (UTC)
@The Anome: Relevant notes: "Secure connections (HTTPS) are routed directly from your mobile device to the destination, bypassing the compression proxy." So a lot of logged in traffic will not be affected. Erik Moeller (WMF) knows some people at Google. Maybe those contacts can help us get a list of the proxy IP ranges. Superm401 | Talk 06:25, 3 December 2014 (UTC)
Thanks -- that's great. Do you know if any progress has been made on this? -- The Anome (talk) 14:16, 13 January 2015 (UTC)
@The Anome: I haven't heard anything or contacted him further about this (I think I only pinged him above), so probably not. It may make sense to file a bug to track the issue. Mattflaschen (WMF) (talk) 05:08, 14 January 2015 (UTC)
Return to "XFF project" page.