Cidram: Showing Server IP address when loading loader.php
CIDRAM is not getting my real IP address when i am trying to log into frontend of CIDRAM. As i am using cloud hosting so, every time i am trying to visit frontend "I get Access Denied page" to bypass that i enabled reCaptcha.
As a solution when i changed default value of general->ipaddr from
REMOTE_ADDR to HTTP_X_REAL_IP
after this tweak everything working good.
my question is should i do this? will it defeat the purpose of CIDRAM?
Waiting for your suggestion's before changing this thing.
Right now I am using REMOTE_ADDR and whitelisted my server IP.
soumsps
All 12 comments
The general->ipaddr field is where you tell CIDRAM where to look for the originating IP for the request.
In a normal header that would be REMOTE_ADDR, but if your installation is behind a proxy of some kind you must change this field to the header field that carries the external IP information.
That you mention HTTP_X_REAL_IP gives the impression that you are indeed behind some kind of NAT, and thus you might not only be in the situation that you should do it, but that you must do it to get CIDRAM working as intended.
May I ask which cloud service you are using?
ghost
on 25 Mar 2018
The HTTP_ headers are not recommended as they can be changed by clients.
DanielRuf
on 25 Mar 2018
I am using Vultr Cloud Server. @macmathan
My website setup is VestaCP (Apache + Nginx) I think this is only reason i am seeing my server IP. On top of this config I have Cloudflare...
2 month earlier i got same type of error where all wordpress plugin were reporting my own server IP. I solved that error by overriding the default behviour of $_SERVER variable with the HTTP_X_FORWARDED_FOR in wp-config.php file.
CIDRAM is able to detect correct IP Addressess but it is only failing when i am trying to load loader.php.
soumsps
on 25 Mar 2018
Cloudflare uses another header.
CF-Connecting-IP
DanielRuf
on 25 Mar 2018
HTTP_X_FORWARDED_FOR
Also insecure and is just used by some proxies and redirects.
DanielRuf
on 25 Mar 2018
When i removed cloudflare then also same thing is happening. I guess i am getting my own server IP because of Nginx proxy server running on top of Apache.
Is there any alternative to HTTP_X_FORWARDED_FOR which can fetch me originating IP.
soumsps
on 25 Mar 2018
In general, something worth reading, for anyone in this type of situation: __Recommended values for "ipaddr".__
Generally, Cloudflare uses either CF-Connecting-IP or HTTP_CF_CONNECTING_IP, but if you're also behind an Nginx reverse-proxy, it might be worth checking over the configuration for Nginx and experimenting a little, to see what works best. The headers will sometimes be different when using Nginx as a reverse-proxy, and depends on exactly how it's been configured, but also, using multiple reverse-proxy services together (e.g., Nginx +Cloudflare), I'm not entirely sure what the end effect would be in terms of the correct header to use to be able to get a user's originating IP address.
Maikuolan
on 25 Mar 2018
HTTP_X_FORWARDED_FOR
Also insecure and is just used by some proxies and redirects.
Like Daniel mentioned, these headers aren't secure. They're required by some proxy services in order to be able to the originating IP address of a user/client, and in those cases, you'll need to use them (these reverse-proxy services will sometimes forward the originating IP address via these headers), but they shouldn't be used unless needed, due to that they can be easily faked/generated by the user/client to whatever they want to set it as.
Maikuolan
on 25 Mar 2018
Worth noting too, that you can set protect_frontend in your configuration to false, if you need to gain access to the front-end and you're being blocked as a result of the default included signature files. Doing this won't resolve the root problem of whether CIDRAM is able to see the correct originating user/client IP address though.
Maikuolan
on 25 Mar 2018
If you use more than one reverse-proxy (i.e. cloudflare + nginx) you will probably want the latter one to forward the first one's header for identifying the originating IP.
Assuming a pretty standard configuration in use, the last one would only identify the first proxy and so you could end up shielding yourself from the real origin this way.
ghost
on 25 Mar 2018
@Maikuolan CIDRAM I able to see the correct originating user/client IP in my case. I confirmed this with 7 VPN server IP. Firstly i noted down there IP address via whatismyip.com. Then visiting my site via that vpn, Access denied page reported the same IP. [using REMOTE_ADDR]
protect_frontend I was not knowing about this. thank you :)
So finally, for now, I will happily continue with REMOTE_ADDR and whitelisting my Server IP.
soumsps
on 25 Mar 2018
Marking as "Resolved" and closing. Feel free to reopen if problems persist though.
Maikuolan
on 26 Mar 2018
Related issues
Maikuolan
路
5Comments
Dibbyo456
路
3Comments
eurobank
路
7Comments
100percentlunarboy
路
6Comments
eurobank
路
3Comments
Most helpful comment
If you use more than one reverse-proxy (i.e. cloudflare + nginx) you will probably want the latter one to forward the first one's header for identifying the originating IP.
Assuming a pretty standard configuration in use, the last one would only identify the first proxy and so you could end up shielding yourself from the real origin this way.