SiteFort security guide

Firewall

Recommended settings for IP detection, bot protection, AI crawler control, scanner blocking, rate limiting, and traffic rules. Configure in this order and the firewall will protect without blocking the wrong people.

Security Guide Firewall Docs

Setup order

Open SiteFort → Firewall. This order isn't arbitrary. It's the order that avoids the two support tickets we see most often from firewall setups: an admin locked out of their own site, and a firewall that's technically "on" but banning the wrong IPs because it never knew who the real visitor was in the first place.

Verify IP Detection in Advanced before anything else. Every other decision the firewall makes depends on getting this right.
Enable Server-Level WAF if your server supports it.
Add Trusted IPs for your office, VPN, or agency network, so you can't accidentally lock yourself out later.
Turn on Protection settings: bot policy, AI crawler control, scanner detection, community blocklist, rate limiting.
Add Traffic Rules only when you have a specific reason: a known bad IP, a country you don't serve, or a bot causing a real problem.
Connect Cloudflare Sync if the site runs through Cloudflare. See the Cloudflare Sync guide.
Come back to the Traffic Log after a few days and adjust based on what actually shows up, not what you assumed would show up.

Do not skip IP Detection. If the site sits behind Cloudflare, a CDN, or a reverse proxy and IP Detection is wrong, the firewall bans, rate-limits, and trusts the wrong addresses, sometimes for weeks before anyone notices the pattern doesn't make sense. Fix this first, before anything else on this page.

IP Detection

Go to SiteFort → Firewall → Advanced → IP Detection.

Every firewall decision, every ban, every trusted allowlist entry, every country rule, comes down to one question: does SiteFort actually know which IP the request came from? On a plain server connection with nothing in front of it, that's easy. Behind Cloudflare or any other proxy, WordPress sees the proxy's IP by default unless something tells it to look at the right header instead. Get this step wrong and every other setting on this page is making decisions based on bad information, quietly, in a way that's hard to notice until you're staring at a ban list full of IPs that make no sense.

Your setup	Recommended detection setting
Standard hosting, no proxy or CDN	Automatic
Cloudflare in front of WordPress	Automatic, then apply the Cloudflare preset if prompted
Other CDN or reverse proxy	Automatic first. Switch to Manual only if Automatic reads the wrong IP

After choosing a mode, compare the IP SiteFort detects against your own actual public IP. If they match, you're good, the firewall is reading requests correctly. If they don't match, stop here. Don't turn on strict enforcement yet. Fix detection first, or you'll spend the next week troubleshooting symptoms instead of the actual cause.

Trusted IPs

Trusted IPs bypass every firewall rule you set up, which is exactly why this list should stay short and deliberate. Add your office's static IP, your agency or developer VPN, and any uptime monitor you actually rely on. Don't add broad IP ranges, shared VPN exit nodes, or anything you don't personally control, since a trusted entry is a permanent hole in whatever protection you just configured.

If you add your current IP as trusted, confirm it's actually static first. A residential or dynamic IP that changes later either becomes a dead rule protecting nobody, or worse, quietly trusts whichever stranger your ISP hands that address to next.

Protection settings

Go to SiteFort → Firewall → Protection.

This is where the actual day-to-day blocking happens, the settings doing the work while nobody's watching. Turn these on once IP Detection is verified and matching your real IP, not before.

Setting	Recommended	Watch out for
Bot and Crawler Policy	Balanced	Balanced blocks hacking tools, data scraping bots, and automated scripts, while Google, Bing, social previews, and major AI assistants (ChatGPT, Claude, Perplexity) stay allowed at every level. Move to Maximum only during active abuse, and check the Traffic Log afterward for anything legitimate that got caught in the wider net before you leave it there long-term.
Block AI Training Crawlers	Your call, off by default	A separate toggle sitting below the three policy levels. Turn it on if you don't want bots like GPTBot or ClaudeBot scraping your content to train a model. AI assistants acting on an actual visitor's request are unaffected either way, and it has no bearing on your Google or Bing ranking.
Detect and Block Scanners	On	Default is 3 failed probe attempts within 10 minutes, and that default works for most sites out of the box. If a legitimate monitoring tool starts tripping it, add that tool's IP to Trusted IPs rather than turning scanner detection off entirely, since the detection itself is doing exactly what it's supposed to.
Community IP Blocklist	On	Genuinely low-maintenance. Refreshes every 6 hours on its own, nothing to babysit here.
Rate Limiting	On, moderate values	Start moderate and watch the Traffic Log before tightening anything. A WooCommerce checkout, a membership account page, or an LMS course player all generate far more requests per real user than a static brochure site does, so a limit that's fine for one will choke the other.

Which bot policy level to use

Level	Use when
Basic	You're testing a new site with a lot of third-party integrations, or rolling out firewall protection cautiously for the first time and want to see how the site behaves before tightening further.
Balanced	The right default for most WordPress sites. Start here unless you have a specific reason not to.
Maximum	You're dealing with an active scraping attack, aggressive bot traffic, or sustained abuse from crawlers you don't recognize. Check the Traffic Log after switching, since this level is also the one most likely to catch a legitimate service you didn't know was crawling you.

What each level blocks

Category	Basic	Balanced	Maximum
Hacking & pentesting tools	Blocked	Blocked	Blocked
Data scraping bots	Not blocked	Blocked	Blocked
Automated scripts	Not blocked	Blocked	Blocked
Unrecognized bots	Not blocked	Not blocked	Blocked

Google, Bing, social previews, and major AI assistants like ChatGPT, Claude, and Perplexity stay allowed no matter which level you pick. Tightening this policy never puts your search visibility or social sharing at risk.

Should you block AI training crawlers?

This one comes down to what kind of site you're running, not a security judgment, so there's genuinely no universally right answer here.

Turn it on if your content is the product itself, publishers, course creators, original research, and you'd rather it not end up training someone else's model.
Leave it off if reach matters more to you than that concern, and AI training access doesn't bother you.

Either way, AI assistants responding to an actual visitor's request are never affected by this toggle, and it has no effect on how Google or Bing rank your site.

Rate limiting by site type

Site type	Recommended approach
Business or brochure site	Moderate limits work fine. Low logged-in activity makes this the easiest case to get right on the first try.
WooCommerce store	Start moderate, then actually test the cart, checkout, account pages, filters, and payment callbacks yourself. These generate real multi-request flows from legitimate customers, and a limit that looks reasonable on paper can still trip up a real checkout.
Membership or LMS	Set limits noticeably higher than you would for a brochure site. Someone actively working through course content or browsing a member area generates far more requests per session than a casual visitor.
Site under active attack	Tighten temporarily, then relax once traffic settles back down. Leaving tight limits in place permanently on a dynamic site just trades one problem for a slower, quieter one: real users hitting friction they can't explain.

Traffic rules

Go to SiteFort → Firewall → Rules.

Traffic rules exist for specific situations, not as a general-purpose "add more security" button: blocking a known bad IP, allowing a trusted service through, restricting access by country. Don't build these speculatively. Add a rule when the Traffic Log or a support request actually gives you a concrete reason to.

IP rules

Situation	Recommended action	Duration
IP repeatedly fails login attempts	Block	1 to 7 days
IP probing sensitive file paths	Block	30 days
Known malicious server or hosting range	Block	90 days or permanent
Your office, agency VPN, or developer IP	Allow (only if the IP is static)	Permanent
Trusted monitoring or integration service	Allow	Permanent

Allowed IPs bypass every firewall rule, including scanner detection, rate limiting, and the community blocklist. Only allowlist an IP you own or genuinely trust with that much access.

Bot and crawler rules

Add a bot rule when one specific crawler is chewing through server resources, scraping aggressively, or hammering the site in a way the Balanced policy just isn't catching on its own.

When you add a Trust rule for a crawler, be as specific as the User-Agent pattern allows. Avoid trusting anything broad like bot, Mozilla, or crawler, since a pattern that loose can end up trusting far more traffic than you meant to. Trusted patterns bypass every firewall check, so vague ones create a much bigger hole than intended.

Country blocking

Go to SiteFort → Firewall → Rules → Country.

Country blocking is genuinely useful in the right situation, but it's rarely the right first move against general attack traffic. Most attacks come from many countries at once, often from compromised servers sitting in countries you do legitimately serve, so blocking by country alone tends to catch less than people expect.

When to use block-selected mode

Block specific countries when the Traffic Log shows a sustained pattern of abuse from somewhere your site has no legitimate audience, and the volume is high enough to be worth the small risk of occasionally blocking a real visitor on a VPN or traveling through that region.

When to use allow-only mode

Allow-only mode blocks everything except the countries you explicitly select, including traffic with unknown or unresolvable origin. This makes sense for a local business site, a private portal, an internal tool, or anything with a genuinely narrow, well-defined audience.

Don't use allow-only mode if: you sell internationally, your customers travel, your team works remotely across countries, you rely on global payment gateways or shipping providers, or you're honestly not sure where your legitimate traffic actually comes from. Allow-only blocks all unknown-country traffic, and that includes plenty of real users on VPNs and corporate networks, not just the traffic you're trying to keep out.

GeoIP source

Country blocking needs a GeoIP source to work at all. If the site runs through Cloudflare, SiteFort can use Cloudflare's country headers and push country rules to the edge directly. If not, connect MaxMind GeoIP under Settings → Integrations and run Update Country Database before turning on any country rules.