Cloudflare Zero-Trust – A good alternative to provide ZTNA?

As cyber threats continue to evolve, traditional security measures are no longer sufficient to protect networks and data. Zero Trust security has emerged as a powerful approach to security that ensures secure access to resources in a world of increasing complexity and data breaches. Cloudflare, a global cloud platform provider which now in the latest polls manages about close to 20% all of internet traffic according to w3techs

Some time ago, Cloudflare introduced a revamped version of their Cloudflare Access solution, now named Cloudflare Zero Trust. This security solution empowers organizations to adopt Zero Trust principles in network access. This blog post will delve into the concept of Zero Trust security and how Cloudflare Zero Trust can enhance an organization’s security posture in the face of ever-changing threats.

What is the challenge of ensuring secure access? Many organizations have some sort of secure network access, such as VPN/VDI or a proxy service to access internal applications and services. However, the specific needs of users vary depending on their role within the organization – it could be developers, general users, or administrators.

In the past, a lot of external access was managed using VPN or VDI, and to this day, these methods are still commonly used. To ensure external access is secure, an MFA service is often implemented to prevent malicious attacks. However, we have seen a lot of cases where attacks still occur in these scenarioes, so let me give a few examples.

  • The VPN Service that is public facing has a known vulnerability (This has happened on many occasions with F5/Fortinet/Citrix to name a few)
  • New attack methods that are used to bypass MFA services such as MFA Fatigue attacks
  • When connecting to the VPN service there is in most cases no context check of the user’s identity or the health of the machine.

I have personally witnessed ransomware attacks that occurred due to a compromised device that was authenticated to a VPN service. In such cases, the machine had previously authenticated to the service before getting compromised, which allowed the attacker to use the endpoint to jump to other parts of the infrastructure.

Amidst the COVID pandemic, we have become proficient at conducting health checks, and a ZTNA service operates in a similar context. Where it makes sure that we do health checks, and we always verify before granting access.

Another way of looking at it is that a ZTNA service will threats all connections as hostile and that you need to fulfill the conditions that have been defined you are given access to the service or data. In addition, the service will verify that connection for each request, meaning that if you need to access another service it will go through the same process again. Then if something changes, which will affect those conditions you might lose access to the service. This can be for instance changing to another network, or something impacted the health of your device.

In the context of Cloudflare Zero-Trust, the service offers support for various identity providers and EDR/MDM services, allowing it to gather information on device and identity health. For instance, it can work with Endpoint Manager and Azure Active Directory or Carbon Black and GitHub identity to name a few. To utilize the full capabilities from an endpoint, you must have the Cloudflare Warp client installed, which connects to the nearest Cloudflare PoP. Here, policies are applied, and traffic is routed. If you need to access internal services, they are proxied to an internal server running Cloudflared. The server running Cloudflared does not require a public IP address since it communicates with the Cloudflare service via a reverse connection.

NOTE: You can setup a free 50 users Cloudflare zero-trust account and if you have a public domain that you can use it makes the set up a lot easier.

Now to use Zero-Trust the best approach is if you have your own public cloud, that way it is easy to setup new services publicly available with its own DNS record which I am going to use in this example.

First of we need to set up a tunnel (aka the Cloudflared service) which you get clear instructions how to configure from within the portal.

Once the tunnel is active, which you can see the status of if you go back into tunnels. We must do some further configuration before we set up the proxy connection. First of we need to add an authentication mechanism, such as Azure AD to allow our end-users to authenticate. This is done under Settings | Authentication | Login Methods | Add new, as I’ve done here.

Now let us expose an internal web application trough the proxy component. To set up external connection you need three things.

Then you can go back to Access | Tunnels | Select the active tunnel and click configure. From there click on Public hostnames and click add a public hostname.
So let us assume that I have an internal web server that I want to access, then I just add this service type and internal IP and a public hostname that I want to provide it.

Next, we must define an access group which will be used afterwards when we publish the application, for now we are just going to add everyone to the group.

Finally, we add the application, where we define the same application domain with the A records that we created earlier as part of the tunnel set up and define that all the different identity providers can be used.

Finally, we define a policy, where we group together the access group and other conditions that we want to include such as location or it can be device posture. Once we are done with the set up and add the application, the service will now be available externally using the FQDN. So, if we go to the website, we will see this logon page.

Since this is a public facing website, we will be able to access it from wherever the user is located by default. We also have the option to provide access to the internal network as well. If we go back to Access | Tunnels and click configure on the existing tunnel that we have configured and then go into private network and add the internal subnet that we want to have added (in my case, it is 10.0.0.0/8) then go back to applications then click add and choose private network. In my case I want to add an internal SMB file server on this IP 10.0.0.6. Then click next and add policies, this is where we define the allow/block firewall policies to allow access to the application. By default, you will get a allow policy that allows access to that specific application. You can also reduce it further by adding policies to allow traffic only on port 445.

The only thing you need to be aware of as well, is how the client handles split tunneling. By default, it will exclude certain IP addresses so you might need to configure that, so it includes the traffic that you want for your private IP ranges. This is configured under Settings | Warp Client | Device Settings | Profile Settings | Split tunnels | Manage. Here you need to make sure that you IP addresses that you want to include is either not part of the exclude list or part of the included list.

The last thing we need is the Warp client which can be downloaded from here –> 1.1.1.1 — The free app that makes your Internet faster. (cloudflarewarp.com) and install it. Once it is installed and started you will get a new icon in the taskbar, right click, and click preferences and go into Account | Login with Cloudflare Zero Trust.

Once the authentication is successful you should have this status in the Warp client. This means that Cloudflare will handle all DNS traffic and egress traffic will be routed via Cloudflare.

If you now, try and access internal applications according to the application that we added it will be routed via the WARP agent.

Leave a Reply

Scroll to Top