Securing access to your Windows Azure Virtual Machines

A few days ago Alan Smith (Windows Azure MVP) started a discussion about the “Virtual Machine hacking” thread on the MSDN forum and how we could protect our Virtual Machines. Let’s take a look at our options for reducing the attack surface of a Windows VM (some options can also be applied to Linux VMs).

The problem

When you create a new Windows Server Virtual Machine from the gallery you’ll see that you can’t change the username (defaults to Administrator). This means anyone who could access your Virtual Machine already knows your username is Administrator.

After your Virtual Machine has been created you’ll also see that the VM already has 1 endpoint defined:

Port 3389 allows you to connect to a machine using the Remote Desktop Protocol (RDP) and opening this endpoint means anyone can try to connect to your Virtual Machine. If you do a quick search on Google Bing you’ll find plenty of RDP brute force tools which can be used to try and connect to the VM using different usernames and passwords (or you can build your own using the RDP ActiveX control and the IMsRdpClientNonScriptable interface). These brute force tools will try frequently used usernames and passwords. After that they’ll try to generate some more random passwords. But guess what… Administrator is a frequently used username.

So if you leave this open for a while there’s a high chance that you’ll see this in the Event Log of the VM:

Change the public port

A good start would be to change the public port:

This way people will have a harder time to guess what the port is for and you’ll probably already secure your VM from all those kiddie scripters. But the port is still open, meaning anyone who does a full portscan on each IP in the Windows Azure IP Address range could find this open endpoint. With the required tools they’ll also be able to see that this port is for RDP.

Change the administrator username

Ok so we kinda applied security through obscurity. What if we could make it harder for those tools by renaming the default Administrator user? This is very easy to do with Powershell:

This script will rename the Administrator user to a generated random username (with some allowed special characters). Make sure you also have a complex password and the bruteforce tools will have a hard time guessing the username/password combination.

I noticed a few issues after renaming the Administrator account (like IE not working) and simply rebooting the the Virtual Machine fixed the issues.

Improving security for the public port

This still leaves us with 1 issue, anyone connected to the internet could connect to our public port. But this can easily be changed using the Windows Firewall (in Control Panel > System And Security). You’ll see that the Windows Firewall contains 2 rules for RDP:

By double clicking these rules you can specify an IP address range which can access to these ports:

Add your static IP or your IP range(s) if you don’t have a static IP. If you press OK or Apply the firewall immediately applies these changes, so be careful and make sure you don’t lock yourself out.

Looks like we did it. RDP is only accessible from our machine/corporate network and we renamed the Administrator user to something complex.

Removing the RDP endpoint and using Windows Azure Connect

Using the Windows Firewall to secure the RDP port is ok for small deployments, but what if you have a whole farm you need to manage like this? There is an other way to secure the public endpoint… by removing it. Hackers won’t be able to connect to the endpoint but you won’t either.

The solution here would be to create an IPSec connection between your machine(s) and the Virtual Machines in Windows Azure (Virtual Networks would also be a solution but this means you would need specific hardware). Setting up this IPSec connection is possible with Windows Azure Connect. Simply go to the old portal (http://windows.azure.com) and navigate to the Virtual Network > Connect tab.

The Connect tab allows you to download the Windows Azure Connect Endpoint Software (because of the activation token you’ll need to download it once per machine you want to install it on). Click the Install Local Endpoint button to download and install the software on your machine and on the Virtual Machine:

After installing the software on your machine and your VM you’ll see them show up under endpoints:

Finally you need to create a group, add both machines in the group and check the “Allow connections between endpoints in group” option:

That’s it! Your machines are connected. And the advantage here is that, when other people need access to the VM, they can simply install the software and you can add them to the group for that VM.

Take a look at the Windows Azure Connect icon next to your clock (the tooltip should say Status: Connected). You should also be able to resolve the IP of the Virtual Machine (by using ping <vmname> for example):

You can now safely remove the endpoint and connect directly to the VM:

And in case there is an issue with Windows Azure Connect, you can simply add the public endpoint for RDP to connect to your VM and fix the issue.

Opening the endpoint when you need it

Michael Washam also had a great tip concerning the Remote Desktop endpoint. You could simply remove the endpoint and only add it whenever you need it (something you can automate with PowerShell):

Enjoy!

About Sandrino Di Mattia

Sandrino Di Mattia is a Windows Azure Consultant at RealDolmen and a Windows Azure Insider. He lives and breathes Windows Azure.

  • http://www.cloudstaff.com/ Hoyt Velasquez

    This is a great post on accessing Windows Azure in virtual machines. Thanks for sharing.

  • http://www.process-box.com/ Clarissa Lucas

    Security is really a problem when it comes to this. Good thing you made these good observations. Your tips are worth trying. This post is a good read.