Deployments and YAML, Exams of Microsoft AZ-304, Microsoft AZ-304 Certifications, Network Security Groups, Public IP addresses

Network Security Groups – Network Connectivity and Security

by Katie Campbell

NSGs allow you to define inbound and outbound rules that will allow or deny the flow of traffic from a source to a destination on a specific port. Although you define separate inbound and outbound rules, each rule is stateful. This means that the flow in any one direction is recorded so that the returning traffic can also be allowed using the same rule.

In other words, if you allow HTTPS traffic into a service, then that same traffic will be allowed back out for the same source and destination.

We create NSGs as components in Azure and then attach them to a subnet or network interface on a VM. Each subnet can only be connected to a single NSG, but any NSG can be attached to multiple subnets. This allows us to define rulesets independently for everyday use cases (such as allowing web traffic) and then reusing them across various subnets.

When NSGs are created, Azure applies several default rules that effectively block all access except essential Azure services.

If you create a VM in Azure, a default NSG is created for you and attached to the network interface of the VM; we can see such an example in the following screenshot:

Figure 8.5 – Example NSG ruleset

In the preceding figure, we can see five inbound rules and three outbound. The top two inbound rules highlighted in red were created with the VM – in the example, we specified to allow RDP (3389) and HTTP (80).

The three rules in the inbound and outbound highlighted in green are created by Azure and cannot be removed or altered. These define a baseline set of rules that must be applied for the platform to function correctly while blocking everything else. As the name suggests on these rules, AllowVnetInBound allows traffic to flow freely between all devices in that VNET, and the AllowAzureLoadBalancerInBound rule allows any traffic originating from an Azure load balancer. DenyAllInBound blocks everything else.

Each rule requires a set of options to be provided:

  • Name and Description: For reference; these have no bearing on the actual service. They make it easier to determine what it is or what it is for.
  • Source and Destination port: The port is, of course, the network port that a particular service communicates on – for RDP, this is 3389; for HTTP, it is 80, and for HTTPS, it is 443. Some services require port mapping; that is, the source may expect to communicate on one port, but the actual service communicates on a different port.
  • Source and Destination location: The source and destination locations define where traffic is coming from (the source) and where it is trying to go to (the destination). The most common option is an IP address or list of IP addresses, and these will typically be used to define external services.

For Azure services, we can either choose the VNET – that is, the destination is any service on the VNET the NSG is attached to – or a service tag, which is a range of IPs managed by Azure. Examples may include the following:

– Internet: Any address that doesn’t originate from the Azure platform

– AzureLoadBalancer: An Azure load balancer

– AzureActiveDirectory: Communications from the Azure Active Directory service

– AzureCloud.EastUS: Any Azure service in the East US region

As we can see from these examples, with the exception of the internet option, they are IP sets that belong to Azure services. Using service tags to allow traffic from Azure services is safer than manually entering the IP ranges (which Microsoft publishes) as you don’t need to worry about them changing.

  • Protocol: Any, TCP, UDP, or ICMP. Services use different protocols, and some services require TCP and UDP. You should always define the least access; so, if only TCP is needed, only choose TCP. ICMP protocol is used primarily for Ping.
  • Priority: Firewall rules are applied one at a time in order, with the lowest number, which is 100, being used last. Azure applies a Deny All rule to all NSGs with the lowest priority. Therefore, any rule with a higher priority will overrule this one. Deny all is a failsafe rule – this means everything will be blocked by default unless you specifically create a rule to allow access.

Through the use of NSGs, we can create simple rules around our VNET-integrated services and form part of an effective defense strategy. There may be occasions, however, when you want to apply different firewall rules to other components within the same subnet; we can use Application Security Groups (ASGs) for these scenarios.