If you’ve tested the waters of the Azure cloud at all, you’ve probably gone so far as to set up a simple Pay-As-You-Go subscription for your organization and created a simple virtual machine (VM) in a resource group. As this was your first foray into the cloud, the thought of adhering to best practices and using the Cloud Adoption Framework probably hadn’t crossed your mind – you just wanted to see what the fuss was all about with the cloud and try it out for yourself.
So, you created a VM, along with a virtual network and a public IP address to associate with your VM and started to tinker with your creation. You probably logged into the VM via RDP as well, using the public IP address attached to the network interface of your VM. Satisfied with the progress you made in understanding more about cloud technology, you may (or may not) have stopped your VM and deallocated it, fully intending to tinker with it some more as your organization begins its journey to the cloud.
A dynamically allocated IP address will change every time the underlying VM is deallocated.
What did you do with that first VM you created? Did you wind up deleting it after some time? Did you use it as a sort of template for creating additional VMs?
Did it become a production-level resource for your organization? More importantly, what did you learn from creating that first VM on your own? Among other things, you learned that it was perfectly fine to create a VM and associate a publicly accessible IP address to it.
Therein lies the problem.
What Are Public IP Addresses and Why Are They Bad?
A public IP address in Azure is a resource that provides an IPv4 or IPv6 address to a network interface resource, which in turn is usually associated with another resource in Azure like a VM. This IP address can be seen from anywhere on the Internet (the public part of its name). Public IP addresses can be static or dynamic by design. If a public IP address resource is created and uses the static allocation method, it simply means that the IP address assigned to it will never change. Conversely, a dynamically allocated IP address will change every time the underlying VM is deallocated (unless you specify that the address should be kept).
Having IP addresses that are publicly accessible is a necessity of the internet – without them, our computers wouldn’t be able to resolve website URLs, rendering just about every website useless. Indeed, if you are planning on building a website for the public to access, you will need a public IP address at some point (most likely, on a firewall or load balancer that resides in front of your web server).
Ironically, the very thing that makes public IP addresses so useful is what also makes them so dangerous.
By assigning a public IP address (through the network interface) to a VM in Azure, that VM now becomes visible to everyone on the Internet. This includes all those ne’er-do-wells who scan the Internet for these addresses, looking to find any open ports or vulnerabilities to exploit. Once your VM is found by one of these attackers, it is just a matter of time before they launch a script or botnet to try to gain access to it.
If you still have that VM in your Azure subscription with a public IP address associated with it, power it up and open an RDP connection to it using that IP address. If you receive an error message stating, “An internal error occurred.”, then congratulations – your VM is currently being attacked! The error message occurs because there are too many attempts to open an RDP session to the VM happening at the same time. Since you’re probably the only person in your organization attempting to access that VM at that moment, you can safely assume that the others who are also trying to access it are not friendly! Note that this error occurrence is somewhat temporary – if you keep trying, eventually you should be able to log in to your VM.
In case you’re still skeptical about the possibility that your VM may be under siege, open up Event Viewer from within the VM (once you do manage to log in successfully via RDP, of course), and navigate to the Security log under the Windows Logs folder.
The first thing you may notice is that the log contains an enormous amount of “Audit Failure” events. These are the brute force attempts that the attacker has tried already, using commonly used logins and password combinations.
The second thing you may notice is that your Security log may only have a few hours’ worth of data in it. This is due to the fact that the attacker has tried so many times to gain access, the log has already reached its default maximum size (usually 20,480 KB) and is now dropping older events to allow recording of newer ones. Thus, even if the attacker has not successfully accessed your VM, he or she has already done enough damage to render your VM’s local security log somewhat useless.
Fixing the Problem
One of the best ways of fixing this problem is to avoid it altogether. If you’re deploying a VM to the cloud, avoid creating and attaching a public IP address resource to it. There are numerous ways to securely connect to your VMs in the cloud, such as a site-to-site VPN tunnel or Azure Bastion. Using these methods allows you to treat your Azure VMs as a logical extension of your on-premises network. The effort involved in setting up the resources for these connectivity methods is rather low; the most significant hurdle to be cleared might be the task of getting the configuration settings to work with any on-premises firewalls you may be connecting to.
If you believe you still require a public IP address on your VM, you may want to ask yourself why. Is this a web server that you’re migrating to the cloud? Consider instead the concept of migrating the individual web sites or web applications into cloud-based versions that do not rely on managed IIS servers. Does this VM house a public-facing legacy application?
If you’re deploying a VM to the cloud, avoid creating and attaching a public IP address resource to it.
There may be a more modern cloud-based version of the same application that you could leverage without the need to deploy a VM to support it.
If you’re convinced that you need a public IP address on the VM you’re deploying (perhaps you’re configuring a VM-based firewall), then you should ensure the following:
- Inbound access to the VMs RDP port (typically TCP port 3389) should be restricted to specific IP address ranges. Never allow your RDP port to be open to the Internet without any restrictions.
- Use a network security group, either on the VM’s network interface or on the subnet of the virtual network that the VM is connected to, to restrict port traffic inbound and outbound of the VM.
- Enforce the use of identity protection measures on your VM, such as multi-factor authentication, just-in-time access, privileged identity management, and strong passwords for user accounts.
- Utilize tools such as the VM’s local security log or any access logs in Azure that track access attempts to your VM. Make note of any unauthorized attempts to access the VM and follow through on remediation to address any weak points in its security measures.
- Follow Azure Security Baseline best practices by addressing recommendations provided by Microsoft Defender for Cloud, which will help you to harden the VM from external threats.
Adoption of the cloud benefits companies of all sizes. Tallan can assist you in navigating and making the best use of the ever-expanding range of tools and platforms to meet your business goals, whether you are just getting started or have a cloud-based company.
The infrastructure and security team at Tallan is an expert in determining where you are so that we can design, create, and deploy safe environments and cloud-based apps that are totally centered on where you want to be. Click here to learn about the scalability and dependability of Tallan’s Azure-based solutions.