Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

How to create Azure network security groups (NSGs)

Azure Network Security Groups (NSGs) are vital for controlling network traffic in virtual networks within the Azure platform. They employ a set of rules that allow or deny network traffic based on specified conditions, including source and destination IP addresses, ports, and protocols.

Azure NSG Basics

A Network Security Group in Azure is a tool for activating rules or access control lists (ACLs) that manage network traffic to your virtual machine instances in a virtual network. NSGs can be associated with subnets or individual virtual machine instances within those subnets. When an NSG is associated with a subnet, the ACL rules apply to all virtual machine instances of that subnet. Additionally, NSGs can be directly associated with a specific virtual machine for more granular traffic control.

Configuring Network Security Groups in Azure

Azure Network Security Group rules

All network security groups contain a set of default rules. You cannot delete the default rules, but since they are assigned the lowest priority, they can be replaced by the rules you create.

As shown in the following predetermined rules, traffic that originates and terminates in a virtual network is allowed in both the inbound and outbound directions. Although Internet connectivity is allowed for the exit address, it is blocked for the entry address by default. There is a default rule to allow the Azure load balancer to poll the status of virtual machines and role instances. You can override this rule if you are not going to use a load balanced set.

Association of network security groups

You can associate a network security group with virtual machines, NICs, and subnets, depending on the deployment model you use:

  • Association of a network security group to a virtual machine (only classical implementations): When you associate a network security group with a VM, the network access rules of the network security group apply to all traffic that enters and leaves the VM.
  • Association of a network security group to a NIC (only implementations of the Resource Manager): By associating a network security group with a NIC, the network access rules of the network security group apply only to that NIC. This means that in a virtual machine with several NICs, the fact that a network security group applies to a single NIC does not affect the traffic linked to other NICs.
  • Association of a network security group to a subnet (all implementations): When associating a network security group with a subnet, the network access rules of the network security group are applied to all the IaaS and PaaS resources of the subnet.

You can associate different network security groups to a virtual machine (or NIC, depending on the deployment model) and to the subnet to which a NIC or virtual machine is linked.

When this happens, all network access rules are applied to traffic, by priority in each network security group, in the following order:

Inbound traffic:

  1. Network security group applied to subnet: If a network security group on the subnet has a matching rule to deny traffic, the packet will be discarded.
  2. Network security group applied to NIC (Resource Manager) or VM (classic): If the network security group of the virtual machine or the NIC has a matching rule to deny traffic, the packet will be discarded in the virtual machine or the NIC, even if the network security group on the subnet has a match rule to allow traffic.

Outbound traffic:

  1. Network security group applied to a NIC (Resource Manager) or VM (classic): If the network security group of the virtual machine or the NIC has a matching rule to deny traffic, the packet will be discarded.
  2. Network Security Group applied to the subnet: If the network security group on the subnet has a matching rule to deny traffic, the packet will be discarded here, even if the network security group of the virtual machine or the NIC has a matching rule to allow traffic.

Virtual network and subnet design

Designing virtual networks and subnets with NSG considerations is crucial. Grouping resources by subnet and applying NSGs at the subnet level can optimize network security. However, this might require defining new subnets and virtual networks and migrating existing resources to align with NSG designs.

Special rules

You must also take into account the special rules listed below. Make sure that it does not block the traffic allowed by those rules because, otherwise, the infrastructure will not be able to communicate with essential Azure services.

  • Virtual IP of the host node: Ensure communication with the host node’s virtual IP (168.63.129.16) is not blocked.
  • Licenses (key management service): Allow license requests to the key management service on port 1688.

ICMP Traffic

Although NSGs primarily allow TCP or UDP protocols, ICMP traffic is allowed within a virtual network by default through the virtual network rules.

Subnets

  • Consider the number of levels required by the workload. Each level can be isolated by using a subnet, and a network security group is applied to each subnet.
  • If you need to implement a subnet for a VPN gateway or an ExpressRoute circuit, be sure NOT to apply a network security group to that subnet. If it does, connectivity between local environments or between virtual networks will not work.
  • If you need to implement a virtual appliance, be sure to do it on your subnet, so that your user-defined routes (UDR) can work correctly. You can implement a subnet level network security group to filter traffic in and out of this subnet.

Load balancers

When using load balancers, consider creating separate NSGs for each back-end group. This ensures that traffic directly reaching the back-end group is filtered appropriately. Also, understand that the source and destination ports and addresses for traffic filtered by NSGs are related to the originating and receiving equipment, not the load balancer itself.

Step by Step configure a security group in Virtual Machine in Azure

We enter our portal and look for our resource group

We go to the resource group panel and click on Add

Assign the name of our security group and select our resource group and click on create

We wait for the NSG to deploy and once completed, we can view it by clicking on All Services on the left-hand side and selecting Network Security Groups:

We can now see our new NSG, and we can further configure it by clicking on the name:

We need to assign a subnet to associate this NSG with, select Subnets on the left-hand side:

Now click the Associate button so we can find our subnet and the virtual network that we created in part 1. Remember, we created this when we set up the Virtual Network:

We can now see that we have the LukeLabVnet1 virtual network that we created and the LukeLabSubnet assigned to this network security group. Click Ok to configure:

Creation of Security Groups in Azure Via PowerShell

#Defining security rules for Virtual Machine entry

$ rule1 = New-AzureRmNetworkSecurityRuleConfig -Name rdp-rule -Description "Allow RDP" -Access Allow -Protocol Tcp -Direction Inbound -Priority 100 -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 3389

New-AzureRmNetworkSecurityGroup -ResourceGroupName $ ResourceGroupName -Location $ Location -Name "SECURITY" -SecurityRules $ rule1

#Creating Virtual Machine entry security rule

New-AzureRmVM -ResourceGroupName $ ResourceGroupName -Location $ Location -VM $ vm

Enjoy!

Become the cloud networking hero of your business.

See how Aviatrix can increase security and resiliency while minimizing cost, skills gap, and deployment time.