Azure Web Application Firewall (WAF) is a function of the Azure Application Gateway that detects and prevents exploits and attacks to a web application. Using a WAF we add an additional security layer in front of our application. To have a sneak peak at the most common web application attacks, take a look at the OWASP Top 10 Most Critical Web Application Security Risks .
At my previous posts we have seen how to Protect your Web App using Azure Application Gateway Web Application Firewall and Use Log Analytics to Query the WAF Logs and email those logs to the Admins. At this post I want to share some tips on how to configure the Azure Web Application Firewall.
The Azure Web Application Firewall, like all WAFs, needs a period of detection “the training period”, in order to gather logs about what is logged as blocked so to configure it accordingly before turning the WAF to Prevention mode. The Azure Web Application Firewall uses OWASP ModSecurity Core Rule Set (CRS). You can select version 2.2.9 or version 3.0 of the OWASP ModSecurity Core Rule Set. These rules include protection against attacks such as SQL injection, cross-site scripting attacks, and session hijacks.
The configuration of the Azure Web Application Firewall has two parts. One part is the OWASP rules custom configuration, where we can check / uncheck the OWASP rules that the WAF will use to analyse the requests:
and the second part is the Exclusions and the Request Size Limits:
Let’s see how we can find out what to exclude and what to customize. Once you setup the Azure Application Gateway and Publish your web application turn of the Firewall in Detection mode. Enable the Diagnostic Logs and send the logs to Log Analytics and start using the we application. I have covered all those steps at my previous posts, Protect your Web App using Azure Application Gateway Web Application Firewall and Use Log Analytics to Query the WAF Logs and email those logs to the Admins. To make it more fun you can actually attack your application using sample attacks, like SQL Injection samples from this link: https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005) and Cross-site Scripting (XSS) from this link: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) . Both links are from OWASP for testing.
After a while run the query to check the Azure Web Application Firewall logs:
AzureDiagnostics | where Resource == "PROWAF" and OperationName == "ApplicationGatewayFirewall" | where TimeGenerated &gt; ago(24h) | summarize count() by TimeGenerated, clientIp_s , TimeGenerated , ruleId_s , Message , details_message_s , requestUri_s, details_file_s , hostname_s
You will get the below results:
At the Message part of the Log you will see the kind of attack that the WAF has detected.
At the ruleId_s you can find the OWASP rule ID. With this information you can search the Rule ID at the Advanced rule configuration and uncheck the specific rule. Of course every rule you uncheck you open a security hole. So I recommend to first check if you can alter your application to comply with the rule and only if this is not possible to drop the rule.
At the details_message_s column also you can find the matched pattern and configure the Exclusions
Finally you can configure the request size limits according to your application
Once you finalize your Azure Application Firewall configuration and you no longer have “Blocked” messages change it to “Prevention” mode to start protecting your web application.
WAF Overview: https://docs.microsoft.com/en-us/azure/application-gateway/waf-overview
WAF Configuration: https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-waf-configuration
OWASP ModSecurity Core Rule Set (CRS): https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project