17.3 Web Application Firewall (WAF) Architecture, Audit Logs, Benefits & Limitations
Key Takeaways
- A WAF inspects HTTP and HTTPS at Layer 7 against request content, which is what distinguishes it from a network firewall operating on the 5-tuple and from an IPS matching generic network signatures.
- WAFs deploy as a reverse proxy, a transparent bridge, a host-based module such as ModSecurity inside Apache or IIS, or a cloud service, and only the reverse-proxy and cloud modes can terminate TLS to inspect encrypted request bodies.
- The WAF audit log is frequently the only place the full request body is preserved, because standard IIS and Apache access logs record the URI and query string but not POST content.
- Negative security models block known-bad signatures such as the OWASP ModSecurity Core Rule Set and miss novel attacks, while positive models allow only explicitly permitted input and miss nothing but require per-application tuning.
- A WAF cannot see attacks that bypass it entirely by reaching the origin server directly, and it cannot detect business-logic abuse such as parameter tampering, which is why origin access controls and application-level logging remain mandatory.
17.3 Web Application Firewall (WAF) Architecture, Audit Logs, Benefits & Limitations
Quick Answer: Blueprint Domain 3 pairs Web Application Firewall (WAF) and benefits and limitations of WAF with the MySQL database topics. A WAF is a Layer 7 control that inspects HTTP/HTTPS request and response content — unlike a network firewall, which decides on the 5-tuple, and unlike a generic IPS, which matches network-level signatures. For the examiner the operational point is blunt: the WAF audit log is frequently the only artifact that preserved the full request body, because IIS and Apache access logs record the URI and query string but not POST content.
WAF Position in the Security Stack
| Control | Layer | Decision basis | Blind to |
|---|---|---|---|
| Network firewall | 3–4 | Source/destination IP, port, protocol, state | Everything inside an allowed HTTP session |
| IPS/IDS | 3–7 | Network signatures, protocol anomalies | Encrypted traffic without decryption; application semantics |
| WAF | 7 | HTTP method, URI, headers, cookies, full body, response content | Non-HTTP protocols; attacks that never traverse it |
| RASP | Inside the app runtime | Actual code execution paths | Nothing in-process, but requires app instrumentation |
Deployment Modes
| Mode | How it sits | Forensic consequence |
|---|---|---|
| Reverse proxy | All traffic terminates on the WAF, which re-originates to the origin | Sees decrypted bodies; rewrites the client IP, so the origin must honor X-Forwarded-For or every log line shows the WAF's address |
| Transparent bridge / inline | Layer 2 device in the path | No IP rewriting; cannot decrypt without keys |
| Host-based module | ModSecurity inside Apache/Nginx/IIS | Sees traffic already decrypted by the web server; consumes origin CPU |
| Cloud / CDN-integrated | Cloudflare, AWS WAF, Azure Front Door, Akamai, Imperva | Scales and absorbs volumetric attack; logs live with the provider and must be exported under retention policy |
[!WARNING] The reverse-proxy client-IP problem ruins timelines. When a WAF or CDN fronts the site, every origin access-log entry records the proxy's address unless the origin is configured to log
X-Forwarded-FororCF-Connecting-IP. An examiner who attributes an attack to the WAF's own IP has produced a false finding. Always verify which header carries the true client address and whether the origin trusts it.
Security Models
Negative (blocklist) model — block what matches known-bad patterns. The reference implementation is the OWASP ModSecurity Core Rule Set (CRS).
- Benefit: deploys immediately with broad coverage and no application knowledge.
- Limitation: cannot stop a novel attack or a well-obfuscated variant of a known one.
Positive (allowlist) model — permit only explicitly defined input: each parameter's type, length, character set, and range.
- Benefit: blocks unknown attacks by construction.
- Limitation: requires a learned or hand-built profile per application and breaks on every legitimate application change.
Anomaly scoring (CRS 3.x default) is the pragmatic middle: each matched rule adds to a score, and the request is blocked only when the score crosses an inbound threshold. This reduces false positives and, forensically, means a logged rule match is not necessarily a blocked request — the examiner must read the score and the final disposition, not the presence of an alert.
ModSecurity Rules and Audit Logs
A rule has the form:
SecRule REQUEST_URI|ARGS|REQUEST_BODY|REQUEST_HEADERS "@rx (?i)(union[\s\x00]+select)" \
"id:942100,phase:2,block,t:none,t:urlDecodeUni,t:lowercase,\
msg:'SQL Injection Attack Detected',severity:'CRITICAL',\
tag:'attack-sqli',logdata:'Matched Data: %{MATCHED_VAR} in %{MATCHED_VAR_NAME}'"
Phases run in order: 1 request headers, 2 request body, 3 response headers, 4 response body, 5 logging. A rule inspecting REQUEST_BODY must be in phase 2 — a phase-1 rule simply cannot see the body, which is a common misconfiguration finding.
SecRuleEngine has three values that decide what the logs will contain:
| Setting | Behavior | Forensic meaning of a log entry |
|---|---|---|
On | Detect and block | An entry with Access denied means the attack was stopped |
DetectionOnly | Detect, allow through | An entry means the attack reached the application — check the origin for impact |
Off | No inspection | No entries at all; absence of alerts proves nothing |
Audit Log Structure
ModSecurity's audit log is segmented by letter, and each segment answers a different forensic question:
| Part | Contents |
|---|---|
| A | Audit log header: unique transaction ID, timestamp, source IP and port, destination IP and port |
| B | Request headers |
| C | Request body — the segment no access log preserves |
| E | Intended response body |
| F | Final response headers |
| H | Trailer: matched rule IDs, messages, anomaly score, and the action taken |
| K | Full list of every rule that matched |
Configure SecAuditLogParts ABCEFHKZ to retain all of it; the default omits C in some distributions, which silently discards exactly the evidence a POST-based injection or XXE investigation requires.
Cloud WAFs express the same data as JSON — AWS WAF logs to Kinesis Firehose with terminatingRuleId, action, httpRequest.clientIp, and matched rule details; Cloudflare's firewall events carry RuleID, Action, ClientIP, and ClientRequestPath.
Why the WAF Log Is Often the Decisive Artifact
- It preserves the POST body. An XXE
<!DOCTYPE ... <!ENTITY SYSTEM ...>, a SQL injection in a JSON body, or a serialized-object payload never appears in an IIS or Apache access log. Part C of the audit log is the only copy. - It records the decision. The trailer states whether the request was blocked and at what anomaly score, which establishes exposure rather than mere attempt.
- It survives origin log rotation. WAF logs often ship to a separate SIEM with longer retention than the web server's own logs.
- It timestamps the campaign. Rule-match counts per source IP over time distinguish a single opportunistic scan from a sustained, targeted campaign.
Limitations the Examiner Must State
| Limitation | Consequence for the investigation |
|---|---|
| Bypass via direct origin access | If the origin server's IP is reachable without going through the cloud WAF, the attacker skips inspection entirely and no WAF log exists. Origin IP leakage through DNS history, mail headers, or certificate transparency logs is the usual cause. |
| Encrypted traffic without termination | A bridge-mode WAF without TLS keys inspects nothing. |
| Business-logic attacks | Parameter tampering, IDOR, and workflow abuse are syntactically valid requests. A WAF has no concept of the correct price or the right owner, so it cannot detect them. |
| Evasion | Case variation, comment insertion (UN/**/ION), double and mixed encoding, HTTP parameter pollution, chunked transfer encoding, and oversized bodies exceeding SecRequestBodyLimit all evade naive rules. |
| Zero-day and novel payloads | A negative model matches only what it knows. |
| Client-side attacks | DOM-based XSS executes entirely in the browser; the malicious payload may never traverse the WAF. |
| False positives and tuning drift | Rules disabled to fix a business breakage create permanent blind spots. Always retrieve the ruleset and exclusion list as it stood at the incident time, not as it stands today. |
| Insider and authenticated abuse | A legitimate authenticated user extracting data at scale generates perfectly valid requests. |
[!IMPORTANT] "The WAF shows no alerts" is not a finding of no attack. It is consistent with
SecRuleEngine Off, a disabled or excluded rule, a direct-to-origin bypass, a business-logic attack the WAF cannot model, or an evasion the ruleset did not match. The examiner must establish the WAF's configuration, engine mode, ruleset version, and exclusion list at the time of the incident before drawing any negative inference from log silence.
Investigative Workflow
- Identify deployment mode and whether TLS was terminated at the WAF.
- Retrieve the ruleset version, engine mode, and exclusion list effective at the incident time from configuration management.
- Export audit log parts A, B, C, H, K for the window and hash the export.
- Separate attempted from reached-the-application: entries under
DetectionOnly, or entries whose anomaly score fell below the blocking threshold, mean the request was served. - Join the WAF transaction ID to the origin access log entry, using the true client IP from
X-Forwarded-For, to confirm what the application actually returned. - Confirm whether the origin was reachable directly, which determines whether the WAF log set is complete or partial.
An XXE attack is suspected against a SOAP endpoint. The Apache access logs for the window show only POST /api/orders with status 200 and no payload, and the application has no request logging. Which artifact preserves the attack payload itself?
An e-commerce breach investigation finds that an attacker purchased 400 items at $1.00 each by intercepting checkout requests and modifying a hidden price field. The WAF ran in blocking mode with a fully updated Core Rule Set and logged nothing for those sessions. What explains the silence?
After a cloud WAF was deployed, an investigation finds attack traffic in the origin Apache logs that the WAF never recorded, and every legitimate request in the origin log shows the WAF's IP address as the client. What two configuration problems does this reveal?