Tag Archives: Cloudflare Access

RDP without the risk: Cloudflare’s browser-based solution for secure third-party access

Post Syndicated from Ann Ming Samborski original https://blog.cloudflare.com/browser-based-rdp/

Short-lived SSH access made its debut on Cloudflare’s SASE platform in October 2024. Leveraging the knowledge gained through the BastionZero acquisition, short-lived SSH access enables organizations to apply Zero Trust controls in front of their Linux servers. That was just the beginning, however, as we are thrilled to announce the release of a long-requested feature: clientless, browser-based support for the Remote Desktop Protocol (RDP). Built on top of Cloudflare’s modern proxy architecture, our RDP proxy offers a secure and performant solution that, critically, is also easy to set up, maintain, and use.

Security challenges of RDP 

Remote Desktop Protocol (RDP) was born in 1998 with Windows NT 4.0 Terminal Server Edition. If you have never heard of that Windows version, it’s because, well, there’s been 16 major Windows releases since then. Regardless, RDP is still used across thousands of organizations to enable remote access to Windows servers. It’s a bit of a strange protocol that relies on a graphical user interface to display screen captures taken in very close succession in order to emulate the interactions on the remote Windows server. (There’s more happening here beyond the screen captures, including drawing commands, bitmap updates, and even video streams. Like we said — it’s a bit strange.) Because of this complexity, RDP can be computationally demanding and poses a challenge for running at high performance over traditional VPNs.

Beyond its quirks, RDP has also had a rather unsavory reputation in the security industry due to early vulnerabilities with the protocol. The two main offenders are weak user sign-in credentials and unrestricted port access. Windows servers are commonly protected by passwords, which often have inadequate security to start, and worse still, may be shared across multiple accounts. This leaves these RDP servers open to brute force or credential stuffing attacks. 

Bad actors have abused RDP’s default port, 3389, to carry out on-path attacks. One of the most severe RDP vulnerabilities discovered is called BlueKeep. Officially known as CVE-2019-0708, BlueKeep is a vulnerability that allows remote code execution (RCE) without authentication, as long as the request adheres to a specific format and is sent to a port running RDP. Worse still, it is wormable, meaning that BlueKeep can spread to other machines within the network with no user action. Because bad actors can compromise RDP to gain unauthorized access, attackers can then move laterally within the network, escalating privileges, and installing malware. RDP has also been used to deploy ransomware such as Ryuk, Conti, and DoppelPaymer, earning it the nickname “Ransomware Delivery Protocol.” 

This is a subset of vulnerabilities in RDP’s history, but we don’t mean to be discouraging. Thankfully, due to newer versions of Windows, CVE patches, improved password hygiene, and better awareness of privileged access, many organizations have reduced their attack surface. However, for as many secured Windows servers that exist, there are still countless unpatched or poorly configured systems online, making them easy targets for ransomware and botnets. 

The need for a browser-based RDP solution

Despite its security risks, RDP remains essential for many organizations, particularly those with distributed workforces and third-party contractors. It provides value for compute-intensive tasks that require high-powered Windows servers with CPU/GPU resources greater than users’ machines can offer. For security-focused organizations, RDP grants better visibility into who is accessing Windows servers and what actions are taken during those sessions. 

Because issuing corporate devices to contractors is costly and cumbersome, many organizations adopt a bring-your-own-device (BYOD) policy. This decision instead requires organizations to provide contractors with a means to RDP to a Windows server with the necessary corporate resources to fulfill their role.

Traditional RDP requires client software on user devices, so this is not an appropriate solution for contractors (or any employees) using personal machines or unmanaged devices. Previously, Cloudflare customers had to rely on self-hosted third-party tools like Apache Guacamole or Devolutions Gateway to enable browser-based RDP access. This created several operational pain points:

  • Infrastructure complexity: Deploying and maintaining RDP gateways increases operational overhead.

  • Maintenance burden: Commercial and open-source tools may require frequent updates and patches, sometimes even necessitating custom forks.

  • Compliance challenges: Third-party software requires additional security audits and risk management assessments, particularly for regulated industries.

  • Redundancy, but not the good kind – Customers come to Cloudflare to reduce the complexity of maintaining their infrastructure, not add to it.

We’ve been listening. Cloudflare has architectured a high-performance RDP proxy that leverages the modern security controls already part of our Zero Trust Network Access (ZTNA) service. We feel that the “security/performance tradeoff” the industry commonly touts is a dated mindset. With the right underlying network architecture, we can help mitigate RDP’s most infamous challenges.

Introducing browser-based RDP with Access

Cloudflare’s browser-based RDP solution is the newest addition to Cloudflare Access alongside existing clientless SSH and VNC offerings, enabling secure, remote Windows server access without VPNs or RDP clients. Built natively within Cloudflare’s global network, it requires no additional infrastructure.

Our browser-based RDP access combines the power of self-hosted Access applications with the additional flexibility of targets, introduced with Access for Infrastructure. Administrators can enforce:

  • Authentication: Control how users authenticate to your internal RDP resources with SSO, MFA, and device posture.

  • Authorization: Use policy-based access control to determine who can access what target and when. 

  • Auditing: Provide Access logs to support regulatory compliance and visibility in the event of a security breach.

Users only need a web browser — no native RDP client is necessary! RDP servers are accessed through our app connector, Cloudflare Tunnel, using a common deployment model of existing Access customers. There is no need to provision user devices to access particular RDP servers, making for minimal setup to adopt this new functionality.


How it works

The client

Cloudflare’s implementation leverages IronRDP, a high-performance RDP client that runs in the browser. It was selected because it is a modern, well-maintained, RDP client implementation that offers an efficient and responsive experience. Unlike Java-based Apache Guacamole, another popular RDP client implementation, IronRDP is built with Rust and integrates very well with Cloudflare’s development ecosystem.

While selecting the right tools can make all the difference, using a browser to facilitate an RDP session faces some challenges. From a practical perspective, browsers just can’t send RDP messages. RDP relies directly on the Layer 4 Transmission Control Protocol (TCP) for communication, and while browsers can use TCP as the underlying protocol, they do not expose APIs that would let apps build protocol support directly on raw TCP sockets.

Another challenge is rooted in a security consideration: the username and password authentication mechanism that is native to RDP leaves a lot to be desired in the modern world of Zero Trust.

In order to tackle both of these challenges, the IronRDP client encapsulates the RDP session in a WebSocket connection. Wrapping the Layer 4 TCP traffic in HTTPS enables the client to use native browser APIs to communicate with Cloudflare’s RDP proxy. Additionally, it enables Cloudflare Access to secure the entire session using identity-aware policies. By attaching a Cloudflare Access authorization JSON Web Token (JWT) via cookie to the WebSocket connection, every inter-service hop of the RDP session is verified to be coming from the authenticated user.  

A brief aside into how security and performance is optimized: in conventional client-based RDP traffic, the client and server negotiate a TLS connection to secure and verify the session. However, because the browser WebSocket connection is already secured with TLS to Cloudflare, we employ IronRDP’s RDCleanPath protocol extension to eliminate this second encapsulation of traffic. Removing this redundancy avoids unnecessary performance degradation and increased complexity during session handshakes.

The server

The IronRDP client initiates a WebSocket connection to a dedicated WebSocket proxy, which is responsible for authenticating the client, terminating the WebSocket connection, and proxying tunneled RDP traffic deeper into Cloudflare’s infrastructure to facilitate connectivity. The seemingly simple task of determining how this WebSocket proxy should be built turned out to be the most challenging decision in the development process. 

Our initial proposal was to develop a new service that would run on every server within our network. While this was feasible, operating a new service would introduce a non-trivial maintenance burden, which ultimately turned out to be more overhead than value-add in this case. The next proposal was to build it into Front Line (FL), one of Cloudflare’s oldest services that is responsible for handling tens of millions of HTTP requests per second. This approach would have sidestepped the need to expose new IP addresses and benefitted from the existing scaffolding to let the team move quickly. Despite being promising at first, this approach was decided against because FL is undergoing significant investment, and the team didn’t want to build on shifting sands.

Finally, we identified a solution that implements the proxy service using Cloudflare Workers! Fortunately, Workers automatically scales to massive request rates, which eliminates some of the groundwork we’d lay if we had chosen to build a new service. Candidly, this approach was not initially preferred due to some ambiguities around how Workers communicates with internal Cloudflare services, but with support from the Workers team, we found a path forward. 

From the WebSocket proxy Worker, the tunneled RDP connection is sent to the Apollo service, which is responsible for routing traffic between on-ramps and off-ramps for Cloudflare Zero Trust. Apollo centralizes and abstracts these complexities to let other services focus on application-specific functionality. Apollo determines which Cloudflare colo is closest to the target Cloudflare Tunnel and establishes a connection to an identical Apollo instance running in that colo. The egressing Apollo instance can then facilitate the final connection to the Cloudflare Tunnel. By using Cloudflare’s global network to traverse the distance between the ingress colo and the target Cloudflare Tunnel, network disruptions and congestion is managed.

Apollo connects to the RDP server and passes the ingress and egress connections to Oxy-teams, the service responsible for inspecting and proxying the RDP traffic. It functions as a pass-through (strictly enabling traffic connectivity) as the web client authenticates to the RDP server. Our initial release makes use of NT Lan Manager (NTLM) authentication, a challenge-response authentication protocol requiring username and password entry. Once the client has authenticated with the server, Oxy-teams is able to proxy all subsequent RDP traffic!

This may sound like a lot of hops, but every server in our network runs every service. So believe it or not, this complex dance takes place on a single server and by using UNIX domain sockets for communication, we also minimize any performance impact. If any of these servers become overloaded, experience a network fault, or have a hardware problem, the load is automatically shifted to a neighboring server with the help of Unimog, Cloudflare’s L4 load balancer.

Putting it all together

  1. User initiation: The user selects an RDP server from Cloudflare’s App Launcher (or accesses it via a direct URL). Each RDP server is associated with a public hostname secured by Cloudflare. 

  2. Ingress: This request is received by the closest data center within Cloudflare’s network. 

  3. Authentication: Cloudflare Access authenticates the session by validating that the request contains a valid JWT. This token certifies that the user is authorized to access the selected RDP server through the specified domain.

  4. Web client delivery: Cloudflare Workers serves the IronRDP web client to the user’s browser.

  5. Secure tunneling: The client tunnels RDP traffic from the user’s browser over a TLS-secured WebSocket to another Cloudflare Worker. 

  6. Traffic routing: The Worker that receives the IronRDP connection terminates the WebSocket and initiates a connection to Apollo. From there, Apollo creates a connection to the RDP server.

  7. Authentication relay: With a connection established, Apollo relays RDP authentication messages between the web client and the RDP server. 

  8. Connection establishment: Upon successful authentication, Cloudflare serves as an RDP proxy between the web browser and the RDP server, connecting the user to the RDP server with free-flowing traffic. 

  9. Policy enforcement: Cloudflare’s secure web gateway, Oxy-teams, applies Layer 4 policy enforcement and logging of the RDP traffic.


Key benefits of this architecture:

  • No additional software: Access Windows servers directly from a browser.

  • Low latency: Cloudflare’s global network minimizes performance overhead.

  • Enhanced security: RDP access is protected by Access policies, preventing lateral movement.

  • Integrated logging and monitoring: Administrators can observe and control RDP traffic.

To learn more about Cloudflare’s proxy capabilities, take a look at our related blog post explaining our proxy framework.

Selective, modern RDP authentication

Cloudflare’s browser-based RDP solution exclusively supports modern RDP authentication mechanisms, enforcing best practices for secure access. Our architecture ensures that RDP traffic using outdated or weak legacy security features from older versions of the RDP standard, such as unsecured password-based authentication or RC4 encryption, are never allowed to reach customer endpoints.

Cloudflare supports secure session negotiation using the following principles:

  1. TLS-based WebSocket connection for transport security.

  2. Fine-grained policies that enforce single sign on (SSO), multi-factor authentication (MFA), and dynamic authorization.

  3. Integration with enterprise identity providers via SAML (Security Assertion Markup Language) and OIDC (OpenID Connect).

Every RDP session that passes through Cloudflare’s network is encrypted and authenticated.

What’s next? 

This is only the beginning for our browser-based RDP solution! We have already identified a few areas for continued focus:

  • Enhanced visibility and control for administrators: Because RDP traffic passes through Cloudflare Workers and proxy services, browser-based RDP will expand to include session monitoring. We are also evaluating data loss prevention (DLP) support, such as restricting actions like file transfers and clipboard use, to prevent unauthorized data exfiltration without compromising performance. 

  • Advanced authentication: Long-lived credentials are a thing of the past. Future iterations of browser-based RDP will include passwordless functionality, eliminating the need for end users to remember passwords and administrators from having to manage them. To that end, we are evaluating methods such as client certificate authentication, passkeys and smart cards, and integration with third-party authentication providers via Access.

Compliance and FedRAMP High certification

We plan to include browser-based RDP in our FedRAMP High offering for enterprise and government organizations, a high-priority initiative we announced in early February. This certification will validate that our solution meets the highest standards for:

  • Data protection

  • Identity and access management

  • Continuous monitoring

  • Incident response

Seeking FedRAMP High compliance demonstrates Cloudflare’s commitment to securing sensitive environments, such as those in the federal government, healthcare, and financial sectors.

By enforcing a modern, opinionated, and secure implementation of RDP, Cloudflare provides a secure, scalable, and compliant solution tailored to the needs of organizations with critical security and compliance mandates.

Get started today

At Cloudflare, we are committed to providing the most comprehensive solution for ZTNA, which now also includes privileged access to sensitive infrastructure like Windows servers over browser-based RDP. Cloudflare’s browser-based RDP solution is in closed beta with new customers being onboarded each week. You can request access here to try out this exciting new feature.

In the meantime, check out our Access for Infrastructure documentation to learn more about how Cloudflare protects privileged access to sensitive infrastructure. Access for Infrastructure is currently available free to teams of under 50 users, and at no extra cost to existing pay-as-you-go and Contract plan customers through an Access or Zero Trust subscription. Stay tuned as we continue to natively rebuild BastionZero’s technology into Cloudflare’s Access for Infrastructure service!

Improved support for private applications and reusable access policies with Cloudflare Access

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/improved-support-for-private-applications-and-reusable-access-policies-with-cloudflare-access/

Simplifying secure access for every application

For years, Cloudflare has helped organizations modernize their access to internal resources by delivering identity-aware access controls through our Zero Trust Network Access (ZTNA) service, Cloudflare Access. Our customers have accelerated their ZTNA implementations for web-based applications in particular, using our intuitive workflows for Access applications tied to public hostnames.

However, given our architecture design, we have primarily handled private network application access (applications tied to private IP addresses or hostnames) through the network firewall component of our Secure Web Gateway (SWG) service, Cloudflare Gateway. We provided a small wrapper from Access to connect the two experiences. While this implementation technically got the job done, there were some clear downsides, and our customers have frequently cited the inconsistency.

Today, we are thrilled to announce that we have redesigned the self-hosted private application administrative experience within Access to match the experience for web-based apps on public hostnames. We are introducing support for private hostname and IP address-defined applications directly within Access, as well as reusable access policies. Together, these updates make ZTNA even easier for our customers to deploy and streamline ongoing policy management.

In order to better understand how this feature improves the overall functionality of Access, let’s explore what makes up a “private” application, how they are typically accessed, what was possible before this feature, and what the new feature enables. If you are a networking expert or aficionado, you can skip ahead to A look back: protecting private applications with Cloudflare Zero Trust before Access Private IP Address and Hostname support.

Private applications

A private application in this context, is any application that is only accessible through a private IP address or hostname. 

Private IP addresses

Private IP addresses, often referred to as RFC 1918 IP addresses, are scoped to a specific network and can only be reached by users on that network. While public IP addresses must be unique across the entire Internet, private IP addresses can be reused across networks. Any device or virtual machine will have a private IP address. For example, if I run ipconfig on my own Windows machine, I can see an address of 192.168.86.172.


This is the address that any other machine on my own network can use to reference and communicate with this specific machine. Private IP addresses are useful for applications and ephemeral infrastructure (systems that spin up and down dynamically) because they can be reused and only have to be unique within their specific network. This is much easier to manage than issuing a public IPv4 address to resources – we’ve actually run out of available public IPv4 address space!

In order to host an application on a machine in my network, I need to make that application available to other machines in the network. Typically, this is done by assigning the application to a specific port. A request to that application might then look something like this: http://10.128.0.6:443 which in plain English is saying “Using the hypertext transfer protocol, reach out to the machine at an address of 10.128.0.6 in my network, and connect to port 443.” Connecting to an application can be done in a browser, over SSH, over RDP, through a thick client application, or many other methods of accessing a resource over an IP address.

In this case, we have an Apache2 example web server, running at that address and port combination.


If I attempt to access this IP address outside of the same network as this machine running the web server, then I will either get no result, or a completely different application, if I have something else running on that IP address/port combination in that other network.


Private hostnames

We don’t want to remember 10.128.0.6 every time we want to access this application. Just like the Internet, we can use DNS in our private network. While public DNS serves as the phone book for the entire Internet, private DNS is more like a school directory that is only valid for phone numbers within the campus.

For a private application, I can configure a DNS record, very similar to how I might expose a public website to the world. But instead, I will map my DNS record to a private IP address that is only accessible within my own network. Additionally, private DNS does not require registering a domain with a registrar or adhering to defined top level domains. I can host an application on application.mycompany, and it is a valid internal DNS record. 

In this example, I am running my web server on Google Cloud and will call the application kennyapache.local. In my local DNS, kennyapache.local has an A record mapping it to an IPv4 address within my private network on Google Cloud (GCP).


This means that any machine within my network can use https://kennyapache.local instead of having to remember the explicit IP address.


Accessing private applications outside the private network

Private networks require your machine, or virtual machine, to be connected directly to the same network as the target private IP address or hostname. This is a helpful property to keep unauthorized users from accessing applications, but presents a challenge if the application you want to use is outside your local network. 

Virtual Private Networks (VPNs), forward proxies, and proxy protocols (aka “PAC files”) are all methods to enable a machine outside your private network to reach a private IP address/hostname within the private network. These tools work by adding an additional network interface to the machine and specifying that certain requests need to be routed through a remote private network, not the local network the machine is currently connected to, or out to the public Internet.

When I connect my machine to a forward proxy, in this case Cloudflare’s device client, WARP, and run ipconfig I can see a new network interface and IP address added to the list:


This additional network interface will take control of specific network requests and route those to an external private network instead of the default behavior of my machine, which would be to route to that IP address on my own local network.

A look back: protecting private applications with Cloudflare Zero Trust before Access Private IP Address and Hostname support

We will continue to use our Apache2 server hosted on a GCP private domain as an example private application. We will briefly touch on how Cloudflare Zero Trust was previously used to protect private applications and why this new feature is a huge step forward. Cloudflare Zero Trust has two primary components used to protect application traffic: Cloudflare Access and Gateway.

Cloudflare Access

Cloudflare Access is designed to protect internal applications and resources without the need for a traditional VPN. Access allows organizations to authenticate and authorize users through identity providers — such as Okta, Azure AD, or Google Workspace — before granting them entry to internal systems or web-based applications. 

Until now, Access required that an application had to be defined using a public DNS record. This means that a user had to expose their application to the Internet in order to leverage Access and use all of its granular security features. This isn’t quite as scary as it sounds, because Access allows you to enforce strong user, device, and network security controls. In fact, NIST and many other major security organizations support this model.

In practice, an administrator would map their internal IP address or hostname to a public URL using our app connector, Cloudflare Tunnel. 


Then, the administrator would create an Access application corresponding to that public URL. Cloudflare then sends a user through a single sign-on flow for any request made to that application.


However, this approach does not work for organizations that have strict requirements to never expose an application over public DNS. Additionally, this does not work for applications outside the browser like SSH, RDP, FTP and other thick client applications, which are all options to connect to private applications.

If I tried to SSH to my Access-protected public hostname, I would get an error message with no way to authenticate, since there is no easy way to do a single sign-on through the browser in conjunction with SSH.

Access Private Network applications

Until now, because Access operated using public hostnames, we have handled private network access for our customers using the network firewall piece of Cloudflare Gateway. A few years ago, we launched Access Private Network applications, which automatically generate the required Gateway block policies. However, this was a limited approach that was ultimately just a wrapper in front of two Gateway policies. 


Cloudflare Gateway

Cloudflare Gateway is a secure web gateway that protects users from threats on the public Internet by filtering and securing DNS and web traffic. Gateway acts as a protective layer between end users and online resources by enforcing security controls, like blocking malicious domains, restricting access to risky categories of sites, and preventing data exfiltration. 

Gateway is also used to route user traffic into private networks and acts as a forward proxy. It allows customers to create policies for private IP addresses and hostnames. This is because Gateway relies on traffic being proxied from the user’s machine to the Gateway service itself. This is most commonly done with the Cloudflare WARP client. WARP enables the configuration of which IP addresses and hostnames to send to Gateway for filtering and routing.

Once connected to a private network, through Gateway, a user can directly connect to private IP addresses and hostnames that are configured for that network.

I can then configure specific network firewall policies to allow or block traffic destined to private IP addresses.


Great! Looks like we’ve solved protecting private applications using Gateway. Not quite, unfortunately, as there are a few components of Gateway that are not an ideal model for an application-focused security model. While not discussed above, a few of the challenges we encountered when using Gateway for application access control included:

  • Private applications were mixed in with general Gateway network firewall rules, complicating configuration and maintenance

  • Defining and managing private applications was not possible in Terraform

  • Application access logs were buried in general network firewall logs (these logs can contain all Internet traffic for an organization!)

  • Enforcement within Gateway relied on specific WARP client sessions, which lacked granular identity details

  • Administrators couldn’t use Access Rule Groups or other Access features built specifically for managing application access controls

We knew we could do better.

A unified approach to application access

Knowing these limitations, we set out to extend Access to support any application, regardless of whether it is public or private. This principle guided our efforts to create a unified application definition in Cloudflare Access. Any self-hosted application, regardless of whether it is public or privately routable, should be defined in a single application type. The result is quite straightforward: Access Applications now support private IP addresses and hostnames.


However, the engineering work was not as simple as adding a private IP address and hostname option to Cloudflare Access. Given our platform’s architecture, Access does not have any way to route private requests by itself. We still have to rely on Gateway and the WARP client for that component.

An application-aware firewall

This meant that we needed to add an application-specific phase to Gateway’s firewall. The new phase detects whether a user’s traffic matches a defined application, and if so it sends the traffic to Access for authentication and authorization of a user and their session. This required extending Gateway’s network firewall to have knowledge of which private IP addresses and hostnames are defined as applications.

Thanks to this new firewall phase, now an administrator can configure exactly where they want their private applications to be evaluated in their overall network firewall.


Private application sessions

The other component we had to solve was per-application session management. In an Access public application, we issue a JSON Web Token (JWT) as a cookie which conveniently has an expiration associated. That acts as a session expiration. For private applications, we do not always have the ability to store a cookie. If the request is not over a browser, there is nowhere to put a cookie.

For browser-based private applications, we follow the exact same pattern as a public application and issue a JWT as a means to track the session. App administrators get the additional benefit of being able to do JWT validation for these apps as well. Non-browser based applications required adding a new per-application session to Gateway’s firewall. These application sessions are bound to a specific device and track the next time a user has to authenticate before accessing the application.


Access private applications

Once we solved application awareness and session management in Gateway’s firewall, we could extend Access to support private IP address- and hostname-defined applications. Administrators can now directly define Access applications using private IP addresses and hostnames:


You can see that private hostname and private IP address are now configuration options when defining an Access application.

If it is a non-HTTPS application (whether HTTP or non-browser), the user will receive a client pop-up prompting a re-authentication:


HTTPS applications will behave exactly the same as an Access application with a public hostname. The user will be prompted to log in via single sign-on, and then a JWT will be issued to that specific domain.


Then we see a JWT issued to the application itself.


Introducing Reusable Policies

As part of this work, we were able to address another long-standing pain point in Access —– managing policies across multiple applications was a time-consuming and error-prone process. Policies were nested objects under individual applications, requiring administrators to either rely heavily on Access Groups or repeat identical configurations for each application. 


With Reusable Policies, administrators can now create standardized policies — such as high, medium, or low risk — and assign them across multiple applications. A single change to a reusable policy will propagate to all associated applications, significantly simplifying management. With this new capability, we anticipate that many of our customers will be able to move from managing hundreds of access policies to a small handful. We’ve also renamed “Access Groups” to “Rule Groups,” aligning with their actual function and reducing confusion with identity provider (IdP) groups.

A redesigned user interface

Alongside these functional updates, we’ve launched a significant UI refresh based on years of user feedback. The new interface offers more information at a glance and provides consistent, intuitive workflows for defining and managing applications. 

Looking ahead

While today’s release is a major step forward, there’s more to come. Currently, private hostname support is limited to port 443 with TLS inspection enabled. Later in 2025, we plan to extend support to arbitrary private hostnames on any port and protocol, further broadening Access’s capabilities.

Get started today

These new Access features are live and ready for you to explore. If you haven’t yet started modernizing remote access at your organization, sign up for a free account to test it out. Whether you’re securing private resources or simplifying policy management, we’re excited to see how these updates enhance your Zero Trust journey. As always, we’re here to help — reach out to your account team with any questions or feedback.

Watch on Cloudflare TV

Conventional cryptography is under threat. Upgrade to post-quantum cryptography with Cloudflare Zero Trust

Post Syndicated from Sharon Goldberg original https://blog.cloudflare.com/post-quantum-zero-trust/

Quantum computers are actively being developed that will eventually have the ability to break the cryptography we rely on for securing modern communications. Recent breakthroughs in quantum computing have underscored the vulnerability of conventional cryptography to these attacks. Since 2017, Cloudflare has been at the forefront of developing, standardizing, and implementing post-quantum cryptography to withstand attacks by quantum computers. 

Our mission is simple: we want every Cloudflare customer to have a clear path to quantum safety. Cloudflare recognizes the urgency, so we’re committed to managing the complex process of upgrading cryptographic algorithms, so that you don’t have to worry about it. We’re not just talking about doing it. Over 35% of the non-bot HTTPS traffic that touches Cloudflare today is post-quantum secure. 

The National Institute of Standards and Technology (NIST) also recognizes the urgency of this transition. On November 15, 2024, NIST made a landmark announcement by setting a timeline to phase out RSA and Elliptic Curve Cryptography (ECC), the conventional cryptographic algorithms that underpin nearly every part of the Internet today. According to NIST’s announcement, these algorithms will be deprecated by 2030 and completely disallowed by 2035.

At Cloudflare, we aren’t waiting until 2035 or even 2030. We believe privacy is a fundamental human right, and advanced cryptography should be accessible to everyone without compromise. No one should be required to pay extra for post-quantum security. That’s why any visitor accessing a website protected by Cloudflare today benefits from post-quantum cryptography, when using a major browser like Chrome, Edge, or Firefox. (And, we are excited to see a small percentage of (mobile) Safari traffic in our Radar data.) Well over a third of the human traffic passing through Cloudflare today already enjoys this enhanced security, and we expect this share to increase as more browsers and clients are upgraded to support post-quantum cryptography. 

While great strides have been made to protect human web traffic, not every application is a web application. And every organization has internal applications (both web and otherwise) that do not support post-quantum cryptography.  

How should organizations go about upgrading their sensitive corporate network traffic to support post-quantum cryptography?

That’s where today’s announcement comes in. We’re thrilled to announce the first phase of end-to-end quantum readiness of our Zero Trust platform, allowing customers to protect their corporate network traffic with post-quantum cryptography. Organizations can tunnel their corporate network traffic though Cloudflare’s Zero Trust platform, protecting it against quantum adversaries without the hassle of individually upgrading each and every corporate application, system, or network connection. 

More specifically, organizations can use our Zero Trust platform to route communications from end-user devices (via web browser or Cloudflare’s WARP device client) to secure applications connected with Cloudflare Tunnel, to gain end-to-end quantum safety, in the following use cases: 

  • Cloudflare’s clientless Access: Our clientless Zero Trust Network Access (ZTNA) solution verifies user identity and device context for every HTTPS request to corporate applications from a web browser. Clientless Access is now protected end-to-end with post-quantum cryptography.

  • Cloudflare’s WARP device client: By mid-2025, customers using the WARP device client will have all of their traffic (regardless of protocol) tunneled over a connection protected by post-quantum cryptography. The WARP client secures corporate devices by privately routing their traffic to Cloudflare’s global network, where Gateway applies advanced web filtering and Access enforces policies for secure access to applications. 

  • Cloudflare Gateway: Our Secure Web Gateway (SWG) — designed to inspect and filter TLS traffic in order to block threats and unauthorized communications — now supports TLS with post-quantum cryptography. 

In the remaining sections of this post, we’ll explore the threat that quantum computing poses and the challenges organizations face in transitioning to post-quantum cryptography. We’ll also dive into the technical details of how our Zero Trust platform supports post-quantum cryptography today and share some plans for the future.

Why transition to post-quantum cryptography and why now? 

There are two key reasons to adopt post-quantum cryptography now:

1. The challenge of deprecating cryptography

History shows that updating or removing outdated cryptographic algorithms from live systems is extremely difficult. For example, although the MD5 hash function was deemed insecure in 2004 and long since deprecated, it was still in use with the RADIUS enterprise authentication protocol as recently as 2024. In July 2024, Cloudflare contributed to research revealing an attack on RADIUS that exploited its reliance on MD5. This example underscores the enormous challenge of updating legacy systems — this difficulty in achieving crypto-agility — which will be just as demanding when it’s time to transition to post-quantum cryptography. So it makes sense to start this process now.

2. The “harvest now, decrypt later” threat

Even though quantum computers lack enough qubits to break conventional cryptography today, adversaries can harvest and store encrypted communications or steal datasets with the intent of decrypting them once quantum technology matures. If your encrypted data today could become a liability in 10 to 15 years, planning for a post-quantum future is essential. For this reason, we have already started working with some of the most innovative banks, ISPs, and governments around the world as they begin their journeys to quantum safety. 

The U.S. government is already addressing these risks. On January 16, 2025, the White House issued Executive Order 14144 on Strengthening and Promoting Innovation in the Nation’s Cybersecurity. This order requires government agencies to “regularly update a list of product categories in which products that support post-quantum cryptography (PQC) are widely available…. Within 90 days of a product category being placed on the list … agencies shall take steps to include in any solicitations for products in that category a requirement that products support PQC.”

At Cloudflare, we’ve been researching, developing, and standardizing post-quantum cryptography since 2017. Our strategy is simple:

Simply tunnel your traffic through Cloudflare’s quantum-safe connections to immediately protect against harvest-now-decrypt-later attacks, without the burden of upgrading every cryptographic library yourself.

Let’s take a closer look at how the migration to post-quantum cryptography is taking shape at Cloudflare.

A two-phase migration to post-quantum cryptography

At Cloudflare, we’ve largely focused on migrating the TLS (Transport Layer Security) 1.3 protocol to post-quantum cryptography.   TLS primarily secures the communications for web applications, but it is also widely used to secure email, messaging, VPN connections, DNS, and many other protocols.  This makes TLS an ideal protocol to focus on when migrating to post-quantum cryptography.

The migration involves updating two critical components of TLS 1.3: digital signatures used in certificates and key agreement mechanisms. We’ve made significant progress on key agreement, but the migration to post-quantum digital signatures is still in its early stages.

Phase 1: Migrating key agreement

Key agreement protocols enable two parties to securely establish a shared secret key that they can use to secure and encrypt their communications. Today, vendors have largely converged on transitioning TLS 1.3 to support a post-quantum key exchange protocol known as ML-KEM (Module-lattice based Key-Encapsulation Mechanism Standard). There are two main reasons for prioritizing migration of key agreement:

  • Performance: ML-KEM performs well with the TLS 1.3 protocol, even for short-lived network connections.

  • Security: Conventional cryptography is vulnerable to “harvest now, decrypt later” attacks. In this threat model, an adversary intercepts and stores encrypted communications today and later (in the future) uses a quantum computer to derive the secret key, compromising the communication. As of March 2025, well over a third of the human web traffic reaching the Cloudflare network is protected against these attacks by TLS 1.3 with hybrid ML-KEM key exchange.


Post-quantum encrypted share of human HTTPS request traffic seen by Cloudflare per Cloudflare Radar from March 1, 2024 to March 1, 2025. (Captured on March 13, 2025.)

Here’s how to check if your Chrome browser is using ML-KEM for key agreement when visiting a website: First, Inspect the page, then open the Security tab, and finally look for X25519MLKEM768 as shown here:


This indicates that your browser is using key-agreement protocol ML-KEM in combination with conventional elliptic curve cryptography on curve X25519. This provides the protection of the tried-and-true conventional cryptography (X25519) alongside the new post-quantum key agreement (ML-KEM).

Phase 2: Migrating digital signatures

Digital signatures are used in TLS certificates to validate the authenticity of connections — allowing the client to be sure that it is really communicating with the server, and not with an adversary that is impersonating the server. 

Post-quantum digital signatures, however, are significantly larger, and thus slower, than their current counterparts. This performance impact has slowed their adoption, particularly because they slow down short-lived TLS connections. 

Fortunately, post-quantum signatures are not needed to prevent harvest-now-decrypt-later attacks. Instead, they primarily protect against attacks by an adversary that is actively using a quantum computer to tamper with a live TLS connection. We still have some time before quantum computers are able to do this, making the migration of digital signatures a lower priority.

Nevertheless, Cloudflare is actively involved in standardizing post-quantum signatures for TLS certificates. We are also experimenting with their deployment on long-lived TLS connections and exploring new approaches to achieve post-quantum authentication without sacrificing performance. Our goal is to ensure that post-quantum digital signatures are ready for widespread use when quantum computers are able to actively attack live TLS connections.

Cloudflare Zero Trust + PQC: future-proofing security

The Cloudflare Zero Trust platform replaces legacy corporate security perimeters with Cloudflare’s global network, making access to the Internet and to corporate resources faster and safer for teams around the world. Today, we’re thrilled to announce that Cloudflare’s Zero Trust platform protects your data from quantum threats as it travels over the public Internet.  There are three key quantum-safe use cases supported by our Zero Trust platform in this first phase of quantum readiness.

Quantum-safe clientless Access

Clientless Cloudflare Access now protects an organization’s Internet traffic to internal web applications against quantum threats, even if the applications themselves have not yet migrated to post-quantum cryptography. (“Clientless access” is a method of accessing network resources without installing a dedicated client application on the user’s device. Instead, users connect and access information through a web browser.)


Here’s how it works today:

  • PQ connection via browser: (Labeled (1) in the figure.)
    As long as the user’s web browser supports post-quantum key agreement, the connection from the device to Cloudflare’s network is secured via TLS 1.3 with post-quantum key agreement.

  • PQ within Cloudflare’s global network: (Labeled (2) in the figure) 
    If the user and origin server are geographically distant, then the user’s traffic will enter Cloudflare’s global network in one geographic location (e.g. Frankfurt), and exit at another (e.g. San Francisco).  As this traffic moves from one datacenter to another inside Cloudflare’s global network, these hops through the network are secured via TLS 1.3 with post-quantum key agreement. 

  • PQ Cloudflare Tunnel: (Labeled (3) in the figure)
    Customers establish a Cloudflare Tunnel from their datacenter or public cloud — where their corporate web application is hosted — to Cloudflare’s network. This tunnel is secured using TLS 1.3 with post-quantum key agreement, safeguarding it from harvest-now-decrypt-later attacks.

Putting it together, clientless Access provides end-to-end quantum safety for accessing corporate HTTPS applications, without requiring customers to upgrade the security of corporate web applications.

Quantum-safe Zero Trust with Cloudflare’s WARP Client-to-Tunnel configuration (as a VPN replacement)

By mid-2025, organizations will be able to protect any protocol, not just HTTPS, by tunneling it through Cloudflare’s Zero Trust platform with post quantum cryptography, thus providing quantum safety as traffic travels across the Internet from the end-user’s device to the corporate office/data center/cloud environment.

Cloudflare’s Zero Trust platform is ideal for replacing traditional VPNs, and enabling Zero Trust architectures with modern authentication and authorization polices.  Cloudflare’s WARP client-to-tunnel is a popular network configuration for our Zero Trust platform: organizations deploy Cloudflare’s WARP device client on their end users’ devices, and then use Cloudflare Tunnel to connect to their corporate office, cloud, or data center environments.   


 Here are the details:  

  • PQ connection via WARP client (coming in mid-2025): (Labeled (1) in the figure)
    The WARP client uses the MASQUE protocol to connect from the device to Cloudflare’s global network. We are working to add support for establishing this MASQUE connection with TLS 1.3 with post-quantum key agreement, with a target completion date of mid-2025.  

  • PQ within Cloudflare’s global network:  (Labeled (2) in the figure)
    As traffic moves from one datacenter to another inside Cloudflare’s global network, each hop it takes through Cloudflare’s network is already secured with TLS 1.3 with post-quantum key agreement.

  • PQ Cloudflare Tunnel: (Labeled (3) in the figure)
    As mentioned above, Cloudflare Tunnel already supports post-quantum key agreement. 

Once the upcoming post-quantum enhancements to the WARP device client are complete, customers can encapsulate their traffic in quantum-safe tunnels, effectively mitigating the risk of harvest-now-decrypt-later attacks without any heavy lifting to individually upgrade their networks or applications.  And this provides comprehensive protection for any protocol that can be sent through these tunnels, not just for HTTPS!

Quantum-safe SWG (end-to-end PQC for access to third-party web applications)

A Secure Web Gateway (SWG) is used to secure access to third-party websites on the public Internet by intercepting and inspecting TLS traffic. 

Cloudflare Gateway is now a quantum-safe SWG for HTTPS traffic. As long as the third-party website that is being inspected supports post-quantum key agreement, then Cloudflare’s SWG also supports post-quantum key agreement. This holds regardless of the onramp that the customer uses to get to Cloudflare’s network (i.e. web browser, WARP device client, WARP Connector, Magic WAN), and only requires the use of a browser that supports post-quantum key agreement.


Cloudflare Gateway’s HTTPS SWG feature involves two post-quantum TLS connections, as follows:

  • PQ connection via browser: (Labeled (1) in the figure) 
    A TLS connection is initiated from the user’s browser to a data center in Cloudflare’s network that performs the TLS inspection. As long as the user’s web browser supports post-quantum key agreement, this connection is secured by TLS 1.3 with post-quantum key agreement.  

  • PQ connection to the origin server: (Labeled (2) in the figure) 
    A TLS connection is initiated from a datacenter in Cloudflare’s network to the origin server, which is typically controlled by a third party. The connection from Cloudflare’s SWG currently supports post-quantum key agreement, as long as the third party’s origin server also already supports post-quantum key agreement.  You can test this out today by using https://pq.cloudflareresearch.com/ as your third-party origin server. 

Put together, Cloudflare’s SWG is quantum-ready to support secure access to any third-party website that is quantum ready today or in the future. And this is true regardless of the onramp used to get end users’ traffic into Cloudflare’s global network!

The post-quantum future: Cloudflare’s Zero Trust platform leads the way

Protecting our customers from emerging quantum threats isn’t just a priority — it’s our responsibility. Since 2017, Cloudflare has been pioneering post-quantum cryptography through research, standardization, and strategic implementation across our product ecosystem.

Today marks a milestone: We’re launching the first phase of quantum-safe protection for our Zero Trust platform. Quantum-safe clientless Access and Secure Web Gateway are available immediately, with WARP client-to-tunnel network configurations coming by mid-2025. As we continue to advance the state of the art in post-quantum cryptography, our commitment to continuous innovation ensures that your organization stays ahead of tomorrow’s threats.  Let us worry about crypto-agility so that you don’t have to.

To learn more about how Cloudflare’s built-in crypto-agility can future-proof your business, visit our Post-Quantum Cryptography webpage.

Watch on Cloudflare TV

Introducing Access for Infrastructure: SSH

Post Syndicated from Sharon Goldberg original https://blog.cloudflare.com/intro-access-for-infrastructure-ssh

BastionZero joined Cloudflare in May 2024. We are thrilled to announce Access for Infrastructure as BastionZero’s native integration into our SASE platform, Cloudflare One. Access for Infrastructure will enable organizations to apply Zero Trust controls in front of their servers, databases, network devices, Kubernetes clusters, and more. Today, we’re announcing short-lived SSH access as the first available feature. Over the coming months we will announce support for other popular infrastructure access target types like Remote Desktop Protocol (RDP), Kubernetes, and databases.

Applying Zero Trust principles to infrastructure

Organizations have embraced Zero Trust initiatives that modernize secure access to web applications and networks, but often the strategies they use to manage privileged access to their infrastructure can be siloed, overcomplicated, or ineffective. When we speak to customers about their infrastructure access solution, we see common themes and pain points:

  • Too risky: Long-lived credentials and shared keys get passed around and inflate the risk of compromise, excessive permissions, and lateral movement

  • Too clunky: Manual credential rotations and poor visibility into infrastructure access slow down incident response and compliance efforts

Some organizations have dealt with the problem of privileged access to their infrastructure by purchasing a Privileged Access Management (PAM) solution or by building a homegrown key management tool. Traditional PAM solutions introduce audit logging and session recording features that capture user interactions with their servers and other infrastructure and/or centralized vaults that rotate keys and passwords for infrastructure every time a key is used. But this centralization can introduce performance bottlenecks, harm usability, and come with a significant price tag. Meanwhile, homegrown solutions are built from primitives provided by cloud providers or custom infrastructure-as-code solutions, and can be costly and tiresome to build out and maintain. 

We believe that organizations should apply Zero Trust principles to their most sensitive corporate resources, which naturally includes their infrastructure. That’s why we’re augmenting Cloudflare’s Zero Trust Network Access (ZTNA) service with Access to Infrastructure to support privileged access to sensitive infrastructure, and offering features that will look somewhat similar to those found in a PAM solution:

  • Access: Connect remote users to infrastructure targets via Cloudflare’s global network.

  • Authentication: Eliminate the management of credentials for servers, containers, clusters, and databases and replace them with SSO, MFA, and device posture. 

  • Authorization: Use policy-based access control to determine who can access what target, when, and under what role. 

  • Auditing: Provide command logs and session recordings to allow administrators to audit and replay their developers’ interactions with the organization’s infrastructure.

At Cloudflare, we are big believers that unified experiences produce the best security outcomes, and because of that, we are natively rebuilding each BastionZero feature into Cloudflare’s ZTNA service. Today, we will cover the recently-released feature for short-lived SSH access.

Secure Shell (SSH) and its security risks

SSH (Secure Shell) is a protocol that is commonly used by developers or system administrators to secure the connections used to remotely administer and manage (usually Linux/Unix) servers. SSH access to a server often comes with elevated privileges, including the ability to delete or exfiltrate data or to install or remove applications on the server. 

Modern enterprises can have tens, hundreds, or even thousands of SSH targets. Servers accessible via SSH can be targeted in cryptojacking or proxyjacking attacks. Manually tracking, rotating, and validating SSH credentials that grant access is a chore that is often left undone, which creates risks that these long-lived credentials could be compromised. There’s nothing stopping users from copying SSH credentials and sharing them with other users or transferring them to unauthorized devices.

Although many organizations will gate access to their servers to users that are inside their corporate network, this is no longer enough to protect against modern attackers. Today, the principles of Zero Trust demand that an organization also tracks who exactly is accessing their servers with SSH, and what commands they are running on those servers once they have access. In fact, the elevated privileges that come along with SSH access mean that compliance frameworks like SOC2, ISO27001, FedRAMP and others have criteria that require monitoring who has access with SSH and what exactly they are doing with that access. 

Introducing SSH with Access for Infrastructure

We’ve introduced SSH with Access for Infrastructure to provide customers with granular control over privileged access to servers via SSH. The feature provides improved visibility into who accessed what service and what they did during their SSH session, while also eliminating the risk and overhead associated with managing SSH credentials. Specifically, this feature enables organizations to:

  • Eliminate security risk and overhead of managing SSH keys and instead use short-lived SSH certificates issued by a Cloudflare-managed certificate authority (CA).

  • Author fine-grained policy to govern who can SSH to your servers and through which SSH user(s) they can log in as.

  • Monitor infrastructure access with Access and SSH command logs, supporting regulatory compliance and providing visibility in case of security breach.

  • Avoid changing end-user workflows. SSH with Access for Infrastructure supports whatever native SSH clients end users happen to be using. 

SSH with Access for Infrastructure is supported through one of the most common deployment models of Cloudflare One customers. Users can connect using our device client (WARP), and targets are made accessible using Cloudflare Tunnel (cloudflared or the WARP connector). This architecture allows customers with existing Cloudflare One deployments to enable this feature with little to no effort. The only additional setup will be configuring your target server to accept a Cloudflare SSH certificate.


Cloudflare One already offers multiple ways to secure organizations’ SSH traffic through network controls. This new SSH with Access for Infrastructure aims to incorporate the strengths of those existing solutions together with additional controls to authorize ports, protocols, and specific users as well as a much improved deployment workflow and audit logging capabilities.

Eliminating SSH credentials using an SSH CA

How does Access for Infrastructure eliminate your SSH credentials? This is done by replacing SSH password and SSH keys with an SSH Certificate Authority (CA) that is managed by Cloudflare. Generally speaking, a CA’s job is to issue certificates that bind an entity to an entity’s public key. Cloudflare’s SSH CA has a secret key that is used to sign certificates that authorize access to a target (server) via SSH, and a public key that is used by the target (server) to cryptographically validate these certificates. The public key for the SSH CA can be obtained by querying the Cloudflare API. And the secret key for the SSH CA is kept secure by Cloudflare and never exposed to anyone. 

To use SSH with Access for Infrastructure to grant access via SSH to a set of targets (i.e. servers), you need to instruct those servers to trust the Cloudflare SSH CA. Those servers will then grant access via SSH whenever they are presented with an SSH certificate that is validly signed by the Cloudflare SSH CA.

The same Cloudflare SSH CA is used to support SSH access for all of your developers and engineers to all your target servers. This greatly simplifies key management. You no longer need to manage long-lived SSH keys and passwords for individual end users, because access to targets with SSH is granted via certificates that are dynamically issued by the Cloudflare SSH CA. And, because the Cloudflare SSH CA issued short-lived SSH certificates that expire after 3 minutes, you also don’t have to worry about creating or managing long-lived SSH credentials that could be stolen by attackers. 

The 3-minute time window on the SSH certificate only applies to the time window during which the user has to authenticate to the target server; it does not apply to the length of the SSH session, which can be arbitrarily longer than 3 minutes. This 3-minute window was chosen because it was short enough to reduce the risk of security compromise and long enough to ensure that we don’t miss the time window of the user’s authentication to the server, especially if the user is on a slow connection.

Centrally managing policies down to the specific Linux user

One of the problems with traditional SSH is that once a user has an SSH key or password installed on a server, they will have access to that server forever — unless an administrator somehow remembers to remove their SSH key or password from the server in question. This leads to privilege creep, where too many people have standing access to too many servers, creating a security risk if an SSH key or password is ever stolen or leaked.

Instead, SSH with Access for Infrastructure allows you to centrally write policies in the Cloudflare dashboard specifying exactly what (set of) users has access to what (set of) servers. Users may be authenticated by SSO, MFA, device posture, location, and more, which provides better security than just authenticating them via long-lived SSH keys or passwords that could be stolen by attackers.

Moreover, the SSH certificates issued by the Cloudflare CA include a field called ValidPrinciples which indicates the specific Linux user (e.g. root, read-only, ubuntu, ec2-user) that can be assumed by the SSH connection. As such, you can write policies that specify the (set of) Linux users that a given (set of) end users may access on a given (set of) servers, as shown in the figure below. This allows you to centrally control the privileges that a given end user has when accessing a given target server. (The one caveat here is that the server must also be pre-configured to already know about the specific Linux user (e.g. root) that is specified in the policies and presented in the SSH certificate. Cloudflare is NOT managing the Linux users on your Linux servers.)

As shown below, you could write a policy that says users in Canada, the UK, and Australia that are authenticated with MFA and face recognition can access the root and ec2-user Linux users on a given set of servers in AWS.


How does Cloudflare capture SSH command logs?

Cloudflare captures SSH command logs because we built an SSH proxy that intercepts the SSH connections. The SSH proxy establishes one SSH connection between itself and the end user’s SSH client, and another SSH connection between itself and the target (server). The SSH proxy can therefore inspect the SSH commands and log them. 

SSH commands are encrypted at rest using a public key that the customer uploads via the Cloudflare API. Cloudflare cannot read SSH command logs at rest, but they can be extracted (in encrypted form) from the Cloudflare API and decrypted by the customer (who holds the corresponding private key). Instructions for uploading the encryption public key are available in our developer documentation.


How the SSH interception works under the hood

How does generic SSH work?

To understand how Cloudflare’s SSH proxy works, we first must review how a generic SSH connection is established.

First off, SSH runs over TCP, so to establish an SSH connection, we first need to complete a TCP handshake. Then, once the TCP handshake is complete, an SSH key exchange is needed to establish an ephemeral symmetric key between the client and the server that will be used to encrypt and authenticate their SSH traffic. The SSH key exchange is based on the server public key, also known as the hostkey. If you’ve ever used SSH, you’ve probably seen this message — that is the SSH server telling your SSH client to trust this hostkey for all future SSH interactions. (This is also known as TOFU or Trust On First Use.)


Finally, the client needs to authenticate itself to the server. This can be done using SSH passwords, SSH keys, or SSH certificates (as described above). SSH also has a mode called none, which means that the client does NOT need to authenticate itself to the server at all.

So how does Cloudflare’s SSH proxy work? 


To understand this, we note that whenever you set up SSH with Access for Infrastructure in the Cloudflare dashboard, you first need to create the set of targets (i.e. servers) that you want to make accessible via SSH. Targets can be defined by IP address or hostname. You then create an Access for Infrastructure application that captures the TCP ports (e.g. port 22) that SSH runs over for those targets, and write policies for those SSH connections, as we already described above and in our developer documentation.

This setup allows Cloudflare to know the set of IP addresses and ports for which it must intercept SSH traffic. Thus, whenever Cloudflare sees a TCP handshake with an IP address and port that must be intercepted, it sends traffic for that TCP connection to the SSH proxy. 

The SSH proxy leverages the client’s already authenticated identity from the WARP client, and enforces the configured Access for Infrastructure policies against it. If the policies do not allow the identity to connect to the target under the requested Linux user (e.g. root), the SSH proxy will reject the connection and log an Access denied event to the Access logs. Otherwise, if policies do allow the identity to connect, the the SSH proxy will establish the following two SSH connections: 

  1. SSH connection from SSH proxy to target

  2. SSH connection from end user’s SSH client (via Cloudflare’s WARP client) to SSH proxy

Let’s take a look at each of these SSH connections, and the cryptographic material used to set them up. 

To establish the SSH connection from SSH proxy to the target, the SSH proxy acts as a client in the SSH key exchange between itself and the target server. The handshake uses the target server’s hostkey to establish an ephemeral symmetric key between the client and the server that will encrypt and authenticate their SSH traffic. Next, the SSH proxy must authenticate itself to the target server. This is done by presenting the server with a short-lived SSH certificate, issued by the Cloudflare SSH CA, for the specified Linux user that is requested for this connection as we already described above. Because the target server has been configured to trust the Cloudflare SSH CA, the target server will be able to successfully validate the certificate and the SSH connection will be established.

To establish the SSH connection from the end-user’s SSH client to SSH proxy, the SSH proxy acts as a server in the SSH key exchange between itself and the end-user’s SSH client. 

To do this, the SSH proxy needs to inform the end user’s SSH client about the hostkey that will be used to establish this connection. But what hostkey should be used? We cannot use the same hostkey used by the target server, because that hostkey is the public key that corresponds to a private key that is known only to the target server, and not known to the SSH proxy. So, Cloudflare’s SSH proxy needs to generate its own hostkey. We don’t want the end user to randomly see warnings like the one shown below, so the SSH proxy should provide the same hostkey each time the user wants to access a given target server. But, if something does change with the hostkey of the target server, we do want the warning below to be shown. 


To achieve the desired behavior, the SSH proxy generates a hostkey and its corresponding private key by hashing together (a) a fixed secret value valid that associated with the customer account, along with (b) the hostkey that was provided by this target server (in the connection from SSH proxy to target server). This part of the design ensures that the end user only needs to see the TOFU notification the very first time it connects to the target server via WARP, because the same hostkey is used for all future connections to that target. And, if the hostkey of the target server does change as a result of a Monster-In-The-Middle attack, the warning above will be shown to the user.

Finally, during the SSH key exchange handshake from WARP client to SSH proxy, the SSH proxy informs that end user’s native SSH client that it is using none for client authentication. This means that the SSH client does NOT need to authenticate itself to the server at all. This part of the design ensures that the user need not enter any SSH passwords or store any SSH keys in its SSH configuration in order to connect to the target server via WARP. Also, this does not compromise security, because the SSH proxy has already authenticated the end user via Cloudflare’s WARP client and thus does not need to use the native SSH client authentication in the native SSH client.

Put this all together, and we have accomplished our goal of having end users authenticate to target servers without any SSH keys or passwords, using Cloudflare’s SSH CA instead. Moreover, we also preserve the desired behaviors of the TOFU notifications and warnings built into native SSH clients!

All the keys

Before we wrap up, let’s review the cryptographic keys you need in order to deploy SSH with Access for Infrastructure. There are two keys:

  1. Public key of the SSH CA. The private key of the SSH CA is only known to Cloudflare and not shared with anyone. The public key of the SSH CA is obtained from the Cloudflare API and must be installed on all your target servers. The same public key is used for all of your targets. This public key does not need to be kept secret.

  2. Private key for SSH command log encryption. To obtain logs of SSH commands, you need to generate a public-private key pair, and upload the public key to Cloudflare. The public key will be used to encrypt your SSH commands logs at REST. You need to keep the private key secret, and you can use it to decrypt your SSH command logs. 

That’s it! No other keys, passwords, or credentials to manage!

Try it out today

At Cloudflare, we are committed to providing the most comprehensive solution for ZTNA, which now also includes privileged access to sensitive infrastructure like servers accessed over SSH.

Organizations can now treat SSH like any other Access application and enforce strong MFA, device context, and policy-based access prior to granting user access. This allows organizations to consolidate their infrastructure access policies into their broader SSE or SASE architecture.

You can try out Access for Infrastructure today by following these instructions in our developer documentation. Access for Infrastructure is currently available free to teams of under 50 users, and at no extra cost to existing pay-as-you-go and Contract plan customers through an Access or Zero Trust subscription. Expect to hear about a lot more features from us as we continue to natively rebuild BastionZero’s technology into Cloudflare’s Access for Infrastructure service!

Heeding the call to support Australia’s most at-risk entities

Post Syndicated from Carly Ramsey original https://blog.cloudflare.com/heeding-the-call-to-support-australias-most-at-risk-entities


When Australia unveiled its 2023-2030 Australian Cyber Security Strategy in November 2023, we enthusiastically announced Cloudflare’s support, especially for the call for the private sector to work together to protect Australia’s smaller, at-risk entities. Today, we are extremely pleased to announce that Cloudflare and the Critical Infrastructure – Information Sharing and Analysis Centre (CI-ISAC), a member-driven organization helping to defend Australia’s critical infrastructure from cyber attacks, are teaming up to protect some of Australia’s most at-risk organizations – General Practitioner (GP) clinics.

Cloudflare helps a broad range of organizations -– from multinational organizations, to entrepreneurs and small businesses, to nonprofits, humanitarian groups, and governments across the globe — to secure their employees, applications and networks. We support a multitude of organizations in Australia, including some of Australia’s largest banks and digital natives, with our world-leading security products and services.

When it comes to protecting entities at high risk of cyber attack who might not have significant resources, we at Cloudflare believe we have a lot to offer. Our mission is to help build a better Internet. A key part of that mission is democratizing cybersecurity – making a range of tools readily available for all, including small and medium enterprises (SMEs), non-profits, and individuals. We also offer our cyber protection products and services at no cost to certain at-risk organizations. One example of this is Australia’s Citizens of the Great Barrier Reef, which is a participant in Cloudflare’s Project Galileo. Through Project Galileo, they have access to our advanced cybersecurity tools and support, freeing them to focus on their mission.

CI-ISAC Australia is a not-for-profit organization with a mission to help build the collective defenses of Australia’s critical infrastructure to protect them from crippling cyberattacks. CI-ISAC facilitates sharing, aggregates sources, and analyzes cyber threat intelligence across multiple sectors, including healthcare.

Project Secure Health – protecting Australia’s General Practitioner (GP) clinics

Globally, the healthcare sector consistently reports the highest financial costs from cyber attacks. Sensitive patient data is a prime target for cybercriminals. Not surprisingly, Australia’s big and small healthcare organizations alike are facing crippling cyberattacks. GP clinics serve as the backbone of Australia’s community healthcare, but these small-but-essential entities typically face resource constraints that make it difficult for them to implement fundamental but costly cybersecurity measures, leaving Australian patient data exposed to cybercriminals.

The 2023-2030 Australia Cybersecurity Strategy is clear about the threat to smaller at-risk organizations and the vital role of the private sector in supporting these entities. We couldn’t agree more. Heeding their call to help make Australia more secure for all, we are extremely pleased to introduce Project Secure Health: Cloudflare and CI-ISAC’s combined cyber security support for Australia’s GP clinics. This program will enable Australia’s GP Clinics to counter a range of challenging cyber threats: data breaches, ransomware attacks, phishing scams, and insider threats.

CI-ISAC will provide GP clinics with membership in its organization for free and with no time limit, which will enable member GP clinics to proactively understand and respond to healthcare-specific cyber threats. Clinics will have access to CI-ISAC’s tailored threat intelligence products and services, informed by observations across Australia’s critical infrastructure sectors.

As members of CI-ISAC, GP clinics will also receive key Cloudflare services, for free and with no time limit: Cloudflare Gateway, and Cloudflare Access, our Zero Trust Network Access (ZTNA) service. Cloudflare Gateway helps protect GP clinics against Internet threats by preventing staff from accessing harmful and inappropriate Internet content, like ransomware or phishing sites. With Cloudflare Access, GP clinics can simply and effectively manage user access to sensitive patient data, thereby minimizing the risk of unauthorized users gaining access.

Cloudflare and CI-ISAC are ready to support

For GP Clinics interested in participating in Project Secure Health, please contact CI-ISAC at [email protected]. To be eligible for free CI-ISAC membership and Cloudflare ZTNA services, GP Clinics must have fewer than 50 staff members.

Cloudflare acquires BastionZero to extend Zero Trust access to IT infrastructure

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/cloudflare-acquires-bastionzero


We’re excited to announce that BastionZero, a Zero Trust infrastructure access platform, has joined Cloudflare. This acquisition extends our Zero Trust Network Access (ZTNA) flows with native access management for infrastructure like servers, Kubernetes clusters, and databases.

Security teams often prioritize application and Internet access because these are the primary vectors through which users interact with corporate resources and external threats infiltrate networks. Applications are typically the most visible and accessible part of an organization’s digital footprint, making them frequent targets for cyberattacks. Securing application access through methods like Single Sign-On (SSO) and Multi-Factor Authentication (MFA) can yield immediate and tangible improvements in user security.

However, infrastructure access is equally critical and many teams still rely on castle-and-moat style network controls and local resource permissions to protect infrastructure like servers, databases, Kubernetes clusters, and more. This is difficult and fraught with risk because the security controls are fragmented across hundreds or thousands of targets. Bad actors are increasingly focusing on targeting infrastructure resources as a way to take down huge swaths of applications at once or steal sensitive data. We are excited to extend Cloudflare One’s Zero Trust Network Access to natively protect infrastructure with user- and device-based policies along with multi-factor authentication.

Application vs. infrastructure access

Application access typically involves interacting with web-based or client-server applications. These applications often support modern authentication mechanisms such as Single Sign-On (SSO), which streamline user authentication and enhance security. SSO integrates with identity providers (IdPs) to offer a seamless and secure login experience, reducing the risk of password fatigue and credential theft.

Infrastructure access, on the other hand, encompasses a broader and more diverse range of systems, including servers, databases, and network devices. These systems often rely on protocols such as SSH (Secure Shell), RDP (Remote Desktop Protocol), and Kubectl (Kubernetes) for administrative access. The nature of these protocols introduces additional complexities that make securing infrastructure access more challenging.

  • SSH Authentication: SSH is a fundamental tool for accessing Linux and Unix-based systems. SSH access is typically facilitated through public key authentication, through which a user is issued a public/private key pair that a target system is configured to accept. These keys must be distributed to trusted users, rotated frequently, and monitored for any leakage. If a key is accidentally leaked, it can grant a bad actor direct control over the SSH-accessible resource.
  • RDP Authentication: RDP is widely used for remote access to Windows-based systems. While RDP supports various authentication methods, including password-based and certificate-based authentication, it is often targeted by brute force and credential stuffing attacks.
  • Kubernetes Authentication: Kubernetes, as a container orchestration platform, introduces its own set of authentication challenges. Access to Kubernetes clusters involves managing roles, service accounts, and kubeconfig files along with user certificates.

Infrastructure access with Cloudflare One today

Cloudflare One facilitates Zero Trust Network Access (ZTNA) for infrastructure resources with an approach superior to traditional VPNs. An administrator can define a set of identity, device, and network-aware policies that dictate if a user can access a specific IP address, hostname, and/or port combination. This allows you to create policies like “Only users in the identity provider group ‘developers’ can access resources over port 22 (default SSH port) in our corporate network,” which is already much finer control than a VPN with basic firewall policies would allow.

However, this approach still has limitations, as it relies on a set of assumptions about how corporate infrastructure is provisioned and managed. If an infrastructure resource is configured outside of the assumed network structure, e.g. SSH over a non-standard port is allowed, all network-level controls may be bypassed. This leaves only the native authentication protections of the specific protocol protecting that resource and is often how leaked SSH keys or database credentials can lead to a wider system outage or breach.

Many organizations will leverage more complex network structures like a bastion host model or complex Privileged Access Management (PAM) solutions as an added defense-in-depth strategy. However, this leads to significantly more cost and management overhead for IT security teams and sometimes complicates challenges related to least-privileged access. Tools like bastion hosts or PAM solutions end up eroding least-privilege over time because policies expand, change, or drift from a company’s security stance. This leads to users incorrectly retaining access to sensitive infrastructure.

How BastionZero fits in

While our goal for years has been to help organizations of any size replace their VPNs as simply and quickly as possible, BastionZero expands the scope of Cloudflare’s VPN replacement solution beyond apps and networks to provide the same level of simplicity for extending Zero Trust controls to infrastructure resources. This helps security teams centralize the management of even more of their hybrid IT environment, while using standard Zero Trust practices to keep DevOps teams productive and secure. Together, Cloudflare and BastionZero can help organizations replace not only VPNs but also bastion hosts; SSH, Kubernetes, or database key management systems; and redundant PAM solutions.

BastionZero provides native integration to major infrastructure access protocols and targets like SSH, RDP, Kubernetes, database servers, and more to ensure that a target resource is configured to accept connections for that specific user, instead of relying on network level controls. This allows administrators to think in terms of resources and targets, not IP addresses and ports. Additionally, BastionZero leverages OpenPubKey, an open source library that uses two forms of authentication to generate an OpenID Connect (OIDC) token, which avoids single point of failure risks inherent to a standalone Identity Provider.

BastionZero will add the following capabilities to Cloudflare’s SASE platform:

  • The elimination of long-lived keys/credentials through frictionless infrastructure privileged access management (PAM) capabilities that modernize credential management (e.g., SSH keys, kubeconfig files, database passwords) through a new ephemeral, decentralized approach.
  • A DevOps-based approach for securing SSH connections to support least privilege access that records sessions and logs every command for better visibility to support compliance requirements. Teams can operate in terms of auto-discovered targets, not IP addresses or networks, as they define just-in-time access policies and automate workflows.
  • Clientless RDP to support access to desktop environments without the overhead and hassle of installing a client on a user’s device.

What’s next for BastionZero

The BastionZero team will be focused on integrating their infrastructure access controls directly into Cloudflare One. During the third and fourth quarters of this year, we will be announcing a number of new features to facilitate Zero Trust infrastructure access via Cloudflare One. All functionality delivered this year will be included in the Cloudflare One free tier for organizations less than 50 users. We believe that everyone should have access to world-class security controls.

We are looking for early beta testers and teams to provide feedback about what they would like to see with respect to infrastructure access. If you are interested in learning more, please sign up here.

Eliminate VPN vulnerabilities with Cloudflare One

Post Syndicated from Dan Hall original https://blog.cloudflare.com/eliminate-vpn-vulnerabilities-with-cloudflare-one


On January 19, 2024, the Cybersecurity & Infrastructure Security Agency (CISA) issued Emergency Directive 24-01: Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities. CISA has the authority to issue emergency directives in response to a known or reasonably suspected information security threat, vulnerability, or incident. U.S. Federal agencies are required to comply with these directives.

Federal agencies were directed to apply a mitigation against two recently discovered vulnerabilities; the mitigation was to be applied within three days. Further monitoring by CISA revealed that threat actors were continuing to exploit the vulnerabilities and had developed some workarounds to earlier mitigations and detection methods. On January 31, CISA issued Supplemental Direction V1 to the Emergency Directive instructing agencies to immediately disconnect all instances of Ivanti Connect Secure and Ivanti Policy Secure products from agency networks and perform several actions before bringing the products back into service.

This blog post will explore the threat actor’s tactics, discuss the high-value nature of the targeted products, and show how Cloudflare’s Secure Access Service Edge (SASE) platform protects against such threats.

As a side note and showing the value of layered protections, Cloudflare’s WAF had proactively detected the Ivanti zero-day vulnerabilities and deployed emergency rules to protect Cloudflare customers.

Threat Actor Tactics

Forensic investigations (see the Volexity blog for an excellent write-up) indicate that the attacks began as early as December 2023. Piecing together the evidence shows that the threat actors chained two previously unknown vulnerabilities together to gain access to the Connect Secure and Policy Secure appliances and achieve unauthenticated remote code execution (RCE).

CVE-2023-46805 is an authentication bypass vulnerability in the products’ web components that allows a remote attacker to bypass control checks and gain access to restricted resources. CVE-2024-21887 is a command injection vulnerability in the products’ web components that allows an authenticated administrator to execute arbitrary commands on the appliance and send specially crafted requests. The remote attacker was able to bypass authentication and be seen as an “authenticated” administrator, and then take advantage of the ability to execute arbitrary commands on the appliance.

By exploiting these vulnerabilities, the threat actor had near total control of the appliance. Among other things, the attacker was able to:

  • Harvest credentials from users logging into the VPN service
  • Use these credentials to log into protected systems in search of even more credentials
  • Modify files to enable remote code execution
  • Deploy web shells to a number of web servers
  • Reverse tunnel from the appliance back to their command-and-control server (C2)
  • Avoid detection by disabling logging and clearing existing logs

Little Appliance, Big Risk

This is a serious incident that is exposing customers to significant risk. CISA is justified in issuing their directive, and Ivanti is working hard to mitigate the threat and develop patches for the software on their appliances. But it also serves as another indictment of the legacy “castle-and-moat” security paradigm. In that paradigm, remote users were outside the castle while protected applications and resources remained inside. The moat, consisting of a layer of security appliances, separated the two. The moat, in this case the Ivanti appliance, was responsible for authenticating and authorizing users, and then connecting them to protected applications and resources. Attackers and other bad actors were blocked at the moat.

This incident shows us what happens when a bad actor is able to take control of the moat itself, and the challenges customers face to recover control. Two typical characteristics of vendor-supplied appliances and the legacy security strategy highlight the risks:

  • Administrators have access to the internals of the appliance
  • Authenticated users indiscriminately have access to a wide range of applications and resources on the corporate network, increasing the risk of bad actor lateral movement

A better way: Cloudflare’s SASE platform

Cloudflare One is Cloudflare’s SSE and single-vendor SASE platform. While Cloudflare One spans broadly across security and networking services (and you can read about the latest additions here), I want to focus on the two points noted above.

First, Cloudflare One employs the principles of Zero Trust, including the principle of least privilege. As such, users that authenticate successfully only have access to the resources and applications necessary for their role. This principle also helps in the event of a compromised user account as the bad actor does not have indiscriminate network-level access. Rather, least privilege limits the range of lateral movement that a bad actor has, effectively reducing the blast radius.

Second, while customer administrators need to have access to configure their services and policies, Cloudflare One does not provide any external access to the system internals of Cloudflare’s platform. Without that access, a bad actor would not be able to launch the types of attacks executed when they had access to the internals of the Ivanti appliance.  

It’s time to eliminate the legacy VPN

If your organization is impacted by the CISA directive, or you are just ready to modernize and want to augment or replace your current VPN solution, Cloudflare is here to help. Cloudflare’s Zero Trust Network Access (ZTNA) service, part of the Cloudflare One platform, is the fastest and safest way to connect any user to any application.

Contact us to get immediate onboarding help or to schedule an architecture workshop to help you augment or replace your Ivanti (or any) VPN solution.
Not quite ready for a live conversation? Read our learning path article on how to replace your VPN with Cloudflare or our SASE reference architecture for a view of how all of our SASE services and on-ramps work together.

Zero Trust WARP: tunneling with a MASQUE

Post Syndicated from Dan Hall original https://blog.cloudflare.com/zero-trust-warp-with-a-masque


Slipping on the MASQUE

In June 2023, we told you that we were building a new protocol, MASQUE, into WARP. MASQUE is a fascinating protocol that extends the capabilities of HTTP/3 and leverages the unique properties of the QUIC transport protocol to efficiently proxy IP and UDP traffic without sacrificing performance or privacy

At the same time, we’ve seen a rising demand from Zero Trust customers for features and solutions that only MASQUE can deliver. All customers want WARP traffic to look like HTTPS to avoid detection and blocking by firewalls, while a significant number of customers also require FIPS-compliant encryption. We have something good here, and it’s been proven elsewhere (more on that below), so we are building MASQUE into Zero Trust WARP and will be making it available to all of our Zero Trust customers — at WARP speed!

This blog post highlights some of the key benefits our Cloudflare One customers will realize with MASQUE.

Before the MASQUE

Cloudflare is on a mission to help build a better Internet. And it is a journey we’ve been on with our device client and WARP for almost five years. The precursor to WARP was the 2018 launch of 1.1.1.1, the Internet’s fastest, privacy-first consumer DNS service. WARP was introduced in 2019 with the announcement of the 1.1.1.1 service with WARP, a high performance and secure consumer DNS and VPN solution. Then in 2020, we introduced Cloudflare’s Zero Trust platform and the Zero Trust version of WARP to help any IT organization secure their environment, featuring a suite of tools we first built to protect our own IT systems. Zero Trust WARP with MASQUE is the next step in our journey.

The current state of WireGuard

WireGuard was the perfect choice for the 1.1.1.1 with WARP service in 2019. WireGuard is fast, simple, and secure. It was exactly what we needed at the time to guarantee our users’ privacy, and it has met all of our expectations. If we went back in time to do it all over again, we would make the same choice.

But the other side of the simplicity coin is a certain rigidity. We find ourselves wanting to extend WireGuard to deliver more capabilities to our Zero Trust customers, but WireGuard is not easily extended. Capabilities such as better session management, advanced congestion control, or simply the ability to use FIPS-compliant cipher suites are not options within WireGuard; these capabilities would have to be added on as proprietary extensions, if it was even possible to do so.

Plus, while WireGuard is popular in VPN solutions, it is not standards-based, and therefore not treated like a first class citizen in the world of the Internet, where non-standard traffic can be blocked, sometimes intentionally, sometimes not. WireGuard uses a non-standard port, port 51820, by default. Zero Trust WARP changes this to use port 2408 for the WireGuard tunnel, but it’s still a non-standard port. For our customers who control their own firewalls, this is not an issue; they simply allow that traffic. But many of the large number of public Wi-Fi locations, or the approximately 7,000 ISPs in the world, don’t know anything about WireGuard and block these ports. We’ve also faced situations where the ISP does know what WireGuard is and blocks it intentionally.

This can play havoc for roaming Zero Trust WARP users at their local coffee shop, in hotels, on planes, or other places where there are captive portals or public Wi-Fi access, and even sometimes with their local ISP. The user is expecting reliable access with Zero Trust WARP, and is frustrated when their device is blocked from connecting to Cloudflare’s global network.

Now we have another proven technology — MASQUE — which uses and extends HTTP/3 and QUIC. Let’s do a quick review of these to better understand why Cloudflare believes MASQUE is the future.

Unpacking the acronyms

HTTP/3 and QUIC are among the most recent advancements in the evolution of the Internet, enabling faster, more reliable, and more secure connections to endpoints like websites and APIs. Cloudflare worked closely with industry peers through the Internet Engineering Task Force on the development of RFC 9000 for QUIC and RFC 9114 for HTTP/3. The technical background on the basic benefits of HTTP/3 and QUIC are reviewed in our 2019 blog post where we announced QUIC and HTTP/3 availability on Cloudflare’s global network.

Most relevant for Zero Trust WARP, QUIC delivers better performance on low-latency or high packet loss networks thanks to packet coalescing and multiplexing. QUIC packets in separate contexts during the handshake can be coalesced into the same UDP datagram, thus reducing the number of receive and system interrupts. With multiplexing, QUIC can carry multiple HTTP sessions within the same UDP connection. Zero Trust WARP also benefits from QUIC’s high level of privacy, with TLS 1.3 designed into the protocol.

MASQUE unlocks QUIC’s potential for proxying by providing the application layer building blocks to support efficient tunneling of TCP and UDP traffic. In Zero Trust WARP, MASQUE will be used to establish a tunnel over HTTP/3, delivering the same capability as WireGuard tunneling does today. In the future, we’ll be in position to add more value using MASQUE, leveraging Cloudflare’s ongoing participation in the MASQUE Working Group. This blog post is a good read for those interested in digging deeper into MASQUE.

OK, so Cloudflare is going to use MASQUE for WARP. What does that mean to you, the Zero Trust customer?

Proven reliability at scale

Cloudflare’s network today spans more than 310 cities in over 120 countries, and interconnects with over 13,000 networks globally. HTTP/3 and QUIC were introduced to the Cloudflare network in 2019, the HTTP/3 standard was finalized in 2022, and represented about 30% of all HTTP traffic on our network in 2023.

We are also using MASQUE for iCloud Private Relay and other Privacy Proxy partners. The services that power these partnerships, from our Rust-based proxy framework to our open source QUIC implementation, are already deployed globally in our network and have proven to be fast, resilient, and reliable.

Cloudflare is already operating MASQUE, HTTP/3, and QUIC reliably at scale. So we want you, our Zero Trust WARP users and Cloudflare One customers, to benefit from that same reliability and scale.

Connect from anywhere

Employees need to be able to connect from anywhere that has an Internet connection. But that can be a challenge as many security engineers will configure firewalls and other networking devices to block all ports by default, and only open the most well-known and common ports. As we pointed out earlier, this can be frustrating for the roaming Zero Trust WARP user.

We want to fix that for our users, and remove that frustration. HTTP/3 and QUIC deliver the perfect solution. QUIC is carried on top of UDP (protocol number 17), while HTTP/3 uses port 443 for encrypted traffic. Both of these are well known, widely used, and are very unlikely to be blocked.

We want our Zero Trust WARP users to reliably connect wherever they might be.

Compliant cipher suites

MASQUE leverages TLS 1.3 with QUIC, which provides a number of cipher suite choices. WireGuard also uses standard cipher suites. But some standards are more, let’s say, standard than others.

NIST, the National Institute of Standards and Technology and part of the US Department of Commerce, does a tremendous amount of work across the technology landscape. Of interest to us is the NIST research into network security that results in FIPS 140-2 and similar publications. NIST studies individual cipher suites and publishes lists of those they recommend for use, recommendations that become requirements for US Government entities. Many other customers, both government and commercial, use these same recommendations as requirements.

Our first MASQUE implementation for Zero Trust WARP will use TLS 1.3 and FIPS compliant cipher suites.

How can I get Zero Trust WARP with MASQUE?

Cloudflare engineers are hard at work implementing MASQUE for the mobile apps, the desktop clients, and the Cloudflare network. Progress has been good, and we will open this up for beta testing early in the second quarter of 2024 for Cloudflare One customers. Your account team will be reaching out with participation details.

Continuing the journey with Zero Trust WARP

Cloudflare launched WARP five years ago, and we’ve come a long way since. This introduction of MASQUE to Zero Trust WARP is a big step, one that will immediately deliver the benefits noted above. But there will be more — we believe MASQUE opens up new opportunities to leverage the capabilities of QUIC and HTTP/3 to build innovative Zero Trust solutions. And we’re also continuing to work on other new capabilities for our Zero Trust customers.
Cloudflare is committed to continuing our mission to help build a better Internet, one that is more private and secure, scalable, reliable, and fast. And if you would like to join us in this exciting journey, check out our open positions.

Introducing behavior-based user risk scoring in Cloudflare One

Post Syndicated from Noelle Kagan original https://blog.cloudflare.com/cf1-user-risk-score


Cloudflare One, our secure access service edge (SASE) platform, is introducing new capabilities to detect risk based on user behavior so that you can improve security posture across your organization.

Traditionally, security and IT teams spend a lot of time, labor, and money analyzing log data to track how risk is changing within their business and to stay on top of threats. Sifting through such large volumes of data – the majority of which may well be benign user activity – can feel like finding a needle in a haystack.

Cloudflare’s approach simplifies this process with user risk scoring. With AI/machine learning techniques, we analyze the real-time telemetry of user activities and behaviors that pass through our network to identify abnormal behavior and potential indicators of compromises that could lead to danger for your organization, so your security teams can lock down suspicious activity and adapt your security posture in the face of changing risk factors and sophisticated threats.

User risk scoring

The concept of trust in cybersecurity has evolved dramatically. The old model of “trust but verify” has given way to a Zero Trust approach, where trust is never assumed and verification is continuous, as each network request is scrutinized. This form of continuous evaluation enables administrators to grant access based not just on the contents of a request and its metadata, but on its context — such as whether the user typically logs in at that time or location.

Previously, this kind of contextual risk assessment was time-consuming and required expertise to parse through log data. Now, we’re excited to introduce Zero Trust user risk scoring which does this automatically, allowing administrators to specify behavioral rules — like monitoring for anomalous “impossible travel” and custom Data Loss Prevention (DLP) triggers, and use these to generate dynamic user risk scores.

Zero Trust user risk scoring detects user activity and behaviors that could introduce risk to your organizations, systems, and data and assigns a score of Low, Medium, or High to the user involved. This approach is sometimes referred to as user and entity behavior analytics (UEBA) and enables teams to detect and remediate possible account compromise, company policy violations, and other risky activity.

How risk scoring works and detecting user risk

User risk scoring is built to examine behaviors. Behaviors are actions taken or completed by a user and observed by Cloudflare One, our SASE platform that helps organizations implement Zero Trust.

Once tracking for a particular behavior is enabled, the Zero Trust risk scoring engine immediately starts to review existing logs generated within your Zero Trust account. Then, after a user in your account performs a behavior that matches one of the enabled risk behaviors based on observed log data, Cloudflare assigns a risk score — Low, Medium, or High — to the user who performed the behavior.

Behaviors are built using log data from within your Cloudflare account. No additional user data is being collected, tracked or stored beyond what is already available in the existing Zero Trust logs (which adhere to the log retention timeframes).

A popular priority amongst security and insider threat teams is detecting when a user performs so-called “impossible travel”. Impossible travel, available as a predefined risk behavior today, is when a user completes a login from two different locations that the user could not have traveled to in that period of time. For example, if Alice is in Seattle and logs into her organization’s finance application that is protected by Cloudflare Access and only a few minutes later is seen logging into her organization’s business suite from Sydney, Australia, impossible travel would be triggered and Alice would be assigned a risk level of High.

For users that are observed performing multiple risk behaviors, they will be assigned the highest-level risk behavior they’ve triggered. This real-time risk assessment empowers your security teams to act swiftly and decisively.

Zero Trust user risk scoring detecting impossible travel and flagging a user as high risk

Enabling predefined risk behaviors

Behaviors can be enabled and disabled at any time, but are disabled by default. Therefore, users will not be assigned risk scores until you have decided what is considered a risk to your organization and how urgent that risk is.

To start detecting a given risk behavior, an administrator must first ensure the behavior requirements are met (for instance, to detect whether a user has triggered a high number of DLP policies, you’ll need to first set up a DLP profile). From there, simply enable the behavior in the Zero Trust dashboard.

After a behavior has been enabled, Cloudflare will start analyzing behaviors to flag users with the corresponding risk when detected. The risk level of any behavior can be changed by an administrator. You have the freedom to enable behaviors that are relevant to your security posture as well as adjust the default risk score (Low, Medium, or High) from an out-of-the-box assignment.

And for security administrators who have investigated a user and need to clear a user’s risk score, simply go to Risk score > User risk scoring, choose the appropriate user, and select ‘Reset user risk’ followed by ‘Confirm.’ Once a user’s risk score is reset, they disappear from the risk table — until or unless they trigger another risk behavior.

Zero Trust user risk scoring behaviors can be enabled in seconds

How do I get started?

User risk scoring and DLP are part of Cloudflare One, which converges Zero Trust security and network connectivity services on one unified platform and global control plane.

To get access via Cloudflare One, reach out for a consultation, or contact your account manager.

Wildcard and multi-hostname support in Cloudflare Access

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/access-wildcard-and-multi-hostname/

Wildcard and multi-hostname support in Cloudflare Access

Wildcard and multi-hostname support in Cloudflare Access

We are thrilled to announce the full support of wildcard and multi-hostname application definitions in Cloudflare Access. Until now, Access had limitations that restricted it to a single hostname or a limited set of wildcards. Before diving into these new features let’s review Cloudflare Access and its previous limitations around application definition.

Access and hostnames

Cloudflare Access is the gateway to applications, enforcing security policies based on identity, location, network, and device health. Previously, Access applications were defined as a single hostname. A hostname is a unique identifier assigned to a device connected to the internet, commonly used to identify a website, application, or server. For instance, “www.example.com” is a hostname.

Upon successful completion of the security checks, a user is granted access to the protected hostname via a cookie in their browser, in the form of a JSON Web Token (JWT). This cookie’s session lasts for a specific period of time defined by the administrators and any request made to the hostname must have this cookie present.

However, a single hostname application definition was not sufficient in certain situations, particularly for organizations with Single Page Applications and/or hundreds of identical hostnames.

Many Single Page Applications have two separate hostnames – one for the front-end user experience and the other for receiving API requests (e.g., app.example.com and api.example.com). This created a problem for Access customers because the front-end service could no longer communicate with the API as they did not share a session, leading to Access blocking the requests. Developers had to use different custom approaches to issue or share the Access JWT between different hostnames.

In many instances, organizations also deploy applications using a consistent naming convention, such as example.service123.example.com, especially for automatically provisioned applications. These applications often have the same set of security requirements. Previously, an Access administrator had to create a unique Access application per unique hostname, even if the services were functionally identical. This resulted in hundreds or thousands of Access applications needing to be created.

We aimed to make things easier for security teams as easier configuration means a more coherent security architecture and ultimately more secure applications.

We introduced two significant changes to Cloudflare Access: Multi-Hostname Applications and Wildcard Support.

Multi-Hostname Applications

Multi-Hostname Applications allow teams to protect multiple subdomains with a single Access app, simplifying the process and reducing the need for multiple apps.

Wildcard and multi-hostname support in Cloudflare Access

Access also takes care of JWT cookie issuance across all hostnames associated with a given application. This means that a front-end and API service on two different hostnames can communicate securely without any additional software changes.

Wildcards

A wildcard is a special character, in this case *, defines a specific application pattern to match instead of explicitly having to define each unique application. Access applications can now be defined using a wildcard anywhere in the subdomain or path of a hostname. This allows an administrator to protect hundreds of applications with a single application policy.

Wildcard and multi-hostname support in Cloudflare Access

In a scenario where an application requires additional security controls, Access is configured such that the most specific hostname definition wins (e.g., test.example.com will take precedence over *.example.com).

Give it a try!

Wildcard Applications are now available in open beta on the Cloudflare One Dashboard. Multi Hostname support will enter an open beta in the coming weeks. For more information, please see our product documentation about Multi-hostname applications and wildcards.

Introducing custom pages for Cloudflare Access

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/access-custom-pages/

Introducing custom pages for Cloudflare Access

Introducing custom pages for Cloudflare Access

Over 10,000 organizations rely on Cloudflare Access to connect their employees, partners, and contractors to the applications they need. From small teams on our free plan to some of the world’s largest enterprises, Cloudflare Access is the Zero Trust front door to how they work together. As more users start their day with Cloudflare Access, we’re excited to announce new options to customize how those users experience our industry-leading Zero Trust solution. We’re excited to announce customizable Cloudflare Access pages including login, blocks and the application launcher.

Where does Cloudflare Access fit in a user’s workflow today?

Most teams we work with start their Zero Trust journey by replacing their existing virtual private network (VPN) with Cloudflare Access. The reasons vary. For some teams, their existing VPN allows too much trust by default and Access allows them to quickly build segmentation based on identity, device posture, and other factors. Other organizations deploy Cloudflare Access because they are exhausted from trying to maintain their VPN and dealing with end user complaints.

When those administrators begin setting up Cloudflare Access, they connect the resources they need to protect to Cloudflare’s network. They can deploy a Cloudflare Tunnel to create a secure, outbound-only, connection to Cloudflare, rely on our existing DNS infrastructure, or even force SaaS application logins through our network. Administrators can then layer on granular Zero Trust rules to determine who can reach a given resource.

To the end user, Cloudflare Access is just a security guard checking for identity, device posture, or other signals at every door. In most cases they should never need to think about us. Instead, they just enjoy a much faster experience with less hassle. When they attempt to reach an application or service, we check each and every request and connection for proof that they should be allowed.

When they do notice Cloudflare Access, they interact with screens that help them make a decision about what they need. In these cases we don’t just want to be a silent security guard – we want to be a helpful tour guide.

Introducing custom pages for Cloudflare Access

Cloudflare Access supports the ability for administrators to configure multiple identity providers simultaneously. Customers love this capability when they work with contractors or acquired teams. We can also configure this only for certain applications. When users arrive, though, we need to know which direction to send them for their initial authentication. We present this selection screen, along with guiding text provided by the administrator, to the user.

Introducing custom pages for Cloudflare Access

When teams move their applications behind Cloudflare Access, we become the front door to how they work. We use that position to present the user with all of the applications they can reach in a portal that allows them to click on any tile to launch the application.

Introducing custom pages for Cloudflare Access

In some cases, the user lacks sufficient permissions to reach the destination. Even though they are being blocked we still want to reduce confusion. Instead of just presenting a generic browser error or dropping a connection, we display a block page.

Why do these need to change?

More and more large enterprises are starting to adopt a Zero Trust VPN replacement and they’re selecting Cloudflare to do so. Unlike small teams that can send a short Slack message about an upcoming change to their employee workflow, some of the CIOs and CSOs that deploy Access need to anticipate questions and curiosity from tens of thousands of employees and contractors.

Those users do not know what Cloudflare is and we don’t need them to. Instead, we just want to securely connect them to the tools they need. To solve that, we need to give IT administrators more space to communicate and we need to get our branding out of the way.

What will I be able to customize?

Following the release of Access page customization, administrators will be able to customize: the login screen, access denied errors and the Access Application Launcher.

What’s next?

We are building page customization in Cloudflare Access following the existing template our reverse proxy customers can use to modify pages presented to end users. We’re excited to bring that standard experience to these workflows as well.

Even though we’re building on that pattern, we still want your feedback. Ahead of a closed beta we are looking for customers who want to provide input as we fine tune this new configuration option. Interested in helping shape this work? Let us know here.

Using Cloudflare Access with CNI

Post Syndicated from David Tuber original https://blog.cloudflare.com/access-aegis-cni/

Using Cloudflare Access with CNI

Using Cloudflare Access with CNI

We are thrilled to introduce an innovative new approach to secure hosted applications via Cloudflare Access without the need for any installed software or custom code on your application server. But before we dive into how this is possible, let’s review why Access previously required installed software or custom code on your application server.

Protecting an application with Access

Traditionally, companies used a Virtual Private Network (VPN) to access a hosted application, where all they had to do was configure an IP allowlist rule for the VPN. However, this is a major security threat because anyone on the VPN can access the application, including unauthorized users or attackers.

We built Cloudflare Access to replace VPNs and provide the option to enforce Zero Trust policies in hosted applications. Access allows you to verify a user’s identity before they even reach the application. By acting as a proxy in front of your application’s hostname (e.g. app.example.com), Cloudflare enables strong verification techniques such as identity, device posture, hardkey MFA, and more. All without having to directly add SSO or Authentication logic directly into your applications.

However, since Access enforces at a hostname level, there is still a potential for bypass – the origin server IP address. This means that if someone knows your origin server IP address, they can bypass Access and directly interact with the target application. Seems scary, right? Luckily, there are proven solutions to prevent an origin IP attack.

Traditionally, organizations use two approaches to prevent an Origin IP bypass: Cloudflare Tunnel and JSON Web Token (JWT) Validation.

Cloudflare Tunnel

Cloudflare Tunnel creates a secure, outbound-only tunnel from your origin server to Cloudflare, with no origin IP address. This means that the only inbound traffic to your origin is coming from Cloudflare. However, it does require a daemon to be installed in your origin server’s network.

JWT Validation

JWT validation, on the other hand, prevents requests coming from unauthenticated sources by issuing a JWT when a user successfully authenticates. Application software can then be modified to check any inbound HTTP request for the Access JWT. The Access JWT uses signature-based verification to ensure that it cannot be easily spoofed by malicious users. However, modifying the logic of legacy hosted applications can be cumbersome or even impossible, making JWT validation a limited option for some.

Protecting an application without installed or custom software

And now, the exciting news – our new approach to protect Access applications from bypass without any installed software or code modifications! We achieve this using Cloud Network Interconnect (CNI) and a new Cloudflare product called Aegis.

In this blog, we’ll explore the benefits of using Access, CNI, and Aegis together to protect and optimize your applications. This offers a better way to securely connect your on-premise or cloud infrastructure to the Cloudflare network, as well as manage access to your applications and resources. All without having to install additional software.

Cloudflare Access

Cloudflare Access is a cloud-based identity and access management solution that allows users to secure access to their applications and resources. With Access, users can easily set up single sign-on (SSO) and multi-factor authentication (MFA) to protect against unauthorized access.

Many companies use Access today to protect their applications. However, since Access is based on an application’s hostname, there is still a possibility that security controls are bypassed by going straight to an application’s IP address. The solution to this is using Cloudflare Tunnels and JWT validation, to ensure that any request to the application server is legitimate and coming directly from Cloudflare.

Both Cloudflare Tunnels and JWT validation require additional software (e.g. cloudflared) or code customization in the application itself. This takes time and requires ongoing monitoring and maintenance.

Cloudflare Network Interconnect

Cloudflare Network Interconnect (CNI) enables users to securely connect their on-premises or cloud infrastructure to the Cloudflare network. Until recently, direct network connections were a cumbersome and manual process. Cloud CNI allows users to manage their own direct connections of their infrastructure and Cloudflare.

Cloudflare peers with over 11,500 networks directly and is located in over 285 cities which means there are many opportunities for direct connections with a company’s own private network. This can massively reduce latency of requests between an application server and Cloudflare, leading to a better application user experience.

Aegis

Cloudflare Aegis allows a customer to define a reliable IP address for traffic from Cloudflare to their own infrastructure. With Aegis it is assured that the assigned IP address is coming only from Cloudflare and for traffic associated with a specific account. This means that a company can configure their origin applications to verify all inbound requests are coming from the known IP. You can read more about Aegis here.

Access + CNI and Aegis

With CNI and Aegis, the only configuration required is an allowlist rule based on the inbound IP address. Cloudflare takes care of the rest and ensures that all requests are verified by Access (and other security products like DDoS and Web Application Firewall). All without requiring software or application code modification!

This is a different approach from traditional IP allowlists for VPNs because you can still enforce Zero Trust policies on the inbound request. Plus, Cloudflare has logic in place to ensure that the Aegis IP address can only be used by Cloudflare services.

Hosting your own infrastructure and applications can be a powerful way to have complete control and customization over your online presence. However, one of the challenges of hosting your own infrastructure is providing secure access to your applications and resources.

Traditionally, users have relied on virtual private networks (VPNs) or private circuits to provide secure access to their applications. While these solutions can be effective, they can also be complex to set up and maintain, and may not offer the same level of security and performance as newer solutions.

How it works

An application can be secured behind Access if its hostname is configured in Cloudflare. That hostname can be pointed to either a Cloudflare Tunnel, Load Balancer or direct IP Address. An application can then be configured to enforce specific security policies like identity provider group, hard key MFA, device posture and more.

Using Cloudflare Access with CNI

However, the network path that the application takes can be different and Cloudflare Network Interconnect allows for a completely private path from Cloudflare to your application. For example, Cloudflare Tunnel implicitly assumes that the network path between Cloudflare and your application is using the public Internet. Cloudflare Tunnel encrypts your traffic over the public Internet and ensures that your connection to Cloudflare is secure. But the public Internet is still a concern for a lot of people, who don’t want to harden their service to the public Internet at all.

Using Cloudflare Access with CNI

What if you implicitly knew that your connection was secure because nobody else was using it? That’s what Cloudflare Network Interconnect allows you to guarantee: private, performant connectivity back to Cloudflare.

By configuring Access and CNI together, you get protected application access over a private link. Cloudflare Aegis provides a dedicated IP that allows you to apply network-level firewall policies to ensure that your solution is completely airgapped: no one can access your application but Cloudflare-protected Access calls that come from their own dedicated IP address.

Using Cloudflare Access with CNI

Even if somebody could access your application over the CNI, they would get blocked by your firewall because they didn’t go through Access. This provides security at Layer 7 and Layer 3: at the application and the network.

Getting started

Access, Cloud CNI and Aegis are generally available to all Enterprise customers. If you would like to learn more about protecting and accelerating your private applications, please reach out to your account team for more information and how to enable your account.

Announcing SCIM support for Cloudflare Access & Gateway

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/access-and-gateway-with-scim/

Announcing SCIM support for Cloudflare Access & Gateway

Announcing SCIM support for Cloudflare Access & Gateway

Today, we’re excited to announce that Cloudflare Access and Gateway now support the System for Cross-domain Identity Management (SCIM) protocol. Before we dive into what this means, let’s take a step back and review what SCIM, Access, and Gateway are.

SCIM is a protocol that enables organizations to manage user identities and access to resources across multiple systems and domains. It is often used to automate the process of creating, updating, and deleting user accounts and permissions, and to keep these accounts and permissions in sync across different systems.

Announcing SCIM support for Cloudflare Access & Gateway

For example, most organizations have an identity provider, such as Okta or Azure Active Directory, that stores information about its employees, such as names, addresses, and job titles. The organization also likely uses cloud-based applications for collaboration. In order to access the cloud-based application, employees need to create an account and log in with a username and password. Instead of manually creating and managing these accounts, the organization can use SCIM to automate the process. Both the on-premise system and the cloud-based application are configured to support SCIM.

When a new employee is added to, or removed from, the identity provider, SCIM automatically creates an account for that employee in the cloud-based application, using the information from the on-premises system. If an employee’s information is updated in the identity provider, such as a change in job title, SCIM automatically updates the corresponding information in the cloud-based application. If an employee leaves the organization, their account can be deleted from both systems using SCIM.

SCIM helps organizations efficiently manage user identities and access across multiple systems, reducing the need for manual intervention and ensuring that user information is accurate and up to date.

Cloudflare Access provides secure access to your internal applications and resources. It integrates with your existing identity provider to enforce strong authentication for users and ensure that only authorized users have access to your organization’s resources. After a user successfully authenticates via the identity provider, Access initiates a session for that user. Once the session has expired, Access will redirect the user back to the identity provider.

Similarly, Cloudflare Gateway is a comprehensive secure web gateway (SWG) which leverages the same identity provider configurations as Access to allow administrators to build DNS, Network, and HTTP inspection policies based on identity. Once a user logs in using WARP client via the identity provider, their identity is logged and evaluated against any policies created by their organization’s administrator.

Challenges before SCIM

Before SCIM, if a user needed to be deprovisioned (e.g. leaving the business, a security breach or other factors) an administrator needed to remove access for the user in both the identity provider and Access. This was because a user’s Cloudflare Zero Trust session would stay active until they attempted to log in via the identity provider again. This was time-consuming and error-prone, and it leaves room for security vulnerabilities if a user’s access is not removed in a timely manner.

Announcing SCIM support for Cloudflare Access & Gateway

Another challenge with Cloudflare Access and Gateway was that identity provider groups had to be manually entered. This meant that if an identity provider group changed, an administrator had to manually update the value within the Cloudflare Zero trust dashboard to reflect those changes. This was tedious and time-consuming, and led to inconsistencies if the updates were not made promptly. Additionally, it required additional resources and expertise to manage this process effectively.

Announcing SCIM support for Cloudflare Access & Gateway

SCIM for Access & Gateway

Now, with the integration of SCIM, Access and Gateway can automatically deprovision users after they are deactivated in an identity provider and synchronize identity provider groups. This ensures that only active users, in the right group, have access to your organization’s resources, improving the security of your network.

User deprovisioning via SCIM listens for any user deactivation events in the identity provider and then revokes all active sessions for that user. This immediately cuts off their access to any application protected by Access and their session via WARP for Gateway.

Announcing SCIM support for Cloudflare Access & Gateway

Additionally, the integration of SCIM allows for the synchronization of identity provider group information in Access and Gateway policies. This means that all identity provider groups will automatically be available in both the Access and Gateway policy builders. There is also an option to automatically force a user to reauthenticate if their group membership changes.

For example, if you wanted to create an Access policy that only applied to users with emails associated with example.com and apart from the risky user group, you would be able to build a policy as show below by simply selecting the risky user group from a drop-down:

Announcing SCIM support for Cloudflare Access & Gateway

Similarly, if you wanted to create a Gateway policy to block example.com and all of its subdomains for these same users you could create the policy below:

Announcing SCIM support for Cloudflare Access & Gateway

What’s next

Today, SCIM support is available for Azure Active Directory and Okta for Self-Hosted Access applications. In the future, we plan to extend support for more Identity Providers and to Access for SaaS.

Try it now

SCIM is available for all Zero Trust customers today and can be used to improve operations and overall security. Try out SCIM for Access and Gateway yourself today.

One-click data security for your internal and SaaS applications

Post Syndicated from Tim Obezuk original https://blog.cloudflare.com/one-click-zerotrust-isolation/

One-click data security for your internal and SaaS applications

One-click data security for your internal and SaaS applications

Most of the CIOs we talk to want to replace dozens of point solutions as they start their own Zero Trust journey. Cloudflare One, our comprehensive Secure Access Service Edge (SASE) platform can help teams of any size rip out all the legacy appliances and services that tried to keep their data, devices, and applications safe without compromising speed.

We also built those products to work better together. Today, we’re bringing Cloudflare’s best-in-class browser isolation technology to our industry-leading Zero Trust access control product. Your team can now control the data in any application, and what a user can do in the application, with a single click in the Cloudflare dashboard. We’re excited to help you replace your private networks, virtual desktops, and data control boxes with a single, faster solution.

Zero Trust access control is just the first step

Most organizations begin their Zero Trust migration by replacing a virtual private network (VPN). VPN deployments trust too many users by default. In most configurations, any user on a private network can reach any resource on that same network.

The consequences vary. On one end of the spectrum, employees in marketing can accidentally stumble upon payroll amounts for the entire organization. At the other end, attackers who compromise the credentials of a support agent can move through a network to reach trade secrets or customer production data.

Zero Trust access control replaces this model by inverting the security posture. A Zero Trust network trusts no one by default. Every user and each request or connection, must prove they can reach a specific resource. Administrators can build granular rules and monitor comprehensive logs to prevent incidental or malicious access incidents.

Over 10,000 teams have adopted Cloudflare One to replace their own private network with a Zero Trust model. We offer those teams rules that go beyond just identity. Security teams can enforce hard key authentication for specific applications as a second factor. Sensitive production systems can require users to provide the reason they need temporary access while they request permission from a senior manager. We integrate with just about every device posture provider, or you can build your own, to ensure that only corporate devices connect to your systems.

The teams who deploy this solution improve the security of their enterprise overnight while also making their applications faster and more usable for employees in any region. However, once users pass all of those checks we still rely on the application to decide what they can and cannot do.

In some cases, that means Zero Trust access control is not sufficient. An employee planning to leave tomorrow could download customer contact info. A contractor connecting from an unmanaged device can screenshot schematics. As enterprises evolve on their SASE migration, they need to extend Zero Trust control to application usage and data.

Isolate sessions without any client software

Cloudflare’s browser isolation technology gives teams the ability to control usage and data without making the user experience miserable. Legacy approaches to browser isolation relied on one of two methods to secure a user on the public Internet:

  • Document Object Model (DOM) manipulation – unpack the webpage, inspect it, hope you caught the vulnerability, attempt to repack the webpage, deliver it. This model leads to thousands of broken webpages and total misses on zero days and other threats.
  • Pixel pushing – stream a browser running far away to the user, like a video. This model leads to user complaints due to performance and a long tail of input incompatibilities.

Cloudflare’s approach is different. We run headless versions of Chromium, the open source project behind Google Chrome and Microsoft Edge and other browsers, in our data centers around the world. We send the final rendering of the webpage, the draw commands, to a user’s local device.

One-click data security for your internal and SaaS applications

The user thinks it is just the Internet. Highlighting, right-clicking, videos – they all just work. Users do not need a special browser client. Cloudflare’s technology just works in any browser on mobile or desktop. For security teams, they can guarantee that code never executes on the devices in the field to stop Zero-Day attacks.

We added browser isolation to Cloudflare One to protect against attacks that leap out of a browser from the public Internet. However, controlling the browser also gives us the ability to pass that control along to security and IT departments, so they can focus on another type of risk – data misuse.

As part of this launch, when administrators secure an application with Cloudflare’s Zero Trust access control product, they can click an additional button that will force sessions into our isolated browser.

One-click data security for your internal and SaaS applications

When the user authenticates, Cloudflare Access checks all the Zero Trust rules configured for a given application. When this isolation feature is enabled, Cloudflare will silently open the session in our isolated browser. The user does not need any special software or to be trained on any unique steps. They just navigate to the application and start doing their work. Behind the scenes, the session runs entirely in Cloudflare’s network.

Control usage and data in sessions

By running the session in Cloudflare’s isolated browser, administrators can begin to build rules that replace some goals of legacy virtual desktop solutions. Some enterprises deploy virtual desktop instances (VDIs) to sandbox application usage. Those VDI platforms extended applications to employees and contractors without allowing the application to run on the physical device.

Employees and contractors tend to hate this method. The client software required is clunky and not available on every operating system. The speed slows them down. Administrators also need to invest time in maintaining the desktops and the virtualization software that power them.

We’re excited to help you replace that point solution, too. Once an application is isolated in Cloudflare’s network, you can toggle additional rules that control how users interact with the resource. For example, you can disable potential data loss vectors like file downloads, printing, or copy-pasting. Add watermarks, both visible and invisible, to audit screenshot leaks.

You can extend this control beyond just data loss. Some teams have sensitive applications where you need users to connect without inputting any data, but they do not have the developer time to build a “Read Only” mode. With Cloudflare One, those teams can toggle “Disable keyboard” and allow users to reach the service while blocking any input.

One-click data security for your internal and SaaS applications

The isolated solution also integrates with Cloudflare One’s Data Loss Prevention (DLP) suite. With a few additional settings, you can bring comprehensive data control to your applications without any additional engineering work or point solution deployment. If a user strays too far in an application and attempts to download something that contains personal information like social security or credit card numbers, Cloudflare’s network will stop that download while still allowing otherwise approved files.

One-click data security for your internal and SaaS applications

Extend that control to SaaS applications

Most of the customers we hear from need to bring this level of data and usage control to their self-hosted applications. Many of the SaaS tools they rely on have more advanced role-based rules. However, that is not always the case and, even if the rules exist, they are not as comprehensive as needed and require an administrator to manage a dozen different application settings.

To avoid that hassle you can bring Cloudflare One’s one-click isolation feature to your SaaS applications, too. Cloudflare’s access control solution can be configured as an identity proxy that will force all logins to any SaaS application that supports SSO through Cloudflare’s network where additional rules, including isolation, can be applied.

What’s next?

Today’s announcement brings together two of our customers’ favorite solutions – our Cloudflare Access solution and our browser isolation technology. Both products are available to use today. You can start building rules that force isolation or control data usage by following the guides linked here.

Willing to wait for the easy button? Join the beta today for the one-click version that we are rolling out to customer accounts.

New ways to troubleshoot Cloudflare Access ‘blocked’ messages

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/403-logs-cloudflare-access/

New ways to troubleshoot Cloudflare Access 'blocked' messages

New ways to troubleshoot Cloudflare Access 'blocked' messages

Cloudflare Access is the industry’s easiest Zero Trust access control solution to deploy and maintain. Users can connect via Access to reach the resources and applications that power your team, all while Cloudflare’s network enforces least privilege rules and accelerates their connectivity.

Enforcing least privilege rules can lead to accidental blocks for legitimate users. Over the past year, we have focused on adding tools to make it easier for security administrators to troubleshoot why legitimate users are denied access. These block reasons were initially limited to users denied access due to information about their identity (e.g. wrong identity provider group, email address not in the Access policy, etc.)

Zero Trust access control extends beyond identity and device. Cloudflare Access allows for rules that enforce how a user connects. These rules can include their location, IP address, the presence of our Secure Web Gateway and other controls.

Starting today, you can investigate those allow or block decisions based on how a connection was made with the same level of ease that you can troubleshoot user identity. We’re excited to help more teams make the migration to a Zero Trust model as easy as possible and ensure the ongoing maintenance is a significant reduction compared to their previous private network.

Why was I blocked?

All Zero Trust deployments start and end with identity. In a Zero Trust model, you want your resources (and the network protecting them) to have zero trust by default of any incoming connection or request. Instead, every attempt should have to prove to the network that they should be allowed to connect.

Organizations provide users with a mechanism of proof by integrating their identity provider (IdP) like Azure Active Directory or Okta. With Cloudflare, teams can integrate multiple providers simultaneously to help users connect during activities like mergers or to allow contractors to reach specific resources. Users authenticate with their provider and Cloudflare Access uses that to determine if we should trust a given request or connection.

After integrating identity, most teams start to layer on new controls like device posture. In some cases, or in every case, the resources are so sensitive that you want to ensure only approved users connecting from managed, healthy devices are allowed to connect.

While that model significantly improves security, it can also create strain for IT teams managing remote or hybrid workforces. Troubleshooting “why” a user cannot reach a resource becomes a guessing game over chat. Earlier this year, we launched a new tool to tell you exactly why a user’s identity or device posture did not meet the rules that your administrators created.

New ways to troubleshoot Cloudflare Access 'blocked' messages

What about how they connected?

As organizations advance in their Zero Trust journey, they add rules that go beyond the identity of the user or the posture of the device. For example, some teams might have regulatory restrictions that prevent users from accessing sensitive data from certain countries. Other enterprises need to understand the network context before granting access.

These adaptive controls enforce decisions around how a user connects. The user (and their device) might otherwise be allowed, but their current context like location or network prohibits them from doing so. These checks can extend to automated services, too, like a trusted chatbot that uses a service token to connect to your internal ticketing system.

While user and device posture checks require at least one step of authentication, these contextual rules can consist of policies that make it simple for a bad actor to retry over and over again like an IP address check. While the user will still be denied, that kind of information can overwhelm and flood your logs while you attempt to investigate what should be a valid login attempt.

With today’s release, your team can now have the best of both worlds.

However, other checks are not based on a user’s identity, these include looking at a device’s properties, network context, location, presence of a certificate and more. Requests that fail these “non-identity” checks are immediately blocked. These requests are immediately blocked in order to prevent a malicious user from seeing which identity providers are used by a business.

New ways to troubleshoot Cloudflare Access 'blocked' messages

Additionally, these blocks were not logged in order to avoid overloading the Access request logs of an individual account. A malicious user attempting hundreds of requests or a misconfigured API making thousands of requests should not cloud a security admin’s ability to analyze legitimate user Access requests.

These logs would immediately become overloaded if every blocked request were logged. However, we heard from users that in some situations, especially during initial setup, it is helpful to see individual block requests even for non-identity checks.

We have released a GraphQL API that allows Access administrators to look up a specific blocked request by RayID, User or Application. The API response will return a full output of the properties of the associated request which makes it much easier to diagnose why a specific request was blocked.

New ways to troubleshoot Cloudflare Access 'blocked' messages

In addition to the GraphQL API, we also improved the user facing block page to include additional detail about a user’s session. This will make it faster for end users and administrators to diagnose why a legitimate user was not allowed access.

New ways to troubleshoot Cloudflare Access 'blocked' messages

How does it work?

Collecting blocked request logs for thousands of Access customers presented an interesting scale challenge. A single application in a single customer account could have millions of blocked requests in a day, multiple that out across all protected applications across all Access customers and the number of logs start to get large quickly.

We were able to leverage our existing analytics pipeline that was built to handle the scale of our global network which is far beyond the scale of Access. The analytics pipeline is configured to intelligently begin sampling data if an individual account begins generating too many requests. The majority of customers will have all non-identity block logs captured while accounts generating large traffic volumes will retain a significant portion to diagnose issues.

How can I get started?

We have built an example guide to use the GraphQL API to diagnose Access block reasons. These logs can be manually checked using an GraphQL API client or periodically ingested into a log storage database.

We know that achieving a Zero Trust Architecture is a journey and a significant part of that is troubleshooting and initial configuration. We are committed to making Cloudflare Zero Trust the easiest Zero Trust solution to troubleshoot and configure at scale. Keep an eye out for additional announcements in the coming months that make Cloudflare Zero Trust even easier to troubleshoot.

If you don’t already have Cloudflare Zero Trust set up, getting started is easy – see the platform yourself with 50 free seats by signing up here.

Or if you would like to talk with a Cloudflare representative about your overall Zero Trust strategy, reach out to us here for a consultation.

For those who already know and love Cloudflare Zero Trust, this feature is enabled for all accounts across all pricing tiers.

Improved Access Control: Domain Scoped Roles are now generally available

Post Syndicated from Garrett Galow original https://blog.cloudflare.com/domain-scoped-roles-ga/

Improved Access Control: Domain Scoped Roles are now generally available

Improved Access Control: Domain Scoped Roles are now generally available

Starting today, it is possible to scope your users’ access to specific domains with Domain Scoped Roles becoming generally available!

We are making it easier for account owners to manage their team’s access to Cloudflare by allowing user access to be scoped to individual domains. Ensuring users have the least amount of access they need and no more is critical, and Domain Scoped Roles is a major step in this direction. Additionally, with the use of Domain Groups, account owners can grant users access to a group of domains instead of individually. Domains can be added or removed from these groups to automatically update the access of those who have been granted access to the group. This reduces toil in managing user access.

One of the most common uses we have seen for Domain Scoped Roles is to limit access to production domains to a small set of team members, while still allowing development and pre-production domains to be open to the rest of the team. That way, someone can’t make changes to a production domain unless they are given access.

We are doing a rollout of this functionality across all Enterprise Cloudflare accounts, and you will receive an email when this functionality is enabled for your account.

Any existing access on accounts today will remain the same, with the ability to further scope down access where it makes sense. All of our account-wide roles are still available to assign to users.

How to use Domain Scoped Roles

Once you have Domain Scoped Roles, here is how to start using it:

Log in to dash.cloudflare.com, select your account, and navigate to the members page.

From this page, you can manage your members’ permissions. In this case, we will invite a new user, however you can also modify an existing user’s permissions.

Improved Access Control: Domain Scoped Roles are now generally available

After clicking “Invite”, you will determine which users to invite, multiple users can be invited at the same time. After selecting users, we provide appropriate scope. Within the scope selection list, three options are available: all domains, a specific domain, and a domain group. Selecting all domains continues to grant account wide access, and all of our legacy roles are available at this level of scoping. A specific domain or domain groups provide access to our new domain scoped roles. Finally, with a user and a scope selected, a role (or multiple roles) can be selected to grant appropriate permissions.

Improved Access Control: Domain Scoped Roles are now generally available

Before sending the invite, you will be able to confirm the users, scope, and roles.

Improved Access Control: Domain Scoped Roles are now generally available

Domain Groups

In addition to manually creating inclusion or exclusion lists per user, account owners can also create Domain Groups to allow granting one or more users to a group of domains. Domain Groups can be created from the member invite flow or directly from Account Configurations → Lists. When creating a domain group, the user selects the domains to include and, from that point on, the group can be used when inviting a user to the account.

What’s next

We are doing a rollout of this functionality across all Enterprise Cloudflare accounts, and you will receive an email when this functionality is enabled for your account.

Any existing access on accounts today will remain the same, with the ability to further scope access where you decide. All of our account-wide roles are still available to assign to users.

If you are an enterprise customer and interested in getting Domain Scoped Roles sooner, please contact your CSM to get enabled! Otherwise, you will receive an email when your account has this feature enabled.

This announcement represents a step forward in our migration to a new authorization system built for Cloudflare’s scale. This will allow us to expand these capabilities to more products in the future and to create an authorization system that puts customers more in control of their team’s access across all of Cloudflare’s services.

How Cloudflare Security does Zero Trust

Post Syndicated from Noelle Gotthardt original https://blog.cloudflare.com/how-cloudflare-security-does-zero-trust/

How Cloudflare Security does Zero Trust

How Cloudflare Security does Zero Trust

Throughout Cloudflare One week, we provided playbooks on how to replace your legacy appliances with Zero Trust services. Using our own products is part of our team’s culture, and we want to share our experiences when we implemented Zero Trust.

Our journey was similar to many of our customers. Not only did we want better security solutions, but the tools we were using made our work more difficult than it needed to be. This started with just a search for an alternative to remotely connecting on a clunky VPN, but soon we were deploying Zero Trust solutions to protect our employees’ web browsing and email. Next, we are looking forward to upgrading our SaaS security with our new CASB product.

We know that getting started with Zero Trust can seem daunting, so we hope that you can learn from our own journey and see how it benefited us.

Replacing a VPN: launching Cloudflare Access

Back in 2015, all of Cloudflare’s internally-hosted applications were reached via a hardware-based VPN. On-call engineers would fire up a client on their laptop, connect to the VPN, and log on to Grafana. This process was frustrating and slow.

Many of the products we build are a direct result of the challenges our own team is facing, and Access is a perfect example. Launching as an internal project in 2015, Access enabled employees to access internal applications through our identity provider. We started with just one application behind Access with the goal of improving incident response times. Engineers who received a notification on their phones could tap a link and, after authenticating via their browser, would immediately have the access they needed. As soon as people started working with the new authentication flow, they wanted it everywhere. Eventually our security team mandated that we move our apps behind Access, but for a long time it was totally organic: teams were eager to use it.

With authentication occuring at our network edge, we were able to support a globally-distributed workforce without the latency of a VPN, and we were able to do so securely. Moreover, our team is committed to protecting our internal applications with the most secure and usable authentication mechanisms, and two-factor authentication is one of the most important security controls that can be implemented. With Cloudflare Access, we’re able to rely on the strong two-factor authentication mechanisms of our identity provider.

Not all second factors of authentication deliver the same level of security. Some methods are still vulnerable to man-in-the-middle (MITM) attacks. These attacks often feature bad actors stealing one-time passwords, commonly through phishing, to gain access to private resources. To eliminate that possibility, we implemented FIDO2 supported security keys. FIDO2 is an authenticator protocol designed to prevent phishing, and we saw it as an improvement to our reliance on soft tokens at the time.

While the implementation of FIDO2 can present compatibility challenges, we were enthusiastic to improve our security posture. Cloudflare Access enabled us to limit access to our systems to only FIDO2. Cloudflare employees are now required to use their hardware keys to reach our applications. The onboarding of Access was not only a huge win for ease of use, the enforcement of security keys was a massive improvement to our security posture.

Mitigate threats & prevent data exfiltration: Gateway and Remote Browser Isolation

Deploying secure DNS in our offices

A few years later, in 2020, many customers’ security teams were struggling to extend the controls they had enabled in the office to their remote workers. In response, we launched Cloudflare Gateway, offering customers protection from malware, ransomware, phishing, command & control, shadow IT, and other Internet risks over all ports and protocols. Gateway directs and filters traffic according to the policies implemented by the customer.

Our security team started with Gateway to implement DNS filtering in all of our offices. Since Gateway was built on top of the same network as 1.1.1.1, the world’s fastest DNS resolver, any current or future Cloudflare office will have DNS filtering without incurring additional latency. Each office connects to the nearest data center and is protected.

Deploying secure DNS for our remote users

Cloudflare’s WARP client was also built on top of our 1.1.1.1 DNS resolver. It extends the security and performance offered in offices to remote corporate devices. With the WARP client deployed, corporate devices connect to the nearest Cloudflare data center and are routed to Cloudflare Gateway. By sitting between the corporate device and the Internet, the entire connection from the device is secure, while also offering improved speed and privacy.

We sought to extend secure DNS filtering to our remote workforce and deployed the Cloudflare WARP client to our fleet of endpoint devices. The deployment enabled our security teams to better preserve our privacy by encrypting DNS traffic over DNS over HTTPS (DoH). Meanwhile, Cloudflare Gateway categorizes domains based on Radar, our own threat intelligence platform, enabling us to block high risk and suspicious domains for users everywhere around the world.

How Cloudflare Security does Zero Trust

Adding on HTTPS filtering and Browser Isolation

DNS filtering is a valuable security tool, but it is limited to blocking entire domains. Our team wanted a more precise instrument to block only malicious URLs, not the full domain. Since Cloudflare One is an integrated platform, most of the deployment was already complete. All we needed was to add the Cloudflare Root CA to our endpoints and then enable HTTP filtering in the Zero Trust dashboard. With those few simple steps, we were able to implement more granular blocking controls.

In addition to precision blocking, HTTP filtering enables us to implement tenant control. With tenant control, Gateway HTTP policies regulate access to corporate SaaS applications. Policies are implemented using custom HTTP headers. If the custom request header is present and the request is headed to an organizational account, access is granted. If the request header is present and the request goes to a non-organizational account, such as a personal account, the request can be blocked or opened in an isolated browser.

After protecting our users’ traffic at the DNS and HTTP layers, we implemented Browser Isolation. When Browser Isolation is implemented, all browser code executes in the cloud on Cloudflare’s network. This isolates our endpoints from malicious attacks and common data exfiltration techniques. Some remote browser isolation products introduce latency and frustrate users. Cloudflare’s Browser Isolation uses the power of our network to offer a seamless experience for our employees. It quickly improved our security posture without compromising user experience.

Preventing phishing attacks: Onboarding Area 1 email security

Also in early 2020, we saw an uptick in employee-reported phishing attempts. Our cloud-based email provider had strong spam filtering, but they fell short at blocking malicious threats and other advanced attacks. As we experienced increasing phishing attack volume and frequency we felt it was time to explore more thorough email protection options.

The team looked for four main things in a vendor: the ability to scan email attachments, the ability to analyze suspected malicious links, business email compromise protection, and strong APIs into cloud-native email providers. After testing many vendors, Area 1 became the clear choice to protect our employees. We implemented Area 1’s solution in early 2020, and the results have been fantastic.

Given the overwhelmingly positive response to the product and the desire to build out our Zero Trust portfolio, Cloudflare acquired Area 1 Email Security in April 2022. We are excited to offer the same protections we use to our customers.

What’s next: Getting started with Cloudflare’s CASB

Cloudflare acquired Vectrix in February 2022. Vectrix’s CASB offers functionality we are excited to add to Cloudflare One. SaaS security is an increasing concern for many security teams. SaaS tools are storing more and more sensitive corporate data, so misconfigurations and external access can be a significant threat. However, securing these platforms can present a significant resource challenge. Manual reviews for misconfigurations or externally shared files are time consuming, yet necessary processes for many customers. CASB reduces the burden on teams by ensuring security standards by scanning SaaS instances and identifying vulnerabilities with just a few clicks.

We want to ensure we maintain the best practices for SaaS security, and like many of our customers, we have many SaaS applications to secure. We are always seeking opportunities to make our processes more efficient, so we are excited to onboard one of our newest Zero Trust products.

Always striving for improvement

Cloudflare takes pride in deploying and testing our own products. Our security team works directly with Product to “dog food” our own products first. It’s our mission to help build a better Internet — and that means providing valuable feedback from our internal teams. As the number one consumer of Cloudflare’s products, the Security team is not only helping keep the company safer, but also contributing to build better products for our customers.

We hope you have enjoyed Cloudflare One week. We really enjoyed sharing our stories with you. To check out our recap of the week, please visit our Cloudflare TV segment.

Verify Apple devices with no installed software

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/private-attestation-token-device-posture/

Verify Apple devices with no installed software

Verify Apple devices with no installed software

One of the foundations of Zero Trust is determining if a user’s device is “healthy” — that it has its operating system up-to-date with the latest security patches, that it’s not jailbroken, that it doesn’t have malware installed, and so on. Traditionally, determining this has required installing software directly onto a user’s device.

Earlier this month, Cloudflare participated in the announcement of an open source standard called a Private Attestation Token. Device manufacturers who support the standard can now supply a Private Attestation Token with any request made by one of their devices. On the IT Administration side, Private Attestation Tokens means that security teams can verify a user’s device before they access a sensitive application — without the need to install any software or collect a user’s device data.

At WWDC 2022, Apple announced Private Attestation Tokens. Today, we’re announcing that Cloudflare Access will support verifying a Private Attestation token. This means that security teams that rely on Cloudflare Access can verify a user’s Apple device before they access a sensitive application — no additional software required.

Determining a “healthy” device

There are many solutions on the market that help security teams determine if a device is “healthy” and corporately managed. What the majority of these solutions have in common is that they require software to be installed directly on the user’s machine. This comes with challenges associated with client software including compatibility issues, version management, and end user support. Many companies have dedicated Mobile Device Management (MDM) tools to manage the software installed on employee machines.

MDM is a proven model, but it is also a challenge to manage — taking a dedicated team in many cases. What’s more, installing client or MDM software is not always possible for contractors, vendors or employees using personal machines. Security teams have to resort to VDI or VPN solutions for external users to securely access corporate applications.

How Private Attestation Tokens verify a device

Private Attestation Tokens leverage the Privacy Pass Protocol, which Cloudflare authored with major device manufacturers, to attest to a device’s health and integrity.

In order for Private Attestation Tokens to work, four parties agree to work in concert with a common framework to generate and exchange anonymous, unforgeable tokens. Without all four parties in the process, PATs won’t work.

  1. An Origin. A website, application, or API that receives requests from a client. When a website receives a request to their origin, the origin must know to look for and request a token from the client making the request. For Cloudflare customers, Cloudflare acts as the origin (on behalf of customers) and handles the requesting and processing of tokens.
  2. A Client. Whatever tool the visitor is using to attempt to access the Origin. This will usually be a web browser or mobile application. In our example, let’s say the client is a mobile Safari Browser.
  3. An Attester. The Attester is who the client asks to prove something (i.e that a mobile device has a valid IMEI) before a token can be issued. In our example below, the Attester is Apple, the device vendor.
  4. An Issuer. The issuer is the only one in the process that actually generates, or issues, a token. The Attester makes an API call to whatever Issuer the Origin has chosen to trust,  instructing the Issuer to produce a token. In our case, Cloudflare will also be the Issuer.
Verify Apple devices with no installed software

We are then able to rely on the attestation from the device manufacturer as a form of validation that a device is in a “healthy” enough state to be allowed access to a sensitive application.

Checking device health without client software

Private Attestation Tokens do not require any additional software to be installed on the user’s device. This is because the “attestation” of device health and validity is attested directly by the device operating system’s manufacturer — in this case, Apple.

This means that a security team can use Cloudflare Access and Private Attestation Tokens to verify if a user is accessing from a “healthy” Apple device before allowing access to a sensitive corporate application. Some checks as part of the attestation include:

  • Is the device on the latest OS version?
  • Is the device jailbroken?
  • Is the window attempting to log in, in focus?
  • And much more.

Over time, we are working with other device manufacturers to expand device support and what is verified as part of the device attestation process. The attributes that are attested will also continue to expand over time, which means the device verification in Access will only strengthen.

In the next few months, we will move Private Attestation Support in Cloudflare Access to a closed beta. The first version will work for iOS devices and support will expand from there. The only change required will be an updated Access policy, no software will need to be installed. If you would like to be part of the beta program, sign up here today!

How to augment or replace your VPN with Cloudflare

Post Syndicated from Michael Keane original https://blog.cloudflare.com/how-to-augment-or-replace-your-vpn/

How to augment or replace your VPN with Cloudflare

“Never trust, always verify.”

How to augment or replace your VPN with Cloudflare

Almost everyone we speak to these days understands and agrees with this fundamental principle of Zero Trust. So what’s stopping folks? The biggest gripe we hear: they simply aren’t sure where to start. Security tools and network infrastructure have often been in place for years, and a murky implementation journey involving applications that people rely on to do their work every day can feel intimidating.

While there’s no universal answer, several of our customers have agreed that offloading key applications from their traditional VPN to a cloud-native Zero Trust Network Access (ZTNA) solution like Cloudflare Access is a great place to start—providing an approachable, meaningful upgrade for their business.

In fact, GartnerⓇ predicted that “by 2025, at least 70% of new remote access deployments will be served predominantly by ZTNA as opposed to VPN services, up from less than 10% at the end of 2021.”1 By prioritizing a ZTNA project, IT and Security executives can better shield their business from attacks like ransomware while simultaneously improving their employees’ daily workflows. The trade-off between security and user experience is an outmoded view of the world; organizations can truly improve both if they go down the ZTNA route.

You can get started here with Cloudflare Access for free, and in this guide we’ll show you why, and how.

Why nobody likes their VPN

The network-level access and default trust granted by VPNs create avoidable security gaps by inviting the possibility of lateral movement within your network. Attackers may enter your network through a less-sensitive entry point after stealing credentials, and then traverse to find more business-critical information to exploit. In the face of rising attacks, the threat here is too real—and the path to mitigate is too within reach—to ignore.

How to augment or replace your VPN with Cloudflare

Meanwhile, VPN performance feels stuck in the 90s… and not in a fun, nostalgic way. Employees suffer through slow and unreliable connections that simply weren’t built for today’s scale of remote access. In the age of the “Great Reshuffle” and the current recruiting landscape, providing subpar experiences for teams based on legacy tech doesn’t have a great ROI. And when IT/security practitioners have plenty of other job opportunities readily available, they may not want to put up with manual, avoidable tasks born from an outdated technology stack. From both security and usability angles, moving toward VPN replacement is well worth the pursuit.

Make least-privilege access the default

Instead of authenticating a user and providing access to everything on your corporate network, a ZTNA implementation or “software-defined perimeter” authorizes access per resource, effectively eliminating the potential for lateral movement. Each access attempt is evaluated against Zero Trust rules based on identity, device posture, geolocation, and other contextual information. Users are continuously re-evaluated as context changes, and all events are logged to help improve visibility across all types of applications.

How to augment or replace your VPN with Cloudflare

As co-founder of Udaan, Amod Malviya, noted, “VPNs are frustrating and lead to countless wasted cycles for employees and the IT staff supporting them. Furthermore, conventional VPNs can lull people into a false sense of security. With Cloudflare Access, we have a far more reliable, intuitive, secure solution that operates on a per user, per access basis. I think of it as Authentication 2.0 — even 3.0″.

Better security and user experience haven’t always co-existed, but the fundamental architecture of ZTNA really does improve both compared to legacy VPNs. Whether your users are accessing Office 365 or your custom, on-prem HR app, every login experience is treated the same. With Zero Trust rules being checked behind the scenes, suddenly every app feels like a SaaS app to your end users. Like our friends at OneTrust said when they implemented ZTNA, “employees can connect to the tools they need, so simply teams don’t even know Cloudflare is powering the backend. It just works.”

Assembling a ZTNA project plan

VPNs are so entrenched in an organization’s infrastructure that fully replacing one may take a considerable amount of time, depending on the total number of users and applications served. However, there still is significant business value in making incremental progress. You can migrate away from your VPN at your own pace and let ZTNA and your VPN co-exist for some time, but it is important to at least get started.

Consider which one or two applications behind your VPN would be most valuable for a ZTNA pilot, like one with known complaints or numerous IT support tickets associated with it. Otherwise, consider internal apps that are heavily used or are visited by particularly critical or high-risk users. If you have any upcoming hardware upgrades or license renewals planned for your VPN(s), apps behind the accompanying infrastructure may also be a sensible fit for a modernization pilot.

As you start to plan your project, it’s important to involve the right stakeholders. For your ZTNA pilot, your core team should at minimum involve an identity admin and/or admin who manages internal apps used by employees, plus a network admin who understands your organization’s traffic flow as it relates to your VPN. These perspectives will help to holistically consider the implications of your project rollout, especially if the scope feels dynamic.

Executing a transition plan for a pilot app

Step 1: Connect your internal app to Cloudflare’s network
The Zero Trust dashboard guides you through a few simple steps to set up our app connector, no virtual machines required. Within minutes, you can create a tunnel for your application traffic and route it based on public hostnames or your private network routes. The dashboard will provide a string of commands to copy and paste into your command line to facilitate initial routing configurations. From there, Cloudflare will manage your configuration automatically.

A pilot web app may be the most straightforward place to start here, but you can also extend to SSH, VNC, RDP, or internal IPs and hostnames through the same workflow. With your tunnel up and running, you’ve created the means through which your users will securely access your resources and have essentially eliminated the potential for lateral movement within your network. Your application is not visible to the public Internet, significantly reducing your attack surface.

Step 2: Integrate identity and endpoint protection
Cloudflare Access acts as an aggregation layer for your existing security tools. With support for over a dozen identity providers (IdPs) like Okta, Microsoft Azure AD, Ping Identity, or OneLogin, you can link multiple simultaneous IdPs or separate tenants from one IdP. This can be particularly useful for companies undergoing mergers or acquisitions or perhaps going through compliance updates, e.g. incorporating a separate FedRAMP tenant.

In a ZTNA implementation, this linkage lets both tools play to their strengths. The IdP houses user stores and performs the identity authentication check, while Cloudflare Access controls the broader Zero Trust rules that ultimately decide access permissions to a broad range of resources.

Similarly, admins can integrate common endpoint protection providers like Crowdstrike, SentinelOne, Tanium or VMware Carbon Black to incorporate device posture into Zero Trust rulesets. Access decisions can incorporate device posture risk scores for tighter granularity.

You might find shortcut approaches to this step if you plan on using simpler authentication like one-time pins or social identity providers with external users like partners or contractors. As you mature your ZTNA rollout, you can incorporate additional IdPs or endpoint protection providers at any time without altering your fundamental setup. Each integration only adds to your source list of contextual signals at your disposal.

Step 3: Configure Zero Trust rules
Depending on your assurance levels for each app, you can customize your Zero Trust policies to appropriately restrict access to authorized users using contextual signals. For example, a low-risk app may simply require email addresses ending in “@company.com” and a successful SMS or email multifactor authentication (MFA) prompt. Higher risk apps could require hard token MFA specifically, plus a device posture check or other custom validation check using external APIs.

MFA in particular can be difficult to implement with legacy on-prem apps natively using traditional single sign-on tools. Using Cloudflare Access as a reverse proxy helps provide an aggregation layer to simplify rollout of MFA to all your resources, no matter where they live.

Step 4: Test clientless access right away
After connecting an app to Cloudflare and configuring your desired level of authorization rules, end users in most cases can test web, SSH, or VNC access without using a device client. With no downloads or mobile device management (MDM) rollouts required, this can help accelerate ZTNA adoption for key apps and be particularly useful for enabling third-party access.

Note that a device client can still be used to unlock other use cases like protecting SMB or thick client applications, verifying device posture, or enabling private routing. Cloudflare Access can handle any arbitrary L4-7 TCP or UDP traffic, and through bridges to WAN-as-a-service it can offload VPN use cases like ICMP or server-to-client initiated protocol traffic like VoIP as well.

How to augment or replace your VPN with Cloudflare

At this stage for the pilot app, you are up and running with ZTNA! Top priority apps can be offloaded from your VPN one at a time at any pace that feels comfortable to help modernize your access security. Still, augmenting and fully replacing a VPN are two very different things.

Moving toward full VPN replacement

While a few top resource candidates for VPN offloading might be clear for your company, the total scope could be overwhelming, with potentially thousands of internal IPs and domains to consider. You can configure the local domain fallback entries within Cloudflare Access to point to your internal DNS resolver for selected internal hostnames. This can help you more efficiently disseminate access to resources made available over your Intranet.

It can also be difficult for admins to granularly understand the full reach of their current VPN usage. Potential visibility issues aside, the full scope of applications and users may be in dynamic flux especially at large organizations. You can use the private network discovery report within Cloudflare Access to passively vet the state of traffic on your network over time. For discovered apps requiring more protection, Access workflows help you tighten Zero Trust rules as needed.

Both of these capabilities can help reduce anxiety around fully retiring a VPN. By starting to build your private network on top of Cloudflare’s network, you’re bringing your organization closer to achieving Zero Trust security.

The business impact our customers are seeing

Offloading applications from your VPN and moving toward ZTNA can have measurable benefits for your business even in the short term. Many of our customers speak to improvements in their IT team’s efficiency, onboarding new employees faster and spending less time on access-related help tickets. For example, after implementing Cloudflare Access, eTeacher Group reduced its employee onboarding time by 60%, helping all teams get up to speed faster.

Even if you plan to co-exist with your VPN alongside a slower modernization cadence, you can still track IT tickets for the specific apps you’ve transitioned to ZTNA to help quantify the impact. Are overall ticket numbers down? Did time to resolve decrease? Over time, you can also partner with HR for qualitative feedback through employee engagement surveys. Are employees feeling empowered with their current toolset? Do they feel their productivity has improved or complaints have been addressed?

Of course, improvements to security posture also help mitigate the risk of expensive data breaches and their lingering, damaging effects to brand reputation. Pinpointing narrow cause-and-effect relationships for the cost benefits of each small improvement may feel more art than science here, with too many variables to count. Still, reducing reliance on your VPN is a great step toward reducing your attack surface and contributes to your macro return on investment, however long your full Zero Trust journey may last.

Start the clock toward replacing your VPN

Our obsession with product simplicity has helped many of our customers sunset their VPNs already, and we can’t wait to do more.

You can get started here with Cloudflare Access for free to begin augmenting your VPN. Follow the steps outlined above with your prioritized ZTNA test cases, and for a sense of broader timing you can create your own Zero Trust roadmap as well to figure out what project should come next.

For a full summary of Cloudflare One Week and what’s new, tune in to our recap webinar.

___

1Nat Smith, Mark Wah, Christian Canales. (2022, April 08). Emerging Technologies: Adoption Growth Insights for Zero Trust Network Access. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

Infinitely extensible Access policies

Post Syndicated from Kenny Johnson original https://blog.cloudflare.com/access-external-validation-rules/

Infinitely extensible Access policies

Infinitely extensible Access policies

Zero Trust application security means that every request to an application is denied unless it passes a specific set of defined security policies. Most Zero Trust solutions allow the use of a user’s identity, device, and location as variables to define these security policies.

We heard from customers that they wanted more control and more customizability in defining their Zero Trust policies.

Starting today, we’re excited that Access policies can consider anything before allowing a user access to an application. And by anything, we really do mean absolutely anything. You can now build infinitely customizable policies through the External Evaluation rule option, which allows you to call any API during the evaluation of an Access policy.

Why we built external evaluation rules

Over the past few years we added the ability to check location and device posture information in Access. However, there are always additional signals that can be considered depending on the application and specific requirements of an organization. We set out to give customers the ability to check whatever signal they require without any direct support in Access policies.

The Cloudflare security team, as an example, needed the ability to verify a user’s mTLS certificate against a registry to ensure applications can only be accessed by the right user from a corporate device. Originally, they considered using a Worker to check the user’s certificate after Access evaluated the request. However, this was going to take custom software development and maintenance over time. With External Evaluation rules, an API call can be made to verify whether a user is presenting the correct certificate for their device. The API call is made to a Worker that stores the mapping of mTLS certificates and user devices. The Worker executes the custom logic and then returns a true or false to Access.

How it works

Cloudflare Access is a reverse proxy in front of any web application. If a user has not yet authenticated, they will be presented with a login screen to authenticate. The user must meet the criteria defined in your Access policy. A typical policy would look something like:

  • The user’s email ends in @example.com
  • The user authenticated with a hardware based token
  • The user logged in from the United States

If the user passes the policy, they are granted a cookie that will give them access to the application until their session expires.

To evaluate the user on other custom criteria, you can add an external evaluation rule to the Access policy. The external evaluation rule requires two values: an API endpoint to call and a key to verify that any request response is coming from a trusted source.

Infinitely extensible Access policies

After the user authenticates with your identity provider, all information about the user, device and location is passed to your external API. The API returns a pass or fail response to Access which will then either allow or deny access to the user.

Example logic for the API would look like this:

/**
 * Where your business logic should go
 * @param {*} claims
 * @returns boolean
 */
async function externalEvaluation(claims) {
  return claims.identity.email === '[email protected]'
}

Where the claims object contains all the information about the user, device and network making the request. This externalEvaluation function can be extended to perform any desired business logic. We have made an open-source repository available with example code for consuming the Access claims and verifying the signing keys from Access.

This is really powerful! Any Access policy can now be infinitely extended to consider any information before allowing a user access. Potential examples include:

  • Integrating with endpoint protection tools we don’t yet integrate with by building a middleware that checks the endpoint protection tool’s API.
  • Checking IP addresses against external threat feeds
  • Calling industry-specific user registries
  • And much more!

We’re just getting started with extending Access policies. In the future we’ll make it easier to programmatically decide how a user should be treated before accessing an application, not just allow or deny access.

This feature is available in the Cloudflare Zero Trust dashboard today. Follow this guide to get started!