News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

Reverse Proxy IP Header selection not working

Started by JazzyNL, February 09, 2023, 07:39:00 AM

Previous topic - Next topic

JazzyNL

Hi,

We recently migrated from 2.0.15 to 2.1.3, we lost some of the previous administrators so decided to leave most of the customization behind and start with a clean slate. One issue that I have not been able to resolve is that the IP address of the reverse proxy is logged instead of the actual client IP.

As far as I know the reverse proxy adds a X-Forwarded-for header, so I went to Server Settings, Maintenance and under Reverse Proxy IP Header, I selected X-Forwarded-For. In the Reverse Proxy Servers IPs box I added the IP address that we currently see, a 192.168.x.x IP address.

This does not work. All activity is still logged with the IP address of the reverse proxy.

Next I added the following code in index.php:
if(isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https'){
    $_SERVER['HTTPS']='on';
    $_SERVER['REQUEST_SCHEME']='https';
    $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
}

This seemed to work, the actual client IP address now appears with each post. Unfortunately this introduced an other issue, we saw frequent Critical errors:

Wrong value type sent to the database. IPv4 or IPv6 expected.(ip)
Function: writeLog

This happens for functions writelog and is_not_banned. Unfortunately I lack php knowledge and do not know what to change to the code to resolve this. But ideally I would want to use the board's native feature, which doesn't seem to work either.

Board url: https://www.htforum.nl/yabbse/index.php

JazzyNL

Forgot to add the information from php.info:

Showing the reverse proxy address:
$_SERVER['REMOTE_ADDR']

Showing the actual client IP address:
$_SERVER['HTTP_X_FORWARDED_FOR']
$_SERVER['HTTP_CF_CONNECTING_IP']
$_SERVER['HTTP_X_REAL_IP']
$_SERVER['HTTP_CLIENT_IP']

Maybe relevant, the reverse proxy seems to perform SSL ofloading:
$_SERVER['SERVER_PORT'] 80
$_SERVER['HTTP_X_FORWARDED_PROTO'] https

JazzyNL

Gentle kick. Someone know why this feature doesn't work on our board?

Arantor


JazzyNL


Arantor

Try it without putting the revere proxy server IP in the box.

JazzyNL

Quote from: Arantor on February 15, 2023, 07:09:21 AMTry it without putting the revere proxy server IP in the box.
I just tried. Makes no difference, unfortunately.

The weird thing is, php.info shows the correct values to it's not a server issue. Is this feature depending on anyting else that could be missing on my server?

Arantor

PHP info shows the correct values for which fields, exactly?

JazzyNL

Quote from: Arantor on February 15, 2023, 05:18:11 PMPHP info shows the correct values for which fields, exactly?
The correct values for HTTP_X_FORWARDED_FOR, HTTP_CF_CONNECTING_IP, HTTP_X_REAL_IP and HTTP_CLIENT_IP.

For me this confirms that the reverse proxy provide the rigth headers, it's the board's feature that fails to use them and display on of those instead of the default REMOTE_ADDR address.

Arantor

Well, SMF internally has always taken two - historically both REMOTE_ADDR and HTTP_X_FORWARDED_FOR so that you couldn't just ban evade with a proxy.

What I don't get is why I don't replicate the behaviour you have - I'm behind CloudFlare too (the CF_CONNECTING_IP header is a giveaway) and... it just works as expected for me, though I don't tend to bother putting in the revere proxy IP.

But I'm wondering if you have a second proxy on there or similar and SMF is getting hung up on an intermediate?

JazzyNL

Quote from: Arantor on February 16, 2023, 10:59:03 AMBut I'm wondering if you have a second proxy on there or similar and SMF is getting hung up on an intermediate?
There's no second proxy. And please help me understand, if php.info shows the right values for all four IP address parameters, where would SMF obtain it's information and potentially getting hung up?

Also, is there another way you could recommend me to get support for this issue? I understand that SMF is supported through the community, but at this point this seems to be a SMF bug or issue and you're the only person who even responded to this thread. I'm grateful, don't get me wrong, but this is an impacting issue for our board and needs to be resolved.

Arantor

So let's recap. When it hits phpinfo, REMOTE_ADDR should contain the CloudFlare IP, and the others should contain the real IP. Seeing your post on this made me go look a bit deeper at what the code is actually doing.

What's weird is that my host apparently fixes this - which is why I'd never noticed a problem with it before, because php_info on my host serves up HTTP_CF_CONNECTING_IP and HTTP_X_FORWARDED_FOR as my real IP - but also REMOTE_ADDR.

I've never looked at this part of the code before, I'd assumed it would work as expected but actually... it can't.

It sets up $_SERVER['BAN_CHECK_IP'] as a secondary IP address (i.e. one step up the chain to find proxy ban evaders), but it never actually resets $_SERVER['REMOTE_ADDR'].

I'd suggest changing the lines in QueryString.php:
$_SERVER['BAN_CHECK_IP'] = trim($ip);
$_SERVER['BAN_CHECK_IP'] = $_SERVER[$proxyIPheader];
to both reference $_SERVER['REMOTE_ADDR'].

I'm also not 100% sure of the IPv4-over-6 code in there, it feels like it runs at the wrong point in the cycle and potentially does nothing with the output but that's a different question entirely.

This has also been noticed in the past, in https://github.com/SimpleMachines/SMF/pull/7368 but there's a misunderstanding on all sides that prevented it from being merged (and wouldn't work quite the way I'm suggesting)


Edit: filed as https://github.com/SimpleMachines/SMF/issues/7684

Aleksi "Lex" Kilpinen

So, I replicated all of this in my test environment. I could not get SMF to fix the IP, I was however fairly easily able to get Apache to fix the IP before it ever gets to SMF. This is probably something along the lines of what Arantor's host is doing. https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

Arantor

It's still wrong, though: if you're telling it to use an external proxy source to get the IP, it should use that IP!

Aleksi "Lex" Kilpinen

#14
Yes, I agree! Just noting that there is a possible workaround. As well as an explanation to why this might have gone unnoticed.
Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

JazzyNL

Thanks both. And apologies for abandoning the thread for a while, there were other priorities in life. Glad to see confirmation that I'm not the only person where SMF is not able to display any IP other than $_SERVER['REMOTE_ADDR'].

@Arantor: Just to clarify, this primarily has nothing to do with banning or working around a ban. It's much more basic than that, SMF is displaying the wrong IP-address at the left side of each user's post. Since the wrong IP address is logged in the DB too, there's a myriad of additional challenges but that's more the result of the original problem.

And like I said before, from the php.info we know that the alternative IP address values are in the requests. It's just the SMF feature to use those that seems to be broken.

Arantor

Quote from: JazzyNL on March 11, 2023, 01:19:32 PMthis primarily has nothing to do with banning or working around a ban

I know that's not your primary consideration, but I'm deliberately pointing it out because it's directly relevant to SMF's ban system.

SMF tracks two IP addresses for users - the first one is the primary and this gets funnelled into posts etc. but the *second* is used as a secondary for checking that individuals aren't using proxies to evade bans.

This is directly relevant because while the primary is REMOTE_ADDR, the secondary is hardcoded to look for the presence and contents of X-Forwarded-For. Which in your case is *correct* while REMOTE_ADDR is not. So changing this logic has consequences for the ban system too for other users.

JazzyNL

Quote from: Arantor on March 11, 2023, 01:56:16 PMThis is directly relevant because while the primary is REMOTE_ADDR, the secondary is hardcoded to look for the presence and contents of X-Forwarded-For. Which in your case is *correct* while REMOTE_ADDR is not. So changing this logic has consequences for the ban system too for other users.
Makes perfect sense. It would be helpful to understand how the new logic in 2.1.3 is supposed to work, with the new dropdown list that was added to the admin options (Server Settings, Maintenance, Reverse Proxy IP Header). I'm not a dev unfortunately so I guess we're depending on the people who developed this feature.

Is there anywhere I should raise this to get some traction? Sorry for asking, have no idea how bugs are being tracked for this project.

Aleksi "Lex" Kilpinen

Slava
Ukraini!
"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum. Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

How you can help SMF

JazzyNL

I just came back to edit my post, had found it too. :)

MarckMabimods

Quote from: Aleksi on March 11, 2023, 11:52:17 AMSo, I replicated all of this in my test environment. I could not get SMF to fix the IP, I was however fairly easily able to get Apache to fix the IP before it ever gets to SMF. This is probably something along the lines of what Arantor's host is doing. hxxp:httpd.apache.org/docs/2.4/mod/mod_remoteip.html [nonactive]

I was able to do a similar workaround with Nginx to get this problem fixed. In my case I have both Cloudlare, and another server on-prem doing a reverse proxy to the SMF server.

Nginx config setting:

set_real_ip_from 127.0.0.1/32;
real_ip_header CF-Connecting-IP;



JazzyNL

So it has been one year since this was reported. While I appreciate all developing work on SMF and understand work is prioritized, could someone please give me an indication if this is going to be addressed in let's say the next year?

Kindred

Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."


Arantor

Well, it's tagged for 2.1.5 and has been since last summer. In theory it could even have been solved in time for 2.1.4 but apparently it's too hard to solve.

I'd have thought the usual approach of 'let's just make everything configurable by the user and make it their choice' would have been wonderful here.

JazzyNL

If it worked, it would've been great. :) Funny thing is that the default behavior in 2.0.x worked fine, the configuration with the drop-down list in 2.1.x broke things. Besides the fact that we can't ban on IP anymore, our users frequently hit rate limits since SMF sees all traffic coming from the same IP address. When you hit that error while trying to post, and click Back to return to the previous page, the text that you had typed is now lost.

Our users are frustrated and as the admin I get it completely. Anyway, appreciate the effort in getting this resolved.

szinski

I got my 2.1 forum working with Cloudflare (displaying client's real IP address) following these instructions (I'm using cPanel)

https://support.cpanel.net/hc/en-us/articles/360051107513-Restoring-visitors-IP-with-mod-remoteip

Advertisement: