Azure Web Application Firewall (WAF) on Azure Application Gateway provides centralized protection for your web applications against common vulnerabilities and exploits. Web applications are increasingly targeted by malicious attacks that vulnerabilities. SQL Injection (SQLi) and Cross-Site Scripting (XSS) are examples of some well-known attacks. Preventing such attacks in application code can be challenging and may require rigorous maintenance, patching, and monitoring at many layers of the application topology. A centralized web application firewall helps make security management much simpler and gives better assurance to application developers and security teams against threats or intrusions.
The Azure Web Application Firewall (WAF) engine is the component that inspects traffic and determines whether a web-request represents a potential attack, then takes appropriate action depending on the configuration. Previously, when you used the Azure WAF with Application Gateway, there were certain limitations in the way you could configure and monitor your WAF deployments. We are happy to announce several enhancements to the configurations and monitoring capabilities of Azure WAF when used with Azure Application Gateway going forward.
We will be discussing the enhancements which Generally Available in the following sections of this blog.
Scale Limit Increases
Azure WAFs running on the next generation WAF engine can now leverage increased scale limits in key configurations covering security and application needs. The increase in scale limits allows organizations to have greater flexibility and to achieve more with fewer deployments in their environment. Increases in features such as WAF exclusions, HTTP listeners, and SSL certificates allow for better security, improved scale, easier deployment, and better management of applications.
For a compressed version of the new changes introduced, you can reference the table below for more information.
200, 100 active listeners
Limited to 100 active listeners that are routing traffic. Active listeners = total number of listeners - listeners not active. If a default configuration inside a routing rule is set to route traffic (for example, it has a listener, a backend pool, and HTTP settings) then that also counts as a listener. For more information, see Frequently asked questions about Application Gateway.
WAF IP address ranges per match condition
1 per HTTP listener
1 per HTTP listener
You can read more about the next generation WAF engine that makes this possible here, and get a full list of the supported scale limits for Application Gateways running WAF here.
The WAF’s new metrics will allow security teams to monitor the total requests, managed rule matches, custom rule matches, and bot protection matches and filter them through a range of dimensions. These dimensions can assist security teams in identifying patterns in attack behaviors by splitting and filtering the metric by policy name, method, and geo-location for example. Sending the metrics to a log analytics workspace allows security teams to ingest this data using Microsoft Sentinel, where you can leverage the data using workbooks, notebooks, and analytic rules. These new metrics also allow for real time alerts to trigger against specified alert logic that you can manage with Azure Monitor.
Reference the table below to see what Metrics are available for Application Gateway WAF v2.
WAF Total Requests
Count of successful requests that WAF engine has served
1Only Bot Manager Rule Set 0.1 will be displayed under “WAF Bot Protection Matches”. Requests matching Bot Manager Rule Set 1.0 will increase “WAF Total Requests” metrics, not “WAF Bot Protection Matches”.
You can read more about all metrics supported by Application Gateway v2 SKU here, and how to create Alert rules on metrics here.
With these new improvements, we hope to better meet the security needs of our customers using Azure WAF. For more information on Azure WAF with Application Gateway, please see the following documentation: