A Web Application Firewall (WAF) is one of the most important security tools available for protecting your website. Unlike traditional firewalls that filter traffic at the network level, a WAF operates at the application layer (Layer 7), inspecting HTTP/HTTPS requests and responses to detect and block malicious activity targeting your web applications. On SakuraHost servers, ModSecurity is the WAF engine that provides this protection. This guide explains how WAFs work, what ModSecurity protects against, and how to manage it on your hosting account.

What Is a Web Application Firewall?

A WAF sits between your website visitors and your web server, acting as a reverse proxy that inspects every HTTP request before it reaches your application. It analyzes request headers, body content, URL parameters, cookies, and other HTTP elements against a set of security rules. If a request matches a known attack pattern, the WAF blocks it before it can reach your website code.

What a WAF Protects Against

According to the OWASP Foundation, the most common web application vulnerabilities include:

Attack TypeDescriptionWAF Protection
SQL InjectionMalicious SQL code inserted through input fields to access/modify databasesBlocks requests containing SQL syntax in unexpected places
Cross-Site Scripting (XSS)Malicious scripts injected into web pages viewed by other usersDetects and blocks script injection attempts
Remote File Inclusion (RFI)Forces the server to load malicious files from remote serversBlocks requests attempting to include remote URLs
Local File Inclusion (LFI)Exploits file inclusion to access sensitive server files like /etc/passwdDetects path traversal attempts (../ patterns)
Cross-Site Request Forgery (CSRF)Forces authenticated users to perform unintended actionsValidates request origins and tokens
Command InjectionExecutes system commands through vulnerable application inputsBlocks system command patterns in requests

ModSecurity on SakuraHost

ModSecurity is an open-source WAF engine that runs as an Apache module on SakuraHost servers. It uses the OWASP Core Rule Set (CRS), a comprehensive collection of security rules maintained by the OWASP community. These rules are regularly updated to protect against newly discovered attack vectors.

Enabled by Default: ModSecurity is active on all SakuraHost hosting accounts by default. No setup or configuration is required on your part to benefit from its protection. The OWASP CRS rules are maintained and updated by our server administration team.

Managing ModSecurity in cPanel

Checking ModSecurity Status

Step 1: Log in to cPanel from your SakuraHost client area.
Step 2: Navigate to the Security section and click ModSecurity.
Step 3: You will see a list of your domains with their ModSecurity status (On/Off). Each domain can be managed independently.

When to Temporarily Disable ModSecurity

While ModSecurity is essential for security, there are situations where it may interfere with legitimate functionality:

  • False Positives: ModSecurity may block legitimate requests that happen to match an attack pattern. For example, posting content that contains code examples, SQL queries in educational content, or certain special characters.
  • Plugin/Theme Installation: Some WordPress themes or plugins may trigger ModSecurity rules during installation or configuration because they make requests that resemble attack patterns.
  • Custom Application Features: If you have developed custom functionality that uses unusual request patterns, ModSecurity may flag them.
Proceed with Caution: Disabling ModSecurity removes a critical security layer. Only disable it temporarily for troubleshooting and re-enable it immediately afterwards. If you need a permanent exception, contact SakuraHost Support to create a targeted rule exclusion rather than disabling the entire WAF.

Understanding ModSecurity Logs

When ModSecurity blocks a request, it generates an error log entry and returns a 403 Forbidden or 406 Not Acceptable response to the visitor. You can identify ModSecurity blocks in your error logs by looking for entries containing ModSecurity:

# Example ModSecurity block log entry: [error] [client 192.168.1.100] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Rx' with parameter `(?i:union.*select)' against variable `ARGS:search_query'. [file "/etc/modsecurity/crs/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"] [id "942100"] [msg "SQL Injection Attack Detected via libinjection"]

This log entry tells you: the client IP, the rule that matched (SQL injection detection), the specific parameter that triggered it (search_query), the rule file and ID, and the description of the detected threat.

Resolving False Positives

Method 1: Adjust Your Application Code

Often, the best solution is to modify your application to avoid triggering ModSecurity rules. For example, if a form submission is being blocked because user input contains SQL-like syntax, consider encoding or sanitizing the input before submission.

Method 2: Request Rule Exclusions

If a specific ModSecurity rule is consistently blocking legitimate functionality, contact SakuraHost Support with the following information:

  • The URL being blocked
  • The ModSecurity rule ID from the error log
  • A description of the legitimate action being blocked
  • The expected behaviour

Our team can add a targeted rule exclusion that allows your specific use case while maintaining protection against actual attacks.

Additional WAF Layers: Cloudflare

For enhanced protection, consider using Cloudflare's WAF in addition to ModSecurity. Cloudflare provides:

  • Edge-level filtering: Malicious requests are blocked at Cloudflare's edge network before they even reach your server
  • Managed rulesets: Cloudflare maintains its own rule sets with automatic updates for new threats
  • Bot management: Advanced bot detection beyond what ModSecurity provides
  • Rate limiting: Granular control over request rates per IP or per endpoint
  • IP reputation: Cloudflare leverages threat intelligence from millions of websites to identify malicious IPs

Using both Cloudflare and ModSecurity creates a defence-in-depth strategy where threats must pass through two independent WAF layers to reach your application.

Security Headers

In addition to WAF protection, implementing security headers strengthens your website's defence. Add these to your .htaccess file:

# Security Headers Header always set X-Content-Type-Options "nosniff" Header always set X-Frame-Options "SAMEORIGIN" Header always set X-XSS-Protection "1; mode=block" Header always set Referrer-Policy "strict-origin-when-cross-origin" Header always set Content-Security-Policy "upgrade-insecure-requests" Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

You can verify your security headers using the Mozilla Observatory, which provides a grade and specific recommendations for improvement.

Layered Security: A WAF is one component of a comprehensive security strategy. Combine it with SSL/TLS encryption, two-factor authentication, regular software updates, strong passwords, and secure coding practices for robust protection. Review the OWASP Top 10 regularly to stay informed about the most critical web application security risks.
Was this answer helpful? 0 Users Found This Useful (0 Votes)