- Install Ansible on Windows - Thu, Jul 20 2023
- Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
- Azure Virtual Desktop: Getting started - Fri, Apr 14 2023
The first question any new cloud administrator asks after successfully deploying their first Windows Server VM is, "Okay, now how do I make a Remote Desktop Connection (RDP) to the server?" I'm going to start this lesson with the connection method you should definitely consider last, after which I'll explain what Azure Bastion is, how to set it up, and how you can use it to remotely manage your Azure VMs from over the Internet.
Avoid this configuration at all costs
Unless you have a predefined business case that requires direct inbound access to your Azure VMs from the Internet, do NOT associate an Azure public IP address with your VMs. Why? Because Microsoft makes all their public IP addresses available to the public for download, and I guarantee that your VM will be flooded with RDP brute force attacks within minutes or hours at the most.
Microsoft publishes its owned public IP ranges to support hybrid cloud customers whose firewall administrators are required to specify discrete Azure endpoint IP addresses. This transparency, of course, means bad actors run port scans against those IP ranges 24 hours a day, 365 days a year.
Deploy Azure Bastion
Azure Bastion is a platform-as-a-service (PaaS) offering that gives you a secure entry point into your virtual network infrastructure. Under the hood, I suspect Azure Bastion is a VM scale set running a specialized version of Remote Desktop Services. I say "specialized" because you can make both RDP and Secure Shell (SSH) administrative connections to your Azure VMs.
Azure Bastion obviously has an Azure public IP endpoint, but the service listens only on TCP 443. Therefore, the Bastion appears to be an HTTPS web server to the rest of the world.
As you can see in the following network topology diagram, you deploy Azure Bastion in an empty subnet of at least /26 size named AzureBastionSubnet; that's a reserved name, so don't mistype it.
Hub and spoke VNet architecture with Azure Bastion
Also, remember that you'll only be able to deploy Bastion to a VNet (and associated VMs) in the same Azure region.
Of course, in the real world, you'll want to deploy Azure Bastion via infrastructure-as-code (IaC). Here's one of Microsoft’s quickstart Bicep templates, which creates an Azure Bastion instance in an Azure VNet.
After the Bastion is up and running, that's really it. Sadly, the Bastion can't be paused, so you're paying for the service 24 hours a day, regardless of when or how much you use it. On the other hand, you can use a Bastion deployed to a hub VNet to reach Linux and Windows Server VMs in peered spoke VNets (central VNet [hub] that serves as a gateway for other VNets [spokes]). That didn't used to be the case. I'm grateful the option now exists to save customers' money.
Connect to your VM through Azure Bastion
Historically, you had to tunnel through Azure Bastion to reach your Azure VMs using an HTML5-capable web browser, as shown in the following screenshot.
Connecting to an Azure VM via Bastion in the Azure portal
Be sure to disable your browser's popup blocker for azure.com, or you'll never complete the connection!
However, nowadays, you can use the Azure command-line interface (CLI) to make Bastion remote administration connections using native RDP and SSH client applications. Here's the step-by-step on using the native Microsoft Remote Desktop Connection client with Bastion:
- Install Azure CLI, open a command or PowerShell prompt, and run az login to get connected to your target Azure subscription.
- Obtain the resource ID of your target VM by running the following command:
az vm show –name <vm-name> --resource-group <rg-name> --query id –output tsv
- Make the RDP connection by running the following command:
az network bastion rdp --name <bastion-name> --resource-group <rg-name> --target-resource-id <vm-resource-id>
The Remote Desktop session will default to full screen and stretch across all your monitors; this isn't optimal, at least not for me. The az network bastion rdp command has a --configure flag that opens the standard Remote Desktop Connection client, from which you can set screen resolution and all the usual options.
Managing the Azure Bastion
As I mentioned earlier, there really isn't much to Azure Bastion. When you're finished with your remote administration session, you simply close the browser tab.
As you can see in the screenshot below, the Azure portal shows you who's connected to the Bastion, and you can force-disconnect them. Bastion also allows you to administrate the shared text clipboard feature, although I personally find it really handy for passing PowerShell into my target VM.
Managing Bastion connections in the Azure portal
Combine Azure Bastion with Just-in-Time VM Access
We'll finish up with a technique to further improve the security of your Azure VM environment. Just-in-Time VM Access (JIT VM Access) is a feature of Microsoft Defender for Cloud Standard that locks down the administrative ports (in our case, TCP 3389, the default RDP port) until you make an explicit connection request.
After the connection request is approved, the virtual network interface card (vNIC)'s network security group (NSG) gets a time-limited Allow rule that enables the connection. Once the time window expires, Microsoft Defender for Cloud closes the NSG rule. Clever, eh?
As long as (a) the Windows Server or Linux VM has a vNIC-associated NSG, and (b) the VMs are enrolled in Microsoft Defender for Cloud Standard, you can set them up for JIT VM Access. Once you've done so, here's how to combine the feature with Azure Bastion:
- Request access to connect to the VM using JIT VM Access (as shown in the following screenshot). Ignore all the errors saying the IP address prerequisite isn't met.
- Once access is granted, authenticate to Azure Bastion as usual, either in Azure portal or with a native client.
Requesting an administrative VM connection with JIT VM access
Wrap-up
The focus of this article is to make secure, inbound Internet connections to your VMs by implementing Azure Bastion. However, some other options for you to consider include:
Subscribe to 4sysops newsletter!
- Destination Network Address Translation (DNAT) through Azure Firewall, Azure Virtual Network Gateway, or Azure Application Gateway
- Deploying your own purpose-built Azure-based jump host VM
Unless something changed in the last year, as it was the last time I used Bastion, the underlying service is or was based on Apache Guacamole. I personally run my own instance of Guacamole which is far better than the version Microsoft was running at the time, oh and if course it’s free whereas Bastion isn’t.
Would firewall rules limiting incoming RDP to only a few allowed IPs not be sufficient for RDP security?
Just wondering, why I wouldn’t run a VPN to protect my RDP traffic instead?