Last modified: 2014-02-12 23:32:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T48604, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 46604 - Need for a XFF logging that does not depend on other attributes
Need for a XFF logging that does not depend on other attributes
Status: UNCONFIRMED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.20.x
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-27 15:19 UTC by Eitan Caspi
Modified: 2014-02-12 23:32 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Eitan Caspi 2013-03-27 15:19:59 UTC
This enhancement request bug is originated from the following support forum thread: 
http://www.mediawiki.org/wiki/Project:Support_desk#Using_a_range_of_IP_addresses_within_.24wgSquidServers_25325

The need: I wish to use a 3rd party online/cloud security service called Incapsula (but the idea is general). This service handle all HTTP/HTTPS traffic to the site and block clients based on various conditions (know bad sources, comment/spam bots, known attack patterns and more). It also has a caching function.
This service is acting as a proxy, so MediaWiki "see" the service IP as the client, but Incapsula also send a XFF header.
The service is made out of hundreds of servers scattered around the globe with many, non-sequential, ip address ranges.

So, when one wish to tell MediaWiki to log the most inner XFF attribute as the true client IP address and not the get the standard Incapsula random server IP address - he/she has a problem.

(The need for the real source IP is mostly for blocking misbehaving sources, so the admin can block just the unique source and not a client-unifying proxy server, which also serves legit clients)

Why is there a problem?

1. I tried to use the $wgUsePrivateIPs directive of localsettings.php . But, it forces the user to also use with it either $wgSquidServers or $wgSquidServersNoPurge - but these two accept, AFAIK, only SINGLE ip address as values into its array format - which means that I should enter each an every IP address of all the Incapsula servers. Not logical.

2. When I tried to solve this by using the extension of TrustedXFF, I learned it has to have the DBA module of PHP enabled on the underlying web server, but I am at a shared hosting plan, and my hosting company is not willing to compile this module for shared installations. I guess I'm not alone in this configuration.

So, it looks like I reached the end of my XFF logging options...

I wish to ask for a solution for this.
Possible solutions I see for this:

1. The simplest - add a new type of $wgUsePrivateIPs that will not be forced to be accompanied by any other directive and will simply always take the XFF most inner value and set it to be the logged source client. If there is no XFF header, than the IP level address will be logged.
Admins will be able to limit the access from the actual proxy servers by out-of-band means, like relevant web server restrictions (like the .htaccess file for Apache).

2. Enhance $wgSquidServers or $wgSquidServersNoPurge to accept ip ranges (e.g. (x-y) or subnet definition (either 1.2.0.0 netmask 255.255.255.0 or as 1.2.0.0/24 (CIDR)). Ip ranges is a more flexible format as it doesn't have to be bound to known subnet block sizes.

Thank you.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links