IP Groups in Azure Firewall

• 
  

IP Groups allow you to group and manage IP addresses for Azure Firewall rules in the following ways:

• As a source address in DNAT rules
• As a source or destination address in network rules
• As a source address in application rules

An IP Group can have a single IP address, multiple IP addresses, one or more IP address ranges or addresses and ranges in combination.

IP Groups can be reused in Azure Firewall DNAT, network, and application rules for multiple firewalls across regions and subscriptions in Azure. Group names must be unique. You can configure an IP Group in the Azure portal, Azure CLI, or REST API. A sample template is provided to help you get started.

Sample format

The following IPv4 address format examples are valid to use in IP Groups:

• Single address: 10.0.0.0
• CIDR notation: 10.1.0.0/32
• Address range: 10.2.0.0-10.2.0.31

Create an IP Group

An IP Group can be created using the Azure portal, Azure CLI, or REST API. For more information, see Create an IP Group.

Browse IP Groups

1. In the Azure portal search bar, type IP Groups and select it. You can see the list of the IP Groups, or you can select Add to create a new IP Group.

2. Select an IP Group to open the overview page. You can edit, add, or delete IP addresses or IP Groups.

   

Manage an IP Group

You can see all the IP addresses in the IP Group and the rules or resources that are associated with it. To delete an IP Group, you must first dissociate the IP Group from the resource that is using it.

1. To view or edit the IP addresses, select IP Addresses under Settings on the left pane.
2. To add a single or multiple IP address(es), select Add IP Addresses. This opens the Drag or Browse page for an upload, or you can enter the address manually.
3. Selecting the ellipses (…) to the right to edit or delete IP addresses. To edit or delete multiple IP addresses, select the boxes and select Edit or Delete at the top.
4. Finally, can export the file in the CSV file format.

 Note

If you delete all the IP addresses in an IP Group while it is still in use in a rule, that rule is skipped.

Use an IP Group

You can now select IP Group as a Source type or Destination type for the IP address(es) when you create Azure Firewall DNAT, application, or network rules.

Parallel IP Group updates (preview)

You can now update multiple IP Groups in parallel at the same time. This is particularly useful for administrators who want to make configuration changes more quickly and at scale, especially when making those changes using a dev ops approach (templates, ARM, CLI, and Azure PowerShell).

With this support, you can now:

• Update 20 IP Groups at a time
• Update the firewall and firewall policy during IP Group updates
• Use the same IP Group in parent and child policy
• Update multiple IP Groups referenced by firewall policy or classic firewall simultaneously
• Receive new and improved error messages

  • Fail and succeed states

    For example, if there is an error with one IP Group update out of 20 parallel updates, the other updates proceed, and the errored IP Group fails. In addition, if the IP Group update fails, and the firewall is still healthy, the firewall remains in a Succeeded state. To check if the IP Group update has failed or succeeded, you can view the status on the IP Group resource.

To activate Parallel IP Group support, you can register the feature using either Azure PowerShell or the Azure portal.

It can take several minutes for this to take effect. Once the feature is completely registered, consider performing an update on Azure Firewall for the change to take effect immediately.

Azure portal

1. Navigate to Preview features in the Azure portal.
2. Search and register AzureFirewallParallelIPGroupUpdate.
3. Ensure the feature is enabled.

 

Introduction to Azure Firewall

Microsoft recently announced the availability of a long-awaited service required by the users of systems in the Azure environment , it is the’Azure Firewall. The Azure Firewall is a new managed service and fully integrated into the Microsoft public cloud, that allows you to secure the resources present on the Virtual Networks of Azure. This article will look at the main features of this new service, currently in preview, and it will indicate the procedure to be followed for its activation and configuration.

Figure 1 – Positioning of Azure Firewall in network architecture

The Azure Firewall is a type of firewall stateful, which makes it possible to centrally control, through policy enforcement, network communication streams, all cross subscriptions and cross virtual networks. This service, in the presence of type of network architectures hub-and-spoke, lends itself to be placed in the Hub network, in order to obtain a complete control of the traffic.

The Azure Firewall features, currently available in this phase of public preview, are the following:

• High availability (HA) Built-in: high availability is integrated into the service and are not required specific configurations or add-ons to make it effective. This is definitely an element that distinguishes it compared to third-party solutions that, for the configuration of Network Virtual Appliance (NVA) in HA, typically require the configuration of additional load balancers.
• Unrestricted cloud scalability: Azure Firewall allows you to scale easily to adapt to any change of network streams.
• FQDN filtering: you have the option to restrict outbound HTTP/S traffic towards a specific list of fully qualified domain names (FQDN), with the ability to use wild card characters in the creation of rules.
• Network traffic filtering rules: You can create rules to allow or of deny to filter the network traffic based on the following elements: source IP address, destination IP address, ports and protocols.
• Outbound SNAT support: to the Azure Firewall is assigned a public static IP address, which will be used by outbound traffic (Source Network Address Translation), generated by the resources of the Azure virtual network, allowing easy identification from remote Internet destinations.
• Azure Monitor logging: all events of Azure Firewall can be integrated into Azure Monitor. In the settings of the diagnostic logs you are allowed to enable archiving of logs in a storage account, stream to an Event Hub, or set the sending to a workspace of OMS Log Analytics.

Azure Firewall is currently in a managed public preview, which means that to implement it is necessary to explicitly perform the enable via the PowerShell command Register-AzureRmProviderFeature.

Figure 02 – PowerShell commands for enabling the public preview of Azure Firewall

Feature registration can take up to 30 minutes and you can monitor the status of registration with the following PowerShell commands:

Figure 03 – PowerShell commands to verify the status of enabling Azure Firewall

After registration, you must run the following PowerShell command:

Figure 04 – Registration command of Network Provider

To deploy the Azure Firewall on a specific Virtual Network requires the presence of a subnet called AzureFirewallSubnet, that must be configured with a sunbnet mask at least /25.

Figure 05 – Creation of the subnet AzureFirewallSubnet

To deploy Azure Firewall from the Azure portal, you must select Create a resource, Networking and later See all:

Figure 06 - Search Azure Firewall in Azure resources

Filtering for Firewall will also appear the new resource Azure Firewall:

Figure 07 – Microsoft Firewall resource selection

By starting the creation process you will see the following screen that prompts you to enter the necessary parameters for the deployment:

Figure 08 – Parameters required for the deployment of the Firewall

Figure 09 – Review of selected parameters and confirmation of creation

In order to bring outbound traffic of a given subnet to the firewall you must create a route table that contains a route with the following characteristics:

Figure 10 - Creation of the Rule of traffic forwarding to the Firewall Service

Although Azure Firewall is a managed service, you must specify Virtual appliance as next hop. The address of the next hop will be the private IP of Azure Firewall.

The route table must be associated with the virtual network that you want to control with Azure Firewall.

Figure 11 - Association of the route table to the subnet

At this point, for systems on the subnet that forwards the traffic to the Firewall, is not allowed outgoing traffic, as long as it is not explicitly enabled:

Figure 12 – Try to access blocked website from Azure Firewall

Azure Firewall provides the following types of rules to control outbound traffic.

Figure 13 – The available rule Types

• Application rules: to configure access to specific fully qualified domain names (FQDNs) from a given subnet.

Figure 14 - Creating Application rule to allow access to a specific website

• Network rules: enable the configuration of rules that contain the source address, the protocol, the address and port of destination.

 

Azure Firewall Standard features

• 
  

Azure Firewall Standard is a managed, cloud-based network security service that protects your Azure Virtual Network resources.

Azure Firewall includes the following features:

• Built-in high availability
• Availability Zones
• Unrestricted cloud scalability
• Application FQDN filtering rules
• Network traffic filtering rules
• FQDN tags
• Service tags
• Threat intelligence
• DNS proxy
• Custom DNS
• FQDN in network rules
• Deployment without public IP address in Forced Tunnel Mode
• Outbound SNAT support
• Inbound DNAT support
• Multiple public IP addresses
• Azure Monitor logging
• Forced tunneling
• Web categories
• Certifications

To compare Azure Firewall features for all Firewall SKUs, see Choose the right Azure Firewall SKU to meet your needs.

Built-in high availability

High availability is built in, so no extra load balancers are required and there's nothing you need to configure.

Availability Zones

Azure Firewall can be configured during deployment to span multiple Availability Zones for increased availability. With Availability Zones, your availability increases to 99.99% uptime. For more information, see the Azure Firewall Service Level Agreement (SLA). The 99.99% uptime SLA is offered when two or more Availability Zones are selected.

You can also associate Azure Firewall to a specific zone just for proximity reasons, using the service standard 99.95% SLA.

There's no extra cost for a firewall deployed in more than one Availability Zone. However, there are added costs for inbound and outbound data transfers associated with Availability Zones. For more information, see Bandwidth pricing details.

As the firewall scales, it creates instances in the zones it's in. So, if the firewall is in Zone 1 only, new instances are created in Zone 1. If the firewall is in all three zones, then it creates instances across the three zones as it scales.

Azure Firewall Availability Zones are available in regions that support Availability Zones. For more information, see Regions that support Availability Zones in Azure.

 Note

Availability Zones can only be configured during deployment. You can't configure an existing firewall to include Availability Zones.

For more information about Availability Zones, see Regions and Availability Zones in Azure.

Unrestricted cloud scalability

Azure Firewall can scale out as much as you need to accommodate changing network traffic flows, so you don't need to budget for your peak traffic.

Application FQDN filtering rules

You can limit outbound HTTP/S traffic or Azure SQL traffic to a specified list of fully qualified domain names (FQDN) including wild cards. This feature doesn't require TLS termination.

The following video shows how to create an application rule:

Network traffic filtering rules

You can centrally create allow or deny network filtering rules by source and destination IP address, port, and protocol. Azure Firewall is fully stateful, so it can distinguish legitimate packets for different types of connections. Rules are enforced and logged across multiple subscriptions and virtual networks.

Azure Firewall supports stateful filtering of Layer 3 and Layer 4 network protocols. Layer 3 IP protocols can be filtered by selecting Any protocol in the Network rule and select the wild-card * for the port.