Getting Started with Azure Firewall REST API: A Step-by-Step Guide – Part I
This blog is written in collaboration with andrewmathu. The REST API is essential for managing resources in Azure, providing a structured way to perform create, read, update, and delete (CRUD) operations. By using HTTP methods such as GET, POST, PUT, and DELETE, the REST API makes it straightforward for administrators to interact with Azure resources. It supports various data formats, including JSON and XML, ensuring flexibility in data exchange. This capability is particularly useful for automating workflows, streamlining deployments, and integrating with continuous deployment and integration processes. Azure Firewall is a cloud-native, intelligent network firewall security service that provides top tier threat protection for your cloud workloads running in Azure. It is a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability. The Azure Firewall REST API allows users to automate firewall configurations, retrieve policy details, and manage rules programmatically. This blog provides step-by-step guidance on interacting with the Azure Firewall REST API and serves as Part I of our series. In this part, we will focus on the prerequisites, initial setup, and specific tasks such as creating an Azure Firewall instance, creating a firewall policy, associating policies, updating threat intelligence settings, and defining network and application rules. Getting Started In this blog, we will use Bruno, a lightweight, offline and user-friendly API testing tool, to send REST API requests to Azure Resource Manager for managing Azure Firewall configurations. While other API testing tools such as Postman, PowerShell, Azure CLI, and Swagger can also be used to interact with Azure REST APIs, the fundamental principles remain the same, with only the interface differing. Before diving into the API requests, we will first cover the prerequisites and initial setup. Then, we will demonstrate how to use Bruno to perform essential Azure Firewall operations such as creating a firewall instance, configuring policies, associating policies, updating threat intelligence settings, and defining firewall rules Prerequisites: Link to download Bruno: Bruno API Client | Downloads. Bruno documentation: What is Bruno? – Bruno Docs Link to blog that covers how to prepare your identities: Azure REST APIs with Postman (2021) | Jon Gallant. Note: While this blog focuses on using Postman to send REST API commands, the steps can be adapted for other API testing tools, such as Bruno, which we are using in this blog. Using the steps outlined in the blog, we can configure a collection for Bruno with the variables defined as below: Bruno supports pre-request scripts for modifying requests, but unlike Postman, it lacks built-in request chaining for authentication. While it's possible to use fetch() to obtain an access token, Bruno does not ensure the request waits for the token before execution. Other tools such as PowerShell or Insomnia can automate token retrieval, but in our case, we manually fetch the token via a POST request and use it in the Authorization header for subsequent API calls. Since tokens expire after about 60 minutes, this process will need to be repeated periodically. The access token that we obtain from our POST request is used in the collection to authenticate API requests to Azure Resource Manager. It is included in the Authorization header of each request to ensure that the API calls have the necessary permissions to interact with Azure Firewall. Azure Firewall Configurations via REST API With our prerequisites complete, we now proceed with some Azure Firewall configurations through REST API: Creating a new Azure Firewall instance. Creating a new Azure Firewall policy. Associating an Azure Firewall policy to an Azure Firewall instance. Updating Azure Firewall Threat Intelligence mode. Creating Rule Collections for Network and Application Rules. Listing our created resources. Azure Firewall REST API offers a wide range of configuration and management capabilities beyond these tasks. The steps covered in this section represent just a subset of the available operations that can be performed programmatically, enabling automation and streamlined management of firewall resources. To get us started, we need to have a resource group, a virtual network and a public IP address for the firewall to be created. The resource group has been created with the help of API, as shown below: To create the Virtual Network and the Firewall public IP address, we have utilized the portal as shown below: Creating a new Azure Firewall instance: The following are the parameters required for Azure Firewall instance via REST API: By using the PUT command and request body, we can create a firewall instance as shown below: Method URL PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/azureFirewalls/{azureFirewallName}?api-version=2024-05-01 As we can confirm on the portal, that the firewall has now been created Creating a new Azure Firewall policy: The following are the parameters required for Azure Firewall Policy creation via REST API By using the PUT command and request body, we can create a firewall policy as shown below: HTTP Method URL PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/firewallPolicies/{firewallPolicyName}?api-version=2024-05-01 Associating an Azure Firewall policy to an Azure Firewall instance: To associate a Firewall Policy with an Azure Firewall instance, use the following parameters. HTTP Method URL PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/azureFirewalls/{{azureFirewallName}}?api-version=2024-05-01 As we can see below, the firewall policy has now been associated with the firewall AZFW-RestAPI Updating Azure Firewall Threat Intelligence Mode: Updating the threat intelligence mode for your Azure Firewall instance can be done similarly by using the parameters below Method URL PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/firewallPolicies/RestAPI-FirewallPolicy-Standard?api-version=2024-05-01 Creating Rule Collections for Network and Application Rules: To create rule collection groups for network and application rules, use the following parameters. By using the below Put Command we will be able to create Network and Application rule collection groups as shown below: Method URL PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/firewallPolicies/{firewallPolicyName}/ruleCollectionGroups/{ruleCollectionGroupName}? api-version=2024-05-01 Listing Created Resources: To list the resources you've created, you can use the following GET command. When sending a GET request, we no longer require the request body, only the URI parameters to pull the information for the resource we want. HTTP Method URL GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/firewallPolicies/{firewallPolicyName}/ruleCollectionGroups?api-version=2024-05-01 As we can see from the above screenshot, we are able to list the rule collections that we created using the GET command. Similarly, we can use the GET command to list or get details of any created resources using the respective URL. Conclusion: By utilizing the Azure REST API, you can efficiently create, update, and configure Azure Firewall and Firewall Policies, streamlining deployment and management processes. This guide has shown how to set up and manage firewall instances, create policies, rule collection groups, and view resources, ultimately automating and securing your cloud environment with Azure Firewall. References: Azure Firewalls - Create Or Update - REST API (Azure Firewall) | Microsoft Learn Firewall Policies - REST API (Azure Virtual Networks) | Microsoft Learn Getting Started with Azure WAF REST API for Application Gateway: A Step-by-Step Guide | Microsoft Community Hub Getting Started with Azure WAF REST API for Azure Front Door: A Step-by-Step Guide | Microsoft Community Hub Getting Started with Azure DDoS Protection REST API: A Step-by-Step Guide | Microsoft Community HubProtecting the Public IPs of Secured Virtual Hub Azure Firewalls against DDoS Attacks
As discussed previously in the blog post “Fortify Your Azure Firewall: Custom Public IP Configuration on Secured Virtual Hub Deployments”, in the current cloud-focused environment, the management of network security has become increasingly important. Azure Firewall has long been an effective solution for securing virtual networks and virtual hubs, but recent updates have further enhanced its capabilities. The ability to specify your own Azure public IP to be used by your Azure Firewall within an Azure Virtual WAN Secured Virtual Hub, rather than relying on Azure to automatically assign one is a great feature that provides enhanced control over your network's public-facing IPs, enabling alignment with organizational security policies and compliance standards. In this blog, we'll discuss enhancing your secured virtual hub Azure firewall security by configuring Azure DDoS IP Protection for a comprehensive solution. Recap of the key benefits of using specific Public IPs for your Secured Virtual Hub Azure Firewalls Full Control: Gain complete ownership and management over the lifecycle of your firewall's public IP address. This means you can assign, reassign, and retire IP addresses as needed, ensuring that your network infrastructure remains agile and responsive to changing demands. By having full control, you can also implement custom configurations and policies that align with your specific security and operational requirements. Enhanced Security: Strengthen your network's defenses by enabling Distributed Denial of Service (DDoS) mitigation. This advanced security feature helps protect your infrastructure from malicious attacks that aim to overwhelm your network with excessive traffic. By proactively identifying and neutralizing potential threats, DDoS mitigation ensures that your services remain available and secure, providing peace of mind and uninterrupted access for your users. IP Address Flexibility: Enjoy the flexibility of allocating public IP addresses from a predefined IP prefix pool. This allows you to efficiently manage your IP resources, ensuring that you have the right number of addresses available for your current and future needs. With this flexibility, you can easily scale your network, accommodate new devices, and optimize IP address usage, all while maintaining a streamlined and organized IP address management system. How-to enable Azure DDoS IP Protection In this section we’ll configure Azure DDoS Protection to prevent DDoS attacks against the deployment. This is a key benefit that comes with the ability to configure your own public IPs on the Azure Firewall with Secured Virtual Hub. Select any of the public IPs you have associated with the firewall, this should bring you to the Overview blade of that resource. From the Overview blade, select the Protect button under Get Started. This will be how we enable the protection level for the public IP today, since the SKU that can be used for the protection will be Azure DDoS IP Protection, not Azure DDoS Network Protection. Since the virtual network used for the Virtual Hub is a managed virtual network, we cannot use the DDoS Network Protection SKU. You do have the option to enable this level of protection via Azure PowerShell or Azure CLI. From this view, we can see the various ways to configure DDoS protection for a public IP in Azure. As mentioned before, public IPs associated with an Azure Firewall in Secured Virtual Hub must use IP protection. In case you already have a DDoS Protection Plan, you will have the option to link it to the DDoS IP SKU when enabling the IP protection. When a DDoS IP SKU is linked to a plan, you will only be charged by your DDoS Protection Plan, instead of being charged for both. Once DDoS IP Protection is enabled, you can check the following 3 metrics, under the public IP resource, to validate the threshold levels applied to the public IP. Inbound SYN packet to trigger DDoS mitigation Inbound UDP packets to trigger DDoS mitigation Inbound TCP packet to trigger DDoS mitigation This indicates that the Azure DDoS IP Protection is on and protecting the workload behind the public endpoint. Conclusion Configuring specific public IP addresses for your Azure Firewall within a secured virtual hub represents a major leap forward in network security management. This feature not only offers enhanced control over your firewall's public-facing IPs but also significantly bolsters your security posture by incorporating Azure DDoS IP Protection. By utilizing this capability, you can safeguard your firewall against potential DDoS attacks, ensuring a more resilient and secure environment for your applications and services.Fortify Your Azure Firewall: Custom Public IP Configuration on Secured Virtual Hub Deployments
Written in collaboration with davidfrazee and gusmodena. In today's cloud-centric world, managing network security is more critical than ever. Azure Firewall has always been a robust solution for protecting your virtual networks, but recent updates have made it even more powerful. One of the latest enhancements allows you to configure which public IP addresses are used on your Azure Firewall in an Azure Virtual WAN Secured Virtual Hub, rather than having Azure automatically assign one for you. This new feature provides greater control over your network's public-facing IPs, enabling you to align them with your organization's security policies and compliance requirements. Moreover, this capability opens the door to leveraging Azure DDoS IP Protection. By selecting specific public IPs for your firewall, you can ensure that these addresses are shielded from distributed denial-of-service (DDoS) attacks, enhancing the overall security posture of your Azure environment. This integration not only fortifies your defenses but also simplifies the management of your network security infrastructure. In this blog, we will discuss our newly announced feature for Azure Firewall, detailing how to configure public IP addresses from your own subscription and highlighting the benefits of this enhancement. Key Benefits Full control – Own and manage the lifecycle of your firewall’s public IP. Enhanced security – Enable DDoS mitigation for better protection. IP address flexibility – Allocate public IPs from an IP prefix pool. How-To To get started with configuring public IP addresses on your Azure Firewall, you'll need to follow a few straightforward steps. This guide will walk you through the process, ensuring that you can take full advantage of this new feature. By the end of this section, you'll have a clear understanding of how to assign specific public IPs to your firewall, enhancing your control over network security and enabling the integration of Azure DDoS IP Protection. You’ve created an Azure Virtual WAN and now need to deploy secured virtual hubs. A great place to start with building out the environment in the Azure Portal will be in the Azure Firewall Manager. Here you’ll be able to have a centralized management portal to view your Azure Firewalls, firewall policies, Azure DDoS Protection plans, and more. Once you’re in Azure Firewall Manager, select Virtual Hubs to build a new secured virtual hub. Once you’ve configured the basic configurations for the secured virtual hub, you’ll have the option to start creating the Azure Firewall. You’ll notice a new option called Select source of public IP. Here we will select Customer provided (Preview) to define which public IPs will be used for the new secured virtual hub. You’ll have the option to choose a pre-created public IP or to create new from the firewall manager blade. With the secured virtual hub created, we can navigate back to Azure Firewall Manager and manage the new deployment from there. Under Virtual Hubs, select on the Firewall name to manage the public IP addresses. To add more public IPs to your Azure Firewall, you can either create new public IP resources or select from pre-created ones. This feature ensures that Azure won't just assign an IP for you; instead, you have the flexibility to choose or create the specific public IPs that align with your network requirements. This approach provides greater control and customization for your firewall's public-facing IP addresses. Now that we’ve added public IPs to the Azure Firewall, we can configure Azure DDoS Protection to prevent DDoS attacks against the deployment. This is a key benefit that comes with the ability to configure your own public IPs on the Azure Firewall with Secured Virtual Hub. Stay tuned for our next blog post where we’ll go through the steps needed to protect the Public IP associated to your secured virtual hub Azure Firewall. Conclusion The ability to configure specific public IP addresses for your Azure Firewall in a secured virtual hub marks a significant advancement in network security management. This feature not only grants you greater control over your firewall's public-facing IPs but also enhances your security posture by enabling the integration of Azure DDoS IP Protection. As we continue to navigate the complexities of cloud security, features like these empower organizations to tailor their security strategies to meet their unique needs and compliance requirements. Stay tuned for more updates and best practices on optimizing your Azure Firewall and protecting your network infrastructure.A Guide to Azure Data Transfer Pricing
Understanding Azure networking charges is essential for businesses aiming to manage their budgets effectively. Given the complexity of Azure networking pricing, which involves various influencing factors, the goal here is to bring a clearer understanding of the associated data transfer costs by breaking down the pricing models into the following use cases: VM to VM VM to Private Endpoint VM to Internal Standard Load Balancer (ILB) VM to Internet Hybrid connectivity Please note this is a first version, with a second version to follow that will include additional scenarios. Disclaimer: Pricing may change over time, check the public Azure pricing calculator for up-to-date pricing information. Actual pricing may vary depending on agreements, purchase dates, and currency exchange rates. Sign in to the Azure pricing calculator to see pricing based on your current program/offer with Microsoft. 1. VM to VM 1.1. VM to VM, same VNet Data transfer within the same virtual network (VNet) is free of charge. This means that traffic between VMs within the same VNet will not incur any additional costs. Doc. Data transfer across Availability Zones (AZ) is free. Doc. 1.2. VM to VM, across VNet peering Azure VNet peering enables seamless connectivity between two virtual networks, allowing resources in different VNets to communicate with each other as if they were within the same network. When data is transferred between VNets, charges apply for both ingress and egress data. Doc: VM to VM, across VNet peering, same region VM to VM, across Global VNet peering Azure regions are grouped into 3 Zones (distinct from Avaialbility Zones within a specific Azure region). The pricing for Global VNet Peering is based on that geographic structure. Data transfer between VNets in different zones incurs outbound and inbound data transfer rates for the respective zones. When data is transferred from a VNet in Zone 1 to a VNet in Zone 2, outbound data transfer rates for Zone 1 and inbound data transfer rates for Zone 2 will be applicable. Doc. 1.3. VM to VM, through Network Virtual Appliance (NVA) Data transfer through an NVA involves charges for both ingress and egress data, depending on the volume of data processed. When an NVA is in the path, such as for spoke VNet to spoke VNet connectivity via an NVA (firewall...) in the hub VNet, it incurs VM to VM pricing twice. The table above reflects only data transfer charges and does not include NVA/Azure Firewall processing costs. 2. VM to Private Endpoint (PE) Private Endpoint pricing includes charges for the provisioned resource and data transfer costs based on traffic direction. For instance, writing to a Storage Account through a Private Endpoint incurs outbound data charges, while reading incurs inbound data charges. Doc: 2.1. VM to PE, same VNet Since data transfer within a VNet is free, charges are only applied for data processing through the Private Endpoint. Cross-region traffic will incur additional costs if the Storage Account and the Private Endpoint are located in different regions. 2.2. VM to PE, across VNet peering Accessing Private Endpoints from a peered network incurs only Private Link Premium charges, with no peering fees. Doc. VM to PE, across VNet peering, same region VM to PE, across VNet peering, PE region != SA region 2.3. VM to PE, through NVA When an NVA is in the path, such as for spoke VNet to spoke VNet connectivity via a firewall in the hub VNet, it incurs VM to VM charges between the VM and the NVA. However, as per the PE pricing model, there are no charges between the NVA and the PE. The table above reflects only data transfer charges and does not include NVA/Azure Firewall processing costs. 3. VM to Internal Load Balancer (ILB) Azure Standard Load Balancer pricing is based on the number of load balancing rules as well as the volume of data processed. Doc: 3.1. VM to ILB, same VNet Data transfer within the same virtual network (VNet) is free. However, the data processed by the ILB is charged based on its volume and on the number load balancing rules implemented. Only the inbound traffic is processed by the ILB (and charged), the return traffic goes direct from the backend to the source VM (free of charge). 3.2. VM to ILB, across VNet peering In addition to the Load Balancer costs, data transfer charges between VNets apply for both ingress and egress. 3.3. VM to ILB, through NVA When an NVA is in the path, such as for spoke VNet to spoke VNet connectivity via a firewall in the hub VNet, it incurs VM to VM charges between the VM and the NVA and VM to ILB charges between the NVA and the ILB/backend resource. The table above reflects only data transfer charges and does not include NVA/Azure Firewall processing costs. 4. VM to internet 4.1. Data transfer and inter-region pricing model Bandwidth refers to data moving in and out of Azure data centers, as well as data moving between Azure data centers; other transfers are explicitly covered by the Content Delivery Network, ExpressRoute pricing, or Peering. Doc: 4.2. Routing Preference in Azure and internet egress pricing model When creating a public IP in Azure, Azure Routing Preference allows you to choose how your traffic routes between Azure and the Internet. You can select either the Microsoft Global Network or the public internet for routing your traffic. Doc: See how this choice can impact the performance and reliability of network traffic: By selecting a Routing Preference set to Microsoft network, ingress traffic enters the Microsoft network closest to the user, and egress traffic exits the network closest to the user, minimizing travel on the public internet (“Cold Potato” routing). On the contrary, setting the Routing Preference to internet, ingress traffic enters the Microsoft network closest to the hosted service region. Transit ISP networks are used to route traffic, travel on the Microsoft Global Network is minimized (“Hot Potato” routing). Bandwidth pricing for internet egress, Doc: 4.3. VM to internet, direct Data transferred out of Azure to the internet incurs charges, while data transferred into Azure is free of charge. Doc. It is important to note that default outbound access for VMs in Azure will be retired on September 30 2025, migration to an explicit outbound internet connectivity method is recommended. Doc. 4.4. VM to internet, with a public IP Here a standard public IP is explicitly associated to a VM NIC, that incurs additional costs. Like in the previous scenario, data transferred out of Azure to the internet incurs charges, while data transferred into Azure is free of charge. Doc. 4.5. VM to internet, with NAT Gateway In addition to the previous costs, data transfer through a NAT Gateway involves charges for both the data processed and the NAT Gateway itself, Doc: 5. Hybrid connectivity Hybrid connectivity involves connecting on-premises networks to Azure VNets. The pricing model includes charges for data transfer between the on-premises network and Azure, as well as any additional costs for using Network Virtual Appliances (NVAs) or Azure Firewalls in the hub VNet. 5.1. H&S Hybrid connectivity without firewall inspection in the hub For an inbound flow, from the ExpressRoute Gateway to a spoke VNet, VNet peering charges are applied once on the spoke inbound. There are no charges on the hub outbound. For an outbound flow, from a spoke VNet to an ER branch, VNet peering charges are applied once, outbound of the spoke only. There are no charges on the hub inbound. Doc. The table above does not include ExpressRoute connectivity related costs. 5.2. H&S Hybrid connectivity with firewall inspection in the hub Since traffic transits and is inspected via a firewall in the hub VNet (Azure Firewall or 3P firewall NVA), the previous concepts do not apply. “Standard” inter-VNet VM-to-VM charges apply between the FW and the destination VM : inbound and outbound on both directions. Once outbound from the source VNet (Hub or Spoke), once inbound on the destination VNet (Spoke or Hub). The table above reflects only data transfer charges within Azure and does not include NVA/Azure Firewall processing costs nor the costs related to ExpressRoute connectivity. 5.3. H&S Hybrid connectivity via a 3rd party connectivity NVA (SDWAN or IPSec) Standard inter-VNet VM-to-VM charges apply between the NVA and the destination VM: inbound and outbound on both directions, both in the Hub VNet and in the Spoke VNet. 5.4. vWAN scenarios VNet peering is charged only from the point of view of the spoke – see examples and vWAN pricing components. Next steps with cost management To optimize cost management, Azure offers tools for monitoring and analyzing network charges. Azure Cost Management and Billing allows you to track and allocate costs across various services and resources, ensuring transparency and control over your expenses. By leveraging these tools, businesses can gain a deeper understanding of their network costs and make informed decisions to optimize their Azure spending.Enhancing Azure Firewall Management with Change Tracking
Azure Firewall's Change Tracking (Preview) feature is a powerful enhancement that provides administrators with insights into changes made to firewall configurations, particularly Rule Collection Groups. This feature leverages Azure Resource Graph (ARG) to enable efficient monitoring and analysis of changes, improving visibility, accountability, and troubleshooting capabilities. Key Benefits of Change Tracking Enhanced Visibility Monitor modifications to Rule Collection Groups, enabling administrators to track configuration changes in real time. Improved Accountability Identify when changes were made and what changed, addressing compliance and audit requirements. Efficient Troubleshooting Detect unintended changes quickly to resolve issues affecting security or performance. How Azure Resource Graph (ARG) Powers Change Tracking Azure Resource Graph is the backbone of the Change Tracking feature, providing an efficient query and analysis engine designed for large-scale Azure environments. ARG collects metadata and property changes from Azure resources, including Azure Firewall, and enables administrators to query and analyze this data. Key ARG Features for Change Tracking: Scalable Querying: ARG supports querying changes across multiple subscriptions, management groups, or even tenants, ensuring insights are accessible for large environments. Detailed Change Insights: Administrators can query historical data, revealing what property changed and when. Kusto Query Language (KQL): ARG queries use KQL, allowing for flexible filtering, grouping, and analysis. ARG’s recent support for Rule Collection Groups ensures precise tracking of firewall rule changes, such as: Addition or removal of rule collections. Updates to specific rules (e.g., IP ranges, protocols, actions). Reordering of rule collections affecting priority and execution. How to Use Change Tracking with ARG Administrators can use the Azure Resource Graph Explorer in the Azure Portal to execute custom queries. Here’s an example query to retrieve changes in Rule Collection Groups: networkresourcechanges | where properties contains "microsoft.network/firewallpolicies/rulecollectiongroups" | where properties contains "properties.rulecollections" For more readable logs, you can use the following enhanced query: networkresourcechanges | where properties contains "microsoft.network/firewallpolicies/rulecollectiongroups" | extend parsedProperties = parse_json(properties) | extend TargetResource = tostring(parsedProperties.targetResourceId), Timestamp = todatetime(parsedProperties.changeAttributes.timestamp), Changes = todynamic(parsedProperties.changes), ChangeType = tostring(parsedProperties.changeType), PreviousSnapshotId = tostring(parsedProperties.changeAttributes.previousResourceSnapshotId), NewSnapshotId = tostring(parsedProperties.changeAttributes.newResourceSnapshotId), CorrelationId = tostring(parsedProperties.changeAttributes.correlationId), ChangesCount = toint(parsedProperties.changeAttributes.changesCount), TenantId = tostring(tenantId), Location = tostring(location), SubscriptionId = tostring(subscriptionId), ResourceGroup = tostring(resourceGroup), FirewallPolicyName = extract('/firewallPolicies/([^/]+)/', 1, tostring(id)) | mv-expand ChangeKey = bag_keys(Changes) | extend ChangeDetails = todynamic(Changes[tostring(ChangeKey)]) | extend RuleCollectionName = extract('properties\\.ruleCollections\\["([^"]+)"\\]', 1, tostring(ChangeKey)) | where isnotempty(RuleCollectionName) | summarize Changes = make_list(pack("ChangeKey", ChangeKey, "PreviousValue", tostring(ChangeDetails.previousValue), "NewValue", tostring(ChangeDetails.newValue))) by Timestamp = format_datetime(Timestamp, 'yyyy-MM-dd HH:mm:ss'), TenantId, SubscriptionId, ResourceGroup, Location, TargetResource, FirewallPolicyName, RuleCollectionName, ChangeType, PreviousSnapshotId, NewSnapshotId, CorrelationId, ChangesCount | project Timestamp, TenantId, SubscriptionId, ResourceGroup, Location, TargetResource, FirewallPolicyName, RuleCollectionName, ChangeType, PreviousSnapshotId, NewSnapshotId, CorrelationId, ChangesCount, Changes This enhanced query filters changes related to Azure Firewall's Rule Collection Groups, parses and extracts key details like timestamps, change types, and rule collection names, and formats the output for readability. This provides a clear and detailed log of configuration changes, making it easier for administrators to monitor and analyze changes over time. Here is a screenshot showing an example of the output from this query: Real-World Use Cases Change Management Maintain a historical record of configuration changes for audits and compliance. Security Monitoring Detect unauthorized changes to firewall rules, ensuring configurations remain aligned with organizational security policies. Operational Efficiency Quickly identify and resolve issues caused by recent changes to Rule Collection Groups. Conclusion With Change Tracking (Preview), powered by Azure Resource Graph, Azure Firewall becomes a more robust tool for managing and securing your network environment. Administrators gain enhanced control and insight into firewall configurations, improving their ability to maintain compliance, troubleshoot issues, and enforce security policies effectively. Start exploring Change Tracking today using the Azure Resource Graph Explorer and enhance your network security posture.
Azure Firewall has no capacity to maintain source IP on outbound traffic?
Hello all, My use case: To have multiple static public IP addresses attached to Azure Firewall with SNAT rules configured so that the public IP isn't just randomly selected. We have multiple services that have whitelisting configured for specific public load balancer IPs and now we are trying to move them behind Azure Firewall. Since there is whitelisting on the destination, the public IP being randomly selected won't work. My resources: One instance of premium SKU Azure Firewall. Hub and spoke architecture. Route tables being used to force traffic through Firewall (routed to private IP of firewall) The research I have conducted: I have tried absolutely everything I can think of before coming to this forum and from what I can tell the 4 ways of outbound connectivity provided by Azure are: Default outbound connectivity. Against best practice to do this and won't work since its routing through a virtual appliance (firewall) Associate a NAT gateway to a subnet. This won't work since we have only one instance of Azure Firewall and the requirement for multiple public IPs to be used. Assign a public IP to a virtual machine. Not applicable, sitting in backend pool of a load balancer, single public IP to be used for multiple member servers. Using the frontend IP address(es) of a load balancer for outbound via outbound rules. Needs to go through the firewall, impossible unless we can somehow integrate the firewall between the load balancer and the backend pool? Expanding more on the load balancer scenario, I ran across this documentation in Microsoft Learn. This looks great to tackle the asymmetric routing issue, however, we are only interested in maintaining the source IP for outbound traffic, this would again just use the firewalls public IP for outbound traffic and again randomly select it. Consensus: It seems bizarre to me that Azure has no capacity for static SNAT configuration like most firewalls do. I would have thought a large amount of use cases would require this function. Am I missing something? Is there another workaround? Or is Azure just behind the 8ball with networking. Thanks heaps in advance for any help :) Much Appreciated, usernameone101Introducing Copilot in Azure for Networking: Your AI-Powered Azure Networking Assistant
As cloud networking grows in complexity, managing and operating these services efficiently can be tedious and time consuming. That’s where Copilot in Azure for Networking steps in, a generative AI tool that simplifies every aspect of network management, making it easier for network administrators to stay on top of their Azure infrastructure. With Copilot, network professionals can design, deploy, and troubleshoot Azure Networking services using a streamlined, AI-powered approach. A Comprehensive Networking Assistant for Azure We’ve designed Copilot to really feel like an intuitive assistant you can talk to just like a colleague. Copilot understands networking-related questions in simple terms and responds with actionable solutions, drawing from Microsoft’s expansive networking knowledge base and the specifics of your unique Azure environment. Think of Copilot as an all-encompassing AI-Powered Azure Networking Assistant. It acts as: Your Cloud Networking Specialist by quickly answering questions about Azure networking services, providing product guidance, and configuration suggestions. Your Cloud Network Architect by helping you select the right network services, architectures, and patterns to connect, secure, and scale your workloads in Azure. Your Cloud Network Engineer by helping you diagnose and troubleshoot network connectivity issues with step-by-step guidance. One of the most powerful features of Copilot in Azure is its ability to automatically diagnose common networking issues. Misconfigurations, connectivity failures, or degraded performance? Copilot can help with step-by-step guidance to resolve these issues quickly with minimal input and assistance from the user, simply ask questions like ”Why can’t my VM connect to the internet?”. As seen above, upon the user identifying the source and destination, Copilot can automatically discover the connectivity path and analyze the state and status of all the network elements in the path to pinpoint issues such as blocked ports, unhealthy network devices, or misconfigured Network Security Groups (NSGs). Technical Deep Dive: Contextualized Responses with Real-Time Insights When users ask a question on the Azure Portal, it gets sent to the Orchestrator. This step is crucial to generating a deep semantic understanding of the user’s question, reasoning over all Azure resources, and then determining that the question requires Network-specific capabilities to be answered. Copilot then collects contextual information based on what the user is looking at and what they have access to before dispatching the question to the relevant domain-specific plugins. Those plugins then use their service-specific capabilities to answer the user’s question. Copilot may even combine information from multiple plugins to provide responses to complex questions. In the case of questions relevant to Azure Networking services, Copilot uses real-time data from sources like diagnostic APIs, user logs, Azure metrics, Azure Resource Graph etc. all while maintaining complete privacy and security and only accessing what the user can access as defined in Azure Role based Access Control (RBAC) to help generate data-driven insights that help keep your network operating smoothly and securely. This information is then used by Copilot to help answer the user’s question via a variety of techniques including but not limited to Retrieval-Augmented Generation (RAG) and grounding. To learn more about how Copilot works, including our Responsible AI commitments, see Copilot in Azure Technical Deep Dive | Microsoft Community Hub. Summary: Key Benefits, Capabilities and Sample Prompts Copilot boosts efficiency by automating routine tasks and offering targeted answers, which saves network administrators time while troubleshooting, configuring and architecting their environments. Copilot also helps organizations reduce costs by minimizing manual work and catching errors while empowering customers to resolve networking issues on their own with AI-powered insights backed by Azure expertise. Copilot is equipped with powerful skills to assist users with network product information and selection, resource inventory and topology, and troubleshooting. For product information, Copilot can answer questions about Azure Networking products by leveraging published documentation, helping users with questions like “What type of Firewall is best suited for my environment?”. It offers tailored guidance for selecting and planning network architectures, including specific services like Azure Load Balancer and Azure Firewall. This guidance also extends to resilience-related questions like “What more can I do to ensure my app gateway is resilient?” involving services such as Azure Application Gateway and Azure Traffic Manager, among others. When it comes to inventory and topology, Copilot can help with questions like “What is the data path between my VM and the internet?” by mapping network resources, visualizing topologies, and tracking traffic paths, providing users with clear topology maps and connectivity graphs. For troubleshooting questions like “Why can’t I connect to my VM from on prem?”, Copilot analyzes both the control plane and data plane, offering diagnostics at the network and individual service levels. By using on-behalf-of RBAC, Copilot maintains secure, authorized access, ensuring users interact only with resources permitted by their access level. Looking Forward: Future Enhancements This is only the first step we are taking toward bringing interactive, generative-AI powered capabilities to Azure Networking services and as it evolves over time, future releases will introduce advanced capabilities. We also acknowledge that today Copilot in preview works better with certain Azure Networking services, and we will continue to onboard more services to the capabilities we are launching today. Some of the more advanced capabilities we are working on include predictive troubleshooting where Copilot will anticipate potential issues before they impact network performance. Network optimization capabilities that suggest ways to optimize your network for better performance, resilience and reliability alongside enhanced security capabilities providing insights into network security and compliance, helping organizations meet regulatory requirements starting with the integration of Security Copilot attack investigation capabilities for Azure Firewall. Conclusion Copilot in Azure for Networking is intended to enhance the overall Azure experience and help network administrators easily manage their Azure Networking services. By combining AI-driven insights with user-friendly interfaces, it empowers networking professionals and users to plan, deploy, and operate their Azure Network. These capabilities are now in preview, see Azure networking capabilities using Microsoft Copilot in Azure (preview) | Microsoft Learn to learn more and get started.Azure Firewall integration in Security Copilot: protect networks at machine speed with gen AI
Today, at Microsoft Build, we are excited to announce the availability of the Azure Firewall integration in Security Copilot. It helps analysts perform detailed investigations of the malicious traffic intercepted by the IDPS feature of their firewalls across their entire fleet using natural language questions in the Security Copilot portal. Azure Firewall is a cloud-native and intelligent network firewall security service that provides best of breed threat protection for your cloud workloads running in Azure. It's a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. In this blog we will walk through the newly announced Azure Firewall integration in Security Copilot. These capabilities were announced at RSA. Take a look at this blog to learn more about the user journey and value that Copilot can deliver: Bringing generative AI to Azure network security with new Microsoft Copilot integrations. There are four primary capabilities now in preview which are outlined below. Get top IDPS signature hits This capability retrieves the top IDPS signature hits for an Azure Firewall. It helps the user get information about the traffic intercepted by the IDPS feature by simply asking natural language questions instead of the user having to construct KQL queries manually. Get details on an IDPS signature This capability enriches the threat profile of an IDPS signature beyond the information found in logs. It helps the user get additional details about an IDPS signature instead of requiring them to manually source this information. Search across firewalls for an IDPS signature This capability looks for a given IDPS signature across your tenant, subscription or resource group. It helps users perform a fleet-wide search (over any scope) for a threat across all their Firewalls instead of searching for the threat manually. Secure your environment using IDPS This capability generates recommendations to secure your environment using Azure Firewall’s IDPS feature. It helps users get information from documentation about using Azure Firewall’s IDPS feature to secure their environment instead of having to look up this information manually. Get started Learn more in our documentation about these capabilities and how to access them today!
