Files
dotfiles/dot_agents/skills/cloudflare/references/ddos/gotchas.md
T
Prad Nukala 6406208b35 shell: fish functions -> ~/.local/bin executables + bash/zsh ports; manage ~/.agents
- 16 cross-shell utilities converted to sh/bash chezmoi executables:
  ai c2p cp-appid extract_agents fab gdc gh-sonr-org-migrate ghg-clone
  ghn gho git-summary launch_omp_livediff_overlay lc-elir mdcp mdp pj
  (ghg-clone not named ghg: unrelated cargo binary owns that name)
- cwd/history helpers stay per-shell: yy c cd clip-last + ghg/ghn/gho
  cd-wrappers in bash/functions/ and zsh/functions/, loaded by rc files
- fish keeps only shell-state functions; converted ones now hit PATH
- cp-appid ignore gating moved to .local/bin path
- dot_agents/skills: 82 skills materialized from dotstate storage so
  dot_claude skill symlinks resolve on fresh bootstrap; dotstate
  profile/symlinks.json released .agents/skills .bashrc .zshrc
2026-08-10 15:15:06 -04:00

3.8 KiB

DDoS Gotchas

Common Errors

"False positives blocking legitimate traffic"

Cause: Sensitivity too high, wrong action, or missing exceptions
Solution:

  1. Lower sensitivity for specific rule/category
  2. Use log action first to validate (Enterprise Advanced)
  3. Add exception with custom expression (e.g., allowlist IPs)
  4. Query flagged requests via GraphQL Analytics API to identify patterns

"Attacks getting through"

Cause: Sensitivity too low or wrong action
Solution: Increase to default sensitivity and use block action:

const config = {
  rules: [{
    expression: "true",
    action: "execute",
    action_parameters: { id: managedRulesetId, overrides: { sensitivity_level: "default", action: "block" } },
  }],
};

"Adaptive rules not working"

Cause: Insufficient traffic history (needs 7 days)
Solution: Wait for baseline to establish, check dashboard for adaptive rule status

"Zone override ignored"

Cause: Account overrides conflict with zone overrides
Solution: Configure at zone level OR remove zone overrides to use account-level

"Log action not available"

Cause: Not on Enterprise Advanced DDoS plan
Solution: Use managed_challenge with low sensitivity for testing

"Rule limit exceeded"

Cause: Too many override rules (Free/Pro/Business: 1, Enterprise Advanced: 10)
Solution: Combine conditions in single expression using and/or

"Cannot override rule"

Cause: Rule is read-only
Solution: Check API response for read-only indicator, use different rule

"Cannot disable DDoS protection"

Cause: DDoS managed rulesets cannot be fully disabled (always-on protection)
Solution: Set sensitivity_level: "eoff" for minimal mitigation

"Expression not allowed"

Cause: Custom expressions require Enterprise Advanced plan
Solution: Use expression: "true" for all traffic, or upgrade plan

"Managed ruleset not found"

Cause: Zone/account doesn't have DDoS managed ruleset, or incorrect phase
Solution: Verify ruleset exists via client.rulesets.list(), check phase name (ddos_l7 or ddos_l4)

API Error Codes

Error Code Message Cause Solution
10000 Authentication error Invalid/missing API token Check token has DDoS permissions
81000 Ruleset validation failed Invalid rule structure Verify action_parameters.id is managed ruleset ID
81020 Expression not allowed Custom expressions on wrong plan Use "true" or upgrade to Enterprise Advanced
81021 Rule limit exceeded Too many override rules Reduce rules or upgrade (Enterprise Advanced: 10)
81022 Invalid sensitivity level Wrong sensitivity value Use: default, medium, low, eoff
81023 Invalid action Wrong action for plan Enterprise Advanced only: log action

Limits

Resource/Limit Free/Pro/Business Enterprise Enterprise Advanced
Override rules per zone 1 1 10
Custom expressions ✗ ✗ ✓
Log action ✗ ✗ ✓
Adaptive DDoS ✗ ✓ ✓
Traffic history required - 7 days 7 days

Tuning Strategy

  1. Start with log action + medium sensitivity
  2. Monitor for 24-48 hours
  3. Identify false positives, add exceptions
  4. Gradually increase to default sensitivity
  5. Change action from log → managed_challenge → block
  6. Document all adjustments

Best Practices

  • Test during low-traffic periods
  • Use zone-level for per-site tuning
  • Reference IP lists for easier management
  • Set appropriate alert thresholds (avoid noise)
  • Combine with WAF for layered defense
  • Avoid over-tuning (keep config simple)

See patterns.md for progressive rollout examples.