Create and deploy an Azure App Gateway with Web Application Firewall (WAF) using the Azure CLI (2024)

In this article, I will show you how to create and deploy an Azure app gateway with WAF web application firewall using the Azure CLI.

Azure Web Application Firewall (WAF) on Azure Application Gateway provides centralized protection of your web applications from common exploits and vulnerabilities. Web applications are increasingly targeted by malicious attacks that exploit commonly known vulnerabilities. SQL injection and cross-site scripting are among the most common attack.

This took a bit of poking at to get working with both the Portal and CLI, so if you have tried to deploy this and failed I don't blame you... I have tried to boil this down the minimum required steps for you.

Here are the steps to help you complete this task:

Step 1 - Create and deploy a web app service

Create the resource group:

az group create --name TestResourceGroup --location westus

Create the app service plan:

az appservice plan create -g TestResourceGroup -n TestAppServicePlan --sku B1

Create the web app:

az webapp create -g TestResourceGroup -p TestAppServicePlan -n AppGatewayWAFTestAppService

Step 2 - Create a public IP address and DNS A-Record for the app gateway to use

az network public-ip create --name MyAppGatewayPublicIp \

--resource-group TestResourceGroup \

--sku Standard --dns-name testappgatewaywafv2

Note: SKU WAF_v2 can only reference public ip with Standard SKU.

Step 3 - Create VNET with a designated app gateway subnet

az network vnet create --name TestVNET --resource-group TestResourceGroup \

--address-prefix 10.204.0.0/16 \

--subnet-name AppGatewaySubnet --subnet-prefix 10.204.250.0/24

Step 4 - Create an application gateway with sku WAF_v2

az network application-gateway create --name TestAppGateway \

--resource-group TestResourceGroup \

--vnet-name TestVNET --subnet AppGatewaySubnet \

--min-capacity 0 --max-capacity 2 \

--public-ip-address MyAppGatewayPublicIp \

--private-ip-address 10.204.250.6 \

--http-settings-protocol Http \

--servers appgatewaywaftestappservice.azurewebsites.net \

--sku WAF_v2

Note: Application Gateway with SKU tier WAF_v2 can only use PrivateIPAddress with IpAllocationMethod as Static.

Step 5 - Create a backend health probe

az network application-gateway probe create -g TestResourceGroup \

--gateway-name TestAppGateway \

--name MyProbe --protocol http \

--host AppGatewayWAFTestAppService.azurewebsites.net --path /

Step 6 - Modify the app gateways http-settings

Show the name of the http-settings:

az network application-gateway http-settings list --gateway-name TestAppGateway --resource-group TestResourceGroup | grep name

"name": "appGatewayBackendHttpSettings",

az network application-gateway http-settings update \

--gateway-name TestAppGateway \

--name appGatewayBackendHttpSettings \

--port 80 --resource-group TestResourceGroup \

--enable-probe true --probe MyProbe \

--host-name-from-backend-pool true \

--protocol Http

Step 7 - Enable the WAF and set to detection mode

Find the most recent rule type and version (As of this writing its OWASP 3.1):

az network application-gateway waf-config list-rule-sets

"ruleSetType": "OWASP",

"ruleSetVersion": "3.1",

Then enable the WAF and set it to use the rule set listed above:

az network application-gateway waf-config set --enabled true \

--gateway-name TestAppGateway --resource-group TestResourceGroup \

--firewall-mode Detection \

--rule-set-type OWASP --rule-set-version 3.1

Step 8 - Using the portal verify the resources

We can see that there are now 5 resources in our new RG:

Clicking on the Application Gateway, scroll down to "backend health" on the left hand Settings menu. We can see that the backend health pool is "Healthy".

Selecting the "Web application firewall" from the Settings menu, we can see that the WAF is enabled and in Detection mode.

Note: We did not enable detection logs in this blog post.

Using the DNS A-Record we created for our Application Gateway's public IP, we should be able to pull up the web page of our newly created web app.

Note: This post did not deal with https due to the complexity of adding certificates distracting from the overall purpose.