Highlighted

Security in the cloud

Engaged ,
Mar 16, 2019

Copy link to clipboard

Copied

Hi,

We are on a cloud server with CF2018 Enterprise. We want to implement access restrictions to specific folders for certain user IP addresses and, of course, CGI variables such as REMOTE_ADDR are useless since we just get our cloud proxy address. CGI.REMOTE_ADDR has bit more promise as I am not sure it can be easily spoofed, but has anyone tackled such a problem and what technique did you use?

We also have CGI.X_FORWARDED_FOR and this does have the client's IP address, but again I am not sure as to its "spoofability". If we ensured that the X_FORWARDED_FOR was the IP we wanted and the REMOTE_ADDR was our proxy gateway address, would that be sufficient to allow/disallow users to certain folders to run .cfm scripts?

Thanks,

Mark

We just installed the Firefox X-Forwarded-For spoof plugin and even though we can only get to our site one way, we can still spoof the header. It just goes to show that you must never trust the X-Forwarded-For even if your site is only available through a load balancer or proxy. In this case Azure picks up the client header and inserts it as the first in the X-Forwarded-For list, which in turn could be picked up in your code. Not good. This seems to be how Azure works - it just prepends the IP address to the existing list of IPs 😞

Update: We are using IIS with managed ARR and our hosting people inserted a URL rewrite rule to ensure that all Azure gateway IP ranges (10.0.0.1 to 10.0.0.15 in our case) were replaced with the real client IP address. This ensures CGI.REMOTE_ADDR has the clients real (original) IP address. CGI.X_FORWARDED_FOR was was a bit unreliable in this respect.

TOPICS
Advanced techniques

Views

1.2K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Security in the cloud

Engaged ,
Mar 16, 2019

Copy link to clipboard

Copied

Hi,

We are on a cloud server with CF2018 Enterprise. We want to implement access restrictions to specific folders for certain user IP addresses and, of course, CGI variables such as REMOTE_ADDR are useless since we just get our cloud proxy address. CGI.REMOTE_ADDR has bit more promise as I am not sure it can be easily spoofed, but has anyone tackled such a problem and what technique did you use?

We also have CGI.X_FORWARDED_FOR and this does have the client's IP address, but again I am not sure as to its "spoofability". If we ensured that the X_FORWARDED_FOR was the IP we wanted and the REMOTE_ADDR was our proxy gateway address, would that be sufficient to allow/disallow users to certain folders to run .cfm scripts?

Thanks,

Mark

We just installed the Firefox X-Forwarded-For spoof plugin and even though we can only get to our site one way, we can still spoof the header. It just goes to show that you must never trust the X-Forwarded-For even if your site is only available through a load balancer or proxy. In this case Azure picks up the client header and inserts it as the first in the X-Forwarded-For list, which in turn could be picked up in your code. Not good. This seems to be how Azure works - it just prepends the IP address to the existing list of IPs 😞

Update: We are using IIS with managed ARR and our hosting people inserted a URL rewrite rule to ensure that all Azure gateway IP ranges (10.0.0.1 to 10.0.0.15 in our case) were replaced with the real client IP address. This ensures CGI.REMOTE_ADDR has the clients real (original) IP address. CGI.X_FORWARDED_FOR was was a bit unreliable in this respect.

TOPICS
Advanced techniques

Views

1.3K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Mar 16, 2019 0
Adobe Community Professional ,
Mar 17, 2019

Copy link to clipboard

Copied

If you have a load balancer (whether it's an actual load balancer or a load balancing service like Amazon offers) or a proxy, and if the only way public network users can reach your servers is via the load balancer or proxy, then you can certainly rely on X-Forwarded-For to identify the client's IP address, implement client access rules, etc. You will not be able to use CGI.REMOTE_ADDR or anything else, because those will have values provided by the load balancer or proxy.

Dave Watts, Eidolon LLC

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 17, 2019 1
Adobe Community Professional ,
Mar 17, 2019

Copy link to clipboard

Copied

Oh, and this isn't really "security in the cloud" question - it would be the same if you had an on-premise load balancer or proxy set up the same way.

Dave Watts, Eidolon LLC

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 17, 2019 0
Engaged ,
Mar 17, 2019

Copy link to clipboard

Copied

We are on Azure cloud, hence my phrasing, but yes, it's in essence a proxy. It was the spoofing that was the concern. So if we trust the load balancer and there is no other access to the server without the LB we should be ok.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 17, 2019 0
Engaged ,
Mar 18, 2019

Copy link to clipboard

Copied

We just installed the Firefox X-Forwarded-For spoof plugin and even though we can only get to our site one way, we can still spoof the header. It just goes to show that you must never trust the X-Forwarded-For even if your site is only available through a load balancer or proxy. In this case Azure picks up the client header and inserts it as the first in the X-Forwarded-For list, which in turn could be picked up in your code. Not good. This seems to be how Azure works - it just prepends the IP address to the existing list of IPs 😞

Update: We are using IIS with managed ARR and our hosting people inserted a URL rewrite rule to ensure that all Azure gateway IP ranges (10.0.0.1 to 10.0.0.15 in our case) were replaced with the real client IP address. This ensures CGI.REMOTE_ADDR has the clients real (original) IP address. CGI.X_FORWARDED_FOR was was a bit unreliable in this respect.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Mar 18, 2019 1
Adobe Community Professional ,
May 08, 2019

Copy link to clipboard

Copied

Just FYI: while you seem happy with your rewrite workaround, many reading along may not have that option.

For them, and you perhaps, consider instead the option of leveraging the fact that CF runs in Tomcat, which has an available "remoteipvalve", whose purpose is to solve this very problem of putting the ip found in a header like that into what populates the cgi.remote_addr in CF.

And it provides protections against the spoofing you're concerned with, in its available attributes that let you list additional characteristics to control trust in that ip header.

I did a blog post on the valve just last week, and I point to the tomcat docs for more on its additional attributes:

How to get CF to know a user's real IP address, when behind a proxy, load balancer, caching solution...

I will tweak it a bit at some point to add more clarity on this issue as well as another I was asked about privately since then.

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
May 08, 2019 2
Engaged ,
Jun 07, 2019

Copy link to clipboard

Copied

Hi Charlie, that's a really good little nugget, unfortunately it did not work for us on Azure. I added the valve, restarted CF and the header did not exist. For us, as mentioned, we are behind ARR and the only way for us to get the "real" IP was to set up a rule to forward it from the Azure gateway IP (subnets) to our CF VMs. I'd rather your way worked since we don't then have to rely on the ISP. Any ideas why your way does not work for us?

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jun 07, 2019 0
Adobe Community Professional ,
Jun 07, 2019

Copy link to clipboard

Copied

When you say "the header does not exist", which do you mean? This reads as if you thought the valve creates  header. It does not. It works BASED on whatever header you find IS passed in and want to be used to set the cgi.remote_addr.

As for the valve not working, perhaps the rewrite rule is hiding what is needed. Try having the host remove it, then try what I proposed just now in your other comment in the blog post just now.

Please clarify in both places once things are resolved.

/Charlie (server troubleshooter, carehart.org)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jun 07, 2019 0