Accessing a VM in your local environment is generally a straight forward operation. You initiate an RDP connection to a private IP and enter your credentials. Simple and relatively secure as all traffic is local relative to your LAN. With Azure, this can become more complex as the option to attach a public IP is available.
Even with added complexity, attaching a public IP to your VM should not be viewed as a negative. The functionality it offers is incredibly useful in many scenarios. However, as this allows the VM to be accessed from the internet, the correct precautions must be taken to ensure your VM is kept safe and secure.
Let’s start with the most basic but often overlooked piece of security; username and password. Choose a username that is unique to your organisation and choose a password that is complex. RDP ports are one of the most tried perimeter ports on Microsoft’s public network, having your credentials as secure as possible adds a minimal but useful level of security to your VM.
Next up, a Network Security Group. This can prevent or allow IP addresses accessing your VMs network interface and/or subnet. An example configuration would be to allow access to RDP for your outbound IP range and deny all other access. This would mean that only your outbound IP range can access the RDP port. This works well but what if the VM requires access from multiple locations? What if you don’t have access to their IP range?
This is where we add our final layer of security, a public facing Azure Load Balancer. This object will carry it’s own public IP address and allows for the creation of NAT rules. To secure the RDP port (3389 by default) simply create an inbound NAT rule to translate a random public facing port, for example 50001 or 100003, to our standard internal port 3389. Once this rule is in place, you should remove the public IP associated to your VM. The LB association will route traffic inbound and outbound via the LB public IP and therefore use the NAT translation for secure access. For those of you who used ASM VMs, this is similar to how endpoints were setup within Cloud Services, but this offers a more granular control.
Below are some links on some of the features and points mentioned in this post as well as a technet blog on provisioning and attaching an LB for RDP. As always, any questions, get in touch, enjoy!
wedoAzure 