In this blogpost, I want to explain how you can use Azure Load balancer to increase the management services security, without any cost* and with minimal management overhead.
A common deployment scenario in Azure is to deploy IaaS VMs. These VMs needs to be managed, over their management services, often without establishing a VPN or expressroute circuit.
To understand and visualize why it’s a bad idea to expose your management services (SSH and RDP ports) directly on the internet, I’ve deployed the OMS agent on my internet exposed virtual machines. Using this simple query, I can find all Security events with eventID 4625 (An account failed to log on): Type=SecurityEvent AccountType=user AND EventID=4625 | measure count() by Account
As you can see from the log search, we have had over 2.000 failed log on attempts in a brief time frame. Varying from “Administrator” to widely used account names on both Windows and Unix systems.
The source of all these failed logins are robots trying to access the VMs using a combination of brute force attacks, most used password list and rainbow tables. Common for most of these attacks, is that they scan for known open ports such as RDP and SSH.
A common way of protecting against these attacks have been to not publish the management services directly on internet, using NAT (Network address translation) rules, deploying group policies to lock down the management services, avoid using the most commonly used usernames, in addition to using secure and different password on all virtual machines.
While this blogpost assumes that you follow common best practices for securing your management services, we will address the more uncommon NAT rule configuration topic using the Azure Load balancers NAT feature.
An inbound NAT rule maps a public port on the load balancer to a port for a specific virtual machine in a back-end address pool. That means we can connect to the load balancer on a diffuse port, such as 63011, and let the load balancer map traffic to the backend management services port, such as 3389 for RDP.
The deployment scenario in this post assumes that you have a single Windows backend virtual machine, with no public IP attached to the virtual machines network interface.
The first step in the deployment process is to deploy a new load balancer from the Azure market place.
From the Azure portal;
Make sure to deploy the new public IP with a dynamic IP address, which is free, but might change if deallocated. In step 3, we will configure a “DNS name label” for the IP, and make sure it does not matter for your end-users if the IP of the load balancer changes.
The next step is to add an inbound NAT rule to the load balancer from the load balancer blade.
From the azure portal;
Make sure that you specify a high range port in the “port” field. This is the port you will connect to your management service from the internet. The “target port” field is the backend management system port, such as 3389 for RDP.
Next, navigate to the public IP address that was created in step 1. Under the “configuration” on the public ip address blade, add a new “DNS Name Label”. The “DNS name label“ must be globally unique.
Now, create a CNAME record that’s easy for you to remember, such as jumpstation.lumagate.com and point it to the “DNS name label” you just created. You should now be able connect to the management service on the associated system you specified in step 1, even if the IP of the load balancer changes.
Remote desktop connection;
If you're using a Network security group on your subnet, and you should, remember to allow traffic from “internet” to the management service port in an inbound security rule.
Revisting the “Security and Audit” module in OMS, I can see that I only have 8 failed logons the last 24 hours. All coming from internal systems.
By creating a free Azure load balance with an inbound NAT rule to map our management services port to a different than the standard port, we have greatly reduced the attack surface of robots.
* There is no reservation cost for the first five static public IP addresses whether associated with a running virtual machine network interface or an Azure Load Balancer. Usage cost applies. Any additional static public IPs are charged for reservation.