How to secure an Azure Virtual Network

The most common question that anyone asks when they buy a service is, can it be secured? The answer to that question, in this case, is absolutely yes. In this tutorial, we will learn to secure your connection between virtual machines.

On top of the security, Microsoft provides for Azure as a vendor, there are some configurations that you can do at your end to increase the level of security to your virtual network.

For a higher level of security, you can use the following:

NSG: It is like a firewall that controls the inbound and outbound traffic by specifying which traffic is allowed to flow to/from the NIC/subnet

Distributed denial of service (DDoS) protection: It is used to prevent DDoS attacks and at the time of writing is in preview

This tutorial is an excerpt from the book, Hands-On Networking with Azure, written by Mohamed Waly.

Network Security Groups (NSG)

NSG controls the flow of traffic by specifying which traffic is allowed to enter or exit the network.

Creating NSG

Creating NSG is a pretty straightforward process. To do it, you need to follow these steps:

Navigate to Azure portal, and search for network security groups, as shown in the following screenshot:

Figure 2.13: Searching for network security groups

Once you have clicked on it, a new blade will be opened wherein all the created NSGs are located, as shown in the following screenshot:

Figure 2.12: Network security groups blade

Click on Add and a new blade will pop up, where you have to specify the following:
- Name: The name of the NSG
- Subscription: The subscription, which will be charged for NSG usage
- Resource group: The resource group within which the NSG will be located as a resource
- Location: The region where this resource will be created

Figure 2.13: Creating an NSG

Once you have clicked on Create, the NSG will be created within seconds.

Inbound security rules

By default, all the subnets and NICs that are not associated with NSG have all the inbound traffic allowed and once they are associated with an NSG, the following inbound security rules are assigned to them as they are a default part of any NSG:

AllowVnetInBound: Allows all the inbound traffic that comes from a virtual network

AllowAzureLoadBalancerInBound: Allows all the inbound traffic that comes from Load Balancer

DenyAllInbound: Denies all the inbound traffic that comes from any source

Figure 2.14: Default inbound security rules

As shown in the previous screenshot, the rule consists of some properties, such as PRIORITY, NAME, PORT, and so on.

It is important to understand what these properties mean for a better understanding of security rules. So, let's go ahead and explain them:

PRIORITY: A number assigned to each rule to specify which rule has a higher priority than the other. The lower the number, the higher the priority. You can specify a priority with any number between 100 and 4096.

NAME: The name of the rule. The same name cannot be reused within the same network security group.

PORT: The allowed port through which the traffic will flow to the network.

PROTOCOL: Specify whether the protocol you are using is TCP or UDP.

SOURCE and DESTINATION: The source can be any, an IP address range, or a service tag.

You can remove the default rules by clicking on Default rules.

You can customize your own inbound rules, by following these steps:

On the Inbound security rules blade, click on Add.

A new blade will pop up, where you have to specify the following:
- Source: The source can be Any, an IP address range, or a service tag. It specifies the incoming traffic from a specific source IP address range that will be allowed or denied by this rule.
- Source port ranges: You can provide a single port, such as 80, a port range, such as 1024 - 65535, or a comma-separated list of single ports and/or port ranges, such as 80, 1024 - 65535. This specifies on which ports traffic will be allowed or denied by this rule. Provide an asterisk (*) to allow traffic on any port.
- Destination: The destination can be Any, an IP address range, or a virtual network. It specifies the outing traffic to a specific destination IP address range that will be allowed or denied by this rule.
- Destination port ranges: What applies for the source port ranges, applies for the destination port ranges.
- Protocol: It can be Any, TCP, or UDP.
- Action: Whether to Allow the rule or to Deny it.
- Priority: As mentioned earlier, the lower the number, the higher the priority. The priority number must be between 100 - 4096.
- Name: The name of the rule.
- Description: The description of the rule, which will help you to differentiate between the rules.

In our scenario, I want to allow all the incoming connections to access a website published on a web server located in a virtual network, as shown in the following screenshot:

Figure 2.15: Creating an inbound security rule

Once you click on OK, the rule will be created.

Outbound security rules

Outbound security rules are no different than inbound security rules, except inbound rules are meant for inbound traffic and outbound rules are meant for outbound traffic. Otherwise, everything else is similar.

Associating the NSG

Once you have the NSG created, you can associate it to either an NIC or a subnet.

Associating the NSG to an NIC

To associate the NSG to an NIC, you need to follow these steps:

Navigate to the Network security groups that you have created and then select Network interfaces, as shown in the following screenshot:

Figure 2.16: Associated NICs to an NSG

Click on Associate.

A new blade will pop up, from which you need to select the NIC that you want to associate with the NSG, as shown in the following screenshot:

Figure 2.17: NICs to be associated to the NSG

Voila! You are done.

Associating the NSG to a subnet

To associate the NSG to a subnet, you need to follow these steps:

Navigate to the Network security groups that you have created and then select Subnets, as shown in the following screenshot:

Figure 2.18: Associated subnets to an NSG

Click on Associate.

A new blade will pop up, where you have to specify the virtual network within which the subnet exists, as shown in the following screenshot:

Figure 2.19: Choosing the VNet within which the subnet exists

Then, you need to specify which subnet of the VNet you want to associate the NSG to, as shown in the following screenshot:

Figure 2.20: Selecting the subnet to which the NSG will be associated

Once the subnet is selected, click on OK, and it will take some seconds to get it associated to the NSG.

Azure DDoS protection

DDoS attacks have spread out lately, by exhausting the application and making it unavailable for use, and you can expect an attack of that type any time. Recently, Microsoft announced the support of Azure DDoS protection as a service for protecting Azure resources, such as Azure VMs, Load Balancers, and Application Gateways.

Azure DDoS protection comes in two flavors:

Basic: This type has been around for a while as it is already enabled for Azure services to mitigate DDoS attacks. It incurs no charges.

Standard: This flavor comes with more enhancements that mitigate attacks, especially for Azure VNet.

At the time of writing this book, Azure DDoS protection standard is in preview and it is not available at the portal. You need to request it by filling out a form that is available here.

If you found this post useful, do check out the book Hands on Networking with Azure, to design and implement Azure Networking for Azure VMs.

The Microsoft Azure Stack Architecture

What is Azure API Management?