Securing Your Virtual Networks with Azure Virtual Network Manager

Published Wednesday, May 11, 2022

Azure Virtual Network Manager

AVNM is a one-stop-shop for managing the connectivity and security of virtual networks, or VNets, at scale. In this guide, we’re going to focus on the security features that AVNM offers.

AVNM works through three main components – group, configure, and deploy. You can group your VNets as you’d like, whether that’s by environment, function, team, or some other logical designation. Then you can create connectivity or security configurations to apply on those network groups. You can build and maintain topologies among the VNets in your network group with connectivity configurations, and enforce high-priority security rules among your VNets with security configurations. If you’re curious about more details on creating a network manager and connectivity configurations, check out this blog by Eric Long: Simple and Central Azure Virtual Network Management Using the New Azure Virtual Network Manager. We’ll also walk through an end-to-end example of setting up a security admin configuration in a bit.

Security Admin Rules

AVNM currently enables you to protect your VNets at scale with security admin configurations. A security admin configuration consists of a rule collection, which contains individual security admin rules. These rules are not NSG rules, though they have the same kind of parameters (source and destination ports, action, priority, etc.). The power of security admin rules lies in that they are evaluated before NSG rules and can be enforced at a higher level than NSG rules.

But before we get into the weeds of how security admin rules work and how we can create them, let’s back up – why do we need security admin rules in the first place? The answer is two-fold: enforcement and management at scale.

Enforcement

With NSGs alone, widespread enforcement on VNets across several applications, teams, or even entire organizations can be tricky. Often there’s a balancing act between attempts at centralized enforcement across an organization and handing over granular, flexible control to teams. Let’s look at a few common models of security management without security admin rules, and their pros and cons:

Model 1: NSGs are managed by a central governance team.

Pros – The central governance team can enforce important security rules.

Cons – Operational overhead is high as admins need to manage each NSG, as the number of NSGs increases, the burden increases.

Model 2: NSGs are managed by individual teams.

Pros – The individual team has flexible control in tailoring security rules based on their service requirements.

Cons – The central governance team cannot enforce critical security rules, such as blocking risky ports. Individual team might also misconfigure or forget to attach NSGs, leading vulnerability exposures.

Model 3: NSGs are managed by individual teams, but NSGs are created using Azure Policy to have standard rules. Modifying these rules would trigger audit notifications.

Pros – The individual team has flexible control in tailoring security rules. The central governance team can create standard security rules and receive notifications if these are modified.

Cons – The central governance team still cannot enforce the standard security rules, since NSG owners in teams can still modify them. Notifications would also be overwhelming to manage.

Security admin rules aim to eliminate this sliding scale between enforcement and flexibility altogether by consolidating the pros of each of these models while reducing the cons of each. Central governance teams establish guard rails through security admin rules, while still leaving room for individual teams to flexibly pinpoint security as needed through NSG rules. Security admin rules are not meant to override NSG rules, but rather interact in different ways depending on the type of action specified in the security admin rule. We’ll explore these interactions after we discuss the immense scaling benefits of security admin rules.

Management at Scale

When you apply a security admin configuration to a network group – a collection of VNets that were selected either manually or conditionally – then all of the resources in the selected network groups’ VNets have those security admin rules applied to them, regardless a network group contains dozens or hundreds of VNets matters not, since a security admin configuration would apply its rules to all the VNets in the selected network groups.

This protection encapsulates not only existing resources, but extends even to new resources. If you add new VMs to a VNet that belongs to a network group that has a security admin configuration applied on it, then those VMs will automatically be secured as well. In effect, security admin rules protect your resources from day zero. As soon as your resources are provisioned, they'll fall under the protection of security admin rules.

Then, if new security risks are identified, new security admin rules can still protect your resources at scale. You can create security admin rules to protect against the new risk, then apply them to network groups – essentially, hundreds of VNets at once.

Security Admin Rules vs. NSGs

Security admin rules are similar to NSG rules in structure and the parameters they intake, but as we’ve explored so far, they’re not the exact same construct. The first difference is intended audience – admin rules are intended to be used by network admins of a central governance team, thereby delegating NSG rules to individual application or service teams to further specify security as needed. With these intentions, admin rules were designed to have a higher priority than NSGs and therefore be evaluated before NSG rules. Admin rules also include an additional action type of “Always Allow”, which allows the specified traffic through to its intended destination and terminates further (and possibly conflicting) evaluation by NSGs rules. Admin rules are also applied not only to a network group’s existing VNets but also to newly provisioned resources, as described in the previous section. Admin rules are currently applied at the VNet level, whereas NSGs can be associated at the subnet and NIC level.

Let’s boil down these differences and similarities:

	Target Audience	Applied On	Evaluation Order	Action Types	Parameters
Security Admin Rules	Network admins, central governance team	Virtual networks	Higher priority	Allow, Deny, Always Allow	Priority, protocol, action, source, destination
NSG Rules	Individual teams	Subnets, NICs	Lower priority, after security admin rules	Allow, Deny	Priority, protocol, action, source, destination

The Order of Evaluation

Let’s drive this point home one more time – security admin rules are not NSG rules. Security admin rules are evaluated before NSG rules and depending on the type of security admin rule you create, it can interact differently with NSG rules so that organizations can set enforced security policies alongside teams' NSGs that address their own use cases. The diagram below illustrates the order of evaluation of traffic.

There are three kinds of actions – Allow, Always Allow, and Deny. If you create a security admin rule to “Allow” a certain type of traffic, then this rule will be evaluated first. When the traffic is allowed by a security admin rule, it will be further evaluated by NSG rules. This means it leaves room for NSG rules down the line to handle this type of traffic differently as needed. If you create a security admin rule to “Always Allow” or “Deny” a certain type of traffic, then this rule will be evaluated first, and it will terminate the NSG evaluation of this traffic – meaning the evaluation is stopped. If the security admin rule is “Always Allow,” then the traffic won't hit NSGs, and instead deliver directly to VMs or other resource. This can be useful when administrators want to enforce some traffic to be not denied by NSG rules. For example, administrators may want to force the organization to consume software updates from certain ports. In the case of “Deny,” evaluation and therefore traffic is stopped without being delivered to the destination. This means that you can use security admin rules to set definitive security rules that cannot be overridden by others.

Note that security admin rules do not depend on NSGs in order to exist. This means that administrators can use security admin rules to create default security rules. Even if application owners misconfigured or forgot to establish NSGs, your organization is protected by default!

Enforcement and Flexibility in Practice

Let’s apply the concepts we’ve discussed so far to an example scenario. A company network administrator wants to enforce a security rule to block inbound SSH traffic for the whole company. As mentioned above, having such enforcement was difficult without AVNM’s security admin rule. If the administrator manages all the NSGs, then management overhead is high, and the administrator cannot rapidly respond to product teams’ needs to modify NSG rules. On the other hand, if the product teams manage their own NSGs without security admin rules, then the administrator cannot enforce critical security rules, leaving potential security risks open. Using both security admin rules and NSGs can solve this dilemma. In this case, the administrator wants to make an exception for Application 1 as the Application 1 team needs more time to make changes to not rely on SSH. The diagram below visualizes how the administrator can achieve the goal of enforcement with security admin rules, while leaving an exception open for the Application 1 team to handle SSH traffic through NSGs.

Step 1: Create a network manager instance

The company administrator can create a network manager with the root management group of the firm as the scope of this network manager instance.

Step 2: Create network groups for VNets

The administrator creates two network groups – “ALL Network Group,” consisting of all the VNets in the organization, and “App 1 Network Group,” consisting of VNets for Application 1. ALL Network Group in the above diagram consists of VNet 1 to VNet 5, and App 1 Network Group has VNet 4 and VNet 5. Users can easily define both network groups using dynamic membership.

Step 3: Create a security admin configuration

This security admin configuration contains a security admin rule to block inbound SSH traffic for ALL Network Group and another security admin rule to allow inbound SSH traffic for App 1 Network Group with a higher priority.

Step 4: Deploy the security admin configuration

After the deployment of the security admin configuration, all VNets in the company will have the deny inbound SSH traffic rule enforced by the security admin rule. No individual team can modify this rule, only the administrator. The App 1 VNets will have both an allow inbound SSH traffic rule and a deny inbound SSH traffic rule. The priority number of the allow inbound SSH traffic rule for App 1 Network Group should be smaller so that it is evaluated first. When inbound SSH traffic comes to an App 1 VNet, it will be allowed by this higher priority security admin rule. Assuming there are NSGs on the subnets of the App 1 VNets, this inbound SSH traffic will be further evaluated by NSGs set by the Application 1 team. Using this methodology, the company administrator can effectively enforce company policies and create security guard rails, while product teams can simultaneously react to meet their needs by owning the control of NSGs.

High-Risk Ports that Should be Blocked for Security

Based on the industry study and suggestions from Microsoft, below is what we recommend customers restrict the traffic from outside using security admin rules. These ports are often used for the management of resources or unsecure/unencrypted data transmission and should not be exposed to the internet.

Port	Protocol	Description
20	TCP	Unencrypted FTP Traffic
21	TCP	Unencrypted FTP Traffic
22	TCP	SSH. Potential brute force attacks
23	TCP	TFTP allows unauthenticated and/or unencrypted traffic
69	UDP	TFTP allows unauthenticated and/or unencrypted traffic
111	TCP/UDP	RPC. Unencrypted authentication allowed
119	TCP	NNTP for unencrypted authentication
135	TCP/UDP	End Point Mapper, multiple remote management services
161	TCP	SNMP for unsecure / no authentication
162	TCP/UDP	SNMP Trap - unsecure / no authentication
445	TCP	SMB - well known attack vector
512	TCP	Rexec on Linux - remote commands without encryption authentication
514	TCP	Remote Shell - remote commands without authentication or encryption
593	TCP/UDP	HTTP RPC EPMAP - unencrypted remote procedure call
873	TCP	Rsync - unencrypted file transfer
2049	TCP/UDP	Network File System
3389	TCP	RDP - Common brute force attack port
5800	TCP	VNC Remote Frame Buffer over HTTP
5900	TCP	VNC Remote Frame Buffer over HTTP
11211	UDP	Memcached

You might want to create exceptions to blockage of these high-risk ports for certain VNets. Please refer to the Enforcement and Flexibility in Practice section above to see how to create exceptions with security admin rules.

End-to-End Walkthrough

Now, let’s walk through creating security admin rules to block some of those high-risk ports all the way from the beginning – creating a network manager – to the end – deploying the security admin configuration – in just a few clicks in the Azure Portal.

Create a Virtual Network Manager

We can start from creating a network manager instance and its child resources. Let’s start on the Azure Portal home page.

Select + Create a resource and search for Network Managers. Then select Create to begin setting up our network manager.
On the Basics tab, we’ll enter or select the following information:

To call out a few details – Scope defines the boundary of network resources that this network manager instance will manage, and Features defines whether the network manager can create connectivity and/or security admin configurations. Selecting the Connectivity feature would allow us to create network topologies at scale, but since we’re focusing on creating high-priority security rules, we’ll just select the Security admin feature. You can also select both connectivity and security features at the same time.
Select Review + create and then select Create once validation has passed.

Create a Network Group

With our network manager created, we can now create a network group to encapsulate the VNets we want to protect.

Go to the network manager instance we created.
Select Network groups under Settings, then select + Create.
On the Create a network group page, let’s enter a Name for the network group. We’ll keep it simple and name this OurNetworkGroup.
Select Add to create this network group.
Now that we’re back on the Network groups page, select OurNetworkGroup that we just created – it’s time to add some VNets to this network group.
Instead of adding the VNets one by one, we’ll add them all at once. In the Get started tab, find the Define dynamic membership header and select Define.

We can also get to the Define dynamic membership page by navigating through the Member virtual network page under Settings.
On the Define dynamic membership page, enter or select the following values in the Parameter, Operator, and Condition fields.

What we’re doing is defining a condition for membership to OurNetworkGroup. This condition we’ve set up will check whether a VNet in OurNetworkManager’s scope has a name that contains “Prod”. If a VNet satisfies this condition, it will be automatically added to OurNetworkGroup. We could add more conditions and/or use different parameters, operators, and condition values to specify what VNets we want to add to OurNetworkGroup; but this condition statement will work for us in this walkthrough.
Select Preview resources to see what VNets in OurNetworkGroup’s scope satisfies the condition we just created.
It looks like we have 10 VNets caught by this dynamic membership condition. Close out of this preview window and select Save.
In the Member virtual network page, we can see the VNets that our dynamic membership condition added to OurNetworkGroup.

Create a Security Admin Configuration

It’s time to construct our security admin rules within a configuration so that we can apply those rules to all the VNets within OurNetworkGroup at once.

Go to the OurNetworkManager page.
Select Configurations under Settings, then select + Create and select Security admin configuration.
On the Add a security configuration page, enter a Name on the Basics tab.
Select the Rule collections tab and select + Add. This is where we’ll create a rule collection consisting of five security admin rules to apply to the Prod VNets in OurNetworkGroup.
In the Add a rule collection page, enter a Name and select OurNetworkGroup from the Target network groups dropdown list.
Under the Security admin rules header, select + Add. We’ll create five separate security admin rules to block five of the high-risk ports listed previously. Specifically, we’re going to block ports 20, 21, 22, 23, and 111.

This rule is for denying all inbound traffic on port 22, which is used for SSH connections over a TCP protocol. Note that you can also specify source and destination types, IP addresses, and ports in security admin rules.
Select Add to add this Block22SSH security admin rule to the BlockRiskyPorts rule collection.
Follow the same procedure to add four more security admin rules to deny inbound traffic for ports 20, 21, 23, and 111 to the BlockRiskyPorts rule collection. Note that each rule must have a different priority from one another so that there’s no risk of conflict – otherwise the rule won’t get added.
Once you’ve added all five security admin rules, select Add or Save to add the rules you’ve created to this rule collection.
Select Review + create and then select Create once validation has passed.
Back on the Configurations page, select Refresh. We should now see OurSecurityConfig, which we just created.

Deploy the Security Admin Configuration

We’re at the final step, which is to deploy OurSecurityConfig. This is how the security admin configuration will actually take effect on the VNets in OurNetworkGroup, and we can control the regions to which this deployment rolls out.

Select Deployments under Settings, then select Deploy configurations.
In the Goal state tab, check the box for Include security admin in your goal state and select OurSecurityConfig that we created. Then choose the region(s) we would like to deploy this configuration to – in this case, we’ll select West US 2 – and select Next to review and deploy the configuration.

Note that we did not check Include connectivity configurations in your goal state. This is because we simply don’t have any connectivity configurations to deploy at this time, but keep in mind that you have the ability to include both security admin and connectivity configurations in a single deployment.
Review the Goal state box under the West US 2 header, then select Deploy.
Back on the Deployments page, if we don’t see OurSecurityConfig, select Refresh. The deployed configuration, its status, and its name should all be visible and grouped by region.

And there we have it! In a few minutes, we were able to set up a network manager, create a network group that automatically adds VNets that satisfy the network group’s dynamic membership condition, create a security admin configuration consisting of rules that block five high-risk ports, and deploy this configuration to the VNets in the network group in our desired regions.

Note, when you have VNets that meet the condition of the dynamic membership, which is the VNets containing "Prod" in their name, these VNets will automatically receive the security admin rules to protect them from exposing high-risk ports to the internet by default. This is because you deployed the configuration that applies the security admin rules on the network group using the criteria of all the VNets whose names contain "Prod."

Exception Walkthrough

Being able to enforce security rules throughout an organization is useful, to say the least. But one of the benefits of security admin rules that we discussed was its allowance for flexibility by teams within the organization to handle traffic differently as needed. We looked at an exception scenario in the Enforcement and Flexibility in Practice section, but let’s build on our previous walkthrough to achieve this step by step in the Azure Portal.

Create a Network Group

We need to create a network group specifically for the Application 1 team’s VNets so that we can create security admin rules that pertain only to Application 1’s VNets and allow them to handle SSH traffic through their own NSGs. Since we already have OurNetworkManager created, we can go ahead and create another network group.

Go to OurNetworkManager.
Select Network groups under Settings, then select + Create.
On the Create a network group page, let’s enter a Name for Application 1’s network group. We’ll call it App1NetworkGroup.
Select Add to create this network group.
Now that we’re back on the Network groups page, select App1NetworkGroup that we just created – it’s time to add Application 1’s VNets to this network group.
Unlike OurNetworkGroup, we’ll add Application 1’s VNets one by one since they only have two VNets (ProdVnet1 and ProdVnet2). In the Get started tab, find the Static membership header and select Add.

We can also get to the Add static members page by navigating through the Member virtual network page under Settings.
On the Add static members page, click the dropdown list labeled No Grouping in the search bar and select Grouping by Resource Group. The grouping options and search bar are useful when trying to find specific VNets among the list of all VNets within your network manager’s scope.
Minimize all resource groups listed except for SecurityBlog. Select ProdVnet1 and ProdVnet2, then select Add.
In the Member virtual network page, we can see the two VNets that we manually added to App1NetworkGroup.

Great, our Application 1 team’s network group is set up!

Create a Security Admin Rule Collection for Application 1

We can now create an exception for Application 1’s VNets by adding a new rule collection and security admin rule to our existing security admin configuration.

Go to the OurNetworkManager page.
Select Configurations under Settings, then select OurSecurityConfig.
Select Rule collections under Settings, then select + Create to create a new rule collection.

Because rule collections are assigned to target network groups, we’re creating a new rule collection to apply specifically to the App1NetworkGroup we just created.
In the Add a rule collection page, enter a Name and select App1NetworkGroup from the Target network groups dropdown list.
Under the Security admin rules header, select + Add. We’ll create one security admin rule to allow inbound SSH traffic, which will come through port 22.

Recall that when we originally created rules to block five high-risk ports and applied them to all of our VNets in OurNetworkGroup, we gave those rules a priority from 10 to 14. By creating this SSH allow rule with a higher priority of 5 and applying it to only Application 1’s VNets in App1NetworkGroup, traffic destined for port 22 in Application 1’s VNets will be directly allowed by this higher priority admin rule and will never hit the lower priority deny rule applied to all VNets. After this point, because this rule is Allow and not Always Allow, the Application 1 team will be able to handle this SSH traffic as desired through their own NSGs.
Select Add to add this Allow22SSH security admin rule to the AllowSSHApp1 rule collection.
Select Add to add the AllowSSHApp1 rule collection to OurSecurityConfig.

Deploy the Security Admin Configuration

We’re at the final step, which is to redeploy OurSecurityConfig since we’ve modified this configuration by adding a rule collection.

Go to OurSecurityConfig’s Overview page and select Deploy. Note that you can also deploy configurations from OurNetworkManager’s Deployments page.
In the Goal state tab, check the box for Include security admin in your goal state and select OurSecurityConfig that we modified. Then choose the region(s) we would like to deploy this configuration to – in this case, we’ll select West US 2 – and select Next to review and deploy the configuration.
Review the Existing configurations and Goal state box under the West US 2 header, then select Deploy.
Back on the Deployments page in OurNetworkManager, if we don’t see OurSecurityConfig, select Refresh. The deployed configuration, its status, and its name should all be visible and grouped by region.

We’ve successfully created an exception for the Application 1 team’s VNets so that they can handle SSH traffic as needed, while still maintaining protection against that port for the rest of our VNets in OurNetworkGroup, as well as against the other four high-risk ports for all of our VNets!

In Summary

If you’ve read from beginning to end, good job – we’ve learned a bunch of new concepts on the security side with Azure Virtual Network Manager! To recap, we’ve discussed:

The what and the why of security admin rules
Where security admin rules can improve common security models
How security admin rules work with NSGs
How to grant exceptions with security admin rules
Examples of high-risk ports that you can enforce blockage of at an organizational level

Best of all, we got to walk through securing your VNets with a network manager and security admin rules from end to end, and even how to create an exception with security admin rules. These pages are meant to be a guide for you in navigating the security benefits of AVNM, whether you’re new to network manager or a seasoned user, and we’re always open for questions and comments through our feedback form. Thanks for reading!

Continue to website...