Azure Front Door and Web Application Firewall - in 10 minutes

We had several scenarios where we considered Azure Front Door (AFD) but one of the most compelling for us at the moment is DDoS protection.

While Azure provides DDoS Standard is a very compelling service. It is applied to public IP addresses associated to resources deployed in virtual networks but comes with pretty steep price tag (3.7K CAD to start as of 2019-07-26) which makes it cost-prohibitive to some clients.

https://docs.microsoft.com/en-us/azure/virtual-network/ddos-protection-overview

Our scenario included public Azure App Services (and API Management) which we usually protect by placing Application Gateways in front on them. Yet after looking at scenarios when Microsoft advises to deploy an Application Gateway behind Front Door it seems reasonable to forego Application Gateways and route traffic from Front Door directly to App Services.

https://docs.microsoft.com/en-us/azure/frontdoor/front-door-faq#when-should-we-deploy-an-application-gateway-behind-front-door

Initial deployment

The deployment of Azure Front Door is a really simple and guided process: just follow the prompts step-by-step.

One of the nice features is the ability to assign an existing custom domain without affecting existing production workload directed to this domain name.

https://docs.microsoft.com/en-us/azure/frontdoor/front-door-custom-domain#map-the-temporary-afdverify-sub-domain

Do not forget to add a rule to route your custom domain requests.

Once custom domain rule has been added in Front Door Designer you should see something like below:

Once custom domain has been enabled the next step is to configure custom domain HTTPS certificate. You can use your own or have AFD provision certificate for you.

It is a really great idea of Microsoft to offer certificate-management service integrated with Azure but so far I find it slow and buggy. For example domain has already been validated when added custom domain to AFD (or Azure CDN) yet the process of generating certificate performs this check again and had to open support request when process of generating certificate seems stuck on domain validation.

Note 1: Based on several experiments it seems to me Front Door-managed certificate provisioning tends to get stuck on domain validation. We had similar problems with Front Door-managed certificates with CDN this leads to suspicion that could be underlying issues with Azure Services-managed certificates overall which hope will be resolved soon but until then it seems using own certificates is a safer option. Please make sure you follow guidelines on adding Front Door to you Key Vault policies like below

Note 2: Overall Front-Door seems to have yet made steps to improve SSL support and overall error-handling. For example

• passwords for pfx are still not supported as of Jun-27-2019 therefore make sure you load your pfx into Azure Key Vault without passwords.

• you may receive cryptic errors like below.

• you may receive following error which is less cryptic but really detrimental to ability to support this service in production when it haunts you for hours and days:

Note 3: Also when back end App Service has custom domains associated with it Azure Front Door seem to choose one of the custom domain names assigned to App Service as both the target and the host header when creating backend pool of "App Service" type. This may not be the desired behavior and therefore seems the best option when yoiu have customk domains is to select "Custom Host" as backend host type even when actual backend is an App Service. Of course this applies only portal configurations.

All goes well you should see that you successfully deployed your certificate and enabled HTTPS for custom domain.

Security

To lock down back end access to allow only Front Door to access App Service please refer to: How do I lock down the access to my backend to only Azure Front Door?

Test

In the test below we see that dig resolves our custom domain to xxx.zurefd.net and curl successfully returns Azure Functions greeting

Web Application Firewall

Since one of the main reasons to use Azure Front Door for us is protection of App Services (including DDOS) below shows example how to configure rule to limit rate of calls from allowed from a single client IP.

First create a new Web Application Firewall.

Configure Policy for prevention and Provide deny response body

Then in "Custom Rules" tab create a custom Rule to allow no more than 10 request per minute from the same IP address.

Add associated frontend host

Once WAF Policy has been saved lets test it by sending multiple requests to the Front Door endpoint.

We can see that after large number of requests is sent we rate limit mechanism has been triggered.

Automation

For automation a PowerShell configuration example provided by Microsoft is below.

https://docs.microsoft.com/en-us/azure/frontdoor/waf-front-door-rate-limit-powershell

Happy Summer Sunday and enjoy Azure Front Door services :)

Limitations, Bugs and Snags

FrontDoor is rather new and still there are some issues before it matures. From what I see so far they do not prevent the use of FrontDoor service but it may be a good idea to keep ability to bypass it in case issues are encountered.

No more than one Front Door with the same custom domain

Got confirmation from Microsoft when you add an already existing frontend endpoint, it should fail. This seems like a limitation as I may need to test different FrontDoor configurations with the same front-end custom domain (in combination with Traffic Manager).

This is a known bug that it does not fail and this leads to other errors if you do create multiple FrontDoor instances.