Sharing of thoughts and information is what blogging is all about. This way we can learn from each other. Post A Comment!These postings are provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.
Anthony Bartolo Twitter | LinkedIn
Pierre Roman Twitter | LinkedIn
On October 22nd, we discussed how to use endpoint to allow traffic to your machines. Well there is another way. One that provides more granular control and more functionality. Setting ACL on the endpoints.
An ACL provides the ability to selectively permit or deny traffic for a virtual machine endpoint. This packet filtering capability provides an additional layer of security. Currently, you can specify network ACLs for virtual machines endpoints only. You cannot specify an ACL for a virtual network or a specific subnet contained in a virtual network
Setting up ACL on between VMs on Azure will allow you to permit or deny incoming traffic as you see fit based on remote subnet IPv4 address range to a virtual machine input endpoint. It will also provide the following capabilities
Basically it’s another layer of security that you can apply to your environment. In this post we’ll look at the steps required to configure ACL on a Virtual Machine endpoints.
To try this for yourselves, use the info in an earlier post on Windows Azure Trials and consume the following MVA modules (they’re full of great info you can access at your convenience.)
An ACL is an object that contains a list of rules. When you create an ACL and apply it to a virtual machine endpoint, packet filtering takes place on the host node of your VM. This means the traffic from remote IP addresses is filtered by the host node for matching ACL rules instead of on your VM. This prevents your VM from spending the precious CPU cycles on packet filtering.
When a virtual machine is created, a default ACL is put in place to block all incoming traffic. However, if an endpoint is created for Remote Desktop for example(port 3389), then the default ACL is modified to allow all inbound traffic for that endpoint. Inbound traffic from any remote subnet is then allowed to that endpoint and no firewall provisioning is required. All other ports are blocked for inbound traffic unless endpoints are created for those ports. Outbound traffic is allowed by default.
The default ACL for the RDP endpoint would be as follows.
1- Installing the Windows Azure PowerShell Module
Windows Azure PowerShell is the module for Windows PowerShell that you can use to control and automate the deployment and management of your workloads in Windows Azure.
You can download and install the Windows Azure PowerShell module by running the Microsoft Web Platform Installer. When prompted, click Run. The Microsoft Web Platform Installer loads, with the Windows Azure PowerShell module available for installation. The Web Platform Installer installs all dependencies for the Windows Azure PowerShell cmdlets. Follow the prompts to complete the installation.
2- Connect PowerShell to your subscription
The cmdlets require your subscription information so that it can be used to manage your services. As of the .0.7 release of the module, there are two ways of providing this information. You can download and use a management certificate that contains the information, or you can log in to Windows Azure using your Microsoft account or an organizational ID. When you log in, Windows Azure Active Directory (Windows Azure AD) authenticates the credentials. In our environment we will use the certificate method
The Windows Azure PowerShell module we just installed, includes cmdlets that help you download and import the certificate.
Run the Get-AzurePublishSettingsFile cmdlet on your local server and it opens a web page on the Windows Azure Management Portal, from which you can download the subscription information. The information is contained in a .publishsettings file. You may have to authenticate with the Microsoft account you used for your trial or your MSDN subscription. save that file locally.
3- Use the cmdlet to create a ACL.
To retrieve a complete list of the ACL PowerShell cmdlets, you can use either of the following:
get-command -module azure -name *ACL*
Here we will look at how we create a new ACL that contains rules. This ACL will be applied to a virtual machine endpoint (in our case endpoint on our AZR-DC2 virtual machine).
he ACL rules will allow access from our on premise subnet only. To create a new Network ACL with permit rules for a remote subnet, open a Windows Azure PowerShell ISE and use the following command to build your script and once completed, execute it.
first line we will create the new network ACL object.
$acl1 = New-AzureAclConfig
Set a rule that permits access from our on premise network. you set rule 100 (which has priority over rule 200 and higher) to allow the remote subnet 192.168.11.0/24 access to the virtual machine endpoint. Replace the values with your own configuration requirements. The name “Remote Desktop ACL Config” can be replaced with any friendly name that you want to call this rule.
Set-AzureAclConfig –AddRule –ACL $acl1 –Order 100 –Action permit –RemoteSubnet “192.168.11.0/24” –Description “Remote Desktop ACL config”
For additional rules, repeat the cmdlet, replacing the values with your own configuration requirements. Be sure to change the rule number Order to reflect the order in which you want the rules to be applied. The lower rule number takes precedence over the higher number.
Next, you can either create a new endpoint (Add) or set the ACL for an existing endpoint (Set). for us, we will set an existing endpoint called “RDP” and update the virtual machine endpoint with the ACL settings.
Get-AzureVM –ServiceName AZR-Lab –Name AZR-DC2 | Set-AzureEndpoint –Name “RDP” –Protocol tcp –Localport 3389 -PublicPort 3389 –ACL $acl1 | Update-AzureVM
And the result is as follows:
Once the ACL is applied, if I try to access the AZR-DC2 vm from the public facing subnet (10.10.2.0/24) of our Virtual network I get the following error:
Here we go, one more way of controlling what traffic can access our machines in the cloud.
Pierre Roman | Technology Evangelist Twitter | Facebook | LinkedIn
Very good. Thanks for sharing