Azure Bastion is a platform-as-a-service (PaaS) offering in Microsoft Azure that increases the security posture of your company by removing any RDP/SSH connections from the Internet to your VMs. The way the service works is simple but it provides an extra layer of security and protection for your infrastructure-as-a-service (IaaS) VMs running in Azure. From the Azure Portal, the operator can connect using Azure Bastion, and that requires only a secure 443 port from the Azure Portal to the Azure Bastion host. The second portion of the connection takes place inside of the protected virtual network, and communication from Azure Bastion on either port 22 (SSH, Linux) or 3389 (RDP, Windows) is required to connect.
The solution is deployed at the virtual network level. The solution is scalable, and there is no additional configuration from the cloud administrator and does not require any other software. The only requirement is an HTML 5 browser.
If you are a company that is exposing your VMs on the Internet, this is a perfect solution and also saves cost where no public IPs are required on your VMs to receive remote control on day-to-day operations. If you do have VPN/ExpressRoute or NVAs, you may have some layer of protection, but Azure Bastion is still a valid option to avoid all the RDP and jump boxes VMs on your environment.
Creating the Azure Bastion
The first step is to go to your virtual network and check the address space item and validate the current size of your virtual network. We need a /27 subnet to be added to the virtual network.
If you don’t have enough room, for example, if your virtual network has an address space of 10.0.0.0/24, then it is recommended to increase it to /16 before moving forward.
Here’s how to add the subnet required for the Azure Bastion service. Click on subnets in the virtual network blade, and click on Add Subnet. The name of the new subnet must be AzureBastionSubnet, and the address range must use /27.
You shouldn’t configure any route table to this subnet. A network security group will be associated when we lock down the resource in the next section. However, the current configuration configured in this section will be enough to get the service running.
The final step is to create a new resource: Click on Create a resource or search for Bastion on the global search. In the Create a Bastion blade, we need to define the resource group, name, and region. In the same location, we also need to select the virtual network. The subnet will be filled out automatically and create a new public IP address that will be used by the service.
Using Azure Bastion service
At this stage, we have configured the Azure Bastion service and we have placed a VM in the default subnet of the same virtual network. To use the service, in the properties blade of the desired VM, click on Connect and then on Bastion.
Another method introduced recently is using the Connect item, which is located in the same VM’s properties.
In the new blade, provide the credentials (username and password) and the cloud administrator can choose between opening the session on the existing browser or a new window (my recommendation), click on Connect.
Behind the scenes, your browser is connected securely through port 443 in the Azure Bastion service. A connection is being created from the Azure Bastion subnet to the server within the virtual network. As long as the network security groups are following the recommendation from the previous section, the result should be a new server console in the web browser.
After connecting to the VM, we can copy and paste content between the host and virtual machine. There is an icon on the left side (Item 1), click on it, and a new dialogue box will be displayed, and that is the working memory used by copy and paste commands between your laptop and the VM. If you copy something in the VM, the content will be placed in that area, and you can use that information on the host.
You may be wondering about copying files between your workstation and the VM. At the time of this writing, such a feature wasn’t available — neither direct copy nor paste. That is a great security feature where we guarantee that only secure sources have direct contact with your VM, thus ensuring the clean source principle and in some scenarios saving you the trouble of creating a Privileged Administration Workstation (PAW) machine.
Permissions required to use Azure Bastion service
The documentation states that the user trying to use the service must have at least read permissions at the VM level, NIC level, and on the Azure Bastion resource.
If you assign the role virtual machine user login at VM/resource group or even subscription, and reader to the Azure Bastion host resource, that would be enough to get the user to connect on the VM.
Another possibility is to create a group either in Azure AD or synchronized from on-premises. Then, assign the same roles above to that group in the specific resources that you plan to grant access, and then add users to the group to give them access to connect to the VMs using Azure Bastion Service.
Understanding the traffic flow and protection using network security groups
To lock down Azure Bastion, we can start with at least one network security group being assigned to the Azure Bastion subnet and another one being associated with one or more subnets.
I recommend associating network security groups to a subnet instead of network adapters. Either way, we need to make sure that we allow connections from Azure Bastion subnet to the VMs within the same virtual network.
Here’s how to create a new network security group: In the new blade, in the Source options, we will select IP Addresses and 10.0.10.0/27, which is the range associated with the Azure Bastion service. In the destination port ranges, we will add 3389, 22 (if you don’t have Linux or Windows, you can remote from the list), and define a priority and name to match your requirements.
Note: If you have a network security group in place, you can just add the rule above to the existing NSG.
The second network security group is the one that we need to associate with the Azure Bastion subnet. A summary of the rules required
- Inbound security rules
- 443 from Internet
- 443 and 4443 from GatewayManager (service tag)
- Outbound security rules
- 22 and 3389 to VirtualNetwork (service tag)
- 443 to AzureCloud (service tag)
After creating the new network security group, make sure to associate it with the Azure Bastion subnet, as depicted in the image below.
Those are the required steps to get your Azure Bastion service up and running on your Azure environment. As you may have noticed, it is a straightforward process and, in a few minutes, you can get rid of jump boxes that you need to maintain updates, remove public IPs from your VMs, and save tons of recommendations from Azure Security Center.
Featured image: Shutterstock