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 “Restrict Unauthorized Network Access”.
There are many ways to protect your data nowadays; it is all about finding the best tools that adhere to your infrastructure and integrating them in the most efficient and effective way. Azure Security Center has an Enhanced Secure Score which brings specific security recommendations of your hybrid workloads in the cloud (Azure or others) as well as on premises. These recommendations are meant to keep your resources safe and improve your security hygiene where a continuous teamwork must be placed.
Gaining network access should be based on IP and device restrictions, firewall policies, network ports control, network security rules and more according to your business’s needs. Azure Security Center’s security control “Restrict Unauthorized Network Access” has a series of recommendations for this type of scenario. For a reference on this security control’s definition and others, visit this article.
The type of resources that you have in your infrastructure will dictate the kind of recommendations that are going to appear under “Restrict Unauthorized Network Access” security control. The sections that follows will cover some of the most common security recommendations that belong to this security control.
Azure Security Center identifies virtual machines that are exposed to the Internet without a network security group (NSG) to filter the traffic. Although there are some other options to protect your internet-facing virtual machines, for the purpose of ASC, this is the security recommendation that needs to be remediated. When you go and click that recommendation, there will be a manual remediation you can follow. Once all the VMs have NSGs assigned, the task would be completed.
This recommendation appears when Azure Security Center identifies that some of your Network Security Groups' inbound rules are too permissive. Which means, you have inbound rules that are too broad, for example from “Any” to “Any”. This recommendation is relevant only for virtual machines protected by a network security group, so even if you have virtual machines on NSGs but are not-internet-facing, they will appear in the “Not applicable resources” tab. The manual procedure indicates that you should improve the network security group rule by applying less permissive source IP ranges. Once this is performed, it would appear as completed.
Cross-Origin Resource Sharing (CORS) allows restricted resources on a web page to be requested from another domain. This recommendation aims to harden the list of required domains that can interact with your Function App/Web App. It has the Quick Fix button, which triggers an automatic script (modifiable) to remediate.
Note: The allowedOrigins parameter should be in the format:
The manual remediation requires that you go to your app service CORS section so you remove the “*” and specify explicit origins that should be allowed to make cross-origin calls.
When you have any IoT solution based on Azure IoT Hub and the IP Filter grid is by default (a rule that accepts the 0.0.0.0/0 IP address range), your hub will accept connections from any IP address. That is when this recommendation will be displayed.
The manual remediation is to go to your IoT solution and edit your IP Filter. Read this article to learn how to add/edit/delete an IP filter rule and more.
Azure Security Center will show this recommendation when it discovers that IP forwarding is enabled on some of your virtual machines. This allows the VM to accept incoming network packets that should be send to another network. The Azure Security Center GitHub community page has a Logic App Playbook and a PowerShell script sample to resolve the recommendation.
The manual remediation is to go to the VM’s networking blade and under NIC click in IP Configurations to disable “IP Forwarding”.
It is imperative to constantly review your Secure Score and act in the recommendations provided specifically for your infrastructure. You can always disable the recommendations that do not apply to your environment, in fact, it is quite easy; nevertheless, we encourage you to get every team involved in this to analyze the behaviors that should be allowed for each resource.
This blog was written as a collaboration with @Yuri Diogenes
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.