Now that we have a Web Application Firewall policy applied to our Application Gateway, let's review how we can modify and customize the rule set. As we explore the different rule options for the Web Application Firewall, keep in mind that a single rule may not be enough for an Application Gateway. An Application Gateway can have multiple sites and paths behind it. Each may have a specific policy requirement different from the others. There's no limit to the number of Web Application Firewall policies we can create, and we can apply the policies globally to the Application Gateway at the site hosted by the Application Gateway or apply to specific paths in a site.

For example, say there are two sites behind an Application Gateway, we could create a global policy with a basic set of rules and apply that to the gateway. This policy would apply to all sites hosted by the Application Gateway. Then other policies can be applied to each site with more specific settings related to that site. These are associated with the HTTP listener for the site. We can get even more specific down to the URI of the site with a Per-URI policy applied to the route path. Policies can also be applied to multiple targets. So for example, we can apply the global application gateway policy to each application gateways in the environment. 

Multiple policies and targets are helpful for creating granular security rule settings in an environment, but care should be taken when using multiple policies as they can make the rule sets difficult to read and troubleshoot. There are two types of rules available in a web application policy: managed rules and custom rules. Let's take a look at managed rules next.

As we review managed rules, it's helpful to know the origins of the Core Rule Set, or CRS. The Core Rule Set are rules based on the Open Web Application Security Project, or OWASP. OWASP is a nonprofit foundation with a goal of improving software security. OWASP is a community-driven organization with tens of thousands of members and chapters worldwide. OWASP offers tools and resources, community and networking events, and education and training. OWASP publishes a set of attack definition rules for compatible web application firewalls to protect web-based applications from a wide variety of attacks.

The Core Rule Set is designed to stop web-based attacks while minimizing false positive alerts. The CRS provides protection from many common attack vectors including SQL Injection, Cross Site Scripting, Local File Inclusion, Remote File Inclusion, PHP Code Injection, Java Code Injection, HTTPoxy, Shellshock, Unix and Windows Shell Injection, Session Fixation, Scripting Scanning Bot Detection, and metadata or error leakage. The Azure Web Application Firewall supports CRS 2.29, 3.0, 3.1, and 3.2. CRS 3.1 is the default and supports reduced false positives compared to 3.0 and 2.2.9. CRS 3.2 is currently in preview and has a new engine and rules to defend against Java infections. Managed Core Rule Sets can be modified, allowing for switching between rule sets and disabling specific rules as needed.

There's another managed rule type to be aware of. Microsoft Bot Manager Rule Set or Bot Protection. A bot is an automated process that scans for vulnerabilities in a website. Microsoft estimates that 20% of all internet traffic comes from bad bots. Network bandwidth is not free, and reducing bandwidth by 20% by blocking bad bots is a good investment for Microsoft. Microsoft runs one of the largest networks in the world, and can identify these malicious bots with Microsoft Threat Intelligence.

By enabling Bot Protection, we can block or log requests from IP addresses identified as malicious by the Microsoft Threat Intelligence feed. Enabling Bot Protection secures the site by blocking traffic from malicious bots, it also prevents your application from wasting cycles, responding to invalid requests from these bots.

The second rule type is custom rules. Custom rules, as the name implies, provides the ability to create our own rules that evaluate requests as they pass through the Web Application Firewall. Custom rules have a higher priority over managed rules. A custom rule supports multiple conditions and compounding logic with an and or or statement.

So we can create three conditions, for example, and set the rule to match condition one and two or condition three. If a condition is met, we can set the action to allow or block the request. A custom rule has several required and optional fields. These include a name, that's what appears in the log. A priority, this is a value from one to 100 processed from low to high, this has to be unique across all custom rules, we can't have two rules with the same priority. There's a list of variables to match the rule to. This includes items such as remote address, request method, query string, header and body information, and other variables.

Optionally, we can also include a selector that specifies a field of a match variable. There are several operators we can provide to the rule including IP match, contains, less than, greater than, and others. We can also negate the condition and transform strings before the match attempt with the transform option. The rule requests a list of matched values, a list of values to match against. Each value represents an or condition.

Once the rule condition is met, we can set the rule to allow, block, or log. Allow authorizes the transaction and skips all other rules. Allowed rules aren't evaluated for other custom or managed rules. Block stops the transaction with no further processing of custom or managed rules. The log action writes the transaction to the log file and continues processing other custom and managed rules.

Finally, the last type of custom rule we can configure is a geomatch rule. A geomatch rule is used to allow or deny access based on the source country or region of the transaction request.

Coming up next, we'll walk through linking the Web Application Gateway policy to a second application gateway, configure managed rules, and create custom rules in the policy. To follow along, you will need the Web Application Gateway policy and Application Gateway from the previous demo. A second Web Application Gateway configured similar to the one we previously created. The second Web Application Gateway will not need the servers used as the backend host pool. Also, a computer deployed to a different country or region to test the custom rules. Let's log into the portal and review configuring rule sets for the application gateway.