- [Instructor] In this lecture we'll introduce and explore the AWS Web Application Firewall, or AWS WAF. Following this lecture we will be able to recognize and describe what the Web Application Firewall is, and what the core components of the Web Application Firewall service are. The Web Application Firewall is a managed service that allows you to add another layer of security to your web applications. It protects your applications from common web exploits. It also lets you customize your web security by giving you the ability to control who can have access to your applications, based on a set of rules you define.

Before we go ahead and have a look at the service on the AWS console, let's explore a few concepts first. Firstly, let's make sure we understand what the Web Application Firewall is. The Web Application Firewall sits between a web application and the web client that's requesting content from it. A web application is simply a remote program that is accessed over the Internet. A web client can be a web browser or another application. So why would we want a Web Application Firewall sitting between our web application and a web client requesting something from it?

In short, it's security, and here's why. At a really basic level, the Internet is a public network that enables anonymous web clients to request content from open web applications. So in essence, any web clients using the right protocol, can make a request from any web application. The most common protocol is the hypertext transmission protocol. The HTTP, or HTTPS, of a website address, which is a stateless protocol. In other words, clients don't need to identify who they are to make a request to a website or application.

Unfortunately, this means that some malicious requests to web applications can occur. The AWS Web Application Firewall is a service that helps to prevent websites and web applications from being maliciously attacked by common web attack patterns, such as SQL injection and cross-site scripting. Let me provide a brief explanation of some of the attack patterns I've mentioned, so you have a high-level overview of what they are and what they can do. Let's start with an SQL injection attack. If these are successful, they can alter and read existing data within a database and spoof identities. Some can even perform privileged functions on a database, such as a shutdown, which is obviously an administrative level action.

These SQL injection attacks are performed by inserting and SQL query via a client into an entry field to the remote application database where it is then executed. They can cause serious damage, and extract very sensitive information for the attacker, if it's designed to do so. Cross-site scripting is 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, so the client browser has no reason to suspect foul play, and the script is then executed. Cross-site scripting is one of the most common vulnerabilities found in web applications today. A third common attack pattern is the distributed denial of service attack or DDOS. This is where a website or web application receives a huge number of requests in a very short time period, sent maliciously by an attacker, essentially preventing legitimate requests from getting through to the web servers and being processed, whilst at the same time severely hindering the performance of the application or website. So much so, in fact, the users usually think the site is down.

So, these are just a few of the attacks that the Web Application Firewall can help prevent, along with a host of other malicious attempts. The Web Application Firewall helps prevent these types of attacks by monitoring and filtering the requests to and from your web applications. As the underlying AWS service receives requests for your websites, the AWS infrastructure forwards those requests to the Web Application Firewall for inspection against a set of rules you define. Once a request meets a condition defined in your rules, the Web Application Firewall instructs the underlying service to either block or allow the request based on the action you define.

The Web Application Firewall does this by working closely with Amazon CloudFront. Amazon CloudFront is Amazon's content delivery network. When enabled, Amazon CloudFront distributes your content from an origin source to points of presence, or POPs, which are located in various regions around the globe. These points of presence may be in closer proximity to the person requesting the content, thereby speeding up the delivery of that content to the end-user's client or browser. Another benefit of this distributed content network is that it provides an additional layer of security, and the Web Application Firewall works closely with the Amazon CloudFront service.

The Web Application Firewall works with Amazon CloudFront to filter both HTTP and HTTPS traffic by distinguishing between legitimate and harmful inbound requests that will then either be allowed or blocked. Amazon CloudFront supports custom origins, so you can configure the Web Application Firewall to protect sites and applications you don't host in AWS. The Web Application Firewall can also work with other services, such as Amazon Application Load Balancer. The Amazon Application Load Balancer is essentially a listener service that scales up and down to meet and respond to inbound requests from the Internet. The Application Load Balancer will balance the distribution of inbound requests to your back end applications. This provides scalability and security, as the Application Load Balancer can perform SSL termination or offloading, among other features.

The Web Application Firewall acts as an additional intermediary agent. It accepts and filters requests from the application load balancer, deciding whether to pass a request to your back end application based on the rules you've defined. Let's now take a deeper look at what the WAF service is comprised of, to allow us to understand how it works. There are a number of essential components relating to WAF. These being conditions, rules, web access control lists, also known as web ACLs, and the CloudFront service. Let's take a look at 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.

So what are they? Conditions allow you to specify what elements of the incoming HTTP or HTTPS request do you want WAF to be monitoring for. These can be the attack methods we mentioned earlier, both cross-site scripting or SQL injection, or it could be an IP address or IP address range, or the condition could even be the strings from within the header. Once a condition is defined, along with its value, for example the IP address or IP address range involved, then your conditions are set. Rules are combinations of conditions.

You can associate many conditions to be evaluated during the requests and how the conditions will relate with each other. A rule allows you to combine 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 have 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 rules.

This gives you fine-grained control over very specific source targets. An important point to make about the rules is that they are executed in the order that they are listed within WAF. So be careful to architect this order correctly for your rule base. Typically, these are ordered as shown, starting with the white-listed IP, which is set to allow, and then black-listed IPs, which is set to block, and bad signatures, which are also set to block. White-listed IP addresses are a list of IP addresses that are allowed to access the resource. If you're finding a known customer is getting blocked within your rule base that shouldn't be, then you could simply add their IP address to the white list and they would gain access.

Black-listed 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 or cross-site scripting vulnerabilities. When an incoming HTTP request comes into WAF, it will be matched against a rule base in the order that they appear. As soon as a 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. Rules are then added to web access control lists. These form the final package for the decision process as to whether the traffic is blocked or allowed on through to the associated CloudFront distribution. Within the web ACL, an action is applied to each rule. These actions can be either allow, block or count.

When a request is allowed, this is forwarded on to the associated CloudFront distribution. When a request is blocked the request gets 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 good option to select when testing new rules, to ensure that the rule is picking up the request 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 with default actions applied, which can be either allow or block. The final part of the WAF service is the association of this web ACL to one of your existing CloudFront distributions.

So let's summarize what we've learned. We've learned that the Web Application Firewall provides a flexible, managed service to protect your websites and applications. The Web Application Firewall works with Amazon CloudFront and other services such as Amazon Application Load Balancer to filter both HTTP and HTTPS traffic, by distinguishing between legitimate and harmful inbound requests, that will either then be allowed or blocked.

When an incoming HTTP request comes into WAF, it will be matched against a rule base in the order that they appear. Conditions allow you to specify what elements of the incoming HTTP or HTTPS request you want WAF to be monitoring for. Rules are combinations of conditions. You can associate many conditions to be evaluated during the requests and how the conditions will relate to each other. That brings us to the end of this lecture.