Custom rules for Web Application Firewall v2

The Azure Application Gateway Web Application Firewall (WAF) v2 comes with a pre-configured, platform-managed ruleset that offers protection from many different types of attacks. These attacks include cross site scripting, SQL injection, and others. If you're a WAF admin, you may want to write you own rules to augment the core rule set (CRS) rules. Your rules can either block or allow requested traffic based on matching criteria.

Custom rules allow you to create your own rules that are evaluated for each request that passes through the WAF. These rules hold a higher priority than the rest of the rules in the managed rule sets. The custom rules contain a rule name, rule priority, and an array of matching conditions. If these conditions are met, an action is taken (to allow or block).

For example, you can block all requests from an IP address in the range 192.168.5.4/24. In this rule, the operator is IPMatch, the matchValues is the IP address range (192.168.5.4/24), and the action is to block the traffic. You also set the rule’s name and priority.

Custom rules support using compounding logic to make more advanced rules that address your security needs. For example, (Condition 1 and Condition 2) or Condition 3). This example means that if Condition 1 and Condition 2 are met, or if Condition 3 is met, the WAF should take the action specified in the custom rule.

Different matching conditions within the same rule are always compounded using and. For example, block traffic from a specific IP address, and only if they’re using a certain browser.

If you want to or two different conditions, the two conditions must be in different rules. For example, block traffic from a specific IP address or block traffic if they’re using a specific browser.

Note

The maximum number of WAF custom rules is 100. For more information about Application Gateway limits, see Azure subscription and service limits, quotas, and constraints.

Regular expressions are also supported in custom rules, just like in the CRS rulesets. For examples of these, see Examples 3 and 5 in Create and use custom web application firewall rules.

Allowing vs. blocking

Allowing and blocking traffic is simple with custom rules. For example, you can block all traffic coming from a range of IP addresses. You can make another rule to allow traffic if the request comes from a specific browser.

To allow something, ensure that the -Action parameter is set to Allow. To block something, ensure that the -Action parameter is set to Block.

$AllowRule = New-AzApplicationGatewayFirewallCustomRule `
   -Name example1 `
   -Priority 2 `
   -RuleType MatchRule `
   -MatchCondition $condition `
   -Action Allow

$BlockRule = New-AzApplicationGatewayFirewallCustomRule `
   -Name example2 `
   -Priority 2 `
   -RuleType MatchRule `
   -MatchCondition $condition `
   -Action Block

The previous $BlockRule maps to the following custom rule in Azure Resource Manager:

"customRules": [
      {
        "name": "blockEvilBot",
        "priority": 2,
        "ruleType": "MatchRule",
        "action": "Block",
        "matchConditions": [
          {
            "matchVariables": [
              {
                "variableName": "RequestHeaders",
                "selector": "User-Agent"
              }
            ],
            "operator": "Contains",
            "negationConditon": false,
            "matchValues": [
              "evilbot"
            ],
            "transforms": [
              "Lowercase"
            ]
          }
        ]
      }
    ], 

This custom rule contains a name, priority, an action, and the array of matching conditions that must be met for the action to take place. For further explanation of these fields, see the following field descriptions. For example custom rules, see Create and use custom web application firewall rules.

Fields for custom rules

Name [optional]

This is the name of the rule. This name appears in the logs.

Priority [required]

  • Determines the order that rules are evaluated in. The lower the value, the earlier the evaluation of the rule. -Must be unique amongst all custom rules. A rule with priority 100 will be evaluated before a rule with priority 200.

Rule type [required]

Currently, must be MatchRule.

Match variable [required]

Must be one of the variables:

  • RemoteAddr – IP Address/hostname of the remote computer connection
  • RequestMethod – HTTP Request method (GET, POST, PUT, DELETE, and so on.)
  • QueryString – Variable in the URI
  • PostArgs – Arguments sent in the POST body
  • RequestUri – URI of the request
  • RequestHeaders – Headers of the request
  • RequestBody – Body of the request
  • RequestCookies – Cookies of the request

Selector [optional]

Describes the field of the matchVariable collection. For example, if the matchVariable is RequestHeaders, the selector could be on the User-Agent header.

Operator [required]

Must be one of the following operators:

  • IPMatch - only used when Match Variable is RemoteAddr
  • Equals – input is the same as the MatchValue
  • Contains
  • LessThan
  • GreaterThan
  • LessThanOrEqual
  • GreaterThanOrEqual
  • BeginsWith
  • EndsWith
  • Regex

Negate condition [optional]

Negates the current condition.

Transform [optional]

A list of strings with names of transformations to do before the match is attempted. These can be the following transformations:

  • Lowercase
  • Trim
  • UrlDecode
  • UrlEncode
  • RemoveNulls
  • HtmlEntityDecode

Match values [required]

List of values to match against, which can be thought of as being OR'ed. For example, it could be IP addresses or other strings. The value format depends on the previous operator.

Action [required]

  • Allow – Authorizes the transaction, skipping all subsequent rules. This means that the specified request is added to the allow list and once matched, the request stops further evaluation and is sent to the backend pool. Rules that are on the allow list aren't evaluated for any further custom rules or managed rules.
  • Block – Blocks the transaction based on SecDefaultAction (detection/prevention mode). Just like the Allow action, once the request is evaluated and added to the block list, evaluation is stopped and the request is blocked. Any request after that meets the same conditions will not be evaluated and will just be blocked.
  • Log – Lets the rule write to the log, but lets the rest of the rules run for evaluation. Subsequent custom rules are evaluated in order of priority, followed by the managed rules.

Next steps

After you learn about custom rules, create your own custom rules.