Azure WAF Policy

Azure Web Application Firewall (WAF) on Azure Application Gateway provides centralized protection to 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 attacks.

Azure WAF is getting better and better since V1 was released back in March 2017 as an additional capability to the Azure Application Gateway. In April 2019, V2 was made public available and WAF policies were released after that which extended the WAF capabilities.

In this post, I will provide some tips on how to fine tune OWASP rules from the WAF perspective and also how to create custom rules, geo-fencing rules to be more specific. I say from the WAF perspective because we are going to disable specific rules which are blocking legit traffic. In an ideal world you would remediate your application so that whatever is in the request doesn't match what is in the rule.

So let's go ahead and create a new WAF Policy with a Custom rule.

Specify the basic details. In this example I will associate the policy with an Application Gateway.

 

Now specify the Policy settings. If you want to block traffic that matches the rule, make sure you set the Mode to Prevention.

Important: Currently the maximum request body size supported is 128KB. Anything larger than that will generate an error 413 Request Entity Too Large. To my knowledge, from the WAF side, the only way to avoid this error is to disable the request body inspection however in my view this defeats the purpose of the WAF. It will still evaluate header and cookie requests though.

In the managed rules section select one of the rule sets. I will select OWASP_3.0 and later in this post I will demonstrate how to fine tune the available rules.

OK so now we got to the custom rules, where we are going to configure geo-fencing. Go ahead and click to Add a custom rule.

Configure the rule like in the figure below. I have set priority 1 so that it is always the first rule to be evaluated. I have also selected Australia and New Zealand as the countries. This rule will deny any traffic which is not coming from an IP Address in Australia or New Zealand.

Now associate the policy with an Application Gateway or HTTP listener and we are done.

You can validate the custom rule is working by checking the App Gateway WAF logs. In the example below we can see the rule was evaluated and it blocked the traffic.

OK now that we are done with the custom rule, let's see how we can fine tune that OWASP 3.0 ruleset. If you expand the ruleset, you will see that all rules are enabled and they have an ID. For example, the rule "Method is not allowed by policy" has an ID 911100.

So what I recommend you do is to place your WAF in detection mode, get an application user to execute common tasks and get the public IP from where the tasks are being executed while you monitor the App Gateway WAF logs.

In the example below, we searched for the public IP address and we found that traffic was getting blocked because it was matching the rule "SQL Comment Sequence Detected" with ruleId 942440.

Now with the ruleId in hand, you can go back to the rule set and disable that specific rule.

In the next example we have 2 more matches.

Continue the process until you don't have any more matches in your logs.

As I said before, in an ideal world you would remediate your application so that it doesn't match any of the OWASP rules but in the real world that is often not possible therefore you have to disable some of the rules so that your application can function correctly while still having protection from the rules which are still enabled.