How to – Secure an Application Service with Application Gateway v2

Application Gateway conceptual

Application Gatway v2 brings several welcome additions to the service since it’s initial v1 release. For those who have spent time configuring an Application Gateway, you’ll be glad to hear that udpate/modification times have been drastically reduced. Better performance and the addition of functionality are some of the other main reasons to use v2 over v1. The entire list can be found here.

Recently, I had to secure an Application Service with an Application Gateway v2 on the WAF (web application firewall) tier. This is something I have done several times with v1 without any significant issue. In this instance the Application Service runs on a custom domain as does the Application Gateway. Requirements were to run SSL end to end and have WAF run in prevention mode.

If you’ve ever done this before, you know there are some basics to be completed within your Application Service. For this post and my requirement, they were map a custom domain, runs HTTPS only and prep rules to allow connections only from your Application Gateway. How to do all of that can be found at the following links:

Once your Application Service is ready to go, you move on to configuring your Application Gateway. This is a relatively simple process and can even be completed within the Portal. There is a published guide here. However, once it was configured, I noticed that certain redirect functionality aspects of the application were returning the default host name of the Application Service. This can also happen if you use Azure AD authentication. With WAF in prevention mode, this returns a 403 as a default rule picks up the change in address.

The reason for this is how both Application Gateway and Application Service handle their host headers. To fix this issue, there are two changes you can make, one of which that is only possible on Application Gateway v2.

The v2 only fix is to rewrite the location in the host header using rewrite rules. Rewrite rules are new functionality only included in v2. A guide on what you need to do exactly is here. Make sure the text is exactly as in the guide or it will not work.

The second option, and the one that is more common is to change how your Custom Probe and HTTP settings are configured. The reason for this is that the default guide does not take into account the use of a custom domain on your Application Service. For both settings, modify and remove the ” PickHostNameFromBackendAddress” setting. Now, the Application Gateway will forward the same hostname and redirection will happen on the same too. Full guide here.

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

Azure – Protect My App

If you’ve taken a path to adopt public cloud and part of that adoption is a public facing application, you need to review how you are protecting it within Azure. When your application was on-premises, there was most likely only a single well managed solution to granting external access. In Azure, there are several various solutions available and each carries its own set of functionality and risk.

Rather than try define that entire list, let us look at how best to protect your application, regardless of how you have deployed it. With Azure, these are my three preferred options:

  1. Azure AD Application Proxy
  2. Azure Application Gateway
  3. 3rd Party Network Virtual Appliance

These arguably run from least to most secure. An important tip is to treat each application as unique, because it is. There is not a single best solution for all of your applications and as Azure is a shared model of security it is up to you to protect your data!

Awkward stuff out of the way, let’s look at Application Proxy, we’ve already had a post on setting this up here. The key point with this service is that you do not have your site exposed externally at a network level. Of course, the application itself will be and therefore possibly your server and data, but there is not an open endpoint accepting traffic.

Next is Application Gateway. This is actually a load-balancing solution but you can enable the Web Application Firewall tier easily. This provides protection of your applications from common exploits and vulnerabilities. However, this protection is based on rules from the OWASP core rule set and while it is configurable, this only means you can disable certain rules, not add custom ones. Application Gateway can seamlessly integrate into your environment whether you are running PaaS or IaaS solutions and is economical from a cost perspective. However, that point regarding customisation can often be the deciding factor in choosing our third option instead.

Finally, a 3rd party appliance. Azure offers solutions from the majority of the major providers in this space. Easily deployable from the Azure Marketplace within minutes. Integration options are good but require some work, (See post on routing here) and cost can be a factor to meet required availability levels. But if you need maximum protection and customisation, this is your best option.

Overall, I think there is definitely a solution in Azure that will meet your requirements. Take the time to understand your application, consult with your SMEs and you won’t go wrong!