How to Protect a Site with a WAF

What is a WAF (Web Application Firewall)

A Web Application Firewall (WAF) is a security system that filters, monitors, and blocks malicious HTTP traffic to your web application. Unlike a classic network firewall that operates at the IP address and port level, a WAF understands the HTTP protocol and can analyze request content - URL parameters, POST data, cookies, HTTP headers, and the request body. This lets it detect and block attacks that would pass through a classic firewall.

Picture a WAF as the security at a restaurant entrance checking every guest. A classic firewall only verifies whether the guest has an invitation (correct IP and port). The WAF checks whether the guest is carrying weapons, fake documents, or has bad intent - it analyzes behavior, not just identity. In a world where roughly 2,800 cyber attacks happen every day, a WAF is a critical layer of protection for every website.

How a WAF works

A WAF sits between the user and the web server and analyzes every HTTP request before it reaches your application. Decisions are made based on predefined rules and algorithms.

Detection models

A WAF uses two main models for attack detection. The negative security model (blacklisting) blocks requests that contain known malicious patterns - SQL injection strings, XSS payloads, path traversal sequences, and so on. This is the most common approach because it's easier to implement, but it can't detect new, unknown attacks (zero-day). The positive security model (whitelisting) defines what's allowed and blocks everything else. This model is more secure but requires detailed configuration for every application because you have to define every legitimate parameter, URL, and data format.

What the WAF protects against

The WAF protects against the most common web attacks defined in the OWASP Top 10 list: SQL Injection (injecting SQL code through forms and URL parameters to access or modify the database), Cross-Site Scripting - XSS (injecting malicious JavaScript code that executes in other users' browsers), Cross-Site Request Forgery - CSRF (forcing an authenticated user to perform an unwanted action), Local/Remote File Inclusion (loading malicious files through the PHP include mechanism), Path Traversal (accessing files outside the web root using ../ sequences), Command Injection (executing system commands through a web application), and brute force attacks on login forms.

Actions the WAF can take

When the WAF detects a suspicious request, it can take various actions: block the request and return a 403 Forbidden error, allow the request but log it for later analysis (monitoring mode), trigger a CAPTCHA check to determine whether the user is a human or a bot, rate limit requests from a particular IP address, or temporarily block an IP address that sends many malicious requests. Modern WAF systems combine these actions based on threat severity.

Types of WAF

WAF solutions differ by where they're implemented and by architecture.

Cloud-based WAF

A cloud WAF is implemented by changing DNS records - traffic is routed through a cloud provider that filters malicious requests before they reach your server. Examples: Cloudflare WAF, Sucuri, AWS WAF, Akamai. Pros: simple implementation (no server-side changes required), scalability (cloud infrastructure absorbs DDoS attacks), automatic rule updates, and CDN benefits (faster site load). Cons: dependence on a third party, potential latency (extra hop), and monthly costs.

Host-based WAF

A host-based WAF is installed directly on the web server as a module or application. The most well-known example is ModSecurity, which integrates with Apache, Nginx, and LiteSpeed web servers. Pros: full control over configuration, no additional network hop, access to detailed logs on the server, and no monthly cost for cloud service. Cons: requires technical knowledge for configuration and maintenance, consumes server resources for request analysis, and rule updating is your responsibility.

Hybrid approach

The best protection is a combination of cloud and host-based WAFs. A cloud WAF (Cloudflare) filters volumetric attacks and known threats before they reach the server, while a host-based WAF (ModSecurity) provides deep inspection of requests that pass through the cloud layer. This defense-in-depth strategy ensures that even if one layer misses an attack, the other layer catches it.

Cloudflare WAF - configuration

Cloudflare is the most popular cloud WAF for small and medium sites because of its free plan that includes basic protection and affordable paid plans with advanced WAF features.

Basic setup

To use Cloudflare WAF, you need to create a Cloudflare account, add your domain, and change nameservers to Cloudflare's. After DNS propagation (usually 24-48 hours), all traffic to your site passes through the Cloudflare network. The free plan offers DDoS protection, a free encryption certificate, CDN, and basic bot protection. WAF rules are available from the Pro plan ($20/month).

Managed Rules

Cloudflare Managed Rules are pre-configured rules that protect against known vulnerabilities. The Cloudflare Managed Ruleset covers OWASP Top 10 attacks, the Cloudflare WordPress Ruleset is specifically designed for WordPress vulnerabilities, and Cloudflare Leaked Credentials Detection checks whether users are using compromised passwords. These rules are automatically updated when new threats are discovered.

Custom Rules

Besides managed rules, you can create custom WAF rules for your site's specific needs. For example: block access to the wp-admin page for everyone except your IP address, restrict access to xmlrpc.php, block requests from specific countries, require a CAPTCHA for the login page, or block user agents of known bots and scanners. Custom rules are created through the Cloudflare dashboard using a visual editor or Wire Format expression syntax.

Rate Limiting

Cloudflare Rate Limiting allows limiting the number of requests per IP address in a given time period. This is an effective defense against brute force attacks and API abuse. For example: limit the login page to 5 requests per minute per IP address, limit API endpoints to 100 requests per minute. Requests that exceed the limit can be blocked, trigger a CAPTCHA, or be redirected to an error page.

ModSecurity - configuration

ModSecurity is an open-source WAF engine that runs as a module on Apache, Nginx, and LiteSpeed servers. It's the most prevalent host-based WAF in the hosting industry.

Installation and basic setup

On cPanel servers, ModSecurity is installed through WHM (Web Host Manager) in one click. On Linux servers without cPanel, it's installed from packages (apt install libapache2-mod-security2 on Ubuntu/Debian). After installation, ModSecurity runs in Detection Only mode - logs suspicious requests but doesn't block them. This is recommended at the start to identify false positives before switching to enforcing mode.

OWASP Core Rule Set (CRS)

ModSecurity by itself doesn't contain rules - it needs a rule set. The OWASP Core Rule Set (CRS) is the most-used set of rules that covers OWASP Top 10 vulnerabilities. CRS uses an anomaly scoring system where every suspicious element of the request adds points, and a request is blocked only when the total score crosses the threshold (default 5). This reduces false positives because one suspicious element isn't enough for blocking - there must be multiple indicators of malicious behavior.

Fine-tuning rules

ModSecurity rules often generate false positives - blocking legitimate requests. The most common examples are: WordPress editor sending HTML/CSS code (looks like XSS), firewall plugins whose control panel forms contain security terms, and contact forms with specific content. To fix false positives, you can: disable a specific rule for a particular URL or directory, raise the anomaly scoring threshold, or add a whitelist rule for known safe requests. Review the ModSecurity audit log to identify which rules generate false positives.

ModSecurity on LiteSpeed

LiteSpeed Web Server has built-in support for ModSecurity rules without the need for an external module. LiteSpeed processes ModSecurity rules faster than Apache because it uses an optimized engine designed for LiteSpeed's event-driven architecture. The configuration is identical to Apache - the same rules, the same directives, but better performance.

WAF for WordPress - specific rules

WordPress sites are the most common target of attacks and require specific WAF rules in addition to generic ones.

Admin area protection

Restrict access to /wp-admin/ and /wp-login.php to known IP addresses or require additional authentication. Block access to sensitive files: wp-config.php, xmlrpc.php, wp-cron.php (allow only server-side access). Prevent user enumeration by blocking requests with the ?author= parameter that reveals usernames.

Protection from plugin vulnerabilities

WordPress plugins are the most common attack vector. WAF rules should block: direct access to PHP files in the wp-content/plugins/ directory (except for AJAX handlers), upload of malicious file types (.php, .phtml, .pht disguised as images), and exploitation of known vulnerabilities in popular plugins (Cloudflare and ModSecurity CRS have specific rules for WordPress plugin vulnerabilities).

Bot protection

A large percentage of traffic on WordPress sites comes from bots - good ones (Google bot, Bing bot) and bad ones (vulnerability scanners, content scrapers, brute force bots). The WAF should: allow known good bots based on user agent and IP ranges, block or rate limit known bad bots, trigger CAPTCHA for suspicious bots, and limit crawl rate for all bots so they don't load the server.

Monitoring and maintaining the WAF

A WAF isn't a "set and forget" solution. It requires regular monitoring and tuning.

Log analysis

Regularly review WAF logs to identify: false positives that block legitimate users (and adjust rules), attack patterns that may indicate a targeted attack, IP addresses or ranges that generate many malicious requests, and new attack types that may not be covered by existing rules. Cloudflare offers a visual dashboard for analysis, while ModSecurity uses text log files you can analyze with tools like GoAccess or the ELK stack.

Updating rules

New vulnerabilities are discovered daily and WAF rules must be updated to cover them. Cloud WAF solutions (Cloudflare) update rules automatically. For ModSecurity with OWASP CRS, update the rule set at least once a month. Follow security bulletins for WordPress, the plugins, and the themes you use, and add specific rules for newly discovered vulnerabilities before a patch becomes available (virtual patching).

Common WAF mistakes

• Overly aggressive rules: A WAF that blocks legitimate users is worse than no WAF at all because it drives visitors and customers away. Start in monitoring mode and gradually tighten rules.
• Relying on WAF alone: The WAF is one layer of protection, not a replacement for updated software, strong passwords, secure configuration, and backups. A defense-in-depth strategy is the only correct approach.
• Ignoring logs: WAF logs are gold - they show you exactly who is trying what on your site. Ignoring the logs means missing important threat signals.
• Outdated rules: A WAF with rules a year old is like an antivirus with an outdated database - it doesn't recognize new threats.
• No testing after changes: Every WAF rule change must be tested to confirm it doesn't block legitimate site functionality.

Conclusion

A WAF is an essential layer of protection for every website, especially WordPress sites that are the most common target of attacks. The combination of cloud WAF (Cloudflare) for volumetric and DDoS protection with host-based WAF (ModSecurity) for deep request inspection provides comprehensive protection. Start in monitoring mode, follow the logs, tune rules for your site, and update rule sets regularly. At BeoHosting, all hosting plans come with pre-configured ModSecurity WAF with the OWASP Core Rule Set optimized for WordPress, along with our recommendation to use Cloudflare's free plan for an additional layer of protection and CDN benefits.