Avoid Getting Burned: Identifying and Correcting Common Misconfigurations in Azure Networking and Firewalls

Networking in Azure offers robust capabilities, enabling complex workflows and cross-tenant collaboration while incorporating many security features. However, the extensive range of functions available can make networking in Azure seem overwhelming.  

IT must meet networking goals, implement various models, and manage a complicated mix of resources. Given these challenges, it’s not surprising that operations can become hectic and certain security risks overlooked.  

This article will explore the different nuances and common misconfigurations seen in Azure network access controls that can potentially expose sensitive data and resources.  

Azure firewalls, Resource firewalls, and NSGs 

There are numerous network access controls that exist. Although these controls may sound similar at first, each has specific uses and accompanying behaviors that may not follow expectations.  

Azure Firewall 

Azure Firewall is a fully stateful firewall that can be used much like a classic physical firewall, allowing it to perform threat intelligence-based filtering, Network Address Translation (NAT), internet access filtering, and more.  

When deploying Azure Firewall, users will notice three different SKUs to choose from, ranging from basic at the lowest end, which does not include any advanced threat protection, to premium — the highest tier which includes all the features. 

Azure resource firewall 

Many Azure resources have public endpoints, and an Azure resource firewalls allows you to permit public access or restrict access through a whitelist of virtual networks and permitted IP addresses. This access configuration is also called a “firewall.” 

For example, a storage account’s internet access configuration is known as a “storage account firewall.” Each resource behaves slightly differently regarding public endpoints, with nuances in their respective operation modes.  

One such variation is the “Allow Azure services and resources to access this server” setting for Azure SQL Servers, which sounds similar to but is very different from the “Allow Azure services on the trusted services list to access this storage account” setting for storage accounts. 

The first rule allows any IP that belongs to Azure, including VMs from other tenants and cloud shell sessions, to access the database (which basically makes the database public). The second rule allows only a subset of trusted Azure services to access the resource. 

Azure network security groups  

Network security groups (NSGs) filter traffic between Azure resources within a virtual network and can be applied to an entire subnet or specific network interfaces. This differs from an Azure Firewall, as Azure Firewalls are fully featured network appliances, and NSGs are simply five-tuple access rules (source, source port, destination, destination port, and protocol). One example of this difference is that an Azure Firewall can be used as an internet gateway, whereas NSGs cannot. 

Private endpoints  

Private endpoints provide a solution to allow resources that generally only have a public endpoint, such as Azure Storage, also to have a network interface within a virtual network. Deploying a private endpoint for a resource adds a network interface to your virtual network. It includes a DNS entry redirecting the public endpoint to the interface’s internal IP. 

Azure resource firewalls 

The previously mentioned resource firewall only affects public IP addresses. It doesn't impact traffic to private endpoints, allowing network access for any entity connected to the virtual network where the endpoint is deployed. Using another method to limit access from the internal network is recommended. 

Azure NSGs 

Having created an internal endpoint within a virtual network using a private endpoint, it makes sense to use NSGs to restrict access. What can cause a fair amount of confusion is the “Network Policy for Private Endpoints” setting for each subnet. This setting dictates if NSG rules should apply to private endpoints within the subnet, and, by default, does not enforce these rules. This means that although a network engineer may have designed what appears to be a secure environment using NSGs to limit access to resources within the VNET, these rules do not automatically apply to resources deployed through private endpoints. This could potentially result in a security vulnerability. 

Below is an Azure resource graph query that will locate virtual networks with problematic subnets that do not enforce NSGs on private endpoints. 

	
		
resources
| where type =~ "microsoft.network/virtualnetworks"
| extend subnets = properties.subnets 
| mv-expand subnets 
| project subscription=subscriptionId, resourceGroup=resourceGroup, vnetId=id, vnetName=name, subnetName=subnets.name, nsgsEnforcedOnPrivateEndpoints=subnets.properties.privateEndpointNetworkPolicies 
| where nsgsEnforcedOnPrivateEndpoints == "Disabled"
	

We recommend changing the above setting across all virtual networks to enforce NSGs on private endpoints. Network administrators should be wary of accidentally resetting the “Network Policy for Private Endpoints” to its default value when they create a storage account via the portal and opt to add the private endpoint during that process. Adding private endpoints after storage account creation is recommended as this allows choosing the “Network Policy for Private Endpoints” setting separately. 

Storage account network settings abuse 

Azure Storage accounts are essential for storing and accessing crucial application and workflow data. Therefore, it’s necessary to have various network settings and possibilities available while protecting Storage Accounts. However, the flexibility in networking settings can sometimes lead to potential vulnerabilities and attack vectors. 

Azure Storage account NFS 

NFS (Network File System) is a network protocol for distributed file sharing that can be used in Azure Storage Accounts. NSGs for private endpoints are crucial due to how blob storage functions with NFS. Blob storage can be accessed via NFS, but this is restricted to a virtual network, excluding public endpoints. This feature does not include authorization, so access control to the blob storage though NFS is determined solely by network security settings such as NSGs for private endpoints and permitted virtual networks for service endpoints. This introduces security issues, as storage containers requiring authentication will bypass it when accessed with NFS, and as we have seen, NSGs and private endpoints have their own issues. We suggest ensuring that NFS 3.0 for blob storage is disabled. 

The following Azure resource graph query locates storage accounts with NFS enabled for blob storage: 

	
		
resources 
| where type == "microsoft.storage/storageaccounts" 
| where properties['isNfsV3Enabled'] == "true" 
| project tenant=tenantId,subscriptionId=subscriptionId, resourceGroup=resourceGroup, storageAccountName=name, storageAccountId=id, isNFSEnabled=properties['isNfsV3Enabled'] 
	

Azure Storage firewall and object replication 

Despite having secured network access to a storage account using NSGs, resource firewalls, and proper authentication methods and settings, an individual with the Azure Storage Account Contributor role can still access all data in the storage account from any IP address. This can be done without altering networking settings, making detection difficult. How? Through object replication.  

When object replication is set up to duplicate objects to a separate storage account, whether this account is within the same tenant or involves cross-tenant replication, the existing networking and access level rules do not affect the replication process. This means an attacker with the Storage Account Contributor role can configure cross-tenant object replication, thereby gaining access to all existing and new data in the account. 

An attacker with the required privileges could exploit this feature by enabling cross-tenant replication and configuring object replication to a storage account they control. We suggest disabling cross-tenant replication if possible, and if not, ensure that both the source and destination accounts have similar levels of protection. The following Azure resource graph query lists storage accounts that have cross-tenant replication enabled: 

	
		
resources 
| where  type == 'microsoft.storage/storageaccounts' 
| where properties.allowCrossTenantReplication == 'true' 
| project tenant=tenantId,subscriptionId=subscriptionId, resourceGroup=resourceGroup, storageAccountName=name, storageAccountId=id, isCrossTenantReplicationEnabled=properties.allowCrossTenantReplication 
	

Another way an attacker may gain access is by replicating objects to a public storage account or one for which they have permission. This can be detected with the following PowerShell script, which lists all object replication policies and whether the destination container is in an external subscription or a public container. 

	
		
$Subscriptions = Get-AzSubscription | ForEach-Object { $_.id } 
 
$ORPolicies = Get-AzStorageAccount | ForEach-Object{ Get-AzStorageObjectReplicationPolicy -ResourceGroupName $_.ResourceGroupName -StorageAccountName $_.StorageAccountName} 
foreach ($Policy in $ORPolicies) { 
    foreach ($Rule in $Policy.Rules) { 
            $destContainer = Get-AzResource -ResourceId ($Policy.DestinationAccount + "/blobServices/default/containers/" + $Rule.DestinationContainer) -ErrorAction SilentlyContinue 
            $Custom = [pscustomobject]@{ 
                SourceStorageAccount = $Policy.SourceAccount 
                SourceContainer = $Rule.SourceContainer 
                DestinationStorageAccount = $Policy.DestinationAccount 
                DestinationContainer = $Rule.DestinationContainer 
                IsToExternalTenant = ($Subscriptions -contains $Policy.DestinationAccount.split('/')[2]) 
                IsPublicAccessEnabledOnDest = $destContainer.Properties.publicAccess 
            } 
            $Custom | Format-Table 
    } 
}  
	

Summary 

We’ve shown you how various network settings in Azure can affect resource access in specific and sometimes unexpected ways.  

It’s important to understand the security implications these networking settings have on your environment and data during deployment.  

Using a security platform that monitors your environment and calculates effective data resource access can help ensure your data remains secure.