Hi all just configured and tested Cloudflare Access with Microsoft Azure AD as authentication provider. Setup is easy and works perfectly well.
I do have discovered a potential flow of the product. So if you setup Cloudflare access and have an A record (e.g ABC.domain.tld) proxied through Cloudflare all is good, Access page shown and authentication requested. IF you create a CNAME (DCE.domain.tld) point to your ABC.domain.tld record, Cloudflare Access is actually getting bypassed and original server is exposed
Could be a misconfiguration concept for anyone but i would rather say its a flaw, as this could expose someone without knowing about it
There are many ways to shoot yourself in the foot when configuring a server, and this is just one of them. Exposing your origin IP address and not firewalling off non-Cloudflare connections is another way.
well the firewall is actually up. both the A record and CNAME are protected by Cloudflare and resolve to 104.x.x.x IP. Hence i believe it can be classified as flow since:
a) if you access the A record, Cloudflare Access prompts you for Authentication provider before landing you on the protected app’s page.
b) if you access the CNAME which point to the A record, Cloudflare Access gets bypassed completely exposing you the app’s page without the need to authenticate against your authentication provider.
Our local firewall allows connections only from Cloudflare IP address spaces, therefore this means that traffic is actually routed through CF proxy but Access is getting bypassed
I didn’t mean to imply that the firewall had anything to do with Access. It’s just another way people have security holes in their systems. Adding a CNAME that points to a part of your site that uses Hostnames to restrict access is another.
Ok so lets make it more interesting :))
I have created a CNAME on a different Cloudflare account (B) pointing to my A record of my primary Cloudflare account (A) and when accessing the CNAME, i’m again landing on my app’s page bypassing CF Access completely
I’ll try with a completely different NS provider but i started worrying the result will be the same.
So this either means:
- this should be filtered by Cloudflare access
- that the web server must always listen to a specific hostname
- if the web server is not configurable there must be something else implemented as protection.
Your list is pretty much accurate - the web server must be set up to correctly handle non-set-up hostnames.
One issue is that I can’t replicate your results when CNAME’ing across accounts - if I try to CNAME to a different CF account [with the proxy ], it’ll show an error like so:
This is even with the principle account of that domain being a “administrator” of the other account it’s CNAMEing to.
I’ve also written about the hostname thing
Following proper procedure like so is important if you run anything more than a simple wordpress site trying to protect wp-admin.
Yes you are right - i used the word “account” wrongly. It is actually the same CF account but 2x different domains.
The resume would be that the webserver must only listen to explicitly to the hostname that it should (i assume we are referring to rhe SNI?)
yes, having your website config set to only respond to certain SNI hostnames (doable by having a “default” vhost in nginx/apache) + blacklisting all but Cloudflare IPs at the firewall should provide the security needed for making sure Access can’t be bypassed.
This is also an option -