How To – Enable Web Application Firewall Geomatch Custom Rules

At the end of July, Microsoft announced the general availability of geomatching via Custom Rules in Web Application Firewall. This is a feature I am quite fond of, and is excellent at reducing your attack surface. Thankfully, it’s also quite simple to implement!

First, what is Web Application Firewall (WAF)? Well it’s a service that provides protection for your web apps from common exploits and vulnerabilities. It can be deployed with Azure Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDNN is preview for now). WAF allows for central management, meaning you can react to threats faster, instead of securing each individual web application. There are a couple of specific differences depending on the service you attach a WAF policy to, and you can read about them here.

WAF overview
Nice graphical explainer of WAF from Microsoft

Next, what are Custom Rules? As part of each WAF policy, you have to configure a set of standard rules, such as Prevention or Detection mode, and managed rules (OWASP). However, you can also create your own rules, and in WAF these are simply called Custom Rules (CR). A CR is made up of one or more conditions followed by an action. All CRs for a WAF policy are match rules. You can have multiple CRs per policy and they are processed in order of priority in a range of 1-100, with 1 being highest priority, or processed earliest.

Now that we have the foundation, let’s look at the geomatch option. This is available within your CR as a match Condition.

Create your CR with an appropriate name and priority, then choose ‘Geo location’ from the Match type drop down as above. Next, you’ll want to ensure you choose RemoteAddr as the match variable, and decide what logic you want to apply. By logic I mean the pattern that will fire the rule. In this example, I want all traffic except Ireland blocked. So I will choose the Operation ‘Is not’, then location Ireland, then Deny. If I wanted all traffic allowed and Ireland blocked, I would simply choose the Operation ‘Is’. I recommend figuring out your pattern then working your way through the final section of the CR.

So, based on my example with Ireland, my CR now looks like this:

Now most commonly, I would see a geomatch policy applied to an Application Gateway, but it can be applied to Front Door also. On of the nice features of a WAF policy when using it with Application Gateway is that you get association choices. This means you can be as granular as having different policies per listener, or even per path rule. Giving you huge flexibility when combined with CRs.

Finally, I have obviously shown you how to create this CR in the portal, but there are other methods, like Powershell. These can be very handy if you need to recreate a geomatch CR, especially if you have multiple conditions with many countries (there is a max of 10 per condition). Note, if using these methods, you need to use country codes, like IE, and these are all listed here.

And that’s it! You have your CR created and associated. WAFs take effect pretty quickly so you should be able to test within a couple of minutes. If you want to perform a simple verify, you can switch the action from Deny traffic to Allow and retest.

Finally, a nice tip when you’re happy with your configuration is to setup an alert against your WAF should there be a change made, or worse, deleted (apply resource locks people). This runs as a signal alert from Azure Monitor against an action group as per standard

That’s it for this post, as always, if you have any questions, please get in touch!

Global Azure Virtual 2020

As a result of the current global health crisis, the Global Azure events have moved entirely online. Spread over three days (23rd-25th April) it promises to be an amazing mix of content from contributors from all corners of the world.

In the UK & Ireland, we have a local event. Organised by a great team, all of the details are here – https://azureglobalbootcamp2020.azurewebsites.net/

There is a mix of live, and pre-recorded sessions with a wide range of topics.

I’ve contributed a session myself, pre-recorded, on Azure Foundations. If anyone you know is looking to make a start on Azure, have them check it out! #GlobalAzureVirtual

How to – Use Azure Firewall IP Groups

If you’re familiar with Azure Firewall you would know that the introduction of an IP Group resource is most welcome. IP Groups are still in preview at the moment, so as usual be cautious on production environments as there is no SLA. However, it’s always nice to try out a service to see if it can work for you, or make your life easier.

IP Groups themselves are a relatively simple resource. They can contain a single IP address, multiple IP addresses, or one or more IP address ranges. They can then be used for DNAT, Network, or Application rules in Azure Firewall.

They currently have some interesting limitations that are a little bit confusing at first. From Docs:

For 50 IP Groups or less, you can have a maximum of 5000 individual IP addresses each per firewall instance. For 51 to 100 IP Groups, you can have 500 individual IP address each per firewall instance.

What this means is that while your rules should already be scoped accurately, you may need to use a couple of extra IP groups if you’re working with large address ranges. A simple example is a /16 will simply not work in an IP Group, /20 is basically your limit per IP Group.

I actually tried this on my own sub and it appears to actually work for now. Expect that to change as preview progresses.

If you’ve worked with Azure Firewall, I’m sure you’ve already thought of several places these rules can really help. For me, it was within Network Rule Collections.

However, as the service is in preview, there are a few aspects to be ironed out. Unfortunately, one of those is the ability to add an IP Group as a destination within a network rule when using the Portal. See below

UPDATE: As expected, this is now resolved! However, read on to see how to do this at scale.

At this point, I am going to flag extreme caution if your Azure Firewall is in production and you are trying this. It is very easy to overwrite all of your collections, take your time and export them before making any changes!

I’m a Windows guy, so I’m going to explain how to do this with Powershell, but it also works for CLI. Similarly, I’m showing a Network Rule, same process works for Application Rules.

First up, you need to all of the details for your Azure Firewall as we will work with it’s config as a variable and finally update it.

#Get the AFW I want to edit
$afw = Get-AzFirewall -Name wda-afw-test -ResourceGroupName rg-wda-afw

#Save current Network Rule Collection to a variable for reference
$oldcol = $afw.NetworkRuleCollections

#Get the IP Group I want to use
$ipg = Get-AzIpGroup -Name wda-group1 -ResourceGroupName rg-wda-afw

#Create my new network rule
$newrule = New-AzFirewallNetworkRule -Name "rule2" -Protocol TCP -SourceAddress * -DestinationIpGroup $ipg.Id -DestinationPort 445

Now this is where it can get a bit tricky. Collections are stored as nested arrays. My AFW has two collections, I want to add my new rule to the second one which means I need to reference index 1. See the collections below, the one we’ll be editing is “collection2” which currently only has “rule2”

#view all collections
$afw.NetworkRuleCollections

#view the specific collection rules using place in array
$afw.NetworkRuleCollections[1].Rules | ft

#add my new rule to my collection
$afw.NetworkRuleCollections[1].AddRule($newrule)

#if you like, check it has updated as desired
$afw.NetworkRuleCollections[1].Rules | ft

#If as expected, update AFW
Set-AzFirewall -AzureFirewall $afw

The last command can take a minute or two to complete. Once it has, you can see the rule is now added to my collection2. The Portal will display it correctly, but you cannot edit correctly with the glitch.

And that’s it! You’ve successfully added an IP Group as a destination to your Azure Firewall. Again, please be careful, the above is only a guide and I cannot be responsible for your Azure Firewall 🙂

Azure Private Link – Where to Start?

Last week, Microsoft announced that the majority of Private Link is now GA. This means it’s now supported for production workloads, however, is it useful for your production workloads? Hopefully this post will help you understand the service a bit more, and whether it’s worth investing your time in exploring.

First up, what exactly is Azure Private Link (APL)? Well, it allows you to access Azure resources using a private endpoint in a virtual network. There are two possible component within APL.

  • Private Endpoint
  • Private Link Service

A Private Endpoint is a private IP that exists within your vnet and presents a service via APL. Traffic targeting a service via APL travels via the Azure backbone, removing the need for public access if it’s not required. The service could be Azure PaaS, or a service presented by yourself, or a Partner via Private Link Service.

A Private Link Service leverages Azure Standard Load Balancer frontend IP configuration to present as a service, for use by a Private Endpoint. The workload behind ALB could be your own, or a vendors.

Below is a somewhat complex diagram explaining this visually, from Microsoft

Private endpoint overview

So, let’s try break that down into simpler concepts.

First, it allows you to access PaaS services without the need to implement a Microsoft Peering for ExpressRoute. Which gives you greater flexibility as well as a simpler footprint should you have VPN connectivity.

APL maps to single instances of resources, rather than whole services, so you have a more direct and therefore secure connectivity footprint. For example, allow connections to an Azure SQL instance, rather than all Azure SQL instances. This is also relative to vendors providing a service, you can connect to just their presented endpoint rather than a broader or more complex connection.

All of the above can be done across regions and across Azure AD tenants, so if you are providing a service, you can offer it via APL at a global scale.

A lot of Azure PaaS is GA, but there are still quite a few in Preview, so be wary of your production requirements, a full list is here – https://docs.microsoft.com/en-us/azure/private-link/private-link-overview#availability

So what might an APL deployment look like in your environment? Below, I’ve put together a quick example from my own tenant. I have a very simple website, running from a Storage Account and I have a test VM I will RDP to to load the site.

I created an APL, connected it to the SA, which automatically makes a couple of changes and auto-approves the connection within the SA. So now, when I lookup the corresponding endpoint, it shows as a private IP within my vnet (10.55.1.5), and I can browse to it successfully (cert error is expected due to lack of DNS here).

Within APL, I can check the status of my Private Endpoint, which confirms settings as expected.

And on the SA itself, I can see that a Private Endpoint has been activated.

So all of the above seems quite simple and very usable. But there are some current limitations to be aware of.

For Private Endpoint, NSGs are not supported. While subnets containing the private endpoint can have NSG associated with it, the rules will not be effective on traffic processed by the private endpoint. When you create a Private Endpoint via the Portal, it automatically makes a switch to the subnet to disable network policies. Other deployment methods require a manual change, documented here – https://docs.microsoft.com/en-us/azure/private-link/disable-private-endpoint-network-policy

For Private Link Service, it must be a Standard ALB, only IPv4 and only TCP traffic. The above note about subnets and network policies is also valid, documented here – https://docs.microsoft.com/en-us/azure/private-link/disable-private-link-service-network-policy

Overall I think APL is a great addition to the network offerings and more closely aligns what Operations teams like to be able to control when working with PaaS. The options it introduces for vendors could also see some clever solutions brought to market, especially with the supported global capability.

As always, if there are any questions, get in touch!

How to – Enable Alerts for Azure ExpressRoute

Azure ExpressRoute is Microsoft’s recommended method of accessing resources in Azure over a private connection. It is unique to the platform and can offer unparalleled resilience and performance. It also has the capability to allow you connect to Azure Public Resources, such as Storage Accounts, Azure SQL, over the same circuit and therefore, private connection.

With the above being possible, it’s clear that ExpressRoute, once implemented, becomes the key resource in your environment. As such, you would be wise to implement some level of monitoring and alerting for it.

Here, I’m going to show you how to very quickly put in place alerts should either of the required BGP sessions drop for your ExpressRoute circuit.

To add some context to that, each ExpressRoute circuit requires a pair of BGP sessions to meet SLA requirements. They will function with just one, but that’s not fully supported and definitely not recommended! So, presuming you have both active, we’ll base our alert off of that metric. We’re going to look specifically at Private Peering as it’s the most common implementation, but the logic is identical for Microsoft Peering.

If both are active and configured correctly, you should see the same routes being advertised within the circuit if you check your route table from the Peering blade

Next, let’s look at the Metric we will be using for the alert. In your ExpressRoute Circuit blade, choose Metrics. Then we’ll choose the ‘BGP Availability’ Metric and ensure Aggregation is ‘Avg’

Next, to future proof the alert, or if you have a Microsoft Peering, we’re going to apply some filtering. So choose ‘Add filter’ (highlighted above). Then we’re going to select the ‘Peering Type’ Property, and choose ‘private’ from the Values drop down and click the tiny blue tick to the right (You won’t see Microsoft if you don’t have one, but do this anyway to ensure your alert is tightly scoped).

Now, we’re looking at the average BGP availability, for our Private Peering only.

To make life easier, you can now just click ‘New Alert Rule’ on the top right to use this scoped metric for your alert.

This applies the right resource scope and brings the metric across too, you now just have to configure some of the required choices on specifics.

First up, let’s confirm the condition and signal logic. Click on the blue text under Condition. You will see Private is already selected for you. I’m going to change Operator to ‘less than or equal to’ and add a value of 95.

The above settings mean that the BGP Availability metric for my private peering, over the last 5 minutes, will be assessed every minute. Should it drop below or equal to 95%, an alert will fire. You can adjust this as needed to suit your own environment.

Now, we need to define what happens when they alert fires. Click Done on the signal logic pop out, this will bring you back to the alert configuration blade.

I would recommend you create and use an Action Group, even something simple like a distribution group to email. More on Action Groups – https://docs.microsoft.com/en-us/azure/azure-monitor/platform/action-groups

Next, define the final details for the alert. Use a descriptive name and the appropriate severity for your environment/system.

Now, the alert itself can take some time to become fully active, so I would recommend waiting about thirty minutes before attempting a test. But, please ensure you test the alert!

And that’s it. Once tested, you have now setup a fully scoped alert rule for your ExpressRoute Private Peering. You can repeat the above, and change the scope to Microsoft Peering to cover that too if you have it.

As always, if there are any questions, get in touch!