3.1.3. AWS WAF (Web Application Firewall)

AWS WAF protects web applications and APIs from common web exploits and bots, by inspecting HTTP/S traffic at the application layer (Layer 7), ensuring security and availability.

Scenario: You need to protect a public-facing web application from common web exploits like SQL injection and Cross-Site Scripting (XSS), and also block traffic from specific malicious IP addresses.

For network specialists, protecting web applications from common web-based attacks (e.g., SQL injection, Cross-Site Scripting (XSS)) is crucial. AWS WAF provides this protection at the application layer.

AWS WAF (Web Application Firewall) is a web application firewall that helps protect your web applications or APIs from common web exploits that may affect availability, compromise security, or consume excessive resources.

Key Features of AWS WAF:

• Application-Layer Protection (Layer 7): Inspects HTTP/S traffic specifically.
• Common Web Exploits: Protects against common attacks defined by the OWASP Top 10.
• Integration Points: You deploy AWS WAF with:
  • Amazon CloudFront: For global web applications and CDNs.
  • Application Load Balancer (ALB): For regional web applications.
  • Amazon API Gateway: For securing REST and WebSocket APIs.
  • AWS AppSync: For GraphQL APIs.
• Rules: Define custom rules to allow, block, or count web requests based on conditions such as:
  • IP addresses (e.g., geo-blocking).
  • HTTP headers, body, or query strings.
  • SQL injection patterns.
  • XSS attacks.
  • Size constraints.
• Managed Rules: Predefined, AWS-managed rule groups that provide protection against common threats without requiring you to write custom rules.
• Rate-based Rules: Automatically block or limit traffic from IP addresses that are generating an unusually high number of requests (e.g., for DDoS mitigation).
• Rule Statement Types: String match (search a request component such as the URI or query string for text like /etc/passwd), regex match, SQL injection and XSS match, size constraint, geo match, IP set match, label match and rate-based statements. AWS Managed Rules add curated groups such as the Core rule set and Known bad inputs (request patterns tied to known exploits) — the fastest way to cover a published vulnerability without writing your own regex.
• AWS Firewall Manager: Across the accounts in AWS Organizations, Firewall Manager applies a mandatory WAF policy (and Shield Advanced, security group, Network Firewall and DNS Firewall policies) to every in-scope resource, including new ones, and shows per-account and per-resource compliance status in its console. A policy is scoped by accounts or OUs, resource type (ALB, CloudFront, API Gateway and others) and resource tags (include or exclude), so a tag such as Protection=Required pulls in every matching ALB, including ones created later, with no Lambda glue or per-ARN list. It requires AWS Organizations and AWS Config. CloudFormation StackSets can deploy rules but neither enforce them nor report drift; the WAF console shows one account.
• API Gateway Throttling: For abusive-but-valid API requests, API Gateway throttles at the stage/method level and, through usage plans, per API key (rate, burst and quota), returning HTTP 429 when a limit is exceeded; a WAF rate-based rule on the stage adds per-IP limits for distributed floods. Shield Standard covers Layer 3/4 attacks only.

Practical Implementation: Creating a WAF Web ACL and Rule

# 1. Create a Web ACL
WEB_ACL_ID=$(aws wafv2 create-web-acl \
  --name MyWebAppACL \
  --scope REGIONAL \
  --default-action Allow={} \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=MyWebAppACLMetrics \
  --query Summary.Id --output text)
echo "Web ACL ID: $WEB_ACL_ID"

# 2. Add a rule to block specific IP addresses
aws wafv2 update-web-acl \
  --name MyWebAppACL \
  --scope REGIONAL \
  --id $WEB_ACL_ID \
  --default-action Allow={} \
  --rules '[
    {
      "Name": "BlockMaliciousIPs",
      "Priority": 1,
      "Action": {"Block": {}},
      "Statement": {
        "IpSetReferenceStatement": {
          "Arn": "arn:aws:wafv2:us-east-1:123456789012:regional/ipset/MyMaliciousIPSet/abcdefg-1234-5678-9012-abcdefghijkl"
        }
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "BlockMaliciousIPsMetrics"
      }
    }
  ]' \
  --lock-token <get-lock-token-from-describe-web-acl> # You need to get the current lock token

⚠️ Common Pitfall: Deploying WAF without proper testing. Overly aggressive WAF rules can block legitimate user traffic, leading to application downtime. Always test rules in "Count" mode first.

Key Trade-Offs:

• Protection vs. False Positives: More aggressive WAF rules offer stronger protection but increase the risk of blocking legitimate traffic.

Reflection Question: How does AWS WAF, by inspecting HTTP/S traffic at the application layer (Layer 7) and allowing custom rules, fundamentally protect web applications and APIs from common web exploits and bots, ensuring their security and availability?