Browser VNC with Zero Trust Rules

Hey, good morning, good afternoon, or good evening, depending on where you're at in the world. My name is Kenny Johnson, and I'm a product manager here at Cloudflare. Thank you for joining. And I'm here today to talk a little bit about our new browser -based SSH and VNC products that are powered by Cloudflare for Teams with Zero Trust rules. Really just to quickly set kind of what I'm going to go through today, I'll do a brief overview of what browser-based SSH and VNC are, how it's powered, kind of as well as what's possible using our Zero Trust engine. I'll talk a little bit about how it's powered by Cloudflare's network. Then I'll actually go through a demo of these products. I'll touch a little bit on what the configuration looks like for these individual products, and then we'll get to see them in action. Awesome, with that, I'll go ahead and step right in. So just jumping into browser-based SSH and VNC, basically how these systems work are that what I'm able to do is taking a non-HTTP app, so either SSH to some kind of server or something like that on AWS or DigitalOcean, or possibly VNC. What I'm able to do is create a TCP connection to the server where that particular resource lives. And then what we've done at Cloudflare is we've built code on our edge in WebAssembly to actually render an SSH or a VNC viewer directly in the browser. A couple of things to note here are that the connection is fully encrypted, so Cloudflare doesn't see anything going over the SSH entries or the VNC session. However, the other piece that is powerful here is that we are soon gonna be able to add auditability on top of this, so actually giving users the ability to see actions being taken within an SSH terminal or within a VNC browser. Once that's been configured, then all a user needs is just a browser and an Internet connection, and then they're able to access both a VNC or SSH session. This is much different than kind of the current status quo where I might be using a machine-based VNC viewer or I might just use my normal terminal to access SSH. It can be really handy for users, but it can be a really kind of dangerous security vector to leave open because if a user's keys are ever leaked or anything like that, I don't have a ton of control as an admin who's actually SSHing to a particular server. There's no kind of validation check beyond being able to identify and verify a user's keys while connecting. This gives you a lot more control and visibility over who is accessing, when they're accessing, what device they're accessing from, as well as additional controls and enforcement on the actual access to these particular resources. And these are all backed by Cloudflare for Teams. So this is backed by Cloudflare Access, which has been a well-established product that powers Cloudflare Zero Trust Control to applications. So you're able to plug in multiple identity providers, device posture or device security posture signals. So does the device's serial number fit in a certain list? Are they running CrowdStrike? Checks like that, as well as contextual factors. So looking at the IP address that it's coming from, user's country, you're able to build really granular policies for these applications to dictate who can and cannot access that particular application. And I think one of the most important distinctions and why this technology wasn't necessarily possible in the past was that latency would be a huge concern. If you were trying to render an SSH terminal with a centralized data center or just a few data centers spread across the globe. If as a user, I'm trying to perform very latency-sensitive key stroking on an SSH terminal or use a VNC browser, or I'm actually dragging and dropping things and my mouse is taking forever to move because I'm having to backhaul traffic to a data center halfway across the world, that's just not an acceptable user experience. What makes Cloudflare really unique is that we have a vast edge network of over 200 data centers across the entire world. Meaning that we're less than 100 milliseconds or within less than 100 milliseconds of 99% of Internet connected users across the world. This allows us to deliver these experiences really efficiently because both the SSH and VNC terminal render completely at our edge at the data center nearest to the user. So there really aren't latency controls that would be a concern in kind of in days past. Awesome, so now what I wanna do is I wanna actually go ahead and take a look at what the configuration and setup looks like for both the SSH and VNC terminal or VNC browser based applications within Cloudflare. So I'm gonna go ahead and start in Cloudflare for Teams. So just to quickly orient you in Cloudflare for Teams, there's two core components within Cloudflare for Teams. There's gateway, which is our secure web gateway product that's for web filtering, not super relevant today, but I always just like to touch on what's involved in this dashboard. The piece that is gonna be super relevant is Cloudflare access because Cloudflare access is basically the gatekeeper or the controller over who can and cannot access these particular resources. And this is where we go ahead and actually set up the initial connection and the policies for who can access these particular resources. So I'll go ahead and start with my SSH application. So I have just a basic hostname or subdomain against a domain that I own, that I've set up and configured to render an SSH browser session. What I've done to configure this is I'm just basically specifying that I wanna render this as an SSH session. I'll get into kind of what's going on in the backend of the particular server that I'm exposing in a moment as well. But the next piece that I wanna do once I've specified and said, I want this application to be a browser-based SSH terminal is now I wanna actually dictate who can access this particular browser-based SSH session. So what I'm gonna do is I'm gonna create an access policy. And in this case, I've created a very basic access policy. I'm saying that I want to only lock down and allow my employees. So anybody with an at Cloudflare email address can access this particular resource. If I wanted to, I could do additional things like look for a certificate, look for filter for specific countries. I'm able to be really granular in defining these policies. I'll quickly kind of step through what's possible within access, just in terms of groupings. So the first piece is just some basic location and network context. So based on a user's country, based on an IP range, signal like that, as well as identity information. So this comes from various identity providers that you can hook into access. So these are things like email addresses, membership to specific Okta groups, additional SAML claims, things like that. And really the final area of signal is device posture. So this can be something like I issue a token to the machine, I put a certificate on the machine, or I can actually check device posture of that particular machine before allowing access. So are they running Cloudflare's Warp Client? So is there traffic being encrypted? Do they have Tanium or SentinelOne or CrowdStrike or any kind of any major endpoint protection provider running on that machine before I want to allow access? Or is the device's serial number in a list of managed serial numbers that I set up and configure within Teams? So I'm able to be very, very granular with exactly how I want to allow and which users I want to allow access into these particular applications. Once I've configured the policy, I'm then also able to configure which identity provider I would like to actually allow access to for that particular application. So this is the access policy side and kind of that configuration side. The other side of the setup is on the actual server that I want to expose via SSH or VNC. So in this case, I've actually set up just a DigitalOcean server. So I'll go ahead and pull that up. So I just have a DigitalOcean droplet. I'm powering both my browser-based SSH and VNC session out of this same droplet. So what I actually am able to do within DigitalOcean is using a product called Cloudflare Tunnel. I'm able to create a secure outbound tunnel connection to Cloudflare's edge. So pulling up a console within DigitalOcean, I'll actually pull this up in my browser-based SSH in a moment as well, but I'll start quickly here with DigitalOcean's terminal just to show you what's going on underneath the hood. So using what's called Cloudflare Tunnel, Cloudflare Tunnel basically creates a secure outbound tunnel connection to Cloudflare's edge. It allows you to basically route traffic from Cloudflare into a particular server, and then I can lock that server down so no direct traffic can reach that particular resource. So what I've now done is I've created a tunnel using our daemon called Cloudflare-D. I called it DigitalOcean-VNC or DoVNC. This gave me a specific tunnel ID, and then you can see it's created multiple persistent connections to the closest colos or to the closest data centers to my location. So in this case, or in this case, it's actually the DigitalOcean's infrastructure's location, which they're in the Bay Area, so we're getting San Jose and LAX. So I've got two redundant connections to each of those data centers. The next step is I need to take this tunnel that I've just created and hook this up to the particular DNS record that I want to expose the SSH application through. So if I go ahead and step back to the Cloudflare for Teams stash, we can see that I want to expose this via digitalocean-ssh.kennyatx.com. So then my last step here is within Cloudflare DNS. I want to go ahead and map my DigitalOcean SSH subdomain to the Cloudflare tunnel instance that I've created. So this Cloudflare tunnel instance that I've created is now mapped to digitalocean-ssh.kennyatx.com. So now I've got it all hooked up to where I'm able to, and there's one additional configuration step I'll actually show you when I get into the browser-based SSH as well. So what I'm gonna go ahead and do is now I'll go to, here, I'll go ahead and do it again. I had it on the other tab. So I hit digitalocean-ssh.kennyatx.com. And what this did is this took me to a Cloudflare access login screen. So now I'm able to see the specific identity providers that I've set up and configured. One additional note, if you ever like to use it, this actually can be a really, really good use case if you have external users or contractors who you would like to grant SSH access to. What we can do in access is we can actually set up and configure a one-time pin for those users or an option to do that. So if a user exists in a particular policy, say I want to put a certain contractor domain or very specific contractors into an access policy, they're then able to enter their email here to receive a one-time code. So I don't have to worry about onboarding them to my Okta instance or bringing them into G Suite or trying to onboard their G Suite org into my identity management system. I can just do a really kind of quick and dirty one-time pin to be able to grant them access to this particular resource. So what I'm gonna go ahead and do now is I've got my SSH application here. I'll go ahead and log in through Google, log in via my Cloudflare account. And if you remember, how I had it set up was my policy was allowing anybody with an app Cloudflare account. So I passed that policy check because I used my Kenny Johnson at Cloudflare.com. If you have any feedback on this, feel free to email me if you want. I have that email within my access policy. So now what I'm being prompted to, this is just my own DigitalOcean infrastructure now prompting me for my access management credentials. So I'm gonna go ahead and log in just as my root user. One additional note is we actually support short-lived certificates. So you can put a certificate on your machine and this just will automatically take you straight through to your SSH session. In this case, I'm just using a password. So I'll just go ahead and log in with my SSH password within DigitalOcean. And now I'm actually being presented with my SSH terminal directly within DigitalOcean. So just to make it super clear too, I can go ahead and pull up my droplet in DigitalOcean and you'll be able to see the, let me go ahead and grab that. I can pull that up and you'll be able to see kind of the IPs and everything match up. So it's definitely that you can see I've got, I'm now in my DigitalOcean account, just pulling this up now. You can see that IP address matches up. And really the benefit now is in order to access this, what I can do is I could create really granular and locked down firewall controls so that nothing can access this droplet except for connections over this browser-based SSH connection. And so the piece, the kind of the final piece that I wanted to touch on in terms of configuration on the Cloudflare D side, I always like to do it this way because then I'm actually able to do this configuration directly in my browser-based SSH terminal. And it helps kind of show off what I'm doing or how I'm able to use this particular application and kind of how great the latency is and things like that. So what I've done or what I'm gonna show you guys now is I'm gonna step into Cloudflare D, my Cloudflare D directory, which basically Cloudflare D is just a really lightweight daemon that you can install on pretty much any server, any operating system. So Linux, Mac, Windows are all fine. And that then gives me a command line interface to create tunnels, add routes to tunnels, things like that. So stepping into my Cloudflare D directory, you can see I've got some configuration or a certificate to go ahead and authenticate some additional metadata information. And then I also have a config file. And the config file is where I'm actually defining and configuring kind of the last step of creating these inbound connections for these particular applications. So I'm gonna go ahead and open that configuration file up and just kind of talk through what's going on underneath the hood. So within this YAML config file, what I'm able to specify is which ports or which services I want to map to which particular host names. So this is where I'm able to say on a given server for SSH over port 22, which host name do I wanna go ahead and map that to? So in this case, I actually am mapping that to do-ssh.kennyatx.com. And you can see I've mapped it to localhost port 22, which is the standard SSH port. So that is then giving me the ability to now make SSH calls directly in the browser, which I'm doing here. So it's kind of an inception right now. I'm using the tunnel that's powered by this config file to look at the config file of this tunnel. But this really does give me a lot of flexibility to now manipulate anything that I need directly within my DigitalOcean server, all directly from the browser. And then kind of a final benefit or a piece that is already baked into the app within Teams is this authentication request that I've made is now going to be logged as an access login event to the Teams dashboard. So you're gonna be able to see, here's my request four minutes ago. And this is really powerful information if you think about this. Traditionally, SSH is something that's completely driven from a user's machine. I have to do a lot of heavy lifting on my origin server side or my network configuration side, either via a hardware-defined network perimeter or an agent on the user's device or things like that to actually monitor and log the traffic coming over SSH or VNC for a particular user, or really any non-web -based application. So in this case now, without anything installed on my machine, I'm able to see my access to that particular SSH console. So we can see that I hit, I'm calling my app SSH Grafana because that's a droplet that I've got Grafana hosted on. I can see which user did that, where their IP address was, what domain they used, how they connected. So I can see that I logged in over Google, as well as the country that that request is coming from. So you can imagine, you can start to build pretty granular policies or build exception reporting around things like logins from anomalous countries or block bad IPs, really things like that. What I'll mention as well is that all of these logs here, these access request logs, these can be used with Cloudflare's log push and log pull products. So if you have a SIEM tool or a security event and incident management tool like Splunk or Datadog or something like that, you're able to push these events directly into your SIEM and then build alerting off of those. So now what is traditionally a blind spot and a very powerful blind spot, think about what you can actually do with SSH with the right permissions on a particular server. You can really bring that into visibility now. You're able to see and build reporting and alerts around user access to particular resources over SSH. So that's the SSH side. So the final piece that's coming around SSH that is something we're still working on a bit of a proof of concept on, but just kind of as a roadmap sneak preview is we're working on the idea of SSH command logging or SSH session recording to where we'll actually be able to provide a mechanism to replay the actions that a user took directly within an SSH terminal. Because Cloudflare is rendering this terminal at our edge, we do have the ability to actually log the requests being made. So you could imagine in a situation where you have a really significant security incident where something went wrong, either an outside actor took some bad action or was able to breach or an internal user acted maliciously, the ability to replay their session and see exactly what they did on a particular origin server becomes really powerful in piecing together the kind of the scope and breadth of a particular compromise. So this is something that we're working on over the summer. We should hopefully have some details coming out over the next few months. So keep your eyes peeled on the blog and on Twitter and things like that, because we'll definitely make some exciting announcements around that piece as well. That's a piece that I'm just generally very excited about and I geek out about because it's just such a kind of massive security vector that I think we'll be able to help out with. So this is the SSH side of things. If it's interesting to actually set up, if you wanna go ahead and give this a try on your own, Cloudflare for Teams is free to try for up to 50 users. And what I'll actually make a plug for is directly within our developer documentation in our tutorials, we have a very clear tutorial about how to set up an SSH client in the browser with Zero Trust rules. And this starts completely from scratch. You just basically need some server that has access to the Internet. So it could be something on the public cloud. You could use AWS GCP, kind of something like that, DigitalOcean, all the way down to if you have a Raspberry Pi that you've got connected to the Internet at your house, you should be able to do that. I think we actually even maybe have, I think there's a blog about that piece. If you search our blog and look for connecting a terminal via Raspberry Pi, you should see that as well. Excellent. So what I'm gonna go ahead and do next is I'm going to now take you guys quickly through VNC. A lot of the same principles apply, but this was the next step in the evolution of our browser -based Zero Trust apps. I will throw in a bit of a tidbit. It's probably not gonna be our last. We're thinking about additional non-web, traditionally non-web based applications that we could possibly bring to the browser as well. Think things like RDP or SMB file shares. If you have ideas on that, feel free to tweet directly at me at KennyJohnsonATX or at Cloudflare. Let us know your thoughts. If there are things you'd like us to consider, I'd love to hear about those. But we definitely think that there's broader applicability. So the next protocol that we set up and created was VNC. So VNC is basically, if you're not familiar, it's an open source way to render a browser. Traditionally, I would use an on-premise or a machine-based VNC viewer that would allow me to render a remote desktop from either somebody else's machine or a server. This now brings this experience to the browser as well. So very similar to SSH, I am defining a subdomain that I want to go ahead and map to a particular VNC application. I've defined some set of rules. In this case, I think I'm just allowing Cloudflare, but again, I could build really granular policies down to does a user have a hard key plugged into their machine? Is the device corporately managed? Things like that. And then the final piece is instead of SSH, now I've selected VNC as the browser rendering option. So now if I go ahead and pull up a new browser and go to dovnc .kennyatx.com, and then I'm going to go ahead and just, this is my VNC side password again, similar to the root kind of login that I did for SSH. Now this actually gives me a browser-based VNC option. So I've got now just a, this is literally just a, I think it's Ubuntu or Debian. I can't remember which Linux disk image I chose, but this is basically my Linux UI now that I'm running and using directly over the browser. So I can actually just go ahead and run it. I can actually open a browser within a browser. I think I probably have a firewall rule locking that piece down. But what's also fun is I could do like a terminal within a terminal. So now I have my web, I have a web-based VNC powering a terminal. So there's a lot of powerful things that I can start to do with a remote-based desktop like this. This helps me provide a very kind of secure means of using a desktop interface for either external users or users in sensitive countries, or really users working with really sensitive secure data. This gives me a lot of flexibility in deploying and providing those particular resources. So one nice thing here as well is this just typically works with most popular VNC deployments. This is just using TypeVNC, which is just a free open source VNC package out there, but we've tested it pretty broadly across a number of different VNC deployments. It can sometimes be a little tricky to get your VNC configuration properly configured, but once you have that properly configured, we've had a lot of really good success with these particular, with VNC deployments directly within the browser. And again, this is just works. Desktop interfaces are very latency dependent. So this is something that, since this is being powered by the edge, my connection right now, this is just going and hitting Dallas Fort Worth. This is really fast. I'm not seeing a lot of drag in my mouse. It's the user interface is reacting really quickly, which works out well. And I'll say there's also possibilities for doing things like screen recordings in the future, because we're rendering this in the browser. We could do things like replaying user actions for certain key events. That's a little farther afield than what we're considering for SSH command logging, because replaying video and GIFs and things like that might be a little bit more of a challenge, but it is definitely something that we're thinking about. And we'd love to hear people's thoughts on kind of how that might be useful in their businesses or just kind of daily life, if you want to go ahead and create browser-based VNC options. Excellent. And then we'll, we again, we'll be able to see in the access logs, my request being made to the VNC instance. So again, it's just really powerful in terms of being able to see users accessing this, who accessed it, which identity was tied to the particular application. Another kind of interesting piece that we've seen with these browser-based tools is collaboration. I can actually share this particular desktop with another user at the same time. So there's opportunity to collaborate in the same desktop. If somebody else signed in, they'd be able to see me moving my mouse around, dragging these things around. So it opens up some collaboration use cases as well. Excellent. And if you want to go ahead and get started with VNC, similar to SSH, I believe we do have, yeah. So we have the option as well to render VNC through a browser. And because VNC is a little bit trickier to get up and going, than SSH, we actually start with kind of bare metal, just getting started with type VNC from scratch. However, if you are going through and setting this up and you already have an instance of VNC that you like and enjoy, you actually can just, you can skip this first step and then you just basically need to point your VNC server to Cloudflare, create the Zero Trust rule that I showed off, and then you should be ready to roll. Excellent. And I think the piece that I really just want to reiterate is that this is free to try. You can go sign up for Cloudflare for Teams. I'll show you guys what that website looks like. Cloudflare for Teams is free up to the first 50 users. So just, if you just go to Cloudflare.com slash teams and click on get started, that'll help you sign up and get configured with a Cloudflare for Teams dashboard account. If you're an existing Cloudflare user, if you go into the Cloudflare dashboard, go to the dash, I'll show you quickly where that lives. If you just go into your main dashboard view and scroll down to the right and select teams, that'll launch your team session as well. And it'll just take you through some basic setup steps. And again, it's free up to the first 50 users. So we really encourage you to give this a try. The browser-based SSH and VNC are just kind of a small sliver of what you can do with Cloudflare for Teams to bring kind of enhanced Zero Trust security to your team. So I really encourage you to check it out, give it a try, put it on a website, put it on your staging website, give it a go. Excellent. Well, thank you all so much for joining my session to kind of hear about what we're doing with browser-based applications. Stay tuned. We are just getting started. And again, my name is Kenny Johnson. Feel free to reach out on Twitter, LinkedIn. You can probably find me there. Thank you all so much and enjoy the rest of y'all's days wherever you are in the world. Thank you so much. Thank you.