If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

wiki.mozilla.org discloses internal IP

RESOLVED FIXED in 2014-Q1

Status

Websites
wiki.mozilla.org
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: Luke Deller, Assigned: jd)

Tracking

unspecified
2014-Q1

Details

Attachments

(1 attachment)

1.96 KB, application/octet-stream
Details
(Reporter)

Description

4 years ago
Created attachment 755283 [details]
full email received

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31

Steps to reproduce:

I registered a new account on wiki.mozilla.org


Actual results:

I received an email which began:

Someone, probably you, from IP address 10.8.81.216,
has registered an account "Luked" with this email address on MozillaWiki.


Expected results:

That IP address which is internal to your network should not have been disclosed to me.  My own presenting IP address should have been shown instead, which starts with 110.33.
This probably means $wgUsePrivateIPs and $wgSquidServersNoPurge need to be set.  I'll need a list of the IPs if there are more than the one listed here.

https://www.mediawiki.org/wiki/Manual:$wgUsePrivateIPs
https://www.mediawiki.org/wiki/Manual:$wgSquidServersNoPurge
(Assignee)

Comment 2

4 years ago
From the config file

$wgUseSquid = true;
$wgSquidServers = array('10.8.81.215','10.8.81.216','10.8.81.217','10.8.81.218','10.8.81.219');

Let me know if this is not the information you need and what I need to do to correct the issue. From looking at the links you posted I am not sure what purge will do.

Thanks
Assignee: nobody → jcrowe
Flags: needinfo?(mah)
QA Contact: nmaul
k, settings look correct, but I was able to reproduce this.  Could you confirm that the wiki does get X-Forwarded-For IPs for the proxy?
Flags: needinfo?(mah)
(Assignee)

Comment 4

4 years ago
Due to a stupid decision to be unique like a snowflake, and back when they were Zeus the makers decided to create 'X-Cluster-Client-Ip' instead of using 'X-Forwarded-For' for the client IP header (they wanted to make sure no one could simply switch to Varnish IMHO).

There are two solutions, the first is to change the app to use the snowflake header (I do not know if this is possible in MW). The second is that I can add a traffic rule to the load balancer pool to add the 'X-Forwarded-For' header.

Let me know what you think is best / simplest / best.

Thanks
(In reply to Jason Crowe [:jd] from comment #4)
> There are two solutions, the first is to change the app to use the snowflake
> header (I do not know if this is possible in MW). The second is that I can
> add a traffic rule to the load balancer pool to add the 'X-Forwarded-For'
> header.

If I were to fix this in MW core, I would like to get some review for the change.  Patching the code would be trivial, but the problem would pop up the next time MW is upgraded since X-Forwarded-For is currently hard-coded.

Client-IP was also checked pre-1.19 -- maybe that is available?  I'll look at why it was removed in 1.19 (which just happens to be the version used)
(Assignee)

Comment 6

4 years ago
I added the 'X-Forwarded-For' in a traffic rule. This is a trivial fix. It is unfortunate that a bad decision by Zeus some years ago has lead to this problem (It is actually quite common and causes a ton of problems). We will need to be diligent in the future to ensure this setting gets moved if this site is migrated, otherwise the issue will reoccur. It sucks to use a transient solution to attempt to work around bad decisions, but alas this is where we find ourselves.

Let me know if this solves the issue.
(Assignee)

Comment 7

4 years ago
I believe this issue was resolved back when. I will close this bug out now.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2014-Q1
You need to log in before you can comment on or make changes to this bug.