Cloud Police

The Azure cloud offers a variety of access options for resources. Many organizations outsource parts of their data centers to Azure and publish services such as websites, applications, or complex infrastructures as publicly accessible offerings or for users within their own organizations. Rarely are the scenarios so simple that they involve a single website or a single web server operated and published from an Azure virtual machine (VM). "Lift and shift" scenarios or complex architectures, in particular, often map various protected levels that force the isolation of diverse services and components. Classic data centers are rarely connected by any-to-any communication but are grouped into zones and protected.

For demanding applications that comprise multiple components, databases, front ends, back ends, storage, microservices, and loosely connected external data sources, no one likely has the need to talk to everyone else. This means that Azure also needs to support the isolation and distribution of various resources. Imagine a distributed application with multiple tiers distributed across multiple data centers for resilience. Because Azure networks can be connected across data center boundaries and regions, as well, it must be possible to define which requests cross these boundaries. The means of choice goes by the name of Network Security Groups (NSGs).

Rules-Based Traffic Control

On Azure networks, NSGs act like a firewall, examining and filtering incoming and outgoing traffic. Filtering is solved in a classic way, involving definable rules, controlled by Azure admins. The solution is useful for all resources of an Azure network, such as VMs, Azure batch services, HDInsight, Azure AD Domain Services, containers in Kubernetes or container instances, or Azure SQL. These firewall-style capabilities can be applied to multiple resources and are not limited to the outer limits of a virtual network.

For a defense-in-depth strategy, general communication rules can be defined on the virtual network, which in turn can be more granularly defined for individual services within the network. For example, say two virtual networks are connected: One of them will host network infrastructure and the other a publicly available multitiered website. To operate the application, communication must be established and protected both within the website network and beyond its boundaries into the infrastructure network. Although only the front end and back end need to communicate within the web network, the back end has to be able to negotiate with resources from the remote network. Therefore, a multitiered set of rules is required: one NSG at each network level, and several NSGs that include the resource groups of the different servers and allow traffic.

A ruleset of this kind comprises five pieces of information: source, source address, target, target address, and protocol. The ruleset can be used to allow or deny access. NSGs are stateful, so they can remember communication paths and any connections created. You do not have to define response packages for incoming or outgoing requests separately in the ruleset. A rule can contain several target and source addresses and several target and source ports – you do not have to create a rule for each protocol or logical connection. This is especially useful if you can bundle traffic from server groups. NSGs work at the protocol level, making them Layer 4 devices (Figure 1).

Figure 1: NSGs are used to bundle resources and define and control network traffic.

Creating NSGs

You can define up to 100 NSGs per Azure subscription, with Azure Support increasing the limit to 200 on request. Although this sounds like a large number, you should still plan your deployment well to avoid ending up with a bottleneck. Microsoft also allows the definition of 200 firewall rules per NSG (which can be extended to 1,000 if you contact Azure support).

When creating new resources in Azure, you can define a default NSG ruleset for a new virtual network as early as the create stage – protecting new resources such as VMs from the start. First, however, you need to create a new resource group for test purposes, to which you add a new NSG by clicking +Create a resource and searching for Network Security Group . Next, name the NSG and be sure to check that the correct resource group is selected.

When you then create a new VM on the Azure portal in an existing resource group, the wizard will guide you through the most important machine setup decisions. If you create a VM manually, you will be asked for the Network Security Group with options Basic or Advanced , in addition to building a new virtual network (VNet).

The Basic option provides the general switch that enables or disables access to resources on the new network from the Internet. Although this is not very granular, it is particularly useful for less complex or small scenarios or test environments. For a proper ruleset, switch to Advanced and create a new NSG by entering a name. A simple naming convention is very important and recommended.

After deploying the VM, you have a resource group, a VM with all its necessary resources, and two NSGs: one for the VM and one for the network. If you select the default subnet while creating a VM in the virtual network settings (Figure 2), you can also configure an NSG there. From the list, select the NSG you previously created, thereby assigning the VM and the entire virtual network their own NSGs with their own rules. If you look at the Networking properties of your VM, you will see the VM's ruleset, which includes the VM's own NSG for incoming and outgoing network traffic, as well as the virtual network's NSG. The blade therefore lists all rulesets that are applied at different levels (the resource itself, resource group, and network). At the head of the blade, you can view the resulting ruleset in Effective security rules – all rules are determined there. Of course, managing a large number of VMs and deployments manually in this way is difficult; to understand the concepts, it helps to examine the effects and relationships on the Azure portal.

Figure 2: When creating a VM, you can specify whether it is given an NSG immediately.

Allowing RDP and SSH

To grant remote access to the newly installed VM, create two new rules: one for the network NSG and one for the VM NSG. Access from the Internet to the VM must pass through both NSGs so that the traffic can access the VM end-to-end. If one of the rules is missing, you see an Access denied message, and the connection is not established.

Selecting the properties of the VM and then Networking takes you to the rule overview. Press Add inbound port rule to create a new rule for the VM's NSG. Microsoft offers predefined endpoints for the rules via service tags. For Source you can select Service tag and then Internet . In the list of service tags, you can see some additional definitions that can be helpful when creating complex rules and connecting several Azure services to each other: Internet , Virtual Network , AzureLoadBalancer , EventHub , AzureActiveDirectory , and Storage are just a few of the definitions you can select for Azure to assign the correct source or destination IP addresses dynamically to the rule. As the Destination , select the IP address of the VM; now the rule is as specific as possible. As Destination ports , you can specify 3368, 22 for the two services Remote Desktop Protocol (RDP) and Secure Shell (SSH), which lets you manage Windows and Linux remotely.