Quick look at Azure Firewall

When you’ve heard of cloud firewall, it’d be often referred to a back-end hardware based firewall to protect underlying cloud infrastructure from network attack. Azure Firewall is not an exceptional one. First time getting introduced, you’d think it’s kind of magical & intelligent firewall Microsoft is using to protect its huge cloud infrastructure all over the world. In fact, Azure Firewall is not that thought.  Azure Firewall is a managed service offered to customer cloud tenant to help them better control and manage network traffic in a single place.

Today Microsoft announced Azure Firewall being gone through public preview. This article is going to provide a quick look at Azure Firewall. It also gives a guidance on how to set up and test Azure Firewall.

Azure Firewall Overview

Before we have a look at Azure Firewall, let’s quickly look back to what have been available so far for network security:

  • Network Security Group (NSG): you must be familiar with this feature if working with Azure virtual network. NSG is considered a 5-tuple firewall which allows you to control source and destination of network traffic.
  • Application Security Group: this is part of NSG, allowing you to create groups of target virtual machines which share same NSG.
  • User Defined Routing (UDR) allows you to control network routing by forcing them to a monitoring or defensive system. For example, you’d like to route outgoing traffic to a hosted monitoring system. Or suspicious traffic needs to be routed to be inspected to prevent malicious one.
  • Custom hosted firewall: when you are familiar with open-source firewall, building a custom hosted firewall e.g. using iptables, pfSense is a common consideration.
  • Azure DDos protection: by its name, Azure DDos protection helps mitigate largely volumetric network attack against your network.

You may like to read the article about Defending your Azure virtual network with Defense In Depth strategy

Azure Firewall supports two layers:

  • Network: similar to network security group, Azure Firewall allows you to create network security rules to control traffic.
  • Application: when network with IP address is not enough, Azure Firewall allows you to indicate the FQDN (Full Qualified Domain Name). It’s helpful, for instance, for the scenario you’d like to prevent website e.g. Facebook, GitHub or malicious one.

There are two common deployment models:

  1. Dedicated virtual network: when you’d like to build a DMZ where traffics must be gone through this perimeter. The model is often used with hub-spoke model, and requires VPN peering setup.
  2. Existing virtual network: for small deployment which you’d not like to control multiple virtual network and peering. In this model, Azure Firewall is deployed in the same virtual network with target protected virtual machines.

Azure Firewall doesn’t associate with subnet or NIC. Instead, it acts like a network virtual appliance which you may have deployed  (e.g. Barracuda, F5). To use Azure Firewall, you must set up route table and rule to route traffic from virtual machines to your Azure Firewall. Below is sample deployment:

Azure Firewall is not designed to cater end-user website browsing. It would be helpful but it would result inconvenience to end-user if rule collections are not well designed and managed .

Azure Firewall would be best for allowing your hosted virtual machines to be able to communicate back to the Internet for external web services such as Multi-factor Token request, Microsoft Update Center, Red Hat Update Center, GitHub (if that hosted virtual machine is a developer workstation), and also prevent data being pushed to malicious website (aka backdoor prevention)

Enable Azure Firewall Public Preview

Azure Firewall can be only enabled by PowerShell in public preview. You can run the following PowerShell commands to enable Azure Firewall. The first command is to enable application based rule and the second one is for network based rule.

Wait approximately 15-20 minutes and run the following commands to verify the registration

..then run the following command to register Microsoft.Network resource provider again

One the registration is complete, you can start creating a new Azure Firewall resource.

Create Azure Firewall resource

As of this article, only PowerShell and Azure Portal supports Azure Firewall creation.

With PowerShell, you need to install AzureRm.Network  module with version 6.4.0 preview to use AzureRmFirewall  cmdlets. You can either upgrade AzureRm module or uninstall AzureRm.Network  module then install a newer one.

If you have multiple AzureRm.Network modules, you need to import the newest one using Import-Module cmdlet. Once the module is imported succefully, run the following command to verify Azure Firewall PowerShell module

Notes: to list all available parameters for each cmdlet, simply use Get-Member, for example, to list parameters of Get-AzureRmFirewall, use the following command

Before creating an Azure Firewall resource, you need to meet the following pre-requisites

  • A virtual network is available where Azure Firewall is deployed to. Virtual network and Firewall must belong to the same resource group.
  • There must be a subnet named AzureFirewallSubnet. You cannot use a different name. The subnet mask must be at least /25. (Ref)
  • The Public IP must use Standard SKU and must belong to the same resource group as the Azure Firewall resource.

Run the following command to create an Azure Firewall resource with an assumption that virtual network, subnet and a public IP address

Wait until the command is successful and check your newly created Azure Firewall using the following command:

Environment Setup

Before testing Azure Firewall, you need to set up your environment. The setup includes:

  • Two virtual machine deployed in the same virtual network with Azure Firewall.
  • Route table associated to the virtual machine’s subnet. The route table contains a rule to route network traffic from virtual machine to Azure Firewall’s private IP address.

Run the PowerShell script here to provision the lab.

Outbound FQDN Fitering

One of the big challenges today when managing large workplace environment is to prevent employees or developers from accessing non-allowed websites (e.g. Facebook, GitHub) from a hosted workstation. Before Azure Firewall, if you want to achieve the prevention, you need a hosted firewall with somewhat WAF capability.  Now with Azure Firewall, creating a rule to deny a website could not be easier.

Go to the newly created Azure Firewall. Click Rules on the blade then click Add application rule collection.

Name the collection, e.g. blacklist-website. Set priority for the collection. The priority is similar to NSG to identify which collection is more priority. The smaller number, the more priority.

Before testing Deny rules, you need to create an Allow rule to allow all websites, except the two added FQDNs above.

The PowerShell below can be used to create two collections rule for testing purposes:

  • Blacklist collection rule: contains two rules to deny GitHub and Facebook.
  • Whitelist collection rule: contains one rule to allow all FQDNs

Now, remote to your virtual machine and try to access both websites.

For network based rule collection, repeat the same step then see how its goes. Currently there seems to be a bug if you have both Network and Application collection rules working together. I created a network collection rule in which port 80 and 443 were blocked completely. A new application collection rule was created after then where I created some allowed FQDN rules. Doing the test, I still managed to open the allowed websites.

There are notes for application rules:

  • If you want to allow all websites, simply use (*) wildcard in FQDN. And remember not to use “100” in priority in case you also need to use blacklist.
  • If you have an Allow list of websites, then the others are blocked by Azure Firewall with the message: HTTP request blocked by Azure Firewall. No rule matchedProceeding with default action.
  • If you have a website in Deny list, you won’t see the above message when you do the test by browsing it on browser.
  • The priority number would be important if you have both Allow and Deny collections. If Allow collection’s priority number is smaller than the Deny one, rules in Allow collection are applied. And the Deny rule would not make too much sense as Allow means whitelist. The websites which are not in the Allow list will be blocked.
  • The rule also is applicable to a website which has redirection module. For example, if I allow *microsoft.com but the website I open is https://azure.com (we know it redirects to https://azure.microsoft.com), then the rule will still deny https://azure.com until you also add *azure.com in your Allow list.
  • What if I only have a Deny list? It would make sense because by default without any rule, Azure Firewall would drop all until you create an Allow list. The Deny list would only be helpful when you have an Allow list to allow all FQDNs.
  • You can have both Allow and Deny rule for the same FQDN. The priority decides how the rule is effective.
  • Is there a difference between *microsoft.com and microsoft.com ? Yes it is. If you want to cover subdomain/prefix, you need wildcard (*), e.g. *.microsoft.com. *microsoft.com works though.
  • If I want to allow http://google.com/chrome, would *.google.com be enough? The answer is that you can’t add domain with suffix like http://google.com/chrome, even the input supports String. You can only add Host.
  • If my website doesn’t use HTTPs/443, does it matter if I put Https:443 in the rule? No it doesn’t.
  • Deny event should be different from Block one. Deny event occurs when the FQDN is in the Deny list, while Block means the target FQDN doesn’t belong to any collection  in Azure Firewall.

There might be a question regarding the similarity or difference between Azure Firewall and Azure Application Gateway. From the OSI model perspective, Azure Firewall actually partially works at L7 while Application Gateway is fully capable as a a web application firewall. Give you an example of controlling incoming HTTP request, Azure Firewall would only read to the Host information in the HTTP package body and it doesn’t care how parameters are constructed.

…while Application Gateway really cares those constructed parameters and queries which may potentially be malicious.

ARM Template Deployment

Azure Firewall can be constructed in format of ARM and deploy like any resource deployment through Azure RM API. Here is the sample one . Rules can be constructed collaboratively, making security pipeline more effective.

Azure Firewall Monitoring 

Monitoring firewall log is imperative to security operation. Azure Firewall can be monitored by enabling diagnostic log. Similar to other services, you can store log to a storage account, or stream to Event Hub or push to Log Analytics workspace.

You can also enable diagnostic log and send it to Log Analytics workspace by the following PowerShel

There are two log categories: ApplicationFirewallApplicationRule and AzureFirewallNetworkRule. If log is stored in Log Analytics workspace, you can use Log Analytics query languge to query log file, simple as sample below

Or simple one below shows you all Deny logs

Azure Firewall Monitoring should not be different from other resource monitoring. You can always take advantages from Azure Monitoring capabilities to work with Azure Firewall. Log construct would not meet your expectation as Azure Firewall is still under public preview.

For more details on Azure Firewall Monitoring using Log Analytics, read this article.

Limitation 

[Updating]

There is not a limit on the number of application/network rule collection. However, the maximum number of rule is limited to 10,000 for each type.

Pricing

Pricing model of Azure Firewall is based on firewall logical unit and data transfer. Even Azure Firewall is currently under public preview, you are still be charged for $0.625/Hour per logical firewall unit.

If you just test Azure Firewall, make sure to delete it to avoid unexpected charge. Azure Firewall is similar to Application Gateway which cannot be stopped like virtual machine.

Be sure to check updated price information here. Price will be change once Azure Firewall goes GA (general availability)

Conclusion

As of now, what we’ve seen from Azure Firewall is the capability of outbound control, acting like a final gateway before traffics come over to the Internet. It’s too early to say that Azure Firewall is not a firewall. Here below is the list I’d expect to see in Azure Firewall in the future

  • Add existing NSG to Azure Network Rule Collection
  • Add existing application gateway rules to Azure Application Rule Collection
  • Load balancing capability added to make Azure Firewall to be the front gate in DMZ.
  • More PowerShell cmdlet to update or remove network or application rule.
  • Integrate Azure Firewall to Azure Security Center to help security operation personnel better manage in a single place.
  • Integrate with Azure Function or Azure Automation for automation capability (e.g. email notification, incident response…)
  • Visualization map to see which resources Azure Firewall is protecting.
  • Azure Firewall resource ( Microsoft.Network/azureFirewalls ) is supported in Azure Policy for compliance audit

List of references for you:

Comments

  1. Sas Kn
    July 17, 2018 — 7:53 pm

    Very well written, Thuan. You in fact shared a detailed PoC plan 🙂

    • Thuan Soldier
      July 17, 2018 — 11:45 pm

      Thank you Sas KN.Hope it is helpful to you.

Leave a Reply

© 2018 The Soldier of Fortune.