Introduction

Network security is a critical aspect of maintaining a secure and reliable infrastructure. Azure provides a powerful tool called Network Security Group (NSG) that allows organizations to filter network traffic and enforce access controls in their cloud environments. In this training module, we will explore how to utilize Azure NSG to enhance network security and protect your resources.

Scenario

Imagine your work as a cloud architect for a growing e-commerce company. The company has recently migrated its infrastructure to Microsoft Azure and wants to ensure that network traffic to their resources is secure and restricted to authorized sources. As the responsible architect, you need to implement effective network security measures using Azure NSG.

Learning Objectives

By the end of this training module, participants will:

• Understand the purpose and benefits of using Azure NSG to filter network traffic.
• Learn how to create and configure NSGs to enforce access controls for Azure resources.
• Gain insights into how NSGs can be used to allow or deny specific types of traffic based on source, destination, and port.
• Understand how to prioritize NSG rules and leverage Azure NSG flow logs for monitoring and troubleshooting.
• Recognize the role of NSGs in implementing network security best practices in Azure.

Goals

• Enable participants to effectively utilize Azure NSG to filter network traffic and enforce access controls.
• Improve participants’ understanding of network security concepts in Azure.
• Provide participants with hands-on experience in creating and configuring NSGs.
• Empower participants to implement network security best practices and restrict unauthorized access to Azure resources.
• Enhance participants’ ability to monitor and troubleshoot network traffic using NSG flow logs.

Azure resource group

A Resource Group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization. Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.

The Resource Group stores metadata about the resources. Therefore, when you specify a location for the resource group, you are specifying where that metadata is stored. For compliance reasons, you may need to ensure that your data is stored in a particular region.

Example: Azure Resource Group

Azure Virtual Network

Azure Virtual Network is the fundamental building block for your private network in Azure. A virtual network enables many types of Azure resources, such as Azure Virtual Machines (VM), to securely communicate with each other, the internet, and on-premises networks. A virtual network is similar to a traditional network that you’d operate in your own data center. An Azure Virtual Network brings with it extra benefits of Azure’s infrastructure such as scale, availability, and isolation.

Example: Azure virtual network

Why use an Azure Virtual network?

Azure virtual network enables Azure resources to securely communicate with each other, the internet, and on-premises networks.

Key scenarios that you can accomplish with a virtual network include:

• Communication of Azure resources with the internet
• Communication between Azure resources
• Communication with on-premises resources
• Filtering network traffic
• Routing network traffic
• Integration with Azure services.

Based on the principle of “never trust, always verify,” Zero Trust helps secure corporate resources by eliminating unknown and unmanaged devices and limiting lateral movement. Implementing a true Zero Trust model requires that all components—user identity, device, network, and applications—be validated and proven trustworthy. Zero Trust verifies identity and device health prior to granting access to corporate resources. When access is granted, applying the principle of least privilege limits user access to only those resources that are explicitly authorized for each user, thus reducing the risk of lateral movement within the environment. In an ideal Zero Trust environment, the following four elements are necessary:

• Strong identity authentication everywhere (user verification via authentication)
• Devices are enrolled in device management, and their health is validated
• Least-privilege user rights (access is limited to only what is needed)
• The health of services is verified (future goal)

Communicate with the internet

All resources in a virtual network can communicate outbound to the internet, by default. You can communicate inbound to a resource by assigning a public IP address or a public load balancer. You can also use public IP, Network Address Translation (NAT) gateway, or public load balancer to manage your outbound connections.

Communicate between Azure resources

Azure resources communicate securely with each other in one of the following ways:

• Through a virtual network: You can deploy VMs, and other types of Azure resources to a virtual network. Examples of resources include Azure App Service Environments, the Azure Kubernetes Service (AKS), and Azure Virtual Machine Scale Sets.
• Through a virtual network service endpoint: Extend your virtual network private address space and the identity of your virtual network to Azure service resources. Examples of resources include Azure Storage accounts and Azure Structured Query Language (SQL) Database, over a direct connection. Service endpoints allow you to secure your critical Azure service resources to only a virtual network.
• Through virtual network peering: You can connect virtual networks to each other, enabling resources in either virtual network to communicate with each other, using virtual network peering. The virtual networks you connect can be in the same, or different, Azure regions.

Communicate with on-premises resources

You can connect your on-premises computers and networks to a virtual network using any of the following options:

• Point-to-site virtual private network (VPN): Established between a virtual network and a single computer in your network. Each computer that wants to establish connectivity with a virtual network must configure its connection. This connection type is great if you’re just getting started with Azure, or for developers, because it requires little or no changes to your existing network. The communication between your computer and a virtual network is sent through an encrypted tunnel over the internet.
• Site-to-site VPN: Established between your on-premises VPN device and an Azure VPN Gateway that is deployed in a virtual network. This connection type enables any on-premises resource that you authorize to access a virtual network. The communication between your on-premises VPN device and an Azure VPN gateway is sent through an encrypted tunnel over the internet.
• Azure ExpressRoute: Established between your network and Azure, through an ExpressRoute partner. This connection is private. Traffic doesn’t go over the internet.

Filter network traffic

You can filter network traffic between subnets using either or both of the following options:

• Network security groups: Network security groups and application security groups can contain multiple inbound and outbound security rules. These rules enable you to filter traffic to and from resources by source and destination IP address, port, and protocol.
• Network virtual appliances: A network virtual appliance is a VM that performs a network function, such as a firewall, Wide-Area Network (WAN) optimization, or other network function.

Route network traffic

Azure routes traffic between subnets, connected virtual networks, on-premises networks, and the Internet, by default. You can implement either or both of the following options to override the default routes Azure creates:

• Route tables: You can create custom route tables with routes that control where traffic is routed to for each subnet.
• Border gateway protocol (BGP) routes: If you connect your virtual network to your on-premises network using an Azure VPN Gateway or ExpressRoute connection, you can propagate your on-premises Border Gateway Protocol (BGP) routes to your virtual networks.

Virtual network integration for Azure services

Integrating Azure services to an Azure virtual network enables private access to the service from virtual machines or compute resources in the virtual network. You can integrate Azure services in your virtual network with the following options:

• Deploying dedicated instances of the service into a virtual network. The services can then be privately accessed within the virtual network and from on-premises networks.
• Using Private Link to access privately a specific instance of the service from your virtual network and from on-premises networks.
• You can also access the service using public endpoints by extending a virtual network to the service, through service endpoints. Service endpoints allow service resources to be secured to the virtual network.

Azure Virtual Network limits

There are certain limits around the number of Azure resources you can deploy. Most Azure networking limits are at the maximum values. However, you can increase certain networking limits as specified on the virtual network limits page.

Virtual networks and availability zones

Virtual networks and subnets span all availability zones in a region. You don’t need to divide them by availability zones to accommodate zonal resources. For example, if you configure a zonal VM, you don’t have to take into consideration the virtual network when selecting the availability zone for the VM. The same is true for other zonal resources.

How network security groups filter network traffic

You can use an Azure network security group to filter network traffic between Azure resources in an Azure virtual network. A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources. For each rule, you can specify source and destination, port, and protocol.

Security rules

A network security group contains as many rules as desired, within Azure subscription limits. Each rule specifies the following properties:

Security rules are evaluated and applied based on the five-tuple (1. source, 2. source port, 3. destination, 4. destination port, and 5. protocol) information. You can’t create two security rules with the same priority and direction. A flow record is created for existing connections. Communication is allowed or denied based on the connection state of the flow record. The flow record allows a network security group to be stateful. If you specify an outbound security rule to any address over port 80, for example, it’s not necessary to specify an inbound security rule for the response to the outbound traffic. You only need to specify an inbound security rule if communication is initiated externally. The opposite is also true. If inbound traffic is allowed over a port, it’s not necessary to specify an outbound security rule to respond to traffic over the port.

Existing connections may not be interrupted when you remove a security rule that allowed the connection. Modifying network security group rules will only affect new connections. When a new rule is created or an existing rule is updated in a network security group, it will only apply to new connections. Existing connections are not reevaluated with the new rules.

Existing connections may not be interrupted when you remove a security rule that allowed the connection. Modifying network security group rules will only affect new connections. When a new rule is created or an existing rule is updated in a network security group, it will only apply to new connections. Existing connections are not reevaluated with the new rules.

How network security groups filter network traffic

You can deploy resources from several Azure services into an Azure virtual network. You can associate zero, or one, network security group to each virtual network subnet and network interface in a virtual machine. The same network security group can be associated to as many subnets and network interfaces as you choose. The following picture illustrates different scenarios for how network security groups might be deployed to allow network traffic to and from the internet over TCP port 80:

Inbound traffic

For inbound traffic, Azure processes the rules in a network security group associated to a subnet first, if there’s one, and then the rules in a network security group associated to the network interface, if there’s one. This process includes intra-subnet traffic as well.

• VM1: The security rules in NSG1 are processed, since it’s associated to Subnet 1 and VM1 is in Subnet 1. Unless you’ve created a rule that allows port 80 inbound, the DenyAllInbound default security rule denies the traffic. The traffic doesn’t get evaluated by NSG2 because it’s associated with the network interface. If NSG1 allows port 80 in its security rule, NSG2 processes the traffic. To allow port 80 to the virtual machine, both NSG1 and NSG2 must have a rule that allows port 80 from the internet.
• VM2: The rules in NSG1 are processed because VM2 is also in Subnet 1. Since VM2 doesn’t have a network security group associated to its network interface, it receives all traffic allowed through NSG1 or is denied all traffic denied by NSG1. Traffic is either allowed or denied to all resources in the same subnet when a network security group is associated to a subnet.
• VM3: Since there’s no network security group associated to Subnet 2, traffic is allowed into the subnet and processed by NSG2, because NSG2 is associated to the network interface attached to VM3.
• VM4: Traffic is allowed to VM4, because a network security group isn’t associated to Subnet 3, or the network interface in the virtual machine. All network traffic is allowed through a subnet and network interface if they don’t have a network security group associated to them.

Outbound traffic

For outbound traffic, Azure processes the rules in a network security group associated to a network interface first, if there’s one, and then the rules in a network security group associated to the subnet, if there’s one. This process includes intra-subnet traffic as well.

• VM1: The security rules in NSG2 are processed. The AllowInternetOutbound default security rule in both NSG1 and NSG2 allows the traffic unless you create a security rule that denies port 80 outbound to the internet. If NSG2 denies port 80 in its security rule, it denies the traffic, and NSG1 never evaluates it. To deny port 80 from the virtual machine, either, or both of the network security groups must have a rule that denies port 80 to the internet.
• VM2: All traffic is sent through the network interface to the subnet, since the network interface attached to VM2 doesn’t have a network security group associated to it. The rules in NSG1 are processed.
• VM3: If NSG2 denies port 80 in its security rule, it denies the traffic. If NSG2 doesn’t deny port 80, the AllowInternetOutbound default security rule in NSG2 allows the traffic because there’s no network security group associated with Subnet 2.
• VM4: All network traffic is allowed from VM4, because a network security group isn’t associated to the network interface attached to the virtual machine, or to Subnet 3.

Intra-Subnet traffic

It’s important to note that security rules in an NSG associated to a subnet can affect connectivity between VMs within it. By default, virtual machines in the same subnet can communicate based on a default NSG rule allowing intra-subnet traffic. If you add a rule to NSG1 that denies all inbound and outbound traffic, VM1 and VM2 won’t be able to communicate with each other.

You can easily view the aggregate rules applied to a network interface by viewing the effective security rules for a network interface. You can also use the IP flow verify capability in Azure Network Watcher to determine whether communication is allowed to or from a network interface. You can use IP flow verify to determine whether a communication is allowed or denied. Additionally, Use IP flow verify to surface the identity of the network security rule responsible for allowing or denying the traffic.