Security and Identity
This course is an introduction to AWS security. During this course, we will get started on the most important topics by covering the AWS Shared Responsibility model, the AWS Acceptable Use policy, and penetration testing rules. We will then explore each of the services in the security and identity category. Besides the most obvious of those, Identity and Access Management (IAM), we will also learn about AWS Directory Service, the brand new Inspector service (which is still in preview mode), the recently announced Web Application Firewall (WAF) and Microsoft AD, an Enterprise-level domain hosted in the cloud. Also, we will take a quick look at the most basic security best practices that we need to be aware of when working with AWS.
There are no big pre-requisites for this course, you just need to have general IT knowledge and some basic understanding of AWS. If you don't yet feel confident enough on AWS to tackle this, you should take a look at the AWS Fundamentals Learning Path prior to getting started.
After taking this course you should be able to identify who is responsible for what in the AWS cloud and describe all the services in the security and identity category.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
- [Narrator] In this lecture, we'll introduce and explore the AWS web application firewall or AWS WAF. Following this lecture, we'll 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 application from common web exploits. And also lets you customize you're 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 this 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 has access to the internet. A web client can be a web browser or another application. So why would we want our web application firewall sitting between our web application and our 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 client 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. But fortunately, 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 shut down 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's then executed. They can cause serious damage and extract very sensitive information for the attacker if it's designed to do so. Coss-site scripting is essentially scripts that have been written to maliciously gain access to client-side data from another user via web application. These 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 that 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 malicious intents. 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 the points of presence or POPS which are located in various regions around the globe. These points of presence my be in closer proximity to the person requesting the content thereby speeding up the delivery of that content to the end users 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 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 the request to your back end application based on the rules you define. 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 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 a request and how the conditions will relate to 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 processed by the 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're executed in the order that they're listed within WAF. So be careful to architect this order correctly for your rule base. Typically these are ordered in show 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 https request comes into WAF, it will be matched against the rule base in the order that they appear. As soon as a request matches all the condition 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 be wither allow, block or count. When a request is allowed, this is forwarded onto the associated CloudFront distribution. When a request is blocked, the request gets terminated there and no further processing of that request is taken. Account action will do exactly that. It will count the number or requests that meet the conditions within that rule. This is a good option to select between testing new rules to ensure that the rule is picking up the request as expected before setting it 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 supplied 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 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 be then first governed by the conditions, rules and web ACL you configure within WAF providing that additional security barrier to your websites and web applications. This diagram shows how WAF handles requests coming to your web application. To use WAF, you need to create an Amazon CLoudFront distribution and place it in front of your web application. In this diagram, the application is represented by an elastic load balancer sending requests to several EC2 instances. Once a user sends a request to your application, WAF will evaluate it based on a set of web ACLs. If WAF doesn't find any rule that blocks the access, it will forward the request to the CLoudFront distribution. So web application firewall provides a flexible managed service to protect your websites and applications. Let's now have a look at how it works in the AWS console. To get started with this service, first you need to configure your web application to sit behind the CloudFront distribution. Setting up CloudFront is not in our scope for this lecture, so I've set up a CloudFront distribution already. Let me show you how to create a simple web ACL. So, here are the WAF console, click on get started. Since we don't have anything created, a wizard is automatically started for us. The first page includes an overview of the exact concept we just discussed. Let's click on next. Here we just have to give a name for our web ACL and click next. Now we have to create the conditions. First, I'll create a list of IP addresses. I'll use this condition to block requests coming from these addresses, note that I can put more than one address in a single condition. I will also create an SQL injection condition. I'll name it, define the filter, create it and then click on next. And in this step, we need to create the rules and set actions for each of the rules. I'll create one rule for each condition. The rules we created are going to be evaluated in the order shown, and once a request matches one of them, the WAF will take the defined action immediately. We can change the order in here. I'll select the block action for both of these rules and set the default action to be allow all requests. Now we're almost done. Let's click on next. Here we need to select the distribution to which we'll associate this web ACL. There, we're ready to create the web ACL. In this page, we can review the settings and confirm the creation. Done. Now we have our web ACL created and already monitoring the requests coming to our distribution. We can see more details about this web ACL by clicking on it. If you require more protection against DDOS attacks, Amazon provides another level of protection called AWS Shield Advanced. AWS Shield Advanced provides expanded DDOS protection for your elastic load balancing resources, CloudFront, and Amazon Route 53 resources. AWS Shield Advanced includes intelligent DDOS attack detection and mitigation for not only network layer, layer three, and transport layer, layer four attacks, but also application layer, layer seven attacks. AWS Shield Advanced comes at additional costs. So check the website for more detail on this service. So let's summarize what we've learned. We've learned that the web application firewall provides a flexible manage 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 filer both http and https traffic by distinguishing between legitimate and harmful inbound requests that will either be then allowed or blocked. When an incoming http request comes into WAF it will be matched against the 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 requests and how the conditions will relate to each other. That brings us to the end of this lecture. Any questions or comments please contact us on email@example.com
About the Author
Head of Content
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.