Temporary Remote Access

Azure offers just-in-time VM access in the Azure Security Center (ASC) for additional protection of VMs that need ports opened. ASC can protect port releases by checking during connection establishment whether the user to be connected has permissions for the VM in Azure role-based access control (RBAC). If so, access is allowed, if not, access is canceled. ASC creates new NSG access rules for both the virtual network and the VM itself during VM enrollment. By default, access to VMs and management ports is blocked.

If an end user wants access, they first need to request permission by selecting Request access in the properties of the VM under Connect . It is only after doing so that VM access via RDP or SSH is enabled and the RDP file is released for download. Access will then only be enabled for the IP address from which the access request was made. This can also be enabled with NSG rules that ASC manages. Access is automatically rolled back after a predefined time (the default is three hours). In ASC, you can also define whether an access request requires confirmation from another administrator or whether access can be granted immediately after manual activation.

The enrollment of a VM for just-in-time access can be initiated on the Azure portal by selecting the VM properties and then Configuration and pressing Enable just-in-time policy . As soon as you enable this, you will discover that the ASC has already created all the required rules and prioritized them as necessary (Figure 3). Each VM is given an NSG rule that contains an any-to-any block statement. If access to a VM is requested with Request access , the system creates a new NSG rule (for each access path), and access is then permitted specifically with a lower priority value. The lower the priority value, the earlier the rule is evaluated. The first applicable rule wins.

Figure 3: Azure Security Center creates the necessary NSG rules to protect VMs created by just-in-time configuration.

Publishing endpoints on the Internet is highly discouraged, but managing the VMs either from an internal corporate network connected to Azure by ExpressRoute or a VPN, or with a point-to-point VPN connection from the laptop to the target network on which the VMs are located, gives you access to the VMs without actually having to publish ports on the Internet. If neither ExpressRoute nor VPN are available, as might be the case in a test environment, enable remote access only as long as you need it to reduce the attack vectors to the extent possible.

Automate NSGs

Setting up multiple NSGs manually is not particularly efficient; automation with PowerShell or Azure Resource Manager (ARM) templates is the far more convenient and enterprise-ready option. The cmdlets for creating and managing NSGs are available by an Install-Module named AzureRM. One essential advantage is that the scripts can be archived and are thus perfect as documentation, which is an important step toward Infrastructure as Code (IaC).

You will receive an overview of all NSGs in a resource group in Azure as soon as you register with Azure and choose a subscription:

> Login-AzureRMAccount
> Select-AzureRmSubscription -Name "Test-Subscription"

You call the NSGs of a resource group as follows:

> Get-AzureRmNetworkSecurityGroup -ResourceGroupName "NSG-Test" | SELECT Name, SecurityRules

A new rule for an existing NSG is easily added:

> $nsg = Get-AzureRmNetworkSecurityGroup -ResourceGroupName "NSG-Test" -Name "Vnet-NSG"
> $nsgVNet | Add-AzureRmNetworkSecurityRuleConfig -Name "AllowFTP" -Description "Allow FTP port in for FTP server VM" -Protocol Tcp -SourcePortRange "*" -DestinationPortRange "21" -SourceAddressPrefix "*" -DestinationAddressPrefix "10.0.4.4" -Access Allow -Direction Inbound -Priority 200 | Set-AzureRmNetworkSecurityGroup

Here, the Network Security Group to be changed is first stored in a variable and then piped to Add-AzureRMNetworkSecurityRuleConfig before being set to Set-AzureRMNetworkSecurityGroup. Changing a rule follows a similar procedure:

> $nsg = Get-AzureRmNetworkSecurityGroup -Name "Vnet-NSG" -ResourceGroupName "NSG-Test"
< $nsg | Get-AzureRmNetworkSecurityRuleConfig -Name "AllowFTP"
> Set-AzureRmNetworkSecurityRuleConfig -Name "AllowFTP" -NetworkSecurityGroup $nsg -Protocol "UDP" -Priority 150

You just call the rule by name and then change it.

Traffic Analysis with Flow Logs

Where Network Security Groups are used, you are naturally also interested in their content. For this purpose, Microsoft provides the NSG flow logs function as part of the Network Watcher, which lets you record, save, and later evaluate the details of incoming and outgoing IP traffic. Flow logs are not handled like other logfiles; they are stored directly in the storage account. The connections are generated on storage during logging and created in the usual JSON format to enable subsequent standardized reading and evaluation with a security information and event management (SIEM) tool. All relevant information, such the source and target IP addresses, source and target ports, protocol used, and whether access was allowed or blocked, are recorded.

To enable NSG flow recording, enable the Network Watcher, which then logs the NSG connections. You will find the Network Watcher by searching for it on the Azure portal with the All services selection. In the wizard, select the corresponding region (e.g., USA ) and enable the Watcher. Next, go to the Azure portal, select Subscriptions and select the target subscription where the NSG is located. For the subscription, search in Resource providers for a provider named microsoft.insights , which you also need to register.

Now you can enable flow logs. As already mentioned, this can be done at different levels. The storage account and the retention period are defined in each case. However, configuring this manually for each NSG will involve a great deal of work; the Azure CLI or PowerShell is very helpful here. A script by Alexandre Verkinderen [1] uses PowerShell to enable NSG flow logs and saves them to the defined storage account. The retention period for the logs can also be defined to suit your requirements; you configure this as a value in days. If you leave the value empty, the logs are not deleted.

If you want to evaluate the logs in a visually appealing way and publish them on a dashboard, you can have the connections processed by Power BI. Microsoft does not have its own dashboard for flow logs but offers a template that displays the connection data [2]. The template requires both the storage account name and the desired number of logfiles to be loaded and included in the analysis. Only the current access key is then required to access the storage account; then, the logfiles are downloaded and displayed in previously prepared visualizations.