AWS WAF (Web Application Firewall)¶

Without WAF:
  Attacker sends SQL injection → hits your application → database compromised

With WAF:
  Attacker sends SQL injection → WAF inspects HTTP body → matches rule → BLOCK ❌
  Legitimate user → WAF inspects → no match → ALLOW ✅ → reaches application

Architecture options:
  Option A: WAF on CloudFront (global)
    User → CloudFront (WAF here) → ALB → Application
    ✅ Inspects at edge (closest to attacker) — cheapest, fastest blocking

  Option B: WAF on ALB (regional)
    User → ALB (WAF here) → Application
    ✅ Inspects regional traffic
    ❌ Bypassed if attacker hits ALB directly (skip CloudFront)

  Option C: WAF on both CloudFront AND ALB
    Most secure — blocks at edge + backstop if ALB is reached directly [reddit](https://www.reddit.com/r/aws/comments/1kc0fnb/rate_limit_rules_in_waf_with_cloudfront/)

Web ACL properties:
  Scope: CLOUDFRONT (global) or REGIONAL (ALB, API GW, etc.)
  Default action: ALLOW or BLOCK (what happens if no rule matches)
  Rules: ordered list of rules and rule groups (priority 0–99,999,999)
  Capacity: max 1,500 WCUs (Web ACL Capacity Units)

Rule:
  Name:      BlockSQLInjection
  Priority:  10              ← lower number = evaluated first
  Statement: SQL injection match on request body
  Action:    Block

Rule:
  Name:      AllowOfficeIP
  Priority:  5               ← evaluated before BlockSQLInjection (lower priority number)
  Statement: IP set match (203.0.113.0/24)
  Action:    Allow

Every rule consumes WCUs based on complexity:
  Simple IP match:          1 WCU
  Regex pattern match:      25 WCUs per pattern (max 10 patterns = 250 WCUs)
  SQL injection detection:  20 WCUs
  Bot Control (common):     25 WCUs
  Bot Control (targeted):   50 WCUs

Web ACL limit: 1,500 WCUs total
(Can request increase, costs extra per 500 additional WCUs)

Count action use case:
  New rule you're testing → set to Count first
  Monitor in CloudWatch: how many requests would have been blocked?
  If no false positives → switch to Block

CAPTCHA vs Challenge:
  Challenge: silent, JavaScript-based browser verification (invisible to user)
  CAPTCHA:   visible image puzzle the user must solve
  Use Challenge first → if bots pass it → escalate to CAPTCHA

Add managed rule group to Web ACL:
  → select rule group → set priority → choose override actions if needed
  → AWS maintains all rules inside — you do not write individual rules

Override action (per rule inside the group):
  Use group defaults  → respect all built-in Allow/Block/Count actions
  Count all          → override all actions to Count (safe testing mode)
  Override specific  → override individual rules from Block → Count or vice versa

Statement types you can use:

IP Set Match:
  Block specific IP ranges
  "Statement": { "IPSetReferenceStatement": { "ARN": "arn:aws:wafv2:...:ipset/block-list" } }

Geo Match:
  Block all traffic from specific countries
  "Statement": { "GeoMatchStatement": { "CountryCodes": ["RU", "CN", "KP"] } }

String Match:
  Block requests containing specific string in URI, header, body, query string
  "Statement": {
    "ByteMatchStatement": {
      "SearchString": "../../../etc/passwd",
      "FieldToMatch": { "UriPath": {} },
      "TextTransformations": [{ "Priority": 0, "Type": "URL_DECODE" }],
      "PositionalConstraint": "CONTAINS"
    }
  }

Regex Match:
  Block URIs matching regex pattern
  FieldToMatch: URI, headers, body, query string, cookies, HTTP method

Rate-Based Rule:
  Block IPs exceeding N requests per 5 minutes (see Section 7)

SQL Injection Match:
  Built-in SQLi detection on specific field

XSS Match:
  Built-in cross-site scripting detection on specific field

Logical Rules (AND / OR / NOT):
  Combine multiple statements:
  "AND": [geo match CN, rate > 1000] → Block
  "NOT": [IP in allowlist] AND [SQLi match] → Block

WCU cost: 25 WCUs
Detects: well-known bots by signature (user agent, IP, behavior patterns)
  → Googlebot, Bingbot (verified → Allow)
  → Scrapers, crawlers (unverified → Block)
Pricing: additional fee per million requests inspected

WCU cost: 50 WCUs
Adds: machine learning analysis of traffic patterns
      browser fingerprinting (detects automated browsers)
      coordinated activity detection (distributed bot farms)
Rules with TGT_ prefix = targeted rules
Rules with TGT_ML_ prefix = ML-powered rules (take up to 24h to baseline) [docs.aws.amazon](https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control-rg-using.html)
Pricing: higher additional fee per million requests

WAF adds labels to requests for custom rule chaining:
  awswaf:managed:aws:bot-control:bot:category:ai
  awswaf:managed:aws:bot-control:bot:verified
  awswaf:managed:aws:bot-control:signal:automated_browser
  awswaf:managed:aws:bot-control:signal:known_bot_data_center
  awswaf:managed:aws:bot-control:signal:non_browser_user_agent

Use labels in downstream rules:
  "If label = signal:automated_browser → CAPTCHA"
  "If label = bot:verified → Allow (Googlebot)"
  "If label = signal:known_bot_data_center → Block"

Rate-based rule:
  Threshold: 1,000 requests
  Window: 5 minutes (fixed — cannot change)
  Aggregate key: IP address (default)
  Action: Block (or Count, CAPTCHA, Challenge)

Behavior:
  AWS WAF counts requests per IP in rolling 5-minute window
  When IP exceeds 1,000 in any 5-minute window → Action triggered
  Block lifted when rate drops below threshold
 [docs.aws.amazon](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based-request-limiting.html)

Scope-down statement (optional): [docs.aws.amazon](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
  Only count/rate-limit requests that match a condition
  Example: rate-limit only POST /login (not all endpoints)
  "ScopeDownStatement": {
    "ByteMatchStatement": {
      "SearchString": "/login",
      "FieldToMatch": { "UriPath": {} },
      "PositionalConstraint": "EXACTLY"
    }
  }
  → Only login attempts counted toward rate limit
  → Other endpoints unaffected

Reusable list of IP addresses/CIDR ranges
Create once → reference in multiple rules

IP set types:
  Allowlist: known safe IPs (office, partners) → Always Allow
  Blocklist: known bad IPs, threat intel feeds → Always Block

Create:
  aws wafv2 create-ip-set \
    --scope REGIONAL \
    --name office-allowlist \
    --ip-address-version IPV4 \
    --addresses "203.0.113.0/24" "198.51.100.5/32"

Update without rule change:
  Add/remove IPs from IP set → rule automatically uses updated list

Block or allow based on country of origin (determined by IP geolocation):

Use cases:
  GDPR: force EU users to EU endpoint only
  Compliance: block service in specific jurisdictions
  Cost reduction: block known bot-heavy regions

"Statement": {
  "GeoMatchStatement": {
    "CountryCodes": ["RU", "CN", "KP", "IR"]
  }
}

Limitation: VPN/Tor users bypass geo match (their exit IP = different country)
  → Combine with AWSManagedRulesAnonymousIpList to also block Tor/VPN

Stage 1: Bot Control rule group runs
  → Labels request: "awswaf:managed:aws:bot-control:signal:automated_browser"

Stage 2: Your custom rule checks for that label
  If: label matches "automated_browser"
  Then: CAPTCHA

Stage 3: If CAPTCHA is solved → allow through
  If CAPTCHA failed → Block

This allows: coarse detection → fine-grained custom response

Enable logging → WAF sends full request logs to:
  Amazon S3                    → long-term storage, Athena queries
  CloudWatch Logs              → real-time monitoring, alarms
  Amazon Kinesis Data Firehose → streaming to S3/Splunk/Datadog

Log contents:
  Timestamp, action (ALLOW/BLOCK/COUNT), rule that matched,
  Client IP, URI, headers (configurable), country, HTTP method,
  Labels applied, terminating rule

Log filtering:
  Log only BLOCK actions (reduces cost)
  Log only specific rule matches
  Redact sensitive headers before logging

AllowedRequests   → count of allowed requests
BlockedRequests   → count of blocked requests per rule
CountedRequests   → count of counted (passthrough) requests
CaptchaRequests   → count of CAPTCHA challenges
PassedRequests    → requests that passed CAPTCHA

Create alarms:
  BlockedRequests > 1000 in 5 min → SNS → PagerDuty
  (sudden spike in blocks = attack in progress)

WAF stores samples of last 3 hours of requests (max 100 per rule):
  Console: WAF → Web ACL → Sampled requests tab
  Shows: actual request that matched (headers, URI, body snippet)
  Use: debug why a rule is blocking legitimate traffic

Combined architecture for full protection:
  CloudFront (with WAF + Shield Advanced)
    → WAF handles: SQLi, XSS, bots, rate limiting, geo blocking
    → Shield handles: volumetric DDoS (millions of pps UDP/TCP floods)
    → Together: comprehensive application protection

Regional Web ACL:    $5.00/month per Web ACL
CloudFront Web ACL:  $5.00/month per Web ACL
Per rule:            $1.00/month per rule
Per rule group:      $1.00/month per rule group
Requests:            $0.60 per 1 million requests (first 10M)
                     $0.40 per 1 million requests (after 10M)

Managed rule groups (AWS Managed):
  Basic groups (CommonRuleSet, SQLi, etc.): included
  Bot Control Common:  additional charge per million requests
  Bot Control Targeted: higher per-million charge

Rule groups from marketplace: vendor-specific pricing

1. Start all new rules in COUNT mode → monitor for 1-2 weeks → switch to BLOCK
   (Prevents blocking legitimate traffic due to false positives)

2. Layer defense:
   Priority 1: IP allowlist (trusted IPs — highest priority, always allow)
   Priority 2: IP blocklist (known bad IPs — block immediately)
   Priority 3: AWS managed rules (OWASP, SQLi, etc.)
   Priority 4: Rate-based rules (DDoS/brute force)
   Priority 5: Custom application rules
   Default:    ALLOW (or BLOCK for strict mode)

3. Use scope-down statements on Bot Control and advanced rules:
   → Only apply expensive rules to sensitive endpoints (/login, /checkout)
   → Reduces WCU consumption and request inspection costs [aws.github](https://aws.github.io/aws-security-services-best-practices/guides/waf/configuring-waf-rules/docs/)

4. Attach WAF to CloudFront (not just ALB):
   → Blocks at edge before traffic reaches your region
   → Reduces origin load from attack traffic [reddit](https://www.reddit.com/r/aws/comments/1kc0fnb/rate_limit_rules_in_waf_with_cloudfront/)

5. Enable WAF logging to S3 + set up CloudWatch alarm on BlockedRequests spike
   → Operational visibility + incident response

6. Regularly review sampled requests for false positives
   → Tune rules before attacks happen, not during