AWS WAF Operations
This lecture explains the foundation of WAF by defining its primary function along with the different components that make up the service itself: conditions, rules and web access control lists. Several common attack methods are also discussed, including SQL injections (SQLI), cross-site scripting (XSS) and distributed denial of service (DDoS).
Hello, and welcome to this lecture, where I shall give an introduction to the WAF service.
AWS WAF, web application firewall, was first launched at the annual AWS re:Invent conference in Las Vegas back in October 2015.
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. AWS WAF works closely with AWS CloudFront distributions, and they work together to filter both HTTP and HTTPS by distinguishing between legitimate and harmful inbound requests that will then either be allowed or blocked.
For clarity, a web application is simply a remote program that is accessed over the internet using a web browser.
Before we go any further, I just want to give a brief explanation of the attack patterns I mentioned here, as we may refer to them as we go through the rest of this course, and I want you to have a high-level overview of what they are and what they can do.
Starting with a 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 the database, such as a shutdown, which is obviously an administrative-level action. These SQL injection attacks are performed by inserting an 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 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 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.
A third, and what is a very common, attack, is that of the DDoS, Distributed Denial of Service attack. 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 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, that users usually think the site is down.
So these are just a few of the attacks that WAF can help prevent, along with a host of other malicious intents.
Let's now take a deeper look at what the WAF service is comprised of, to allow us to understand how it works. So 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 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.
During a later lecture, where I will provide a demonstration of how to configure WAF, we will look at these conditions in more detail, as each offer additional configurable values that widen the scope of vulnerabilities that you can check.
You then need to add those 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 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-grain control over very specific source targets.
An important point to make about 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 WhiteListed IP, which is set to Allow, and then BlackListed IPs, which is set to Block, and Bad Signatures, which are also set to Block.
Whitelisted IP addresses are a list of IP addresses that are allowed to access the resource. If you are 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 whitelist, and they would 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 or cross-site scripting vulnerabilities.
When an incoming HTTP request comes into WAF, it will be matched against the rule base in the order that 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.
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 action can either be 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 to a default action specified, which can either be Allow or Block.
The final part of the WAF service is the association of this Web ACL to one of your existing CloudFront distributions. For those unfamiliar with AWS CloudFront, it's an AWS service that acts as a Content Delivery Network, CDN service. This helps to reduce the latency between your customers and associated websites and web apps. This is achieved via caching mechanisms that happen throughout a global network of edge location infrastructure, which is fully managed by AWS. More information on CloudFront can be found here with one of our existing courses at Cloud Academy. So once your WAF Web ACL has been associated, then any request destined for that distribution will then be first governed by the conditions, rules, and Web ACL you configure within WAF, providing that additional security barrier to your websites and web applications.
That brings us to the end of this lecture. Next we will take a look at why and when you should use AWS WAF.
About the Author
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data centre and network infrastructure design, to cloud architecture and implementation.
To date Stuart has created over 40 courses relating to Cloud, most within the AWS category with a heavy focus on security and compliance
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.