Skip to content
Notifications
Clear all

How do I verify my WAF is actually inspecting traffic?

3 Posts
2 Users
0 Reactions
34 Views
(@danielk)
Honorable Member
Joined: 3 months ago
Posts: 382
Topic starter   [#13649]

You've deployed a WAF ACL with managed rules. Logs show hits and blocks. How do you *prove* the traffic is actually being evaluated and not just bypassing the WAF? Logs can be misleading if the WAF isn't attached correctly or the traffic path is wrong.

Start with these concrete checks:

**1. Validate the resource association:**
Use the CLI to list attachments. Don't just trust the console.
```bash
aws wafv2 list-resources-for-web-acl --web-acl-arn
```
Confirm your ALB, API Gateway, or CloudFront distribution is listed.

**2. Force a block for diagnostics:**
Create a custom rule with a high-count rule action to block a specific test value (e.g., a header like `x-test-force-block: true`). Send a test request with that header. If it passes, your traffic isn't hitting the WAF.

**3. Inspect full request logs:**
Enable full request/response logging for your WAF ACL to an S3 bucket. Look for the `terminatingRuleId` and `action` fields. No terminating rule? Evaluation might not be happening.

**4. Network path verification:**
For CloudFront, the WAF is integrated directly. For ALB, ensure the WAF is attached at the listener level, not just the target group. For API Gateway, check the stage association.


Trust but verify, then don't trust.


   
Quote
(@davidm)
Reputable Member
Joined: 3 months ago
Posts: 270
 

Great points. The forced block with a custom header is smart. I did something similar when I set mine up, but I used a unique query string parameter instead, like `?test_block=1`. That way I didn't risk any weird header normalization.

A quick question about the logs: if the `terminatingRuleId` is missing, could that also mean all the rules just passed and nothing was triggered? Or is that field always populated when evaluation happens? Thanks for the clear steps.



   
ReplyQuote
(@danielk)
Honorable Member
Joined: 3 months ago
Posts: 382
Topic starter  

That's a solid point about query strings vs headers. Header normalization can be a pain if you have proxies that strip or modify them.

To your question: `terminatingRuleId` is only populated when a rule explicitly terminates evaluation (block, allow, or captcha). If all rules are set to Count or just pass without matching, that field will be absent. So a missing `terminatingRuleId` doesn't mean the WAF is bypassed -- it could just mean no rule triggered.

But here's the trap: you should also check the `webaclId` field in the log to make sure it matches *your* WAF ARN. If someone misconfigured a CloudFront distribution to point to a different WAF, you'd see logs with the wrong ACL ID. And if you see no logs at all from a request you know hit the endpoint, that's a bigger red flag.

Also, you can enable sampled requests in the WAF console to see if your test traffic shows up there. That's another quick sanity check independent of full logs.


Trust but verify, then don't trust.


   
ReplyQuote