What is the process for creating Network Security Groups in Azure?
If you want to activate a rule or an access control list (ACL) in Azure, you can do so by creating a network security group (NSG). The rule or ACL will determine whether network traffic is allowed or denied to your virtual machine instances within the virtual network. NSGs can be associated with subnets or with specific virtual machine instances inside a subnet, depending on the configuration. When an NSG is associated with a subnet, the ACL rules associated with that subnet are applied to all Virtual Machine instances associated with that subnet. As a further measure, you can direct traffic to a certain virtual machine by explicitly connecting an NSG with that virtual machine.
The following are some things to consider when setting Network Security Groups.
All network security groups are pre-configured with a set of basic security rules. The default rules cannot be deleted, but because they are given the lowest priority, they can be replaced by the rules that you make.
Traffic that originates and terminates in a virtual network is permitted in both the inbound and outgoing directions, as demonstrated in the following preset regulations. Even though Internet connectivity is permitted for the exit address, it is prohibited for the entering address as a matter of default. The Azure load balancer can poll the status of virtual machines and role instances by default, and this rule is enabled by default. If you are not planning to employ a load-balanced set, you can choose to ignore this rule.
a federation of network security organisations
Depending on the deployment architecture that you employ, you can associate a network security group with virtual machines, network interface cards, and subnets.
Associated network security groups with virtual machines (only classical implementations): When you associate network security groups with virtual machines (VMs), the network access rules associated with those networks are applied to all traffic that enters and leaves the virtual machine (both inbound and outbound).
NIC association with a network security group (available only in Resource Manager implementations): When a network security group is associated with a NIC, only the network access rules of the network security group are applied to that NIC. Because of this, traffic connecting to other NICs in a virtual machine with several networks is not affected by the fact that one network security group is applied to a single network interface card.
In all implementations, when a network security group is associated with a subnet, the network access rules of the network security group are applied to all IaaS and PaaS resources in the subnet, regardless of whether or not the network security group is explicitly configured to do so.
A virtual machine (or network interface card, depending on the deployment architecture) can be associated with many network security groups, each of which can be associated with a separate subnet to which the virtual machine or network interface card is tied. When this occurs, all network access rules in each network security group are applied to traffic in the following order, based on their priority in each network security group:
Inbound traffic: network security group applied to subnet: If a network security group on the subnet has a matching rule to reject traffic, the packet will be discarded. If the network security group on the subnet does not have a matching rule to deny traffic, the packet will be discarded.
NIC (Resource Manager) or VM (classic) network security groups: If the network security group of the virtual machine or the NIC contains a matching rule to deny traffic, a packet will be discarded in the virtual machine or the NIC, even if the network security group on the subnet contains a matching rule to allow traffic.
A network security group applied to a network interface card (Resource Manager) or virtual machine (classic) will discard any outbound traffic if a matching rule to deny traffic exists in the network security group of the virtual machine or network interface card.
The network security group on the subnet may have a matching rule to reject traffic, which means that a packet will be deleted in this case even if the network security group on the virtual machine or the NIC has a matching rule to allow traffic.
Designing a virtual network and subnetwork
You can reduce the number of network security groups by grouping resources by subnet and applying these groups to subnets. This is because network security groups can be applied to subnets. The use of network security groups on subnets may result in the discovery that existing virtual networks and subnets have been formed without considering them if you opt to use network security groups on subnets.
As a result, you may need to create additional subnets and virtual networks to accommodate the architecture of network security groups. In addition, you must create new resources in the new subnets to support them. After that, you may devise a migration strategy for moving the existing resources to the new subnets, if necessary.
Rules that apply just to you
As well as the general regulations, you must consider the particular rules stated below. Make certain that it does not interfere with the traffic permitted by those rules since otherwise, the infrastructure will be unable to communicate with critical Azure services.
Node with virtual IP address: The virtualized host’s IP address 168.63.129.16 is used to provide basic infrastructure services such as dynamic hosting, domain name system (DNS), and system status tracking. Even though this public IP address belongs to Microsoft, it will be the sole virtualized IP address that will be utilised for this purpose across all regions. In this case, the IP address assigned to the virtual machine corresponds to the physical IP address of the server machine (host node) that hosts the virtual machine. It serves as a DHCP relay, DNS recursive resolution, probe source, load balancer maintenance probe, and equipment maintenance probe in addition to other functions. This IP address should not be regarded as a source of intrusion or assault.
In this case, licences (key management services) are required. Windows images that run on virtual machines must be licenced before they may be used. It is necessary to send a licencing request to the key management service host servers that administer those queries to accomplish this. In all cases, this will be completed at the 1688 exit port.
ICMP (Internet Control Message Protocol) Traffic
The protocols TCP and UDP are the only ones that are permitted under the norms of the present network security groups. There is no special ICMP tag for this protocol. ICMP traffic, on the other hand, is permitted by default within a virtual network, thanks to the virtual network rules of entry (the default 65000 input rule), which permit traffic to and from any port and protocol within a virtual network.
Subnets
Calculate the number of levels that will be required by the workload. Using a subnet, each level may be segregated from the others, and a network security group can be applied to each subnet.
If you need to create a subnet for a VPN gateway or an ExpressRoute circuit, be sure that you do not apply a network security group to that subnet first. If this occurs, communication between local environments or between virtual networks will be disrupted, and the network will not function properly.
Remember to build virtual appliances on your subnet if you need to ensure that user-defined routes (UDR) continue to function properly. You can create a network security group at the subnet level to filter traffic coming into and out of this subnet, if necessary.
Load balancers are devices that distribute the load.
Consider the network address translation (NAT) and load balancing rules for each load balancer that is used by each of the workloads in turn. These rules are tied to a back-end group that contains NICs (Resource Manager implementations) or virtual machines and role instances, depending on the configuration (classic implementations). For each back-end group, you could want to consider creating a network security group, which would ensure that only assigned traffic is allowed through the rules specified in the load balancers. It is ensured that the traffic that arrives directly at the back-end group, without passing through load balancing, is also filtered in this manner, as well.
Creating connection points that allocate ports of a load balancer to ports of virtual machines or role instances is a common practice in traditional deployments. In an implementation of the Resource Manager, you can also establish your load balancer with individual public access for your use. Note that the destination port for incoming traffic to virtual machines and role instances that are members of a back-end group of a load balancer is the real port of the virtual machine or role instance, not the port that exposes the load balancer if you are using network security groups to restrict traffic to the virtual machines and role instances that are members of a back-end group of a load balancer. Also, keep in mind that the address and source port for the connection to the virtual machine are the same as the address and source port for the connection to the distant computer on the Internet.
When creating network security groups to filter traffic from an internal load balancer (ILB), you must remember that the source port and the applied address range are those of the equipment that originated the call, not those of the load balancer. This is similar to creating network security groups to filter traffic from publicly accessible load balancers. Furthermore, the port number and the range of destination addresses are tied to the equipment that receives the data, rather than the load balancer, as previously stated.
Configure a security group on a Virtual Machine in Azure step by step, with screenshots.
In our portal, we look for the resource group that we belong to
We navigate to the resource group panel and select the Add button.
Create our security group by giving it a name and selecting our resource group from the drop-down menu.
- It takes a few minutes for the NSG to be deployed, and once it is, we can inspect it by selecting All Services on the left-hand side of the screen and then Network Security Groups:
- By clicking on the name, we may further set our new NSG, which we can see in the image below.
- If we want to associate this NSG with a certain subnet, we may do so by selecting Subnets from the left-hand menu:
- As a final step, click the Associate button to allow us to locate our subnet and virtual network that we constructed in part 1. Please keep in mind that we created this when we set up our Virtual Network:
- We can now see that the LukeLabVnet1 virtual network that we constructed has been assigned to this network security group, as well as the LukeLabSubnet that we created. To configure the following, click OK:
