As part of our recent Microsoft Defender for Cloud Blog Series, we are diving into the different controls within Defender for Cloud’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 Defender for Cloud’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:
- Internet-facing virtual machines should be protected with Network Security Groups
- Management ports should be closed on your virtual machines
- Management ports of virtual machines should be protected with just-in-time network access control
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 Microsoft Defender for Cloud'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:
- DNAT Rules on Azure Firewall – Allows centralized management of inbound access to any resource on an internal VNET. For example, RDP, SSH, and other custom management ports can be forwarded into resources on your private networks, and all activity is logged centrally via Azure Diagnostic Logs. Azure Firewall also integrates with JIT so ports do not have to be permanently open.
- Azure Bastion – Centralized management of RDP and SSH to private networks via a virtual bastion host. All activity is logged centrally via Azure Diagnostic Logs.
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:
- Select a VM to restrict access to.
- In the 'Networking' blade, click on each of the rules that allow management ports (e.g. RDP-3389, WINRM-5985, WIMRM -5968, SSH-22).
- Either change the 'Action' property to 'Deny’ or improve the rule by applying a less permissive range of source IP ranges.
- Click 'Save'.
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: “Defender for Cloud 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 Microsoft Defender for Cloud documentation here.
Next Steps
Wrapping up this blog post, I’d like you to keep in mind this is a small fraction of what Defender for Cloud 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 Defender for Cloud 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 Microsoft Defender for Cloud, visit our docs or our full list of network recommendations.
Continue to remediate based on Defender for Cloud’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 Defender for Cloud.
Reviewer and Acknowledgements
Yuri Diogenes, Principal Program Manager – CxE Defender for Cloud Team
Thank you to @Anthony Roman, for assisting in the Azure Network security options.
Microsoft
