thedixitjain Implementing Cloud WAF Rules
When to Use
- When deploying new web applications or APIs behind cloud load balancers requiring OWASP protection
- When application penetration testing reveals SQL injection, XSS, or other injection vulnerabilities
- When experiencing brute force, credential stuffing, or bot attacks against authentication endpoints
- When compliance requirements mandate a WAF for PCI-DSS or similar standards
- When tuning WAF rules to reduce false positives blocking legitimate application traffic
Do not use for network-level DDoS protection (use AWS Shield or Azure DDoS Protection), for API authentication design (see managing-cloud-identity-with-okta), or for application code-level security fixes (WAF is a compensating control, not a replacement for secure code).
Prerequisites
- AWS ALB/CloudFront, Azure Application Gateway, or Cloudflare configured as the application entry point
- Application traffic logs for baseline analysis before WAF deployment
- Test environment for validating WAF rules before production enforcement
- Understanding of application request patterns to minimize false positives
Workflow
Step 1: Deploy Managed Rule Sets
Enable cloud provider managed rule sets that cover OWASP Top 10 vulnerabilities. Start in Count (detection) mode before switching to Block (prevention) mode.
# AWS WAF: Create Web ACL with AWS Managed Rules
aws wafv2 create-web-acl \
--name production-waf \
--scope REGIONAL \
--default-action '{"Allow": {}}' \
--visibility-config '{
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "production-waf"
}' \
--rules '[
{
"Name": "AWSManagedRulesCommonRuleSet",
"Priority": 1,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesCommonRuleSet"
}
},
"OverrideAction": {"Count": {}},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "CommonRuleSet"
}
},
{
"Name": "AWSManagedRulesSQLiRuleSet",
"Priority": 2,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesSQLiRuleSet"
}
},
"OverrideAction": {"Count": {}},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "SQLiRuleSet"
}
},
{
"Name": "AWSManagedRulesKnownBadInputsRuleSet",
"Priority": 3,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesKnownBadInputsRuleSet"
}
},
"OverrideAction": {"Count": {}},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "KnownBadInputs"
}
}
]'
Step 2: Create Custom Rate Limiting Rules
Deploy rate-based rules to protect login endpoints against brute force and credential stuffing attacks.
# Rate limiting rule for login endpoint (100 requests per 5 minutes per IP)
aws wafv2 update-web-acl \
--name production-waf \
--scope REGIONAL \
--id <web-acl-id> \
--lock-token <lock-token> \
--default-action '{"Allow": {}}' \
--rules '[
{
"Name": "RateLimitLogin",
"Priority": 0,
"Statement": {
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP",
"ScopeDownStatement": {
"ByteMatchStatement": {
"FieldToMatch": {"UriPath": {}},
"PositionalConstraint": "STARTS_WITH",
"SearchString": "/api/auth/login",
"TextTransformations": [{"Priority": 0, "Type": "LOWERCASE"}]
}
}
}
},
"Action": {"Block": {"CustomResponse": {"ResponseCode": 429}}},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitLogin"
}
}
]'
Step 3: Configure Geo-Blocking and IP Reputation
Block traffic from countries where the application has no legitimate users and leverage IP reputation lists to block known malicious sources.
# AWS WAF: Geo-blocking rule
# Block countries not in the allowed list
aws wafv2 create-ip-set \
--name blocked-ips \
--scope REGIONAL \
--ip-address-version IPV4 \
--addresses "198.51.100.0/24" "203.0.113.0/24"
# Add Amazon IP Reputation rule
# AWSManagedRulesAmazonIpReputationList blocks IPs flagged by AWS threat intelligence
Step 4: Tune Rules to Reduce False Positives
Analyze WAF logs in Count mode to identify legitimate requests being flagged. Create rule exceptions for specific URI paths or request patterns.
# Enable WAF logging to S3
aws wafv2 put-logging-configuration \
--logging-configuration '{
"ResourceArn": "arn:aws:wafv2:us-east-1:123456789012:regional/webacl/production-waf/id",
"LogDestinationConfigs": ["arn:aws:s3:::waf-logs-bucket"],
"RedactedFields": [{"SingleHeader": {"Name": "authorization"}}]
}'
# Query WAF logs with Athena to find false positives
# Find rules triggered most frequently for legitimate traffic
cat << 'EOF' > waf-analysis.sql
SELECT
terminatingRuleId,
httpRequest.uri,
httpRequest.httpMethod,
COUNT(*) as block_count
FROM waf_logs
WHERE action = 'BLOCK'
AND timestamp > date_add('day', -7, now())
GROUP BY terminatingRuleId, httpRequest.uri, httpRequest.httpMethod
ORDER BY block_count DESC
LIMIT 20
EOF
# Exclude specific rule from managed rule set that causes false positives
# Example: Exclude SizeRestrictions_BODY for file upload endpoint
aws wafv2 update-web-acl \
--name production-waf \
--scope REGIONAL \
--id <web-acl-id> \
--lock-token <lock-token> \
--rules '[{
"Name": "AWSManagedRulesCommonRuleSet",
"Priority": 1,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesCommonRuleSet",
"ExcludedRules": [{"Name": "SizeRestrictions_BODY"}]
}
},
"OverrideAction": {"None": {}},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "CommonRuleSet"
}
}]'
Step 5: Switch to Block Mode After Validation
After 7-14 days of Count mode with acceptable false positive rates, switch managed rules to Block mode for active protection.
# Change OverrideAction from Count to None (use rule group's default Block action)
# Update each managed rule group from {"Count": {}} to {"None": {}}
# Monitor CloudWatch metrics for sudden changes in blocked request volume
Key Concepts
| Term | Definition |
|---|---|
| Web ACL | Web Access Control List defining the set of rules evaluated against every HTTP request to a protected resource |
| Managed Rule Group | Pre-configured rule set maintained by the cloud provider or third-party vendor covering common attack patterns |
| Rate-Based Rule | WAF rule that tracks request rates per IP address and blocks IPs exceeding the threshold within a time window |
| Count Mode | WAF action that logs matching requests without blocking them, used for rule validation before enforcement |
| Rule Priority | Numerical ordering determining which rules are evaluated first; lower numbers have higher priority |
| Custom Response | WAF capability to return specific HTTP status codes and headers when blocking requests |
| Scope-Down Statement | Condition that narrows a rate-based rule to specific URI paths, methods, or headers |
| False Positive | Legitimate request incorrectly blocked by a WAF rule, requiring rule tuning or exclusion |
Tools & Systems
- AWS WAF: Cloud-native WAF integrated with ALB, CloudFront, API Gateway, and AppSync
- Azure WAF: Web application firewall on Application Gateway or Front Door with OWASP CRS rule sets
- AWS Firewall Manager: Centralized WAF policy management across multiple AWS accounts in an Organization
- WAF Security Automations: AWS solution that deploys Lambda-based automated WAF rule updates based on log analysis
- CloudWatch Metrics: Monitoring dashboard for tracking WAF rule match rates, block counts, and allowed requests
Common Scenarios
Scenario: Credential Stuffing Attack Against Authentication API
Context: An e-commerce application experiences 50,000 login attempts per hour from a botnet using stolen credential lists. The attacker rotates source IPs every few minutes to evade simple IP-based blocking.
Approach:
- Deploy rate-based rules limiting login endpoint requests to 10 per 5 minutes per IP
- Enable AWS WAF Bot Control managed rule group to detect automated request patterns beyond IP rotation
- Add a custom rule requiring valid CAPTCHA tokens for login requests exceeding 5 failures
- Implement IP reputation blocking using AWSManagedRulesAmazonIpReputationList
- Create a custom rule matching on User-Agent patterns common to credential stuffing tools
- Monitor blocked request metrics and adjust thresholds based on legitimate traffic patterns
Pitfalls: Setting rate limits too aggressively blocks legitimate users behind shared NAT IPs. Blocking by User-Agent alone is easily bypassed by rotating agent strings.
Output Format
Cloud WAF Configuration Report
================================
Web ACL: production-waf
Scope: Regional (us-east-1)
Protected Resources: ALB (arn:aws:elasticloadbalancing:...)
Report Date: 2025-02-23
RULE CONFIGURATION:
[P0] RateLimitLogin - BLOCK (100 req/5min/IP)
[P1] AWSManagedRulesCommon - BLOCK (1 exclusion: SizeRestrictions_BODY)
[P2] AWSManagedRulesSQLi - BLOCK
[P3] AWSManagedRulesKnownBad - BLOCK
[P4] AWSManagedRulesBotControl - COUNT (evaluation phase)
[P5] GeoBlockRule - BLOCK (12 countries blocked)
TRAFFIC ANALYSIS (Last 7 Days):
Total Requests: 2,847,293
Allowed: 2,791,456 (98.0%)
Blocked: 51,234 (1.8%)
Counted: 4,603 (0.2%)
TOP BLOCKED RULES:
RateLimitLogin: 23,456 blocks (45.8%)
SQLi Detection: 8,234 blocks (16.1%)
CommonRuleSet (XSS): 7,891 blocks (15.4%)
GeoBlockRule: 6,543 blocks (12.8%)
KnownBadInputs: 5,110 blocks (10.0%)
FALSE POSITIVE ANALYSIS:
Reported False Positives: 3
Confirmed False Positives: 1 (SizeRestrictions_BODY for /api/upload)
Action Taken: Rule exclusion applied
Source: mukul975/Anthropic-Cybersecurity-Skills → skills/implementing-cloud-waf-rules/SKILL.md