AWS Web Application Firewall – WAF
- AWS WAF – Web Application Firewall protects web applications from attacks by allowing rules configuration that allow, block, or monitor (count) web requests based on defined conditions.
- helps protects from common attack techniques like SQL injection and Cross-Site Scripting (XSS), Conditions based include IP addresses, HTTP headers, HTTP body, and URI strings.
- tightly integrates with CloudFront, API Gateway, AppSync, and the Application Load Balancer (ALB) services used to deliver content for their websites and applications.
- AWS WAF with Amazon CloudFront
- AWS WAF rules run in all AWS Edge Locations, located around the world close to the end users.
- Blocked requests are stopped before they reach the web servers.
- Helps support custom origins outside of AWS.
- AWS WAF with Application Load Balancer
- WAF rules run in the region and can be used to protect internet-facing as well as internal load balancers.
- AWS WAF with API Gateway
- Can help secure and protect the REST APIs.
- AWS WAF with Amazon CloudFront
- helps protect applications and can inspect web requests transmitted over HTTP or HTTPS.
- provides Managed Rules which are pre-configured rules to protect applications from common threats like application vulnerabilities like OWASP, bots, or Common Vulnerabilities and Exposures (CVE).
- logs can be sent to the CloudWatch Logs log group, an S3 bucket, or Kinesis Data Firehose.
WAF Benefits
- Additional protection against web attacks using specified conditions
- Conditions can be defined by using characteristics of web requests such as the following:
- IP addresses that the requests originate from
- Values in request headers
- Strings that appear in the requests
- Length of requests
- Presence of SQL code that is likely to be malicious (this is known as SQL injection)
- Presence of a script that is likely to be malicious (this is known as cross-site scripting)
- Managed Rules to get you started quickly
- Rules that you can reuse for multiple web applications
- Real-time metrics and sampled web requests
- Automated administration using the WAF API
How WAF Works
WAF allows controlling the behaviour of web requests by creating conditions, rules, and web access control lists (web ACLs).
Conditions
- Conditions define basic characteristics to watch for in a web request
- Malicious script – XSS (Cross Site Scripting) – Attackers embed scripts that can exploit vulnerabilities in web applications
- IP addresses or address ranges that requests originate from.
- Size – Length of specified parts of the request, such as the query string.
- Malicious SQL – SQL injection – Attackers try to extract data from the database by embedding malicious SQL code in a web request
- Geographic match – Allow or block requests based on the country from which the requests originate.
- Strings that appear in the request, for e.g., values that appear in the User-Agent header or text strings that appear in the query string.
Some conditions take multiple values.
Actions
- Allow all requests except the ones specified – blacklisting for e.g all IP addresses except the ones specified
- Block all requests except the ones specified – whitelisting for e.g IP addresses the request originates from
- Monitor (Count) the requests that match the specified properties – allows counting of the requests that match the defined properties, which can be useful when configuring and testing allow or block requests using new properties. After confirming that the config did not accidentally block all of the traffic to the website, the configuration can be applied to change the behaviour to allow or block requests.
- CAPTCHA – runs a CAPTCHA check against the request.
Rules
- AWS WAF rule defines how to inspect HTTP(S) web requests and the action to take on a request when it matches the inspection criteria.
- Each rule requires one top-level rule statement, which might contain nested statements at any depth, depending on the rule and statement type.
- AWS WAF also supports logical statements for
AND,OR, andNOTthat you use to combine statements in a rule. for e.g.,
- based on recent requests that you’ve seen from an attacker, you might create a rule that includes the following conditions with logical AND condition:
- The requests come from 192.0.2.44.
- They contain the value BadBot in the User-Agent header.
- They appear to include malicious SQL code in the query string.
- All 3 conditions should be satisfied for the Rule to be passed and the associated action to be taken.
- based on recent requests that you’ve seen from an attacker, you might create a rule that includes the following conditions with logical AND condition:
Rule Groups
- A Rule Group is a reusable set of rules that can be added to a Web ACL.
- Rule groups fall into the following main categories
- Managed rule groups, which AWS Managed Rules and AWS Marketplace sellers create and maintain for you
- Your own rule groups, which you create and maintain
- Rule groups that are owned and managed by other services, like AWS Firewall Manager and Shield Advanced.
Web ACLs – Access Control Lists
- A Web Access Control List – Web ACL provides fine-grained control over all of the HTTP(S) web requests that the protected resource responds to.
- Web ACLs provides
- Rule Groups OR Combination of Rules
- Action – allow, block or count to perform for each rule
- WAF compares a request with the rules in a web ACL in the order in which it is listed and takes the action that is associated with the first rule that the request matches.
- For multiple rules in a web ACL, WAF evaluates each request against the rules in the order they are listed in the web ACL.
- When a web request matches all of the conditions in a rule, WAF immediately takes the action – allow or block – and doesn’t evaluate the request against the remaining rules in the web ACL, if any.
- Default action
- determines whether WAF allows or blocks a request that does not match all of the conditions in any of the rules
- Supports criteria like the following to allow or block requests
- IP address origin of the request
- Country of origin of the request
- String match or regular expression (regex) match in a part of the request
- Size of a particular part of the request
- Detection of malicious SQL code or scripting
- Rate based rules
AWS WAF based Architecture
- AWS WAF integration with CloudFront and Lambda to dynamically update WAF rules
- CloudFront receives requests on behalf of the web application, it sends access logs to an S3 bucket that contains detailed information about the requests.
- For every new access log stored in the S3 bucket, a Lambda function is triggered. The Lambda function parses the log files and looks for requests that resulted in error codes 400, 403, 404, and 405.
- Lambda function then counts the number of bad requests and temporarily stores results in the S3 bucket
- Lambda function updates AWS WAF rules to block the IP addresses for a period of time that you specify.
- After this blocking period has expired, AWS WAF allows those IP addresses to access your application again, but continues to monitor the requests from those IP addresses.
- Lambda function publishes execution metrics in CloudWatch, such as the number of requests analyzed and IP addresses blocked.
- CloudWatch metrics can be integrated with SNS for notification
Web Application Firewall Sandwich Architecture
NOTE :- From DDOS Resiliency Whitepaper – doesn’t use the AWS WAF and is not valid anymore
- DDoS attacks at the application layer commonly target web applications with lower volumes of traffic compared to infrastructure attacks.
- WAF can be included as part of the infrastructure to mitigate these types of attacks
- WAFs act as filters that apply a set of rules to web traffic, which cover exploits like XSS and SQL injection but can also help build resiliency against DDoS by mitigating HTTP GET or POST floods.
- HTTP works as a request-response protocol between end users and applications where end users request data (GET) and submit data to be processed (POST). GET floods work by requesting the same URL at a high rate or requesting all objects from your application. POST floods work by finding expensive application processes, i.e., logins or database searches, and triggering those process to overwhelm your application.
- WAFs have several features that may prevent these types of attacks from affecting the application availability for e.g. HTTP rate limiting which limits the number of requests per end user within a certain time period. Once the threshold is exceeded, WAFs can block or buffer new requests to ensure other end users have access to the application.
- WAFs can also inspect HTTP requests and identify those that don’t confirm to normal patterns
- In the “WAF sandwich,” the EC2 instance running the WAF software (not the AWS WAF) is included in an Auto Scaling group and placed in between two ELB load balancers. Basic load balancer in the default VPC will be the frontend, public facing load balancer that will distribute all incoming traffic to the WAF EC2 instance.
- With WAF sandwich pattern, the instance can scale and add additional WAF EC2 instances should the traffic spike to elevated levels.
- Once the traffic has been inspected and filtered, the WAF EC2 instance forwards traffic to the internal, backend load balancer which then distributes traffic across the application EC2 instance.
- This configuration allows the WAF EC2 instances to scale and meet capacity demands without affecting the availability of your application EC2 instance.
AWS Certification Exam Practice Questions
- Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
- AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
- AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
- Open to further feedback, discussion and correction.
- The Web Application Development team is worried about malicious activity from 200 random IP addresses. Which action will ensure security and scalability from this type of threat?
- Use inbound security group rules to block the IP addresses.
- Use inbound network ACL rules to block the IP addresses.
- Use AWS WAF to block the IP addresses.
- Write iptables rules on the instance to block the IP addresses.
- You’ve been hired to enhance the overall security posture for a very large e-commerce site. They have a well architected multi-tier application running in a VPC that uses ELBs in front of both the web and the app tier with static assets served directly from S3. They are using a combination of RDS and DynamoDB for their dynamic data and then archiving nightly into S3 for further processing with EMR. They are concerned because they found questionable log entries and suspect someone is attempting to gain unauthorized access. Which approach provides a cost effective scalable mitigation to this kind of attack? [Old Exam Question]
- Recommend mat they lease space at a DirectConnect partner location and establish a 1G DirectConnect connection to their VPC they would then establish Internet connectivity into their space, filter the traffic in hardware Web Application Firewall (WAF). And then pass the traffic through the DirectConnect connection into their application running in their VPC. (Not cost effective)
- Add previously identified hostile source IPs as an explicit INBOUND DENY NACL to the web tier subnet. (does not protect against new source)
- Add a WAF tier by creating a new ELB and an AutoScaling group of EC2 Instances running a host-based WAF. They would redirect Route 53 to resolve to the new WAF tier ELB. The WAF tier would then pass the traffic to the current web tier. Web tier Security Groups would be updated to only allow traffic from the WAF tier Security Group
- Remove all but TLS 1.2 from the web tier ELB and enable Advanced Protocol Filtering This will enable the ELB itself to perform WAF functionality. (No advanced protocol filtering in ELB)
