Chapter 4: Azure Network Security

In Chapter 1, Azure Security Introduction, we briefly touched on network security in Azure, but only discussed how network security is handled by Microsoft inside Azure data centers. As the network also falls under the shared responsibility model, in this chapter, we will discuss network security from a user aspect and how to handle the security we are responsible for.

We will cover the following topics in this chapter:

• Understanding Azure Virtual Network
• Considering other virtual networks' security
• Understanding Azure Application Gateway
• Understanding Azure Front Door

Understanding Azure Virtual Network

The first step in the transition from an on-premises environment to the cloud is Infrastructure as a Service (IaaS). One of the key elements in IaaS is Virtual Networks (VNets). VNets are a virtual representation of our local network with IP address ranges, subnets, and all other network components that we would find in local infrastructure. Recently, we have seen a lot of cloud network components introduced to on-premises networks as well, with the introduction of Software Defined Networking (SDN) in OS Windows Server 2016.

Before we start looking at VNet security, let's remember that naming standards should be applied to all Azure resources, and networking is no exception. As environments grow, this will help you have better control over your environment, easier management, and more insight into your security posture.

Each VNet that we create is a completely isolated piece of network in Azure. We can create multiple VNets inside one subscription, or even multiple VNets inside one region. There is no direct communication between any VNets, even those created inside a single subscription or region, unless configured otherwise. The first thing that needs to be configured for a VNet is the IP address range. The next thing we need is a subnet with its own range. One VNet can have multiple subnets. Each subnet must have its own IP address range within the VNet's IP address range and cannot overlap with other subnets in the same VNet.

One thing we need to consider when defining the IP address range is that it should not overlap with other VNets we use. Even when there is no initial requirement to create a connection between different VNets, this may become a requirement in the future.

Important note

VNets that have overlapping IP ranges will not be compatible for connection.

VNets are used for communication between Azure resources over private IP addresses. Primarily, they're used for communication between Azure Virtual Machines (VMs), but other resources can be configured to use private IP addresses for communication as well.

Communication between Azure VMs occurs over a network interface card (NIC). Each VM can be assigned one or more NICs, depending on the VM size. A bigger size allows more NICs to be associated with a VM. Each NIC can be assigned a private and public IP address. A private IP address is required and a public IP address is optional. As a NIC must have a private IP address, it must be associated with VNet and subnet on the same VNet.

As a first line of defense, we can use a network security group (NSG) to control traffic for Azure VMs. NSGs can be used to control inbound and outbound traffic. Default inbound and outbound rules are created during the NSG's creation, but we can change (or remove) these rules and create additional rules based on our requirements. The default inbound rules are shown in the following figure:

Figure 4.1 – Inbound security rules

The default inbound rules will allow any traffic coming from within a VNet and any traffic forwarded from Azure Load Balancer. All other traffic will be blocked.

Conversely, the default outbound rule will allow almost any outbound traffic. The default rules will allow any outgoing traffic to a VNet or the internet, as in the following figure:

Figure 4.2 – Outbound security rules

To add a new inbound rule, we need to define the source, source port range, destination, destination port range, protocol, action, priority, and name. Optionally, we can add a description that will help us understand why this rule was created. An example of how to create a rule to allow traffic over port 443 (HTTPS) is shown in the following figure:

Figure 4.3 – Adding new inbound security rules

Alternatively, we can create the same rule with Azure PowerShell:

1. First, we need to create a resource group where resources will be deployed:

   New-AzResourceGroup -Name "Packt-Security" -Location ` "westeurope"

2. Next, we need to deploy VNet:

   New-AzVirtualNetwork -Name "Packt-VNet" -ResourceGroupName ` "Packt-Security" -Location "westeurope" -AddressPrefix ` 10.11.0.0/16

3. And finally, we deploy NSG and create a rule:

   New-AzNetworkSecurityGroup -Name "nsg1" -ResourceGroupName ` "Packt-Security" -Location "westeurope"

   $nsg=Get-AzNetworkSecurityGroup -Name 'nsg1' `

   -ResourceGroupName 'Packt-Security'

   $nsg | Add-AzNetworkSecurityRuleConfig -Name 'Allow_HTTPS' `

   -Description 'Allow_HTTPS' -Access Allow -Protocol Tcp `

   -Direction Inbound -Priority 100 -SourceAddressPrefix Internet `

   -SourcePortRange * -DestinationAddressPrefix * `

   -DestinationPortRange 443 | Set-AzNetworkSecurityGroup

In order to add a new outbound rule, we need to define the same option as the inbound rule. An example of how to create a rule to deny traffic over port 22 is shown in the following figure:

Figure 4.4 – Adding new outbound security rules

Note that the priority plays a very important role when it comes to NSGs. A lower number means higher priority and a higher number means lower priority. If we have two rules that are in contradiction, the rule with the lower number will take precedence. For example, if we create a rule to allow traffic over port 443 with a priority of 100, and create a rule to deny traffic over port 443 with a priority of 400, traffic will be allowed, as the allow rule has a greater priority.

Again, we can use Azure PowerShell to create the rule:

$nsg | Add-AzNetworkSecurityRuleConfig -Name 'Allow_SSH' `

-Description 'Allow_SSH' `

-Access Allow -Protocol Tcp `

-Direction Outbound -Priority 100 `

-SourceAddressPrefix VirtualNetwork -SourcePortRange * `

-DestinationAddressPrefix * -DestinationPortRange 22 `

| Set-AzNetworkSecurityGroup

An NSG can be associated with subnets and NICs. An NSG associated on a subnet level will have all the rules applied to all the devices associated with that subnet. When an NSG is associated with a NIC, rules will be applied only to that NIC. It's recommended to associate NSGs with subnets instead of NICs for more simple management. It's easy to manage traffic on a NIC level when we have fewer VMs. But when the number of VMs is in the dozens, hundreds, or even thousands, it becomes very hard to manage traffic on a NIC level. It's much better to have VMs that have similar requirements associated on a subnet level.

In order to associate an NSG with a subnet, follow these steps:

1. Go to the Subnet section under NSG1 and select Associate, as in the following figure:
   

   Figure 4.5 – NSG Subnets blade

2. Next, we select the virtual network, as in the following screenshot:
   

   Figure 4.6 – VNet association to NSG

3. Finally, we select the subnet and confirm:

Figure 4.7 – Subnet association to NSG

Now all of the Azure VMs added to this subnet will have all the NSG rules applied immediately.

The Azure PowerShell script to associate an NSG with a subnet is the following:

$vnet = Get-AzVirtualNetwork -Name 'Packt-VNet' `

-ResourceGroupName 'Packt-Security'

Add-AzVirtualNetworkSubnetConfig -Name FrontEnd `

-AddressPrefix 10.11.0.0/24 -VirtualNetwork $vnet

$subnet = Get-AzVirtualNetworkSubnetConfig `

-VirtualNetwork $vnet -Name FrontEnd

$nsg = Get-AzNetworkSecurityGroup `

-ResourceGroupName 'Packt-Security' -Name 'nsg1'

$subnet.NetworkSecurityGroup = $nsg

Set-AzVirtualNetwork -VirtualNetwork $vnet

Let's take a simple three-tier application architecture as an example. Here, we would have VMs accessible from outside (over the internet), and these VMs should be placed in a DMZ subnet, which would be associated with an NSG that would allow such traffic. Next, we would have an application tier, which would allow traffic inside a VNet but no direct access over the internet.

The application tier would be associated with an appropriate subnet, which would (with the NSG on a subnet level) deny traffic over the internet but allow any traffic coming from the DMZ. Lastly, we would have a database tier, which would allow only traffic coming from the application tier, using the NSG associated on a subnet level. This way, any request would be able to reach the DMZ tier. Once a request is validated, it can pass to the application tier and from there it can reach the database tier. No direct communication is allowed between the DMZ and database tiers, and a direct request is not allowed to go from the internet to the application or database tiers.

For more security, resources can be associated with application groups. Using NSGs and application groups, we can create additional security rules with more network filtering options.

We will now be looking at connecting on-premises networks with Azure.

Connecting on-premises networks with Azure

In most cases, we already have some sort of local infrastructure and want to use the cloud as a hybrid where we combine cloud and on-premises resources. In such cases, we need to think about how we are going to access Azure Virtual Network (VNet) from our local network.

There are three options available:

• Point-to-Site connection (P2S) is usually used for management. It enables you to create a connection from a single on-premises computer to Azure VNet. It has a secure connection, but not the most reliable one, and shouldn't be used for production purposes, only to perform management and maintenance tasks.
• Site-to-Site connection (S2S) is a more stable connection that enables a network-to-network connection. In this case, that would be from an on-premises network to a VNet, where all on-premises devices can connect to Azure resources and vice versa. Using S2S enables you to expend local infrastructure to Azure, use hybrid cloud, and take advantage of the best things both on-premises and cloud networks can offer.
• ExpressRoute is a direct connection from a local data center to Azure. It doesn't go over the internet and offers a much better connection. Compared to an S2S connection, ExpressRoute offers more reliability and speed with lower network latency.

Next, we will be checking out how to create an S2S connection.

Creating an S2S connection

In order to create an S2S connection, several resources must be created. First, we need to create a Virtual Network Gateway (VNG). During the process of creating a VNG, we need to define a subscription, a name for the VNG, the region where it will be created, and a VNet must be selected.

The VNet that we can select is limited to the region where the VNG will be created. A separate gateway subnet must be defined, so we can either select an existing one or it will be created automatically if it doesn't exist on the selected VNet.

In the same section, we need to define the public IP address (create a new one or select an existing one) and select to enable (or disable) active-active mode or BGP. An example is shown in the figure that follows.

The following details need to be filled in:

• Subscription
• Instance details
• Public IP address

You can see an example of this in the following figure:

Figure 4.8 – Creating a VNG

Another resource we need to create is a Local Network Gateway (LNG). To create an LNG, we need to define the following:

• Name
• IP address
• Address space
• Subscription
• Resource group
• Location
• BGP settings

The BGP settings are optional. The IP address we need to define is the public IP address of our VPN device, and the address range is the address range of our local network. An example is shown in the following figure:

Figure 4.9 – Creating an LNG

After a VNG and an LNG are created, we need to create a connection in VNet:

1. Under the connection settings in the VNet blade, add a new connection.
2. The following parameters need to be defined: Name, Connection type, Virtual network gateway, Local network gateway, Shared key (PSK) and IKE Protocol.
3. Subscription, Resource group and Location will be locked and will use the same options as the ones assigned to the selected VNet:

Figure 4.10 – Creating a VPN connection

After a connection is created in Azure, we still need to create a connection on our local VPN device. It's highly recommended to only use supported devices (most industry leaders are supported, such as Cisco, Palo Alto, and Juniper, to name a few). When configuring a connection on a local VPN device, we need to take into account all the parameters used on the Azure side.

Once a connection is configured on both sides, the tunnel is up and we should be able to access Azure resources from an on-premises network and from Azure to a local network. Of course, we can control how traffic flows and what can access what, how, and under which conditions.

We have now seen how to create connections between Azure VNets and local networks. But we often have a need to connect one VNet with another VNet. Of course, it's still important to keep the same level of security, even if everything is inside Azure. In the next section, we'll discuss how to connect networks in such a situation.

Connecting a VNet to another VNet

In a case where we have multiple VNets in Azure, we may need to create a connection between them in order to allow services to communicate between networks. There are two ways in which we can achieve this goal:

• The first one would be to create an S2S between the VNets. In this case, the process is very similar to creating an S2S between a VNet and a local network. We need to create a VNG for both VNets, but we don't need an LNG. When creating a connection, we need to select VNet-to-VNet in Connection types and select appropriate VNGs.

Another option would be to create VNet peering. An S2S connection is secure and encrypted, but it passes over the internet. Peering uses an Azure backbone network in order to route traffic, and it never leaves Azure. This makes peering even safer.

To create peering between VNets, we need to carry out the following steps:

1. Go to the peerings section in the VNet blade and add a new peering.
2. We need to define the name and the VNet we want to create a connection to.
3. Other settings are also present, such as whether we want to allow connections to go both ways, or whether we want to allow forwarded traffic.

A peering example is shown in the following figure:

Figure 4.11 – Creating VNet-to-VNet peering

It's very important to understand additional security settings in VNet peering and how they affect the network traffic.

The network access settings will define traffic access from one VNet to another. For example, we may want to enable access from VNet A to VNet B. But, because of security settings, we want to block access from VNet B to VNet A. This way, resources in VNet A will be able to access resources in VNet B, but resources in VNet B will not be able to access resources in VNet A:

Figure 4.12 – VNet peering

In the next section, we will define how we handle forwarded traffic. Let's say that VNet A is connected to VNet B and VNet C. There is no connection between VNet B and VNet C. With these settings, we define whether we want to allow traffic from VNet B to reach VNet C over VNet A. The same thing can be defined the other way around:

Figure 4.13 – VNet peering with multiple VNets

The gateway transit settings allow us to control whether we want a current connection to be able to use other connections with another network. For example, VNet A is connected to VNet B and VNet B is connected to an on-premises network (or another VNet). This setting will define whether traffic from VNet A will be able to reach the on-premises network. In this case, one of the VNets would be replaced with the on-premise network. If there is a connection between the on-premise network and VNet A, and a connection between VNet A and VNet B, the gateway transit would decide whether traffic from VNet B can reach the on-premise network.

In the next section, we will be discussing the most important thing when it comes to security, which is service endpoints in VNets.

VNet service endpoints

VNet service endpoints enable us to extend some Platform as a Service (PaaS) services to use private address spaces. With service endpoints, we connect services (that don't have this option by default) to our VNet enabling services to communicate over private IP addresses. This way, traffic is never exposed publicly, and data exchange is carried out over the Microsoft Azure backbone network.

Only some Azure services support this feature:

• Azure App Service
• Azure Container Registry
• Azure Cosmos DB
• Azure Data Lake
• Azure Database for MariaDB
• Azure Database for MySQL
• Azure Database for PostgreSQL
• Azure Event Hub
• Azure Key Vault
• Azure Service Bus
• Azure Storage
• Azure SQL Database
• Azure SQL Data Warehouse

The first security benefit from using service endpoints is definitely that data never leaves the private space. Let's say that we have Azure App Service and Azure SQL Database connected to the VNet with service endpoints. This way, all communication between the web application on App Service and the database on Azure SQL Database would be done securely over the VNet. No data would be exposed publicly, as is the case when using the same services without endpoints.

Without this feature, both services would only have public IP addresses and communication between them going over the internet. Even though there are ways of doing this securely, with communication being sent encrypted over HTTPS, using service endpoints partly removes the security risk in this communication.

But the security benefits of using service endpoints don't stop there. As services connected to VNet with service endpoints are assigned private IP addresses from a specific subnet, all security rules associated with this subnet are applied to our services as well. If an NSG blocks specific traffic on our subnet, the same traffic will be blocked for PaaS services as well.

We can enable service points on VNet either during the creation of a VNet or at a later time. Service endpoints are enabled on a subnet level, and this can be done either on a VNet or subnet configuration. Follow these steps to enable service endpoints in VNet:

1. Go to the VNet blade and select service endpoints. Click add and select the subnet and services you want to use, as in the following figure:
   

   Figure 4.14 – Adding PaaS service endpoints

2. Go to the subnet configuration and select the services, as in the following figure:

Figure 4.15 – Enabling service endpoints on subnet

Enabling service endpoints on a VNet and subnet is only half of the job. We need to enable settings on a PaaS service for the service endpoint to take effect. When enabling the service endpoint in the service settings, only subnets with enabled service endpoints will show up.

With service endpoints, we complete the network section that is available directly on Azure VNet settings. But there are other things we need to consider when it comes to network security. Let's see what else is available to increase network security in Azure.

Considering other virtual networks' security

For additional security and traffic control, a Network Virtual Appliance (NVA) can be used. An NVA can be deployed from Azure Marketplace. Once deployed, you will realize that an NVA, in fact, is an Azure VM with a third-party firewall installed. Most industry leaders are present in Azure Marketplace and we can deploy firewall solutions that we are used to in an on-premises environment. It's important to mention that we don't have to decide between NSGs or NVAs; these can be combined for additional security.

Additional network security can be achieved with Azure Firewall as well. Azure Firewall is a firewall as a service. It allows better network control than an NSG and can be compared to an NVA solution in many aspects. But Azure Firewall also has a few advantages compared to an NVA, such as built-in high availability, the option to deploy to multiple Availability Zones, and unrestricted cloud scalability. This means that no load balancers are needed. We can span Azure Firewall across multiple Availability Zones (and achieve an SLA of 99.99%), and scaling is configured to automatically accommodate any change in network traffic. Some options that are supported are: application filtering, network traffic filtering, FQDN tags, service tags, outbound SNAT support, inbound DNAT support, and multiple public IP addresses. With these options, we can have complete control of network traffic in our VNet. It's important to mention that Azure Firewall is compliant with many security standards, such as SOC 1 Type 2, SOC 2 Type 2, SOC 3, PCI DSS, and ISO 27001, 27018, 20000-1, 22301, 9001, and 27017.

Next, we will be looking at how to deploy and configure Azure Firewall through the Azure portal.

Azure Firewall deployment and configuration

This example – to deploy and configure Azure Firewall – requires Azure PowerShell. However, Azure Firewall can be configured and deployed through the Azure portal as well.

Azure Firewall deployment

In order to deploy Azure Firewall, we need to set up the required network and infrastructure:

1. First, we need to create subnets, create a VNet, and associate the subnets with the VNet:

   $FWsub = New-AzVirtualNetworkSubnetConfig -Name ` AzureFirewallSubnet -AddressPrefix 10.0.1.0/26

   $Worksub = New-AzVirtualNetworkSubnetConfig -Name Workload-SN ` -AddressPrefix 10.0.2.0/24

   $Jumpsub = New-AzVirtualNetworkSubnetConfig -Name Jump-SN `

   -AddressPrefix 10.0.3.0/24

   $testVnet = New-AzVirtualNetwork -Name Packt-VNet `

   -ResourceGroupName Packt-Security -Location "westeurope" `

   -AddressPrefix 10.0.0.0/16 -Subnet $FWsub, $Worksub, $Jumpsub

2. Next, we need to deploy Azure VM, which will be used as a jump box (the VM we connect to in order to perform admin tasks on other VMs in the network; we don't connect to other VMs directly, but only through a jump box):

   New-AzVm -ResourceGroupName Packt-Security -Name "Srv-Jump" `

   -Location "westeurope" -VirtualNetworkName Packt-VNet `

   -SubnetName Jump-SN -OpenPorts 3389 -Size "Standard_DS2"

3. After the jump box, we create a test VM:

   $NIC = New-AzNetworkInterface -Name Srv-work `

   -ResourceGroupName Packt-Security -Location "westeurope" `

   -Subnetid $testVnet.Subnets[1].Id

   $VirtualMachine = New-AzVMConfig -VMName Srv-Work -VMSize ` "Standard_DS2"

   $VirtualMachine = Set-AzVMOperatingSystem -VM $VirtualMachine `

   -Windows -ComputerName Srv-Work -ProvisionVMAgent `

   -EnableAutoUpdate

   $VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine ` -Id $NIC.Id

   $VirtualMachine = Set-AzVMSourceImage -VM $VirtualMachine `

   -PublisherName 'MicrosoftWindowsServer' -Offer 'WindowsServer' ` -Skus '2016-Datacenter' -Version latest

   New-AzVM -ResourceGroupName Packt-Security -Location ` "westeurope" -VM $VirtualMachine -Verbose

4. Finally, we deploy Azure Firewall:

   $FWpip = New-AzPublicIpAddress -Name "fw-pip" `

   -ResourceGroupName Packt-Security -Location "westeurope" `

   -AllocationMethod Static -Sku Standard

   $Azfw = New-AzFirewall -Name Test-FW01 -ResourceGroupName `

   Packt-Security -Location "westeurope" -VirtualNetworkName ` Packt-VNet -PublicIpName fw-pip

   $AzfwPrivateIP = $Azfw.IpConfigurations.privateipaddress

5. Next, we will look at the Azure Firewall configuration.

The Azure Firewall configuration

After Azure Firewall is deployed, it doesn't actually do anything. We need to create a configuration and rules in order for Azure Firewall to be effective:

1. First, we will create a new route table with the BGP propagation disabled:

   $routeTableDG = New-AzRouteTable -Name Firewall-rt-table `

   -ResourceGroupName Packt-Security -location "westeurope" `

   -DisableBgpRoutePropagation

   Add-AzRouteConfig -Name "DG-Route" -RouteTable $routeTableDG `

   -AddressPrefix 0.0.0.0/0 -NextHopType "VirtualAppliance" `

   -NextHopIpAddress $AzfwPrivateIP | Set-AzRouteTable

   Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $testVnet `

   -Name Workload-SN -AddressPrefix 10.0.2.0/24 `

   -RouteTable $routeTableDG | Set-AzVirtualNetwork

2. Next, we create an application rule that allows outbound access to www.google.com:

   $AppRule1 = New-AzFirewallApplicationRule -Name Allow-Google `

   -SourceAddress 10.0.2.0/24 -Protocol http, https `

   -TargetFqdn www.google.com

   $AppRuleCollection = New-AzFirewallApplicationRuleCollection `

   -Name App-Coll01 -Priority 200 -ActionType Allow -Rule $AppRule1

   $Azfw.ApplicationRuleCollections = $AppRuleCollection

   Set-AzFirewall -AzureFirewall $Azfw

3. We then create a rule to allow a DNS on port 53:

   $NetRule1 = New-AzFirewallNetworkRule -Name "Allow-DNS" `

   -Protocol UDP -SourceAddress 10.0.2.0/24 `

   -DestinationAddress 209.244.0.3,209.244.0.4 -DestinationPort 53

   $NetRuleCollection = New-AzFirewallNetworkRuleCollection `

   -Name RCNet01 -Priority 200 -Rule $NetRule1 -ActionType "Allow"

   $Azfw.NetworkRuleCollections = $NetRuleCollection

   Set-AzFirewall -AzureFirewall $Azfw

4. And then we need to assign a DNS to an NIC:

   $NIC.DnsSettings.DnsServers.Add("209.244.0.3")

   $NIC.DnsSettings.DnsServers.Add("209.244.0.4")

   $NIC | Set-AzNetworkInterface

Try connecting to a jump box, and then through a jump box to test the VM. From the test VM, try resolving multiple URLs. Only www.google.com should succeed, as all outbound traffic is denied except for the explicit allow rule we created.

Let's move on to networking in PaaS and see what else is available, besides securing PaaS with service endpoints. We can have better network control and prevent unwanted traffic even with endpoints publicly available.

Understanding Azure Application Gateway

The next Azure service that can help increase security is Application Gateway. Application Gateway is a web-traffic load balancer that enables traffic management for web applications. It operates as layer 7 (L-7, or application layer) load balancing. This means that it supports URL-based routing and can route requests based on the URI path or host header.

Application Gateway supports Secure Socket Layer (SSL/TSL) termination at the gateway. After the gateway, traffic flows unencrypted to backend servers, which are unburdened from encryption and decryption overhead. However, if this is not an option because of security, compliance, or any other requirements, full end-to-end encryption is supported as well.

Application Gateway also supports scalability and zone redundancy. Scalability allows autoscaling depending on traffic load, and zone redundancy allows the service to be deployed to multiple availability zones in order to provide better fault resiliency, and removing the need to deploy the service to multiple zones manually.

Overall, Azure Application Gateway is an L-7 load balancer and we could question the security aspects of it (if we exclude SSL/TSL termination), as it's more a question of reliability and availability. But Application Gateway has an amazing security feature called Azure Web Application Firewall (WAF). WAF protects web applications against common exploits and vulnerabilities.

WAF is based on the Open Web Application Security Project (OWASP) and is updated to address the latest vulnerabilities. As it's PaaS, all updates are done automatically without any user configuration. From a policy perspective, we can create multiple custom policies and apply different sets of policies to different web applications.

Two modes are available: detection and prevention. In detection mode, WAF will detect all suspicious requests but will not stop them, only log them. It's important to mention that WAF can be integrated with different logging tools, so logs can be stored for auditing purposes. When in protection mode, WAF will also block any malicious requests, return a 403 unauthorized access exception, and close the connection. Prevention mode also logs all attacks.

Attacks are categorized by four severity levels:

• Critical (5)
• Error (4)
• Warning (3)
• Notice (2)

Each level has a severity value and the threshold for blocking is 5. So, a single critical issue is enough to block a session with value 5, but at least 2 error issues are needed to block a session, as 1 error with a value of 4 is below the threshold.

WAF works as a filter before Application Gateway – it will process a request, decide whether it's valid or not, and, based on this decision, it will allow the request to proceed to Application Gateway or reject the request. Once the request is allowed by WAF, Application Gateway acts as a normal L-7 load balancer, as if WAF was turned off. You can see that in the following figure:

Figure 4.16 – Application Gateway traffic flow

Some of the attacks that can be detected and prevented with WAF are listed here:

• SQL injection
• Cross-site scripting
• Command injection
• Request smuggling
• Response splitting
• HTTP protocol violations and anomalies
• Protection against crawlers and scanners
• Geo-filter traffic

WAF on Application Gateway supports logging options to Azure Monitor, diagnostic logs to storage accounts, and integration with security tools such as Azure Security Center or Azure Sentinel.

Understanding Azure Front Door

Azure Front Door works very similarly to Application Gateway but on a different level. Like Application Gateway, it's an L-7 load balancer with an SSL offload. The difference is that Application Gateway works with services in a single region where Azure Front Door allows us to define, manage, and monitor routing on a global level. With Azure Front Door, we can ensure the highest availability using global distribution. A similar thing can be achieved with Azure Traffic Manager (in terms of global distribution), but this service lacks L-7 load balancing and SSL offloading.

What Azure Front Door provides actually combines Application Gateway and Traffic Manager to enable an L-7 load balancer with global distribution. It's also important to mention that a WAF is also available on Azure Front Door. Using a WAF on Azure Front Door, we can provide web application protection for globally distributed applications.

Summary

In this chapter, we addressed network security and, prior to that, we saw how to manage cloud identities. We need to remember that network security doesn't stop with IaaS and VNets. Network security basics are usually associated with VNets and NSGs. But even with IaaS, it does not stop there, and we have options to extend with an NVA or Azure Firewall. With PaaS, we can leverage VNet's service endpoints but extend security with services like Application Gateway or Azure Front Door.

But, with all the preclusions limiting who, how, when, and from where we can access our resources, we still need to handle sensitive information and data. The next chapter will address how can we manage certificates, secrets, passwords, and connection strings using Azure Key Vault.

Questions

1. We can control traffic in virtual networks with…

   A. A network interface

   B. A Network Security Group (NSG)

   C. An Access Control List (ACL)

2. What type of connection is available with on-premises networks?

   A. Point-to-Site

   B. Site-to-Site

   C. VNet-to-VNet

3. A connection between Virtual Networks can be made with…

   A. VNet-to-VNet

   B. VNet peering

   C. Both of the above

   D. None of the above

4. Which feature allows us to connect PaaS services to a virtual network?

   A. Service connection

   B. Service endpoints

   C. ExpressRoute

5. When multiple networks are involved…

   A. We can define a route

   B. Traffic is blocked by default

   C. Traffic is allowed by default

   D. A and B are correct

   E. A and C are correct

6. Which feature in Application Gateway adds additional security?

   A. Open Web Application Security Project (OWASP)

   B. Web Application Firewall (WAF)

   C. Secure Socket Layer (SSL) / Transport Layer Security (TSL)

7. What type of attack cannot be blocked with Application Gateway?

   A. SQL injection (SQLi)

   B. Cross-Site Scripting (XSS)

   C. Distributed Denial of Service (DDoS)

   D. HTTP protocol violations