Layer-7 protection: OWASP rules, custom rules, bot mitigation, and rate limiting.

Deployment topology¶

WAF sits between CDN (or LB) and origin:

Client → CDN → WAF → LB → Origin

Cloud Digit WAF is a managed service; you attach it to a CDN distribution or LB.

IAM¶

Role	Can do
waf.viewer	View rules, hits, logs
waf.responder	Add temporary allowlist/blocklist during incidents
waf.rule-author	Manage rules and rule sets
waf.admin	Above + change managed-rule subscriptions

Managed rule sets¶

Rule set	What it covers
core (OWASP CRS)	OWASP Top 10 — SQLi, XSS, RCE, etc.
bots	Known bad bots, scrapers
geo	Block traffic from configurable countries
payment	PCI-DSS-relevant patterns
bd-specific	Patterns specific to local threats

Enable per workload — most apps want core + bots; payment apps add payment.

Custom rules¶

bash cd waf rule create \ --name block-admin-from-foreign \ --priority 100 \ --condition "request.uri starts_with '/admin' AND geo.country != 'BD'" \ --action block

Custom rules execute before managed rules; use sparingly to avoid managed-rule bypass.

Rate limiting¶

Per-IP, per-endpoint:

bash cd waf rate-limit set \ --path "/api/login" \ --limit 10 \ --window 60s \ --action challenge

Action: block rejects; challenge serves a CAPTCHA; log only.

Logging¶

WAF events stream to S3 + SIEM. Sample rate configurable; 100% for compliance, sub-sample for low-value traffic.

Related¶

• WAF — Operation
• WAF — Troubleshooting
• DDoS Premium

Metrics¶

Metric	Healthy	Alert
waf.requests_per_sec	matches traffic
waf.blocked_per_sec	< 0.5% of total	spikes (real attack or false positive surge)
waf.challenge_solved_pct	> 90%	< 70% (challenges too hard or bots)
waf.rule_hit_rate (per rule)	varies	dropped to 0 (rule may be broken)
waf.bypass_attempts_24h	varies	spikes

Tuning false positives¶

For each rule with > 1% legitimate-traffic block rate:

1. Review samples in waf logs
2. Decide: tune the rule, add an exception, or accept the false-positive cost
3. Test in monitor mode before flipping to block:

```bash cd waf rule mode --rule-id --mode monitor # log, don't block

After review:¶

cd waf rule mode --rule-id --mode block ```

Rule set updates¶

Managed rule sets release new rules weekly. Default: auto-apply after 7-day soak in monitor mode. Customize:

bash cd waf managed-rule-set config --name core --auto-apply-delay 14d

Major changes (new rule categories) are opt-in.

Tarpit / challenge for suspicious¶

Instead of blocking, slow down suspected attackers:

bash cd waf rule action set \ --rule-id <id> \ --action challenge # CAPTCHA / proof-of-work

Real users solve in 2-3 seconds; bots usually fail.

Bot management¶

Tier the response by bot type: - Good bots (Googlebot, etc.): allow - Known bad bots: block - Unknown / unclear: challenge

bash cd waf bot-policy set --good-bots allow --bad-bots block --unknown challenge

Audit and compliance¶

Quarterly export of WAF logs to compliance archive:

bash cd waf logs export --since 2026-04-01 --until 2026-04-30 --to s3://acme-compliance/waf/

PCI-DSS requires this; other regulators may require similar.

Related¶

• WAF — Administration
• WAF — Troubleshooting

Legitimate users blocked¶

waf.blocked_per_sec includes false positives. Investigate:

```bash cd waf logs --filter "action=block" --since 1h --limit 50

Sample requests: are they really attacks?¶

```

If false positives: 1. Identify the firing rule 2. Switch rule to monitor mode temporarily 3. Add an exception (often a path or user-agent allowlist) 4. Return rule to block mode

Rule update broke production¶

After auto-applying a new managed rule, production app traffic gets blocked:

```bash cd waf managed-rule-set rollback --name core --to-version

Immediate; restores prior state¶

```

Increase the auto-apply soak period to prevent recurrence.

Bypass via legitimate-looking request¶

Attacker found a rule gap — request looks normal but achieves the attack effect. Symptoms: backend logs show suspicious activity, but WAF logs show "passed."

• Analyze the attack request pattern
• Add a custom rule matching the specific exploit shape
• Engage Cloud Digit's WAF response team if pattern is novel

Performance impact¶

WAF adds 1–10 ms latency per request. If your latency metrics jumped after enabling WAF:

• Some rules are expensive (regex-heavy custom rules). Profile with cd waf rule perf
• High-traffic endpoints: simplify rules
• Move static-asset paths out of WAF inspection (set passthrough rule for /assets/*)

Challenge wall — users complain about CAPTCHA¶

CAPTCHA appears on legitimate users: - Challenge action triggered by too-aggressive rule - Bot management classifying real users as suspicious - Threshold for rate-limit challenge too low

Check waf.challenge_solved_pct — < 70% means real users are struggling. Adjust.

Rate limit blocking legitimate burst¶

A planned promo email caused everyone to hit /api/login simultaneously, all rate-limited:

• Pre-arrange via cd waf rate-limit pre-event
• Add allowlist for known good IP ranges
• Switch action to challenge (lets real users through)

Logs missing entries¶

WAF samples logs by default. If you need 100% for compliance:

```bash cd waf config set --log-sample-rate 1.0

Increases storage and bandwidth costs proportionally¶

```

Related¶

• WAF — Administration
• WAF — Operation