IP detection behind a reverse proxy

[FallenHawk]

Hello,

I'm currently planning to convert my 2 year old forum (Invision 1.3.1) and SMF is the best I have found so far. I have installed version 1.1.2 to test it and get to know it bit more before converting my database.

My site is behind a hxxp:en.wikipedia.org/wiki/Reverse_Proxy [nonactive]. As far as the server knows, the client is only the proxy server and not the user who is actually visiting the site.

The proxy, however, sends the client's IP address as an HTTP header (I believe) and it can be retrieved in PHP (4.4.1) by using $_SERVER['HTTP_X_FORWARDED_FOR'].

SMF can detect the IP address fine, it seems. The correct address and hostname are listed in the user's profile. Unfortunately, the IP address that is shown next to each message the user has posted is always the proxy's and not the same address that is listed in the user's profile.

Is this intended behavior, a configuration issue or could this be a bug?


Thanks.

[Daniel15]

Hello, and welcome to the forums!

Is this intended behavior, a configuration issue or could this be a bug?

This is actually the intended behavior. Previously, it was possible to spoof the IP address, by sending a fake X_FORWARDED_FOR header (see National Vulnerability Database, CVE-2006-7013). In response to this, SMF stores both the proxy IP, and the X_Forwarded_For header IP.

To get the old behaviour back, open Themes/[theme name, or default if you're using the default]/Display.template.php, and find:

Code Select Expand


$message['member']['ip']

Replace all instances (it occurs 4 times) with:

Code Select Expand


$message['member']['ip2']


[FallenHawk]

Thanks for the reply.

In response to this, SMF stores both the proxy IP, and the X_Forwarded_For header IP.

I did search the forums for X_Forwarded_For and found some hits about a vulnerability. I thought it could have something to do with it, since the correct IP must be detected at some point to be shown in the user's profile.

I believe that, since this is sent by the proxy, it'll always be the correct address in my case. The user cannot access the site without going through the proxy first, so I think that (for me) it would be safe to always log just the IP in the header.

I'll try to make a test to confirm that the proxy does not use the X_Forwarded_For header to determine the IP address of the client.

To get the old behaviour back, open Themes/[theme name, or default if you're using the default]/Display.template.php, and find:

I did the modification as you said and replaced all four instances. It did change the IP address that is displayed, but it's still not the right one. The reverse proxy is a group of 12 machines and every time the user needs a new DNS lookup, a new IP address will be used.

The new IP address that is displayed is just another proxy IP address. Seems to be the last IP address instead of the logged IP address on the message, since it's showing the same IP address for all my test posts.

Is there something else I can try?

[FallenHawk]

I added a code in index.php to rewrite the address in REMOTE_ADDR with the IP provided by the header.

Code Select Expand

$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
unset($_SERVER['HTTP_X_FORWARDED_FOR']);

This is probably not very clean, but it works. I do not know if the second line is needed, but I added it just to be safe.

In my case, I can do nothing other than trust that the proxy server will forward the correct address. If it sends an incorrect address, that's going to be all I will get, because I have no access to the first request. So it's either the forwarded address or nothing.

[Daniel15]

Sorry about not replying sooner, I didn't see your reply 

I added a code in index.php to rewrite the address in REMOTE_ADDR with the IP provided by the header.

This will not work properly if the user is using a proxy. If the end user is using a proxy, then two IP addresses will be in the X_FORWARDED_FOR header (I've got an internal proxy, and my ISP's transparent proxy, so for me, it would show three addresses).

When I have more free time, I'll try to come up with a better solution

[bill_mcgonigle]

I know this is an old topic, but Google leads here and it has >900 views.

I just wanted to add that the rpaf apache module solves this problem for me without having to modify SMF.  It adjusts REMOTE_HOST for people who have a trusted reverse proxy.

  hxxp:stderr.net/apache/rpaf/ [nonactive]

If you're using Apache 2, be careful to use the instructions as a guide but adjust for the 2.0 filenames.

[wonslung]

I added a code in index.php to rewrite the address in REMOTE_ADDR with the IP provided by the header.

Code Select Expand

$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
unset($_SERVER['HTTP_X_FORWARDED_FOR']);

This is probably not very clean, but it works. I do not know if the second line is needed, but I added it just to be safe.

In my case, I can do nothing other than trust that the proxy server will forward the correct address. If it sends an incorrect address, that's going to be all I will get, because I have no access to the first request. So it's either the forwarded address or nothing.

I know this is an old topic, but i wanted to say thanks for this.  This worked perfectly for me.


I tried the other hack as well, which did nothing.

[Paracelsus]

After installing nginx as a reverse proxy (nginxcp more exactly since I have cPanel + Apache), I've noticed the exact same problem, ie, the same IP address (the website's IP) on every post no matter which user posted there. If you google this you'll see the reasoning is to make SMF read the x-forwarded-for header to find the original source IP.

So I tried every hack on this topic without success until I tried this on QueryString.php (it's on Sources folder):

Found:

Code Select Expand

// Store the REMOTE_ADDR for later - even though we HOPE to never use it...
$_SERVER['BAN_CHECK_IP'] = isset($_SERVER['REMOTE_ADDR']) && preg_match('~^((([1]?\d)?\d|2[0-4]\d|25[0-5])\.){3}(([1]?\d)?\d|2[0-4]\d|25[0-5])$~', $_SERVER['REMOTE_ADDR']) === 1 ? $_SERVER['REMOTE_ADDR'] : 'unknown';

Replaced with:

Code Select Expand

// Store the REMOTE_ADDR for later - even though we HOPE to never use it...
$_SERVER['BAN_CHECK_IP'] = isset($_SERVER['HTTP_X_FORWARDED_FOR']) && preg_match('~^((([1]?\d)?\d|2[0-4]\d|25[0-5])\.){3}(([1]?\d)?\d|2[0-4]\d|25[0-5])$~', $_SERVER['HTTP_X_FORWARDED_FOR']) === 1 ? $_SERVER['HTTP_X_FORWARDED_FOR'] : 'unknown';


I don't know if someone has a better or easier one, but this worked for me.

[chico200987]

Hi,

For me :

Code Select Expand

$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];

At the top of index.php works fine

[Joshua Dickerson]

I am going to add support in 2.1 for detecting the real IP when you're behind a proxy/load balancer.

[user1234]

My new DDoS host (been with them a couple months) just "upgraded" their PHP and I noticed our forum "guests" went from the usual 15-20, down to 3-4 and all with the same first few character prefixes in the IP as in the issue expressed previously in this thread.
186.190.211.26
186.190.211.86
186.190.211.26
186.190.211.90
186.190.211.82
I mentioned it to them and they sent me the following with a link to this thread.
Is there a definitive "best" solution to this now, or most recommended fix from the prior posts?

My new host (DDoS Hosting Solutions) explained:

"The IP addresses that you are seeing belong to the filters that sit on front of the server that you are hosted on.
Please see the following KB article: https://clients.ddoshostingsolutions.com/knowledgebase.php?action=displayarticle&id=8
I also think this thread over at simplemachines.org will help you as well: http://www.simplemachines.org/community/index.php?P=c297101ef96a3981333e1dcc79d637bb&topic=151317.0 "

(I'm running 2.0.2, and when I go to "admin" and "Check all files against current versions" everything looks current except:
Default Templates    2.0    2.0.2 )

[talkleft]

I am having the same problem. I know Joshua said he would do a fix for the next version, but my question also is what is the best or most recommended fix or solution for this now. I'm also using 2.0.2. Everyone's IP address comes up as the address for the local host, and we have a reverse proxy. It's important because I can't ban anyone by IP address or track them when everyone has the same IP address.

Thanks, any guidance will be very appreciated.

[Joshua Dickerson]

I think I added it but I don't know if it made it in as we did some transferring when we moved from SVN to Github.

[talkleft]

Joshua, thanks for the reply. Is there a place I can go to access what you added? Or do you have a recommendation to fix it manually?

[Joshua Dickerson]

As a quick hack, I think what the other posters have posted would work. However, I don't have a link or detailed explanation, sorry.

[user1234]

Joshua, thanks for the reply. Is there a place I can go to access what you added? Or do you have a recommendation to fix it manually?

It don't know quite how, but I just stumbled across your post. If you haven't fixed the problem yet, I copy and pasted the following directions from my thread in the charter members section.
The following changes are to be made in your "Load.php" directory which is in your "sources" directory:

That trick should affect only the link you see close to "report to moderator" (I think).

That would be a bit more...extreme, but you can try to change in Load.php:

Code Select Expand

'ip' => $_SERVER['REMOTE_ADDR'],
'ip2' => $_SERVER['BAN_CHECK_IP'],

into

Code Select Expand

'ip' => $_SERVER['BAN_CHECK_IP'],
'ip2' => $_SERVER['BAN_CHECK_IP'],

But honestly I don't know if this could affect something else...

It worked for me. Haven't noticed any ill effects.

[Arantor]

It will only work for you because your reverse proxy uses X-Forwarded-For, other reverse proxies may or may not work.

[JazzyNL]

Realize this is an old topic, but can someone please confirm that support for this was added to 2.1? Recently upgraded to 2.1.3 from an old version and now see this issue, am not completely sure how this was addressed in the old version we ran.

[JazzyNL]

Realize this is an old topic, but can someone please confirm that support for this was added to 2.1? Recently upgraded to 2.1.3 from an old version and now see this issue, am not completely sure how this was addressed in the old version we ran.

And as these things go I found the answer to my question immediately after posting. The configuration did make it to 2.1 and a Reverse Proxy IP Header can be found in the Security section of the Admin area.

Hope this is helpful for others.