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:

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:

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:

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.

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:

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:

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

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

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

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:

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:

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

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

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

The post A Caveat for Azure VM Public IP Configuration appeared first on Ermetic.

*** This is a Security Bloggers Network syndicated blog from Ermetic authored by Lior Zatlavi. Read the original post at: https://ermetic.com/blog/azure/a-caveat-for-azure-vm-public-ip-configuration/