Skip to content

Firewall firewall.json

Virtual Application-Layer Firewall

The framework includes a powerful virtual firewall that operates at the application layer, intercepting and evaluating requests before WordPress is even bootstrapped. This early-stage filtering reduces the attack surface, mitigates abusive behavior, and enhances performance.

A Virtual Firewall is a lightweight security layer that screens traffic with smart rules, custom IP logic, and zero plugin overhead — acting as your first line of defense before the WordPress core is touched.


📌 Overview

This firewall functions as a pre-request filter, enabling advanced threat controls directly from a central configuration file. By operating outside of the WordPress plugin stack, it provides a faster and more predictable response to malicious traffic.

Core benefits:

  • Stops malicious requests before WordPress loads
  • Reduces load on your server by rejecting abusive requests early
  • Keeps your firewall logic version-controlled and environment-aware

🛡️ Key Features

  • IP Filtering: Allowlist and blocklist support for individual IPs and CIDR ranges.

  • Rate Limiting: Throttle excessive requests from a single IP using a sliding window.

  • User-Agent Blocking: Block suspicious or unwanted traffic by user agent string.

  • Path Filtering: Block access to known WordPress targets like xmlrpc.php or wp-login.php.

  • Threat Intelligence Modules:

    • AbuseIPDB: Score-based IP reputation filtering
    • CrowdSec (optional): Real-time enrichment via local LAPI instance
  • Request Logging: Record blocked requests to aid with audits, debugging, or trend analysis.


⚙️ Configuration

All rules and settings are defined in a single JSON file:

configs/firewall.json

Example firewall.json:

json
{
  "enabled": true,
  "logBlockedRequests": true,
  "allowedIPs": [],
  "blockedIPs": [],
  "rateLimit": {
    "enabled": true,
    "maxRequests": 100,
    "windowSeconds": 60
  },
  "userAgentRules": {
    "blocked": ["BadBot", "curl"]
  },
  "pathFilters": {
    "blockedPaths": ["/wp-login.php", "/xmlrpc.php"]
  },
  "abuseIpDb": {
    "enabled": true,
    "threshold": 0.50,
    "cache_ttl": 3600
  },
  "crowdSec": {
    "enabled": false,
    "lapiUrl": "http://localhost:8080",
    "lapiKey": "CROWDSEC_LAPI_KEY"
  }
}

🔐 Threat Intelligence Modules

AbuseIPDB Integration

  • Purpose: Automatically block IPs with poor reputations.

  • Configuration:

    • enabled: Enable or disable AbuseIPDB integration.
    • threshold: Block if IP score ≥ threshold (0.0–1.0).
    • cache_ttl: Cache result per IP for performance (in seconds).

CrowdSec Integration (Optional)

  • Purpose: Use local CrowdSec LAPI to assess incoming IP risk.

  • Configuration:

    • enabled: Enable CrowdSec lookups.
    • lapiUrl: Full URL to local API instance.
    • lapiKey: Auth token for accessing LAPI.

📁 Logging

When logBlockedRequests is set to true, all denied requests are logged to:

var/storage/logs/

see Blocked IP Reference for documentation details.

Logging is Common Log Format (CLF)-inspired specification for recording blocked IP addresses, and can be rotated for compliance or monitoring pipelines.