Application Gateway with WAF (Layer 7)

Keep the gateway running for both breaks, then clean up.

1Break it: 502 after an app change

The app team moves the web server to port 8080 and tells nobody:

az vm run-command invoke --resource-group rg-saat-l52 --name vm-app1 --command-id RunShellScript --scripts 'systemctl stop web; systemd-run --unit web8080 python3 -m http.server 8080 --directory /srv/www; sleep 2; systemctl is-active web8080' --query "value[0].message" -o tsv
curl.exe -sI http://$agwIp/

After about a minute you should see something like this:

HTTP/1.1 502 Bad Gateway
Server: Microsoft-Azure-Application-Gateway/v2

Ask the gateway why:

az network application-gateway show-backend-health --resource-group rg-saat-l52 --name agw-saat --query "backendAddressPools[0].backendHttpSettingsCollection[0].servers[].{address:address, health:health, log:healthProbeLog}" -o json

You should see something like this:

[
  {
    "address": "10.52.1.4",
    "health": "Unhealthy",
    "log": "Cannot connect to backend server. Check whether any NSG/UDR/Firewall is blocking access to the server. Check if application is running on correct port."
  }
]

502 is the gateway saying “I have no healthy server to send this to”. The backend health log points to the port. On the VM, the app now listens on 8080 while the backend settings still use 80.

Fix it: point the backend settings at the new port, then check health and the site:

az network application-gateway http-settings update --resource-group rg-saat-l52 --gateway-name agw-saat --name appGatewayBackendHttpSettings --port 8080 -o none
az network application-gateway show-backend-health --resource-group rg-saat-l52 --name agw-saat --query "backendAddressPools[0].backendHttpSettingsCollection[0].servers[].{address:address, health:health, log:healthProbeLog}" -o json
curl.exe -s http://$agwIp/

Health shows Healthy and the page says Hello from vm-app1 again.

2Break it: the WAF blocks a real user

A SQL course on your site lets students submit code. A student sends a normal SQL homework answer:

curl.exe -sI "http://$agwIp/submit?code=SELECT+name+FROM+students+UNION+SELECT+name+FROM+teachers"

You should see this:

HTTP/1.1 403 Forbidden
Server: Microsoft-Azure-Application-Gateway/v2

That’s a false positive: the WAF is doing its job, but on this site SQL in the code field is expected. Find which rules fired (allow 5 to 10 minutes for logs):

$ws = az monitor log-analytics workspace show --resource-group rg-saat-core --workspace-name law-saat --query customerId -o tsv
az monitor log-analytics query --workspace $ws --analytics-query "AGWFirewallLogs | where TimeGenerated > ago(30m) and RequestUri has 'submit' | project RuleId, Action, Message | take 10" -o table

You should see something like this (rule numbers can differ):

Action    Message                                          RuleId
--------  -----------------------------------------------  --------
Matched   SQL Injection Attack Detected via libinjection   942100
Matched   Detects MySQL comment-/space-obfuscated ...      942190
Blocked   Mandatory rule. Cannot be disabled. Inbound ...  949110

949110 only adds up the score; the real triggers are the Matched SQLI rules. Don’t switch the whole WAF to Detection. Exclude only the code parameter from only those rules:

Fix it: add a per-rule exclusion with the rule IDs from your log, wait a minute, and retry:

az network application-gateway waf-policy managed-rule exclusion rule-set add --resource-group rg-saat-l52 --policy-name wafp-saat --type Microsoft_DefaultRuleSet --version 2.1 --group-name SQLI --rule-ids 942100 942190 --match-variable RequestArgNames --match-operator Equals --selector code -o none
curl.exe -sI "http://$agwIp/submit?code=SELECT+name+FROM+students+UNION+SELECT+name+FROM+teachers"
curl.exe -sI "http://$agwIp/?q=%3Cscript%3Ealert(1)%3C/script%3E"

You should see something like this:

HTTP/1.0 404 File not found
Server: SimpleHTTP/0.6 Python/3.12.3

HTTP/1.1 403 Forbidden
Server: Microsoft-Azure-Application-Gateway/v2

The homework request now passes the WAF and reaches the VM, which answers 404 because the lab server has no /submit page; in a real app that’s where the form handler runs. The script attack is still blocked, because the exclusion only covers SQLI rules on one field.

3Clean up (the gateway bills by the hour)

Delete the diagnostic setting, then the resource group:

az monitor diagnostic-settings delete --name agw-to-law --resource $agwId
az group delete --name rg-saat-l52 --yes
az resource list --tag lesson=52 -o table

The last command should print nothing.

✅ Checkpoint: You fixed a 502 with backend health and a WAF false positive with a narrow exclusion, and nothing from this lab is left.