Hello and welcome to this lecture where I shall give an introduction to the WAF service. The AWS Web Application Firewall is a service that helps to prevent web sites and web applications from being maliciously attacked by common web attack patterns such as SQL injection and cross-site scripting. It is also used to identify how Amazon CloudFront distributions and application load balancers respond to web requests based upon specific conditions. The services work together to filter both HTTP and HTTPS by distinguishing between legitimate and harmful inbound requests that will then either be allowed or blocked with a HTTP 403 error code which is a Forbidden error. For clarity, a web application can be simply defined as a remote program that is accessed over the Internet via a web browser. Let me take a deeper look at what the WAF service is comprised of to allow you to understand how it works. So there are a number of essential components relating to WAF, these being: Conditions, Rules and Web access control lists, also known as Web ACLs. Let me explain each of these individually to see what part they play within the service, starting with the first building block of the configuration, that being Conditions. Conditions allow you to specify what elements of the incoming HTTP or HTTPS request you want WAF to be monitoring for. Currently these are defined as follows: Cross-site scripting. This threat are essentially scripts that have been written to maliciously gain access to client-side data from another user via a web application. This can be data such as stored cookie information and other sensitive client information. These scripts are embedded within web pages that are normally trusted and so the the client browser has no reason to suspect foul play and the script is then executed.

 Cross site scripting is one of the largest vulnerabilities found in web applications today. Geo Match. This function allows you to specify which countries and geographic locations that you would like AWS WAF to filter on. This is a similar function that is provided with Amazon CloudFront. On this point it's important to bear in mind that if you are using the Geo restriction functionality within CloudFront to block a certain country from accessing your web application then the traffic from that country will not reach AWS WAF. If you want to use the Geo Match function within WAF, then you must first disable the Geo restriction settings within your associated CloudFront distribution. IP addresses. Much like the Geo Match setting, this condition allows you to specify a single IP address or a range of IP addresses that you want to either allow or block as you configure the WAF rules. This can be used in conjunction with the Geo Match condition for granular access. For example, you might decide to block all originating requests from a specific country using Geo Match, but then allow specific IP addresses access to your web infrastructure from that country using the IP Address condition. Size constraints. This condition allows you to block traffic based on the size of parts of the request. These parts can include: Header, HTTP Method, Query String, Single query parameter. All query parameters. URI, Uniform Resource Identifier or the Body. 

Once you have decided on which part of the request to define on size you can specify operators to define the size restriction, such as greater than, less than, equals et cetera. The size is then specified in Bytes. SQL injection attacks. If successful, these attacks can alter and read data within a database and spoof identities, some can even perform privileged functions on the database itself, such as a shutdown which is obviously an administrative level action and highly impactful to your service of operation. SQL attacks are performed by inserting a SQL query via a client into an entry field to a remote application database where it is then executed. Depending on the design of the attack it can cause serious damage as well as extract highly sensitive information for the attacker. String and Regex Matching. This allows you to identify web requests based on strings that are contained within the request itself, for example a string within the request header. Again, as applies with other conditions, when we create a web ACL we can select to either allow or block the request based on one of the strings identified. AWS Rules. You then need to add these conditions to a rule. A WAF rule allows you to compile one or more of these conditions into a list which acts as a rule where each condition is ANDed to form the complete rule. For example, if you had three conditions listed within a rule and an incoming request met only two of those conditions it would not be a match to the rule, it would have to meet all three conditions. The request will then continue to be processed by the associated Web ACL to see if it meets any other rule. This gives you fine grained control of very specific source targets. When creating your rule you will be asked to select a Rule Type, a Regular Rule or a Rate-Based Rule. 

The only difference between a rate-based rule and a regular rule is that rate-based rules count the number of requests that are being received from a particular IP address 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 time frame. When the count limit is reached, all other requests from that same IP address is then blocked. If the request rate falls back below the rate limit specified the traffic is then allowed to pass through and is no longer blocked. When setting your rate limit it must be set to a value above 2000. Any request under this limit is considered a Regular Rule. You must also specify if the rule is associated to CloudFront or an application load balancer, and if so, in which region. When it comes to adding your conditions to the rule you must specify some parameters that the condition relates to, so the following options must be made for each request. Your rule is not limited to a single condition, it's possible to add more as you see fit. And again to reiterate, every condition in the rule has to be met for the action of the rule to be carried out. The action associated with the rule is defined in the Web ACL the Access Control List. 

Let's take a look at that component in more detail. So once you've created these rules, they can then be added to Web Access Control Lists or the Web ACL. This forms the final component in the decision process as to whether the request traffic is blocked or allowed on through to the associated CloudFront distribution or application load balancer. Within the Web ACL, an action is applied to each rule, these actions can either be Allow, Block or Count. When a request is allowed, it is forwarded onto the relevant CloudFront distribution or Application Load Balancer. When a request is blocked, the request is terminated there and no further 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. This is a really good option to select when testing the 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 the Web ACL then the request takes the action associated to a default action specified which can either be Allow or Block. An important point to make about these rules is that they are executed in the order that they are listed within a Web ACL. So be careful to architect this order correctly for your rule base, typically these are ordered as shown: Where you have your WhiteListed Ips as Allow. Your BlackListed IP addresses as Block and any Bad Signatures also as Block. WhiteListed IP addresses are a list of IP addresses that are allowed to access the resource. 

If you are 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 explicitly blocked for known reasons. 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 a rule base in the order they appear, as soon as the request matches all the conditions within a rule it will be associated with that rule regardless of if there is another rule further down that would also be a match. So once your WAF Web ACL has been associated, then any request destined for CloudFront or your Application Load Balancer will first be governed by the conditions, rules and Web ACL you configured within WAF, providing an additional security barrier to your web applications. That brings me to the end of this lecture. Next I'll take a look at when and why you should use AWS WAF.