Zonelockdown, AWS SGs, flexible SSL - remote_addr question

Hi there, I’ve googled and searched here but haven’t found this specific issue.

I’m trying to :

  • whitelist an EC2 instance to only listen to requests coming from cloudflare
  • set up zone lockdown on cloudflare to whitelist specific IP addresses to the url of that EC2 instance.

EC2 instance has an app running on port 80
DNS entry for that url/ec2 instance IP is orange cloud
SSL is set to flexible

In order to hit the app, I have to have:

  • my IP address in the zone lockdown rule; AND
  • my IP address in the AWS security group the ec2 instance is in (allow port 80 from my ip); AND
  • cloudflare IPs in the security group allow

My goal:

  • cloudflare IPs in security group
  • my IP in cloudflare zone lockdown rule - only.

I do see a hit to 80, a 301, then a hit to 443 (in the browser)
I’ve trial/errored this a bunch, but hoping someone point me in the right directly. I have a feeling it’s the flexible ssl 80/443 setup that’s causing the security group to see both my ip and the cloudflare ip, but I can’t for the life of me understand how two IP addresses are required in the SG along with presence in the zone lockdown. would love to understand the order of operations

I can’t seem to edit, forgot the remote_addr part.
the app on 80 is showing remote_addr as my IP in the logs - not the CF IP.
which would explain why my ip is needed in the SG, but then i can’t figure out why things break without the CF IPs in the SG.

Thats a question for an Amazon forum I am afraid.

I am not sure I understand. Lockdown restricts a list of configurable URLs to a list of addresses. This is however related to the client side, not the origin side (which Amazon would be in your case).

Major mistake I am afraid. Switch to Full strict and make sure you have a valid certificate on your Amazon instance.

I am not sure I understand. Lockdown restricts a list of configurable URLs to a list of addresses. This is however related to the client side, not the origin side (which Amazon would be in your case).

I’m trying to restrict something like admin.website.com to a specific set of IPs - that’s what zone lockdown does right?

Major mistake I am afraid. Switch to Full strict and make sure you have a valid certificate on your Amazon instance.

This isn’t particularly helpful or insightful - why is it a mistake? Does it have an impact, aside from encryption, on how cloudflare connects to the server? does it make more requests? different requests?

That is correct -> https://support.cloudflare.com/hc/en-us/articles/115001595131-Understanding-Cloudflare-Zone-Lockdown

It is a security nightmare and leaves your site as insecure as plain HTTP is.

Nightmare is a bit of a stretch, particularly if we’ve made the whitelisting to cloudflare work. this isn’t a production system, we’re trying to lock down access to home worker IPs for some dev systems. I think the flexible might be a distraction from the actual issue.

Coming out the other side of an http request, on a proxied dns entry - should the server be seeing CF IP or requester IP?

Nightmare is not a stretch. You essentially remain on HTTP, regardless of how much you whitelist or not. All the data you transmit still crosses the Internet in plain text.

Thats not a distraction from an issue, but simply a security concern. Though I am not sure what the actual issue is. Lockdown is pretty straightforward and documented at the link I provided.

As for which IP the origin gets, that will be a Cloudflare address of course and you will have to rewrite that if you want to get the actual client address.

Again, install a proper certificate on your server and switch to “Full strict”, that is the only secure mode and only takes a couple of minutes.

Thank you for your concern around security. it’s a public website serving traffic publicly, so unless the flexible mode impacts number of connections or routing from client, let’s leave it for now.

the app log on my server is showing hits from the IP of the client, not cloudflare. remote_addr is showing the client IP not cloudflare. so “that will be a cloudflare address of course” takes us right back up to the start of the thread where my rules should be sensible an should be cloudflare only, but for some reason on a proxied dns entry the client IP is hitting the server rather than CF IP.

so I ask again (and hope others might see this and chime in) - does the zone rule allowing someone through bypass the proxy? it seems like, from what i’m seeing on the server - that cloudflare makes a call to see if the endpoint is alive, then the client hits directly - the zone rules state that it doesn’t exempt from waf, so that doesn’t make sense to me.

hopefully that clears up the question and enables a more constructive / helpful response

I’m not at all sure what happened, but same settings as yesterday and now things are working exactly as expected…
I’m guessing there was some magic combination of rule propagation, caching and bad luck.

Of course, if you bypass the proxy all security settings are out the window. You need to make sure connections only go via Cloudflare.

As long as requests go via Cloudflare the Lockdown settings will apply.

This topic was automatically closed after 30 days. New replies are no longer allowed.