Each NSG has the following properties regardless of where it is associated:
When a NSG is associated to a subnet, the rules apply to all resources connected to the subnet. Traffic can be further restricted by also associating a NSG to a VM or NIC. NSGs that are associated to subnets are said to be filtering “North/South” traffic (in other words, packets flowing in and out of a subnet). NSGs that are associated to Network Interfaces are said to be filtering “East/West” traffic (in other words, how the VMs within the subnet connect to each other).
Make sure to use both Subnet and NIC NSGs. This will ensure that your North/South traffic (into and out of your VNET) and your East/West traffic (between VMs on the same subnet) are secured.
NSG Rules are the mechanism defining traffic the administrator is looking to control. All NSGs have a set of default rules. These default rules cannot be deleted, but since they have the lowest possible priority, they can be overridden by the rules that you create. The lower the number, the sooner it will take precedence. The default rules allow and disallow traffic as follows:
NSG Rules are enforced based on their Priority. Priority values start from 100 and go to 4096. Rules will be read and enforced starting with 100 then 101, 102 etc., until all rules have been evaluated in this order. Rules with the priority “closest” to 100 will be enforced. For example, if you had an inbound rule that allowed TCP traffic on Port 80 with a priority of 250 and another that denied TCP traffic on Port 80 with a priority of 125, the NSG rule of deny would be put in place. This is because the “deny rule”, with a priority of 125 is closer to 100 than the “allow rule”, containing a priority of 250.
NSGs are used to define the rules of how traffic is filtered for your IaaS deployments in Azure. NSGs by themselves are not implemented until they are “associated”, with a resource in Azure. NSGs can be associated to ARM network interfaces (NIC), which are associated to the VMs, or subnets.
For NICs associated to VMs, the rules are applied to all traffic to/from that Network Interface where it is associated. It is possible to have a multi-NIC VM, and you can associate the same or different NSG to each Network Interface. When NSGs are applied to subnets, rules are applied to traffic to/from all resources connect to that subnet.
Understanding the effective rules of NSGs is critical. Security rules are applied to the traffic by priority in each NSG in the following order:
To Create a NSG and configure the rules using PowerShell, you will need to use the New-AzureRmNetworkSecurityRuleConfig and New-AzureRmNetworkSecurityGroup PowerShell cmdlets together. In this example, it’s assumed that you have run the Login-AzureRmAccount command.
$rule1 = New-AzureRmNetworkSecurityRuleConfig -Name PORT_HTTP_80 `
-Description "Allow HTTP" `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 100 `
-SourceAddressPrefix * `
-SourcePortRange * `
-DestinationAddressPrefix 10.0.0.0/24 `
-DestinationPortRange 80
$nsg = New-AzureRmNetworkSecurityGroup -ResourceGroupName BuildAzureRG `
-Location centralus `
-Name "BuildAzureNSG" `
-SecurityRules $rule1Once the NSG has been created along with the inbound rule, you will next need to associate this with the subnet to control the flow of network traffic using this filter. To achieve this goal, you will need to use the Get-AzureRmVirtualNetwork and the Set-AzureRmVirtualNetworksubnetConfig. Once the Configuration on the subnet has been set, you will then use the Set-AzureRmVirtualNetwork to save the configuration.
$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName BuildAzureRG -Name BuildAzureVNET
Set-AzureRmVirtualNetworksubnetConfig -VirtualNetwork $vnet `
-Name Apps `
-AddressPrefix 10.0.0.0/24 `
-NetworkSecurityGroup $nsg
Set-AzureRmVirtualNetwork -VirtualNetwork $vnet