Network and application protection

This section introduces the core solutions available in Azure to protect and secure the network and applications running in Azure; this section also covers solutions that, while not part of the exam objectives, have been included with brief coverage as they should be considered required knowledge for a day-to-day Azure role.

NSGs

An NSG is a network security control and should be part of your DoD approach to protecting the network layer from network threats.

An NSG controls access, limits connections to virtual machines (VMs) in an Azure Virtual Network (VNet), and uses a deny-by-default policy; this means that all access is denied unless explicitly allowed. The following diagram shows a simplification of this:

Figure 7.7 – VM access

In the preceding diagram, Subnet 1 has no traffic filtering in place, so you would be able to connect to Windows VM1 using Remote Desktop Protocol (RDP) on port 3389, and so can an attacker; the most common attack is a brute-force attack to connect to a VM using unsecured management ports—that is, port 3389 for a Windows VM and port 22 for a Linux VM.

Windows VM2, however, has an NSG applied at the subnet level and so, by default, will filter traffic and deny access when attempting to connect using RDP on port 3389.

An NSG uses a collection of inbound and outbound rules to filter network traffic, in much the same way a traditional packet filter appliance firewall does; it evaluates five data points (referred to as the 5-tuple method) to evaluate whether access is allowed or denied.

An NSG will not encrypt inbound or outbound traffic; it is used for filtering traffic to and from a VM by setting the following five data points:

• Source of the traffic
• Source port used by the traffic
• Destination of the traffic
• Destination port used by the traffic
• Protocol used by the traffic

The preceding data points will determine if a connection can be made; the NSG will provide an action to be taken by a rule (allow or deny) and apply a priority. Each rule is given a number—the lowest-number rules will be processed first.

Any troubleshooting for not being able to access a VM should start by determining the ports and protocols required to establish the communication, then identifying if they are being filtered or if they are blocked.

I use an adage that says: 90% of the time, it’s a ports or protocol (or permissions) issue, and so is the other 10%.

There are a set of default rules for an NSG (which cannot be removed or disabled); these specify which source and destination will be able to access resources to and from the VNets and specify the port and protocol that will be allowed or denied. For a machine to be accessible from the internet on the chosen port, you must ensure that there are rules added to an NSG to allow these ports for communication; by default, all inbound traffic that doesn’t meet one of the default rules will be blocked.

An NSG can be associated with a VM network interface controller (NIC) and a subnet (but not a VNet); the same NSG can be associated with multiple subnets and NICs but a subnet and a NIC can only have one NSG associated. The following diagram aims to visualize this:

Figure 7.8 – NSG association

An NSG can only be used to control access and filter traffic for resources in the same region and subscription as the NSG; if you wish to control access and filter traffic for resources across multiple regions or VNets, then Azure Firewall is required for this type of centralized security control of highly distributed networks.

This section looked at NSGs, which can be used as part of a DiD strategy. The following section looks at Azure Firewall, another network security control that can be implemented.