SiteFort security guide

Cloudflare Sync

How to connect Cloudflare to SiteFort and push firewall rules to the edge. Only relevant if the site's DNS is proxied through Cloudflare.

Security Guide Cloudflare Docs

Is Cloudflare Sync right for your site?

Cloudflare Sync pushes SiteFort's firewall rules out to Cloudflare, so bad traffic gets stopped before it ever reaches your server. Where this actually earns its keep is on sites taking real punishment, high-volume attacks, brute force waves, or scraping traffic heavy enough that even blocking it at WordPress level still costs you server load, since the request has already made it all the way to PHP by the time it gets rejected.

Is your site served through Cloudflare? If the site doesn't use Cloudflare at all, or Cloudflare is just handling DNS without proxying traffic, skip this page, there's nothing here for you yet. Sync only affects requests that actually pass through Cloudflare's network on their way to your server. If you're not sure, check whether the site's DNS records show the orange cloud icon (proxied) rather than grey (DNS only) in your Cloudflare dashboard. No Cloudflare account, or a grey cloud, means none of this applies.

What gets pushed to Cloudflare

Rule type	Pushed to Cloudflare edge?
Manual IP block and allow rules	Yes, when supported by your Cloudflare plan
Country rules	Yes, subject to plan limits
Manual user-agent block rules	Yes
Automatic edge blocks during active attacks	Yes, managed separately from manual rules
Built-in bot policy (Balanced, Maximum)	No. Bot policy runs at origin level only.
Rate limiting	No. Rate limiting runs at origin level only.

Think of Cloudflare Sync as additive, not a replacement. SiteFort's origin-level firewall keeps running for every request regardless. Sync just gives the same bad traffic an earlier exit, stopped at the edge instead of making it all the way to your PHP process and database first.

Sync settings

Go to SiteFort → Firewall → Cloudflare Sync. Before anything here works, Cloudflare needs to actually be connected first, see the Cloudflare connection guide if you haven't done that step yet.

Setting	Recommended	Watch out for
Cloudflare Sync	On, once credentials are verified	Rule changes push automatically once sync is on, no need to babysit it. Reach for Push now after a significant firewall change if you want it live immediately rather than waiting for the next automatic cycle.
Push now	Use after major rule changes	Nothing to worry about here. It just forces an immediate sync of everything eligible.

One quirk worth knowing about: wildcard IP patterns like 192.168.1.* only get enforced at the origin, they can get skipped during the actual Cloudflare push. If a rule genuinely needs edge-level enforcement, use a CIDR range instead of a wildcard.

Automatic edge blocks

Go to SiteFort → Firewall → Cloudflare Sync → Automatic Edge Blocks for Active Attacks.

When an IP keeps tripping firewall blocks, SiteFort can escalate it to a temporary Cloudflare edge block on its own, no manual rule needed. It's the difference between reacting to an attack in progress and having to notice it first, write a rule, and hope the damage was minimal in the meantime.

Setting	Recommended starting point	Watch out for
Block Threshold	10 to 20 triggers	Set this too low and you'll catch shared networks in the crossfire, offices, universities, corporate VPNs, anywhere dozens of people sit behind one IP. One person's bad behavior shouldn't cost everyone else on that network their access.
Observation Window	15 to 30 minutes	A shorter window reacts faster, but it also raises the odds of mistaking a legitimate traffic spike, a launch, an email blast, a sale, for an actual attack.
Edge Block Duration	Start with 30 to 60 minutes	Temporary is the right default for almost everything you'll see. Reach for longer durations only once an IP has shown a pattern of abuse across more than one observation window, not just a single bad burst.

WooCommerce and membership sites: start higher than the defaults on both threshold and observation window. A checkout flow, cart updates, and account page activity all generate legitimate request bursts that can look uncomfortably close to abuse if your thresholds are tuned for a quieter site.