5.2 AWS WAF Architecture & Advanced Rule Sets

5.2 AWS WAF Architecture & Advanced Rule Sets

Application-layer attacks represent the most pervasive and complex threat vector facing modern cloud environments. While network firewalls and security groups effectively filter traffic based on IP addresses and port numbers (Layers 3 and 4), they are completely blind to malicious payloads concealed within valid HTTP/HTTPS requests (Layer 7). Exploits such as SQL injection (SQLi), Cross-Site Scripting (XSS), server-side request forgery (SSRF), distributed credential stuffing, and automated scraping operate entirely within legitimate transport connections.

AWS WAF (v2) provides deep Layer 7 visibility, allowing security teams to inspect, count, challenge, and block malicious traffic before it consumes origin compute resources. This section covers the architectural mechanics of AWS WAF, WebACL scopes, AWS Managed Rules (AMR), advanced Bot Control and Account Takeover Prevention (ATP), custom rate-based rules, header-matching origin cloaking, rule evaluation pipelines, and centralized logging.

---

AWS WAFv2 Architecture, Scopes & Service Associations

AWS WAF operates using a hierarchical model composed of Web Access Control Lists (WebACLs), Rule Groups, and individual Rules. A WebACL defines the inspection criteria, evaluation sequence, and default fallback action for associated resources.

Loading diagram...

WebACL Scopes and Regionality

When provisioning a WebACL, security engineers must explicitly define its Scope:

1. CLOUDFRONT (Global): CloudFront WebACLs protect edge distributions worldwide. Critical Exam Fact: A CloudFront WebACL must always be created in the us-east-1 (N. Virginia) Region. Even if the CloudFront distribution serves viewers primarily in Europe or Asia, its associated WebACL resides in us-east-1. Attempting to associate a regional WebACL with CloudFront will fail.
2. REGIONAL: Protects regional infrastructure located within a specific AWS Region. Regional WebACLs can be associated with:
   • Application Load Balancers (ALBs)
   • Amazon API Gateway REST APIs (HTTP APIs are not supported)
   • AWS AppSync (GraphQL APIs)
   • Amazon Cognito user pools (protecting authentication endpoints)
   • AWS App Runner services and AWS Verified Access instances

WebACL Capacity Units (WCU)

AWS WAF calculates resource consumption using WebACL Capacity Units (WCUs). WCUs represent the computational cost of evaluating rules against incoming requests:

• A web ACL's base price includes up to 1,500 WCUs; usage above that is billed in tiers automatically, up to the hard maximum of 5,000 WCUs.
• Simple rules (such as matching an IP CIDR or a basic URI prefix) consume 1 to 5 WCUs.
• Complex rules (such as inspecting request bodies with regular expressions, calculating rate limits, or executing managed rule groups) consume between 10 and several hundred WCUs.
• When adding AWS Managed Rules, their pre-calculated WCU cost (e.g., Core Rule Set = 700 WCUs, SQLi = 200 WCUs) counts directly against the WebACL's total allocation.

---

Rule Evaluation Pipeline & Action Semantics

Inside a WebACL, rules are organized by an explicit integer Priority (from 0 upwards). AWS WAF evaluates rules in strict order of priority, from lowest numerical value (highest priority) to highest numerical value.

Loading diagram...

Terminating vs Non-Terminating Actions

Understanding action execution behavior is essential for designing effective WAF rule hierarchies:

• Allow (Terminating): Immediately halts further rule evaluation in the WebACL and forwards the request to the protected resource. Warning: Any security inspection rules defined with higher numerical priority values will be skipped.
• Block (Terminating): Immediately halts evaluation and drops the request. CloudFront or ALB returns an HTTP status code (default 403 Forbidden, configurable to 404, 429, or custom status codes) with an optional custom response body (HTML/JSON) and custom response headers.
• Count (Non-Terminating): Increments a CloudWatch metric and immediately passes the request to the next rule in the priority sequence. Count is used to test new rules in production without interrupting legitimate traffic, and to insert custom request headers (e.g., X-WAF-Flag: Suspicious) for downstream logging.
• CAPTCHA and Challenge (Terminating / Conditional): Interrogates the client. Challenge executes a silent, background browser verification (solving a cryptographic puzzle and validating browser telemetry) to generate an AWS WAF client token. CAPTCHA displays a visual or audio puzzle. If the client successfully solves the challenge, a token is stored in client storage, and subsequent requests bypass challenge evaluation.

---

AWS Managed Rules (AMR) & Scope-Down Statements

AWS Managed Rules provide curated, regularly updated rule sets managed directly by the AWS Threat Research Team. They provide rapid, comprehensive protection against common threats without requiring manual rule maintenance.

Core Managed Rule Sets

Safe Deployment via Action Overrides & Scope-Down Statements

Deploying managed rule sets into existing production workloads carries the risk of false positives. AWS WAF provides two critical mechanisms to mitigate this risk:

1. Action Overrides: Security engineers can override the action of an entire rule group—or specific individual rules within the group—to Count. In Count mode, matching requests are logged to CloudWatch metrics without being blocked. Once baseline metrics demonstrate zero false positives over days or weeks, the override is removed to enforce active blocking.
2. Scope-Down Statements: A scope-down statement restricts the managed rule group so that it executes only on requests matching specific conditions, or excludes certain paths entirely. For example, to avoid wasting WCUs and incurring latency evaluating SQLi rules on static image assets:

{
  "Name": "AWS-AWSManagedRulesSQLiRuleSet",
  "Priority": 20,
  "Statement": {
    "ManagedRuleGroupStatement": {
      "VendorName": "AWS",
      "Name": "AWSManagedRulesSQLiRuleSet",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/api/",
          "FieldToMatch": {
            "UriPath": {}
          },
          "TextTransformations": [
            {
              "Priority": 0,
              "Type": "LOWERCASE"
            }
          ],
          "PositionalConstraint": "STARTS_WITH"
        }
      }
    }
  },
  "OverrideAction": {
    "None": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "WAF-SQLi-Rule"
  }
}

---

Advanced Threat Protection: Bot Control & Account Takeover Prevention (ATP)

Sophisticated adversaries deploy distributed bot swarms and automated scripts that mimic human browsing to execute credential stuffing, scraping, and account takeover attacks. Traditional IP-based blocklists and signature-matching rules fail against these threats.

AWS WAF Bot Control (AWSManagedRulesBotControlRuleSet)

Bot Control provides specialized detection across two inspection tiers:

• Common Bot Control: Detects and categorizes known search engine crawlers, SEO tools, site monitors, and scraping frameworks (e.g., Python requests, Scrapy, Puppeteer). It allows legitimate bots (such as Googlebot) while blocking unauthorized scrapers.
• Targeted Bot Control: Defends against stealthy, distributed bots. It uses client interrogation via the AWS WAF JavaScript SDK or mobile SDK, machine learning behavioral analysis, and automated browser fingerprinting to identify automated traffic trying to simulate human keyboard/mouse interaction.

Account Takeover Prevention (AWSManagedRulesATPRuleSet)

Account Takeover Prevention (ATP) is a specialized managed rule group that protects user authentication and login endpoints (e.g., /login, /auth/signin, /oauth/token):

• Credential Stuffing Detection: ATP inspects incoming authentication payloads (supporting JSON and form-urlencoded bodies) extracting username and password fields.
• Compensating Threat Intelligence: ATP queries an internal AWS threat intelligence database containing billions of compromised credentials observed in public data breaches. If an incoming login matches a known compromised credential pair, ATP flags or blocks the attempt.
• Brute-Force & Token Validation: ATP tracks login failure rates per username and per client IP, enforcing silent Challenge or CAPTCHA actions to throttle automated dictionary attacks.

---

Custom Rate-Based Rules & Advanced Aggregation Keys

Rate-based rules monitor the volume of requests matching specific criteria over a configurable sliding time window. If a client breaches the configured threshold, AWS WAF applies the configured action (typically Block or CAPTCHA) until the request rate drops below the threshold.

Rate Limiting Evaluation Parameters

• Evaluation Window: Historically fixed at 5 minutes, AWS WAFv2 allows configurable sliding evaluation windows of 1 minute (60s), 2 minutes (120s), 5 minutes (300s), or 10 minutes (600s).
• Rate Limit Threshold: Configurable down to a minimum of 10 requests per evaluation window.
• Aggregation Keys:
  • Source IP: Evaluates the client IP from the network socket connection.
  • Forwarded IP: Evaluates the IP address extracted from the X-Forwarded-For (XFF) header when traffic traverses intermediate proxies or external CDNs. Includes configuration for handling missing or malformed headers (MATCH or NO_MATCH) and selecting the first or last IP.
  • Custom HTTP Header: Tracks rate limits by session token, API key (e.g., X-API-Key), or user ID header.
  • Composite Keys: Combines multiple request attributes. For example, aggregating by Source IP + URI Path ensures that aggressive scraping on an expensive search endpoint /api/search is blocked without impacting the user's access to the rest of the application.

---

Origin Cloaking via Header Matching & Security Groups

When CloudFront or an external CDN sits in front of an Application Load Balancer, attackers must be prevented from discovering the ALB's public DNS hostname and bypassing WAF inspection by sending requests directly to the ALB.

Loading diagram...

Implementing Origin Cloaking

1. CloudFront Custom Header: Configure CloudFront to inject a secret custom header into every request sent to the origin (e.g., X-Origin-Verify: d9a4f2e8-c81b-417e-9023-458EXAMPLE).
2. ALB WebACL Header Rule: Attach a regional WebACL to the ALB with a high-priority rule (Priority 0) that inspects the X-Origin-Verify header:
   • If the header is missing or does not match the secret token, action = Block (HTTP 403).
   • This guarantees that any direct request to the ALB hostname is immediately rejected.
3. Network Layer Cloaking via AWS Prefix Lists: To harden the perimeter further, attach the managed AWS CloudFront Prefix List (pl-xxxxxxx) to the ALB's security group inbound rules on port 443. This drops all direct internet connections at the network layer (Layer 4) before TLS negotiation occurs.

---

Centralized Logging, Filtering & OCSF Format

Auditing WAF evaluations is a strict regulatory requirement in financial and healthcare environments.

Logging Destinations & Mandatory Naming Conventions

AWS WAF supports three logging destinations, each with a mandatory naming requirement:

• Amazon CloudWatch Logs: The destination log group name must begin with aws-waf-logs- (e.g., aws-waf-logs-alb-production).
• Amazon S3: The destination S3 bucket name must begin with aws-waf-logs- (e.g., s3://aws-waf-logs-enterprise-audit-bucket/).
• Amazon Data Firehose: The delivery stream name must begin with aws-waf-logs- (e.g., aws-waf-logs-stream-siem).

Log Filtering & Sensitive Field Redaction

Logging every single HTTP transaction can generate terabytes of data and incur substantial CloudWatch or S3 storage fees. Security engineers configure Log Filtering in the WebACL:

• Action-Based Filtering: Drop all ALLOW events and log only BLOCK, COUNT, and CAPTCHA events.
• Redacted Fields: To comply with privacy standards (e.g., PCI-DSS, GDPR, HIPAA), sensitive fields must be masked before logs leave WAF. Common redacted fields include Authorization headers, session Cookie values, and query parameters containing user authentication credentials.
• OCSF through Security Lake: Amazon Security Lake collects AWS WAF (v2) logs as a native source and normalizes them to the Open Cybersecurity Schema Framework (OCSF), so SIEM subscribers such as Splunk or Microsoft Sentinel receive one standard schema.

---

Specialty Exam Pitfalls & Architectural Traps

1. Creating a CloudFront WebACL in the Workload Region: A frequent exam trap describes an application running in eu-west-1 with a CloudFront distribution. The scenario asks why an administrator cannot associate a newly created WebACL with CloudFront. The reason: WebACLs for CloudFront must be created in us-east-1 (Global scope). A WebACL created in eu-west-1 can only be attached to regional resources like ALBs or API Gateways.
2. The Runaway Allow Rule: Placing an Allow rule (such as an IP allowlist for an office branch) at Priority 0 with terminating semantics means that any traffic from that IP bypasses all subsequent rules—including SQLi and Core Rule Set protections. If an employee's laptop on that network is infected, malicious requests pass directly to the origin. Best practice: Use Count or combine conditions rather than blind terminating Allow actions.
3. Failure to Account for Body Inspection Limits: AWS WAF inspects a fixed 8 KB of the request body for Application Load Balancer and AppSync, and 16 KB by default for CloudFront, API Gateway, Cognito, App Runner, and Verified Access (raisable in 16 KB steps to 64 KB, with extra charges only for larger bodies). If an attacker submits a malicious SQLi payload at byte offset 20,000 in an oversized JSON payload, WAF will not inspect it unless the rule statement explicitly handles oversized bodies using the Oversize handling configuration (CONTINUE, MATCH, or NO_MATCH).
4. Misconfiguring Forwarded IP with Rate-Based Rules: If an application sits behind a CDN or proxy and the security engineer configures a rate-based rule using Source IP rather than Forwarded IP (X-Forwarded-For), WAF evaluates the IP address of the CDN edge node rather than the client. Once the aggregate threshold is reached, WAF blocks the CDN edge node, causing a widespread outage for all legitimate users traversing that edge node.