A Caveat for Azure VM Public IP Configuration

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

This put up was co-authored by Ermetic Head of Analysis Igal Gofman and Senior Cloud Safety Architect Lior Zatlavi.


Anybody managing computing sources is aware of that one of the vital necessary attributes of their configuration is publicity to public community entry. Public publicity is necessary for 2 causes. From a safety perspective, it’s vital to know who (or what) can have community entry to a useful resource and to restrict that entry as a lot as attainable. From an operational perspective, you need to ensure that companies which might be required to be public (or very loosely restricted) are in reality configured as such.

As a safety firm, we often take care of limiting entry strictly to sources which might be required to be uncovered. This time, we need to shine a lightweight on the other scenario.

In our work, we’ve picked up on a difficulty involving how Azure VMs are configured for public publicity. The method might have you ever pondering you will have configured a machine to be public when in reality it isn’t. We thought we’d put out a caveat as this can be a misconfiguration you don’t need to study on the mistaken time.

Configuring Public Community Entry for a VM

Azure documentation describes the varied configurations wherein entry to a VM might be configured to be accessible to the web:

Determine 1: Totally different configurations of VM entry to the web (Supply: Azure documentation)

Whenever you take a look at VM4 in Determine 1, you might be underneath the impression {that a} VM with no community safety group (NSG) hooked up to its community interface and situated in a subnet with no NSG on it could, if assigned a public IP tackle, be public to the web. Nonetheless a better take a look at one of many attributes of a public IP – the SKU – and its implications, reveals a unique actuality:

Figure 2: Security information for the SKU attribute of a public IP address in Azure
Determine 2: Safety info for the SKU attribute of a public IP tackle in Azure (Supply: Azure documentation)

The marked part in Determine 2 explains that, for such entry to be attainable, a Commonplace SKU (presently the default when a brand new public IP tackle is created together with a VM) requires an NSG permitting public entry to be hooked up to the VM.

Which means on your VM to be public in an structure similar to that of VM4 in Determine 1, it’s a must to use a public IP tackle with Fundamental SKU (which doesn’t assist options similar to working with availability zones).

Alternatively, you’ll be able to connect an NSG to the VM or the Subnet it’s in that permits such public entry. Doing so makes the VM’s structure much like that of VM1, VM2 or VM3 in Determine 1.

If that is information to you, minimize your self some slack – even Azure will get this mistaken.

Taking a VM Out for a Spin

To grasp simply how unclear this will get, let’s arrange an illustration of a VM in an structure resembling that of the VM4 occasion in Determine 1.

We count on the VM to be public – however it received’t be.

Let’s create the VM:

Figure 3 - creating a VM, starting with the “Basics” tab
Determine 3: Making a VM, beginning with the Fundamentals tab

After organising attributes similar to subscription, useful resource group and title within the Fundamentals tab, we’ll head over to configure the networking. We’ll create the VM on a public subnet (that has no NSG hooked up to it) and with a brand new public IP tackle.

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

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

Nonetheless, as you see on the suitable part of Determine 4 under, the default SKU is marked as Commonplace. We’ll choose this selection (as we might not but have learn up on the distinction between Commonplace and Fundamental SKUs) and transfer on.

As soon as we select this configuration for our new public IP tackle, we even get a warning concerning the VM being provisioned as public:

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

To make testing the connection a bit simpler, we’ll load this VM with customized information that may set up an Apache net server and begin serving a easy net web page:

Figure 6 - Loading the new VM with custom data that starts up an Apache web server serving a simple web page
Determine 6: Loading the brand new VM with customized information that begins up an Apache net server serving a easy net web page

As a aspect be aware (and to offer credit score the place due), under is the total customized information that we created very simply utilizing ChatGPT:

Figure 7 - ChatGPT generating custom data for serving a web page on the VM
Determine 7: ChatGPT producing customized information for serving an online web page on the VM

After creating the VM we will get its public IP tackle from the overview web page:

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

Positive sufficient, though Determine 1 led us to imagine in any other case, we should not have a connection from our native machine:

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

Now for the actually fascinating half.

It’s one factor for the Azure documentation and VM creation wizard to be unclear on this situation. However Azure itself misunderstands the configuration: the Azure Community troubleshooting utility stories the VM as public for HTTP communication:

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

That is fairly an oversight.

With Azure’s personal software for evaluating community connectivity getting it mistaken, the typical Azure buyer is hardly at fault to not know higher.

Setting Up the Public IP the Proper Manner

Sadly, we can’t (and doubtless, at the very least in manufacturing environments, wouldn’t need to) downgrade the SKU of the general public IP tackle from Commonplace to Fundamental.

If we would like the VM to be public, the required (and presently lacking) element that may permit public entry to our VM is an NSG.

We’ll due to this fact arrange an NSG permitting inbound HTTP visitors:

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

We then connect the NSG to the VM’s community interface:

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

And… growth, we now have public entry as supposed:

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


Simply to be clear – the important tone we take with Azure right here is NOT concerning the convoluted standards for permitting public entry for a VM with a public IP tackle with the Commonplace SKU.

In reality, it makes good sense that, by default, a machine received’t truly be public except an NSG is configured with guidelines making it public.

Nonetheless Azure’s documentation, consumer interface and native community analysis instruments ought to clearly replicate this configuration nuance as prospects depend on the supplier’s accuracy when organising their environments.

That is an uncommon and perhaps considerably of an edge case that (hopefully) received’t be too troublesome on your deployments.

Nonetheless, it’s a good instance of a bigger lesson; earlier than assuming something will work as anticipated, wherever (particularly in manufacturing), do due diligence. Accomplish that with formal testing or through the use of evaluation instruments similar to Ermetic that present correct info on the configuration of your surroundings. Additionally, when analyzing your structure for faults (similar to unintended public entry), be sure you do thorough evaluation (once more, both your personal or utilizing exact third social gathering evaluation instruments similar to Ermetic) to keep away from false positives.


Lior Zatlavi
Sr. Cloud Safety Architect, Ermetic

Igal Gofman
Head of Analysis, Ermetic


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

*** This can be a Safety Bloggers Community syndicated weblog from Ermetic authored by Lior Zatlavi. Learn the unique put up at: https://ermetic.com/weblog/azure/a-caveat-for-azure-vm-public-ip-configuration/

Leave a Reply

Your email address will not be published. Required fields are marked *