Azure Public IP Ranges and Whitelisting
Introduction
The default Network Security Group rules in Azure allow any outbound connections to the Internet. For most security conscious organisations this is unacceptable and they must implement default deny rules that override the Microsoft defaults, then only explicitly allow outbound traffic where necessary.
The problem with putting in a default deny is that it breaks various functionality such as the VMAgent being able to report health-status to the Azure platform which is then reflected in the portal, the ability to reset VMs, use custom script or basically any type of VM extension. It can also break other Azure services.
NSGs have convenient tags for the VirtualNetwork, AzureLoadBalancer and Internet - unfortunately there are no built-in tags for various Azure regions or particular Azure services, nor is there a way to create your own custom tags (e.g. akin to object groups such as those you have with Cisco or Checkpoint firewalls) - so today there is no easy way to do this.
This post discusses using a list of Azure Public IP ranges that Microsoft publishes and using that to whitelist those IP addresses.
Azure Public IP List
Microsoft publishes a list of all the public IP addresses used across the different Azure regions - you can use this to create NSG rules to whitelist those IPs. You can download this list from here https://www.microsoft.com/en-gb/download/details.aspx?id=41653, the IPs are organised by
region and provided in XML format. This file covers Azure Compute, Storage and SQL - so it doesn't cover absolutely all services.
Downloading the file using PowerShell
The PowerShell code below, retrieves the XML file and saves it locally:
The function takes two parameters:
- The destination path where the file should be saved
- An optional parameter that specifies the download URL, if not specified it uses a default value
Return regions in the XML file
The PowerShell function below returns the regions that the XML file covers by parsing the XML:
The PowerShell function below takes the XML file and a region name, it then depending on the parameters specified:
- Prints the IP addresses for the specified region to the screen
- If the OutputAsNSGAllowRuleFormat switch is specified the results are output in the format of NSG rules (as a CSV). This switch requires that the NSGRuleNamePrefix parameter is specified, which is used to prefix the NSG rule names.
- If the OutputAsIpSecurityXMLFormat switch is used it outputs the IP addresses as IIS IP Security rules XML
- If the OutputAsCheckpointObjectGroupFormat switch is used it causes the IP addresses to be output in Checkpoint firewall network object group format.
You can then for example use the NSG rule format CSV file and use a PowerShell script to apply the rules - you might want to do this in an automated fashion since some regions have hundreds of IP addresses in this file.
$AzPubIPXML = [xml] (gc .\AzurePublicIPRanges.xml) PS C:\Users\vijay> $AzPubIPXML.AzurePublicIpAddresses.Region | Select Name,@{l='IPCount';e={$_.IPRange.Count}} Name IPCount ---- ------- europewest 391 useast 380 useast2 289 uswest 394 usnorth 139 uswest2 109 europenorth 273 uscentral 274 asiaeast 93 asiasoutheast 171 ussouth 324 japanwest 25 japaneast 32 brazilsouth 35 australiaeast 31 australiasoutheast 32 indiacentral 8 indiawest 14 indiasouth 14 canadaeast 21 canadacentral 27 uswestcentral 28 ukwest 19 uksouth 26 uscentraleuap 13 useast2euap 10 koreasouth 16 koreacentral 15
NSG Limits
This brings us to another problem, we can't create custom tags with NSGs, you can have a maximum of 400 NSGs each containing a maximum of 500 rules per NSG - and you can only have one NSG associated with a Subnet (or NIC). This is problematic because if you're accessing resources across multiple Azure regions - there is no way you can cover all the IPs and stay within the limits. One option is not to be specific about the ports you allow and just allow ALL traffic to the Azure IPs but you will still reach the limits.
So what options do we have?
- Don't use NSGs and use a virtual firewall appliance such as a Checkpoint, Barracuda or Cisco appliance.
- These are not subject to the same limits and support the use of object groups which can simplify the rules.
- This of course is a costly option because NSG rules are free, where as the appliances will incur a per hour VM cost , plus a software license cost.
- Furthermore, you now have to design for high-availability for the appliances and scaling them up to handle more traffic (most of the options as far as I am aware only support active-passive configuration and do not support load sharing between appliances).
- To add to this you also have to manage routes to direct traffic through the appliances - all of which add complexity.
- Summarise the Azure IPs - while this can be an effective way to stay within the NGS limits, this does mean that you might end up allowing IPs that are outside of the ranges owned by Microsoft and increases your exposure.
Summarising IP ranges
If you decide to adopt the approach of summarising the Azure Public IP ranges, you can use the following Python script (which uses the Netaddr module to summarise): https://github.com/vijayjt/AzureScripts/blob/master/azure-ip-ranges/summarise_azure_ips.py
Comments
Post a Comment