Implementing Web Application Firewall
What is AWS WAF?
WAF is web application firewall which is used for monitoring HTTP/HTPPS requests that are forwarded to AWS CloudFront or AWS Application load balancer. It is used to control your how CloudFront/Application load balancer responds to the request.
You can configure conditions and rules on the basis of which the requests are being allowed or denied. These conditions are further combined with web ACLs. WAF provides you extra protection to the DDoS attacks, SQL injection, cross-site scripting, HTTP flooding etc. as per the conditions of the web requests as given below:
- 1. IP address that requests originates from.
- 2. Country that requests originates from
- 3. Values in request headers
- 4. String that appears in requests, either specific strings or string that match regular expression (regex) patterns
- 5. Length of requests
- 6. Presence of sql code that is likely to be malicious
- 7. Presence of script that is likely to be malicious
Rules are created to created to precisely target the requests that one wants to allow, block or count. AWS provides two types of rules:
Regular rules only uses condition to target specific requests. You can allow or deny a request coming from a specific IP range or block the request that contain a SQL like code in query string.
Rate Based rule allows you to block the requests after a certain threshold of request has reached from a specific IP. Rate-based rules count the requests that arrive from a specified IP address every five minutes.
Web ACL is where you define an action for each rule you configure i.e. allow, block or count. When a request matches all the conditions in a rule, it will allow or deny a particular request to be forwarded to cloudfront or Application load balancer.
WAF accepts the rules on the basis on the order the rules are listed.
WAF allows you to choose the below mentioned behavior:
- 1. Allow all requests except the ones you define.
- 2. Deny all requests except the ones you define.
- 3. Count the requests that match the properties you define.
WAF setup Workflow:
Setting up WAF using cloudformation template:
For WAF setup, one needs to have access to the following AWS resources.
- 1. WAF full access
- 2. Cloudfront
- 3. Application load balancer
- 4. S3 bucket
- 5. Lambda functions
- 6. Cloudwatch read only access
- 7. Cloudformation
To start with, setup WAF using the cloudformation template provided by AWS that comes with the default 8 conditions and creates the entire stack for WAF. While setting up the WAF, we need to create to separate bucket where the logs are to be kept. The cloudformation template will also create the lambda function which will parse the logs in S3 bucket for any malicious log or for a request that looks for a request that matches the conditions specified.
Create Web ACL:
The next step is to create and configure web ACL using navigation pane and give a name to it. Here you can also provide a cloudwatch metric as well and associate the AWS resource (CloudFront or ALB) that you want with web ACL you created.
The cloudformation template automatically creates 8 conditions as given below:
- 1. SQL injection
- 2. Cross site scripting
- 3. HTTP flooding
- 4. IP match condition
- 5. String match condition
- 6. Scanner and probe protection
- 7. Reputation list
- 8. Bad bot protection
- 1. SQL injection:
A SQL injection match condition identifies the part of web requests, such as a header or a query string, that you want AWS WAF to inspect for malicious SQL code. In AWS WAF, you create SQL injection match condition and specify if you want to allow or deny requests that are like to contain malicious SQL code.
- 2. Cross Site Scripting:
It identifies the part of web requests, such as a header or a query string that you want AWS WAF to inspect for malicious scripts. While creating cross-site scripting condition, you need to specify the filters which indicate the part of request you need to inspect. We can specify the part of the request that we want to inspect using WAF, such as header, body URI or query string etc. for a single query parameter or all query parameters that you define. In single query parameter, you are inspecting the values for the defined parameters while in all query parameters; WAF inspects all the parameter values within the query string for the possible malicious script. You can create more filters to a condition or create the separate condition for each filter as per your requirement.
- 3. HTTP Flooding:
This condition is a rate based for HTTP flood protection that allows you to specify the limit of HTTP request coming from a particular user on the basis of which one can deny the request once the limit reaches the threshold. By default, the threshold is set at 2000 which can be changed as per the requirement.
- 4. IP match condition:
In IP match condition, we can track from where the request has been originated on the basis of which we can allow/deny the request from the specified IP address.
- 5. String match condition:
This condition searches for a specified string value in a header or in a query string on the basis of which we can allow/deny a particular request. We can take the part of request where we want to put the filter on like a body, header or query etc. Then we need to the value to match in a request that needs to be inspected. We can also set up multiple values to match in a request.
- 6. Scanner and probe protection:
With the WAF setup using default cloud formation template, it also creates a lambda function which parses into the logs created by CloudFront distribution or Application load balancer that further counts the no. of malicious requests from a particular IP address and updates WAF to block the source IP address.
- 7. Reputation List:
The AWS WAF solution parses into the reputation list of IP address maintained by attackers like malware distributors, spammers and bots maintained by some organizations and help to block malicious IP addresses.
- 8. Bad bot protection:
The standard Waf & Shield is currently parsed CloudFront logs sent to an s3 bucket. S3 bucket would trigger SNS or a Lambda function directly whenever it receives a new gzipped log file. The Lambda function will then downloads that file, parse it for malicious requests, and block the associated IP addresses. The waf-block-bad-behaving and waf-reactive-blacklist functions in the repo are linked to CloudFront. Occasionally, we will see signatures for bad bots in the user-agent string of the request. The CloudFront logs will show the user-agent string, so we could potentially parse that and block associated IPs accordingly.
One can also create more custom conditions and link it to a particular web ACL as per requirements.
Once these rules and conditions are configured then we need to protect our AWS resources like CloudFront or Application load balancer and raise a ticket seeking support with AWS DRT team.