다음을 통해 공유

Azure: Validate the configuration of your App Gateway for your App Service

  • 아티클

 

Introduction

 When configuring your Azure Web App on Azure you can enable some security features like the Web Application Firewall to mitigate vulnerabilities for your Azure WebApp. Along this article we will review how to properly validate the WAF (Web Application Firewall) for an specific Azure WebApp.  

Azure WAF Protect your application from web vulnerabilities and attacks without modifying backend code. WAF addresses various attack categories including:
SQL injection Cross site scripting Common attacks such as command injection, HTTP request smuggling, HTTP response splitting, and remote file inclusion attack HTTP protocol violations HTTP protocol anomalies Bots, crawlers, and scanners Common application misconfigurations (e.g. Apache, IIS, etc.) HTTP Denial of Service Protect multiple web applications simultaneously. Application Gateway supports hosting up to 20 websites behind a single gateway that can all be protected against web attacks.

So in a few words the Application Gateway provides SSL offloading, end-to-end SSL, a web application firewall (WAF), cookie-based session affinity, URL path-based routing, multisite hosting, and other features.

Scenario

On this specific case we will discuss how to enable WAF capabilities for a single Web application that is not yet inside an ASE (Application Service Environment). Application Gateway includes the WAF capbilities and it is worth to mention that utilize the very well known OWASP ModSecurity Core Rule Set to mitigate potential web vulnerabilities.

 **Although there is an specific Web Application Firewall Service in Preview

Pre-requisites

In order to use the WAF to protect the Azure WebApp: 

  1. The App Service should be moved into a Virtual Network (Vnet)
  2. Create a Subnet for the App Gateway, could be named AppGtwySubnet for reference

Tips to validate the App Gateway configuration for the WebApp: 

 1. Check that the Backend pool is associated to the WebApp and associated to the specific rule: 

Check the Listeners and the HTTP Settings: 

Let´s go and validate the Listener configuration, click on the Listener - in this case the "appGatewayHttpListener". On this setting we will check 2 parameters: 

 1. The Frontend IP configuration: it can be associated to a Private IP or Public IP. The first available address of the chosen Subnet will be assigned as the frontend IP address

**Important: Once allocated, the IP address type (static or dynamic) cannot be changed later.
 
  2. The Frontend Port: Associates the subnet that you previously created to the application gateway and assigns a port to use to access it.

Now check the HTTP Settings: "The application gateway routes traffic to the back-end servers by using the configuration that you specify here. After you create an HTTP setting, you must associate it with one or more request-routing rules."

 Validate the port that is intended to be used for health probe and app traffic.

Ensure that you check the box for Azure App Service and have a custom probe just in case you have a custom probe configured and would like to associate it to this HTTP setting.

Troubleshooting Azure Application Gateway using Cloud Shell/CLI

 

We can use the Azure Cloud Shell Bash / CLI to validate the Application Gateway configuration:

  1. Use CLI to retrieve the list probes with the command below: 
az network application-gateway probe list -g OurResourceGroup --gateway-name OurAppGateway

2. Use CLI to List frontend IP addresses: 

az network application-gateway frontend-ip list -g OurResourceGroup --gateway-name OurAppGateway

With this output you can validate if it was assigned a static or dynamic frontend IP address: 

  1. We can also check if the http settings  with the code below: 
az network application-gateway http-listener show -g ResourceGroup --gateway-name AppGatewayName -n HttpListenerName

Next steps