In part 1 of this series, I began the discussion about hybrid network infrastructure with some thoughts regarding what hybrid clouds are about, and then talked about some of the networking functionality that you get when you adopt Azure Infrastructure Services. There was also an introduction to the Datacenter Extension Reference Architecture Diagram that Tom put together with Jim Dial and several other people at Microsoft. In part 2, Tom joined in as co-author and we went over site to site VPNs and point to site VPNs. In part 3 we took a look at the Azure dedicated WAN link service, which goes by the name of ExpressRoute, and also discussed the Azure Virtual Gateway, which is located on the edge of your Azure Virtual Network and enables you to connect your on-premises network to an Azure Virtual Network.

Then in part 4, we spent the bulk of our time discussing what Azure Virtual Networks are and how they compare to the virtual networks we use in traditional on-premises Hyper-V installations. Part 5 went into a little more detail on Azure Virtual Networks and some special considerations you need to take into account. In Part 6, we discussed Azure Virtual Networks and external load balancers. In Part 7, we began our discussion on the subject of internal load balancing and on how to use PowerShell to configure ILB for virtual machines that are contained within an Azure Virtual Network. In Part 8, we moved on to how to configure ILB for Cloud Services by editing the .cscfg file, and then talked about Network Security Groups

We will now continue working our way through our list of network capabilities that are available in Azure at the time this article was written (always keeping in mind that Azure is constantly changing and growing and adding new functionalities):

√ Site to site VPNs

√ Point to Site VPNs

√ Dedicated WAN links

√ Virtual network gateways

√ Azure Virtual Networks

√ Inter-virtual Network connectivity

√ External load balancers

√Internal load balancers

√Network Security Groups

>Virtual machine ACLs

Third party proxy firewalls

Dual-homed

Dedicated public IP addresses

Static IP addresses on virtual machines

Public addresses on virtual machines

DNS

In this article we’ll continue to make our way down the list and talk about virtual machine ACLs and access to virtual machines for management purposes.

Virtual Machine ACLs

An ACL is an access control list – nothing new about that. But when we talk about Azure Virtual Machines, ACLs have different meanings depending on which “model” of Azure you’re using. In Azure you can create virtual machines using either “Azure Service Management (ASM)” or “Azure Resource Management (ARM)”. ASM might be considered the legacy (or “classic”) method for creating virtual machines in Azure because it was around before ARM. However, Microsoft recommends that going forward that you should create all of your virtual machines using ARM.

Note, though, that you need to be careful about that because you can’t do everything in ARM that you can do with ASM and vice versa. Also, if you already have existing virtual machines that were created using ASM, you can’t just move them over to ARM, so you have to use the features and capabilities that are built into ASM. At least that’s the case at the time of this writing. That said, the Azure cloud infrastructure is changing all the time and maybe by the time you read this, you’ll be able to migrate your ASM virtual machines to ARM with a single click. For now, unfortunately, that’s not the case.

Understanding ACLs in Azure

Let’s get back to ACLs. This term has a very specific meaning in Azure. In contrast to on-premises networks where network ACLs refer to any access control lists you have on routers or switches and can refer to any source and destination, Azure Virtual Machine ACLs refer only to connections coming from the Internet. Azure does not use the term “ACLs” when you create access control lists that control traffic moving between virtual machines that exist within Azure, nor between virtual machines that live in Azure and communicate with the corporate network.

If you have ASM virtual machines, you configure ACLs on “endpoints”. In Azure language, a virtual machine is an “endpoint” if connections are allowed to it from the Internet. Therefore, if you don’t allow any connections to the virtual machine from the Internet, the virtual machine is not an endpoint. If you use the Azure ASM portal, then you configure the endpoint when you create a new virtual machine.

If you have ARM virtual machines, you don’t configure endpoints at all, since there is no option to create an “endpoint” when you create a new virtual machine using the ARM model. Instead, you configure a Network Security Group to allow whatever connections from the Internet that you want to allow to the virtual machine.

It might sound a little confusing, but the bottom line is that whether the Azure virtual machine is called an endpoint or not, what you’re doing is allowing access to the virtual machine from the Internet.

ACLs, then, allow you to control which IP addresses are allowed to establish connections to virtual machines. For example, suppose you configure a virtual machine in Azure and you want to be able to manage it using the RDP protocol. You would configure the virtual machine as an endpoint that allows inbound RDP connections. In fact, if you use ASM, the virtual machine configuration wizard will do that for you and will even assign a random listening port (not TCP 3389) for you to connect to, which is then forwarded to the virtual machine’s listening port of TCP 3389. Azure does this to make it harder for attackers to troll for RDP listeners and then execute brute force attacks.

Configuring Endpoints

The figure below provides an example of what endpoints look like when you configure them using ASM.

Figure 1

You can configure ACLs after you’ve defined the endpoint. The figure below shows how you do that in the ASM model.

Keep in mind that you do not have to make virtual machines endpoints. If you don’t want your virtual machine to be Internet facing, just don’t make it an endpoint. In the ASM model, when you create a virtual machine using the portal, it will by default make your virtual machine a remote desktop, remote PowerShell, and SSH endpoint. This is done because you will probably want to manage your virtual machines over the Internet and these are the only ways you can do it. That is to say, you don’t have access to the virtual machines over the VM bus, like you do when you’re running a virtualized infrastructure on-premises. So you have to use these remote management protocols to access the virtual machines.

Alternatives to Endpoints

That’s not to say that you have to create endpoints to manage virtual machines. There are two other alternatives:

Instead of making the virtual machine an endpoint, you can establish a point to site VPN connection to the Azure Virtual Network that the virtual machine is on. This is a typical remote access VPN client connection to the Azure Virtual Network. Once you’re authenticated and authorized, you have a connection to the Azure Virtual Network and can then establish a management connection to the virtual machine’s actual IP address on the Azure Virtual Network, instead of the public address that is exposed to the Internet. This is no different from the situation where you’re working remotely and need to VPN into your corporate network to manage machines in your on-premises datacenter.

Point to site VPN is easy and doesn’t require centralized IT support. The other option, site to site VPN, requires that your networking group establish a site to site VPN between your on-premises datacenter and the Azure Virtual Network. When that connection is established, then you can connect to the actual IP addresses used by the virtual machines on the Azure Virtual Network from any location on your on-premises network, provided that there is a route available in your routing table infrastructure on-premises.

ACLs and ARM

What about virtual machine ACLs when using ARM? In that case, you’re not dealing with endpoints per se, since the concept of endpoints doesn’t technically exist in the ARM model. Instead, you’ll use Network Security Groups (NSGs). Network Security Groups can be thought of as simple stateful firewalls that use 5-tuples for access control. In ARM, you configure Network Security Groups with the source and destination addresses to which you want to allow or deny traffic using Network Security rules.

At this time, you can’t create a new Network Security Group using the portal interface, but you can take advantage of the new ARM templates, which is a lot easier than using PowerShell. Then, after the new Network Security Group is created, you can use the ARM portal (preview portal) to configure the Network Security Group rules.

Summary

In this article, Part 9 of our series on hybrid network infrastructure in Microsoft Azure, we talked about virtual machine ACLs and how you can configure them to allow inbound traffic from the Internet. We called out the fact that virtual machine ACLs are mostly an ASM concept since they depend on the “endpoint” construct, and that with ARM virtual machines, you just configure Network Security Group rules to allow Internet access to virtual machines. We also talked about how to manage virtual machines that you don’t want to be Internet facing. Finally, we finished up with a discussion around Network Security Groups and how you can use them to achieve the same result as virtual machine ACLs.

If you would like to read the other parts in this article series please go to:

Featured Links

Deb Shinder

Debra Littlejohn Shinder is a technology and security analyst and author specializing in identity, security and cybercrime, utilizing her past experience as a police officer and police academy/criminal justice instructor. She has written numerous books and articles for web and print publications and has been awarded the Microsoft MVP designation for fourteen years in a row.

Latest Podcast

Follow Us

Hybrid Network Infrastructure in Microsoft Azure (Part 9)

TECHGENIX

TechGenix reaches millions of IT Professionals every month, and has set the standard for providing free technical content through its growing family of websites, empowering them with the answers and tools that are needed to set up, configure, maintain and enhance their networks.