Here we are in the portal in the Web Application Firewall policy created previously. Let's start by associating the policy with another application gateway. Go to Associated Application Gateways. Here you can see our existing application gateway, add an association. Notice we have the option to add an association to the application gateway, HTTP listener and specific path. For example, if we select listener, we can select a second gateway and a listener. Let's cancel out of this and add an application gateway. Select the gateway to associate with and select the box to apply the configuration, click add and Save. This will associate the second application gateway to the Web Application Firewall policy. If you deploy a second application gateway but don't see it, be sure it has the proper SKU. Now we have both application gateways associated with the policy. Any changes in the policy will update on both application gateways.

Let's review Managed Rules next. Go to Manage Rules; under Manage Rule Set, we have the option to select the CRS version we want the policy to use. 3.1 is the default. The option to set it to 3.2, 3.0 or 2.29 is available. Notice we can't select multiple CRS versions. Bot protection is off by default. Let's enable it by selecting the Microsoft Bot Manager Rule Set. Let's scroll down. We have a series of dropdowns for different rules in the rule set. We can see each by clicking expand all. This shows an extensive list of rules in the rules set. We can select any of these rules that gives us the option to disable the rule or enable the rule if it's disabled.

Let's collapse the OWASP rule, and we'll expand the Microsoft Bot Mitigation Rule. This only shows one rule, The Microsoft Manage Known bad Bot Rule. The Microsoft Bot Manager Rule Set is off by default. Now, that we have it selected, let's click Save to apply the configuration. Once the change is complete, let's move on to custom rules. There are no custom rules set. Next, We'll create a geomatch rule that will block all connections from outside the United States.

Let's switch to another Azure VM that was deployed outside the US. Using iplocation.com, we can see that the computers IP is located in Ireland. Let's open up the application gateway page and verify we can access the gateway, that works. Let's create a blocking rule next. Next, we'll go back to the portal, add a custom rule, give it a name BlockOutsideUS for this example; give it a priority, We'll use 10 for this example. Under match type, we'll select Geo location. Change the Match Variable to RemoteAddress. Changing the operation to, is not. Set the country or region to United States.

Notice that we can add multiple countries or regions. Leave the action to deny traffic and click Add. Once complete, Save the changes. Once saved, let's go back to the VM located outside of the United States. And from here, we'll try to access the application gateway again and it still works. Why is that? Let's go back to the web Web Application Firewall policy. Go to overview, notice at the top it indicates the option to switch to prevention mode. When we deployed this policy, we deployed it in detection mode. This will monitor and log the policy, but does not block transactions.

Detection mode is recommended for newly implemented policies to verify actions before blocking transactions. Change the policy to Prevention Mode to enforce the policy action. Once complete, let's go back to the computer outside of the US and try again. Now we get a 403 forbidden message. The connection was blocked. Let's go back to a computer deployed in the US and try connecting to the application gateway, that works. Our custom policy is now blocking connections from outside of the US.

Let's go back to the portal and add a second rule. We're back on a computer located in the United States. This rule will apply specifically to this computer's public IP address and block the connection, if the web browser is anything other than Chrome. We to get the computer's public IP address. There are several ways to do this. We can open up another and go to iplocations.com. If the computer is an Azure VM, you can also find the public IP address in the portal. Save the IP address, we'll need that shortly. Back at the new rule, Let's give it a name, ChromeOnly for this example. Give it a priority of 15. This rule is processed after the previous one we created. Set the match type to IP address, does contain, and add the IP address for the computer we're testing. Scroll down and add a new condition, set the Match type to String. Change the Match variable to Request Headers. Set the header name to User-Agent. This specifies the request header field. We have the option to add another match variable if needed. Change the operation to, is not. Set the transformation to lower case, and set the Match value to Chrome. With this rule, if a request comes from the computer's IP address and the request header does not equal Chrome, traffic is denied.

Let's Add the rule and Save. The rule finished saving. Let's try to open the website from the computer with a public IP address we specified in the rule using Internet Explorer. Here we are an Internet Explorer and it's letting us know that we should use Edge, but we'll use Internet Explorer for this example. In here, we get the 403 forbidden. Next, let's go to Chrome or Edge, since the new Edge browser uses the Chrome engine, we'll go to our gateway IP, and that works successfully. That is how to configure manage rules, and two examples of creating customers in the Web Application Firewall policy.