Azure Firewall Network to Application Security Policy Migration

As organizations increasingly adopt cloud-based architectures, network security becomes even more critical to protect against cyber threats. Azure Firewall is a popular tool for securing network traffic in Azure environments, providing features such as network and application-level filtering, threat intelligence integration, and high availability. One aspect of Azure Firewall configuration is the definition of security policies, which specify how traffic is allowed or blocked based on various criteria. In this blog post, we will focus on the migration of a security policy from a “Network Rule Collection” to an “Application Rule Collection” in Azure Firewall.

Specifically, we will use an example scenario of allowing outbound traffic from a Linux machine in a spoke network to “google.com” and “example.com” websites. Initially, this is achieved using a Network Policy that allows HTTP/HTTPS traffic to the websites. We will then show how to migrate this policy to an Application Policy, where we will limit the access to only Google and block Example by using the implicit deny rule.

By the end of this post, you will have a good understanding of the steps involved in migrating from a Network Policy to an Application Policy in Azure Firewall, and how to effectively manage network traffic in your Azure environment.

The code snippet above provides specific instructions to Terraform on which versions of core and plugins to download and run. Furthermore, we have the option to define explicit backend remote storage locations for the Terraform state, such as Azure Blob Storage or AWS S3. If you plan to run this lab via GitHub Actions or any other ad-hoc temporary host compute, it is highly recommend setting up the backend storage by following the instructions provided to allow state to transition between hosts.

In this step, we will define variables that our Terraform configuration will use. Please note that the password required to log into the machines is not published in clear text code, but rather inherited through the environmental variables of our Linux system. Additionally, we can specify the size of the Linux servers spawned by the lab, which may serve as a cost optimization point for many.

To begin the process of creating Azure resources using Terraform, we first need to create the resource groups. In most organizations, there is an IT operations model in place in the cloud where specific components such as virtual networks, route tables, peering, etc. are owned by teams such as “network” and fall under their subscription. Meanwhile, other components such as virtual machines, network interface cards, security groups, storage, etc. are owned by the application team and associated with their own resource group.

In the Microsoft Cloud Adoption Framework (CAF), it is recommended to dedicate an entire virtual network or spoke to one application, and all aspects of that spoke should be mapped to the application team’s resource group with that resource group mapped to their subscription.

To commence the establishment of our hub network, the code snippet above creates a virtual network for the hub and carves out a subnet, “GatewaySubnet,” for a Virtual Network Gateway (VNG) configured for Express Route (ExR). While the lab lacks a connection on the other end, the functionality of the Express Route Virtual Network Gateway is not required. However, the code base being used is forked from a more robust lab topology, and cost optimization refactoring is possible but not covered in this post.

In the hub network, we will be implementing a policy enforcement point through the use of an Azure Firewall capable of deep packet inspection for the Application rules that filter at layer 7. The utilization of Azure Firewall application rules presents an advantage in providing a more granular level of control over network traffic. This enables us to allow or block traffic based on the specific application or protocol being used, ensuring that only authorized traffic is allowed through the firewall. Incorporating these rules helps to enhance security, thereby reducing the risk of data breaches or other security incidents. Furthermore, application rules assist in meeting compliance requirements by providing more detailed logs and audit trails of network traffic.

With the firewall deployed, we can discuss the different types of firewall rules that can be implemented on an Azure Firewall that are organized through rule collection groups:

A “Rule Collection Group” is a useful feature in Azure Firewall that allows multiple rule collections (rule types) to be organized into a single logical entity for simplified management. This container is often used to group together rule collections that share common properties such as applications, IP addresses, or ports. Similar to the decision point when setting up the landing zone, whether to use a centralized or decentralized approach, this feature also requires consideration for IT Operations or a tightly coupled Azure operation that follows a cloud adoption framework. In a tightly coupled Azure operation, a rule collection is usually deployed per application and all inputs required for that specific application’s ingress and egress communications are provided in a workflow that can be shared in the definition of their security group policy to ring fence their application components.

In most scenarios, regardless of their coupling, firewalls are typically managed by the same group that manages on-premises firewalls, following a traditional model. Azure Firewall has a fixed order of operations for their cloud-native firewall, which is crucial for our scenario as depicted above. “Rule Collection Groups” are prioritized from low to high, as the list is read traditionally from top to bottom. It is possible to deploy multiple “Rule Collections” within a “Rule Collection Group,” but those rule collections must be prioritized within the group from low to high, according to the specific order enforced by Microsoft. DNAT Rule collections must be prioritized before Network and Application types. Network types must be prioritized before Application types.

A common migration strategy for firewall engineers to migrate policies from legacy layer 4 to modern layer 7 is to create a new rule with all the scope requirements of the old rule and place it above the old rule in the policy set. Over time, the hit count on the old rule will decrease as it is continuously evaluated for legitimate traffic flows before being removed from the rule base due to lack of hit count incrementation or a fiat decision to deny unidentifiable illegitimate traffic flows.

Due to Azure Firewall’s order of operations within a rule collection group, it is impossible to place a more advanced Application Rule Collection before a Network Rule Collection that should only be used through an approved exception process. The workaround for this limitation is to dedicate a “Rule Collection Group” to each “Rule Collection” type. This allows for the distribution of rule collection types from individual applications in a tightly coupled manner into these centralized “Rule Collection” type groups because there is no logic within Azure to determine the type of collections contained therein at the group level.

Once the hub virtual network components are deployed, we will proceed to deploy a centralized bastion and jump host spoke network. This network will enable us to source HTTP connections to the internet. It is important to note that this code snippet is derived from a much larger topology and is used for quick production purposes. However, you can restructure it to reduce costs by manually configuring the route tables. For instance, you can configure the default route to point towards the firewall to enable SSH/RDP connections directly to an attached “PIP” of a host machine. Alternatively, you can establish an inbound NAT on the firewall to access the private IP address of the host machine.

To initiate the traffic flow and establish a baseline, you should connect to the Linux host via the Azure Bastion host. To do so, access the Azure portal, go to the Azure Bastion virtual network spoke, and choose the Bastion service from the left-hand menu. Then, select “MACUETNTPMAJH01,” our Linux host, and enter the username as “MyAppAdmin” along with the password set for the Linux host in the Terraform code. Finally, click on the “connect” button to complete the process.

Upon establishing a connection to the Linux machine, we will proceed with two actions. Firstly, a curl request will be sent to “google.com,” followed by a second curl request to “example.com.” If the lab setup was correctly deployed, both actions should succeed, as demonstrated in the accompanying screenshot. However, our policy objective, as stated earlier in this post, was to allow connections to “google.com” while denying connections to “example.com.” The reason the second data flow is allowed is that HTTP and HTTPS are generically permitted through both the NSG ring fencing the Linux host and the Azure Firewall. The NSG lacks the ability to perform deep packet inspection to ensure that the HTTP headers are targeted at the desired location. However, the Azure Firewall or any Next Generation Firewall (like Palo Alto) is capable of performing the requisite deep packet inspection.

Although you can assign a name to the new rule collection, specify the type as “Application,” and adjust its priority to be more attractive, attempting to associate it with the existing “Rule Collection Group” will not be successful. As the screenshot above shows, the order of operations for Azure Firewall does not permit adding more feature-rich rules above the legacy rules that must be migrated within the same “Rule Collection Group.” As we’ve discussed, you can make the priority of these rules lower than the existing network rule collection, but you will not see any difference on the Linux host, as the Azure Firewall reads rule collections from top to bottom and matches packets against the first matching rule.

(I discarded these changes at this point)

As previously discussed, to get the “Application Rule Collection” installed before the existing “Network Rule Collection” the “Application Rule Collection” will need to be distributed into its own “Rule Collection Group” by itself with that group receiving a more attractive priority. Start by creating a new “Rule Collection Group” called “MAC-UE-TENANT-HUB-PROD-AZFW-APP-POL-RCG” with a priority of 400.

(Note: All these firewall creation, modification, or deletion steps take several minutes for Azure to complete.)

Once the application rules have been inserted and the broader network rules have been removed, you can proceed to reconnect to the Linux host via the Azure Bastion and retry sending the two curls to “google.com” and “example.com”. As shown in the screenshot above, the first curl to “google.com” is allowed through the firewall, whereas the second curl to “example.com” is blocked due to the implicit deny of the firewall caused by the absence of an explicit policy that allows the connection. To verify this, you can examine the Azure Firewall Logs by accessing the firewall resource in the Azure portal, selecting logs, and then running the “Application Rule Log Data” wizard. The exact query code snippet is provided below for your reference.

deployment.yaml:

Thank you for reading this post on configuring Azure Firewall with application rules. If you found this information useful, please feel free to follow me on LinkedIn for more articles on cloud computing and infrastructure. If you have any questions or comments, I would love to hear from you. You can reach me on LinkedIn or through my website.

Related posts:

The news comes from Eric Trump. Long sad at feeling out of the loop, out of the family, and out of the Russian-linked nest, Eric Trump has “gone public” with word that many people associated with the…

Holding on to what you believe will happen in the future creates a strong attatchment towards the outcome. As we know, life is unpredictable. How many times have you thought out a situation in your…

Content marketing is not a new concept, but it continues to evolve as search engine algorithms and consumer behavior change. The most successful content marketing strategies for SEO prioritize…