https://bugzilla.wikimedia.org/show_bug.cgi?id=46604
Web browser: ---
Bug ID: 46604
Summary: There is a need for a XFF logging that does not depend
on other attributes
Product: MediaWiki
Version: 1.20.3
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: Unprioritized
Component: General/Unknown
Assignee: [email protected]
Reporter: [email protected]
Classification: Unclassified
Mobile Platform: ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
