One of the inherent challenges with an organization’s shift to the cloud is the removal of network boundaries. This becomes an even bigger risk when you expose remote management protocols like RDP or SSH to the Internet. Brute force attempts have long been a risk of RDP, but 2019 has introduced even more vulnerabilities for RDP. BlueKeep was discovered in late 2018, which lead to a flurry of remediation efforts across enterprises. But in August 2019 four new vulnerabilities were disclosed. Nicknamed “DejaBlue” by researcher Michael Norris, these this includes the following vulnerabilities:
The only guaranteed remediation is to begin removing RDP from your environment. But there really haven’t been effective alternatives to RDP until recently. This summer Microsoft has added a new option remote management option with Azure Bastion. Azure Bastion is a PaaS connection service for Azure Virtual Machines. Users have to successfully authenticate to the Azure Portal first, and then have access to the Virtual Machine through the web browser. It’s available for RDP as well as SSH. Another important distinction over Azure Bastion is that it does not require the virtual machine to have a public IP address, which greatly reduces the attack surface of the virtual machine.
As of August 2019, Azure Bastion is still in Preview. That means it’s not available in the standard Portal yet. You can access the Azure Bastion using the Preview Portal.
Azure Bastion is a PaaS offering, which means that Azure manages all the underlying components. The only part you have to configure is the VNet and the subnets and making sure your virtual machines are in the right networks.
Enabling Azure Bastion
Access the Preview Portal and navigate to Virtual Networks. Create a new Virtual Network. Ensure it has a large enough address space for virtual machines and a subnet for Azure Bastion. Make sure to adjust the default subnet to not include the entire address space.
Access the newly created VNet and add a new subnet called “AzureBastionSubnet”, it needs at least a /27 or larger address block. Also, the name has to be exact, or it will not be detected when you try to enable the Bastion service.
Create a new resource and search for “bastion”. Select Azure Bastion and click Create. Specify the Name, Resource Group, Region. For the Virtual Network, specify the one you just created, and the AzureBastionSubnet you created. Leave a new public IP selected. Review the configuration and create it.
Once the Bastion creation completes it can be used by a Virtual Machine. When creating a new Virtual Machine make sure to use the same Resource Group and Region as the Azure Bastion service. Also, make sure you don’t enable a Public Inbound IP address. On the Networking tab, make sure to use the VNet tied to the Bastion service, and the default subnet. Ensure there is no Public IP or Inbound Ports.
Create the VM. Once it’s created, when you click the Connect it will give you a third option for Bastion.
Provide the VM administrator username and password and click connect. Another browser window will open connecting the Bastion service. You’ll see a URL like https://bst-ee2acdbd-5338-4c64-a3df-bf39da499686-0.bastion.azure.com
Summary
For the most part, I think Bastion is a great service, and certainly something that Azure has needed for along time. In a lot of scenarios, it will greatly improve security, especially for smaller organizations who do not use Express Route or other VPNs into Azure. Not having to expose RDP or SSH on the Internet is a must-have with the risks in those protocols.
It’s not clear if Microsoft will eventually charge for Bastion, but given that it has resources associated with it, I would assume they will. We can certainly hope for the good of the community they will provide it free of charge.
I’ve noticed a few quirks with the service, sometimes when you first create a Bastion and VM, the Bastion will not connect. After a little while its available. But all in all, I think Bastion is a good tool in the toolbox.
Photo by Jos Bakker on Unsplash
