Administrators who want to manage virtual machines securely but want to avoid complicated jump server setup and maintenance have a new option at their disposal.
When you run Windows Server and Linux virtual machines in Azure, you need to configure administrative access. This requires communicating with these VMs from across the internet using Transmission Control Protocol (TCP) port 3389 for Remote Desktop Protocol (RDP), and TCP 22 for Secure Shell (SSH).
You want to avoid the configuration in Figure 1, which exposes your VMs to the internet with an Azure public IP address and invites trouble via port scan attacks. Microsoft publishes its public IPv4 data center ranges, so bad actors know which public IP addresses to check to find vulnerable management ports.
The problem with the network address translation (NAT)/load balancer method is your security team won't like it. This technique is security by obfuscation, which is to say it does not make things more secure. It's more of a NAT protocol hack.
Figure 1. This setup exposes VMs to the internet with an Azure public IP address that makes an organization vulnerable to port scan attacks.
Another remote server management option offers illusion of security
If you have a dedicated hybrid cloud setup with site-to-site virtual private network or an ExpressRoute circuit, then you can interact with your Azure VMs the same way you would with your on-premises workloads. But not every business has the money and staff to configure a hybrid cloud.
Another option, shown in Figure 2, combines the Azure public load balancer with NAT to route management traffic through the load balancer on nonstandard ports.
Figure 2. Using NAT and Azure load balancer for internet-based administrative VM access.
For instance, you could create separate NAT rules for inbound administrative access to the web tier VMs. If the load balancer public IP is 1.2.3.4, winserv1's private IP is 192.168.1.10, and winserv2's private IP is 192.168.1.11, then you could create two NAT rules that look like:
Inbound RDP connections to 1.2.3.4 on port TCP 33389 route to TCP 3389 on 192.168.1.10
Inbound RDP connections to 1.2.3.4 on port TCP 43389 route to TCP 3389 on 192.168.1.11
The problem with this method is your security team won't like it. This technique is security by obfuscation that relies on a NAT protocol hack.
Jump servers are safer but have other issues
A third method that is quite common in the industry is to deploy a jump server VM to your target virtual network in Azure as shown in Figure 3.
Figure 3. This diagram details a conventional jump server configuration for Azure administrative access.
The jump server is nothing more than a specially created VM that is usually exposed to the internet but has its inbound and outbound traffic restricted heavily with network security groups (NSGs). You allow your admins access to the jump server; once they log in, they can jump to any other VMs in the virtual network infrastructure for any management jobs.
Of these choices, the jump server is safest, but how many businesses have the expertise to pull this off securely? The team would need intermediate- to advanced-level skill in TCP/IP internetworking, NSG traffic rules, public and private IP addresses and Remote Desktop Services (RDS) Gateway to support multiple simultaneous connections.
For organizations that don't have these skills, Microsoft now offers Azure Bastion.
What Azure Bastion does
Azure Bastion is a managed network virtual appliance that simplifies jump server deployment in your virtual networks.
Azure Bastion is a managed network virtual appliance that simplifies jump server deployment in your virtual networks. You drop an Azure Bastion host into its own subnet, perform some NSG configuration, and you are done.
Organizations that use Azure Bastion get the following benefits:
No more public IP addresses for VMs in Azure.
RDP/SSH firewall traversal. Azure Bastion tunnels the RDP and SSH traffic over a standard, non-VPN Transport Layer Security/Secure Sockets Layer connection.
Protection against port scan attacks on VMs.
How to set up Azure Bastion
Azure Bastion requires a virtual network in the same region. As of publication, Microsoft offers Azure Bastion in the following regions: Australia East, East U.S., Japan East, South Central U.S., West Europe and West U.S.
You also need an empty subnet named AzureBastionSubnet. Do not enable service endpoints, route tables or delegations on this special subnet. Further in this tutorial you can define or edit an NSG on each VM-associated subnet to customize traffic flow.
Because the Azure Bastion supports multiple simultaneous connections, size the AzureBastionSubnet subnet with at least a /27 IPv4 address space. One possible reason for this network address size is to give Azure Bastion room to auto scale in a method similar to the one used with autoscaling in Azure Application Gateway.
Next, browse to the Azure Bastion configuration screen and click Add to start the deployment.
Figure 4: Deploying an Azure Bastion resource.
As you can see in Figure 4, the deployment process is straightforward if the virtual network and AzureBastionSubnet subnet are in place.
According to Microsoft, Azure Bastion will support client RDP and SSH clients in time, but for now you establish your management connection via the Connect experience in Azure portal. Navigate to a VM's Overview blade, click Connect, and switch to the Bastion tab as shown Figure 5.
Figure 5. The Azure portal includes an Azure Bastion connection workflow.
On the Bastion tab, provide an administrator username and password, and then click Connect one more time. Your administrative RDP or SSH session opens in another browser tab, shown in Figure 6.
Figure 6. Manage a Windows Server VM in Azure with Azure Bastion using an Azure portal-based RDP session.
You can share clipboard data between the Azure Bastion-hosted connection and your local system. Close the browser tab to end your administrative session.
Customize Azure Bastion
To configure Azure Bastion for your organization, create or customize an existing NSG to control traffic between the Azure Bastion subnet and your VM subnets.
Secure access to VMs with Azure Bastion.
Microsoft provides default NSG rules to allow traffic among subnets within your virtual network. For a more efficient and powerful option, upgrade your Azure Security Center license to Standard and onboard your VMs to just-in-time (JIT) VM access, which uses dynamic NSG rules to lock down VM management ports unless an administrator explicitly requests a connection.
You can combine JIT VM access with Azure Bastion, which results in this VM connection workflow:
Request access to the VM.
Upon approval, proceed to Azure Bastion to make the connection.
Azure Bastion needs some fine-tuning
Azure Bastion has a fixed hourly cost; Microsoft also charges for outbound data transfer after 5 GB.
Azure Bastion is an excellent way to secure administrative access to Azure VMs, but there are a few deal-breakers that Microsoft needs to address:
You need to deploy an Azure Bastion host for each virtual network in your environments. If you have three virtual networks, then you need three Azure Bastion hosts, which can get expensive. Microsoft says virtual network peering support is on the product roadmap. Once Microsoft implements this feature, you can deploy a single Bastion host in your hub virtual network to manage VMs in peered spoke virtual networks.
There is no support for PowerShell remoting ports, but Microsoft does support RDP, which goes against its refrain to avoid the GUI to manage servers.
Microsoft's documentation does not give enough architectural details to help administrators determine the capabilities of Azure Bastion, such as whether an existing RDP session Group Policy can be combined with Azure Bastion.
Dig Deeper on Microsoft messaging and collaboration
