Skip to main content


Lock down network access to virtual machines on Azure virtual networks

Published: August 27, 2015

Author: Tom Shinder, Program Manager, Microsoft Azure Security Engineering

When you run virtual machines in Azure Infrastructure as a Service (IaaS), there are a number of things you can do from a network perspective to lock down your installation. The good news is that network security on Microsoft Azure has a lot in common with the network security concepts and implementation that you use on premises. The trick is to know the names of the relevant features and services in Azure and map them to what you already know.

Here’s three tips that you might find useful when thinking about network security for your IaaS virtual machines in Azure.

Control endpoint access

Virtual machines located on an Azure Virtual Network can be configured as “endpoints”. When you configure a virtual machine to be an endpoint, you make it possible for devices located on the Internet or on other Azure Virtual Networks to connect to the virtual machine.

For example, if you configured a virtual machine to be a web server and you wanted users located on the Internet to reach that virtual machine, you would configure that virtual machine to be an “endpoint” that’s reachable through HTTP or HTTPS.

When you use the “classic” Azure Portal and create a new virtual machine with the graphical interface, you’ll notice that there are default endpoints offered to you. These allow access to the virtual machine for Remote Desktop, Windows PowerShell Remoting, and Secure Shell (SSH). If you want to allow per virtual machine access using these protocols, that’s fine. But if you don’t, make sure that you disable endpoint access for these protocols.

You can learn a lot about endpoints and how to configure or disable them by reading How to set up endpoints to a virtual machine.

Use point-to-site VPN for management

When you allow endpoint access to virtual machines for the purpose of managing them, you still have to authenticate. You’ll use credentials that are appropriate to the virtual machine you’re connecting to. If the machine is domain joined, you might use domain credentials. If the machine is standalone, then you’ll be using local credentials.

A more secure method for remote management would be remove the management endpoints and use a point-to-site VPN connection from your management workstation to connect to the Azure Virtual Network. While the name “point-to-site” might be new to you if you’re a virtual networking veteran, rest assured that’s it’s nothing more than a remote access client VPN connection to the Azure Virtual Network, no different than the remote access VPN client connections enterprises have been using for years. The VPN protocol uses the Secure Socket Tunneling Protocol (SSTP), which uses HTTPS as its transport and allows the connection to traverse firewalls and web proxies that allow outbound HTTPS (SSL/TLS).

The reason why this is considered more secure is that you have to authenticate to the VPN gateway at the edge of the Azure Virtual Network before you’re allowed access to the virtual machines on that network. For the point-to-site connection, certificate-based authentication is used. This means that in order to reach the VMs for management, you have to authenticate twice, using two different authentication methods:

  • First, you need to authenticate with the Azure VPN gateway using certificate-based authentication.
  • After you are authorized and allowed access to the network, you need to authenticate with the virtual machines you want to manage, using your preferred management protocol ( RDP, SSH or Remote PowerShell).

For more information on Azure point-to-site configuration, check out About secure cross-premises connectivity for virtual networks.

Segment your network based on roles and use Network Security Groups

Network segmentation is standard practice on-premises and you can do the same on Azure Virtual Networks. When you create an Azure Virtual Network, you’re asked for an address space. After you define the address space, you can subnet it. You can reduce your operational overhead and improve security (by reducing complexity) by assigning network-based roles to your subnets.

For example, you might want to put all your web front-ends in the same subnet. This allows you to simplify network access controls by allowing only HTTP/HTTPS to servers on that subnet (although you might want to also allow protocols for management traffic). When you add more front-end virtual machines to the subnet, you don’t need to change your network access controls.

This begs the question “how do I enforce network access controls to and from Azure Virtual Network subnets?”

The answer is Network Security Groups. You can think of a Network Security Group as a type of stateful packet inspection network device, where you can create up to 200 network access control rules. Rules can be created to control inbound and outbound traffic to and from a virtual machine or all virtual machines on an Azure Virtual Network subnet. Using the example in the previous paragraph, you can create a Network Security Group with a rule that allows inbound access to HTTP/HTTPS for your web front-end virtual machine subnet.

The article What is a Network Security Group (NSG)? has a ton of excellent information on how to use Network Security Groups. For a comprehensive view on all things related to security on Azure networks, download the Azure Network Security guide.

About the Author

Tom Shinder is a Program Manager with the Microsoft Azure Security Engineering. Prior to his current role, he worked in Microsoft's Server and Cloud Division Information Experience (SCD iX) Solutions Team, where his focus was private cloud architecture, with a special focus on private cloud security and cloud infrastructure technologies.

Microsoft Security Newsletter

Sign up for a free monthly roundup of security news, bulletins, and guidance for IT pros and developers.