By default, all machines provisioned in Azure have direct access to the internet, whether the VM has a public IP address or not. While this might be fine for some companies, not all will be be happy with this and will see it a big security risk. In my experience, most companies now control internet access using a proxy server to provide protection from the internet.
The issue with providing direct internet access is that anyone that has access could log onto the server, access any website, and download any nasty content, which could then be spread around the internal infrastructure.
There are two common approaches for blocking internet access to VMs in Azure. One is to use User Defined Routing (UDRs) and one is to use Network Security Groups (NSGs). Using UDR’s, traffic detained for the internet (0.0.0.0/0) can be routed anywhere (or nowhere) to block internet access, but for this post I am focussing on using the NSG approach.
To start with, one might ask why there can’t just be a single NSG rule to block all traffic destined for the internet. While this is possible, it will cause many issues as VMs have to be able to get to Azure public hosted services (particularly Azure Storage for diagnostic data) to function correctly. To block internet access, but still allow the required communication to Azure services, multiple rules are required allowing access to the Azure services based on the destination service tag. For more information on service tags, visit https://docs.microsoft.com/en-us/azure/virtual-network/security-overview#service-tags.
Below is a screenshot of a default NSG outbound rule set I put together to allow communication to the following services, but still block internet access:
- Azure Storage – For diagnostic data
- SQL – Communication to SQL PaaS services
- Azure Monitor – For monitoring
- Azure Cloud – For Desired State Configuration (DSC)
With the allow rules having a lower priority number than the DenyInternetOutBound rule, they will take precedence over the Deny action of that rule.
The AzureCloud.xxxx destination rules allow outbound access to the compute IP address ranges used by the Microsoft Azure data centres for the region specified. To allow communication to Azure Automation for DSC, this service tag type will need to be used as there is no specific service tag for Automation or DSC.
As with all things in Azure, there could be a service tag for Azure Automation or DSC at any point. If/when that happens, the AzureCloud.xxxx destination rules can be replaced with the new, more specific, service tag.
The advantage of this approach is that if proxy servers are being used to control internet access, the proxy server details can still be specified in a web browser or application on the server to allow/control internet access when required.
Note: I recommend applying NSGs at the subnet, rather than the virtual machine. Administrating NSGs at a VM level becomes unmanageable very quickly. NSGs can be applied to a VM where explicitly required, however applying at the subnet will drastically minimise ongoing administration of NSG rules.
Hope this proves helpful, and please share your approaches to blocking internet access if you’re taking a different approach.