Unprotected Azure public IP adresses
To fully secure any public cloud platform, we need to understand them deeply. This requires both upskilling existing teams with cloud expertise and shifting the way security responsibilities are spread across the organization: security should be on everyone’s agenda, not just for the security experts. In this post, I will cover common network security misconfigurations, why do they matter, and how to mitigate them. Specifically, we’ll discuss how to secure Azure public IP addresses.
Unprotected public endpoints in Azure
The most common security misconfiguration is something that we as a technology industry should know better, but we don’t. In Azure, every cloud resource, application, and database is accessed over the network. Quite often, even the default settings of new resources permit public access!
Why are unprotected public endpoints bad?
And what happens when you leave these network endpoints on? The bad actors come knocking. They come fast, and they bring friends! Here’s a screenshot from my Azure Log Analytics Workspace, where I am monitoring my Virtual Machines running on Azure. I have two virtual machines, both standard Windows Server virtual machines from the Azure Marketplace, so they are running the latest updates. They are, however, configured to allow management port access from the public internet.
Results of a KQL query from the logs of 2 Virtual Machines running in Azure for 24 hours, with public access from RDP port allowed.
During the 24 hours I kept these virtual machines on, there were tens of thousands of failed login attempts! In the screenshot, I run a Kusto Query Language search to show that attackers attempted to log in using 3212 different user names. For the most popular ones, they attempted hundreds of even thousands of times. This goes to show that when anything is exposed to the internet, it is found immediately. And you can rest assured, they will try to break in.
How to secure unprotected cloud network endpoints?
When you create new cloud services, you should understand the shared cloud responsibility and put in place network controls when it’s your responsibility. In practice, every public IP you manage is a risk and one you should carefully review.
When you decide you do need public access, you should secure your IaaS applications (Virtual Machines) with Network Security Groups, Security Center Just-in-time Access or Azure Bastion. You should use secure the PaaS data services you consume with Service Endpoints, Private Endpoints and Firewalls. And finally, you should use Azure Private Link to secure your PaaS and CaaS application connectivity.
In the screenshot below, I have secured my Azure Storage Account by denying public network access. I have done this by navigating to Firewalls and virtual networks, and selecting Allow access from: Selected networks. In the following menu, I have selected a subnet in my virtual network, msft-spoke-vnet, to have access to my Storage account. This means that applications connecting from this network will be allowed access to the Storage account, and any other connection attempts will be denied by Microsoft themselves. So in the case of Storage account, Microsoft is responsible of operating the network controls (firewall), and we as end users are responsible for configuring it.
Azure Storage Account with Firewall enabled and Virtual Network added.
Learn more about Azure network security other security best practices
Thank you for reading my short post about securing Azure public IP addresses and endpoints. If you have further questions, check out my book: Azure Security Handbook: A Comprehensive Guide for Defending Your Enterprise Environment. It goes both deeper and wider all things considering Azure security.
