Website security is a critical concern for WordPress site owners. With the increasing sophistication of cyber threats, having a reliable firewall is essential to protect your website from malicious attacks, data breaches, and unauthorized access.
In today’s digital landscape, website security is not just an option—it’s a necessity. WordPress, powering over 43% of all websites on the internet, is particularly vulnerable to attacks due to its popularity.
Here’s why implementing a WordPress firewall is crucial:
- Prevents unauthorized access and blocks malicious traffic
- Protects against common WordPress vulnerabilities
- Reduces the risk of data breaches and malware infections
- Maintains site performance and uptime
- Builds trust with your visitors by ensuring their data is secure
That’s where NinjaFirewall steps in as a powerful Web Application Firewall (WAF) designed specifically for WordPress sites. In this comprehensive guide, we’ll explore how to leverage NinjaFirewall’s custom rules to create a robust security shield for your WordPress website.
What is NinjaFirewall?
NinjaFirewall is a true Web Application Firewall that provides comprehensive protection for WordPress websites. Unlike many security plugins that operate after WordPress loads, NinjaFirewall works at the server level, filtering requests before they even reach your WordPress core files.
NinjaFirewall comes in two versions:
- NinjaFirewall WP Edition (Free) – Available in the WordPress.org repository
- NinjaFirewall WP+ Edition (Premium) – Offers additional advanced features
The key difference between NinjaFirewall and conventional security plugins is when and how it operates. It filters requests before WordPress or any of its plugins load, making it more effective at stopping threats before they reach your system.
How NinjaFirewall Works
When a visitor or an attacker comes to your site, this is what happens with NinjaFirewall installed (as explained in the official documentation):
|
1 2 3 |
Visitor → HTTP server → PHP interpreter → NinjaFirewall #1 → WordPress → NinjaFirewall #2 → Plugins & Themes → WordPress exit → NinjaFirewall #3 |
NinjaFirewall’s three-part protection mechanism:
- NinjaFirewall #1: The most critical component, the Web Application Firewall runs before WordPress loads. This part uses hundreds of rules and customizable policies to block threats like SQL injections, XSS, and RCE attempts.
- NinjaFirewall #2: This component operates at the WordPress level, handling tasks like sending alerts when someone logs into your admin dashboard or detecting privilege escalation attempts.
- NinjaFirewall #3: Just before the PHP execution ends, NinjaFirewall checks and modifies HTTP headers and cookies to secure them further.
Understanding Firewall Policies vs. Custom Rules
Before diving into custom rules, it’s important to understand the built-in policies NinjaFirewall offers:
Basic Policies
These handle fundamental security measures like:
- HTTP/HTTPS traffic filtering
- File upload controls
- User account creation/deletion protection
- Admin privilege escalation prevention
Intermediate Policies
These control how NinjaFirewall deals with PHP superglobals (GET, POST, COOKIE, etc.) with two primary actions:
- Block: Immediately terminate the connection if a threat is detected
- Sanitize: Clean potentially dangerous inputs rather than blocking them
Advanced Policies
These address specific security concerns like:
- HTTP response headers
- PHP wrappers blocking
- PHP superglobals protection
- ASCII control character filtering
Creating Custom Rules with the .htninja File
While NinjaFirewall’s built-in policies provide excellent protection, custom rules allow you to tailor the firewall to your site’s specific needs. The primary method to add custom rules in NinjaFirewall is through the .htninja configuration file. You can learn more about this in the official documentation.
What is the .htninja file?
The .htninja file is a PHP configuration file that allows you to prepend your own PHP code to the firewall, executing before NinjaFirewall’s own code. This gives you powerful control over how requests are processed.
Where to place the .htninja file
You have two options for placing this file:
- Above your website document root (Recommended):
- If your document root is
/home/user/public_html/, place it at/home/user/.htninja - More secure as it’s outside the document root
- May not work if you have open_basedir restrictions
- If your document root is
- In your document root folder:
- If your document root is
/home/user/public_html/, place it at/home/user/public_html/.htninja - Use this if you have open_basedir restrictions
- Ensure your server blocks access to
.ht*files (Apache does this by default)
- If your document root is
Basic .htninja Structure
The .htninja file is a standard PHP file. Here’s a basic template:
|
1 2 3 4 5 6 7 8 9 10 11 |
<?php /* +===========================================================================================+ | NinjaFirewall optional configuration file | | | | See: https://blog.nintechnet.com/ninjafirewall-wp-edition-the-htninja-configuration-file/ | +===========================================================================================+ */ // Your custom code here</pre--> |
Note: It’s recommended to omit the PHP closing tag (?>) to prevent potential issues with headers.
Practical Custom Rules Examples
Now let’s look at practical examples of custom rules you can implement. You can find a sample .htninja file in the NinjaFirewall GitHub repository for reference:
1. IP Whitelisting and Blacklisting
Whitelist a single IP address:
|
1 2 3 4 5 6 7 |
// Whitelist IP 192.168.1.1 if ($_SERVER["REMOTE_ADDR"] == '192.168.1.1') { define('NFW_UWL', true); return 'ALLOW'; // whitelist } |
Whitelist multiple IP addresses:
|
1 2 3 4 5 6 7 8 |
// Whitelist IPs 192.168.1.1, 10.0.0.1, and 172.16.0.1 $ip_array = array('192.168.1.1', '10.0.0.1', '172.16.0.1'); if (in_array($_SERVER["REMOTE_ADDR"], $ip_array)) { define('NFW_UWL', true); return 'ALLOW'; // whitelist } |
Whitelist an IP range:
|
1 2 3 4 5 6 7 |
// Whitelist all IPs from 192.168.1.1 to 192.168.1.255 if (preg_match('/^192\.168\.1\.\d+$/', $_SERVER["REMOTE_ADDR"])) { define('NFW_UWL', true); return 'ALLOW'; // whitelist } |
Blacklist a single IP address:
|
1 2 3 4 5 6 |
// Block IP 192.168.1.100 if ($_SERVER["REMOTE_ADDR"] == '192.168.1.100') { return 'BLOCK'; // blacklist } |
Blacklist multiple IP addresses:
|
1 2 3 4 5 6 7 |
// Block IPs 192.168.1.100, 10.0.0.100, and 172.16.0.100 $ip_array = array('192.168.1.100', '10.0.0.100', '172.16.0.100'); if (in_array($_SERVER["REMOTE_ADDR"], $ip_array)) { return 'BLOCK'; // blacklist } |
2. CDN Integration
For websites using Content Delivery Networks (CDNs), you need to ensure that NinjaFirewall receives the correct visitor IP:
Cloudflare:
|
1 2 3 4 5 6 |
// Users of Cloudflare CDN if (!empty($_SERVER["HTTP_CF_CONNECTING_IP"]) && filter_var($_SERVER["HTTP_CF_CONNECTING_IP"], FILTER_VALIDATE_IP)) { $_SERVER["REMOTE_ADDR"] = $_SERVER["HTTP_CF_CONNECTING_IP"]; } |
Incapsula:
|
1 2 3 4 5 6 |
// Users of Incapsula CDN if (!empty($_SERVER["HTTP_INCAP_CLIENT_IP"]) && filter_var($_SERVER["HTTP_INCAP_CLIENT_IP"], FILTER_VALIDATE_IP)) { $_SERVER["REMOTE_ADDR"] = $_SERVER["HTTP_INCAP_CLIENT_IP"]; } |
Generic reverse proxy:
|
1 2 3 4 5 6 |
// Generic reverse proxy if (!empty($_SERVER['HTTP_X_FORWARDED_FOR']) && filter_var($_SERVER['HTTP_X_FORWARDED_FOR'], FILTER_VALIDATE_IP)) { $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR']; } |
3. URL-Based Filtering
Allow access to specific directories:
|
1 2 3 4 5 6 7 |
// Allow access to the /member-area/ directory if (strpos($_SERVER['SCRIPT_FILENAME'], '/member-area/') !== FALSE) { define('NFW_UWL', true); return 'ALLOW'; } |
Block requests to specific files:
|
1 2 3 4 5 6 |
// Block access to legacy.php file if (strpos($_SERVER['SCRIPT_NAME'], 'legacy.php') !== FALSE) { return 'BLOCK'; } |
4. Advanced Request Filtering
Block based on POST parameters:
|
1 2 3 4 5 6 |
// Block POST requests containing a 'shell_access' parameter if (isset($_POST['shell_access'])) { return 'BLOCK'; } |
Block suspicious query strings:
|
1 2 3 4 5 6 |
// Block requests with 'eval' in the query string if (isset($_SERVER['QUERY_STRING']) && strpos($_SERVER['QUERY_STRING'], 'eval') !== FALSE) { return 'BLOCK'; } |
Block suspicious user agents:
|
1 2 3 4 5 6 7 8 9 |
// Block common scraping/hacking user agents $bad_agents = array('dirbuster', 'nikto', 'sqlmap', 'nessus', 'vulnerability', 'scanner'); foreach ($bad_agents as $agent) { if (isset($_SERVER['HTTP_USER_AGENT']) && stripos($_SERVER['HTTP_USER_AGENT'], $agent) !== FALSE) { return 'BLOCK'; } } |
5. Custom Session Handling
NinjaFirewall (>=4.7) offers an alternative to PHP sessions that can improve performance for AJAX-heavy sites:
|
1 2 3 4 5 6 7 8 9 10 |
// Enable NinjaFirewall's own session handling const NFWSESSION = true; // Optionally, specify a custom session directory const NFWSESSION_DIR = '/path/to/custom/session/directory'; // Optionally, change the session lifetime (default is 1440 seconds) const NFWSESS_MAXLIFETIME = 2880; |
Advanced Custom Rules
For more security inspiration, check out these WordPress security best practices.
Protecting Against SQL Injection
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// Block SQL injection attempts in query parameters if (isset($_SERVER['QUERY_STRING'])) { $sql_patterns = array( 'union\s+select', 'select.+from', 'insert\s+into', 'drop\s+table', 'update.+set', '--\s' ); foreach ($sql_patterns as $pattern) { if (preg_match('/' . $pattern . '/i', $_SERVER['QUERY_STRING'])) { return 'BLOCK'; } } } |
Protecting File Upload Areas
|
1 2 3 4 5 6 7 8 9 |
// Only allow specific IPs to access the upload script if (strpos($_SERVER['SCRIPT_NAME'], 'upload.php') !== FALSE) { $allowed_ips = array('192.168.1.5', '10.0.0.15'); if (!in_array($_SERVER["REMOTE_ADDR"], $allowed_ips)) { return 'BLOCK'; } } |
Protecting Admin Areas with Extra Security
Protection of your WordPress admin area is critical. For more information, see the WordPress Codex on Administration Over SSL.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// Add extra protection to wp-admin for certain IP ranges if (strpos($_SERVER['SCRIPT_NAME'], '/wp-admin/') !== FALSE) { // Only allow corporate office IPs (example ranges) if (!preg_match('/^(192\.168\.1\.|10\.0\.0\.)/', $_SERVER["REMOTE_ADDR"])) { // If it's login.php, allow it (so remote workers can login) if (strpos($_SERVER['SCRIPT_NAME'], 'login.php') === FALSE) { return 'BLOCK'; } } } |
Rate Limiting for Specific Pages
While full rate limiting is more available in the WP+ Edition, you can create simple versions:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
// This example requires session support if (strpos($_SERVER['SCRIPT_NAME'], '/wp-login.php') !== FALSE && $_SERVER['REQUEST_METHOD'] === 'POST') { session_start(); // Initialize the counter if it doesn't exist if (!isset($_SESSION['login_attempts'])) { $_SESSION['login_attempts'] = 1; $_SESSION['first_attempt_time'] = time(); } else { $_SESSION['login_attempts']++; } // If more than 5 attempts in 5 minutes, block if ($_SESSION['login_attempts'] > 5 && (time() - $_SESSION['first_attempt_time']) < 300) { return 'BLOCK'; } // Reset counter after 5 minutes if ((time() - $_SESSION['first_attempt_time']) >= 300) { $_SESSION['login_attempts'] = 1; $_SESSION['first_attempt_time'] = time(); } } |
Tips and Best Practices
Testing Custom Rules
Always test your custom rules thoroughly before implementing them in production:
- Enable NinjaFirewall’s “Debugging Mode” in the Firewall Options page.
- Implement your custom rules one at a time.
- Monitor the firewall log for false positives.
- Disable “Debugging Mode” once you’re confident in your rules.
Preventing Lockouts
When implementing IP blocking rules:
- Always whitelist your own IP address first.
- Consider setting a time limit for temporary blocks.
- Have a backup access method (like SSH) to modify the
.htninjafile if needed. - For mission-critical sites, test in staging environments first.
Performance Considerations
Custom rules can impact performance, especially complex ones:
- Keep rules as simple and specific as possible.
- Avoid unnecessary regular expressions for high-traffic sites.
- Put the most frequently triggered rules at the top of the file.
- Consider using NinjaFirewall sessions instead of PHP sessions for AJAX-heavy sites.
Thoughts
NinjaFirewall provides a robust security solution for WordPress sites, and custom rules through the .htninja file allow you to tailor its protection to your specific needs. By implementing the examples and best practices in this guide, you can significantly enhance your WordPress site’s security posture and protect against a wide range of threats.
Remember that security is a continuous process, not a one-time setup. Regularly review your firewall logs, update your rules as needed, and stay informed about new security threats and best practices. With NinjaFirewall and custom rules, you’re taking a significant step toward keeping your WordPress site secure in an increasingly hostile digital landscape.
For additional WordPress security resources, check out:
- WordPress Security Hardening Guide
- OWASP Top Ten Web Application Security Risks
- NinjaFirewall Forum on WordPress.org
- Official NinTechNet Blog
Note: While the free NinjaFirewall WP Edition provides excellent protection, the WP+ Edition offers additional features like IP-based access control through the UI rather than requiring manual .htninja file modifications. Consider upgrading for mission-critical websites that require the most comprehensive protection.
