Issues working behind proxy (getting blocked)

Hello @danidub,

Thank you for your feedback! I have already contacted the plugin’s developers and made sure to pass on the provided information. They will review it and consider if the X-Forwarded-For protocol should be honored.

You may check the changelog here to verify if the suggested enhancement has been included in a newer version of the plugin.

Best regards,
Daniela Ivanova

Hello @daniellaivanova,

Please do not mark this issue as resolved as is not and the plugin is failing to work in the case of a proxy being used (without any documentation on the case). This support ticket is not feedback, is a support request.

I’m sorry but marking a support ticket as resolved and tell users to “check the changelog” is not resolving issues. I understand your part but please understand us users.

We need a response from the development team. Please, when you have it, publish it here and we’ll review the resolved status.

Your plugin is failing to work properly behind a proxy and is blocking the proxy IP instead of using the IP on X-Forwarded-For header.

Thank you.

For example, the plugin Wordfence (and many others) use this feature to get the IP of the visitor, see screenshot attached please: https://prnt.sc/s_d3sPSw7NK3

The options shown are:

• Let Wordfence use the most secure method to get visitor IP addresses. Prevents spoofing and works with most sites. (Recommended)
• Use PHP’s built in REMOTE_ADDR and don’t use anything else. Very secure if this is compatible with your site.
• ?Use the X-Forwarded-For HTTP header. Only use if you have a front-end proxy or spoofing may result.
• ?Use the X-Real-IP HTTP header. Only use if you have a front-end proxy or spoofing may result.
• ?Use the Cloudflare “CF-Connecting-IP” HTTP header to get a visitor IP. Only use if you’re using Cloudflare.

On the last line is shown the IP detected for the selected method.

Thank you.

Hello @danidub

My name is Daniel Kanchev and I am the Product Development Director at SiteGround. I would like to provide more information about how we will approach this issue.

You are correct that the SiteGround Security plugin can obtain the information from the X-Forwarded-For HTTP header. We do not offer that option as you noticed. This is so because X-Forwarded-For allows for spoofing and as an attacker I can use it to deny access to a website from specific IP – presuming that the SG Security plugin inspects the X-Forwarded-For header. Generally speaking, web hosts do not trust the X-Forwarded-For precicely because I can write whatever I want in it and I can send requests to a site from a bunch of VMs or containers. You get where I am going with this ??

You are also correct that we can offer this as an additional option and move the responsibility to the site owners – let them decide if it is ok to use X-Forwarded-For as the source of truth. This is indeed an option but at this stage I am reluctant to adding more complexity to the interfaces that our users see and interact with. Not many people are aware what X-Forwarded-For is and it is a challenge to inform them about the issues they could face in case we add this interface change.

That is why at this stage we will not add this option to the SG Security admin interfaces. However, we have created an internal ticket on our end. We will be gathering all such complaints in the ticket and in case the demand is high we might think of implement such an option – with or without a GUI (a wp-config.php option is also doable).

Note: Big proxies such as CloudFlare are trusted by SiteGround servers and the REMOTE_ADDR which SiteGround Security plugin “sees” on SiteGround hosting servers when the request is coming from CloudFlare, for example, is the correct IP of the client.

Let me know in case you still want us to discuss the matter further.

Hello @danielkanchev,

I agree on your explanation and understand your thinking.

The problem is when users don’t use big proxies and use own infrastructure as our case.

At this point your plugin is getting—and blocking—our proxy real IP instead of taking X-Forwarded-For (visitors IP).

Is there any workaround or maybe any filters or actions to use for advanced users and not put those options in the plugin GUI? Maybe a constant on wp-config as you said.

In our case we need to tell the security plugin to always use—force—the X-Forwarded-For instead of the real IP (proxy) and block visitors not our proxy.

I understand that for the moment we need to replace your plugin and use another (we can’t keep getting blocked from our websites).

Thank you.

@danidub please check the latest version of the plugin. It should solve your issues with a global define “SGS_HEADER”.

• This reply was modified 2 years, 1 month ago by Daniel Kanchev.

Hello @danielkanchev,

I’m sorry but using the global does not seem to fix the issue using the plugin behind a proxy.

We are still getting blocked and all hits to our website are using our proxy IP instead the real user IP under X-Forwarded-For.

Thank you.

We have tested on our end and confirmed that the constant works correctly.
Please test the define again and if the issue still persists, check your proxy layer if the expected header is assigned. If the site is hosted on SiteGround server, you could open a new ticket on our end, and we will be glad to investigate the case further.

Best Regards,
Dimitar

We were hosted on SiteGround but without luck. Our proxy layer works ok and the constant was added weeks ago. Sill blocked the proxy IP… And was ignoring the IP under X-Forwarded-For.

For anyone experimenting this issue we are moving to WordFence as they detect the proxy IP without issues and shows user feedback on the options UI.

Thank you anyways.

In my case, the site server is behind a WAF then a Load Balancer:
WAF > Load Balancer > Site server

Both WAF and Load Balancer pass the user IP in the X-Forwarded-For header, but can pass multiple IPs contacted by comas.

For this case I modified the code to allow parse multiple coma separated IPs and take the first valid. I also added the possibility to set multiple headers using the SGS_HEADER constant.

Here is the patch file: https://gist.github.com/luistar15/8369610d3eeee1a38bdf0b85081292c5

Now I can add headers to check the user IP in the following formats:

• define( ‘SGS_HEADER’, ‘X-Forwarded-For’ );
• define( ‘SGS_HEADER’, ‘HTTP_X_FORWARDED_FOR’ );
• define( ‘SGS_HEADER’, ‘Another-Header’ );
• define( ‘SGS_HEADER’, ‘X-Forwarded-For, HTTP_ANOTHER_HEADER’ );

I could not find a repo to make a fork and pull request, I hope you consider this change or other alternative to parse multiple IPs.

Hello @luistar15,

Thank you for the feedback and the suggestions made. It was already passed on to the plugin’s Developer for further consideration.

Best Regards,
Gergana Petrova