In this part we will handle the network recommendations, there are four network recommendations.
Here are the other parts:
- Azure Security Center Blog Series | Part 3
- Azure Security Center Blog Series | Part 2
- Azure Security Center Blog Series | Part 1
Contents
Add Next Generation Firewall
Azure Security Center may recommend that you add a next generation firewall (NGFW) from a Microsoft partner to increase your security protections. The following plan of action can be executed to comply to the Azure Security Center recommendation.
- Go to ASC Recommendation for NGFW.
- Select the IP Address that
NGFW Partners needs to be secured by the NGFW.
- Select one of the partner NGFWs to be deployed.
- Fill in the required information for the deployment. (I would create a new subnet for the firewall or even a new VNET for segregation).
- After the deployment is done you can open the required ports and connect through the newly deployed NGFW.
Route traffic through NGFW only
This recommendation is created only if you installed your NGFW through Security Center. If you have Internet-facing endpoints, Security Center recommends that you configure Network Security Group rules that force inbound traffic to your VM through your NGFW.
The description from the recommendation states: This Internet facing endpoint should be removed or NSG rules should be configured for this public endpoint to limit access to the Next Generation Firewall only. See screenshot.
So what it actually means is that you have to remove the related inbound rule(s) from the NSG and create a new access rule in the newly deployed NGFW and connect through that rule.
To minimize the attack surface of your Azure environment you should remove all the public IP addresses from the VMs and create a management machine (stepping stone server) with Just In Time (JIT) VM Access. See this link for an explanation how JIT works.
Enable Network Security Groups on subnets or virtual machines
Azure Security Center recommends that you enable a network security group (NSG). NSGs contain a list of Access Control List (ACL) rules that allow or deny network traffic to your VM instances in a Virtual Network. NSGs can be associated with either subnets or individual VM instances within that subnet. When an NSG is associated with a subnet, the ACL rules apply to all the VM instances in that subnet. In addition, traffic to an individual VM can be restricted further by associating an NSG directly to that VM.
If you do not have NSGs enabled, Security Center presents two recommendations to you: Enable Network Security Groups on subnets and Enable Network Security Groups on virtual machines. You choose which level, subnet or VM, to apply NSGs.
In the first example the NSGs are associated with the subnets. In the second example the NSGs are associated with NICs of the VMs. You can also associate NSGs to both. The downside is that you have to manage the ACLs in both of the NSGs.
Many of the customers ask me, what is the best practice? I don’t think there is one “holy grail” , just choose what suits best for your company.
Restrict access through Internet facing endpoints
Azure Security Center will recommend that you restrict access through Internet-facing endpoints if any of your Network Security Groups (NSGs) has one or more inbound rules that allow access from “any” source IP address. Opening access to “any” may enable attackers to access your resources. Security Center will recommend that you edit these inbound rules to restrict access to source IP addresses that actually need access.
To comply to this recommendation you should restrict the NSG rules that have source IP address “any”, or remove the whole NSG rule. Solutions like JIT VM Access are perfect to resolve this recommendation.
A NSG has the restriction to have only one source IP address in a NSG rule. So in order to restrict from a couple of IP addresses you need to create several rules. This can be very time consuming, that’s why i have created the following powershell script to help you set up NSG rules based on a array.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
### Login to Azure. Login-AzureRmAccount ### Select Subscription $Subscription = Get-AzureRmSubscription | Out-GridView -Title "Select Subscription" -OutputMode Single Select-AzureRmSubscription -SubscriptionId $Subscription.Id ### Select NSG $NSG = Get-AzureRmNetworkSecurityGroup | Select Name,ResourceGroupName|Out-GridView -Title "Select NSG" -OutputMode Single ### Array with source IP Addresses $SQLServers = @( "12.34.56.78", "90.12.34.56" ) ### Priority to begin with [int]$Priority = 1500 foreach ($SQLServer in $SQLServers){ Write-Host "Now processing NSG rule for: $SQLserver" $NSGRuleName = "SQL-ACCESS-$SQLServer" Write-Host "Name of NSG rule will be $NSGRuleName" $Description = "SQL Access for IP Address: $SQLServer" $Priority++; Write-Host "Priority will be: $Priority" ##### NSG Rule Add command. Get-AzureRmNetworkSecurityGroup -Name $NSG.Name -ResourceGroupName $NSG.ResourceGroupName | Add-AzureRmNetworkSecurityRuleConfig -Name $NSGRuleName ` -Description $Description ` -Access Allow ` -Protocol Tcp ` -Direction Inbound ` -Priority $Priority ` -SourceAddressPrefix $SQLServer ` -SourcePortRange * ` -DestinationAddressPrefix * ` -DestinationPortRange 1433 | Set-AzureRmNetworkSecurityGroup } |
Stay tuned for the final part of Azure Security Center blog series where we handle VM recommendations.