Security professionals have been trying to flag the risks of public facing RDP for years. Despite all the news articles and tweets, the volume of public RDP remains high. Normally these articles, would show a report from Shodan and this article is no exception:
Although this report may be overused, it does show how exposed RDP is today. As users move towards the cloud, it doesn’t necessary mean that we are fixing the issue. Look at the Top Organizations. Notice that they are cloud providers.
Not everyone can be blamed however as some simply don’t understand the risk. I imagine that they are just trying to run a service at a minimum cost. Others though, don’t have an excuse and it’s just either down to laziness or misconfiguration. When I say laziness, I’m talking about the IT users that say, “it’s just easier that way” or “my password is secure, so it doesn’t matter”.
Whatever the reason, we need to help get these off the internet and secured. This article will focus on Azure but other cloud providers having similar solutions.
Not everyone will have money to through at security, so I’ll cover the free options, that just take a little configuration. There are some solutions which come at a small cost however but it’s up to you to weigh up how much it would cost to recover should you be attacked.
Let’s run through a simple example.
Let’s say I run a simple service in Azure from a remote server and I RDP to that server over the internet. This is what it would look like:
At this point, you may be thinking, what about my password? It’s totally secure!
Although that “may” be true, in theory every password is crackable. The complexity just increases the time and effort needed to crack the password. All of this is irrelevant though, should your credentials be leaked or stolen.
To show you an example. This is a VM I span up in Azure and after an hour, this appeared. This is a brute force attack against my machine. This is common and if you aren’t looking at it, you’re not going to know. To be able to view these you will need security center standard, but I will go into that later.
Some of these solutions won’t 100% stop these attacks but it will help minimize the attack surface. Let’s start with the free options.
Network Security Groups
https://docs.microsoft.com/en-us/azure/virtual-network/security-overview
Network Security Groups are free and help control the network traffic to your endpoint, subnet or VNet. They can be applied at different layers but during this example, it’s applied to the machine. If you have multiple and want to manage it this way, it is best you move it to the subnet layer. Then you can control each instance. This will also be more beneficial should you use ASGs.
If you were to click on your virtual machine and click networking, you might see the follow (if public).
Yours may be different but notice that I have an allow rule (inbound) on the RDP port 3389. This basically means, anyone with internet access can attempt to RDP to my machine. They may not be able to pass the login screen, but they can at least have a go (remember the threat report at the top).
I’m going to cover two options. I’m not going to cover dissociating the Public IP as this brings down other services (ports). I’m just going to focus on Public RDP at a simple level for this walkthrough. The first option is managing it in a Network Security Group (NSG). The second is using an Application Security Group (ASG).
Network Security Group
If you click on your RDP rule, you will see a similar screen. Here we can click the dropdown for Source and select IP Addresses. Although it says Addresses, you can enter a single IP.
How do I know my source IP you ask?
If you Google, what’s my IP, it will give you this information:
If you want to do it through PowerShell, you could run the following: (curl http://ipinfo.io/ip).content
In this example, mine is the 80.4.146.198 address. This will be my source IP. If we added that in, it would look like the following:
Doing this will mean that RDP traffic is only allowed from this location. If you travel, you will have to add in the new IP each time. This isn’t an automated process. If you go to Starbucks, the Source IP is different than from your home office. If you run large environments you may be running Firewalls, but if you aren’t this is enough to take it off the internet away from scanners and malicious parties.
Application Security Groups
If the IP management seems to long winded, you could setup an Application Security Group. Although these are often used in scalable environments, they do work for small instances. They can act as an on/off switch should you think the above is too much. Although locking it down by source IP is preferred, doing this is still better than just leaving it exposed so let’s go through it.
To create an ASG, simply search Application Security Groups and click Create.
ASGs aren’t anything too special but they really do help to control/secure traffic based on a pointer. They sort of work as an ID card. I’ll show you what I mean. If we go back to our virtual machine, click networking and select our RDP rule, we can see our current rule:
Note that I’ve reset the Source to be Any, just to show you how this works.
Under the Destination dropdown, select Application Security Group and chose your ASG. This will now break RDP. The reason why is that we are saying that anybody on the internet can RDP to the ASG group. At the minute, there are no machines in the group, and you can’t RDP to nothing.
What we need to do is add this machine in to enable RDP. This can be a lot easier than deleting and creating the RDP rule each time in your NSG. Under the ASG tab on the machine, you will see the following:
Click Configure… and select your ASG. Once done, this now means that RDP is now live to this machine.
To take it off, simply click Configure…and deselect it. This now blocks RDP. To add it back in, click configure….and select it again. Hopefully you can now see what I meant by ID card as it says, hey I’m in the ASG, let people RDP to me.
NSGs and ASGs come at no cost and act as a layer of protection for your network.
Azure Bastion
https://docs.microsoft.com/en-us/azure/bastion/bastion-overview?
Should you have multiple virtual machines you directly RDP or SSH too, you could use the Bastion service which is now out of preview. This acts as a jump server and gives you the ability to remove the Public IPs from your virtual machines and connect through the Bastion server. This server is a service however and cannot be locally managed. What I mean by that is that you can’t login to it.
Let’s run through an example.
For my machine, I’ve removed the Public IP and there is no way to RDP to my machine, unless I setup a connection to my network using VPN gateways etc.
Now if you go to the Bastion service and click Create, you will most likely come across this error:
This is because we must first setup a subnet called AzureBastionSubnet. In small instances, you will need to create the subnet under the same VNet as your machines sit in. For example, if my machines are using VNet1, my Bastion subnet needs to be under VNet1.
If you go to your VNet and click add a Subnet, you will be able to add a new subnet. Remember that it needs to be called AzureBastionSubnet.
The range can be any, but the minimum is /27. This is entirely all up to you. Once done, go back to Bastion, Create and you can select your options:
If you’re happy, click Create and wait a few minutes. Our network will now look something like this. Note you won’t be able to see the Bastion host, but it is there. You can view this under your resource group or Bastion page.
If we try and access our virtual machine using the standard remote desktop client, it will fail. The reason why is that if you look at the diagram, I have no Public IP anymore. This is where my Bastion server can come into play. If I go to my virtual machine, I can select the dropdown and select Bastion.
I can then enter my credentials:
Once I pass the credentials, I can then RDP to the machine through my browser:
Notice that my IP is a private address however, I can access the server over the Internet.
Just to note, should you wish to copy and paste, you can select the arrows to the left and it will pullup the clipboard:
What about my Bastion Public IP, can this be hacked?
If we run a quick scan on the Public IP, we can see that only 443 is open:
Should you attempt to browser, you will see the following:
For now, I’m not going to say it can’t be hacked but as of today, there are no known exploits. The Bastion server can help not only save costs on Public IPs for servers that aren’t running web applications. They also help secure the environment as you are required to go through the portal. This portal can be wrapped in a conditional access to enforce MFA but that is another story.
JIT – Just In Time Access
https://docs.microsoft.com/en-us/azure/security-center/security-center-just-in-time
JIT comes with the standard package of security center. Although you may have to keep the port on the internet, you can at least control a timeframe. It works on requests so for instance, if you need to RDP to your machine for an hour, you could request that it be lifted for an hour using JIT. I’ll run through a quick example.
Under Security Center, in the JIT tab, I’m just going to enable it for my machine.
Here I can customize what I want to control. If you opened these up, you could change it to match your needs. If you leave the defaults, the following ports will be controlled by JIT and it will add a rule at the top of the virtual machines NSG.
Like so…
This now means that your RDP client on your machine won’t work. You will have to login to the Azure portal and request the ports to be lifted. Once they are, the ports are lifted for X amount of time. To request, you can click on your machine, click the Connect tab and select Request Access
If you wanted to change the rules, you can go into Security Centre, click JIT and select Request Access. This will give you a custom option like so:
Once approved, you will see the following and your RDP will now work.
Remember though, if you haven’t limited your Source IP, everyone can access the port. You now have security center watching your VM which will show you attacks like the example at the start.
Hopefully this shows that there are multiple ways to secure your virtual machines and not all have to come with a cost. For those that do, it’s important you understand the costing as you will be billed for the last 2 options. Microsoft document this here:
Bastion: https://azure.microsoft.com/en-us/pricing/details/azure-bastion/
Security Center : https://azure.microsoft.com/en-us/pricing/details/security-center/
amoran.io 
Leave a Reply