Application rules can be used to define the set of domain names that can be accessed by the resources deployed in the subnet. You will be defining these domain name as fully qualified domain names, and based on the domain names, the traffic is allowed. For example, you need to add domains like windowsupdate.microsoft.com, download.windowsupdate.com, download.microsoft.com, etc., to allow Windows update traffic from your subnet. You could also add wildcard entries for specifying the subdomains, for example, *.windowsupdate.com. Just like we did in the case of NAT rules and network rules, let’s understand the parameters required to set up an application rule.
- Name: Friendly name given to identify the rule
- Source addresses: IP address of the source of traffic
- Protocol and port: HTTP/HTTPS protocol and the port numbers
- Target FQDN: The domain names you want to add to the rule
Rule Processing Order
When a packet hits the firewall, the packet will be inspected against the rules that we configured to decide if it’s allowed or not. The rules are processed in the following order. The network rules will be evaluated first, and then the application rules are evaluated. Once a rule allows the traffic, no further evaluation is done. In other words, the evaluation stops when a matching allow rule is found; if none of the rule matches, then the traffic is dropped.
Since we have a clear understanding about the rules in the firewall, now we will present a scenario and see how the firewall can be implemented to secure the workload.
Implementing Azure Firewall
Azure Firewall implementation requires planning, and mostly the firewalls are placed in a central or hub virtual network, which is connected with other virtual networks using virtual network peering or VPN gateways. The Microsoft documentation gives an incredibly good representation of this architecture (refer to Figure 3.6).
If you look at the architecture, you can see that Azure Firewall acts as a crucial point for all communications happening from the Internet as well as on-premises. By default, all traffic from the Internet and on-premises is denied. Using the rules we discussed earlier, you will fine-tune our firewall and only allow the traffic that is required. You will be using NAT rules, application rules, and network rules to tailor a secured network. All known malicious IP and FQDNs are blocked by the Microsoft threat intelligence, so administrators need not set up any other security solution for blocking malicious traffic.
FIGURE 3.6 Demystifying the firewall architecture
There is a full tutorial available in the Microsoft documentation for how to do the firewall implementation.
https://docs.microsoft.com/en-us/azure/firewall/tutorial-firewall-deploy-portal-policy
Summary
The fundamental building block of infrastructure is networking, and in Azure we use virtual networks to implement networking. We discussed the concepts related to virtual networks and their role in the bigger picture. We covered IP allocation methods and types of IP addresses. Later, we discussed network routes and the purpose of system routes and user-defined routes. The system routes are responsible for all communications that happen between the resources inside a virtual network, as well as the communication from the virtual network to the Internet. Administrators can always override these system routes and define their own routing rules using UDR. UDR is useful if you are using NVA or Azure Firewall and you want to force the traffic to pass via NVA or Azure Firewall.
After covering routing, we covered service endpoints; they are used to establish a connection from your virtual network resources and other resources deployed in your subscription. The point to remember here is that the VMs will be able to communicate using their private IP address to the public endpoint of the service you want to connect. If you need the service to have a private IP address within the virtual network, then you need to implement a private link. Creating a private link will create a private IP address for the PaaS service as if it’s deployed in the virtual network, the same as the VM.
Later, our discussion revolved around Azure DNS. You saw how you can host domains in Azure DNS and also set up private DNS zones for the name resolution of your VMs. Then, we shifted our focus to securing our network. Securing the network is primarily accomplished by using network security groups and Azure Firewall. We studied the implementation of both the resources and the difference between them.
Networking is a very vast topic, and we just started the fundamentals and some of the prerequisites. So far, we were talking about the networking configuration in Azure; however, in a hybrid cloud environment, administrators must be affluent in setting up intersite connectivity. By using intersite connectivity, you can extend your on-premises infrastructure to the cloud. In the next chapter, you will focus on setting up this hybrid environment and intersite connectivity using VPN gateways and ExpressRoute.
Leave a Reply