MediaWiki can't see IPs past the reverse proxy

Discussion about the site's wiki, including bugs/issues encountered

Moderator: Moderators

Post Reply
tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

MediaWiki can't see IPs past the reverse proxy

Post by tepples » Thu Nov 10, 2016 5:39 pm

I edited talk pages on wiki.nesdev.com four times, from three different subscribers to a cable ISP and one cellular ISP, and MediaWiki said the edits came from the same IP address all four times. And this IP is in the same /30 as the result of nslookup wiki.nesdev.com. (Reverse proxy much?) This means my wiki spam control must rely on ABUSE filtering instead of my usual practice of blocking an IP for a few months.

User avatar
koitsu
Posts: 4216
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: MediaWiki can't see IPs past the reverse proxy

Post by koitsu » Thu Nov 10, 2016 6:28 pm

This is certainly the result of WhoaMan sticking things "behind nginx". The real/true Internet IP address of the client has to be passed in to the back end via the X-Real-IP HTTP header, and/or X-Forwarded-For.

The situation becomes complicated if PHP is being used on the back end (via FastCGI) or similar, especially under nginx. The software being run (PHP, etc.) has to parse/honour the new headers in software through CGI variables/params. For FastCGI, you need to use the fastcgi_param REMOTE_ADDR $http_x_real_ip; directive to get it to set $REMOTE_ADDR to the actual Internet client's IP address.

There is also the ngx_http_realip_module extension (for the back end) which comes in extremely handy. However, configuring this correctly so that end-users can't override things (thus spoofing the IP that shows up on the back end) is important. It's very easy to screw this up. Actually, I just realised there's a website that kind of talks about most of this (not all of it though, particularly the security aspect -- instead refer to the nginx module doc I linked for that): https://easyengine.io/tutorials/nginx/f ... s-real-ip/

If Apache is being used on the back end, then the admin gets to figure out equivalents there. I believe there's an Apache 2.x module called mod_rpaf that is the Apache equivalent of ngx_http_realip_module.

Again a reminder: when implementing this, please be sure to test the security aspect. Try doing things from an Internet host like curl -H "X-Real-IP: 69.69.69.69" http://wiki.nesdev.com/info.php (where info.php is a PHP script containing <?php phpinfo(); ?> and see what the "client IP" shows up as (if it shows up as 69.69.69.69, then that's bad/people can bypass it. Look into set_real_ip_from). Same goes for testing X-Forwarded-For. Check your HTTP access logs too -- make sure the right IP shows up there (if multiple servers on the front end are around, then you might consider extending the access logs to print both the IP of the front end server *and* the $http_x_real_ip address). Finally, the real_ip_recursive value (on or off) matters TREMENDOUSLY and is actually hard to get right (the documentation describes it in such a way that makes it difficult to understand) -- you may need to try both values, and try the security tests in both cases. You might be surprised what you see (X-Forwarded-For is a clusterfuck).

And now folks hopefully understand why we never used reverse proxying on Parodius -- it's a nightmare for web hosting. The negatives of it, IMO, outweigh the positives; it drives the users insane. (Please do not discuss scaling etc. in this thread -- that's a separate sysadmin subject that can be discussed privately some other time).

User avatar
Quietust
Posts: 1493
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: MediaWiki can't see IPs past the reverse proxy

Post by Quietust » Thu Nov 10, 2016 8:51 pm

If I recall correctly, MediaWiki itself has a special setting to recognize reverse proxies (generally of the Squid variety) by IP address and thus trust whatever's indicated in the X-Forwarded-For (or whatever) header as being the actual client's IP address.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Post Reply