AWS WAF and Shield

Key components: - Web ACL: The main configuration object. You define rules (or rule groups) and a default action (Allow or Block) for requests that don't match any rule. - Rules: Each rule has a name, a statement (the condition to match), and an action. Statements can be simple (e.g., match an IP address) or complex (e.g., inspect a SQL query string for injection patterns). - Rule groups: A reusable set of rules. AWS provides managed rule groups (e.g., AWS Managed Rules for SQL injection, XSS, etc.) that are updated automatically. You can also create your own rule groups. - Conditions (deprecated but still referenced): Older terminology for match criteria. Now replaced by rule statements.

Default limits: - Maximum number of Web ACLs per account per Region: 100 (soft limit, can be increased) - Maximum number of rules per Web ACL: 100 (soft limit) - Maximum number of IP addresses per IP set: 10,000 (for IPv4) and 10,000 (for IPv6) - Maximum size of a request body that can be inspected: 8 KB (for AWS WAF Classic) or 64 KB (for AWS WAF v2)

Rule types: - IP set: Match requests based on source IP address or CIDR range. - String match: Match a specific string in a request component (e.g., header, query string). - Regex pattern set: Match against a regular expression. - Size constraint: Check the length of a request component. - SQL injection match: Detect SQL injection patterns. - Cross-site scripting (XSS) match: Detect XSS patterns. - Rate-based rule: Count requests from a single IP address; if the rate exceeds a threshold (up to 20,000 requests per 5-minute window), block additional requests. - Geographic match: Allow or block requests based on country of origin.

How a request is processed: 1. Request arrives at the resource (e.g., CloudFront). 2. The Web ACL evaluates the request against rules in order (rules are processed in the order you define, but you can set priorities). 3. The first rule that matches determines the action (Allow, Block, Count). If no rule matches, the default action is applied. 4. For Allow requests, the request is forwarded to the origin. For Block, a 403 Forbidden response is returned. Count increments a metric but continues processing (useful for testing).

AWS Shield Advanced provides enhanced protection for your applications running on EC2, ELB, CloudFront, Global Accelerator, and Route 53. It includes: - Enhanced DDoS detection: Uses dedicated monitoring and machine learning to detect attacks with higher accuracy. - Attack mitigation: Provides automatic mitigations for sophisticated attacks, including application-layer attacks. - DDoS cost protection: If your AWS bill increases due to a DDoS attack (e.g., increased data transfer for a CloudFront distribution), you can request a credit. - 24/7 access to the DDoS Response Team (DRT): You can engage the DRT during an attack. - Real-time visibility: CloudWatch metrics and AWS Shield Advanced dashboard show attack traffic.

Shield Advanced protections: - Layer 3/4 attacks: Same as Standard but with higher capacity and additional mitigations. - Layer 7 attacks: Works with AWS WAF to block application-layer DDoS attacks. Shield Advanced provides a Web ACL that automatically includes rules to block common DDoS patterns (e.g., HTTP floods). - Proactive engagement: You can configure Shield Advanced to automatically engage the DRT when certain conditions are met.

aws wafv2 create-web-acl \
    --name MyWebACL \
    --scope CLOUDFRONT \
    --default-action Allow={} \
    --rules file://rules.json \
    --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=MyWebACL

Associating a Web ACL with a CloudFront distribution:

aws wafv2 associate-web-acl \
    --web-acl-arn arn:aws:wafv2:us-east-1:123456789012:regional/webacl/MyWebACL/abc123 \
    --resource-arn arn:aws:cloudfront::123456789012:distribution/E1A2B3C4D5E6F7

Enabling Shield Advanced:

aws shield create-protection \
    --name MyProtection \
    --resource-arn arn:aws:cloudfront::123456789012:distribution/E1A2B3C4D5E6F7

Scenario 1: E-commerce website under SQL injection attack A retail company running a web application on EC2 behind an ALB noticed a spike in database errors. Security logs showed SQL injection attempts in the query string. The solution: deploy AWS WAF with the AWS Managed Rules for SQL injection. The Web ACL was associated with the ALB. Within minutes, malicious requests were blocked, and the application stabilized. The team also added rate-based rules to limit requests per IP to 1000 per 5 minutes to prevent brute force attacks. They used the Count action initially to verify no legitimate traffic was blocked. After a week, they switched to Block. The total cost was ~$5/month for the Web ACL plus request fees.

Scenario 2: Global media site hit by DDoS A streaming service experienced a massive UDP flood targeting its CloudFront distribution. AWS Shield Standard mitigated the layer 3/4 attack automatically, but the application still suffered from a layer 7 HTTP flood. The company subscribed to Shield Advanced ($3,000/month) and enabled the DDoS protection Web ACL, which includes rate limiting and IP reputation lists. Shield Advanced's cost protection meant they could request a credit for the increased data transfer costs during the attack. They also engaged the DRT for assistance. The attack was mitigated within minutes.

Scenario 3: Financial API with strict IP whitelist A bank exposes an API via API Gateway for partner integrations. They must only allow traffic from known partner IP ranges. They created an IP set with the partner CIDRs and a Web ACL with a single rule that allows traffic from that IP set and blocks all others (default action Block). They also added AWS Managed Rules for XSS and SQL injection as an extra layer. The Web ACL is associated with the API Gateway. Misconfiguration: initially, they forgot to set the default action to Block, so traffic from non-partner IPs was allowed. After correcting, they verified using CloudWatch metrics that only allowed traffic was reaching the API.