Early last year, before any of us knew that so many people would be working remotely in 2020, we announced that Cloudflare Access, Cloudflare’s Zero Trust authentication solution, would begin protecting the Remote Desktop Protocol (RDP). To protect RDP, customers would deploy Argo Tunnel to create an encrypted connection between their RDP server and our edge - effectively locking down RDP resources from the public Internet. Once locked down with Tunnel, customers could use Cloudflare Access to create identity-driven rules enforcing who could log in to their resources.
Setting Tunnel up initially required installing the Cloudflare daemon, cloudflared, on each RDP server. However, as the adoption of remote work increased we learned that installing and provisioning a new daemon on every server in a network was a tall order for customers managing large fleets of servers.
What should have been a simple, elegant VPN replacement became a deployment headache. As organizations helped tens of thousands of users switch to remote work, no one had the bandwidth to deploy tens of thousands of daemons.
Message received: today we are announcing Argo Tunnel RDP Bastion mode, a simpler way to protect RDP connections at scale. ? By functioning as a jump-host, cloudflared can reside on a single node in your network and proxy requests to any internal server, eliminating deployment headaches.
Previously, if a user wanted to RDP to a resource not yet protected with a dedicated cloudflared tunnel, they would have to reach out to a member of their infrastructure team and request that it be provisioned manually. For larger enterprises managing thousands of network assets, this could pose a significant burden, involving new configuration management manifests and implementing tunnel health monitoring.
Argo Tunnel RDP Bastion mode enables teams to reach any machine through a single cloudflared instance - a single tunnel, gated by Cloudflare Access, to reach hundreds of remote desktops.
Why does RDP matter?
RDP is one of the most popular protocols used by employees to access their office computers from remote devices. It is installed by default on Windows, and is supported on *nix and MacOS operating systems. Many companies rely on RDP to allow their employees to work from home.
Utilization of the remote desktop protocol has increased significantly in correlation with increased work from home due to the Coronavirus pandemic. Unfortunately, in a rush to make machines available to remote users, many organizations have misconfigured RDP, which has given attackers a new opportunity to target remote desktops.
This increase is due primarily to two factors. The first factor is exposure. Many RDP servers are inadvertently exposed directly to the open Internet due to incomplete enforcement of firewall rules or unpatched vulnerabilities. Quickly exposing desktop fleets in a rush to help employees work from home might result in more security oversights.
Second, most RDP servers are not protected with corporate SSO tools. When users connect over RDP, they often enter a local password to login to the target machine. However, organizations don't always manage these credentials properly. Instead, users set and save passwords on an ad-hoc basis outside of the single sign-on credentials used for other services. That oversight leads to outdated, reused, and ultimately weak passwords that are potentially securing Internet-exposed resources.
Where does Cloudflare Access fit?
Cloudflare Access adds stronger authentication to RDP sessions by first locking down access to the remote machine via Argo Tunnel, then enforcing identity-based policies to determine who can gain access. Whether your organization uses Okta, Azure AD, or another provider, your users will be prompted to authenticate with those credentials before starting any RDP sessions.
With RDP connections protected by Access, organizations can enforce the same password strength and rotation requirements for RDP connections as they do for other critical tools.
How does it work?
On the origin side, an admin will configure a single cloudflared instance to run in bastion mode. That bastion will reach out to the two closest Cloudflare edge data centers and create a long-lived HTTP2 session. Once set up, cloudflared will wait for incoming connections from clients to specify which final origin to connect to. This is unlike conventional cloudflared tunnel behavior, which immediately creates a single outgoing connection to a pre-configured origin.
On the RDP user side, a cloudflared instance running as a client will be configured with the final destination of the RDP session. This isn't the address of the cloudflared bastion but rather the internal hostname the user wants to connect to.
Next, the user’s primary RDP client (i.e. “Remote Desktop Connection” on Windows) will initiate a connection to the local cloudflared client. cloudflared will launch a browser window and navigate to the Access app’s login page, prompting the user to authenticate with an IdP.
Once authenticated, the cloudflared client will tunnel the RDP traffic over HTTPS requests to the Cloudflare edge, including the final RDP destination and Access JWT in the request headers. The edge will verify the Access JWT to ensure that the client is authorized to reach the origin and, if it is, will use a special PoP to PoP route called Argo Smart Routing to forward the connection to the bastion over the shortest path possible.
For each incoming connection, the bastion will initiate an outgoing RDP session to the final internal destination and proxy traffic back and forth to the client.
What’s next?
While today we are proxying just RDP traffic in bastion mode, we will eventually be expanding this functionality to protocols like FTP, SSH, and generic TCP.
In the effort to make protecting internal resources easier than ever before, cloudflared can now also be conveniently found in the Cloudflare package repo, in tagged releases on the cloudflared Github repo, and in the cloudflared Docker hub repo.