Best Practices for securing access to your Azure Virtual Machines

Tim Tetrick

When using a public cloud service like Microsoft Azure, securing access to your Virtual Machines should be a primary security concern.  With that in mind, I wanted to share with you some best practices you can use to help reduce your exposure to attacks.

Username/Password

Hackers utilize brute force tools that try frequently used usernames and passwords.  So the first step is to make sure and utilize complex usernames and passwords for your VMs.  Azure helps you out here by not allowing common usernames like “Admin” or “Administrator” when creating your VMs.  Azure also requires passwords to be at least 8 characters long and must contain 3 of the following: a lowercase character, an uppercase character, a number, a special character.  Azure will also not allow commonly used complex passwords such as “Pass@word1”.

Endpoints

Endpoints allow you to communicate with your VM from the Internet.  When creating a Windows VM in Azure, two endpoints get created by default to help you manage the VM - Remote Desktop and PowerShell.  The first recommendation with respect to endpoints is to eliminate any endpoints you don’t need and to only add them when and while you need them.  If you must have an endpoint open, the recommendation is to change the public port that is used whenever possible.  For example, with Remote Desktop, it is recommended to change the public port to something other than the popularly known default of 3389 to help reduce your exposure.  Once again, Azure helps you out here.  When creating a new Windows VM, by default the public port for Remote Desktop is set to “Auto” which means a random public port will get automatically generated for you.

Access Control Lists

To further protect yourself, you can manage incoming traffic to the public port by configuring rules for the network access control list (ACL) of the endpoint.  An ACL provides the ability to selectively permit or deny traffic for a virtual machine endpoint for an additional layer of security.  Using Network ACLs, you can do the following:

• Selectively permit or deny incoming traffic based on remote subnet IPv4 address range to a virtual machine input endpoint.
• Blacklist IP addresses
• Create multiple rules per virtual machine endpoint
• Specify up to 50 ACL rules per virtual machine endpoint
• Use rule ordering to ensure the correct set of rules are applied on a given virtual machine endpoint (lowest to highest)
• Specify an ACL for a specific remote subnet IPv4 address.

For instructions on configuring ACLs for your Azure Virtual Machine endpoints, see How to Set Up Endpoints to a Virtual Machine under Manage the ACL on an Endpoint.  For more info, see About Network Access Control Lists (ACLs).

Site-to-Site VPN and Point-to-Site VPN

Creating a Site-to-Site VPN connection between your on-premises network and your Virtual Network in Azure gives you a secure, dedicated, IPsec tunnel for communicating.  With a Site-to-Site VPN connection in place, you can completely remove certain public endpoints and then just connect via the internal ports like you would with any other machine on your internal network.  For example, you could remove the Remote Desktop endpoint in your VM and then just connect directly to the VM over the standard RDP port 3389 via the secure VPN tunnel.  There’s no better way to reduce external threats than to completely remove the public facing endpoint!

For general guidance on setting up and configuring a Site-to-Site VPN connection, see Configure a Site-to-Site VPN in the Management Portal.  Also take a look at my colleague Rob Waggoner’s blog Windows Azure: Setting up Synchronization between an On-Premises Infrastructure and Windows Azure with Windows Server 2012 R2 in which he walks through the steps of specifically using RRAS (Routing and Remote Access) services within Windows Server 2012 R2 to configure a Site-to-Site VPN connection.

With a Point-to-Site VPN connection, you can have a secure connection directly from your computer to your Virtual Network without having to acquire and configure a VPN device like you do for a Site-to-Site VPN connection.  Just like with Site-to-Site, Point-to-Site also allows you to completely remove public endpoints and connect directly to the Virtual Machine over the secure VPN connection.  For more information, see Configure a Point-to-Site VPN in the Management Portal.

Thanks for reading!