Azure Application Gateway WAF tuning

The Azure Application Gateway has a Web Application Firewall (WAF) capability that can be enabled on the gateway. The WAF will use the OWASP ModSecurity Core Rule Set 3.0 by default and there is an option to use CRS 2.2.9.

CRS 3.0 offers reduced occurrences of false positives over 2.2.9 by default. However, there may still be times when you need to tune your WAF rule sets to avoid false positives in your site.

Blocked access to the site

The Azure WAF filters all incoming requests to the servers in the backend of the Application Gateway. It uses the ModSecurity Core Rule Sets described above to protect your sites against various items such as code injections, hack attempts, web attacks, bots and mis-configurations.

When the threshold of rules are triggered on the WAF, access is denied to the page and a 403 error is returned. In the below screenshot, we can see that the WAF has blocked access to the site, and when viewing the page in Chrome tools under Network -> Headers we can see that the Status Code is 403 ModSecurity Action


Enable WAF Diagnostics

To be able to view more information on the rules that are being triggered on the WAF you will need to turn on Diagnostic Logs, you do this by adding a diagnostic setting. There are different options for configuring the diagnostic settings but in this example we will direct them to an Azure Storage Account.


Viewing WAF Diagnostic Logs

Now that diagnostic logging is enabled for the WAF to direct to a storage account we can browse to the storage account and view the log files. An easy way to do this is to download the Azure Storage Explorer. You can then use it to browse the storage account and you will see 3 containers that are used for the Application Gateway logging.

  • insights-logs-applicationgatewayaccesslog
  • insights-logs-applicationgatewayfirewalllog
  • insights-logs-applicationgatewayperformancelog

The container that we are interested in for the WAF logs is the insights-logs-applicationgatewayfirewalllog container.

Navigate through the container until you find the PT1H.json file. This is the hourly log of firewall actions on the WAF. Double click on the file and it will open in the application set to view json files.


Each entry in the WAF will include a information about the request and why it was triggered such as the ruleID, Message details. In the below sample log there are 2 highlighted entries.

The message details for the first highlighted log indicate the following “Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score.“.

So we can see that when the anomaly threshold of 5 was reached the WAF triggered the 403 ModSecurity action that we initially saw from the browser when trying to access the site. It is also important to notice that this particular rule cannot be disabled, and it indicates that it is an accumulation of rules being triggered.

The second rule indicates that a file with extension .axd is being blocked by a policy.


Tuning WAF policy rules

Each of the WAF log entries that are captured should be carefully reviewed to determine if they are valid threats. If after reviewing the logs you are able to determine that the entry is a false positive or the log captures something that is not considered a risk you have the option to tune the rules that will be enforced.

From the Web Application Firewall section within the Application Gateway you have the following options:

  • Enable or Disable the WAF
  • Configure Detection or Prevention modes for the WAF
  • Select rule set to use
  • Customize rule configuration

In the example above, if we were to decide that the .axd file extension is valid and allowed for the site we could search for the ruleID 9420440 and un-select it.

Once the number of rules being triggered reduces below the inbound threshold amount the 403 ModSecurity Action will no longer prevent access to the site.

For new implementations or during testing you could apply the Detection mode only and view and fine tune the WAF prior to enabling for production use.


Azure Application Security Groups

Azure Application Security Groups (ASG) are a new feature, currently in Preview, that allows for configuring network security using an application-centric approach within Network Security Groups (NSG). This approach allows for the grouping of Virtual Machines logicaly, irrespective of their IP address or subnet assignment within a VNet.

They work by assigning the network interfaces of virtual machines, as members of the ASG. ASGs are then used within NSGs as either a source or destination of a rule, and this provides additional options and flexibility for controlling network flows of resources within a subnet.

The following requirements apply to the creation and use of ASGs:

  • All network interfaces used in an ASG must be within the same VNet
  • If ASGs are used in the source and destination, they must be within the same VNet

The following scenario demonstrates a use case where ASGs may be useful. In the below diagram, there are 2 sets of VMs within a single subnet. The blue set of VMs require outbound connectivity on TCP port 443, while the green set of VMs require outbound connectivity on TCP port 1433.

As each VM is within the same subnet, to achieve this with traditional NSG rules would require that each IP address be added to a relevant rule that allows the required connectivity. For example:


As virtual machines are added, removed or updated the management overhead that is required to maintain the NSG may become quite considerable. This is where ASGs come in to play to simplify the NSG rule creation, and continued maintenance of the rule. Instead of defining IP prefixes, you create an ASG and use the it within the NSG rule. The Azure platform takes care of the rest by determining the IPs that are covered within the ASG.

As network interfaces of VMs are added to the ASG, the effective network security rules are applied without the need to update the NSG rule itself.


The following steps will demonstrate this process using 2 virtual machines.

Enable Preview Feature

ASGs are currently in preview and the feature must be enabled. At present these are only available within US West Central.

Check the status of the registration, and wait for the RegistrationState to change to Registered.

Create Application Security Groups

We will create 2 application security groups

  • WebAsg
  • SqlAsg

Create security rules

In this example, we create rules that use the source as the application security group created in the previous step.

Create Network Security Group

Now that the ASGs are created and the relevant rules scoped to use the ASG as the source, we can create an NSG that uses these rules.

You can verify the rule from PowerShell, using Get-AzureRmNetworkSecurityGroup, and view the SecurityRules section. In there we can see that the reference to the ASG exists in SourceApplicationSecurityGroups:

Assign the NSG to a subnet:

Add network interfaces to ASG

The final step is to add the network interfaces of the VMs to the Application Security Group. The following example updates existing network interfaces to belong to the application security group. As network interfaces are added and removed the traffic flows will be controlled by the security rules applied to the NSG through the use of the ASGs, without further requirement to update the NSG.

You can verify this by viewing the network interface with Get-AzureRmNetworkInterface and checking the IpConfigurations properties. In there we can see the reference to the ASG memberships in ApplicationSecurityGroups.