How to Set Up a Website Firewall: WAF Options for WordPress and Shared Hosting

If you searched how to set up a website firewall and landed on pages about blocking websites in Windows Firewall, you are not alone. Those guides cover a completely different thing: filtering traffic on a single computer. What protects your public website from bots, SQL injection, brute force logins and vulnerability scanners is a Web Application Firewall (WAF).

This guide explains the three places a WAF can live (plugin, cloud, server), gives you the actual setup steps for each on a typical small business site, and helps you pick one primary layer instead of stacking three overlapping tools that fight each other and slow your pages down.

First, Clear Up the Confusion: Which Firewall Do You Actually Need?

Type of firewall	What it protects	Is it what you need?
Windows Defender Firewall / macOS firewall	One laptop or desktop	No, if you want to protect your website
Network firewall (router, UTM appliance)	Your office network	Useful, but unrelated to your hosting
Web Application Firewall (WAF)	Your website and its login, forms and database	Yes, this is the one

A WAF sits between visitors and your site, inspects each HTTP request, and blocks the ones that match known attack patterns or your own rules. Everything below is about setting up that WAF.

The Three WAF Layers, Compared

There are only three realistic places to filter traffic for a small business site. Understanding the order they run in is the key to not duplicating work. This write-up is worth a look.

Request path: Visitor → Cloud WAF (DNS level) → Server rules (ModSecurity / hosting firewall) → Plugin WAF (inside WordPress) → your page.

Layer	Examples	Blocks traffic	Strengths	Weaknesses
Cloud WAF	Cloudflare, Sucuri, host-provided WAF/CDN bundles	Before it reaches your server	Absorbs DDoS and bot floods, saves CPU, adds CDN caching	Needs DNS change, origin IP must be hidden, some learning curve
Server-level rules	ModSecurity + OWASP CRS, Imunify360, CSF, .htaccess, fail2ban	At the web server, before PHP runs	Fast, protects every site on the account, no plugin overhead	Limited control on shared hosting, false positives can break forms
Plugin WAF	Wordfence, Solid Security, All-In-One Security	Inside WordPress (after PHP loads)	Knows WordPress context, malware scanning, 2FA, login limiting	Uses your server resources, attack already reached your site

Why Stacking All Three Is a Mistake

• Duplicate rate limiting: a cloud WAF and a plugin both counting login attempts can lock out real customers or your own team.
• Broken IP detection: if the plugin does not read the real visitor IP forwarded by the cloud WAF, it sees every visitor as one IP and either blocks everyone or nobody.
• Wasted PHP time: a plugin firewall runs on every uncached request. On shared hosting that is measurable in Time To First Byte.
• Debugging nightmare: when a contact form stops working, you now have three places to check.

The rule we apply for clients: one primary blocking layer, plus non-overlapping extras (malware scanning, 2FA, file change monitoring) from a second tool.

Which Layer Should You Pick? A 60-Second Decision Guide

Your situation	Primary firewall	Secondary (non-overlapping)
Brochure site or small blog on cheap shared hosting	Cloud WAF (free tier is enough)	Security plugin in scan-only mode + 2FA
WooCommerce store, real revenue, checkout traffic	Paid cloud WAF with managed rules	Server-side malware scanning, off-site backups
Managed WordPress host that already includes a WAF	Keep the host WAF, tune it	2FA + login URL hardening only
You cannot change DNS (client controls it)	Plugin WAF in extended protection mode	Ask host to enable ModSecurity
VPS or dedicated server with root access	Server-level: ModSecurity + OWASP CRS	Cloud WAF in front for DDoS, plugin off

Option 1: How to Set Up a Cloud WAF (Recommended for Most Small Sites)

A cloud WAF filters traffic at the DNS level, so malicious requests never touch your hosting account. This is the best value for shared hosting because it also caches static files.

Setup Steps

1. Back up first. Take a full file and database backup and store it off the server. Never touch DNS without a restore point.
2. Note your origin IP. Find your server IP in your hosting panel and write it down. You will need it and you will later hide it.
3. Create the account and add your domain. The provider scans your existing DNS records and imports them automatically.
4. Verify every DNS record. Check A, AAAA, CNAME, MX and TXT records against your current zone file. Missing MX or SPF records is the number one cause of email breaking after a WAF migration.
5. Set proxy status. Turn proxying on for the records that serve your website (usually @ and www). Keep mail records unproxied.
6. Update nameservers at your registrar. Replace the current ones with those provided. Propagation is typically under an hour, sometimes up to 24.
7. Force HTTPS. Enable Full (Strict) SSL mode or the equivalent, plus an automatic HTTP to HTTPS redirect. Make sure a valid certificate exists on the origin too.
8. Turn on the managed ruleset. Start in log or detection mode for 48 hours, review what would have been blocked, then switch to blocking.
9. Protect the login and admin paths. Add a rate limiting rule on /wp-login.php and /xmlrpc.php, for example 5 requests per minute per IP, then a managed challenge. If you never use XML-RPC, block it entirely.
10. Lock the origin. This is the step most people skip. In your hosting firewall or .htaccess, only allow HTTP traffic from your WAF provider’s published IP ranges. Otherwise attackers can bypass the WAF by hitting your server IP directly.
11. Restore real visitor IPs. Ensure your server or WordPress reads the forwarded IP header, otherwise your analytics, comment logs and any secondary tool will see a single proxy IP.

Sensible Starter Rules

• Challenge or block traffic from countries where you have zero customers, if your business is strictly local.
• Rate limit POST requests to your contact and search forms.
• Allowlist your office IP and your developer’s IP for /wp-admin.
• Block direct requests to readme.html, /wp-content/debug.log and backup file extensions.

Option 2: How to Set Up a Plugin-Based Firewall on WordPress

Choose this when you cannot change DNS or you want WordPress-aware protection such as “block requests trying to access a known vulnerable plugin file”.

Setup Steps

1. Install one security plugin only. Two plugin firewalls on the same site is the classic self-inflicted outage.
2. Run the setup wizard and let it perform its first scan before you change any settings.
3. Enable extended or optimized protection. This makes the firewall load before WordPress via auto_prepend_file in .user.ini or php.ini. It is a real performance and security upgrade over basic mode.
4. Keep learning mode on for about a week so the plugin builds allowlists from your normal admin activity. Log in, publish a post, upload media, place a test order.
5. Switch to blocking mode after the learning period.
6. Configure brute force protection: limit failed logins (5 attempts), lock out for 30 minutes, block immediately any login attempt using the username admin, and disable username enumeration via the REST API and author archives.
7. Enable two-factor authentication for every administrator and editor account. This single step prevents most real-world WordPress compromises.
8. Set up email alerts for blocked admin logins, plugin file changes and core file modifications. Send them to an address someone actually reads.
9. Schedule scans daily or weekly, outside peak traffic hours if you are on shared hosting.
10. Exclude heavy paths from scanning such as large media libraries, cache folders and backup directories, to keep CPU usage down.

Performance tip: if your plugin firewall pushes PHP memory or CPU beyond your shared hosting limits, that is a sign you should move the blocking to the cloud layer and keep the plugin for scanning and 2FA only.

Option 3: How to Set Up Server-Level Firewall Rules

Server rules run before PHP, so they are the cheapest in resources. On shared hosting your control is limited, but you still have levers.

On Shared Hosting (cPanel, Plesk, DirectAdmin)

1. Check if ModSecurity is already on. In cPanel look for ModSecurity under Security. Many hosts enable it silently with the OWASP Core Rule Set.
2. Ask support which ruleset is active and whether you can disable individual rule IDs. Never disable ModSecurity entirely to fix one broken form; disable the single offending rule ID instead.
3. Use IP Blocker for known bad IPs or ranges hammering your logs.
4. Turn on hotlink protection and leech protection if available.
5. Add targeted .htaccess rules. Keep them few and readable.

Example: protect the WordPress login with a small allowlist.

<Files wp-login.php>
  Require ip 203.0.113.10
  Require ip 198.51.100.0/24
</Files>

Example: block PHP execution inside the uploads folder (place in /wp-content/uploads/.htaccess).

<FilesMatch "\.(php|phtml|php7|phar)$">
  Require all denied
</FilesMatch>

Example: disable XML-RPC if you do not use the WordPress mobile app or Jetpack.

<Files xmlrpc.php>
  Require all denied
</Files>

On a VPS or Dedicated Server

1. Install ModSecurity 3 with the OWASP Core Rule Set for Apache or Nginx.
2. Run in DetectionOnly mode first and watch the audit log for at least a few days of real traffic.
3. Tune the paranoia level. Level 1 is right for most business sites; higher levels generate false positives on rich text editors and file uploads.
4. Add fail2ban to watch auth and access logs and drop repeat offenders at the network layer.
5. Configure the network firewall (ufw, firewalld or CSF): allow 80, 443 and your SSH port only, and restrict SSH to known IPs with key-based auth.
6. Switch ModSecurity to On once the noise is tuned out, and set up log rotation.

How to Test That Your Website Firewall Actually Works

1. Check the headers. Load your site and inspect the response headers for evidence the proxy is in front (server or CDN headers change once traffic is proxied).
2. Trigger a harmless test. Request a URL with an obvious probe pattern such as ?test=../../etc/passwd and confirm you receive a 403 page from the firewall, not your normal 404.
3. Attempt a bad login six times from a phone on mobile data and confirm you get rate limited.
4. Verify your origin is hidden. Use an online DNS history tool to check the old A record is not still exposed, and confirm your server IP does not serve the site directly.
5. Run a full customer journey: contact form, checkout, file upload, newsletter signup. Firewalls break forms far more often than they break pages.
6. Measure speed before and after with a page speed tool. If TTFB got worse, your layers are overlapping.

Ongoing Maintenance Checklist

Frequency	Task
Weekly	Skim the blocked requests log for false positives and new attack patterns
Weekly	Apply WordPress core, plugin and theme updates (a WAF buys time, it does not replace patching)
Monthly	Review admin users, remove stale accounts, confirm 2FA is active
Monthly	Test that a backup restores correctly
Quarterly	Re-check origin IP allowlists and firewall provider IP ranges

Common Mistakes We See on Small Business Sites

• Leaving the origin exposed after installing a cloud WAF, so the whole thing is bypassable.
• Running two plugin firewalls because one came bundled with the theme or host.
• Blocking all bots including Googlebot and Bingbot, then wondering why rankings dropped. Always verify crawler rules.
• Country blocking a market you actually serve, or blocking a country where a supplier or freelancer works.
• Treating the firewall as a substitute for updates. Most breaches exploit a known vulnerability in an outdated plugin.
• No alerting. A firewall nobody monitors is a log file with extra steps.

FAQ

How do I add a firewall to my website?

Pick one layer and configure it properly. The fastest route for a small business site is a cloud WAF: create an account, point your domain’s nameservers to the provider, enable the managed ruleset in detection mode, review logs for 48 hours, then switch to blocking and restrict your origin server to accept traffic only from the WAF.

Do I need a firewall if my host says security is included?

Ask exactly what is included. Many hosts run ModSecurity and basic network filtering, which is a genuine layer. If that is confirmed, add two-factor authentication, malware scanning and backups instead of a second blocking firewall.

Can I create my own firewall?

Yes, on a VPS or dedicated server you can build one with ModSecurity, the OWASP Core Rule Set, fail2ban and iptables or nftables. It is free but it needs tuning and monitoring. On shared hosting you cannot install one, so a cloud WAF or a plugin is the practical option.

How can I tell if my firewall is blocking a legitimate visitor?

Look for a 403 or a challenge page instead of your normal content. Then open the firewall’s event or audit log, find the entry matching that timestamp and IP, and read the rule ID that fired. Add a specific exception for that rule and path rather than disabling protection globally.

How do I block a specific IP address or country?

In a cloud WAF, use the IP access rules or a custom firewall rule with a country condition. On cPanel, use IP Blocker. In WordPress plugins, use the blocking or country blocking section. Always allowlist your own IP first so you cannot lock yourself out.

Will a WAF slow down my website?

A well-configured cloud WAF usually makes sites faster because it caches static assets and drops junk traffic before it reaches your server. A plugin firewall adds PHP work on every uncached request, and running several overlapping tools is what causes noticeable slowdown.

Is the free tier of a cloud WAF enough?

For a brochure site, a blog or a small service business, a free tier plus a handful of custom rules covers the common threats. Once you process payments, store customer data or run ads at scale, move to a paid plan with managed OWASP rules, bot management and proper rate limiting.

What should I do if my site is already hacked?

A firewall will not clean an existing infection. Take the site offline or into maintenance mode, restore a known clean backup, change all passwords and database credentials, update everything, then install the firewall and scan again before going live.

Need Help Choosing the Right Layer?

Most sites we audit are running two or three overlapping firewalls and are still exposed, usually because the origin server is reachable directly or nobody reads the alerts. If you want a clean setup with one properly tuned layer, correct rules for your forms and checkout, and monitoring that actually reaches a human, get in touch with our team and we will review your current configuration.