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.
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.
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:
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.