A Caveat for Azure VM Public IP Configuration

If you’re not familiar enough with the SKU attribute of the Azure public IP address, you may think you’re configuring VMs as public to the internet... but aren’t.

Lior Zatlavi By Lior Zatlavi
A Caveat for Azure VM Public IP Configuration

This post was co-authored by Ermetic Head of Research Igal Gofman and Senior Cloud Security Architect Lior Zatlavi.

***

Anyone managing computing resources knows that one of the most important attributes of their configuration is exposure to public network access. Public exposure is important for two reasons. From a security perspective, it’s significant to know who (or what) can have network access to a resource and to limit that access as much as possible. From an operational perspective, you want to be sure that services that are required to be public (or very loosely restricted) are in fact configured as such.

As a security company, we usually deal with limiting access strictly to resources that are required to be exposed. This time, we want to shine a light on the opposite situation.

In our work, we’ve picked up on an issue involving how Azure VMs are configured for public exposure. The approach may have you thinking you have configured a machine to be public when in fact it isn’t. We thought we'd put out a caveat as this is a misconfiguration you don’t want to learn about at the wrong time.

Configuring Public Network Access for a VM

Azure documentation describes the various configurations in which access to a VM can be configured to be accessible to the internet:

Figure 1: Different configurations of VM access to the internet - Source: Azure documentation
Figure 1: Different configurations of VM access to the internet (Source: Azure documentation)

When you look at VM4 in Figure 1, you may be under the impression that a VM with no network security group (NSG) attached to its network interface and located in a subnet with no NSG on it would, if assigned a public IP address, be public to the internet. However a closer look at one of the attributes of a public IP - the SKU - and its implications, reveals a different reality:

Figure 2: Security information for the SKU attribute of a public IP address in Azure
Figure 2: Security information for the SKU attribute of a public IP address in Azure (Source: Azure documentation)

The marked section in Figure 2 explains that, for such access to be possible, a Standard SKU (currently the default when a new public IP address is created along with a VM) requires an NSG allowing public access to be attached to the VM.

This means that for your VM to be public in an architecture such as that of VM4 in Figure 1, you have to use a public IP address with Basic SKU (which doesn’t support features such as working with availability zones).

Alternatively, you can attach an NSG to the VM or the Subnet it is in that allows such public access. Doing so makes the VM’s architecture similar to that of VM1, VM2 or VM3 in Figure 1.

If this is news to you, cut yourself some slack – even Azure gets this wrong.

Taking a VM Out for a Spin

To understand just how unclear this gets, let’s set up a demonstration of a VM in an architecture resembling that of the VM4 instance in Figure 1.

We expect the VM to be public - but it won’t be.

Let’s create the VM:

Figure 3 - creating a VM, starting with the “Basics” tab
Figure 3: Creating a VM, starting with the Basics tab

After setting up attributes such as subscription, resource group and name in the Basics tab, we’ll head over to configure the networking. We’ll create the VM on a public subnet (that has no NSG attached to it) and with a new public IP address.

Figure 4 - Configuring networking as part of creating a VM
Figure 4: Configuring networking as part of creating a VM

This setup will supposedly suffice for the virtual machine to be public.

However, as you see on the right section of Figure 4 below, the default SKU is marked as Standard. We will select this option (as we may not yet have read up on the difference between Standard and Basic SKUs) and move on.

Once we choose this configuration for our new public IP address, we even get a warning about the VM being provisioned as public:

Figure 5 - VM creation wizard warning about the newly created VM being public
Figure 5: VM creation wizard warning about the newly created VM being public

To make testing the connection a bit easier, we will load this VM with custom data that will install an Apache web server and start serving a simple web page:

Figure 6 - Loading the new VM with custom data that starts up an Apache web server serving a simple web page
Figure 6: Loading the new VM with custom data that starts up an Apache web server serving a simple web page

As a side note (and to give credit where due), below is the full custom data that we created very easily using ChatGPT:

Figure 7 - ChatGPT generating custom data for serving a web page on the VM
Figure 7: ChatGPT generating custom data for serving a web page on the VM

After creating the VM we can get its public IP address from the overview page:

Figure 8 - Extracting the public IP address for the VM created
Figure 8: Extracting the public IP address for the VM created

Sure enough, even though Figure 1 led us to believe otherwise, we do not have a connection from our local machine:

Figure 9 - No connection to the newly created VM
Figure 9: No connection to the newly created VM

Now for the really interesting part.

It’s one thing for the Azure documentation and VM creation wizard to be unclear on this issue. But Azure itself misunderstands the configuration: the Azure Network troubleshooting utility reports the VM as public for HTTP communication:

Figure 10 - Azure Connection troubleshooting utility showing the VM as supposedly public
Figure 10: Azure Connection troubleshooting utility showing the VM as supposedly public

This is quite an oversight.

With Azure’s own tool for evaluating network connectivity getting it wrong, the average Azure customer is hardly at fault to not know better.

Setting Up the Public IP the Right Way

Unfortunately, we can’t (and probably, at least in production environments, wouldn’t want to) downgrade the SKU of the public IP address from Standard to Basic.

If we want the VM to be public, the required (and currently missing) component that will allow public access to our VM is an NSG.

We will therefore set up an NSG allowing inbound HTTP traffic:

Figure 11 - NSG allowing public inbound HTTP (and HTTPS) access
Figure 11: NSG allowing public inbound HTTP (and HTTPS) access

We then attach the NSG to the VM’s network interface:

Figure 12 - Attaching the NSG to the network interface of the VM
Figure 12: Attaching the NSG to the network interface of the VM

And… boom, we now have public access as intended:

Figure 13 - We now have access to the VM and can view the web page served
Figure 13: We now have access to the VM and can view the web page served

Conclusion

Just to be clear - the critical tone we take with Azure here is NOT about the convoluted criteria for allowing public access for a VM with a public IP address with the Standard SKU.

In fact, it makes perfect sense that, by default, a machine won’t actually be public unless an NSG is configured with rules making it public.

However Azure’s documentation, user interface and native network evaluation tools should clearly reflect this configuration nuance as customers rely on the provider’s accuracy when setting up their environments.

This is an unusual and maybe somewhat of an edge case that (hopefully) won’t be too troublesome for your deployments.

However, it is a good example of a larger lesson; before assuming anything will work as expected, anywhere (especially in production), do due diligence. Do so with formal testing or by using analysis tools such as Ermetic that provide accurate information on the configuration of your environment. Also, when analyzing your architecture for faults (such as unintended public access), make sure you do thorough analysis (again, either your own or using precise 3rd party analysis tools such as Ermetic) to avoid false positives.

***

Lior Zatlavi
Sr. Cloud Security Architect, Ermetic

Igal Gofman
Head of Research, Ermetic