Home · Start Here · Reference Map

• Bridges CSF/LFD actions to Cloudflare firewall controls.
• Essential when reverse-proxy topology prevents direct origin-side attacker IP blocking.
• Automatic trigger sync is intentionally limited (mainly LF_MODSEC and LF_CXS).

Related guide: Integrations-Guide

Behind Cloudflare, origin servers often see Cloudflare edge IPs rather than client attacker IPs.

Even when logs contain the real client IP, origin iptables still receives traffic from Cloudflare edges. This integration pushes enforcement to Cloudflare where client-IP decisions can be applied.

Before enabling, confirm all of the following:

1. Real client IP restoration is working (mod_cloudflare, mod_remoteip, or equivalent).
2. Cloudflare edge IP ranges are in csf.ignore to prevent accidental edge blocking:
   • https://www.cloudflare.com/ips/

   ⚠ Staleness risk: Cloudflare IP ranges change periodically. Do not rely on previously hardcoded ranges. Fetch the current list from the URL above before each deployment, and consider scheduling periodic re-sync (e.g., weekly cron) to catch upstream changes. See also Deployment Runbooks — Runbook 3 for a dynamic-fetch script alternative.

3. URLGET is set to 2 (LWP) in csf.conf.
4. LF_TRIGGER is disabled (must not be used with this feature).
5. CF_TEMP is sized to your Cloudflare rule-capacity limits.
6. Integration is user-level scoped (not full zone-level orchestration).
7. If using the Cloudflare cPanel user plugin, use v7+.

To prevent the staleness risk associated with Cloudflare's dynamic edge IP ranges, it is recommended to automate the fetch and sync process.

Add this to a weekly cron job or your deployment script:

#!/usr/bin/env bash
set -euo pipefail

tmp4=$(mktemp)
tmp6=$(mktemp)
trap 'rm -f "$tmp4" "$tmp6"' EXIT

curl -fsS https://www.cloudflare.com/ips-v4 > "$tmp4"
curl -fsS https://www.cloudflare.com/ips-v6 > "$tmp6"

for file in /etc/csf/csf.allow /etc/csf/csf.ignore; do
  cp "$file" "${file}.bak.$(date +%Y%m%d%H%M%S)"

  awk '
    BEGIN{skip=0}
    /^# BEGIN CLOUDFLARE AUTO$/ {skip=1; next}
    /^# END CLOUDFLARE AUTO$/   {skip=0; next}
    skip==0 {print}
  ' "$file" > "${file}.new"

  {
    cat "${file}.new"
    echo "# BEGIN CLOUDFLARE AUTO"
    sed 's/$/ # Cloudflare edge v4/' "$tmp4"
    sed 's/$/ # Cloudflare edge v6/' "$tmp6"
    echo "# END CLOUDFLARE AUTO"
  } > "$file"

  rm -f "${file}.new"
done

csf -ra

Note: Frequent reloads (csf -ra) can cause brief connection blips. Schedule this during low-traffic windows, and keep console/IPMI access ready before automation touches firewall files.

Automatic LFD → Cloudflare sync requires enough context to identify the affected domain/user mapping.

1. All LFD-synced Cloudflare blocks are treated as temporary.
2. LFD per-trigger temp/perm behavior is overridden for Cloudflare sync; CF_TEMP governs duration.
3. If PERMBLOCK is used, the last tempblock can remain and may require manual Cloudflare cleanup.
4. Restarting CSF can re-create prior temporary Cloudflare entries for LFD to clear after restart.

Cloudflare plan tier limits the number/type of firewall rules that can be created.

Practical implications:

• Keep CF_TEMP realistic to prevent stale rule accumulation.
• Avoid broad automation until rule-volume behavior is observed.
• Review and prune rules during incident spikes.

# List rules
csf --cloudflare list all [user1,user2,...]

# Add block/challenge/whitelist rule (manual Cloudflare action)
csf --cloudflare add challenge 11.22.33.44 [user1,user2,...]

# Delete rule by target
csf --cloudflare del 11.22.33.44 [domain,domain2,...]

# Add temporary allow/deny to BOTH CSF and Cloudflare, synchronized by CF_TEMP
csf --cloudflare tempadd deny 11.22.33.44 [user1,user2,...]

• csf --cloudflare add ... creates Cloudflare rules directly and does not behave like normal LFD-managed temporary lifecycle.
• csf --cloudflare tempadd ... creates synchronized temporary entries in both CSF and Cloudflare.
• For synced temp removals, use normal CSF temp removal operations (for example csf --tr IP) to clear both sides.

Cloudflare rule targets can be:

• IP address
• 2-letter country code
• CIDR range

Plan-based limits apply (for example, country-level blocking capability and CIDR limitations may differ by account tier). In classic CSF Cloudflare integration behavior, country-code block is typically enterprise-only, while allow/challenge are more broadly available; CIDR targeting is commonly constrained (for example /16 and /24 patterns).

1. Validate real client IP visibility in web logs.
2. Add Cloudflare edge ranges to csf.ignore.
3. Configure/verify CF_ENABLE, CF_TEMP, URLGET=2, and LF_TRIGGER disabled.
4. Test with one controlled tempadd entry.
5. Confirm add + expiry + cleanup behavior before broad rollout.
6. Only then rely on automatic LF_MODSEC/LF_CXS synchronization.

• Expecting all LFD triggers to create Cloudflare rules.
• Mixing manual add rules with auto/temp sync without cleanup policy.
• Underestimating Cloudflare rule-count limits for active attack windows.
• Not restoring real client IP at the web/app layer first.

Last reviewed: 2026-02-27

← UI Skinning and Mobile View · InterWorx →