In this lecture, I shall be discussing rules and rule groups within your AWS WAF web ACLs. These rules are used to define inspection criteria that will determine if the web traffic will be allowed or blocked. As a result, they play a fundamental role in making sure your web ACLs are secure and effective. So it's important that you understand them in detail. When you come to build your web ACLs and you have defined the resource that you want it to be associated with, you'll be asked to add a rule or rule group to the web ACL.

As you can see in this screenshot, there were two options. Add manageable groups and add my own rules and rule groups. Let me take a look at each of these in more detail, starting with managed rule groups. So manage role groups are essentially a set of predefined rules that have already been created by AWS and other AWS marketplace sellers for you to use.

At the time of writing this course, I have the following manageable group vendors that appear in the AWS Managed Console. AWS, Cyber Security Cloud, f5, FORTINET, GEOGUARD, imperva and ThreatSTOP. This list will be constantly changing with new vendors. So please review the available manageable groups as and when you need to apply them.

These screenshots here show you a couple of examples from FORTINET and GEOGUARD. As you can see, they provide a set of defined rules that are already configured to monitor and detect anomalies in your web requests against specific vulnerabilities. The example from FORTINET allows you to use a rule group to protect against the OWASP Top 10 vulnerabilities. Whereas the GEOGUARD rule groups contain criteria to help you detect IP fraud using geolocation.

Now, the benefit of using these rule groups is that they have been tried and tested and have been designed to help protect against a specific type of vulnerability or risk. And this can save you a lot of time and effort in trying to recreate the same with your own rules. You may also notice that each rule group also contains a description of the rule group, in addition to the link to subscribe to the rule group, which contains the pricing, reviews and more detailed information.

You may also notice that there is a capacity rating. For FORTINET, the rating is 1,000 and for GEOGUARD, the capacity rating is 100, but what does this mean? Well, for each web ACL, there is a limit of 1,500 capacity units known as WCUs. And these can be used by rules and rule groups. These WCUs are used to control the amount of operating resources that are needed by AWS WAF to run your rules and the inspection criteria set out by those rules.

Now, depending on the rule and its complexity of statements, it will directly relate to and determine how many WCUs will be consumed by that particular rule. So effectively the more intricate the rule is from an inspection perspective, the more WCUs will be consumed. When creating a rule group, you must stipulate an immutable capacity at the time of its creation. This will then set the maximum WCUs that the rules within the group can reach. This is because when you alter the rules within a rule group, it ensures that it doesn't exceed the maximum WCUs of 1500, set out within any web ACLs that are sharing that rule group.

Consider the following scenario. There are two web ACLs, each with a WCU limit of 1500, both sharing a manageable group. Let's call this rule group one. Our web ACLs are configured as shown. If the rule groups did not have an immutable limit and rule group one had its rules changed, which meant the WCU rating changes from 1,000 to 1200 due to additional complexity, then web ACL1 would continue to operate as the total would be 1300 WCUs. However, web ACL2 would fail as the total would change to 1600 WCUs, which exceeds the maximum limit of 1500 for the web ACL. Therefore by ensuring that rule groups have an immutable WCU unit limit set, it would prevent your web ACLs from failing if the rules within the rule group were modified. Any changes to the rule group would have to ensure that the combined rule WCU remained at or below the immutable limit set.

Okay, so now we know what a manageable group is and the benefits that they bring, but let's now go back to looking at creating our own rules and our own rule groups. So custom rules. Let's assume we didn't choose to use manageable groups and instead we wanted to add our own rules. The first thing I need to select is a rule type. So I need to select either IP set, rule builder, or rule group.

The IP set. By selecting IP set, it allows you to configure the rule criteria based upon either the source IP address or the IP address in header. However, before you can select an IP set, you must first create it from outside of the web ACL. To do this, you must select IP sets from the AWS WAF dashboard. From here, you can create an IP set by providing an IP set name, an optional description, a region in which the IP set should exist, or you can split the Global CloudFront Region, the IP version of addresses to be added to the IP set, which can be IPv4 or IPv6, the IP addresses to be attached to the IP set list, And you must add these addresses in a sider format with each entry on a different line. And this allows you to add individual IP addresses or a network range. For example, if using IPv4, then you could add 17.6.7.8/32 to identify a single host address, or something like 107.11.0.0/16 to identify a network range.

Once you have created an IP set, it can then be added within your web ACLs. So jumping back to configuring IP sets in your web ACL. After giving your rule name and selecting your IP set from the dropdown menu, you need to decide if you want to use the source IP address or the IP address in header from the request in your rule. If you decide to configure the IP set on source IP address, then all that remains for you to define is if you want the action of the web ACL that matches the IP source to allow, block or count the request.

When a request is allowed, it is forwarded onto the relevant associated resource, for example, a CloudFront distribution. When a request is blocked, the request is terminated there and no for the processing of that request is taken. A count action will do exactly that. It will count the number of requests that meet the conditions within that rule. So this is a good option to select when testing your rules to ensure that the rule is picking up the requests as expected before setting it to either allow or block.

If an incoming request does not meet any rule within that web ACL, then the request takes the action associated with the default option specified, which can either be, allow or block. If you select the option of the IP address to be based upon the IP address in header, then you must also specify the header field name and how you want to treat missing IP addresses in the header. And then finally, the action required for a match of the rule. Whichever option you choose, source IP address, or IP address in header, then you can enable a custom response to be sent to the requester if the action of block is used. The rule builder.

Let's now take a look at the rule builder option. Here you can create your rules using the rule visual editor, allowing you to create your rule from a series of dropdown menus and options, or you can create your rule statements using the rule JSON builder. If you are experienced with WAF and JSON and are looking to create more complex nested statements within your rule, then the JSON editor is probably the easiest way to do this. By nesting statements, you can implement logic within your rules that allow you to use arguments such as, and, or, and not between the nested statements within your rule.

Okay, let's turn back to the rule visual editor for those who are less familiar with JSON. When building a rule, you first need to give it a name. Next, you need to define the rule type, which can either be regular or rate-based. The only difference between rate-based rules and regular rules is that rate-based rules count the number of requests that are being received based on the source IP address, or the IP address in the header over a time period of five minutes.

When you select a rate-based rule option, and as you can see from the image, you are asked to enter the maximum number of requests from a single IP within a five minute timeframe. When the count limit is reached, the action of the rule is triggered until the request rate falls back below the rate limit specified. This can be used as a temporary block of request from a specific source if they are sending an excessive amount of requests within a short period of time.

It's worth pointing out that the only actions allowed on rate-based rules are either block or count. If you're not looking to monitor the amount of requests from a single source, then simply select a regular rule type. Regular rules are effectively if/then statements. So as you can see, if you need to define a value from the dropdown menu of if a request, then your options, are matches the statement, matches all the statements, matches at least one of the statements, or doesn't match the statement. And these options allow you to implement and build and, or and not statements within your rules.

Depending on the option from this menu will dictate the rest of the options you have within your statement. For example, if you select the matches all the statement, then you will be able to add additional statements to build your rule with a logical and between each statement. When you have finished creating your rule using a single statement or using the logical arguments, then you must define the then part of the rule, which as you are probably familiar with now, are allow, block or count. So here we are allowed to specify an allow action, whereas when we use the rate-based rule, the allow action was not an option. Once your rule has been created, you can see the amount of WCUs that has been assigned to your statement.

Okay, so now we have looked at IP sets, the rule builder. So the last point to look at is adding a rule group to the web ACL. So rule groups. Your rule groups need to be built outside of your web ACL creation. You can't build them on the fly like you can with adding new rules. They are created from the main dashboard menu in your WAF management console. So from here, you can then create your rule groups and each rule group you create can exist in a particular region or the Global CloudFront Region. So bare this in mind when creating your rule groups, that you set the correct location dependent on your use case.

When creating your rule group, you will need to give it a name in addition to a CloudWatch metric name. Now this metric will be created within CloudWatch and allow you to monitor activity relating to the rule group that you've created. It's helpful from a management perspective to keep your CloudWatch metric name the same name as the rule group. You can then create and add your rules as you normally would, and as I previous explained in this lecture, based upon the rule that you create within your rule group, you will be told how many WC Units the rule group currently has.

However, you must also consider future plans for the rule group if you anticipate that you'll add more rules to it going forward. So as a result, you must specify the maximum capacity WCUs for the rule group, as once this option is set, it can't be changed. Once your rule group has been created, this can then be selected from within your web ACL during it's configuration. So rule priority.

I now want to talk to you about rule priority, and this comes up when creating rules within your web ACL and also, when creating your rule groups. During both of their configurations, the web ACL or rule group, you'll be asked to verify the rule priorities of the rules that have been added. And this is an important point as rules are executed in the order that they are listed. So be careful to architect this order correctly for your rule base. Typically, these are ordered as shown.

Firstly, your Whitelisted IPs are allowed, you then have your Blacklisted IPs, which are blocked, and then any Bag signatures, which are also blocked. So Whitelisted IP addresses are a list of IP addresses that are allowed to access the resource. If you're finding that a known customer is getting blocked within your rule base that shouldn't be, then you could simply add their IP address to the Whitelist and they would then gain access.

Blacklisted IP addresses are a list of IP addresses that are explicity blocked for known reasons and Bad signatures would be rules that relate to attack patterns, such as SQL Injections and Cross-Site Scripting vulnerabilities. When an incoming request comes into WAF, it will be matched against the associated rule groups and rules within the web ACL in the order they appear. As soon as the request matches all of your criteria within a rule, the associated action will be carried out for that rule, regardless if there is another rule further down that would also be a match.