Securing Remote Access to Azure Virtual Machines over the Internet

imageAccess to virtual machines when you run them on-premises is easy – just RDP into a VM over your local network. We’ve been doing that for years and not much has changed, other than the fact that the RDP protocol is a lot more secure and more performant than it was years ago.

What about virtual machines you want to manage but don’t accessible over the network using RDP or other remote management protocols? These VMs might be components of your core on-premises infrastructure, such as domain controllers, DHCP servers, DNS servers or certificate servers.

No problem with that. On-premises you have console access to those high-value asset machines. If you’re a virtualization infrastructure or fabric administrator, all you have to do is use console access. Even if you’re not a virtualization or fabric admin, you can still request permissions to gain console access to the VMs that you’re responsible for.

Let’s switch our attention to VMs in the cloud. In the cloud (in this case Microsoft Azure), you also have virtual machines that you can access over RDP. The big difference here is that in most cases, when you RDP into your virtual machines in Azure, you’re doing it over the Internet (this exception would be when you’re RDP’ing into a VM in Azure from another VM in Azure).

You might say to yourself “well, I don’t know if I’m sure I want to use RDP over the Internet or even leave RDP open to the Internet to those virtual machines, I’ll just log into the Azure Management Portal and use console access”. The problem is that console access isn’t available to you, so if you don’t want to use RDP over the Internet, you’ll have to think about other options.

Of course, RDP isn’t the only remote management option available to you. You can use SSH for your Linux deployments and Remote PowerShell for Windows. Still, you might be hesitant to use these remote access protocols over the Internet for certain very high value assets that you would like to lock down.

Note that for other assets, RDP, Remote PowerShell and SSH can be considered secure protocols and you can use them with confidence. By default, when you configure the virtual machine as an RDP endpoint, the public port exposed to the Internet is randomized to a high number port. This means that the default RDP port (TCP or UDP 3389) isn’t used. An attacker will would need to scan a large port range for RDP responses before even being able to attempt a connection.

When you select the Remote PowerShell or SSH protocols for remote access, the public port by default will be the well-known port. However, you can take advantage of port randomization here too by leaving the Public Port value empty. This will show as AUTO in the endpoint configuration, as you can see in the figure below.

clip_image002

In addition to taking advantage of port randomization, you can also configure endpoint ACLs for these protocols. An endpoint ACL allows you to control which IP address, or CIDR subnet of addresses, you want to allow access over that management protocol. For example, if you only wanted source addresses in the range 131.107.0.0/16 to connect to your VMs using RDP, SSH or Remote PowerShell over the Internet, you could create an endpoint ACL to make that happen. The figure below shows you would that would look like.

clip_image004

You can significantly enhance security by requiring complex passwords for remote management access so that brute force attacks won’t be able to easily guess your passwords. For RDP connections, there are other things you can do improve security. Configure Security Settings for Remote Desktop Services contains many of these.

You can see that for your non-high value assets, using the remote management protocols can be used in a secure fashion. But, what are your remote management alternatives for locked down high-value assets that you don’t want to allow RDP, SSH or Remote PowerShell access to over the Internet? Good question! To find out, check out the article Lock down network access to virtual machines on Azure virtual networks.

Thanks!

Tom
Tom Shinder
Project Manager, Azure Security Engineering
@tshinder | Facebook | LinkedIn | Email | Web | Bing me! | GOOG me!

image