Default rules – MS AZ-104 Exam Guide

Default rules

All NSGs have a set of default rules. You cannot add to, edit, or delete these default rules. However, since they have the lowest possible priority, they can be overridden by other rules you create.

The default rules allow and disallow traffic as follows:

• Virtual network  Traffic originating and ending in a virtual network is allowed in both inbound and outbound directions.
• Internet Outbound traffic is allowed, but inbound traffic is blocked.
• Load balancer Allows the Azure Load Balancer to probe the health of your VMs and role instances. If you are not using a load-balanced set, you can override this rule.

Table 4-5 shows the default inbound rules for each NSG.

TABLE 4-5 Default inbound rules

Name	Priority	Source	Source Port	Destination	Destination Port	Protocol	Access
AllowV- NetInBound	65000	VirtualNetwork	Any	Virtual- Network	Any	Any	Allow
AllowAzureLoad BalancerInBound	65001	AzureLoad- Balancer	Any	Any	Any	Any	Allow
DenyAllInBound	65500	Any	Any	Any	Any	Any	Deny

Table 4-6 shows the default outbound rules for each NSG.

TABLE 4-6 Default outbound rules

Name	Priority	Source	Source Port	Destination	Destination Port	Protocol	Access
AllowVNet OutBound	65000	Virtual Network	Any	Virtual Network	Any	Any	Allow
AllowInternet OutBound	65001	Any	Any	Internet	Any	Any	Allow
DenyAll OutBound	65500	Any	Any	Any	Any	Any	Deny

Application security groups

As you have seen, NSG rules are like traditional firewall rules and are defined using source and destination IP blocks. They enable you to segment your network traffic into application tiers, which are segmented into separate subnets.

This creates some management challenges:

• The IP blocks for each subnet must be carefully planned in advance. To ensure addi- tional servers may be added in future, each subnet must be bigger than you really need, which results in inefficient use of the IP space.
• If you make a subnet too small and run out of space, it can be time-consuming to recon-figure the network to free up additional space, especially without application downtime.
• Each subnet requires a separate NSG, making it difficult to get an overall picture of the permitted and blocked traffic at an application level.

Application security groups (ASGs) address these challenges by offering an alternative approach to network segmentation. You can use them to segment your application into sepa- rate tiers, and they strictly control the permitted network flows between tiers. However, ASGs do not require that you associate each tier with a separate subnet, so all the challenges associ- ated with planning and managing subnets fall away. With ASGs, you explicitly—rather than implicitly—define which application tier each VM belongs to, based on the subnet in which the VM has been placed. All VMs can be placed in a single subnet, and a single NSG is used to define all permitted network flows between application tiers. Because a single subnet is used, the IP space can be managed much more flexibly, and because there is a single NSG with rules referring to named application tiers, the network rules are easier to understand and can all be managed in one place.

Figure 4-23 shows a standard three-tier application architecture with web servers, appli- cation servers, and database servers. These servers have been grouped by associating each server with the appropriate application security group. All servers are placed in the same subnet without having to think about how the network space is subdivided. A single network security group contains rules defining the permitted traffic flows between application tiers.

FIGURE 4-23  Using application security groups to simplify subnet and NSG management

Application security groups enable you to configure network security as a natural exten- sion of an application’s structure, so you can group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without the manual maintenance of explicit IP addresses. The platform handles the complexity of explicit IP addresses and multiple rule sets, which allows you to focus on your business logic.

Configuring application security groups is straightforward:

1. First, create an application security group resource for each server group. This resource has no properties, other than its name, resource group, and location.
2. Next, associate the network interface from each VM with the appropriate application
   security group. This defines which group (or groups) each VM belongs to.
3. Finally, define your network security group rules using application security group names instead of explicit IP ranges. This is similar to how rules are configured using named service tags.