As part of our recent Azure Security Center (ASC) Blog Series, we are diving into the different controls within ASC’s Secure Score. In this post we will be discussing the control of “Secure management ports”. This control is worth 8 points and is made up of 3 recommendations. More information on secure score can be found here. From an Azure network security standpoint, this a great starting point to improve your overall security posture. The full list of ASC’s Network recommendations are here.
The Control - Secure management ports
Management ports are a requirement for system admins to access and control their machines. The common ports used are 3389(RDP) and 22(SSH). While extremely useful for management, these ports are also common targets for attackers. Your goal should be to reduce exposure and limit the availability of open ports. Bottom line: management ports don’t always need to be open and accessible. They only need to be open when you need them, for example to perform management or maintenance tasks.
The “Secure management ports” control consists of 3 different network related recommendations:
Like the rest of the Secure Score controls, all three recommendations must be considered in order to get the full points and drive up your Secure Score (you can review all of the recommendations here). For example, if no management ports are open then you will be compliant with this control and would not need to enable JIT. If you have management ports opened, then you should ensure management ports are protected by JIT and those VM's are attached to NSGs. Also, you will notice above that one of the recommendations has a “Quick Fix!” No excuses not to remediate that one, just click the button and you are done.
Recommendation #1 - Virtual machines should be protected with Network Security Groups
This one comes up a lot, I am a strong believer in not having any VM face the internet directly (with the exception of NVAs). I prefer to use Azure Policy to deny a deployment of a VM with a NIC containing a public IP address. Needless to say, there are still legitimate reasons to have public facing VMs, and that’s where this recommendation comes into play. Whether is a Dev environment, or someone used a GitHub template; it happens. Those VM’s are now prime targets for RDP and SSH brute force attacks because management ports are typically left in an open state. More information on this in Recommendation #2.
Protect your VM from potential threats by restricting access to it with a Network Security Group (NSG). NSGs contain access-control lists (ACL) and can be assigned to the VM's NIC or subnet. The ACL rules allow or deny network traffic to the assigned resource. To learn more about controlling traffic with NSGs, NSG Overview.
If you are looking for more of a programmatic way to manage NSGs, you can used PowerShell, REST or Azure CLI, more information on managing NSGs here. You can always use Azure Security Center's Just-in-time (JIT) VM access to lock down inbound traffic to your Azure VMs by demand, we will cover that in Recommendation #3.
Recommendation #2 - Management ports should be closed on your virtual machines
This recommendation takes into consideration one of the biggest default risks of the cloud. Most templates or marketplace VMs will have management ports open… Management ports usually consist of the ports that you used to connect to your Azure virtual machines i.e. Remote Desktop Protocol (RDP) and the Secure Shell (SSH) protocol. These protocols enable admins to manage VMs from remote locations and are common management ports. The potential security problem with using these protocols over the internet, is that attackers can use brute force techniques to gain access to Azure virtual machines. After the attackers gain access, they can use your VM as a launch point for compromising other machines on your virtual network or even attack networked devices outside of Azure.
This is such an important part of your security, that we added it to the wizard. As you see below, a Basic NSG only allowing RDP (this is a Windows VM, it would be SSH for a Linux VM) is selected by default.
We recommend that you disable direct RDP and SSH access to your Azure virtual machines from the internet or even better do not allow VMs to have NICs with Public IP addresses.
For customers desiring a more comprehensive solution to internet exposed services, a rethinking of network design may be appropriate. It is often more secure to allocate only private IP addresses for VMs rather than allowing each to have its own Public IP Address. While NSGs can be used in combination with JIT to control access to public resources, the management of inbound VM access can be centralized using other strategies such as:
To read more about network designs, please visit the Azure Architecture Center.
This recommendation requires a moderate level of effort and has a moderate impact on users. If users or administrators have always accessed their VMs over the internet, this will require a change in how they connect. Use the following steps to manually remediate and restrict access to your virtual machines:
Recommendation #3 - Management ports of virtual machines should be protected with just-in-time network access control
This is one of my favorite recommendations and it requires the Standard tier to be enabled. Just-in-time (JIT) allows you to lock down and designate a specific amount of time, that inbound traffic to your Azure VMs would be allowed. This reduces exposure to attacks while providing easy access to connect to VMs when needed.
The description of this recommendation is: “Azure Security Center has identified some overly-permissive inbound rules for management ports in your Network Security Group. Enable just-in-time access control to protect your VM from internet-based brute-force attacks”. It is a low impact to users and requires a low level of effort to implement as it comes with a “Quick fix” option. You will notice that resources are flagged as “Unhealthy”, “Healthy” or “Not Applicable”.
For more information on Just in Time (JIT) VM access, and how to enable it for your virtual machines, please see the ASC documentation here.
Wrapping up this blog post, I’d like you to keep in mind this is a small fraction of what ASC and the Enhanced Secure Score can offer to you, to strengthen your security posture and increase your secure score. This blog post details some robust steps you can leverage to increase your own comfort level in protecting your environments / assets.
I hope you enjoyed this article and learned something that will assist you on your continued journey of cybersecurity. Please continue to enjoy our ASC Secure Score blog series and I look forward virtually seeing you in the next one. If you would like more information on how to protect network resources in Azure Security Center visit our docs or our full list of network recommendations.
Continue to remediate based on ASC’s recommendations and don’t hesitate to use Workflow automation to do so. If you need assistance in integration Workflow automation with ITSM, take a look at this blog on how to integrate ServiceNow with ASC.
Reviewer and Acknowledgements
Yuri Diogenes, Senior Program Manager – CxE ASC Team
Thank you to @Anthony Roman, for assisting in the Azure Network security options.
Thank you, Doug Birch for writing the original version of this article.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.