Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

AWS WAF: Safe Handling of Legit User IPs Without Blind Allowlisting

0

I’m trying to solve a problem with AWS WAF and want a sanity check.

Goal: I don’t want to blindly allow “trusted” users, but I also don’t want false positives blocking real customers. I still want full WAF visibility and the ability to block if a legit user actually behaves like an attacker (DDoS , cross site scripting , etc).

My approach:

  • Lambda runs on a schedule, pulls active user IPs from DB, converts to CIDR, and syncs to a WAF IP set
  • In WAF:
    1. Known IPs get labeled (custom:legit-ip) and counted (no bypass)
    2. Managed rule groups (CRS, SQLi, IP reputation, etc.) run in COUNT mode for all traffic
    3. Final rule allows requests with custom:legit-ip label after evaluation
  • So legit users are never hard-blocked, but I still get logs + rule hits if they trigger something

This gives full visibility + no customer-facing outages, but still lets me detect suspicious behavior from subscribed users.

Question: Is this over-engineered? Is there a simpler or cleaner way to achieve the same thing (full inspection + no false-positive blocking for known users, but still able to act if they turn malicious)?

Topics
Security, Identity, & Compliance
Tags
AWS WAF
Language
English
asked 20 days ago59 views
1 Answer
3
Accepted Answer

Your logic is sound - avoiding "Blind Allowlisting" is a security best practice (Zero Trust principle). However, your implementation can be simplified to ensure you don't accidentally lower protection for all users.

1. The "Label-Override" Pattern (Recommended) Instead of putting all rules in COUNT mode (which weakens protection for anonymous traffic), use Rule Group Overrides specifically for your trusted IPs.

  • Rule 1 (Priority 10): Match your "Legit IP Set".
    • Action: Count
    • Add Label: trusted-user
  • Rule 2 (Priority 20): AWS Managed Rule Groups (Core Rule Set, etc.).
    • Action: Block (Standard)
    • Scope-down Statement: Only run this rule if the request DOES NOT have the label trusted-user.
  • Rule 3 (Priority 30): The same Managed Rule Groups, but with Action set to Count.
    • Scope-down Statement: Only run this rule if the request HAS the label trusted-user.

Why this is cleaner:

  • Security: Anonymous/untrusted traffic is still hard-blocked by default.
  • Visibility: You still get logs and labels for your trusted users' triggers without breaking their session.
  • Scalability: You don't need a final "Allow" rule that might accidentally bypass future security layers.

2. A Note on the Lambda Sync: Syncing DB IPs to WAF IP Sets works, but watch out for the WAF IP Set limit (typically 10k addresses). If your user base is larger, consider using Verified Access or injecting a Custom JWT/Cookie that the WAF can inspect. A signed token is often more reliable than a volatile IP address, especially for users on mobile networks or VPNs.

Conclusion: Not over-engineered, but focus on using Labels + Scope-down statements to keep your global security posture high while granting "immunity" to known IPs.

EXPERT
answered 19 days ago
  • Paul_L EXPERT
    19 days ago

    It's not particularly easy to add the managed rule groups twice as it can't be done in the console, plus it can push the WCU usage up. It sounds like the original use-case was not to block any traffic and focus on detection, in which case the proposed approach sounds good. If you wanted to block traffic hitting the managed rules - just add them once, and override them to count. Then add a custom rule looking for either specific managed rule group labels, or the label namespace AND NOT the legit-ip label, with a block action.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content