Online Magazine
Azure VMSS – Preventing security gaps in isolated infrastructure
In this hack on the topic of "Azure Virtual Machine Scale Set (VMSS)", I show where a security gap can hide in an isolated infrastructure and how to find it and finally close it.
By Peter Stadler
Using the Microsoft Azure Service "Azure Virtual Machine Scale Set (VMSS)", a group of virtual machines (VMs) with load balancing and automatic scaling can be created or managed. Now, what does that mean exactly and what am I getting at?
Let's assume, for example, that an IT application for resource planning is provided in a company. However, due to the manufacturer's warranty, this application may only be installed on virtual machines. Since it is important to the company that this application is available 365 days a year without interruption, the necessary IT infrastructure must be provided for this application. Azure Virtual Machine Scale Set fulfils exactly this purpose. The service provides an IT infrastructure that not only ensures fail-safety, but also automatically provides the appropriate performance depending on the load and access. The service is mostly used for applications for Big Data, batch, container workloads, etc. For our example, a resource scheduling application does as well. We assume that the application should only be accessible and callable internally (within the own company). In other words, the application is cut off from the Internet and thus an isolated infrastructure is realised. However, this is not automatically guaranteed.
The security gap
When setting up the Azure VMSS, you have the option of choosing whether it gets a public connection or not. To guarantee load balancing, a load balancer is implemented in the front end for access and, if desired, equipped with a public connection:
If you now want to handle access in isolation, it is best to avoid the public connection. In our hack, we don't even create a front-end for access and deselect the load balancer:
Once created, we thus have an isolated Azure VMSS service. As an example, we will now take a closer look at a VM (referred to as a node) and reveal the security gap:
As you can see, this node only has a private and isolated connection with the IP address 10.100.2.4. The network for this is already equipped with a default set of rules as protection (referred to as a network security group), which we will discuss in detail later:
The first tests on the Node are promising and clearly show that this is an isolated setup, as no communication to the internet seems to work:
However, if we set the test a little higher in the OSI model, we will find out that an Internet connection is established at the latest with an HTTPS request:
Of course, this also assigns a public IP to the node, which is not allowed according to our isolated structure:
There it is, our security gap.
Hack
Now let's look at the standard set of rules in the Network Security Group in Azure. In addition to the security measures and the isolated environment without public connectivity, what can be done to close this gap?
Looking more closely at the standard rules, we can see the following:
- Incoming network traffic is only allowed from the private network and the Azure Loadbalancer service, everything else is prevented. This set of rules is fine so far and covers our security needs in this hack.
- Outgoing network traffic, on the other hand, is allowed into the private network, but also towards the Internet and thus into the public network, which we want to prevent in our hack in order to close the security gap.
Thus, as a conclusion, we have to individualise and adapt the outgoing rules:
This overwrites the default rules and the test afterwards shows:
The security gap has been closed.
