IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Hi, Mark Rowe here, and I am the creator of Augmented Living, a Developer/Architect for Microsoft’s Modern Applications Solution Center as a senior consultant, and a long-time Microsoft fanboy and blogger.
One of the most hit aspects of security is RDP on the default ports with poor password governance.
People are busy, we all are.
As previously seen on the web, open VNC and RDP ports are not, shall we say, uncommon. For example, ‘VNC Roulette‘ last year was a real eye opener.
So, lock it down, right? We all know a username of “admin” and a password of “password” can only keep your kids and the neighbors from getting into your router (maybe). It doesn’t do much good against attacks on RDP sessions with actual hackers doing the attacks.
So, what do we do? We do more. Time is, as they say, ‘a wastin’, so Let’s get it started.
Note: In this post, we assume you have already setup a virtual machine in ARM in Azure with Remote Desktop Protocol already working on the default IP and port (3389).
Part 1: Create Load Balancer
-“Ok Done! We are with you but what is with all the tomfoolery! What is this magic you speak of?”
The magic comes in with the Load Balancer. First things first, let’s create that.
Add New Load Balancer.
Give the Load balancer a public IP. This will allow it to be seen on the “interwebs”.
Name the IP address and make it static. (Unless you want Dynamic, but you will need to get your Load Balancers IP when it changes.)
We then make sure everything is properly assigned and set the Resource Group to the same one as the Virtual Machine.
Open the Load Balancer you just created.
Add New Inbound Nat Rule to the Load balancer.
-“Hey this isn’t magic or gnomes! I set this up in my router in the 90’s, you know back when IRC was cool and my email address ended in compuserve”.
You got me, this is just like that.
Figure out the Port you want to connect to on the external Load Balancer
Forward that to 3389 internally.
Then set a NAT Rule you can point to an availability set, or just a single VM.
This should make it so you can reach the Load balancers IP:PORT and get into RDP.
*Port would be something like 4000 or 10001. If your IP were 18.104.22.168. Then your RDP line would read 22.214.171.124:4000 or 126.96.36.199: 10001. Those would translate to the 3389 port internally and still connect you to the VM via RDP.
– For all you kids raising your hands out there. Yes 169. addresses usually mean no DHCP could be contacted and that IP should never happen. – Overachievers!
Any other ports that need to make it through here you can also set up 1 rule per. HTTP, HTTPS etc. You can keep the PORTS the same if you just want a pass through. You can keep them or NAT translate them.
Part 2: Removing the Public IP from VM.
Hold my ‘coffee’. We’ve got this, and if not, there is always support. Right?
“Wait, are you selling support hours? ”
You will never know, or maybe you will in 5.
Go to your Virtual machine, click network interfaces. Then double-click on the record with NAME -PUBLIC IP ADDRESS
Click on IPCONFIGURATION then double-click the appropriate Name for the configuration.
Now disable the public IP.
Your traffic will now be forced to go through load balancer where you can change IP’s etc and the default 3389 port should no longer be accessible externally.
NOTE: Your Network Security Group will not change, it will still need access to ALL on 3389 if you wish to connect from everywhere.
Part 3: Don’t like only having an IP address?
- “My phone keeps all my numbers in it, if I can’t remember those… How about a name for this monstrosity?”
Easy Peasy, well easy as a few UI clicks. Back to the Portal!
Select your Virtual machines from the Virtual machine menu.
Double-click under Public IP Address/DNS name label
Set the DNS Name in the Textbox. This will give the Load Balancer Endpoint that DNS location.
You should now be able to get to your VM through the LB DNS Name!
NOTE: Security groups are still required on your VM or your subnet in order for data to pass through.
Thanks again for all the work Matt Garing and Sumeet Kumar in helping hash this out.
Questions? (About this article)
Mark Rowe Mark.Rowe@Microsoft.com