As discussed briefly, WAF can be enabled over your standard ALBs and over your CloudFront distributions. But before we get started with configuring WAF and its various rules and ACLs, we first need to understand some of its commonly used terms and terminologies:

• Conditions: Conditions form the core of your WAF rulesets. These are basically configurable characteristics that you want WAF to monitor in each of your incoming web requests. At the time of writing this book, WAF supports the following list of conditions:
  • IP match: You can use this condition to check whether the incoming web request originated from a specified black/whitelisted IP addresses or not. You can then plot corresponding actions to be performed against the same based on your requirements, such as not allowing any incoming traffic other that the whitelisted IP range, and so on.  AWS WAF supports /8, /16, /24, /32 CIDR blocks for an IPv4 address.
  • String and regex match: A string match or a regex match condition can be used to specify a part of an incoming web request and its corresponding text that you wish to control access to. For example, you can create a match or regex condition that checks the user agent headers and its value against a preset string or expression. If the condition matches, you can opt to either allow or block that particular traffic using WAF rules.
  • SQL injection match: You can use this condition to inspect certain parts of your incoming web requests, such as the URI or query string, for any malicious SQL code. If a pattern matches, you can then opt to block all traffic originating from that particular request's IP range.
  • Cross-site scripting match: Hackers and exploiters can often embed malicious scripts within web requests that can potentially harm your application. You can leverage the cross-site scripting match condition to inspect your incoming request URI or headers for any such scripts or code, and then opt to block the same using WAF rules.
  • Geographic match: You can use this condition to list countries that your web request originated from and accordingly block or allow the same based on your requirements.
  • Size constraint match: You can use the size constraint match condition to check the lengths of specified parts of your incoming web requests, such as the query string or the URI. For example, you can create a simple WAF rule to block all requests which have a query string greater than 100 bytes, and so on.
• Rules: With your conditions defined, the next important aspect of configuring WAF are the rules. Rules basically allow you to combine one or more conditions into a logical statement, which can then be used to either allow, block, or count a particular incoming request. Rules are further classified into two categories:
  • Regular rules: Regular or standard rules, apply one or more conditions to your most recent batch of incoming web requests. For example, a rule to block all incoming traffic from the IP range 40.40.5.0/24 or if there is any SQL-like code in the query string of your request, and so on.
  • Rate-based rules: Rate-based rules are very much like your regular rules apart from one addition: the rate limit. You can now configure conditions and pass a rate limit along them as well. The rule will only trigger if the conditions match or exceed that particular rate limit which was set.

For example, you may configure a simple condition that blocks all incoming traffic from the IP range 40.40.5.0/24 with a rate limit of 10,000. In this case, the rule will only trigger a corresponding action (allow, block, count) if the condition is met and the number of incoming requests in a 5-minute period exceed 10,000 requests. Requests that do not meet both the conditions are simply not compared towards the rate limit and hence will not be blocked by this rule.

• Web ACLs: Once the rules are defined, you combine them into one or more web ACLs. Here, you have the ability to define an action for your rule if it gets triggered; for example, allow, block, count, or even perform a default action that gets triggered in case a request doesn't match any of the conditions or rules specified. Web ACLs work on a priority basis, so the rule listed first is the one that gets compared to the incoming request first. This makes it extremely important to know the order in which you create and assign your rules in a web ACL.

Here is a simple representation of how conditions, rules, and web ACLs work together in WAF:

With the concepts out of the way, let's look at a few simple steps that allow you to set up and configure WAF Web ACLs for safeguarding your web applications.