Block/allow specific IP addresses from accessing applications running on Azure Cloud Services

For certain scenario, the application / website hosted in Azure Cloud Services needs more secure without anonymous access, this blog will introduce below four ways to specify IP address (or a range of IP addresses) could be blocked / allowed from accessing applications running on Azure Cloud Services:

 

• Using the "IP and Domain Restrictions" feature on cloud services web role via a startup task
• Adding a firewall rule to block access to an IP address via the below command in the startup task
• Implementing NSG rule by placing the cloud service in a VNET
• Implementing ACL on the cloud service

 

- Using the "IP and Domain Restrictions" feature on cloud services web role via a startup task:

You can restrict an Azure web role access to a set of specified IP addresses by modifying your IIS web.config file. Using a command file which unlocks the ipSecurity section of the ApplicationHost.config file.

1. To do unlock the ipSecurity section of the ApplicationHost.config file, create a command file named startup.cmd that runs at role start. Add this file to your Visual Studio project and set the properties to Copy Always to ensure that it is included in your package.
2. Add following commands in your startup.cmd file.

@echo off
@echo Installing "IPv4 Address and Domain Restrictions" feature 
powershell -ExecutionPolicy Unrestricted -command "Install-WindowsFeature Web-IP-Security"
@echo Unlocking configuration for "IPv4 Address and Domain Restrictions" feature 
%windir%\system32\inetsrv\AppCmd.exe unlock config -section:system.webServer/security/ipSecurity

3. Add the startup task to the ServiceDefinition.csdef file.

  

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="BlogSpecificIP" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2015-04.2.6">
  <WebRole name="WebRole1" vmsize="Standard_D1_v2">    
    <Startup>
      <Task commandLine="startup.cmd" executionContext="elevated" />
    </Startup>
  </WebRole>
</ServiceDefinition>

4. Modify the system.webServer section in your web role’s Web.config file to add a list of IP addresses that are granted access, as shown in the following example:

  This sample config allows all IPs to access the server except the one defined.

<system.webServer>
	  <security>
		  <!--Unlisted IP addresses are granted access-->
		  <ipSecurity>
			  <!--The following IP addresses are denied access-->
			  <add allowed="false" ipAddress="denied IP address" subnetMask="releated subnetMask" />			  
		  </ipSecurity>
	  </security>	  
  </system.webServer>

This sample config denies all IPs to access the server except the one defined.

<system.webServer>
	  <security>
		  <!--Unlisted IP addresses are granted access-->
		  <ipSecurity>
			  <!--The following IP addresses are denied access-->
			  <add allowed="true" ipAddress="allowed IP address" subnetMask="releated subnetMask" />			  
		  </ipSecurity>
	  </security>	  
  </system.webServer>

5. If you use deny configuration for specific IPs, you may see the following page when you try to connect to your cloud service from the denied IP address.

 

 Refer more details via https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-startup-tasks-common#block-a-specific-ip-address

 

- Adding a firewall rule to block access to an IP address via the below command in the startup task

 

In Azure, there are effectively two firewalls. The first firewall controls connections between the virtual machine and the outside world. It is controlled by the EndPoints element in the ServiceDefinition.csdef file.

 

In this guide, we focus on the second firewall. It controls connections between the virtual machine and the processes within that virtual machine. This firewall can be controlled by the netsh advfirewall firewall command-line tool.

 

Azure creates firewall rules for the processes started within your roles. These firewall rules can be created by using a startup task. A startup task that creates a firewall rule must have an executionContext of elevated.

 

1. Add the startup task to the ServiceDefinition.csdef file.

 

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="Blogfirewallblock" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2015-04.2.6">
  <WebRole name="WebRole1" vmsize="Standard_D1_v2">   
    <Startup>
      <Task commandLine="BlockIP.cmd" executionContext="elevated" taskType="simple" />
    </Startup>
  </WebRole>
</ServiceDefinition>

2. In this example, the firewall try to block some specific IPs. Add following commands to your start up task file.

REM   Add a firewall rule in a startup task.

REM   Add an inbound rule requiring Block IPs
netsh advfirewall firewall add rule name="Blacklisted IP" dir=in interface=any action=block remoteip= your denied IP

REM   If an error occurred, return the errorlevel.
EXIT /B %errorlevel%

 

3. After deploying it, if you try to visit the cloud service site URL from the IP address above. You will see the following message.

 

Refer more details via https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-startup-tasks-common#add-firewall-rules

 

- Implementing NSG rule by placing the cloud service in a VNET:

 

You can use the Network Security Groups(NSG) to block some IPs. You can add different rules in one NSG and config this NSG to your cloud service’s VNet.

 

Firstly, you need to have a NSG with rules that can block the target IPs. You can use portal to create the NSG and add rules in it.

 

The following lines config a subnet with an existing NSG to your cloud service. You can add the following lines in your ServiceConfiguration.Cloud.cscfg file and redeploy your cloud .

 

 

There is another way if you prefer to config the NSG to the VNet from the portal. This method is more suitable for an existing cloud service that already had a VNet and do not want to redeploy the whole cloud service.

 

If your cloud service does not have a VNet and also want to config the following steps from the portal, you may need to config a VNet in the ServiceConfiguration.Cloud.cscfg firstly and redeploy it, and then follow the below steps.

 

Since we have a cloud service (classic) here, all related resources should also be classic resources.

 

1. You need to create a NSG classic and add some rules that block target IPs.

2. In this case, we add an inbound rule and reject my local host IP visit the site.

 

3. Put my IP address in the source IP resource range. You can also reject a range of IPs here.

 

4. You need to config this NSG to your cloud service VNet.

 

5. When we tried to visit the cloud service URL from Microsoft Edge browser, we can see the following message.

 

Refer more details via https://docs.microsoft.com/en-us/archive/blogs/igorpag/azure-network-security-groups-nsg-best-practices-and-lessons-learned#nsg-and-azure-cloud-services-paas

 

- Implementing ACL on the cloud service:

Please keep in mind the Network/Endpoint ACLs is however not compatible with NSG, so use either one of them.

Network (or Endpoint) Access Control List (ACL) are the key to protecting Web or Worker role public endpoints and controlling that type of access to them.

1. In the ServiceConfiguration.Cloud.cscfg file, you can add the NetworkConfiguration element with the required ACL information within to control allowed IPs.

 

In this “test” ACL, we have created “permit” and “deny” rules, which will be evaluated by their numerical order. So rule 100 will be evaluated before 200. In the permit rule, we allowed my local host IP address to access the Web role (note that this must be in CIDR format, so we have to append with a /32 which denotes a subnet range consisting of this one IP address), but in the second deny rule, we denyed any and all other IP addresses from accessing the Web role (which includes any Azure machines that access the public endpoint). Now look at the EndpointAcls section. We have specified that this combination of Web role and endpoint will use the ACL named “test”.

 

2. After publishing this cloud service, we try to access the Web role from my local IP and it is available.

 

 

3. We now try to access the Web role from a browser in one of Azure virtual machines, which fails as it should.

 

 

Refer more details via https://docs.microsoft.com/en-us/archive/blogs/walterm/windows-azure-paas-acls-are-here

 

 

	Working Scope
IP blocking in IIS	WebRole
IP blocking in OS Firewall	Windows OS
VNET NSG	Subnet
Network ACL	Cloud Service Endpoint

 

 

 

 

 

Posted at https://sl.advdat.com/3o0WQ1s