Understanding Azure cloud services firewall

2
votes

I'm trying to understand what are firewall rules for Azure cloud services (Web/Worker roles) by default, and I'm confused.

Based on multiple source, including this link http://download.microsoft.com/download/C/A/3/CA3FC5C0-ECE0-4F87-BF4B-D74064A00846/AzureNetworkSecurity_v3_Feb2015.pdf, inbound connections are blocked by default for cloud services, be it worker role or web role. To open inbound connection I would need to specify parameters for EndPoints elements in .cscfg.

However, I never did this, but my web roles and worker roles accept inboud connection, even UDP connection to worker role.

What am I missing?

Update: I apologize, I was looking at wrong file. For reasons I cannot explain I mixed .csdef and .cscfg. Now it looks like stupid question :)

2
azureazure-web-rolesazure-worker-rolesazure-cloud-services

2 Answers

1
votes

David has most of the answer covered, for the detailed WHY it works: https://azure.microsoft.com/nl-nl/documentation/articles/cloud-services-role-enable-remote-desktop/

Take a look at the csdef file, there is an imports section in there

<Imports>
  <Import moduleName="<import-module>"/>
</Imports>

The module for RDP is "RemoteAccess" and there will be a "RemoteAccessForwarder", all plugins/modules are in the Azure SDK in this directory (replace v2.9 with your azure SDK version)

C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9\bin\plugins

Importing this module results in the following config being added to the csdef file at runtime:

<?xml version="1.0" ?>
<RoleModule 
  xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition"
  namespace="Microsoft.WindowsAzure.Plugins.RemoteAccess">
  <Startup priority="-1">
    <Task commandLine="RemoteAccessAgent.exe" executionContext="elevated" taskType="background" />
    <Task commandLine="RemoteAccessAgent.exe /blockStartup" executionContext="elevated" taskType="simple" />
  </Startup>
  <ConfigurationSettings>
    <Setting name="Enabled" />
    <Setting name="AccountUsername" />
    <Setting name="AccountEncryptedPassword" />
    <Setting name="AccountExpiration" />
  </ConfigurationSettings>
  <Endpoints>
    <InternalEndpoint name="Rdp" protocol="tcp" port="3389" />
  </Endpoints>
  <Certificates>
    <Certificate name="PasswordEncryption" storeLocation="LocalMachine" storeName="My" permissionLevel="elevated" />
  </Certificates>
</RoleModule>

This will open port 3389 for the RDP connection, so the Endpoint is in the .csdef file, but through an import.

Also take a look at the "RemoteForwarder", it acts as the gateway, so only 1 port (3389) has to be opened on the outside, and only 1 instance will listen to this. The RemoteForwarder will then forward the RDP connection to the right machine. More info: https://blogs.msdn.microsoft.com/avkashchauhan/2011/12/06/how-does-remote-desktop-works-in-windows-azure/

2
votes

You're correct - web and worker roles require endpoints to be defined, to allow external traffic to pass through to your role instances.

Regarding the fact you can currently access your existing web/worker instances: By default, an endpoint for port 80 is created for your web role, and if you enabled RDP, that is enabled as well.

Just be aware that there are port mappings that occur: That is, you specify the external port (maybe... port 8000), which then maps to your actual port where your code is listening (maybe... port 80).

And also be aware that, if you use one of those ports for one role, you must come up with a different port for a different role. All instances of a given role may consume the same port, in a load-balanced fashion. But... if you set up a web server using, say, port 8000 externally on your web role, and you define another web role (or maybe a worker role), you cannot use port 8000 for that role.

Role endpoints are exposed in the cloud service project, within Visual Studio, in case you don't want to edit the configuration file directly.